Skip to content

K
Kernel

openeuler / Kernel
接近 2 年 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 21 11月, 2014 6 次提交
  3. 20 11月, 2014 8 次提交
    • G
      of/selftest: Fix testing when /aliases is missing · 788ec2fc
      由 Grant Likely 提交于 
      The /aliases node isn't always present in the device tree, but the
unittest code assumes that /aliases is there. Add a check when inserting
the testcase data to see if of_aliases needs to be updated, and undo the
settings when the nodes are removed.
Signed-off-by: NGrant Likely <grant.likely@linaro.org>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Gaurav Minocha <gaurav.minocha.os@gmail.com>
Cc: <stable@vger.kernel.org>
      788ec2fc
    • C
      IB/isert: Adjust CQ size to HW limits · b1a5ad00
      由 Chris Moore 提交于 
      isert has an issue of trying to create a CQ with more CQEs than are
supported by the hardware, that currently results in failures during
isert_device creation during first session login.

This is the isert version of the patch that Minh Tran submitted for
iser, and is simple a workaround required to function with existing
ocrdma hardware.
Signed-off-by: NChris Moore <chris.moore@emulex.com>
Reviewied-by: NSagi Grimberg <sagig@mellanox.com>
Cc: <stable@vger.kernel.org> # 3.10+
Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>
      b1a5ad00
    • R
      ACPI / PM: Ignore wakeup setting if the ACPI companion can't wake up · 78579b7c
      由 Rafael J. Wysocki 提交于 
      As reported by Dmitry, on some Chromebooks there are devices with
corresponding ACPI objects and with unusual system wakeup
configuration.  Namely, they technically are wakeup-capable, but the
wakeup is handled via a platform-specific out-of-band mechanism and
the ACPI PM layer has no information on the wakeup capability.  As
a result, device_may_wakeup(dev) called from acpi_dev_suspend_late()
returns 'true' for those devices, but the wakeup.flags.valid flag is
unset for the corresponding ACPI device objects, so acpi_device_wakeup()
reproducibly fails for them causing acpi_dev_suspend_late() to return
an error code.  The entire system suspend is then aborted and the
machines in question cannot suspend at all.

Address the problem by ignoring the device_may_wakeup(dev) return
value in acpi_dev_suspend_late() if the ACPI companion of the device
being handled has wakeup.flags.valid unset (in which case it is clear
that the wakeup is supposed to be handled by other means).

This fixes a regression introduced by commit a76e9bd8 (i2c:
attach/detach I2C client device to the ACPI power domain) as the
affected systems could suspend and resume successfully before that
commit.

Fixes: a76e9bd8 (i2c: attach/detach I2C client device to the ACPI power domain)
Reported-by: NDmitry Torokhov <dtor@chromium.org>
Reviewed-by: NDmitry Torokhov <dtor@chromium.org>
Cc: 3.13+ <stable@vger.kernel.org> # 3.13+
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      78579b7c
    • A
      cxgb4i : Don't block unload/cxgb4 unload when remote closes TCP connection · ee7255ad
      由 Anish Bhatt 提交于 
      cxgb4i was returning wrong error and not releasing module reference if remote
end abruptly closed TCP connection. This prevents the cxgb4 network module from
being unloaded, further affecting other network drivers dependent on cxgb4

Sending to net as this affects all cxgb4 based network drivers.
Signed-off-by: NAnish Bhatt <anish@chelsio.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ee7255ad
    • Y
      PCI: Support 64-bit bridge windows if we have 64-bit dma_addr_t · 7fc986d8
      由 Yinghai Lu 提交于 
      Aaron reported that a 32-bit x86 kernel with Physical Address Extension
(PAE) support complains about bridge prefetchable memory windows above 4GB:

  pci_bus 0000:00: root bus resource [mem 0x380000000000-0x383fffffffff]
  ...
  pci 0000:03:00.0: reg 0x10: [mem 0x383fffc00000-0x383fffdfffff 64bit pref]
  pci 0000:03:00.0: reg 0x20: [mem 0x383fffe04000-0x383fffe07fff 64bit pref]
  pci 0000:03:00.1: reg 0x10: [mem 0x383fffa00000-0x383fffbfffff 64bit pref]
  pci 0000:03:00.1: reg 0x20: [mem 0x383fffe00000-0x383fffe03fff 64bit pref]
  pci 0000:00:02.2: PCI bridge to [bus 03-04]
  pci 0000:00:02.2:   bridge window [io  0x1000-0x1fff]
  pci 0000:00:02.2:   bridge window [mem 0x91900000-0x91cfffff]
  pci 0000:00:02.2: can't handle 64-bit address space for bridge

