| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Add a compatible for SFP+ cages. SFP+ cages are backwards compatible,
but the ethernet device behind them may not support the slower speeds
of SFP modules.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
|
|
Allow the Marvell 10G PHY to register with the SFP bus, so that SFP+
cages can work. This bypasses phylink, meaning that socket status
is not taken into account for the link state. Also, the tx-disable
signal must be commented out in DT for this to work...
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
|
|
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
|
|
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
|
|
mvneta is the only user of fixed_phy_update_state(), which has been
converted to use phylink instead. Remove fixed_phy_update_state().
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
|
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
|
The PSC sync change interrupt can fire multiple times while the link is
down. As this isn't information we make use of, it's pointless having
the interrupt enabled, so let's disable this interrupt.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
|
|
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
|
|
Convert mvneta to use phylink, which models the MAC to PHY link in
a generic, reusable form.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove unused sync status
|
|
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
|
Add support for SFP hotpluggable modules via sfp-bus and phylink.
This supports both copper and optical SFP modules, which require
different Serdes modes in order to properly negotiate the link.
Optical SFP modules typically require the Serdes link to be talking
1000BaseX mode - this is the gigabit ethernet mode defined by the
802.3 standard.
Copper SFP modules typically integrate a PHY in the module to convert
from Serdes to copper, and the PHY will be configured by the vendor
to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a
SGMII Serdes link. However, this is vendor defined, so we instead
detect the PHY, switch the link to SGMII mode, and use traditional
PHY based negotiation.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
|
Add in-band autonegotation support for 10GBase-KR mode.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
|
|
Add support for reading and writing the clause 45 MII registers.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
|
|
Add support for reading module EEPROMs through phylink.
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
|
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
|
|
The link between the ethernet MAC and its PHY has become more complex
as the interface evolves. This is especially true with serdes links,
where the part of the PHY is effectively integrated into the MAC.
Serdes links can be connected to a variety of devices, including SFF
modules soldered down onto the board with the MAC, a SFP cage with
a hotpluggable SFP module which may contain a PHY or directly modulate
the serdes signals onto optical media with or without a PHY, or even
a classical PHY connection.
Moreover, the negotiation information on serdes links comes in two
varieties - SGMII mode, where the PHY provides its speed/duplex/flow
control information to the MAC, and 1000base-X mode where both ends
exchange their abilities and each resolve the link capabilities.
This means we need a more flexible means to support these arrangements,
particularly with the hotpluggable nature of SFP, where the PHY can
be attached or detached after the network device has been brought up.
Ethtool information can come from multiple sources:
- we may have a PHY operating in either SGMII or 1000base-X mode, in
which case we take ethtool/mii data directly from the PHY.
- we may have a optical SFP module without a PHY, with the MAC
operating in 1000base-X mode - the ethtool/mii data needs to come
from the MAC.
- we may have a copper SFP module with a PHY whic can't be accessed,
which means we need to take ethtool/mii data from the MAC.
Phylink aims to solve this by providing an intermediary between the
MAC and PHY, providing a safe way for PHYs to be hotplugged, and
allowing a SFP driver to reconfigure the serdes connection.
Phylink also takes over support of fixed link connections, where the
speed/duplex/flow control are fixed, but link status may be controlled
by a GPIO signal. By avoiding the fixed-phy implementation, phylink
can provide a faster response to link events: fixed-phy has to wait for
phylib to operate its state machine, which can take several seconds.
In comparison, phylink takes milliseconds.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- remove sync status
- rework supported and advertisment handling
- add 1000base-x speed for fixed links
- use functionality exported from phy-core, reworking
__phylink_ethtool_ksettings_set for it
|
|
Add an I2C MDIO bus bridge library, to allow phylib to access PHYs which
are connected to an I2C bus instead of the more conventional MDIO bus.
Such PHYs can be found in SFP adapters and SFF modules.
Since PHYs appear at I2C bus address 0x40..0x5f, and 0x50/0x51 are
reserved for SFP EEPROMs/diagnostics, we must not allow the MDIO bus
to access these I2C addresses.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
|
phylink will need phy_start_machine exported, so lets export it as a
GPL symbol. Documentation/networking/phy.txt indicates that this
should be a PHY API function.
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
|
Sometimes, we need to do additional work between the PHY coming up and
marking the carrier present - for example, we may need to wait for the
PHY to MAC link to finish negotiation. This changes phylib to provide
a notification function pointer which avoids the built-in
netif_carrier_on() and netif_carrier_off() functions.
Standard ->adjust_link functionality is provided by hooking a helper
into the new ->phy_link_change method.
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
|
Add the missing 1000Base-X entry to the phy settings table. This was
not included because the original code could not cope with more than
32 bits of link mode mask.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
|
|
phy-core
phy_lookup_setting() provides useful functionality in ethtool code
outside phylib. Move it to phy-core and allow it to be re-used (eg,
in phylink) rather than duplicated elsewhere. Note that this supports
the larger linkmode space.
As we move the phy settings table, we also need to move the guts of
phy_supported_speeds() as well.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
|
|
Other code would like to make use of this, so make the speed and duplex
string generation visible, and place it in a separate file.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
|
|
Allow the phy settings table to support more than 32 link modes by
switching to the ethtool link mode bit number representation, rather
than storing the mask. This will allow phylink and other ethtool
code to share the settings table to look up settings.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
|
|
Add phylib support for the Marvell Alaska X 10 Gigabit PHY (MV88X3310).
This phy is able to operate at 10G, 1G, 100M and 10M speeds, and only
supports Clause 45 accesses.
The PHY appears (based on the vendor IDs) to be two different vendors
IP, with each devad containing several instances.
This PHY driver has only been tested with the RJ45 copper port, fiber
port and a Marvell Armada 8040-based ethernet interface.
It should be noted that to use the full range of speeds, MAC drivers
need to also reconfigure the link mode as per phydev->interface, since
the PHY automatically changes its interface mode depending on the
negotiated speed.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
|
|
Move the old 10G genphy support to sit beside the new clause 45 library
functions, so all the 10G phy code is together.
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
|
|
genphy_restart_aneg() can only restart autonegotiation on clause 22
PHYs. Add a phy_restart_aneg() function which selects between the
clause 22 and clause 45 restart functionality depending on the PHY
type.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
|
|
Add generic helpers for 802.3 clause 45 PHYs for >= 10Gbps support.
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
|
|
If the port reports that the link is up while we are resetting, there's
little point in waiting for the full duration.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
|
|
The cpuidle ->enter method expects the return value to be the sleep
state we entered. Returning negative numbers or other codes is not
permissible since coupled CPU idle was merged.
At least some of the mvebu_v7_cpu_suspend() implementations return the
value from cpu_suspend(), which returns zero if the CPU vectors back
into the kernel via cpu_resume() (the success case), or the non-zero
return value of the suspend actor, or one (failure cases).
We do not want to be returning the failure case value back to CPU idle
as that indicates that we successfully entered one of the deeper idle
states. Always return zero instead, indicating that we slept for the
shortest amount of time.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl
Pull pinctrl fix from Linus Walleij:
"Brian noticed that this regression has not got a proper fix for the
entire merge window and consequently we need to revert the offending
commit.
It's part of the RT-mainstream work, the dance goes like this, two
steps forward, one step back.
Summary:
- A last fix for v4.12, an IRQ problem reported early in the merge
window appears not to have been properly fixed, so the offending
commit will be reverted and we will find the proper fix for v4.13.
Hopefully"
* tag 'pinctrl-v4.12-4' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl:
Revert "pinctrl: rockchip: avoid hardirq-unsafe functions in irq_chip"
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio
Pull last minute fixes for GPIO from Linus Walleij:
- Fix another ACPI problem with broken BIOSes.
- Filter out the right GPIO events, making a very user-visible bug go
away.
* tag 'gpio-v4.12-4' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio:
gpio: acpi: Skip _AEI entries without a handler rather then aborting the scan
gpiolib: fix filtering out unwanted events
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux
Pull powerpc fixes from Michael Ellerman:
"Hopefully the last two powerpc fixes for 4.12.
The CXL one is larger than I'd usually send at rc7, but it fixes new
code this cycle, so better to have it working for the release. It was
actually sent a few weeks back but got blocked in testing behind
another fix that was causing issues.
We are still tracking one crash in v4.12-rc7, but only one person has
reproduced it and the commit identified by bisect doesn't touch any of
the relevant code, so I think it's 50/50 whether that commit is
actually the problem or it's some code layout / toolchain issue.
Two fixes for code we merged this cycle:
- cxl: Fixes for Coherent Accelerator Interface Architecture 2.0
- Avoid miscompilation w/GCC 4.6.3 on 32-bit - don't inline
copy_to/from_user()
Thanks to Al Viro, Larry Finger, Christophe Lombard"
* tag 'powerpc-4.12-8' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux:
powerpc/32: Avoid miscompilation w/GCC 4.6.3 - don't inline copy_to/from_user()
cxl: Fixes for Coherent Accelerator Interface Architecture 2.0
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu
Pull IOMMU fixes from Joerg Roedel:
"Two fixes:
- A fix for AMD IOMMU interrupt remapping code when IRQs are
forwarded directly to KVM guests
- Fixed check in the recently merged code to allow tboot with
Intel VT-d disabled"
* tag 'iommu-fixes-v4.12-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu:
iommu/amd: Fix interrupt remapping when disable guest_mode
iommu/vt-d: Correctly disable Intel IOMMU force on
|
|
Pull networking fixes from David Miller:
1) Need to access netdev->num_rx_queues behind an accessor in netvsc
driver otherwise the build breaks with some configs, from Arnd
Bergmann.
2) Add dummy xfrm_dev_event() so that build doesn't fail when
CONFIG_XFRM_OFFLOAD is not set. From Hangbin Liu.
3) Don't OOPS when pfkey_msg2xfrm_state() signals an erros, from Dan
Carpenter.
4) Fix MCDI command size for filter operations in sfc driver, from
Martin Habets.
5) Fix UFO segmenting so that we don't calculate incorrect checksums,
from Michal Kubecek.
6) When ipv6 datagram connects fail, reset destination address and
port. From Wei Wang.
7) TCP disconnect must reset the cached receive DST, from WANG Cong.
8) Fix sign extension bug on 32-bit in dev_get_stats(), from Eric
Dumazet.
9) fman driver has to depend on HAS_DMA, from Madalin Bucur.
10) Fix bpf pointer leak with xadd in verifier, from Daniel Borkmann.
11) Fix negative page counts with GFO, from Michal Kubecek.
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: (41 commits)
sfc: fix attempt to translate invalid filter ID
net: handle NAPI_GRO_FREE_STOLEN_HEAD case also in napi_frags_finish()
bpf: prevent leaking pointer via xadd on unpriviledged
arcnet: com20020-pci: add missing pdev setup in netdev structure
arcnet: com20020-pci: fix dev_id calculation
arcnet: com20020: remove needless base_addr assignment
Trivial fix to spelling mistake in arc_printk message
arcnet: change irq handler to lock irqsave
rocker: move dereference before free
mlxsw: spectrum_router: Fix NULL pointer dereference
net: sched: Fix one possible panic when no destroy callback
virtio-net: serialize tx routine during reset
net: usb: asix88179_178a: Add support for the Belkin B2B128
fsl/fman: add dependency on HAS_DMA
net: prevent sign extension in dev_get_stats()
tcp: reset sk_rx_dst in tcp_disconnect()
net: ipv6: reset daddr and dport in sk if connect() fails
bnx2x: Don't log mc removal needlessly
bnxt_en: Fix netpoll handling.
bnxt_en: Add missing logic to handle TPA end error conditions.
...
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm
Pull device mapper fixes from Mike Snitzer:
- dm thinp fix for crash that will occur when metadata device failure
races with discard passdown to the underlying data device.
- dm raid fix to not access the superblock's >= 1.9.0 'sectors' member
unconditionally.
* tag 'for-4.12/dm-fixes-5' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm:
dm thin: do not queue freed thin mapping for next stage processing
dm raid: fix oops on upgrading to extended superblock format
|
|
Pull block fixes from Jens Axboe:
"Two fixes that should go into this release.
One is an nvme regression fix from Keith, fixing a missing queue
freeze if the controller is being reset. This causes the reset to
hang.
The other is a fix for a leak of the bio protection info, if smaller
sized O_DIRECT is used. This fix should be more involved as we have
other problematic paths in the kernel, but given as this isn't a
regression in this series, we'll tackle those for 4.13"
* 'for-linus' of git://git.kernel.dk/linux-block:
block: provide bio_uninit() free freeing integrity/task associations
nvme/pci: Fix stuck nvme reset
|
|
When filter insertion fails with no rollback, we were trying to convert
EFX_EF10_FILTER_ID_INVALID to an id to store in 'ids' (which is either
vlan->uc or vlan->mc). This would WARN_ON_ONCE and then record a bogus
filter ID of 0x1fff, neither of which is a good thing.
Fixes: 0ccb998bf46d ("sfc: fix filter_id misinterpretation in edge case")
Signed-off-by: Edward Cree <ecree@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
We add the pdev data to the pci devices netdev structure. This way
the interface get consistent device names in the userspace (udev).
Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
The dev_id was miscalculated. Only the two bits 4-5 are relevant for the
MA1 card. PCIARC1 and PCIFB2 use the four bits 4-7 for id selection.
Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
The assignment is superfluous.
Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
This patch prevents the arcnet driver from the following deadlock.
[ 41.273910] ======================================================
[ 41.280397] [ INFO: SOFTIRQ-safe -> SOFTIRQ-unsafe lock order detected ]
[ 41.287433] 4.4.0-00034-gc0ae784 #536 Not tainted
[ 41.292366] ------------------------------------------------------
[ 41.298863] arcecho/233 [HC0[0]:SC0[2]:HE0:SE0] is trying to acquire:
[ 41.305628] (&(&lp->lock)->rlock){+.+...}, at: [<bf083bc8>] arcnet_send_packet+0x60/0x1c0 [arcnet]
[ 41.315199]
[ 41.315199] and this task is already holding:
[ 41.321324] (_xmit_ARCNET#2){+.-...}, at: [<c06b934c>] packet_direct_xmit+0xfc/0x1c8
[ 41.329593] which would create a new lock dependency:
[ 41.334893] (_xmit_ARCNET#2){+.-...} -> (&(&lp->lock)->rlock){+.+...}
[ 41.341801]
[ 41.341801] but this new dependency connects a SOFTIRQ-irq-safe lock:
[ 41.350108] (_xmit_ARCNET#2){+.-...}
... which became SOFTIRQ-irq-safe at:
[ 41.357539] [<c06f8fc8>] _raw_spin_lock+0x30/0x40
[ 41.362677] [<c063ab8c>] dev_watchdog+0x5c/0x264
[ 41.367723] [<c0094edc>] call_timer_fn+0x6c/0xf4
[ 41.372759] [<c00950b8>] run_timer_softirq+0x154/0x210
[ 41.378340] [<c0036b30>] __do_softirq+0x144/0x298
[ 41.383469] [<c0036fb4>] irq_exit+0xcc/0x130
[ 41.388138] [<c0085c50>] __handle_domain_irq+0x60/0xb4
[ 41.393728] [<c0014578>] __irq_svc+0x58/0x78
[ 41.398402] [<c0010274>] arch_cpu_idle+0x24/0x3c
[ 41.403443] [<c007127c>] cpu_startup_entry+0x1f8/0x25c
[ 41.409029] [<c09adc90>] start_kernel+0x3c0/0x3cc
[ 41.414170]
[ 41.414170] to a SOFTIRQ-irq-unsafe lock:
[ 41.419931] (&(&lp->lock)->rlock){+.+...}
... which became SOFTIRQ-irq-unsafe at:
[ 41.427996] ... [<c06f8fc8>] _raw_spin_lock+0x30/0x40
[ 41.433409] [<bf083d54>] arcnet_interrupt+0x2c/0x800 [arcnet]
[ 41.439646] [<c0089120>] handle_nested_irq+0x8c/0xec
[ 41.445063] [<c03c1170>] regmap_irq_thread+0x190/0x314
[ 41.450661] [<c0087244>] irq_thread_fn+0x1c/0x34
[ 41.455700] [<c0087548>] irq_thread+0x13c/0x1dc
[ 41.460649] [<c0050f10>] kthread+0xe4/0xf8
[ 41.465158] [<c000f810>] ret_from_fork+0x14/0x24
[ 41.470207]
[ 41.470207] other info that might help us debug this:
[ 41.470207]
[ 41.478627] Possible interrupt unsafe locking scenario:
[ 41.478627]
[ 41.485763] CPU0 CPU1
[ 41.490521] ---- ----
[ 41.495279] lock(&(&lp->lock)->rlock);
[ 41.499414] local_irq_disable();
[ 41.505636] lock(_xmit_ARCNET#2);
[ 41.511967] lock(&(&lp->lock)->rlock);
[ 41.518741] <Interrupt>
[ 41.521490] lock(_xmit_ARCNET#2);
[ 41.525356]
[ 41.525356] *** DEADLOCK ***
[ 41.525356]
[ 41.531587] 1 lock held by arcecho/233:
[ 41.535617] #0: (_xmit_ARCNET#2){+.-...}, at: [<c06b934c>] packet_direct_xmit+0xfc/0x1c8
[ 41.544355]
the dependencies between SOFTIRQ-irq-safe lock and the holding lock:
[ 41.552362] -> (_xmit_ARCNET#2){+.-...} ops: 27 {
[ 41.557357] HARDIRQ-ON-W at:
[ 41.560664] [<c06f8fc8>] _raw_spin_lock+0x30/0x40
[ 41.567445] [<c063ba28>] dev_deactivate_many+0x114/0x304
[ 41.574866] [<c063bc3c>] dev_deactivate+0x24/0x38
[ 41.581646] [<c0630374>] linkwatch_do_dev+0x40/0x74
[ 41.588613] [<c06305d8>] __linkwatch_run_queue+0xec/0x140
[ 41.596120] [<c0630658>] linkwatch_event+0x2c/0x34
[ 41.602991] [<c004af30>] process_one_work+0x188/0x40c
[ 41.610131] [<c004b200>] worker_thread+0x4c/0x480
[ 41.616912] [<c0050f10>] kthread+0xe4/0xf8
[ 41.623048] [<c000f810>] ret_from_fork+0x14/0x24
[ 41.629735] IN-SOFTIRQ-W at:
[ 41.633039] [<c06f8fc8>] _raw_spin_lock+0x30/0x40
[ 41.639820] [<c063ab8c>] dev_watchdog+0x5c/0x264
[ 41.646508] [<c0094edc>] call_timer_fn+0x6c/0xf4
[ 41.653190] [<c00950b8>] run_timer_softirq+0x154/0x210
[ 41.660425] [<c0036b30>] __do_softirq+0x144/0x298
[ 41.667201] [<c0036fb4>] irq_exit+0xcc/0x130
[ 41.673518] [<c0085c50>] __handle_domain_irq+0x60/0xb4
[ 41.680754] [<c0014578>] __irq_svc+0x58/0x78
[ 41.687077] [<c0010274>] arch_cpu_idle+0x24/0x3c
[ 41.693769] [<c007127c>] cpu_startup_entry+0x1f8/0x25c
[ 41.701006] [<c09adc90>] start_kernel+0x3c0/0x3cc
[ 41.707791] INITIAL USE at:
[ 41.711003] [<c06f8fc8>] _raw_spin_lock+0x30/0x40
[ 41.717696] [<c063ba28>] dev_deactivate_many+0x114/0x304
[ 41.725026] [<c063bc3c>] dev_deactivate+0x24/0x38
[ 41.731718] [<c0630374>] linkwatch_do_dev+0x40/0x74
[ 41.738593] [<c06305d8>] __linkwatch_run_queue+0xec/0x140
[ 41.746011] [<c0630658>] linkwatch_event+0x2c/0x34
[ 41.752789] [<c004af30>] process_one_work+0x188/0x40c
[ 41.759847] [<c004b200>] worker_thread+0x4c/0x480
[ 41.766541] [<c0050f10>] kthread+0xe4/0xf8
[ 41.772596] [<c000f810>] ret_from_fork+0x14/0x24
[ 41.779198] }
[ 41.780945] ... key at: [<c124d620>] netdev_xmit_lock_key+0x38/0x1c8
[ 41.788192] ... acquired at:
[ 41.791309] [<c007bed8>] lock_acquire+0x70/0x90
[ 41.796361] [<c06f9140>] _raw_spin_lock_irqsave+0x40/0x54
[ 41.802324] [<bf083bc8>] arcnet_send_packet+0x60/0x1c0 [arcnet]
[ 41.808844] [<c06b9380>] packet_direct_xmit+0x130/0x1c8
[ 41.814622] [<c06bc7e4>] packet_sendmsg+0x3b8/0x680
[ 41.820034] [<c05fe8b0>] sock_sendmsg+0x14/0x24
[ 41.825091] [<c05ffd68>] SyS_sendto+0xb8/0xe0
[ 41.829956] [<c05ffda8>] SyS_send+0x18/0x20
[ 41.834638] [<c000f780>] ret_fast_syscall+0x0/0x1c
[ 41.839954]
[ 41.841514]
the dependencies between the lock to be acquired and SOFTIRQ-irq-unsafe lock:
[ 41.850302] -> (&(&lp->lock)->rlock){+.+...} ops: 5 {
[ 41.855644] HARDIRQ-ON-W at:
[ 41.858945] [<c06f8fc8>] _raw_spin_lock+0x30/0x40
[ 41.865726] [<bf083d54>] arcnet_interrupt+0x2c/0x800 [arcnet]
[ 41.873607] [<c0089120>] handle_nested_irq+0x8c/0xec
[ 41.880666] [<c03c1170>] regmap_irq_thread+0x190/0x314
[ 41.887901] [<c0087244>] irq_thread_fn+0x1c/0x34
[ 41.894593] [<c0087548>] irq_thread+0x13c/0x1dc
[ 41.901195] [<c0050f10>] kthread+0xe4/0xf8
[ 41.907338] [<c000f810>] ret_from_fork+0x14/0x24
[ 41.914025] SOFTIRQ-ON-W at:
[ 41.917328] [<c06f8fc8>] _raw_spin_lock+0x30/0x40
[ 41.924106] [<bf083d54>] arcnet_interrupt+0x2c/0x800 [arcnet]
[ 41.931981] [<c0089120>] handle_nested_irq+0x8c/0xec
[ 41.939028] [<c03c1170>] regmap_irq_thread+0x190/0x314
[ 41.946264] [<c0087244>] irq_thread_fn+0x1c/0x34
[ 41.952954] [<c0087548>] irq_thread+0x13c/0x1dc
[ 41.959548] [<c0050f10>] kthread+0xe4/0xf8
[ 41.965689] [<c000f810>] ret_from_fork+0x14/0x24
[ 41.972379] INITIAL USE at:
[ 41.975595] [<c06f8fc8>] _raw_spin_lock+0x30/0x40
[ 41.982283] [<bf083d54>] arcnet_interrupt+0x2c/0x800 [arcnet]
[ 41.990063] [<c0089120>] handle_nested_irq+0x8c/0xec
[ 41.997027] [<c03c1170>] regmap_irq_thread+0x190/0x314
[ 42.004172] [<c0087244>] irq_thread_fn+0x1c/0x34
[ 42.010766] [<c0087548>] irq_thread+0x13c/0x1dc
[ 42.017267] [<c0050f10>] kthread+0xe4/0xf8
[ 42.023314] [<c000f810>] ret_from_fork+0x14/0x24
[ 42.029903] }
[ 42.031648] ... key at: [<bf0854cc>] __key.42091+0x0/0xfffff0f8 [arcnet]
[ 42.039255] ... acquired at:
[ 42.042372] [<c007bed8>] lock_acquire+0x70/0x90
[ 42.047413] [<c06f9140>] _raw_spin_lock_irqsave+0x40/0x54
[ 42.053364] [<bf083bc8>] arcnet_send_packet+0x60/0x1c0 [arcnet]
[ 42.059872] [<c06b9380>] packet_direct_xmit+0x130/0x1c8
[ 42.065634] [<c06bc7e4>] packet_sendmsg+0x3b8/0x680
[ 42.071030] [<c05fe8b0>] sock_sendmsg+0x14/0x24
[ 42.076069] [<c05ffd68>] SyS_sendto+0xb8/0xe0
[ 42.080926] [<c05ffda8>] SyS_send+0x18/0x20
[ 42.085601] [<c000f780>] ret_fast_syscall+0x0/0x1c
[ 42.090918]
[ 42.092481]
[ 42.092481] stack backtrace:
[ 42.097065] CPU: 0 PID: 233 Comm: arcecho Not tainted 4.4.0-00034-gc0ae784 #536
[ 42.104751] Hardware name: Generic AM33XX (Flattened Device Tree)
[ 42.111183] [<c0017ec8>] (unwind_backtrace) from [<c00139d0>] (show_stack+0x10/0x14)
[ 42.119337] [<c00139d0>] (show_stack) from [<c02a82c4>] (dump_stack+0x8c/0x9c)
[ 42.126937] [<c02a82c4>] (dump_stack) from [<c0078260>] (check_usage+0x4bc/0x63c)
[ 42.134815] [<c0078260>] (check_usage) from [<c0078438>] (check_irq_usage+0x58/0xb0)
[ 42.142964] [<c0078438>] (check_irq_usage) from [<c007aaa0>] (__lock_acquire+0x1524/0x20b0)
[ 42.151740] [<c007aaa0>] (__lock_acquire) from [<c007bed8>] (lock_acquire+0x70/0x90)
[ 42.159886] [<c007bed8>] (lock_acquire) from [<c06f9140>] (_raw_spin_lock_irqsave+0x40/0x54)
[ 42.168768] [<c06f9140>] (_raw_spin_lock_irqsave) from [<bf083bc8>] (arcnet_send_packet+0x60/0x1c0 [arcnet])
[ 42.179115] [<bf083bc8>] (arcnet_send_packet [arcnet]) from [<c06b9380>] (packet_direct_xmit+0x130/0x1c8)
[ 42.189182] [<c06b9380>] (packet_direct_xmit) from [<c06bc7e4>] (packet_sendmsg+0x3b8/0x680)
[ 42.198059] [<c06bc7e4>] (packet_sendmsg) from [<c05fe8b0>] (sock_sendmsg+0x14/0x24)
[ 42.206199] [<c05fe8b0>] (sock_sendmsg) from [<c05ffd68>] (SyS_sendto+0xb8/0xe0)
[ 42.213978] [<c05ffd68>] (SyS_sendto) from [<c05ffda8>] (SyS_send+0x18/0x20)
[ 42.221388] [<c05ffda8>] (SyS_send) from [<c000f780>] (ret_fast_syscall+0x0/0x1c)
Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
---
v1 -> v2: removed unneeded zero assignment of flags
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
My static checker complains that ofdpa_neigh_del() can sometimes free
"found". It just makes sense to use it first before deleting it.
Fixes: ecf244f753e0 ("rocker: fix maybe-uninitialized warning")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
In case a VLAN device is enslaved to a bridge we shouldn't create a
router interface (RIF) for it when it's configured with an IP address.
This is already handled by the driver for other types of netdevs, such
as physical ports and LAG devices.
If this IP address is then removed and the interface is subsequently
unlinked from the bridge, a NULL pointer dereference can happen, as the
original 802.1d FID was replaced with an rFID which was then deleted.
To reproduce:
$ ip link set dev enp3s0np9 up
$ ip link add name enp3s0np9.111 link enp3s0np9 type vlan id 111
$ ip link set dev enp3s0np9.111 up
$ ip link add name br0 type bridge
$ ip link set dev br0 up
$ ip link set enp3s0np9.111 master br0
$ ip address add dev enp3s0np9.111 192.168.0.1/24
$ ip address del dev enp3s0np9.111 192.168.0.1/24
$ ip link set dev enp3s0np9.111 nomaster
Fixes: 99724c18fc66 ("mlxsw: spectrum: Introduce support for router interfaces")
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Reported-by: Petr Machata <petrm@mellanox.com>
Tested-by: Petr Machata <petrm@mellanox.com>
Reviewed-by: Petr Machata <petrm@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
We don't hold any tx lock when trying to disable TX during reset, this
would lead a use after free since ndo_start_xmit() tries to access
the virtqueue which has already been freed. Fix this by using
netif_tx_disable() before freeing the vqs, this could make sure no tx
after vq freeing.
Reported-by: Jean-Philippe Menil <jpmenil@gmail.com>
Tested-by: Jean-Philippe Menil <jpmenil@gmail.com>
Fixes commit f600b6905015 ("virtio_net: Add XDP support")
Cc: John Fastabend <john.fastabend@gmail.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Acked-by: Robert McCabe <robert.mccabe@rockwellcollins.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
This reverts commit 88bb94216f59e10802aaf78c858a4146085faf18.
It introduced a new CONFIG_DEBUG_ATOMIC_SLEEP warning in v4.12-rc1:
[ 7226.716713] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:238
[ 7226.716716] in_atomic(): 0, irqs_disabled(): 0, pid: 1708, name: bash
[ 7226.716722] CPU: 1 PID: 1708 Comm: bash Not tainted 4.12.0-rc6+ #1213
[ 7226.716724] Hardware name: Google Kevin (DT)
[ 7226.716726] Call trace:
[ 7226.716738] [<ffffff8008089928>] dump_backtrace+0x0/0x24c
[ 7226.716743] [<ffffff8008089b94>] show_stack+0x20/0x28
[ 7226.716749] [<ffffff8008371370>] dump_stack+0x90/0xb0
[ 7226.716755] [<ffffff80080cd2a0>] ___might_sleep+0x10c/0x124
[ 7226.716760] [<ffffff80080cd330>] __might_sleep+0x78/0x88
[ 7226.716765] [<ffffff800879e210>] mutex_lock+0x2c/0x64
[ 7226.716771] [<ffffff80083ad678>] rockchip_irq_bus_lock+0x30/0x3c
[ 7226.716777] [<ffffff80080f6d40>] __irq_get_desc_lock+0x78/0x98
[ 7226.716782] [<ffffff80080f7e6c>] irq_set_irq_wake+0x44/0x12c
[ 7226.716787] [<ffffff8008486e18>] dev_pm_arm_wake_irq+0x4c/0x58
[ 7226.716792] [<ffffff800848b80c>] device_wakeup_arm_wake_irqs+0x3c/0x58
[ 7226.716796] [<ffffff80084896fc>] dpm_suspend_noirq+0xf8/0x3a0
[ 7226.716800] [<ffffff80080f1384>] suspend_devices_and_enter+0x1a4/0x9a8
[ 7226.716803] [<ffffff80080f21ec>] pm_suspend+0x664/0x6a4
[ 7226.716807] [<ffffff80080f04d8>] state_store+0xd4/0xf8
...
It was reported on -rc1, and it's still not fixed in -rc6, so it should
just be reverted.
Cc: John Keeping <john@metanate.com>
Signed-off-by: Brian Norris <briannorris@chromium.org>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
|
acpi_walk_resources will stop as soon as the callback passed in returns
an error status. On a x86 tablet I have the first GpioInt in the _AEI
resource list has no handler defined in the DSDT, causing
acpi_walk_resources to abort scanning the rest of the resource list,
which does define valid ACPI GPIO events.
This commit changes the return for not finding a handler from
AE_BAD_PARAMETER to AE_OK so that the rest of the resource list will
get scanned normally in case of missing event handlers.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
|
GPIOEVENT_REQUEST_BOTH_EDGES is not a single flag, but a binary OR of
GPIOEVENT_REQUEST_RISING_EDGE and GPIOEVENT_REQUEST_FALLING_EDGE.
The expression 'le->eflags & GPIOEVENT_REQUEST_BOTH_EDGES' we'll get
evaluated to true even if only one event type was requested.
Fix it by checking both RISING & FALLING flags explicitly.
Cc: stable@vger.kernel.org
Fixes: 61f922db7221 ("gpio: userspace ABI for reading GPIO line events")
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
|
Pull drm fixes from Dave Airlie:
"This is the final set of fixes for -rc8, just a few i915 and one
vmwgfx ones.
I'm off on holidays for a week, so if anything shows up for fixes I've
asked Daniel or Sean Paul to herd it in the right direction"
[ The additional etnaviv fixes were already herded towards me as seen in
my previous pull - Linus ]
* 'drm-fixes' of git://people.freedesktop.org/~airlied/linux:
drm/vmwgfx: Free hash table allocated by cmdbuf managed res mgr
drm/i915: Disable EXEC_OBJECT_ASYNC when doing relocations
drm/i915: Hold struct_mutex for per-file stats in debugfs/i915_gem_object
drm/i915: Retire the VMA's fence tracker before unbinding
|