In this kernel, unsigned long is 32 bits and dma_addr_t is 64 bits.
Previously we used "unsigned long" to hold the bridge window address.  But
this is a bus address, so we should use dma_addr_t instead.

Use dma_addr_t to hold the bridge window base and limit.

The question of whether the CPU can actually *address* the window is
separate and depends on what the physical address space of the CPU is and
whether the host bridge does any address translation.

[bhelgaas: fix "shift count > width of type", changelog, stable tag]
Fixes: d56dbf5b ("PCI: Allocate 64-bit BARs above 4G when possible")
Link: https://bugzilla.kernel.org/show_bug.cgi?id=88131Reported-by: NAaron Ma <mapengyu@gmail.com>
Tested-by: NAaron Ma <mapengyu@gmail.com>
Signed-off-by: NYinghai Lu <yinghai@kernel.org>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
CC: stable@vger.kernel.org	# v3.14+
      7fc986d8
    • O
      net/mlx4_en: Add VXLAN ndo calls to the PF net device ops too · 9737c6ab
      由 Or Gerlitz 提交于 
      This is currently missing, which results in a crash when one attempts
to set VXLAN tunnel over the mlx4_en when acting as PF.

	[ 2408.785472] BUG: unable to handle kernel NULL pointer dereference at (null)
	[...]
	[ 2408.994104] Call Trace:
	[ 2408.996584]  [<ffffffffa021f7f5>] ? vxlan_get_rx_port+0xd6/0x103 [vxlan]
	[ 2409.003316]  [<ffffffffa021f71f>] ? vxlan_lowerdev_event+0xf2/0xf2 [vxlan]
	[ 2409.010225]  [<ffffffffa0630358>] mlx4_en_start_port+0x862/0x96a [mlx4_en]
	[ 2409.017132]  [<ffffffffa063070f>] mlx4_en_open+0x17f/0x1b8 [mlx4_en]

While here, make sure to invoke vxlan_get_rx_port() only when VXLAN
offloads are actually enabled and not when they are only supported.
Reported-by: NIdo Shamay <idos@mellanox.com>
Signed-off-by: NOr Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9737c6ab
    • N
      bonding: fix curr_active_slave/carrier with loadbalance arp monitoring · b8e4500f
      由 Nikolay Aleksandrov 提交于 
      Since commit 6fde8f03 ("bonding: fix locking in
bond_loadbalance_arp_mon()") we can have a stale bond carrier state and
stale curr_active_slave when using arp monitoring in loadbalance modes. The
reason is that in bond_loadbalance_arp_mon() we can't have
do_failover == true but slave_state_changed == false, whenever do_failover
is true then slave_state_changed is also true. Then the following piece
from bond_loadbalance_arp_mon():
                if (slave_state_changed) {
                        bond_slave_state_change(bond);
                        if (BOND_MODE(bond) == BOND_MODE_XOR)
                                bond_update_slave_arr(bond, NULL);
                } else if (do_failover) {
                        block_netpoll_tx();
                        bond_select_active_slave(bond);
                        unblock_netpoll_tx();
                }

will execute only the first branch, always and regardless of do_failover.
Since these two events aren't related in such way, we need to decouple and
consider them separately.

For example this issue could lead to the following result:
Bonding Mode: load balancing (round-robin)
*MII Status: down*
MII Polling Interval (ms): 0
Up Delay (ms): 0
Down Delay (ms): 0
ARP Polling Interval (ms): 100
ARP IP target/s (n.n.n.n form): 192.168.9.2

Slave Interface: ens12
*MII Status: up*
Speed: 10000 Mbps
Duplex: full
Link Failure Count: 2
Permanent HW addr: 00:0f:53:01:42:2c
Slave queue ID: 0

Slave Interface: eth1
*MII Status: up*
Speed: Unknown
Duplex: Unknown
Link Failure Count: 70
Permanent HW addr: 52:54:00:2f:0f:8e
Slave queue ID: 0

Since some interfaces are up, then the status of the bond should also be
up, but it will never change unless something invokes bond_set_carrier()
(i.e. enslave, bond_select_active_slave etc). Now, if I force the
calling of bond_select_active_slave via for example changing
primary_reselect (it can change in any mode), then the MII status goes to
"up" because it calls bond_select_active_slave() which should've been done
from bond_loadbalance_arp_mon() itself.

CC: Veaceslav Falico <vfalico@gmail.com>
CC: Jay Vosburgh <j.vosburgh@gmail.com>
CC: Andy Gospodarek <andy@greyhouse.net>
CC: Ding Tianhong <dingtianhong@huawei.com>

Fixes: 6fde8f03 ("bonding: fix locking in bond_loadbalance_arp_mon()")
Signed-off-by: NNikolay Aleksandrov <nikolay@redhat.com>
Acked-by: NVeaceslav Falico <vfalico@gmail.com>
Acked-by: NAndy Gospodarek <gospo@cumulusnetworks.com>
Acked-by: NDing Tianhong <dingtianhong@huawei.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b8e4500f
    • G
      of/selftest: Fix off-by-one error in removal path · c1a2086e
      由 Grant Likely 提交于 
      The removal path for selftest data has an off by one error that causes
the code to dereference beyond the end of the nodes[] array on the first
pass through. The old code only worked by chance on a lot of platforms,
but the bug was recently exposed on aarch64.

The fix is simple. Decrement the node count before dereferencing, not
after.
Reported-by: NKevin Hilman <khilman@linaro.org>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Gaurav Minocha <gaurav.minocha.os@gmail.com>
Cc: <stable@vger.kernel.org> # v3.17+
      c1a2086e
  5. 19 11月, 2014 17 次提交
  7. 18 11月, 2014 7 次提交
    • S
      can: remove unused variable · 4e2061b1
      由 Sudip Mukherjee 提交于 
      these variable were only assigned some values, but then never
reused again.
so they are safe to be removed.
Signed-off-by: NSudip Mukherjee <sudip@vectorindia.org>
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
      4e2061b1
    • A
      can: esd_usb2: fix memory leak on disconnect · efbd50d2
      由 Alexey Khoroshilov 提交于 
      It seems struct esd_usb2 dev is not deallocated on disconnect. The patch adds
the missing deallocation.

Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: NAlexey Khoroshilov <khoroshilov@ispras.ru>
Acked-by: NMatthias Fuchs <matthias.fuchs@esd.eu>
Cc: linux-stable <stable@vger.kernel.org>
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
      efbd50d2
    • R
      can: dev: fix typo CIA -> CiA, CAN in Automation · 67b5909e
      由 Roman Fietze 提交于 
      This patch fixes a typo in CAN's dev.c:

    CIA -> CiA

which stands for CAN in Automation.
Signed-off-by: NRoman Fietze <roman.fietze@telemotive.de>
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
      67b5909e
    • T
      can: dev: avoid calling kfree_skb() from interrupt context · 5247a589
      由 Thomas Körper 提交于 
      ikfree_skb() is Called in can_free_echo_skb(), which might be called from (TX
Error) interrupt, which triggers the folloing warning:

[ 1153.360705] ------------[ cut here ]------------
[ 1153.360715] WARNING: CPU: 0 PID: 31 at net/core/skbuff.c:563 skb_release_head_state+0xb9/0xd0()
[ 1153.360772] Call Trace:
[ 1153.360778]  [<c167906f>] dump_stack+0x41/0x52
[ 1153.360782]  [<c105bb7e>] warn_slowpath_common+0x7e/0xa0
[ 1153.360784]  [<c158b909>] ? skb_release_head_state+0xb9/0xd0
[ 1153.360786]  [<c158b909>] ? skb_release_head_state+0xb9/0xd0
[ 1153.360788]  [<c105bc42>] warn_slowpath_null+0x22/0x30
[ 1153.360791]  [<c158b909>] skb_release_head_state+0xb9/0xd0
[ 1153.360793]  [<c158be90>] skb_release_all+0x10/0x30
[ 1153.360795]  [<c158bf06>] kfree_skb+0x36/0x80
[ 1153.360799]  [<f8486938>] ? can_free_echo_skb+0x28/0x40 [can_dev]
[ 1153.360802]  [<f8486938>] can_free_echo_skb+0x28/0x40 [can_dev]
[ 1153.360805]  [<f849a12c>] esd_pci402_interrupt+0x34c/0x57a [esd402]
[ 1153.360809]  [<c10a75b5>] handle_irq_event_percpu+0x35/0x180
[ 1153.360811]  [<c10a7623>] ? handle_irq_event_percpu+0xa3/0x180
[ 1153.360813]  [<c10a7731>] handle_irq_event+0x31/0x50
[ 1153.360816]  [<c10a9c7f>] handle_fasteoi_irq+0x6f/0x120
[ 1153.360818]  [<c10a9c10>] ? handle_edge_irq+0x110/0x110
[ 1153.360822]  [<c1011b61>] handle_irq+0x71/0x90
[ 1153.360823]  <IRQ>  [<c168152c>] do_IRQ+0x3c/0xd0
[ 1153.360829]  [<c1680b6c>] common_interrupt+0x2c/0x34
[ 1153.360834]  [<c107d277>] ? finish_task_switch+0x47/0xf0
[ 1153.360836]  [<c167c27b>] __schedule+0x35b/0x7e0
[ 1153.360839]  [<c10a5334>] ? console_unlock+0x2c4/0x4d0
[ 1153.360842]  [<c13df500>] ? n_tty_receive_buf_common+0x890/0x890
[ 1153.360845]  [<c10707b6>] ? process_one_work+0x196/0x370
[ 1153.360847]  [<c167c723>] schedule+0x23/0x60
[ 1153.360849]  [<c1070de1>] worker_thread+0x161/0x460
[ 1153.360852]  [<c1090fcf>] ? __wake_up_locked+0x1f/0x30
[ 1153.360854]  [<c1070c80>] ? rescuer_thread+0x2f0/0x2f0
[ 1153.360856]  [<c1074f01>] kthread+0xa1/0xc0
[ 1153.360859]  [<c1680401>] ret_from_kernel_thread+0x21/0x30
[ 1153.360861]  [<c1074e60>] ? kthread_create_on_node+0x110/0x110
[ 1153.360863] ---[ end trace 5ff83639cbb74b35 ]---

This patch replaces the kfree_skb() by dev_kfree_skb_any().
Signed-off-by: NThomas Körper <thomas.koerper@esd.eu>
Cc: linux-stable <stable@vger.kernel.org>
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
      5247a589
    • D
      brcmfmac: fix error handling of irq_of_parse_and_map · 4c69f05e
      由 Dmitry Torokhov 提交于 
      Return value of irq_of_parse_and_map() is unsigned int, with 0
indicating failure, so testing for negative result never works.
Signed-off-by: NDmitry Torokhov <dtor@chromium.org>
Cc: stable@vger.kernel.org # v3.17
Acked-by: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      4c69f05e
    • M
      brcmfmac: kill URB when request timed out · 8180bd47
      由 Mathy Vanhoef 提交于 
      Kill the submitted URB in brcmf_usb_dl_cmd if the request timed out. This
assures the URB is never submitted twice. It also prevents a possible
use-after-free of the URB transfer buffer if a timeout occurs.
Signed-off-by: NMathy Vanhoef <vanhoefm@gmail.com>
Acked-by: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      8180bd47
    • B
      ath9k: fix regression in bssidmask calculation · daad1660
      由 Ben Greear 提交于 
      The commit that went into 3.17:

    ath9k: Summarize hw state per channel context

    Group and set hw state (opmode, primary_sta, beacon conf) per
    channel context instead of whole list of vifs. This would allow
    each channel context to run in different mode (STA/AP).
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NRajkumar Manoharan <rmanohar@qti.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

broke multi-vif configuration due to not properly calculating
the bssid mask.

The test case that caught this was:

 create wlan0 and sta0-4 (6 total), not sure how much that matters.
 associate all 6 (works fine)
 disconnect 5 of them, leaving sta0 up
 Start trying to bring up the other 5 one at a time.  It will
 fail, with iw events looking like this (in these logs, several
 sta are trying to come up, but symptom is the same with just one)

The patch causing the regression made quite a few changes, but
the part I think caused this particular problem was not
recalculating the bssid mask when adding and removing interfaces.

Re-adding those calls fixes my test case.  Fix bad comment
as well.
Signed-off-by: NBen Greear <greearb@candelatech.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      daad1660
  9. 17 11月, 2014 2 次提交