* Re: [PATCH v4 0/9] driver core: Fix some race conditions
From: Rafael J. Wysocki @ 2026-04-04 17:11 UTC (permalink / raw)
To: Douglas Anderson
Cc: Greg Kroah-Hartman, Rafael J . Wysocki, Danilo Krummrich,
Alan Stern, Saravana Kannan, Christoph Hellwig, Eric Dumazet,
Johan Hovold, Leon Romanovsky, Alexander Lobakin,
Alexey Kardashevskiy, Robin Murphy, Andrew Morton, Frank.Li,
Jason Gunthorpe, alex, alexander.stein, andre.przywara, andrew,
andrew, andriy.shevchenko, aou, ardb, bhelgaas, brgl, broonie,
catalin.marinas, chleroy, davem, david, devicetree, dmaengine,
driver-core, gbatra, gregory.clement, hkallweit1, iommu,
jirislaby, joel, joro, kees, kevin.brodsky, kuba, lenb, lgirdwood,
linux-acpi, linux-arm-kernel, linux-aspeed, linux-cxl,
linux-kernel, linux-mips, linux-mm, linux-pci, linux-riscv,
linux-serial, linux-snps-arc, linux-usb, linux, linuxppc-dev,
m.szyprowski, maddy, mani, maz, miko.lenczewski, mpe, netdev,
npiggin, osalvador, oupton, pabeni, palmer, peter.ujfalusi,
peterz, pjw, robh, sebastian.hesselbarth, tglx, tsbogend, vgupta,
vkoul, will, willy, yangyicong, yeoreum.yun
In-Reply-To: <20260404000644.522677-1-dianders@chromium.org>
On Sat, Apr 4, 2026 at 2:07 AM Douglas Anderson <dianders@chromium.org> wrote:
>
> The main goal of this series is to fix the observed bug talked about
> in the first patch ("driver core: Don't let a device probe until it's
> ready"). That patch fixes a problem that has been observed in the real
> world and could land even if the rest of the patches are found
> unacceptable or need to be spun.
>
> That said, during patch review Danilo correctly pointed out that many
> of the bitfield accesses in "struct device" are unsafe. I added a
> bunch of patches in the series to address each one.
>
> Danilo said he's most worried about "can_match", so I put that one
> first. After that, I tried to transition bitfields to flags in reverse
> order to when the bitfield was added.
>
> Even if transitioning from bitfields to flags isn't truly needed for
> correctness, it seems silly (and wasteful of space in struct device)
> to have some in bitfields and some as flags. Thus I didn't spend time
> for each bitfield showing that it's truly needed for correctness.
>
> Transition was done semi manually. Presumably someone skilled at
> coccinelle could do a better job, but I just used sed in a heavy-
> handed manner and then reviewed/fixed the results, undoing anything my
> script got wrong. My terrible/ugly script was:
>
> var=can_match
> caps="${var^^}"
> for f in $(git grep -l "[>\.]${var}[^1-9_a-zA-Z\[]"); do
> echo $f
> sed -i~ -e "s/\([a-zA-Z_0-9\.>()-][a-zA-Z_0-9\.>()-]*\)->${var} = true/set_bit(DEV_FLAG_${caps}, \&\\1->flags)/" "$f"
> sed -i~ -e "s/\([a-zA-Z_0-9\.>()-][a-zA-Z_0-9\.>()-]*\)\.${var} = true/dev_set_${caps}(\&\\1)/" "$f"
> sed -i~ -e "s/\([a-zA-Z_0-9\.>()-][a-zA-Z_0-9\.>()-]*\)->${var} = false/clear_bit(DEV_FLAG_${caps}, \&\\1->flags)/" "$f"
> sed -i~ -e "s/\([a-zA-Z_0-9\.>()-][a-zA-Z_0-9\.>()-]*\)\.${var} = false/dev_clear_${caps}(\&\\1)/" "$f"
> sed -i~ -e "s/\([a-zA-Z_0-9\.>()-][a-zA-Z_0-9\.>()-]*\)->${var} = \([^;]*\)/assign_bit(DEV_FLAG_${caps}, \&\\1->flags, \\2)/" "$f"
> sed -i~ -e "s/\([a-zA-Z_0-9\.>()-][a-zA-Z_0-9\.>()-]*\)\.${var} = \([^;]*\)/dev_assign_${caps}(\&\\1, \\2)/" "$f"
> sed -i~ -e "s/\([a-zA-Z_0-9\.>()-][a-zA-Z_0-9\.>()-]*\)->${var}\([^1-9_a-zA-Z\[]\)/test_bit(DEV_FLAG_${caps}, \&\\1->flags)\\2/" "$f"
> sed -i~ -e "s/\([a-zA-Z_0-9\.>()-][a-zA-Z_0-9\.>()-]*\)\.${var}\([^1-9_a-zA-Z\[]\)/dev_${caps}(\&\\1)\\2/" "$f"
> done
>
> From v3 to v4, I transitioned to accessor functions with another ugly
> sed script. I had git format the old patches, then transformed them
> with:
>
> for f in *.patch; do
> echo $f
> sed -i~ -e "s/test_and_set_bit(DEV_FLAG_\([^,]*\), \&\(.*\)->flags)/dev_test_and_set_\\L\\1(\\2)/" "$f"
> sed -i~ -e "s/test_and_set_bit(DEV_FLAG_\([^,]*\), \(.*\)\.flags)/dev_test_and_set_\\L\\1(\\2)/" "$f"
> sed -i~ -e "s/test_bit(DEV_FLAG_\([^,]*\), \&\(.*\)->flags)/dev_\\L\\1(\\2)/" "$f"
> sed -i~ -e "s/test_bit(DEV_FLAG_\([^,]*\), \(.*\)\.flags)/dev_\\L\\1(\\2)/" "$f"
> sed -i~ -e "s/set_bit(DEV_FLAG_\([^,]*\), \&\(.*\)->flags)/dev_set_\\L\\1(\\2)/" "$f"
> sed -i~ -e "s/set_bit(DEV_FLAG_\([^,]*\), \(.*\)\.flags)/dev_set_\\L\\1(\\2)/" "$f"
> sed -i~ -e "s/clear_bit(DEV_FLAG_\([^,]*\), \&\(.*\)->flags)/dev_clear_\\L\\1(\\2)/" "$f"
> sed -i~ -e "s/clear_bit(DEV_FLAG_\([^,]*\), \(.*\)\.flags)/dev_clear_\\L\\1(\\2)/" "$f"
> sed -i~ -e "s/assign_bit(DEV_FLAG_\([^,]*\), \&\(.*\)->flags, \(.*\))/dev_assign_\\L\\1(\\2, \\3)/" "$f"
> sed -i~ -e "s/assign_bit(DEV_FLAG_\([^,]*\), \(.*\)\.flags, \(.*\))/dev_assign_\\L\\1(\\2, \\3)/" "$f"
> done
>
> ...and then did a few manual touchups for spacing.
>
> NOTE: one potentially "controversial" choice I made in some patches
> was to always reserve a flag ID even if a flag is only used under
> certain CONFIG_ settings. This is a change from how things were
> before. Keeping the numbering consistent and allowing easy
> compile-testing of both CONFIG settings seemed worth it, especially
> since it won't take up any extra space until we've added a lot more
> flags.
>
> I only marked the first patch as a "Fix" since it is the only one
> fixing observed problems. Other patches could be considered fixes too
> if folks want.
>
> I tested the first patch in the series backported to kernel 6.6 on the
> Pixel phone that was experiencing the race. I added extra printouts to
> make sure that the problem was hitting / addressed. The rest of the
> patches are tested with allmodconfig with arm32, arm64, ppc, and
> x86. I boot tested on an arm64 Chromebook running mainline.
>
> Changes in v4:
> - Use accessor functions for flags
>
> Changes in v3:
> - Use a new "flags" bitfield
> - Add missing \n in probe error message
>
> Changes in v2:
> - Instead of adjusting the ordering, use "ready_to_probe" flag
>
> Douglas Anderson (9):
> driver core: Don't let a device probe until it's ready
> driver core: Replace dev->can_match with dev_can_match()
> driver core: Replace dev->dma_iommu with dev_dma_iommu()
> driver core: Replace dev->dma_skip_sync with dev_dma_skip_sync()
> driver core: Replace dev->dma_ops_bypass with dev_dma_ops_bypass()
> driver core: Replace dev->state_synced with dev_state_synced()
> driver core: Replace dev->dma_coherent with dev_dma_coherent()
> driver core: Replace dev->of_node_reused with dev_of_node_reused()
> driver core: Replace dev->offline + ->offline_disabled with accessors
>
> arch/arc/mm/dma.c | 4 +-
> arch/arm/mach-highbank/highbank.c | 2 +-
> arch/arm/mach-mvebu/coherency.c | 2 +-
> arch/arm/mm/dma-mapping-nommu.c | 4 +-
> arch/arm/mm/dma-mapping.c | 28 ++--
> arch/arm64/kernel/cpufeature.c | 2 +-
> arch/arm64/mm/dma-mapping.c | 2 +-
> arch/mips/mm/dma-noncoherent.c | 2 +-
> arch/powerpc/kernel/dma-iommu.c | 8 +-
> .../platforms/pseries/hotplug-memory.c | 4 +-
> arch/riscv/mm/dma-noncoherent.c | 2 +-
> drivers/acpi/scan.c | 2 +-
> drivers/base/core.c | 53 +++++---
> drivers/base/cpu.c | 4 +-
> drivers/base/dd.c | 28 ++--
> drivers/base/memory.c | 2 +-
> drivers/base/pinctrl.c | 2 +-
> drivers/base/platform.c | 2 +-
> drivers/dma/ti/k3-udma-glue.c | 6 +-
> drivers/dma/ti/k3-udma.c | 6 +-
> drivers/iommu/dma-iommu.c | 9 +-
> drivers/iommu/iommu.c | 5 +-
> drivers/net/pcs/pcs-xpcs-plat.c | 2 +-
> drivers/of/device.c | 6 +-
> drivers/pci/of.c | 2 +-
> drivers/pci/pwrctrl/core.c | 2 +-
> drivers/regulator/bq257xx-regulator.c | 2 +-
> drivers/regulator/rk808-regulator.c | 2 +-
> drivers/tty/serial/serial_base_bus.c | 2 +-
> drivers/usb/gadget/udc/aspeed-vhub/dev.c | 2 +-
> include/linux/device.h | 120 ++++++++++++------
> include/linux/dma-map-ops.h | 6 +-
> include/linux/dma-mapping.h | 2 +-
> include/linux/iommu-dma.h | 3 +-
> kernel/cpu.c | 4 +-
> kernel/dma/mapping.c | 12 +-
> mm/hmm.c | 2 +-
> 37 files changed, 206 insertions(+), 142 deletions(-)
>
> --
For the whole set
Reviewed-by: Rafael J. Wysocki (Intel) <rafael@kernel.org>
^ permalink raw reply
* Re: Some queries on eHCI/xHCI/Thunderbolt and dwc2/dwc3
From: Alan Stern @ 2026-04-04 15:48 UTC (permalink / raw)
To: Ajay Garg; +Cc: linux-usb
In-Reply-To: <CAHP4M8XXQAsOzJFvCwXB=BPN4tdoh5wyn+ZFFmJZPZq5BorxOQ@mail.gmail.com>
On Sat, Apr 04, 2026 at 12:26:35PM +0530, Ajay Garg wrote:
> Hi everyone.
>
> I have been gaining an architectural understanding on how host/gadget
> usb-drivers inter-operate with USB-2 / USB-3 / USB-4 (host-side) and
> synopsys-DWC controllers (gadget-side).
>
> Following have been my understandings :
>
> a)
> For host-side, eHCI does not require / use dwc2, but xHCI mandatorily
> needs dwc3.
>
> Am I correct?
No.
EHCI (not "eHCI") is an architecture for a USB-2 host controller.
Several companies make controllers that are compatible with the EHCI
specification, but Synopsys's DesignWare dwc2 is not one of them.
Similarly, xHCI is an architecture for a USB-3 host controller. The
DesignWare dwc3 is such a controller, but there are others (such as
Intel's).
> If yes, how is hardware-specific actions taken care by eHCI alone
> (since eHCI is hardware-agnostic)?
Part of the EHCI specification says how the host controller should
interact with the PCI bus. Most EHCI implementations use PCI, but not
all. For those that don't, the ehci-hcd driver has platform-specific
submodules.
> Is it that USB-2 PHY-registers are already a part of eHCI
> MMIO-registers themselves (thus not requiring any hardware-specific
> actions on the PHY side)?
More or less. The PHY functionality is part of EHCI, but its registers
don't correspond very well to those of standalone PHYs.
> b)
> For host-side, does thunderbolt driver require any of dwc3 / upcoming-dwc4?
I don't know anything about thunderbolt, USB-4, or dwc4.
> c)
> For gadget-side, dwc2 and dwc3 are enough for USB-2 / USB-3.
> Am I correct?
Yes, as far as I know. But of course there are alternatives.
Alan Stern
> d)
> For gadget-side, would USB-4 require an upcoming-dwc4? Or will dwc3 be
> modified? Or is there another plan in the pipeline?
>
>
> Will be grateful for light on the above from kernel/synopsys experts :)
> Many thanks in advance !
>
> Thanks and Regards,
> Ajay
^ permalink raw reply
* [Bug 221319] Certain operations via PCIe tunneling between an AMD USB4 host and a Thunderbolt-5 peripherals cause an instant reboot
From: bugzilla-daemon @ 2026-04-04 15:25 UTC (permalink / raw)
To: linux-usb
In-Reply-To: <bug-221319-208809@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=221319
--- Comment #1 from Morgwai Kotarbinski (foss@morgwai.pl) ---
Created attachment 309814
--> https://bugzilla.kernel.org/attachment.cgi?id=309814&action=edit
dmesg log when using NV driver v595
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply
* [Bug 221319] New: Certain operations via PCIe tunneling between an AMD USB4 host and a Thunderbolt-5 peripherals cause an instant reboot
From: bugzilla-daemon @ 2026-04-04 15:24 UTC (permalink / raw)
To: linux-usb
https://bugzilla.kernel.org/show_bug.cgi?id=221319
Bug ID: 221319
Summary: Certain operations via PCIe tunneling between an AMD
USB4 host and a Thunderbolt-5 peripherals cause an
instant reboot
Product: Drivers
Version: 2.5
Hardware: AMD
OS: Linux
Status: NEW
Severity: normal
Priority: P3
Component: USB
Assignee: drivers_usb@kernel-bugs.kernel.org
Reporter: foss@morgwai.pl
Regression: No
Created attachment 309813
--> https://bugzilla.kernel.org/attachment.cgi?id=309813&action=edit
dmesg log when using Nouveau driver
I have an AMD Strix laptop (TUXEDO IBP-14 gen10, HX370 APU) and an RTX 3090
that I’ve been successfully connecting using various eGPU adapters:
- ADT-Link UT4G (USB4v1, ASM2464PDX),
- Minisforum DEG1 (OCuLink 4i),
- even daisy-chaining two 3090s via EXP-GDC TH3P4G3 (TB3, JHL7440) + UT4G
...and it has all been working perfectly stable on my Debian-13 system across
several kernel versions (6.16.1 - 7.0~rc6) using both Nouveau and NV
proprietary drivers.
Recently I’ve purchased a new TB5 adapter: Minisforum DEG2: it is quite new,
but a few reviews it received from Windows users praised it for perfect
stability and flawless work.
However when I connected my 3090 via my new DEG2 to my laptop, it abruptly
rebooted about 0.5-1 second after the driver was loaded. I’ve tried several
driver versions across different distros (live Fedora-43+Nouveau, live
POP_OS-24.04+v580, Debian-13+{Nouveau,v580,v590,v595} with kernels 6.18.x,6.19x
distro-provided and self-compiled 7.0~rc6), but the result was always the same.
I also subjected myself to some Windows-11 usage and confirmed that my DEG2
works perfectly stable there with NV's Studio Driver v591.74.
Given all above, it seems that the problem is related to TB5 handling by the
kernel.
After some hair-pulling and extensive testing, I’ve managed to notice, that the
operation that causes the reboots is somehow related to GSP firmware: I’ve
verified that the following configurations allow the eGPU to work somewhat
stable:
- Nouveau driver without `firmware-nvidia-graphics` package (containing GSP
v570.144)
- NV's proprietary flavor driver (package `cuda-drivers` from their repo)
v580, v590 and v595 with `options nvidia NVreg_EnableGpuFirmware=0` (NV's
"open" flavor cannot function without GSP firmware and ignore this option)
Also redirecting the 3090 to a VM via VFIO and loading the firmware inside a VM
causes the whole laptop to reboot (with either Nouveau or v580 or v590
installed in the VM).
Redirecting the 3090 to a VM with v595 installed, causes a reboot of the laptop
even without loading the firmware (ie even with having `options nvidia
NVreg_EnableGpuFirmware=0` inside the VM).
Note: there were also numerous reports on egpu.io forum of vast instability
from Intel host + TB5 adapter + Linux users to the point of being completely
unusable, though without reboots. A few of such users that were using Nvidia
GPUs reported that avoid GSP firmware also mitigated the problem.
Attached are `dmesg` logs from Debian-13 with self compiled kernel 7.0~rc6
under the following scenarios:
dmesg-deg2-x4sp4nal-debian13-linux7.0rc6-nouveau.log:
1. initially package `firmware-nvidia-graphics` containing the GSP firmware is
not installed.
2. eGPU is connected and is properly detected by Nouveau, nothing bad happens.
3. Nouveau is unloaded and eGPU is disconnected.
4. `firmware-nvidia-graphics` is installed.
5. eGPU is connected and reboot occurs about 0.5-1 second after loading the
firmware.
dmesg-deg2-x4sp4nal-debian13-linux7.0rc6-nv595: (to be posted in the next
comment)
1. initially cuda-drivers v595 is installed and
`/etc/modprobe.d/nvidia-nogsp.conf` file contains `options nvidia
NVreg_EnableGpuFirmware=0`.
2. eGPU is connected and is properly detected by the NV driver, nothing bad
happens.
3. all NV modules are unloaded and eGPU is disconnected.
4. `NVreg_EnableGpuFirmware` is changed to `1`.
5. eGPU is connected and reboot occurs about 0.5-1 second after loading the
driver.
Related links:
Corresponding egpu.io thread:
https://egpu.io/forums/wip-builds/wip-2025-14-tuxedo-infinitybook-pro-14-gen10-890m-rai312chx-rtx-3090-64gbps-usb4v1-minisforum-deg2-linux-debian-trixie-loading-nvidia-firmware-reboots-the-machine/
Windows build on egpu.io:
https://egpu.io/forums/builds/2025-14-tuxedo-infinitybook-pro-14-gen10-890m-rai312chx-rtx-3090-64gbps-usb4v1tb5-minisforum-deg2-win11-25h2-daisy-chained-rtx-3090-via-ut4g/
Nvidia Linux forum posting:
https://forums.developer.nvidia.com/t/loading-gsp-firmware-from-an-amd-strix-laptop-to-a-tb5-3090-egpu-causes-instant-reboot/360903
Sometimes a split second before a reboot, there are some error messages from
`amdgpu`, so I also posted to their bug tracker, but it seems `amdgpu` is
rather a victim, not a cause:
https://gitlab.freedesktop.org/drm/amd/-/work_items/4981
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply
* Re: [PATCH net-next v6 0/2] r8152: Add support for the RTL8157 5Gbit USB Ethernet chip
From: Andrew Lunn @ 2026-04-04 15:11 UTC (permalink / raw)
To: Birger Koblitz
Cc: Greg KH, Jakub Kicinski, Andrew Lunn, David S. Miller,
Eric Dumazet, Paolo Abeni, linux-usb, netdev, linux-kernel,
Chih Kai Hsu
In-Reply-To: <23860a3b-5c89-42d8-bf7f-2f77f35cf14a@birger-koblitz.de>
> Thanks for the feedback, Greg!
> the underlying issue is that parts of the patch I submitted are now also
> submitted by others, and that gets fast-tracked. This has now happened twice,
> and I am being told every time to re-submit, without efforts to coordinate
> this, or hints that this pattern may stop. This has somewhat made me loose
> trust in the process.
It is somewhat on you to coordinate with others working on the same
driver.
As is often said, Maintainers are overloaded, and push whatever they
can onto developers. It should not need a Maintainer to get developers
to coordinate, they should be able to do that on there own. Since you
are subscribed to the netdev list, you can see the patches flying by,
you know who else is working on this driver. Please go talk to them.
Andrew
^ permalink raw reply
* Re: xhci_hcd: AMD Raphael/Granite Ridge USB 2.0 xHCI [1022:15b8] dies on resume from suspend
From: Michal Pecio @ 2026-04-04 13:24 UTC (permalink / raw)
To: Martin Alderson; +Cc: linux-usb
In-Reply-To: <CA+_z3hRTD-QAgv3jZhOZUUPA0sNZ8946jfYwYsZ=RnQJ0LG7cw@mail.gmail.com>
On Sat, 4 Apr 2026 13:04:02 +0100, Martin Alderson wrote:
> Just for clarity this never happened to me with the 6.19 kernel I was
> on before (suspend/resumed many times on that kernel with no issues).
> It's happened twice now (once with rc5, now with rc6) in a short space
> of time.
So apparently about once per week. That's not very easy to debug.
One trick I have seen people use to accelerate such tests is running
"rtcwake -s 5 -m freeze" in a loop. This puts the system in s2idle and
resumes automatically after 5 seconds.
Do you have more complete dmesg from those failures with timestamps?
From suspend up to until everything has calmed down after resume, or
also including whatever you have done later to restore operation.
> Previously I was on the Fedora 43 default kernel series, now I
> switched to the COPR for 7.x (to try and fix something else).
Not sure what COPR is, but I gather it went like this:
1. Fedora 6.19 kernel was OK for a long time
2. Some other kernel, possibly other config, 7.0-rc4 still worked, but
only used for a short time. What about 7.0-rc1 to -rc3?
3. After updating to -rc5 it's definitely broken.
> Thanks for the bugzilla, I'll look at some of those workarounds.
Particularly, collecting dynamic debug and debugfs could tell if it's
the same problem with missing IRQ after resume or something else.
Regards,
Michal
^ permalink raw reply
* Re: xhci_hcd: AMD Raphael/Granite Ridge USB 2.0 xHCI [1022:15b8] dies on resume from suspend
From: Martin Alderson @ 2026-04-04 12:04 UTC (permalink / raw)
To: Michal Pecio; +Cc: linux-usb
In-Reply-To: <20260330020749.18fbe433.michal.pecio@gmail.com>
Hi,
Just for clarity this never happened to me with the 6.19 kernel I was
on before (suspend/resumed many times on that kernel with no issues).
It's happened twice now (once with rc5, now with rc6) in a short space
of time. It may just be random luck though than a specific regression
- sorry if I confused things there.
Not sure I'm able to do a bisect because it's very intermittent so
would take an age to reproduce it sorry.
Previously I was on the Fedora 43 default kernel series, now I
switched to the COPR for 7.x (to try and fix something else).
Thanks for the bugzilla, I'll look at some of those workarounds.
On Mon, Mar 30, 2026 at 1:07 AM Michal Pecio <michal.pecio@gmail.com> wrote:
>
> On Sun, 29 Mar 2026 17:52:39 -0400, martinalderson@gmail.com wrote:
> > [BUG] xhci_hcd 0000:0f:00.0: controller declared dead on resume from
> > suspend
> >
> > Hardware:
> > CPU: AMD Ryzen 9 7900 12-Core Processor
> > Board: ASUS PRIME B650-PLUS
> > Controller: AMD Raphael/Granite Ridge USB 2.0 xHCI [1022:15b8]
> > Subsystem: ASUSTeK Computer Inc. [1043:8877]
> > PCI: 0000:0f:00.0 (IOMMU group 30)
> >
> > Software:
> > Kernel: 7.0.0-rc5 (commit be762d8b, built 2026-03-28)
> > Distro: Fedora 43 (Workstation)
> > Desktop: GNOME on Wayland
> >
> > Description:
> > On the first suspend/resume cycle after boot, the xHCI controller at
> > 0000:0f:00.0 (AMD Raphael/Granite Ridge USB 2.0) fails to resume and
> > is declared dead. A Logitech Unifying Receiver (046d:c52b) on this
> > controller is disconnected and the mouse (Logitech M720 Triathlon)
> > stops functioning.
> >
> > A second xHCI controller on the same system (0000:0c:00.0, AMD 600
> > Series Chipset USB 3.2 [1022:43f7]) also errors on resume (USBSTS
> > 0x401) but successfully recovers via reinit. The 0f:00.0 controller
> > does not recover.
> >
> > Regression from rc4: suspend/resume worked correctly on 7.0-rc4 and
> > earlier kernels on the same hardware.
>
> That's interesting because there were no USB subsystem changes
> between 7.0-rc4 and 7.0-rc5.
>
> Any chance you could git-bisect this?
> Are both kernels built with the same .config?
>
> > Reproduce:
> > 1. Boot with USB device attached to a port on the 0000:0f:00.0
> > controller
> > 2. Suspend (systemd suspend)
> > 3. Resume
>
> By the way, are you using this affected controller to resume
> (with a keyboard or something like that)?
>
> > dmesg on resume:
> > xhci_hcd 0000:0f:00.0: xHCI host not responding to stop endpoint command
> > xhci_hcd 0000:0f:00.0: xHCI host controller not responding, assume dead
> > xhci_hcd 0000:0f:00.0: HC died; cleaning up
> > xhci_hcd 0000:0c:00.0: xHC error in resume, USBSTS 0x401, Reinit
> > usb usb1: root hub lost power or was reset
> > usb usb2: root hub lost power or was reset
> > usb 1-7: WARN: invalid context state for evaluate context command.
> > usb 1-10: WARN: invalid context state for evaluate context command.
> > usb 7-1: USB disconnect, device number 2
> >
> > Workaround:
> > PCI remove + rescan recovers the controller:
> > echo 1 > /sys/bus/pci/devices/0000:0f:00.0/remove
> > echo 1 > /sys/bus/pci/rescan
> >
> > A simple PCI device reset (echo 1 > .../reset) was insufficient -- the
> > controller came back but did not re-enumerate the attached device.
>
> What about the unbind/bind procedure described here?
> https://bugzilla.kernel.org/show_bug.cgi?id=221073
>
> > Notes:
> > - The 0f:00.0 controller is USB 2.0 only (USB3 root hub has no ports)
> > - hci version 0x120, hcc params 0x0110ffc5, quirks 0x0000000200000010
^ permalink raw reply
* [Bug 221318] mice behind ASMedia ASM1042A via Thunderbolt 2 never produce input, most likely due to interrupt pipe idle window during enumeration
From: bugzilla-daemon @ 2026-04-04 9:54 UTC (permalink / raw)
To: linux-usb
In-Reply-To: <bug-221318-208809@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=221318
Michał Pecio (michal.pecio@gmail.com) changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |michal.pecio@gmail.com
--- Comment #1 from Michał Pecio (michal.pecio@gmail.com) ---
ASM1042A is a host controller, not a hub, but there is likely a hub between
ASM1042A and the USB ports on the monitor. Maybe the same hub which shows up
when the monitor is plugged into USB instead of Thunderbolt.
Could you post "lsusb -tv" for both connection variants with the same mouse in
the same monitor port?
Maybe see if dynamic debug spits out something useful:
echo 'module xhci_hcd +p' >/proc/dynamic_debug/control
dmesg -W >log.txt
Then connect the mouse with your udev rule, make a few clicks, disconnect,
remove the udev rule, connect again, make a few clicks. Attach the resulting
log.
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply
* [PATCH net-next v7 2/2] r8152: Add support for the RTL8157 hardware
From: Birger Koblitz @ 2026-04-04 7:57 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni
Cc: linux-usb, netdev, linux-kernel, Chih Kai Hsu, Birger Koblitz
In-Reply-To: <20260404-rtl8157_next-v7-0-039121318f23@birger-koblitz.de>
The RTL8157 uses a different packet descriptor format compared to the
previous generation of chips. Add support for this format by adding a
descriptor format structure into the r8152 structure and corresponding
desc_ops functions which abstract the vlan-tag, tx/rx len and
tx/rx checksum algorithms.
Also, add support for the ADV indirect access interface of the RTL8157
and PHY setup.
For initialization of the RTL8157, combine the existing RTL8156B and
RTL8156 init functions and add RTL8157-specific functinality in order
to improve code readability and maintainability.
r8156_init() is now called with RTL_VER_10 and RTL_VER_11 for the RTL8156,
with RTL_VER_12, RTL_VER_13 and RTL_VER_15 for the RTL8156B and with
RTL_VER_16 for the RTL8157 and checks the version for chip-specific code.
Also add USB power control functions for the RTL8157.
Add support for the USB device ID of Realtek RTL8157-based adapters. Detect
the RTL8157 as RTL_VER_16 and set it up.
Signed-off-by: Birger Koblitz <mail@birger-koblitz.de>
---
drivers/net/usb/r8152.c | 913 ++++++++++++++++++++++++++++++++++++++----------
1 file changed, 729 insertions(+), 184 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index c81bb788ac3424bd22108e83a20ff51e21c23f60..7337bf1b7d6ad03572edbc492706c07a8f58760f 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -123,6 +123,7 @@
#define USB_CSR_DUMMY1 0xb464
#define USB_CSR_DUMMY2 0xb466
#define USB_DEV_STAT 0xb808
+#define USB_U2P3_V2_CTRL 0xc2c0
#define USB_CONNECT_TIMER 0xcbf8
#define USB_MSC_TIMER 0xcbfc
#define USB_BURST_SIZE 0xcfc0
@@ -156,6 +157,9 @@
#define USB_U1U2_TIMER 0xd4da
#define USB_FW_TASK 0xd4e8 /* RTL8153B */
#define USB_RX_AGGR_NUM 0xd4ee
+#define USB_ADV_ADDR 0xd5d6
+#define USB_ADV_DATA 0xd5d8
+#define USB_ADV_CMD 0xd5dc
#define USB_UPS_CTRL 0xd800
#define USB_POWER_CUT 0xd80a
#define USB_MISC_0 0xd81a
@@ -492,6 +496,12 @@
/* USB_RX_AGGR_NUM */
#define RX_AGGR_NUM_MASK 0x1ff
+/* USB_ADV_CMD */
+#define ADV_CMD_BMU 0
+#define ADV_CMD_BUSY BIT(0)
+#define ADV_CMD_WR BIT(1)
+#define ADV_CMD_IP BIT(2)
+
/* USB_UPS_CTRL */
#define POWER_CUT 0x0100
@@ -531,11 +541,15 @@
#define CDC_ECM_EN BIT(3)
#define RX_AGG_DISABLE 0x0010
#define RX_ZERO_EN 0x0080
+#define RX_DESC_16B 0x0400
/* USB_U2P3_CTRL */
#define U2P3_ENABLE 0x0001
#define RX_DETECT8 BIT(3)
+/* USB_U2P3_V2_CTRL */
+#define U2P3_V2_ENABLE BIT(29)
+
/* USB_POWER_CUT */
#define PWR_EN 0x0001
#define PHASE2_EN 0x0008
@@ -748,8 +762,6 @@ enum rtl_register_content {
#define RTL8152_MAX_TX 4
#define RTL8152_MAX_RX 10
#define INTBUFSIZE 2
-#define TX_ALIGN 4
-#define RX_ALIGN 8
#define RTL8152_RX_MAX_PENDING 4096
#define RTL8152_RXFG_HEADSZ 256
@@ -761,7 +773,6 @@ enum rtl_register_content {
#define RTL8152_TX_TIMEOUT (5 * HZ)
#define mtu_to_size(m) ((m) + VLAN_ETH_HLEN + ETH_FCS_LEN)
#define size_to_mtu(s) ((s) - VLAN_ETH_HLEN - ETH_FCS_LEN)
-#define rx_reserved_size(x) (mtu_to_size(x) + sizeof(struct rx_desc) + RX_ALIGN)
/* rtl8152 flags */
enum rtl8152_flags {
@@ -846,6 +857,40 @@ struct tx_desc {
#define TX_VLAN_TAG BIT(16)
};
+struct rx_desc_v2 {
+ __le32 opts1;
+#define RX_LEN_MASK_2 0xfffe0000
+#define rx_v2_get_len(x) (((x) & RX_LEN_MASK_2) >> 17)
+#define RX_VLAN_TAG_2 BIT(3)
+#define RX_VER_MASK 0x3
+
+ __le32 opts2;
+
+ __le32 opts3;
+#define IPF_2 BIT(26) /* IP checksum fail */
+#define UDPF_2 BIT(25) /* UDP checksum fail */
+#define TCPF_2 BIT(24) /* TCP checksum fail */
+#define RD_IPV6_CS_2 BIT(15)
+#define RD_IPV4_CS_2 BIT(14)
+#define RD_UDP_CS_2 BIT(11)
+#define RD_TCP_CS_2 BIT(10)
+
+ __le32 opts4;
+};
+
+struct tx_desc_v2 {
+ __le32 opts1;
+
+ __le32 opts2;
+#define TCPHO_MAX_2 0x3ffU
+
+ __le32 opts3;
+#define tx_v2_set_len(x) ((x) << 4)
+
+ __le32 opts4;
+#define TX_SIG (0x15 << 27)
+};
+
struct r8152;
struct rx_agg {
@@ -919,6 +964,19 @@ struct r8152 {
u32 ctap_short_off:1;
} ups_info;
+ struct desc_info {
+ void (*vlan_tag)(void *desc, struct sk_buff *skb);
+ u8 align;
+ u8 size;
+ } rx_desc, tx_desc;
+
+ struct desc_ops {
+ void (*tx_len)(struct r8152 *tp, void *desc, u32 len);
+ u32 (*rx_len)(struct r8152 *tp, void *desc);
+ u8 (*rx_csum)(struct r8152 *tp, void *desc);
+ int (*tx_csum)(struct r8152 *tp, void *desc, struct sk_buff *skb, u32 len);
+ } desc_ops;
+
#define RTL_VER_SIZE 32
struct rtl_fw {
@@ -1183,6 +1241,7 @@ enum rtl_version {
RTL_VER_13,
RTL_VER_14,
RTL_VER_15,
+ RTL_VER_16,
RTL_VER_MAX
};
@@ -1208,7 +1267,7 @@ enum tx_csum_stat {
static const int multicast_filter_limit = 32;
static unsigned int agg_buf_sz = 16384;
-#define RTL_LIMITED_TSO_SIZE (size_to_mtu(agg_buf_sz) - sizeof(struct tx_desc))
+#define RTL_LIMITED_TSO_SIZE (size_to_mtu(agg_buf_sz) - tp->tx_desc.size)
/* If register access fails then we block access and issue a reset. If this
* happens too many times in a row without a successful access then we stop
@@ -1619,6 +1678,122 @@ static inline int r8152_mdio_read(struct r8152 *tp, u32 reg_addr)
return ocp_reg_read(tp, OCP_BASE_MII + reg_addr * 2);
}
+static int wait_cmd_ready(struct r8152 *tp, u16 cmd)
+{
+ return poll_timeout_us(u16 ocp_data = ocp_read_word(tp, MCU_TYPE_USB, cmd),
+ !(ocp_data & ADV_CMD_BUSY), 2000, 20000, false);
+}
+
+static int ocp_adv_read(struct r8152 *tp, u16 cmd, u16 addr, u32 *data)
+{
+ int ret;
+
+ ret = wait_cmd_ready(tp, USB_ADV_CMD);
+ if (ret < 0)
+ goto out;
+
+ ocp_write_word(tp, MCU_TYPE_USB, USB_ADV_ADDR, addr);
+
+ cmd |= ADV_CMD_BUSY;
+ ocp_write_word(tp, MCU_TYPE_USB, USB_ADV_CMD, cmd);
+
+ ret = wait_cmd_ready(tp, USB_ADV_CMD);
+ if (ret < 0)
+ goto out;
+
+ *data = ocp_read_dword(tp, MCU_TYPE_USB, USB_ADV_DATA);
+
+out:
+ return ret;
+}
+
+static int ocp_adv_write(struct r8152 *tp, u16 cmd, u16 addr, u32 data)
+{
+ int ret;
+
+ ret = wait_cmd_ready(tp, USB_ADV_CMD);
+ if (ret < 0)
+ goto out;
+
+ cmd |= ADV_CMD_WR;
+ ocp_write_dword(tp, MCU_TYPE_USB, USB_ADV_DATA, data);
+
+ ocp_write_word(tp, MCU_TYPE_USB, USB_ADV_ADDR, addr);
+
+ cmd |= ADV_CMD_BUSY;
+ ocp_write_word(tp, MCU_TYPE_USB, USB_ADV_CMD, cmd);
+
+out:
+ return ret;
+}
+
+static int rtl_bmu_read(struct r8152 *tp, u16 addr, u32 *data)
+{
+ return ocp_adv_read(tp, ADV_CMD_BMU, addr, data);
+}
+
+static int rtl_bmu_write(struct r8152 *tp, u16 addr, u32 data)
+{
+ return ocp_adv_write(tp, ADV_CMD_BMU, addr, data);
+}
+
+static int rtl_bmu_w0w1(struct r8152 *tp, u16 addr, u32 clear, u32 set)
+{
+ u32 bmu;
+ int ret;
+
+ ret = rtl_bmu_read(tp, addr, &bmu);
+ if (ret < 0)
+ goto out;
+
+ bmu = (bmu & ~clear) | set;
+ ret = rtl_bmu_write(tp, addr, bmu);
+
+out:
+ return ret;
+}
+
+static int rtl_bmu_clr_bits(struct r8152 *tp, u16 addr, u32 clear)
+{
+ return rtl_bmu_w0w1(tp, addr, clear, 0);
+}
+
+static int rtl_ip_read(struct r8152 *tp, u16 addr, u32 *data)
+{
+ return ocp_adv_read(tp, ADV_CMD_IP, addr, data);
+}
+
+static int rtl_ip_write(struct r8152 *tp, u16 addr, u32 data)
+{
+ return ocp_adv_write(tp, ADV_CMD_IP, addr, data);
+}
+
+static int rtl_ip_w0w1(struct r8152 *tp, u16 addr, u32 clear, u32 set)
+{
+ int ret;
+ u32 ip;
+
+ ret = rtl_ip_read(tp, addr, &ip);
+ if (ret < 0)
+ goto out;
+
+ ip = (ip & ~clear) | set;
+ ret = rtl_ip_write(tp, addr, ip);
+
+out:
+ return ret;
+}
+
+static int rtl_ip_clr_bits(struct r8152 *tp, u16 addr, u32 clear)
+{
+ return rtl_ip_w0w1(tp, addr, clear, 0);
+}
+
+static int rtl_ip_set_bits(struct r8152 *tp, u16 addr, u32 set)
+{
+ return rtl_ip_w0w1(tp, addr, 0, set);
+}
+
static void sram_write(struct r8152 *tp, u16 addr, u16 data)
{
ocp_reg_write(tp, OCP_SRAM_ADDR, addr);
@@ -2182,14 +2357,14 @@ static void intr_callback(struct urb *urb)
}
}
-static inline void *rx_agg_align(void *data)
+static void *rx_agg_align(struct r8152 *tp, void *data)
{
- return (void *)ALIGN((uintptr_t)data, RX_ALIGN);
+ return (void *)ALIGN((uintptr_t)data, tp->rx_desc.align);
}
-static inline void *tx_agg_align(void *data)
+static void *tx_agg_align(struct r8152 *tp, void *data)
{
- return (void *)ALIGN((uintptr_t)data, TX_ALIGN);
+ return (void *)ALIGN((uintptr_t)data, tp->tx_desc.align);
}
static void free_rx_agg(struct r8152 *tp, struct rx_agg *agg)
@@ -2307,9 +2482,9 @@ static int alloc_all_mem(struct r8152 *tp)
if (!buf)
goto err1;
- if (buf != tx_agg_align(buf)) {
+ if (buf != tx_agg_align(tp, buf)) {
kfree(buf);
- buf = kmalloc_node(agg_buf_sz + TX_ALIGN, GFP_KERNEL,
+ buf = kmalloc_node(agg_buf_sz + tp->tx_desc.align, GFP_KERNEL,
node);
if (!buf)
goto err1;
@@ -2325,7 +2500,7 @@ static int alloc_all_mem(struct r8152 *tp)
tp->tx_info[i].context = tp;
tp->tx_info[i].urb = urb;
tp->tx_info[i].buffer = buf;
- tp->tx_info[i].head = tx_agg_align(buf);
+ tp->tx_info[i].head = tx_agg_align(tp, buf);
list_add_tail(&tp->tx_info[i].list, &tp->tx_free);
}
@@ -2412,8 +2587,17 @@ static void r8152_csum_workaround(struct r8152 *tp, struct sk_buff *skb,
}
}
-static inline void rtl_tx_vlan_tag(struct tx_desc *desc, struct sk_buff *skb)
+static void r8152_tx_len(struct r8152 *tp, void *tx_desc, u32 len)
+{
+ struct tx_desc *desc = tx_desc;
+
+ desc->opts1 |= cpu_to_le32(len);
+}
+
+static void r8152_tx_vlan_tag(void *d, struct sk_buff *skb)
{
+ struct tx_desc *desc = d;
+
if (skb_vlan_tag_present(skb)) {
u32 opts2;
@@ -2422,8 +2606,10 @@ static inline void rtl_tx_vlan_tag(struct tx_desc *desc, struct sk_buff *skb)
}
}
-static inline void rtl_rx_vlan_tag(struct rx_desc *desc, struct sk_buff *skb)
+static void r8152_rx_vlan_tag(void *d, struct sk_buff *skb)
{
+ struct rx_desc *desc = d;
+
u32 opts2 = le32_to_cpu(desc->opts2);
if (opts2 & RX_VLAN_TAG)
@@ -2431,10 +2617,11 @@ static inline void rtl_rx_vlan_tag(struct rx_desc *desc, struct sk_buff *skb)
swab16(opts2 & 0xffff));
}
-static int r8152_tx_csum(struct r8152 *tp, struct tx_desc *desc,
+static int r8152_tx_csum(struct r8152 *tp, void *d,
struct sk_buff *skb, u32 len)
{
u32 mss = skb_shinfo(skb)->gso_size;
+ struct tx_desc *desc = d;
u32 opts1, opts2 = 0;
int ret = TX_CSUM_SUCCESS;
@@ -2519,6 +2706,74 @@ static int r8152_tx_csum(struct r8152 *tp, struct tx_desc *desc,
return ret;
}
+static u32 r8152_rx_len(struct r8152 *tp, void *d)
+{
+ struct rx_desc *desc = d;
+
+ return le32_to_cpu(desc->opts1) & RX_LEN_MASK;
+}
+
+static u32 r8157_rx_len(struct r8152 *tp, void *d)
+{
+ struct rx_desc_v2 *desc = d;
+
+ return rx_v2_get_len(le32_to_cpu(desc->opts1));
+}
+
+static void r8157_rx_vlan_tag(void *desc, struct sk_buff *skb)
+{
+ struct rx_desc_v2 *d = desc;
+ u32 opts1;
+
+ opts1 = le32_to_cpu(d->opts1);
+ if (opts1 & RX_VLAN_TAG_2) {
+ u32 opts2 = le32_to_cpu(d->opts2);
+
+ __vlan_hwaccel_put_tag(skb, htons(ETH_P_8021Q),
+ swab16((opts2 >> 16) & 0xffff));
+ }
+}
+
+static int r8157_tx_csum(struct r8152 *tp, void *tx_desc, struct sk_buff *skb, u32 len)
+{
+ u32 mss = skb_shinfo(skb)->gso_size;
+
+ if (!mss && skb->ip_summed == CHECKSUM_PARTIAL) {
+ u32 transport_offset = (u32)skb_transport_offset(skb);
+
+ if (transport_offset > TCPHO_MAX_2) {
+ netif_warn(tp, tx_err, tp->netdev,
+ "Invalid transport offset 0x%x\n",
+ transport_offset);
+ return TX_CSUM_NONE;
+ }
+ }
+
+ return r8152_tx_csum(tp, tx_desc, skb, len);
+}
+
+static void r8157_tx_len(struct r8152 *tp, void *tx_desc, u32 len)
+{
+ struct tx_desc_v2 *desc = tx_desc;
+
+ desc->opts3 = cpu_to_le32(tx_v2_set_len(len));
+ desc->opts4 = cpu_to_le32(TX_SIG);
+}
+
+static int rtl_tx_csum(struct r8152 *tp, void *desc, struct sk_buff *skb,
+ u32 len)
+{
+ int ret = TX_CSUM_SUCCESS;
+
+ WARN_ON_ONCE(len > TX_LEN_MAX);
+
+ ret = tp->desc_ops.tx_csum(tp, desc, skb, len);
+ if (!ret)
+ tp->desc_ops.tx_len(tp, desc, len);
+
+ return ret;
+}
+
static int r8152_tx_agg_fill(struct r8152 *tp, struct tx_agg *agg)
{
struct sk_buff_head skb_head, *tx_queue = &tp->tx_queue;
@@ -2535,33 +2790,33 @@ static int r8152_tx_agg_fill(struct r8152 *tp, struct tx_agg *agg)
agg->skb_len = 0;
remain = agg_buf_sz;
- while (remain >= ETH_ZLEN + sizeof(struct tx_desc)) {
- struct tx_desc *tx_desc;
+ while (remain >= ETH_ZLEN + tp->tx_desc.size) {
struct sk_buff *skb;
unsigned int len;
+ void *tx_desc;
skb = __skb_dequeue(&skb_head);
if (!skb)
break;
- len = skb->len + sizeof(*tx_desc);
+ len = skb->len + tp->tx_desc.size;
if (len > remain) {
__skb_queue_head(&skb_head, skb);
break;
}
- tx_data = tx_agg_align(tx_data);
- tx_desc = (struct tx_desc *)tx_data;
+ tx_data = tx_agg_align(tp, tx_data);
+ tx_desc = (void *)tx_data;
- if (r8152_tx_csum(tp, tx_desc, skb, skb->len)) {
+ if (rtl_tx_csum(tp, tx_desc, skb, skb->len)) {
r8152_csum_workaround(tp, skb, &skb_head);
continue;
}
- rtl_tx_vlan_tag(tx_desc, skb);
+ tp->tx_desc.vlan_tag(tx_desc, skb);
- tx_data += sizeof(*tx_desc);
+ tx_data += tp->tx_desc.size;
len = skb->len;
if (skb_copy_bits(skb, 0, tx_data, len) < 0) {
@@ -2569,7 +2824,7 @@ static int r8152_tx_agg_fill(struct r8152 *tp, struct tx_agg *agg)
stats->tx_dropped++;
dev_kfree_skb_any(skb);
- tx_data -= sizeof(*tx_desc);
+ tx_data -= tp->tx_desc.size;
continue;
}
@@ -2579,7 +2834,7 @@ static int r8152_tx_agg_fill(struct r8152 *tp, struct tx_agg *agg)
dev_kfree_skb_any(skb);
- remain = agg_buf_sz - (int)(tx_agg_align(tx_data) - agg->head);
+ remain = agg_buf_sz - (int)(tx_agg_align(tp, tx_data) - agg->head);
if (tp->dell_tb_rx_agg_bug)
break;
@@ -2617,8 +2872,9 @@ static int r8152_tx_agg_fill(struct r8152 *tp, struct tx_agg *agg)
return ret;
}
-static u8 r8152_rx_csum(struct r8152 *tp, struct rx_desc *rx_desc)
+static u8 r8152_rx_csum(struct r8152 *tp, void *d)
{
+ struct rx_desc *rx_desc = d;
u8 checksum = CHECKSUM_NONE;
u32 opts2, opts3;
@@ -2646,6 +2902,30 @@ static u8 r8152_rx_csum(struct r8152 *tp, struct rx_desc *rx_desc)
return checksum;
}
+static u8 r8157_rx_csum(struct r8152 *tp, void *desc)
+{
+ struct rx_desc_v2 *d = desc;
+ u8 checksum = CHECKSUM_NONE;
+ u32 opts3;
+
+ if (!(tp->netdev->features & NETIF_F_RXCSUM))
+ goto return_result;
+
+ opts3 = le32_to_cpu(d->opts3);
+
+ if ((opts3 & (RD_IPV4_CS_2 | IPF_2)) == (RD_IPV4_CS_2 | IPF_2)) {
+ checksum = CHECKSUM_NONE;
+ } else if (opts3 & (RD_IPV4_CS_2 | RD_IPV6_CS_2)) {
+ if ((opts3 & (RD_UDP_CS_2 | UDPF_2)) == RD_UDP_CS_2)
+ checksum = CHECKSUM_UNNECESSARY;
+ else if ((opts3 & (RD_TCP_CS_2 | TCPF_2)) == RD_TCP_CS_2)
+ checksum = CHECKSUM_UNNECESSARY;
+ }
+
+return_result:
+ return checksum;
+}
+
static inline bool rx_count_exceed(struct r8152 *tp)
{
return atomic_read(&tp->rx_count) > RTL8152_MAX_RX;
@@ -2721,10 +3001,10 @@ static int rx_bottom(struct r8152 *tp, int budget)
spin_unlock_irqrestore(&tp->rx_lock, flags);
list_for_each_safe(cursor, next, &rx_queue) {
- struct rx_desc *rx_desc;
struct rx_agg *agg, *agg_free;
int len_used = 0;
struct urb *urb;
+ void *rx_desc;
u8 *rx_data;
/* A bulk transfer of USB may contain may packets, so the
@@ -2747,7 +3027,7 @@ static int rx_bottom(struct r8152 *tp, int budget)
rx_desc = agg->buffer;
rx_data = agg->buffer;
- len_used += sizeof(struct rx_desc);
+ len_used += tp->rx_desc.size;
while (urb->actual_length > len_used) {
struct net_device *netdev = tp->netdev;
@@ -2758,7 +3038,7 @@ static int rx_bottom(struct r8152 *tp, int budget)
WARN_ON_ONCE(skb_queue_len(&tp->rx_queue) >= 1000);
- pkt_len = le32_to_cpu(rx_desc->opts1) & RX_LEN_MASK;
+ pkt_len = tp->desc_ops.rx_len(tp, rx_desc);
if (pkt_len < ETH_ZLEN)
break;
@@ -2768,7 +3048,7 @@ static int rx_bottom(struct r8152 *tp, int budget)
pkt_len -= ETH_FCS_LEN;
len = pkt_len;
- rx_data += sizeof(struct rx_desc);
+ rx_data += tp->rx_desc.size;
if (!agg_free || tp->rx_copybreak > len)
use_frags = false;
@@ -2799,8 +3079,8 @@ static int rx_bottom(struct r8152 *tp, int budget)
goto find_next_rx;
}
- skb->ip_summed = r8152_rx_csum(tp, rx_desc);
- rtl_rx_vlan_tag(rx_desc, skb);
+ skb->ip_summed = tp->desc_ops.rx_csum(tp, rx_desc);
+ tp->rx_desc.vlan_tag(rx_desc, skb);
if (use_frags) {
if (rx_frag_head_sz) {
@@ -2837,10 +3117,10 @@ static int rx_bottom(struct r8152 *tp, int budget)
}
find_next_rx:
- rx_data = rx_agg_align(rx_data + len + ETH_FCS_LEN);
- rx_desc = (struct rx_desc *)rx_data;
+ rx_data = rx_agg_align(tp, rx_data + len + ETH_FCS_LEN);
+ rx_desc = rx_data;
len_used = agg_offset(agg, rx_data);
- len_used += sizeof(struct rx_desc);
+ len_used += tp->rx_desc.size;
}
WARN_ON(!agg_free && page_count(agg->page) > 1);
@@ -3083,13 +3363,19 @@ static netdev_features_t
rtl8152_features_check(struct sk_buff *skb, struct net_device *dev,
netdev_features_t features)
{
+ struct r8152 *tp = netdev_priv(dev);
u32 mss = skb_shinfo(skb)->gso_size;
- int max_offset = mss ? GTTCPHO_MAX : TCPHO_MAX;
+ int max_offset;
+
+ if (tp->version < RTL_VER_16)
+ max_offset = mss ? GTTCPHO_MAX : TCPHO_MAX;
+ else
+ max_offset = mss ? GTTCPHO_MAX : TCPHO_MAX_2;
if ((mss || skb->ip_summed == CHECKSUM_PARTIAL) &&
skb_transport_offset(skb) > max_offset)
features &= ~(NETIF_F_CSUM_MASK | NETIF_F_GSO_MASK);
- else if ((skb->len + sizeof(struct tx_desc)) > agg_buf_sz)
+ else if ((skb->len + tp->tx_desc.size) > agg_buf_sz)
features &= ~NETIF_F_GSO_MASK;
return features;
@@ -3127,31 +3413,26 @@ static void r8152b_reset_packet_filter(struct r8152 *tp)
static void rtl8152_nic_reset(struct r8152 *tp)
{
- int i;
-
switch (tp->version) {
case RTL_TEST_01:
case RTL_VER_10:
case RTL_VER_11:
ocp_byte_clr_bits(tp, MCU_TYPE_PLA, PLA_CR, CR_TE);
-
- ocp_word_clr_bits(tp, MCU_TYPE_USB, USB_BMU_RESET,
- BMU_RESET_EP_IN);
-
+ ocp_word_clr_bits(tp, MCU_TYPE_USB, USB_BMU_RESET, BMU_RESET_EP_IN);
ocp_word_set_bits(tp, MCU_TYPE_USB, USB_USB_CTRL, CDC_ECM_EN);
-
ocp_byte_clr_bits(tp, MCU_TYPE_PLA, PLA_CR, CR_RE);
-
- ocp_word_set_bits(tp, MCU_TYPE_USB, USB_BMU_RESET,
- BMU_RESET_EP_IN);
-
+ ocp_word_set_bits(tp, MCU_TYPE_USB, USB_BMU_RESET, BMU_RESET_EP_IN);
ocp_word_clr_bits(tp, MCU_TYPE_USB, USB_USB_CTRL, CDC_ECM_EN);
break;
+ case RTL_VER_16:
+ ocp_byte_clr_bits(tp, MCU_TYPE_PLA, PLA_CR, CR_RE | CR_TE);
+ break;
+
default:
ocp_write_byte(tp, MCU_TYPE_PLA, PLA_CR, CR_RST);
- for (i = 0; i < 1000; i++) {
+ for (int i = 0; i < 1000; i++) {
if (test_bit(RTL8152_INACCESSIBLE, &tp->flags))
break;
if (!(ocp_read_byte(tp, MCU_TYPE_PLA, PLA_CR) & CR_RST))
@@ -3164,7 +3445,7 @@ static void rtl8152_nic_reset(struct r8152 *tp)
static void set_tx_qlen(struct r8152 *tp)
{
- tp->tx_qlen = agg_buf_sz / (mtu_to_size(tp->netdev->mtu) + sizeof(struct tx_desc));
+ tp->tx_qlen = agg_buf_sz / (mtu_to_size(tp->netdev->mtu) + tp->tx_desc.size);
}
static inline u16 rtl8152_get_speed(struct r8152 *tp)
@@ -3368,6 +3649,7 @@ static void r8153_set_rx_early_timeout(struct r8152 *tp)
case RTL_VER_12:
case RTL_VER_13:
case RTL_VER_15:
+ case RTL_VER_16:
ocp_write_word(tp, MCU_TYPE_USB, USB_RX_EARLY_TIMEOUT,
640 / 8);
ocp_write_word(tp, MCU_TYPE_USB, USB_RX_EXTRA_AGGR_TMR,
@@ -3379,9 +3661,14 @@ static void r8153_set_rx_early_timeout(struct r8152 *tp)
}
}
+static u32 rx_reserved_size(struct r8152 *tp, u32 mtu)
+{
+ return mtu_to_size(mtu) + tp->rx_desc.size + tp->rx_desc.align;
+}
+
static void r8153_set_rx_early_size(struct r8152 *tp)
{
- u32 ocp_data = tp->rx_buf_sz - rx_reserved_size(tp->netdev->mtu);
+ u32 ocp_data = tp->rx_buf_sz - rx_reserved_size(tp, tp->netdev->mtu);
switch (tp->version) {
case RTL_VER_03:
@@ -3406,6 +3693,10 @@ static void r8153_set_rx_early_size(struct r8152 *tp)
ocp_write_word(tp, MCU_TYPE_USB, USB_RX_EARLY_SIZE,
ocp_data / 8);
break;
+ case RTL_VER_16:
+ ocp_write_word(tp, MCU_TYPE_USB, USB_RX_EARLY_SIZE,
+ ocp_data / 16);
+ break;
default:
WARN_ON_ONCE(1);
break;
@@ -3517,6 +3808,7 @@ static void rtl_rx_vlan_en(struct r8152 *tp, bool enable)
case RTL_VER_12:
case RTL_VER_13:
case RTL_VER_15:
+ case RTL_VER_16:
default:
if (enable)
ocp_word_set_bits(tp, MCU_TYPE_PLA, PLA_RCR1,
@@ -3674,6 +3966,14 @@ static void r8153_u2p3en(struct r8152 *tp, bool enable)
ocp_word_clr_bits(tp, MCU_TYPE_USB, USB_U2P3_CTRL, U2P3_ENABLE);
}
+static int r8157_u2p3en(struct r8152 *tp, bool enable)
+{
+ if (enable)
+ return rtl_ip_set_bits(tp, USB_U2P3_V2_CTRL, U2P3_V2_ENABLE);
+ else
+ return rtl_ip_clr_bits(tp, USB_U2P3_V2_CTRL, U2P3_V2_ENABLE);
+}
+
static void r8153b_ups_flags(struct r8152 *tp)
{
u32 ups_flags = 0;
@@ -4019,6 +4319,18 @@ static void r8153b_power_cut_en(struct r8152 *tp, bool enable)
ocp_word_clr_bits(tp, MCU_TYPE_USB, USB_MISC_0, PCUT_STATUS);
}
+static void r8157_power_cut_en(struct r8152 *tp, bool enable)
+{
+ if (enable) {
+ ocp_word_set_bits(tp, MCU_TYPE_USB, USB_POWER_CUT, PWR_EN | PHASE2_EN);
+ ocp_byte_set_bits(tp, MCU_TYPE_USB, USB_MISC_2, BIT(1));
+ } else {
+ ocp_word_clr_bits(tp, MCU_TYPE_USB, USB_POWER_CUT, PWR_EN);
+ ocp_word_clr_bits(tp, MCU_TYPE_USB, USB_MISC_0, PCUT_STATUS);
+ ocp_byte_clr_bits(tp, MCU_TYPE_USB, USB_MISC_2, BIT(1));
+ }
+}
+
static void r8153_queue_wake(struct r8152 *tp, bool enable)
{
if (enable)
@@ -4135,6 +4447,22 @@ static void rtl8156_runtime_enable(struct r8152 *tp, bool enable)
}
}
+static void rtl8157_runtime_enable(struct r8152 *tp, bool enable)
+{
+ if (enable) {
+ r8153_queue_wake(tp, true);
+ r8153b_u1u2en(tp, false);
+ r8157_u2p3en(tp, false);
+ rtl_runtime_suspend_enable(tp, true);
+ } else {
+ r8153_queue_wake(tp, false);
+ rtl_runtime_suspend_enable(tp, false);
+ r8157_u2p3en(tp, true);
+ if (tp->udev->speed >= USB_SPEED_SUPER)
+ r8153b_u1u2en(tp, true);
+ }
+}
+
static void r8153_teredo_off(struct r8152 *tp)
{
switch (tp->version) {
@@ -4159,6 +4487,7 @@ static void r8153_teredo_off(struct r8152 *tp)
case RTL_VER_13:
case RTL_VER_14:
case RTL_VER_15:
+ case RTL_VER_16:
default:
/* The bit 0 ~ 7 are relative with teredo settings. They are
* W1C (write 1 to clear), so set all 1 to disable it.
@@ -4212,6 +4541,7 @@ static void rtl_clear_bp(struct r8152 *tp, u16 type)
bp_num = 8;
break;
case RTL_VER_14:
+ case RTL_VER_16:
default:
ocp_write_word(tp, type, USB_BP2_EN, 0);
bp_num = 16;
@@ -4319,6 +4649,7 @@ static bool rtl8152_is_fw_phy_speed_up_ok(struct r8152 *tp, struct fw_phy_speed_
case RTL_VER_11:
case RTL_VER_12:
case RTL_VER_14:
+ case RTL_VER_16:
goto out;
case RTL_VER_13:
case RTL_VER_15:
@@ -5480,6 +5811,7 @@ static void rtl_eee_enable(struct r8152 *tp, bool enable)
case RTL_VER_12:
case RTL_VER_13:
case RTL_VER_15:
+ case RTL_VER_16:
if (enable) {
r8156_eee_en(tp, true);
ocp_reg_write(tp, OCP_EEE_ADV, tp->eee_adv);
@@ -6064,15 +6396,24 @@ static int rtl8156_enable(struct r8152 *tp)
if (test_bit(RTL8152_INACCESSIBLE, &tp->flags))
return -ENODEV;
- r8156_fc_parameter(tp);
+ if (tp->version < RTL_VER_12)
+ r8156_fc_parameter(tp);
+
set_tx_qlen(tp);
rtl_set_eee_plus(tp);
+
+ if (tp->version >= RTL_VER_12 && tp->version <= RTL_VER_16)
+ ocp_word_clr_bits(tp, MCU_TYPE_USB, USB_RX_AGGR_NUM, RX_AGGR_NUM_MASK);
+
r8153_set_rx_early_timeout(tp);
r8153_set_rx_early_size(tp);
speed = rtl8152_get_speed(tp);
rtl_set_ifg(tp, speed);
+ if (tp->version >= RTL_VER_16)
+ return rtl_enable(tp);
+
if (speed & _2500bps)
ocp_word_clr_bits(tp, MCU_TYPE_PLA, PLA_MAC_PWR_CTRL4,
IDLE_SPDWN_EN);
@@ -6080,10 +6421,12 @@ static int rtl8156_enable(struct r8152 *tp)
ocp_word_set_bits(tp, MCU_TYPE_PLA, PLA_MAC_PWR_CTRL4,
IDLE_SPDWN_EN);
- if (speed & _1000bps)
- ocp_write_word(tp, MCU_TYPE_PLA, PLA_EEE_TXTWSYS, 0x11);
- else if (speed & _500bps)
- ocp_write_word(tp, MCU_TYPE_PLA, PLA_EEE_TXTWSYS, 0x3d);
+ if (tp->version < RTL_VER_12) {
+ if (speed & _1000bps)
+ ocp_write_word(tp, MCU_TYPE_PLA, PLA_EEE_TXTWSYS, 0x11);
+ else if (speed & _500bps)
+ ocp_write_word(tp, MCU_TYPE_PLA, PLA_EEE_TXTWSYS, 0x3d);
+ }
if (tp->udev->speed == USB_SPEED_HIGH) {
/* USB 0xb45e[3:0] l1_nyet_hird */
@@ -6108,45 +6451,6 @@ static void rtl8156_disable(struct r8152 *tp)
rtl8153_disable(tp);
}
-static int rtl8156b_enable(struct r8152 *tp)
-{
- u16 speed;
-
- if (test_bit(RTL8152_INACCESSIBLE, &tp->flags))
- return -ENODEV;
-
- set_tx_qlen(tp);
- rtl_set_eee_plus(tp);
-
- ocp_word_clr_bits(tp, MCU_TYPE_USB, USB_RX_AGGR_NUM, RX_AGGR_NUM_MASK);
-
- r8153_set_rx_early_timeout(tp);
- r8153_set_rx_early_size(tp);
-
- speed = rtl8152_get_speed(tp);
- rtl_set_ifg(tp, speed);
-
- if (speed & _2500bps)
- ocp_word_clr_bits(tp, MCU_TYPE_PLA, PLA_MAC_PWR_CTRL4,
- IDLE_SPDWN_EN);
- else
- ocp_word_set_bits(tp, MCU_TYPE_PLA, PLA_MAC_PWR_CTRL4,
- IDLE_SPDWN_EN);
-
- if (tp->udev->speed == USB_SPEED_HIGH) {
- if (is_flow_control(speed))
- ocp_word_w0w1(tp, MCU_TYPE_USB, USB_L1_CTRL, 0xf, 0xf);
- else
- ocp_word_w0w1(tp, MCU_TYPE_USB, USB_L1_CTRL, 0xf, 0x1);
- }
-
- ocp_word_clr_bits(tp, MCU_TYPE_USB, USB_FW_TASK, FC_PATCH_TASK);
- usleep_range(1000, 2000);
- ocp_word_set_bits(tp, MCU_TYPE_USB, USB_FW_TASK, FC_PATCH_TASK);
-
- return rtl_enable(tp);
-}
-
static int rtl8152_set_speed(struct r8152 *tp, u8 autoneg, u32 speed, u8 duplex,
u32 advertising)
{
@@ -6489,7 +6793,7 @@ static void rtl8156_change_mtu(struct r8152 *tp)
/* TX share fifo free credit full threshold */
ocp_write_word(tp, MCU_TYPE_PLA, PLA_TXFIFO_CTRL, 512 / 64);
ocp_write_word(tp, MCU_TYPE_PLA, PLA_TXFIFO_FULL,
- ALIGN(rx_max_size + sizeof(struct tx_desc), 1024) / 16);
+ ALIGN(rx_max_size + tp->tx_desc.size, 1024) / 16);
}
static void rtl8156_up(struct r8152 *tp)
@@ -6498,7 +6802,8 @@ static void rtl8156_up(struct r8152 *tp)
return;
r8153b_u1u2en(tp, false);
- r8153_u2p3en(tp, false);
+ if (tp->version != RTL_VER_16)
+ r8153_u2p3en(tp, false);
r8153_aldps_en(tp, false);
rxdy_gated_en(tp, true);
@@ -6511,6 +6816,9 @@ static void rtl8156_up(struct r8152 *tp)
ocp_byte_clr_bits(tp, MCU_TYPE_PLA, PLA_OOB_CTRL, NOW_IS_OOB);
+ if (tp->version == RTL_VER_16)
+ ocp_word_clr_bits(tp, MCU_TYPE_PLA, PLA_RCR1, BIT(3));
+
ocp_word_clr_bits(tp, MCU_TYPE_PLA, PLA_SFF_STS_7, MCU_BORW_EN);
rtl_rx_vlan_en(tp, tp->netdev->features & NETIF_F_HW_VLAN_CTAG_RX);
@@ -6534,8 +6842,11 @@ static void rtl8156_up(struct r8152 *tp)
ocp_word_clr_bits(tp, MCU_TYPE_PLA, PLA_MAC_PWR_CTRL3,
PLA_MCU_SPDWN_EN);
- ocp_word_clr_bits(tp, MCU_TYPE_USB, USB_SPEED_OPTION,
- RG_PWRDN_EN | ALL_SPEED_OFF);
+ ocp_word_clr_bits(tp, MCU_TYPE_PLA, PLA_MAC_PWR_CTRL3, PLA_MCU_SPDWN_EN);
+
+ if (tp->version != RTL_VER_16)
+ ocp_word_clr_bits(tp, MCU_TYPE_USB, USB_SPEED_OPTION,
+ RG_PWRDN_EN | ALL_SPEED_OFF);
ocp_write_dword(tp, MCU_TYPE_USB, USB_RX_BUF_TH, 0x00600400);
@@ -6545,9 +6856,10 @@ static void rtl8156_up(struct r8152 *tp)
}
r8153_aldps_en(tp, true);
- r8153_u2p3en(tp, true);
+ if (tp->version != RTL_VER_16)
+ r8153_u2p3en(tp, true);
- if (tp->udev->speed >= USB_SPEED_SUPER)
+ if (tp->version != RTL_VER_16 && tp->udev->speed >= USB_SPEED_SUPER)
r8153b_u1u2en(tp, true);
}
@@ -6562,8 +6874,10 @@ static void rtl8156_down(struct r8152 *tp)
PLA_MCU_SPDWN_EN);
r8153b_u1u2en(tp, false);
- r8153_u2p3en(tp, false);
- r8153b_power_cut_en(tp, false);
+ if (tp->version != RTL_VER_16) {
+ r8153_u2p3en(tp, false);
+ r8153b_power_cut_en(tp, false);
+ }
r8153_aldps_en(tp, false);
ocp_byte_clr_bits(tp, MCU_TYPE_PLA, PLA_OOB_CTRL, NOW_IS_OOB);
@@ -7636,106 +7950,241 @@ static void r8156b_hw_phy_cfg(struct r8152 *tp)
set_bit(PHY_RESET, &tp->flags);
}
-static void r8156_init(struct r8152 *tp)
+static void r8157_hw_phy_cfg(struct r8152 *tp)
{
+ u32 ocp_data;
u16 data;
- int i;
-
- if (test_bit(RTL8152_INACCESSIBLE, &tp->flags))
- return;
-
- ocp_byte_clr_bits(tp, MCU_TYPE_USB, USB_ECM_OP, EN_ALL_SPEED);
-
- ocp_write_word(tp, MCU_TYPE_USB, USB_SPEED_OPTION, 0);
-
- ocp_word_set_bits(tp, MCU_TYPE_USB, USB_ECM_OPTION, BYPASS_MAC_RESET);
-
- r8153b_u1u2en(tp, false);
+ int ret;
- for (i = 0; i < 500; i++) {
- if (ocp_read_word(tp, MCU_TYPE_PLA, PLA_BOOT_CTRL) &
- AUTOLOAD_DONE)
- break;
+ r8156b_wait_loading_flash(tp);
- msleep(20);
- if (test_bit(RTL8152_INACCESSIBLE, &tp->flags))
- return;
+ ocp_data = ocp_read_word(tp, MCU_TYPE_USB, USB_MISC_0);
+ if (ocp_data & PCUT_STATUS) {
+ ocp_data &= ~PCUT_STATUS;
+ ocp_write_word(tp, MCU_TYPE_USB, USB_MISC_0, ocp_data);
}
data = r8153_phy_status(tp, 0);
- if (data == PHY_STAT_EXT_INIT)
+ switch (data) {
+ case PHY_STAT_EXT_INIT:
+ ocp_reg_clr_bits(tp, 0xa466, BIT(0));
ocp_reg_clr_bits(tp, 0xa468, BIT(3) | BIT(1));
+ break;
+ case PHY_STAT_LAN_ON:
+ case PHY_STAT_PWRDN:
+ default:
+ break;
+ }
- r8152_mdio_test_and_clr_bit(tp, MII_BMCR, BMCR_PDOWN);
+ data = r8152_mdio_read(tp, MII_BMCR);
+ if (data & BMCR_PDOWN) {
+ data &= ~BMCR_PDOWN;
+ r8152_mdio_write(tp, MII_BMCR, data);
+ }
- data = r8153_phy_status(tp, PHY_STAT_LAN_ON);
- WARN_ON_ONCE(data != PHY_STAT_LAN_ON);
+ r8153_aldps_en(tp, false);
+ rtl_eee_enable(tp, false);
- r8153_u2p3en(tp, false);
+ ret = r8153_phy_status(tp, PHY_STAT_LAN_ON);
+ if (ret < 0)
+ return;
+ WARN_ON_ONCE(ret != PHY_STAT_LAN_ON);
- /* MSC timer = 0xfff * 8ms = 32760 ms */
- ocp_write_word(tp, MCU_TYPE_USB, USB_MSC_TIMER, 0x0fff);
+ /* PFM mode */
+ ocp_word_clr_bits(tp, MCU_TYPE_PLA, PLA_PHY_PWR, PFM_PWM_SWITCH);
- /* U1/U2/L1 idle timer. 500 us */
- ocp_write_word(tp, MCU_TYPE_USB, USB_U1U2_TIMER, 500);
+ /* Advanced Power Saving parameter */
+ ocp_reg_set_bits(tp, 0xa430, BIT(0) | BIT(1));
- r8153b_power_cut_en(tp, false);
- r8156_ups_en(tp, false);
- r8153_queue_wake(tp, false);
- rtl_runtime_suspend_enable(tp, false);
+ /* aldpsce force mode */
+ ocp_reg_clr_bits(tp, 0xa44a, BIT(2));
- if (tp->udev->speed >= USB_SPEED_SUPER)
- r8153b_u1u2en(tp, true);
+ switch (tp->version) {
+ case RTL_VER_16:
+ /* XG_INRX parameter */
+ sram_write_w0w1(tp, 0x8183, 0xff00, 0x5900);
+ ocp_reg_set_bits(tp, 0xa654, BIT(11));
+ ocp_reg_set_bits(tp, 0xb648, BIT(14));
+ ocp_reg_clr_bits(tp, 0xad2c, BIT(15));
+ ocp_reg_set_bits(tp, 0xad94, BIT(5));
+ ocp_reg_set_bits(tp, 0xada0, BIT(1));
+ ocp_reg_w0w1(tp, 0xae06, 0xfc00, 0x7c00);
+ sram2_write_w0w1(tp, 0x8647, 0xff00, 0xe600);
+ sram2_write_w0w1(tp, 0x8036, 0xff00, 0x3000);
+ sram2_write_w0w1(tp, 0x8078, 0xff00, 0x3000);
+
+ /* green mode */
+ sram2_write_w0w1(tp, 0x89e9, 0xff00, 0);
+ sram2_write_w0w1(tp, 0x8ffd, 0xff00, 0x0100);
+ sram2_write_w0w1(tp, 0x8ffe, 0xff00, 0x0200);
+ sram2_write_w0w1(tp, 0x8fff, 0xff00, 0x0400);
+
+ /* recognize AQC/Bcom function */
+ sram_write_w0w1(tp, 0x8018, 0xff00, 0x7700);
+ ocp_reg_write(tp, OCP_SRAM_ADDR, 0x8f9c);
+ ocp_reg_write(tp, OCP_SRAM_DATA, 0x0005);
+ ocp_reg_write(tp, OCP_SRAM_DATA, 0x0000);
+ ocp_reg_write(tp, OCP_SRAM_DATA, 0x00ed);
+ ocp_reg_write(tp, OCP_SRAM_DATA, 0x0502);
+ ocp_reg_write(tp, OCP_SRAM_DATA, 0x0b00);
+ ocp_reg_write(tp, OCP_SRAM_DATA, 0xd401);
+ sram_write_w0w1(tp, 0x8fa8, 0xff00, 0x2900);
+
+ /* RFI_corr_thd 5g */
+ sram2_write_w0w1(tp, 0x814b, 0xff00, 0x1100);
+ sram2_write_w0w1(tp, 0x814d, 0xff00, 0x1100);
+ sram2_write_w0w1(tp, 0x814f, 0xff00, 0x0b00);
+ sram2_write_w0w1(tp, 0x8142, 0xff00, 0x0100);
+ sram2_write_w0w1(tp, 0x8144, 0xff00, 0x0100);
+ sram2_write_w0w1(tp, 0x8150, 0xff00, 0x0100);
+
+ /* RFI_corr_thd 2p5g */
+ sram2_write_w0w1(tp, 0x8118, 0xff00, 0x0700);
+ sram2_write_w0w1(tp, 0x811a, 0xff00, 0x0700);
+ sram2_write_w0w1(tp, 0x811c, 0xff00, 0x0500);
+ sram2_write_w0w1(tp, 0x810f, 0xff00, 0x0100);
+ sram2_write_w0w1(tp, 0x8111, 0xff00, 0x0100);
+ sram2_write_w0w1(tp, 0x811d, 0xff00, 0x0100);
+
+ /* RFI parameter */
+ ocp_reg_clr_bits(tp, 0xad1c, BIT(8));
+ ocp_reg_w0w1(tp, 0xade8, 0xffc0, 0x1400);
+ sram2_write_w0w1(tp, 0x864b, 0xff00, 0x9d00);
+ sram2_write_w0w1(tp, 0x862c, 0xff00, 0x1200);
+ ocp_reg_write(tp, OCP_SRAM_ADDR, 0x8566);
+ ocp_reg_write(tp, OCP_SRAM_DATA, 0x003f);
+ ocp_reg_write(tp, OCP_SRAM_DATA, 0x3f02);
+ ocp_reg_write(tp, OCP_SRAM_DATA, 0x023c);
+ ocp_reg_write(tp, OCP_SRAM_DATA, 0x3b0a);
+ ocp_reg_write(tp, OCP_SRAM_DATA, 0x1c00);
+ ocp_reg_write(tp, OCP_SRAM_DATA, 0x0000);
+ ocp_reg_write(tp, OCP_SRAM_DATA, 0x0000);
+ ocp_reg_write(tp, OCP_SRAM_DATA, 0x0000);
+ ocp_reg_write(tp, OCP_SRAM_DATA, 0x0000);
+
+ /* RFI-color noise gen parameter 5g */
+ ocp_reg_set_bits(tp, 0xad9c, BIT(5));
+ sram2_write_w0w1(tp, 0x8122, 0xff00, 0x0c00);
+ ocp_reg_write(tp, OCP_SRAM2_ADDR, 0x82c8);
+ ocp_reg_write(tp, OCP_SRAM2_DATA, 0x03ed);
+ ocp_reg_write(tp, OCP_SRAM2_DATA, 0x03ff);
+ ocp_reg_write(tp, OCP_SRAM2_DATA, 0x0009);
+ ocp_reg_write(tp, OCP_SRAM2_DATA, 0x03fe);
+ ocp_reg_write(tp, OCP_SRAM2_DATA, 0x000b);
+ ocp_reg_write(tp, OCP_SRAM2_DATA, 0x0021);
+ ocp_reg_write(tp, OCP_SRAM2_DATA, 0x03f7);
+ ocp_reg_write(tp, OCP_SRAM2_DATA, 0x03b8);
+ ocp_reg_write(tp, OCP_SRAM2_DATA, 0x03e0);
+ ocp_reg_write(tp, OCP_SRAM2_DATA, 0x0049);
+ ocp_reg_write(tp, OCP_SRAM2_DATA, 0x0049);
+ ocp_reg_write(tp, OCP_SRAM2_DATA, 0x03e0);
+ ocp_reg_write(tp, OCP_SRAM2_DATA, 0x03b8);
+ ocp_reg_write(tp, OCP_SRAM2_DATA, 0x03f7);
+ ocp_reg_write(tp, OCP_SRAM2_DATA, 0x0021);
+ ocp_reg_write(tp, OCP_SRAM2_DATA, 0x000b);
+ ocp_reg_write(tp, OCP_SRAM2_DATA, 0x03fe);
+ ocp_reg_write(tp, OCP_SRAM2_DATA, 0x0009);
+ ocp_reg_write(tp, OCP_SRAM2_DATA, 0x03ff);
+ ocp_reg_write(tp, OCP_SRAM2_DATA, 0x03ed);
+
+ /* RFI-color noise gen parameter 2p5g */
+ sram2_write_w0w1(tp, 0x80ef, 0xff00, 0x0c00);
+ ocp_reg_write(tp, OCP_SRAM2_ADDR, 0x82a0);
+ ocp_reg_write(tp, OCP_SRAM2_DATA, 0x000e);
+ ocp_reg_write(tp, OCP_SRAM2_DATA, 0x03fe);
+ ocp_reg_write(tp, OCP_SRAM2_DATA, 0x03ed);
+ ocp_reg_write(tp, OCP_SRAM2_DATA, 0x0006);
+ ocp_reg_write(tp, OCP_SRAM2_DATA, 0x001a);
+ ocp_reg_write(tp, OCP_SRAM2_DATA, 0x03f1);
+ ocp_reg_write(tp, OCP_SRAM2_DATA, 0x03d8);
+ ocp_reg_write(tp, OCP_SRAM2_DATA, 0x0023);
+ ocp_reg_write(tp, OCP_SRAM2_DATA, 0x0054);
+ ocp_reg_write(tp, OCP_SRAM2_DATA, 0x0322);
+ ocp_reg_write(tp, OCP_SRAM2_DATA, 0x00dd);
+ ocp_reg_write(tp, OCP_SRAM2_DATA, 0x03ab);
+ ocp_reg_write(tp, OCP_SRAM2_DATA, 0x03dc);
+ ocp_reg_write(tp, OCP_SRAM2_DATA, 0x0027);
+ ocp_reg_write(tp, OCP_SRAM2_DATA, 0x000e);
+ ocp_reg_write(tp, OCP_SRAM2_DATA, 0x03e5);
+ ocp_reg_write(tp, OCP_SRAM2_DATA, 0x03f9);
+ ocp_reg_write(tp, OCP_SRAM2_DATA, 0x0012);
+ ocp_reg_write(tp, OCP_SRAM2_DATA, 0x0001);
+ ocp_reg_write(tp, OCP_SRAM2_DATA, 0x03f1);
+
+ /* modify thermal speed down threshold */
+ ocp_reg_w0w1(tp, 0xb54c, 0xffc0, 0x3700);
+
+ /* XG compatibility modification */
+ ocp_reg_set_bits(tp, 0xb648, BIT(6));
+ sram2_write_w0w1(tp, 0x8082, 0xff00, 0x5d00);
+ sram2_write_w0w1(tp, 0x807c, 0xff00, 0x5000);
+ sram2_write_w0w1(tp, 0x809d, 0xff00, 0x5000);
+ break;
+ default:
+ break;
+ }
- usb_enable_lpm(tp->udev);
+ if (rtl_phy_patch_request(tp, true, true))
+ return;
- r8156_mac_clk_spd(tp, true);
+ ocp_word_set_bits(tp, MCU_TYPE_PLA, PLA_MAC_PWR_CTRL4, EEE_SPDWN_EN);
- ocp_word_clr_bits(tp, MCU_TYPE_PLA, PLA_MAC_PWR_CTRL3,
- PLA_MCU_SPDWN_EN);
+ ocp_reg_w0w1(tp, OCP_DOWN_SPEED, EN_EEE_100 | EN_EEE_1000, EN_10M_CLKDIV);
- if (rtl8152_get_speed(tp) & LINK_STATUS)
- ocp_word_set_bits(tp, MCU_TYPE_PLA, PLA_EXTRA_STATUS,
- CUR_LINK_OK | POLL_LINK_CHG);
- else
- ocp_word_w0w1(tp, MCU_TYPE_PLA, PLA_EXTRA_STATUS, CUR_LINK_OK,
- POLL_LINK_CHG);
+ tp->ups_info._10m_ckdiv = true;
+ tp->ups_info.eee_plloff_100 = false;
+ tp->ups_info.eee_plloff_giga = false;
- set_bit(GREEN_ETHERNET, &tp->flags);
+ ocp_reg_set_bits(tp, OCP_POWER_CFG, EEE_CLKDIV_EN);
+ tp->ups_info.eee_ckdiv = true;
- /* rx aggregation */
- ocp_word_clr_bits(tp, MCU_TYPE_USB, USB_USB_CTRL,
- RX_AGG_DISABLE | RX_ZERO_EN);
+ rtl_phy_patch_request(tp, false, true);
- ocp_byte_set_bits(tp, MCU_TYPE_USB, USB_BMU_CONFIG, ACT_ODMA);
+ rtl_green_en(tp, test_bit(GREEN_ETHERNET, &tp->flags));
- r8156_mdio_force_mode(tp);
- rtl_tally_reset(tp);
+ ocp_reg_clr_bits(tp, 0xa428, BIT(9));
+ ocp_reg_clr_bits(tp, 0xa5ea, BIT(0) | BIT(1));
+ tp->ups_info.lite_mode = 0;
- tp->coalesce = 15000; /* 15 us */
+ if (tp->eee_en)
+ rtl_eee_enable(tp, true);
+
+ r8153_aldps_en(tp, true);
+ r8152b_enable_fc(tp);
+
+ set_bit(PHY_RESET, &tp->flags);
}
-static void r8156b_init(struct r8152 *tp)
+static void r8156_init(struct r8152 *tp)
{
+ u32 ocp_data;
u16 data;
int i;
if (test_bit(RTL8152_INACCESSIBLE, &tp->flags))
return;
+ if (tp->version == RTL_VER_16) {
+ ocp_byte_set_bits(tp, MCU_TYPE_USB, 0xcffe, BIT(3));
+ ocp_byte_clr_bits(tp, MCU_TYPE_USB, 0xd3ca, BIT(0));
+ }
+
ocp_byte_clr_bits(tp, MCU_TYPE_USB, USB_ECM_OP, EN_ALL_SPEED);
- ocp_write_word(tp, MCU_TYPE_USB, USB_SPEED_OPTION, 0);
+ if (tp->version != RTL_VER_16)
+ ocp_write_word(tp, MCU_TYPE_USB, USB_SPEED_OPTION, 0);
ocp_word_set_bits(tp, MCU_TYPE_USB, USB_ECM_OPTION, BYPASS_MAC_RESET);
- ocp_word_set_bits(tp, MCU_TYPE_USB, USB_U2P3_CTRL, RX_DETECT8);
+ if (tp->version >= RTL_VER_12 && tp->version <= RTL_VER_15)
+ ocp_word_set_bits(tp, MCU_TYPE_USB, USB_U2P3_CTRL, RX_DETECT8);
r8153b_u1u2en(tp, false);
switch (tp->version) {
case RTL_VER_13:
case RTL_VER_15:
+ case RTL_VER_16:
r8156b_wait_loading_flash(tp);
break;
default:
@@ -7755,14 +8204,22 @@ static void r8156b_init(struct r8152 *tp)
data = r8153_phy_status(tp, 0);
if (data == PHY_STAT_EXT_INIT) {
ocp_reg_clr_bits(tp, 0xa468, BIT(3) | BIT(1));
- ocp_reg_clr_bits(tp, 0xa466, BIT(0));
+ if (tp->version >= RTL_VER_12)
+ ocp_reg_clr_bits(tp, 0xa466, BIT(0));
}
- r8152_mdio_test_and_clr_bit(tp, MII_BMCR, BMCR_PDOWN);
+ data = r8152_mdio_read(tp, MII_BMCR);
+ if (data & BMCR_PDOWN) {
+ data &= ~BMCR_PDOWN;
+ r8152_mdio_write(tp, MII_BMCR, data);
+ }
data = r8153_phy_status(tp, PHY_STAT_LAN_ON);
- r8153_u2p3en(tp, false);
+ if (tp->version == RTL_VER_16)
+ r8157_u2p3en(tp, false);
+ else
+ r8153_u2p3en(tp, false);
/* MSC timer = 0xfff * 8ms = 32760 ms */
ocp_write_word(tp, MCU_TYPE_USB, USB_MSC_TIMER, 0x0fff);
@@ -7770,7 +8227,11 @@ static void r8156b_init(struct r8152 *tp)
/* U1/U2/L1 idle timer. 500 us */
ocp_write_word(tp, MCU_TYPE_USB, USB_U1U2_TIMER, 500);
- r8153b_power_cut_en(tp, false);
+ if (tp->version == RTL_VER_16)
+ r8157_power_cut_en(tp, false);
+ else
+ r8153b_power_cut_en(tp, false);
+
r8156_ups_en(tp, false);
r8153_queue_wake(tp, false);
rtl_runtime_suspend_enable(tp, false);
@@ -7780,39 +8241,53 @@ static void r8156b_init(struct r8152 *tp)
usb_enable_lpm(tp->udev);
- ocp_word_clr_bits(tp, MCU_TYPE_PLA, PLA_RCR, SLOT_EN);
+ if (tp->version >= RTL_VER_12 && tp->version <= RTL_VER_15) {
+ ocp_word_clr_bits(tp, MCU_TYPE_PLA, PLA_RCR, SLOT_EN);
- ocp_word_set_bits(tp, MCU_TYPE_PLA, PLA_CPCR, FLOW_CTRL_EN);
+ ocp_word_set_bits(tp, MCU_TYPE_PLA, PLA_CPCR, FLOW_CTRL_EN);
- /* enable fc timer and set timer to 600 ms. */
- ocp_write_word(tp, MCU_TYPE_USB, USB_FC_TIMER,
- CTRL_TIMER_EN | (600 / 8));
+ /* enable fc timer and set timer to 600 ms. */
+ ocp_write_word(tp, MCU_TYPE_USB, USB_FC_TIMER, CTRL_TIMER_EN | (600 / 8));
- if (!(ocp_read_word(tp, MCU_TYPE_PLA, PLA_POL_GPIO_CTRL) & DACK_DET_EN))
- ocp_word_w0w1(tp, MCU_TYPE_USB, USB_FW_CTRL, AUTO_SPEEDUP,
- FLOW_CTRL_PATCH_2);
- else
- ocp_word_clr_bits(tp, MCU_TYPE_USB, USB_FW_CTRL, AUTO_SPEEDUP);
+ ocp_data = ocp_read_word(tp, MCU_TYPE_USB, USB_FW_CTRL);
+ if (!(ocp_read_word(tp, MCU_TYPE_PLA, PLA_POL_GPIO_CTRL) & DACK_DET_EN))
+ ocp_data |= FLOW_CTRL_PATCH_2;
+ ocp_data &= ~AUTO_SPEEDUP;
+ ocp_write_word(tp, MCU_TYPE_USB, USB_FW_CTRL, ocp_data);
- ocp_word_set_bits(tp, MCU_TYPE_USB, USB_FW_TASK, FC_PATCH_TASK);
+ ocp_word_set_bits(tp, MCU_TYPE_USB, USB_FW_TASK, FC_PATCH_TASK);
+ }
r8156_mac_clk_spd(tp, true);
- ocp_word_clr_bits(tp, MCU_TYPE_PLA, PLA_MAC_PWR_CTRL3,
- PLA_MCU_SPDWN_EN);
+ if (tp->version != RTL_VER_16)
+ ocp_word_clr_bits(tp, MCU_TYPE_PLA, PLA_MAC_PWR_CTRL3, PLA_MCU_SPDWN_EN);
+ ocp_data = ocp_read_word(tp, MCU_TYPE_PLA, PLA_EXTRA_STATUS);
if (rtl8152_get_speed(tp) & LINK_STATUS)
- ocp_word_set_bits(tp, MCU_TYPE_PLA, PLA_EXTRA_STATUS,
- CUR_LINK_OK | POLL_LINK_CHG);
+ ocp_data |= CUR_LINK_OK;
else
- ocp_word_w0w1(tp, MCU_TYPE_PLA, PLA_EXTRA_STATUS, CUR_LINK_OK,
- POLL_LINK_CHG);
+ ocp_data &= ~CUR_LINK_OK;
+ ocp_data |= POLL_LINK_CHG;
+ ocp_write_word(tp, MCU_TYPE_PLA, PLA_EXTRA_STATUS, ocp_data);
set_bit(GREEN_ETHERNET, &tp->flags);
- /* rx aggregation */
- ocp_word_clr_bits(tp, MCU_TYPE_USB, USB_USB_CTRL,
- RX_AGG_DISABLE | RX_ZERO_EN);
+ /* rx aggregation / 16 bytes Rx descriptor */
+ if (tp->version == RTL_VER_16)
+ ocp_word_clr_bits(tp, MCU_TYPE_USB, USB_USB_CTRL, RX_AGG_DISABLE | RX_DESC_16B);
+ else
+ ocp_word_clr_bits(tp, MCU_TYPE_USB, USB_USB_CTRL, RX_AGG_DISABLE | RX_ZERO_EN);
+
+ if (tp->version < RTL_VER_12)
+ ocp_byte_set_bits(tp, MCU_TYPE_USB, USB_BMU_CONFIG, ACT_ODMA);
+
+ if (tp->version == RTL_VER_16) {
+ /* Disable Rx Zero Len */
+ rtl_bmu_clr_bits(tp, 0x2300, BIT(3));
+ /* TX descriptor Signature */
+ ocp_byte_clr_bits(tp, MCU_TYPE_USB, 0xd4ae, BIT(1));
+ }
r8156_mdio_force_mode(tp);
rtl_tally_reset(tp);
@@ -8962,6 +9437,11 @@ static void rtl8153_unload(struct r8152 *tp)
return;
r8153_power_cut_en(tp, false);
+
+ if (tp->version >= RTL_VER_16) {
+ /* Disable Interrupt Mitigation */
+ ocp_byte_clr_bits(tp, MCU_TYPE_USB, 0xcf04, BIT(0) | BIT(1) | BIT(2) | BIT(7));
+ }
}
static void rtl8153b_unload(struct r8152 *tp)
@@ -8972,6 +9452,38 @@ static void rtl8153b_unload(struct r8152 *tp)
r8153b_power_cut_en(tp, false);
}
+static int r8152_desc_init(struct r8152 *tp)
+{
+ tp->rx_desc.size = sizeof(struct rx_desc);
+ tp->rx_desc.align = 8;
+ tp->rx_desc.vlan_tag = r8152_rx_vlan_tag;
+ tp->desc_ops.rx_csum = r8152_rx_csum;
+ tp->desc_ops.rx_len = r8152_rx_len;
+ tp->tx_desc.size = sizeof(struct tx_desc);
+ tp->tx_desc.align = 4;
+ tp->tx_desc.vlan_tag = r8152_tx_vlan_tag;
+ tp->desc_ops.tx_csum = r8152_tx_csum;
+ tp->desc_ops.tx_len = r8152_tx_len;
+
+ return 0;
+}
+
+static int r8157_desc_init(struct r8152 *tp)
+{
+ tp->rx_desc.size = sizeof(struct rx_desc_v2);
+ tp->rx_desc.align = 16;
+ tp->rx_desc.vlan_tag = r8157_rx_vlan_tag;
+ tp->desc_ops.rx_csum = r8157_rx_csum;
+ tp->desc_ops.rx_len = r8157_rx_len;
+ tp->tx_desc.size = sizeof(struct tx_desc_v2);
+ tp->tx_desc.align = 16;
+ tp->tx_desc.vlan_tag = r8152_tx_vlan_tag;
+ tp->desc_ops.tx_csum = r8157_tx_csum;
+ tp->desc_ops.tx_len = r8157_tx_len;
+
+ return 0;
+}
+
static int rtl_ops_init(struct r8152 *tp)
{
struct rtl_ops *ops = &tp->rtl_ops;
@@ -8995,6 +9507,7 @@ static int rtl_ops_init(struct r8152 *tp)
tp->rx_buf_sz = 16 * 1024;
tp->eee_en = true;
tp->eee_adv = MDIO_EEE_100TX;
+ r8152_desc_init(tp);
break;
case RTL_VER_03:
@@ -9019,6 +9532,7 @@ static int rtl_ops_init(struct r8152 *tp)
tp->rx_buf_sz = 32 * 1024;
tp->eee_en = true;
tp->eee_adv = MDIO_EEE_1000T | MDIO_EEE_100TX;
+ r8152_desc_init(tp);
break;
case RTL_VER_08:
@@ -9038,6 +9552,7 @@ static int rtl_ops_init(struct r8152 *tp)
tp->rx_buf_sz = 32 * 1024;
tp->eee_en = true;
tp->eee_adv = MDIO_EEE_1000T | MDIO_EEE_100TX;
+ r8152_desc_init(tp);
break;
case RTL_VER_11:
@@ -9060,6 +9575,7 @@ static int rtl_ops_init(struct r8152 *tp)
ops->change_mtu = rtl8156_change_mtu;
tp->rx_buf_sz = 48 * 1024;
tp->support_2500full = 1;
+ r8152_desc_init(tp);
break;
case RTL_VER_12:
@@ -9070,8 +9586,8 @@ static int rtl_ops_init(struct r8152 *tp)
tp->eee_en = true;
tp->eee_adv = MDIO_EEE_1000T | MDIO_EEE_100TX;
tp->eee_adv2 = MDIO_EEE_2_5GT;
- ops->init = r8156b_init;
- ops->enable = rtl8156b_enable;
+ ops->init = r8156_init;
+ ops->enable = rtl8156_enable;
ops->disable = rtl8153_disable;
ops->up = rtl8156_up;
ops->down = rtl8156_down;
@@ -9083,6 +9599,7 @@ static int rtl_ops_init(struct r8152 *tp)
ops->autosuspend_en = rtl8156_runtime_enable;
ops->change_mtu = rtl8156_change_mtu;
tp->rx_buf_sz = 48 * 1024;
+ r8152_desc_init(tp);
break;
case RTL_VER_14:
@@ -9101,6 +9618,29 @@ static int rtl_ops_init(struct r8152 *tp)
tp->rx_buf_sz = 32 * 1024;
tp->eee_en = true;
tp->eee_adv = MDIO_EEE_1000T | MDIO_EEE_100TX;
+ r8152_desc_init(tp);
+ break;
+
+ case RTL_VER_16:
+ tp->eee_en = true;
+ tp->eee_adv = MDIO_EEE_1000T | MDIO_EEE_100TX;
+ tp->eee_adv2 = MDIO_EEE_2_5GT | MDIO_EEE_5GT;
+ ops->init = r8156_init;
+ ops->enable = rtl8156_enable;
+ ops->disable = rtl8153_disable;
+ ops->up = rtl8156_up;
+ ops->down = rtl8156_down;
+ ops->unload = rtl8153_unload;
+ ops->eee_get = r8153_get_eee;
+ ops->eee_set = r8152_set_eee;
+ ops->in_nway = rtl8153_in_nway;
+ ops->hw_phy_cfg = r8157_hw_phy_cfg;
+ ops->autosuspend_en = rtl8157_runtime_enable;
+ ops->change_mtu = rtl8156_change_mtu;
+ tp->rx_buf_sz = 32 * 1024;
+ tp->support_2500full = 1;
+ tp->support_5000full = 1;
+ r8157_desc_init(tp);
break;
default:
@@ -9253,6 +9793,9 @@ static u8 __rtl_get_hw_ver(struct usb_device *udev)
case 0x7420:
version = RTL_VER_15;
break;
+ case 0x1030:
+ version = RTL_VER_16;
+ break;
default:
version = RTL_VER_UNKNOWN;
dev_info(&udev->dev, "Unknown version 0x%04x\n", ocp_data);
@@ -9404,6 +9947,7 @@ static int rtl8152_probe_once(struct usb_interface *intf,
case RTL_VER_12:
case RTL_VER_13:
case RTL_VER_15:
+ case RTL_VER_16:
netdev->max_mtu = size_to_mtu(16 * 1024);
break;
case RTL_VER_01:
@@ -9563,6 +10107,7 @@ static const struct usb_device_id rtl8152_table[] = {
{ USB_DEVICE(VENDOR_ID_REALTEK, 0x8153) },
{ USB_DEVICE(VENDOR_ID_REALTEK, 0x8155) },
{ USB_DEVICE(VENDOR_ID_REALTEK, 0x8156) },
+ { USB_DEVICE(VENDOR_ID_REALTEK, 0x8157) },
/* Microsoft */
{ USB_DEVICE(VENDOR_ID_MICROSOFT, 0x07ab) },
--
2.47.3
^ permalink raw reply related
* [PATCH net-next v7 1/2] r8152: Add support for 5Gbit Link Speeds and EEE
From: Birger Koblitz @ 2026-04-04 7:57 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni
Cc: linux-usb, netdev, linux-kernel, Chih Kai Hsu, Birger Koblitz
In-Reply-To: <20260404-rtl8157_next-v7-0-039121318f23@birger-koblitz.de>
The RTL8157 supports 5GBit Link speeds. Add support for this speed
in the setup and setting/getting through ethtool. Also add 5GBit EEE.
Add functionality for setup and ethtool get/set methods.
Signed-off-by: Birger Koblitz <mail@birger-koblitz.de>
---
drivers/net/usb/r8152.c | 100 +++++++++++++++++++++++++++++++++++++++---------
1 file changed, 82 insertions(+), 18 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 1765da5bd6cfbefb57d02d4f22b6d8498ed91e79..c81bb788ac3424bd22108e83a20ff51e21c23f60 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -606,6 +606,7 @@ enum spd_duplex {
FORCE_100M_FULL,
FORCE_1000M_FULL,
NWAY_2500M_FULL,
+ NWAY_5000M_FULL,
};
/* OCP_ALDPS_CONFIG */
@@ -727,6 +728,7 @@ enum spd_duplex {
#define BP4_SUPER_ONLY 0x1578 /* RTL_VER_04 only */
enum rtl_register_content {
+ _5000bps = BIT(12),
_2500bps = BIT(10),
_1250bps = BIT(9),
_500bps = BIT(8),
@@ -740,6 +742,7 @@ enum rtl_register_content {
};
#define is_speed_2500(_speed) (((_speed) & (_2500bps | LINK_STATUS)) == (_2500bps | LINK_STATUS))
+#define is_speed_5000(_speed) (((_speed) & (_5000bps | LINK_STATUS)) == (_5000bps | LINK_STATUS))
#define is_flow_control(_speed) (((_speed) & (_tx_flow | _rx_flow)) == (_tx_flow | _rx_flow))
#define RTL8152_MAX_TX 4
@@ -946,6 +949,7 @@ struct r8152 {
unsigned int pipe_in, pipe_out, pipe_intr, pipe_ctrl_in, pipe_ctrl_out;
u32 support_2500full:1;
+ u32 support_5000full:1;
u32 lenovo_macpassthru:1;
u32 dell_tb_rx_agg_bug:1;
u16 ocp_base;
@@ -1196,6 +1200,7 @@ enum tx_csum_stat {
#define RTL_ADVERTISED_1000_HALF BIT(4)
#define RTL_ADVERTISED_1000_FULL BIT(5)
#define RTL_ADVERTISED_2500_FULL BIT(6)
+#define RTL_ADVERTISED_5000_FULL BIT(7)
/* Maximum number of multicast addresses to filter (vs. Rx-all-multicast).
* The RTL chips use a 64 element hash table based on the Ethernet CRC.
@@ -5421,12 +5426,23 @@ static void r8153_eee_en(struct r8152 *tp, bool enable)
static void r8156_eee_en(struct r8152 *tp, bool enable)
{
+ u16 config;
+
r8153_eee_en(tp, enable);
+ config = ocp_reg_read(tp, OCP_EEE_ADV2);
+
if (enable && (tp->eee_adv2 & MDIO_EEE_2_5GT))
- ocp_reg_set_bits(tp, OCP_EEE_ADV2, MDIO_EEE_2_5GT);
+ config |= MDIO_EEE_2_5GT;
else
- ocp_reg_clr_bits(tp, OCP_EEE_ADV2, MDIO_EEE_2_5GT);
+ config &= ~MDIO_EEE_2_5GT;
+
+ if (enable && (tp->eee_adv2 & MDIO_EEE_5GT))
+ config |= MDIO_EEE_5GT;
+ else
+ config &= ~MDIO_EEE_5GT;
+
+ ocp_reg_write(tp, OCP_EEE_ADV2, config);
}
static void rtl_eee_enable(struct r8152 *tp, bool enable)
@@ -6190,9 +6206,13 @@ static int rtl8152_set_speed(struct r8152 *tp, u8 autoneg, u32 speed, u8 duplex,
if (tp->support_2500full)
support |= RTL_ADVERTISED_2500_FULL;
+
+ if (tp->support_5000full)
+ support |= RTL_ADVERTISED_5000_FULL;
}
- if (!(advertising & support))
+ advertising &= support;
+ if (!advertising)
return -EINVAL;
orig = r8152_mdio_read(tp, MII_ADVERTISE);
@@ -6235,15 +6255,20 @@ static int rtl8152_set_speed(struct r8152 *tp, u8 autoneg, u32 speed, u8 duplex,
r8152_mdio_write(tp, MII_CTRL1000, new1);
}
- if (tp->support_2500full) {
+ if (tp->support_2500full || tp->support_5000full) {
orig = ocp_reg_read(tp, OCP_10GBT_CTRL);
- new1 = orig & ~MDIO_AN_10GBT_CTRL_ADV2_5G;
+ new1 = orig & ~(MDIO_AN_10GBT_CTRL_ADV2_5G | MDIO_AN_10GBT_CTRL_ADV5G);
if (advertising & RTL_ADVERTISED_2500_FULL) {
new1 |= MDIO_AN_10GBT_CTRL_ADV2_5G;
tp->ups_info.speed_duplex = NWAY_2500M_FULL;
}
+ if (advertising & RTL_ADVERTISED_5000_FULL) {
+ new1 |= MDIO_AN_10GBT_CTRL_ADV5G;
+ tp->ups_info.speed_duplex = NWAY_5000M_FULL;
+ }
+
if (orig != new1)
ocp_reg_write(tp, OCP_10GBT_CTRL, new1);
}
@@ -8220,17 +8245,38 @@ int rtl8152_get_link_ksettings(struct net_device *netdev,
linkmode_mod_bit(ETHTOOL_LINK_MODE_2500baseT_Full_BIT,
cmd->link_modes.supported, tp->support_2500full);
- if (tp->support_2500full) {
- linkmode_mod_bit(ETHTOOL_LINK_MODE_2500baseT_Full_BIT,
- cmd->link_modes.advertising,
- ocp_reg_read(tp, OCP_10GBT_CTRL) & MDIO_AN_10GBT_CTRL_ADV2_5G);
+ linkmode_mod_bit(ETHTOOL_LINK_MODE_5000baseT_Full_BIT,
+ cmd->link_modes.supported, tp->support_5000full);
+
+ if (tp->support_2500full || tp->support_5000full) {
+ u16 ocp_10gbt_ctrl = ocp_reg_read(tp, OCP_10GBT_CTRL);
+ u16 ocp_10gbt_stat = ocp_reg_read(tp, OCP_10GBT_STAT);
+
+ if (tp->support_2500full) {
+ linkmode_mod_bit(ETHTOOL_LINK_MODE_2500baseT_Full_BIT,
+ cmd->link_modes.advertising,
+ ocp_10gbt_ctrl & MDIO_AN_10GBT_CTRL_ADV2_5G);
+
+ linkmode_mod_bit(ETHTOOL_LINK_MODE_2500baseT_Full_BIT,
+ cmd->link_modes.lp_advertising,
+ ocp_10gbt_stat & MDIO_AN_10GBT_STAT_LP2_5G);
+
+ if (is_speed_2500(rtl8152_get_speed(tp)))
+ cmd->base.speed = SPEED_2500;
+ }
+
+ if (tp->support_5000full) {
+ linkmode_mod_bit(ETHTOOL_LINK_MODE_5000baseT_Full_BIT,
+ cmd->link_modes.advertising,
+ ocp_10gbt_ctrl & MDIO_AN_10GBT_CTRL_ADV5G);
- linkmode_mod_bit(ETHTOOL_LINK_MODE_2500baseT_Full_BIT,
- cmd->link_modes.lp_advertising,
- ocp_reg_read(tp, OCP_10GBT_STAT) & MDIO_AN_10GBT_STAT_LP2_5G);
+ linkmode_mod_bit(ETHTOOL_LINK_MODE_5000baseT_Full_BIT,
+ cmd->link_modes.lp_advertising,
+ ocp_10gbt_stat & MDIO_AN_10GBT_STAT_LP5G);
- if (is_speed_2500(rtl8152_get_speed(tp)))
- cmd->base.speed = SPEED_2500;
+ if (is_speed_5000(rtl8152_get_speed(tp)))
+ cmd->base.speed = SPEED_5000;
+ }
}
mutex_unlock(&tp->control);
@@ -8280,6 +8326,10 @@ static int rtl8152_set_link_ksettings(struct net_device *dev,
cmd->link_modes.advertising))
advertising |= RTL_ADVERTISED_2500_FULL;
+ if (test_bit(ETHTOOL_LINK_MODE_5000baseT_Full_BIT,
+ cmd->link_modes.advertising))
+ advertising |= RTL_ADVERTISED_5000_FULL;
+
mutex_lock(&tp->control);
ret = rtl8152_set_speed(tp, cmd->base.autoneg, cmd->base.speed,
@@ -8397,7 +8447,7 @@ static int r8152_set_eee(struct r8152 *tp, struct ethtool_keee *eee)
tp->eee_en = eee->eee_enabled;
tp->eee_adv = val;
- if (tp->support_2500full) {
+ if (tp->support_2500full || tp->support_5000full) {
val = linkmode_to_mii_eee_cap2_t(eee->advertised);
tp->eee_adv2 = val;
}
@@ -8421,19 +8471,28 @@ static int r8153_get_eee(struct r8152 *tp, struct ethtool_keee *eee)
val = ocp_reg_read(tp, OCP_EEE_LPABLE);
mii_eee_cap1_mod_linkmode_t(eee->lp_advertised, val);
- if (tp->support_2500full) {
- linkmode_set_bit(ETHTOOL_LINK_MODE_2500baseT_Full_BIT, eee->supported);
-
+ if (tp->support_2500full || tp->support_5000full) {
val = ocp_reg_read(tp, OCP_EEE_ADV2);
mii_eee_cap2_mod_linkmode_adv_t(eee->advertised, val);
val = ocp_reg_read(tp, OCP_EEE_LPABLE2);
mii_eee_cap2_mod_linkmode_adv_t(eee->lp_advertised, val);
+ }
+
+ if (tp->support_2500full) {
+ linkmode_set_bit(ETHTOOL_LINK_MODE_2500baseT_Full_BIT, eee->supported);
if (speed & _2500bps)
linkmode_set_bit(ETHTOOL_LINK_MODE_2500baseT_Full_BIT, common);
}
+ if (tp->support_5000full) {
+ linkmode_set_bit(ETHTOOL_LINK_MODE_5000baseT_Full_BIT, eee->supported);
+
+ if (speed & _5000bps)
+ linkmode_set_bit(ETHTOOL_LINK_MODE_5000baseT_Full_BIT, common);
+ }
+
eee->eee_enabled = tp->eee_en;
if (speed & _1000bps)
@@ -9374,6 +9433,11 @@ static int rtl8152_probe_once(struct usb_interface *intf,
} else {
tp->speed = SPEED_1000;
}
+ if (tp->support_5000full &&
+ tp->udev->speed >= USB_SPEED_SUPER) {
+ tp->speed = SPEED_5000;
+ tp->advertising |= RTL_ADVERTISED_5000_FULL;
+ }
tp->advertising |= RTL_ADVERTISED_1000_FULL;
}
tp->duplex = DUPLEX_FULL;
--
2.47.3
^ permalink raw reply related
* [PATCH net-next v7 0/2] r8152: Add support for the RTL8157 5Gbit USB Ethernet chip
From: Birger Koblitz @ 2026-04-04 7:57 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni
Cc: linux-usb, netdev, linux-kernel, Chih Kai Hsu, Birger Koblitz
Add support for the RTL8157, which is a 5GBit USB-Ethernet adapter
chip in the RTL815x family of chips.
The RTL8157 uses a different frame descriptor format, and different
SRAM/ADV access methods, plus offers 5GBit/s Ethernet, so support for these
features is added in addition to chip initialization and configuration.
The module was tested with an OEM RTL8157 USB adapter:
[25758.328238] usb 4-1: new SuperSpeed Plus Gen 2x1 USB device number 2 using xhci_hcd
[25758.345565] usb 4-1: New USB device found, idVendor=0bda, idProduct=8157, bcdDevice=30.00
[25758.345585] usb 4-1: New USB device strings: Mfr=1, Product=2, SerialNumber=7
[25758.345593] usb 4-1: Product: USB 10/100/1G/2.5G/5G LAN
[25758.345599] usb 4-1: Manufacturer: Realtek
[25758.345605] usb 4-1: SerialNumber: 000300E04C68xxxx
[25758.534241] r8152-cfgselector 4-1: reset SuperSpeed Plus Gen 2x1 USB device number 2 using xhci_hcd
[25758.603511] r8152 4-1:1.0: skip request firmware
[25758.653351] r8152 4-1:1.0 eth0: v1.12.13
[25758.689271] r8152 4-1:1.0 enx00e04c68xxxx: renamed from eth0
[25763.271682] r8152 4-1:1.0 enx00e04c68xxxx: carrier on
The RTL8157 adapter was tested against an AQC107 PCIe-card supporting
10GBit/s and an RTL8126 5Gbit PCIe-card supporting 5GBit/s for
performance, link speed and EEE negotiation. Using USB3.2 Gen 1 with
the RTL8157 USB adapter and running iperf3 against the AQC107 PCIe
card resulted in 3.47 Gbits/sec, whereas using USB3.2 Gen2 resulted
in 4.70 Gbits/sec, speeds against the RTL8126-card were the same.
As the code integrates the RTL8157-specific code with existing RTL8156 code
in order to improve code maintainability (instead of adding RTL8157-specific
functions duplicaing most of the RTL8156 code), regression tests were done
with an Edimax EU-4307 V1.0 USB-Ethernet adapter with RTL8156.
The code is based on the out-of-tree r8152 driver published by Realtek under
the GPL.
This patch is on top of linux-next as the code re-uses the 2.5 Gbit EEE
recently added in r8152.c.
Signed-off-by: Birger Koblitz <mail@birger-koblitz.de>
---
Changes in v7:
- Rebased to latest net-next
- Link to v6: https://lore.kernel.org/r/20260402-rtl8157_next-v6-0-a9b77c0931ef@birger-koblitz.de
Changes in v6:
- Rebased to net-next
- Fixed typos: ocp_10bt -> ocp_10gbt
- Link to v5: https://lore.kernel.org/r/20260331-rtl8157_next-v5-0-deb3095f8380@birger-koblitz.de
Changes in v5:
- Filter advertising in rtl8152_set_speed() to prevent incorrect speeds
- Prevent double USB transfers in rtl8152_get_link_ksettings()
- Make sure OCP_EEE_ADV2 and OCP_EEE_LPABLE2 are read if a device
supports 5GBit but not 2.5Gbit
- Fix rtl8157_runtime_enable() to follow the behavior of
rtl8156_runtime_enable()
- Prevent call to r8153_u2p3en in rtl8156_up() for RTL8157
- Fix rtl8157_unload() to disable interrupt mitigation
- Link to v4: https://lore.kernel.org/r/20260324-rtl8157_next-v4-0-034312b12de5@birger-koblitz.de
Changes in v4:
- Fix return type of ocp_adv_read()
- In r8152_tx_csum() use tx_desc
- Use TCPHO_MAX_2 for RTL8157 in rtl8152_features_check()
- Include RTL_VER_12 in RTL8156B chip versions in rtl8156_init()
- Remove inline keyword from rx_agg_align and tx_agg_align
- Link to v3: https://lore.kernel.org/r/20260320-rtl8157_next-v3-0-1aefeca7fda7@birger-koblitz.de
Changes in v3:
- Apply reverse Christmas tree order for declarations
- Use poll_timeout_us for register polling
- In rtl8156_enable(), fix version comparison: tp->version >= RTL_VER_16
- Correct error handling of r8153_phy_status in r8157_hw_phy_cfg()
- Fix use of ocp_word_clr_bits for PLA_MCU_SPDWN_EN register
- Link to v2: https://lore.kernel.org/r/20260317-rtl8157_next-v2-0-10ea1fa488d1@birger-koblitz.de
Changes in v2:
- Fixed missing initialization of ret value in wait_cmd_ready()
- Combine all parts with RTL8157-specific code to avoid undefined functions
- Link to v1: https://lore.kernel.org/r/20260314-rtl8157_next-v1-0-9ba77b428afd@birger-koblitz.de
---
Birger Koblitz (2):
r8152: Add support for 5Gbit Link Speeds and EEE
r8152: Add support for the RTL8157 hardware
drivers/net/usb/r8152.c | 1013 +++++++++++++++++++++++++++++++++++++----------
1 file changed, 811 insertions(+), 202 deletions(-)
---
base-commit: 3741f8fa004bf598cd5032b0ff240984332d6f05
change-id: 20260314-rtl8157_next-ae18683eb4fa
Best regards,
--
Birger Koblitz <mail@birger-koblitz.de>
^ permalink raw reply
* Re: [PATCH v7 1/2] dt-bindings: usb: Add Genesys Logic GL3590 hub
From: Krzysztof Kozlowski @ 2026-04-04 7:06 UTC (permalink / raw)
To: Swati Agarwal
Cc: Greg Kroah-Hartman, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Icenowy Zheng, Matthias Kaehlcke, Alexey Charkov,
Dmitry Baryshkov, Mike Looijmans, Pin-yen Lin,
J . Neuschäfer, Chaoyi Chen, Krzysztof Kozlowski, linux-usb,
devicetree, linux-kernel
In-Reply-To: <20260403100435.3477729-2-swati.agarwal@oss.qualcomm.com>
On Fri, Apr 03, 2026 at 03:34:34PM +0530, Swati Agarwal wrote:
> Add the binding for the USB3.2 Genesys Logic GL3590 hub.
> GL3590 hub requires 1.2V and 3.3V supplies for operation.
>
> Signed-off-by: Swati Agarwal <swati.agarwal@oss.qualcomm.com>
> ---
> .../bindings/usb/genesys,gl850g.yaml | 18 ++++++++++++++++++
> 1 file changed, 18 insertions(+)
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Some queries on eHCI/xHCI/Thunderbolt and dwc2/dwc3
From: Ajay Garg @ 2026-04-04 6:56 UTC (permalink / raw)
To: linux-usb
Hi everyone.
I have been gaining an architectural understanding on how host/gadget
usb-drivers inter-operate with USB-2 / USB-3 / USB-4 (host-side) and
synopsys-DWC controllers (gadget-side).
Following have been my understandings :
a)
For host-side, eHCI does not require / use dwc2, but xHCI mandatorily
needs dwc3.
Am I correct?
If yes, how is hardware-specific actions taken care by eHCI alone
(since eHCI is hardware-agnostic)?
Is it that USB-2 PHY-registers are already a part of eHCI
MMIO-registers themselves (thus not requiring any hardware-specific
actions on the PHY side)?
b)
For host-side, does thunderbolt driver require any of dwc3 / upcoming-dwc4?
c)
For gadget-side, dwc2 and dwc3 are enough for USB-2 / USB-3.
Am I correct?
d)
For gadget-side, would USB-4 require an upcoming-dwc4? Or will dwc3 be
modified? Or is there another plan in the pipeline?
Will be grateful for light on the above from kernel/synopsys experts :)
Many thanks in advance !
Thanks and Regards,
Ajay
^ permalink raw reply
* Re: [PATCH net-next v6 0/2] r8152: Add support for the RTL8157 5Gbit USB Ethernet chip
From: Birger Koblitz @ 2026-04-04 6:47 UTC (permalink / raw)
To: Greg KH
Cc: Jakub Kicinski, Andrew Lunn, David S. Miller, Eric Dumazet,
Paolo Abeni, linux-usb, netdev, linux-kernel, Chih Kai Hsu
In-Reply-To: <2026040421-kite-ethanol-2e28@gregkh>
On 04/04/2026 08:27, Greg KH wrote:
> On Sat, Apr 04, 2026 at 05:54:43AM +0200, Birger Koblitz wrote:
>> On 04/04/2026 01:06, Jakub Kicinski wrote:
>>> On Thu, 02 Apr 2026 10:28:12 +0200 Birger Koblitz wrote:
>>>> Add support for the RTL8157, which is a 5GBit USB-Ethernet adapter
>>>> chip in the RTL815x family of chips.
>>>
>>> no longer applies, please rebase & repost
>> It looks like you are letting me play out the story of the hare and the
>> hedgehog. If there is no interest in this patch series or you would like
>> it to look different, please let me know instead of playing games.
>
> "Does not apply" is not a game, you just need to rebase and resubmit as
> others are also doing work on the same driver at the same time, so there
> can be some conflicts that it is up to the submitter to resolve.
>
> This is normal kernel development, has always been this way.
>
Thanks for the feedback, Greg!
the underlying issue is that parts of the patch I submitted are now also
submitted by others, and that gets fast-tracked. This has now happened twice,
and I am being told every time to re-submit, without efforts to coordinate
this, or hints that this pattern may stop. This has somewhat made me loose
trust in the process.
I'll nevertheless rebase and resend, and see what happens next.
Birger
^ permalink raw reply
* Re: [PATCH net-next v6 0/2] r8152: Add support for the RTL8157 5Gbit USB Ethernet chip
From: Greg KH @ 2026-04-04 6:27 UTC (permalink / raw)
To: Birger Koblitz
Cc: Jakub Kicinski, Andrew Lunn, David S. Miller, Eric Dumazet,
Paolo Abeni, linux-usb, netdev, linux-kernel, Chih Kai Hsu
In-Reply-To: <741bde66-45b7-49e4-88be-7fb1ca8a92df@birger-koblitz.de>
On Sat, Apr 04, 2026 at 05:54:43AM +0200, Birger Koblitz wrote:
> On 04/04/2026 01:06, Jakub Kicinski wrote:
> > On Thu, 02 Apr 2026 10:28:12 +0200 Birger Koblitz wrote:
> > > Add support for the RTL8157, which is a 5GBit USB-Ethernet adapter
> > > chip in the RTL815x family of chips.
> >
> > no longer applies, please rebase & repost
> It looks like you are letting me play out the story of the hare and the
> hedgehog. If there is no interest in this patch series or you would like
> it to look different, please let me know instead of playing games.
"Does not apply" is not a game, you just need to rebase and resubmit as
others are also doing work on the same driver at the same time, so there
can be some conflicts that it is up to the submitter to resolve.
This is normal kernel development, has always been this way.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH net-next v6 0/2] r8152: Add support for the RTL8157 5Gbit USB Ethernet chip
From: Birger Koblitz @ 2026-04-04 3:54 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Paolo Abeni,
linux-usb, netdev, linux-kernel, Chih Kai Hsu
In-Reply-To: <20260403160608.04f2408b@kernel.org>
On 04/04/2026 01:06, Jakub Kicinski wrote:
> On Thu, 02 Apr 2026 10:28:12 +0200 Birger Koblitz wrote:
>> Add support for the RTL8157, which is a 5GBit USB-Ethernet adapter
>> chip in the RTL815x family of chips.
>
> no longer applies, please rebase & repost
It looks like you are letting me play out the story of the hare and the
hedgehog. If there is no interest in this patch series or you would like
it to look different, please let me know instead of playing games.
Birger
^ permalink raw reply
* Re: [RFC PATCH 1/2] xhci: prevent automatic endpoint restart after stall or error
From: stern @ 2026-04-04 1:54 UTC (permalink / raw)
To: Thinh Nguyen
Cc: Mathias Nyman, linux-usb@vger.kernel.org, michal.pecio@gmail.com,
oneukum@suse.com, niklas.neronin@linux.intel.com
In-Reply-To: <20260404011530.aukxllvizvmc3f3x@synopsys.com>
On Sat, Apr 04, 2026 at 01:15:52AM +0000, Thinh Nguyen wrote:
> > > How about this:
> > >
> > > Introduce a halted flag the following conditions:
> > >
> > > * Introduce the halted flag in usb_host_endpoint
> > > * The halted flag must be implemented as a bit in a unsigned long so
> > > we can use atomic bit operation
> >
> > I don't see why it needs to use atomic operations. Unless you're
> > thinking that we might want to add other bitflags into the same unsigned
> > long?
>
> Now that I think about it again, it's not needed if we have the
> requirement for clearing the flag only after usb_reset_endpoint.
>
> >
> > > * Only the HCD may set the halted flag, and only upon checking the
> > > first URB completing with a halted status
> >
> > Every status other than 0 should mean that the endpoint's queue is
> > halted. But not all statuses require a clear-halt or reset-endpoint to
> > recover. For instance, a short transfer when the URB_SHORT_NOT_OK flag
> > is set.
>
> It seems we're using the "halted" flag for different things. The halted
> flag to me is the endpoint's state and rather than the endpoint queue
> state. That is, if the endpoint is halted, there's an error that was
> reported on the pipe. So, an -ECONNRESET would not cause a halted
> endpoint.
>
> >
> > Why do you want the HCD to set the flag instead of
> > usb_hcd_giveback_urb()? Just one central place is simpler than in every
> > HCD.
>
> I'm just thinking in term of whose role to return the pending URBs.
> Typically the HCD handles when to give back URBs. If the HCD were to
> handle giving back pending URBs due to halted endpoint, then it should
> be the one to set the halted flag. However, if the core tracks and does
> both setting and clearing of the halted flag, then the core should
> handle canceling the URBs. As you said, if we can shift the burden to
> the core, that would help keep the flow consistent and centralized.
>
> >
> > > * Only the USB core may clear the halted flag, and only after
> > > usb_reset_endpoint returns (this makes sure the HCD drained and reset
> > > the endpoint before the flag is cleared and new URBs are accepted)
> > > * The usb_reset_endpoint must be called after clear-halt, SetInterface,
> > > and SetConfiguration.
> >
> > That's easy to do just by adding it into the appropriate core routines.
>
> Yes.
>
> >
> > > * The USB core will not attempt to unlink pending URBs due to halted
> > > condition
> > > * The HCD is responsible for completing or canceling queued URBs
> > > when the halted flag is set. Cancelled and newly submitted URBs will
> > > be returned with -EPIPE as long as the halted flag is set
> >
> > Why make the HCD responsible for draining the queue? It's like setting
> > the halted flag; one central place is simpler and less error-prone than
> > lots of separate places.
> >
> > For newly submitted URBs, should the submission fail with -EPIPE, or
> > should the submission succeed and then the URB complete with -EPIPE?
> > The first is simpler, but drivers probably aren't prepared for it -- it
> > would mean adding error handling to the submission code as well as to
> > the completion handler code.
> >
> > (Actually, that wouldn't matter unless the driver was queuing up
> > multiple URBs, in which case it should be prepared to handle submission
> > errors in the middle.)
>
> I didn't think about failing immediately on submission because we would
> need to audit every class driver for that. Perhaps the core can
> intercept the URBs and immediately schedule a completion handler with
> the updated URB's status?
>
> >
> > > * The class driver is responsible to check the halted flag to
> > > determine whether to initiate error recovery via usb_clear_halt
> > >
> > > I'm trying to keep a clear separation of responsibilities between HCD
> > > and the USB core. Also, I try to keep the halted flag more closely match
> > > the state of the endpoint.
> > >
> > > Let me know what you think?
> >
> > Making the flag match the endpoint state is a good idea. But there is
> > some ambiguity: Do you mean the state in the device, or the state in the
> > HC hardware, or the state in the HCD? After all, these aren't always
> > the same. For instance, unlinking an URB won't affect the device's
> > state but it will affect the state on the host side.
> >
>
> The HCD state. If we can let the core manage the halted state, then here
> are the points where the halted state is updated (hopefully I didn't
> miss any other ones):
>
> Endpoint is halted (reported by HCD):
> * URB returned with -EPROTO or -EPIPE
>
> Endpoint is active (updated by the core):
> * SetConfiguration, SetInterface, clear-halt
Hmmm. What did you think of my recent proposal in a message to Michal?
Summarizing:
If the class driver wants to unlink queued URBs when a transaction error
occurs, it has to do so itself in the failed URB's completion handler.
We can make this easier by adding a usb_flush_endpoint_queue() routine
to the core. In the meantime, the HCD ensures that the queue is stopped
before giving back the URB. (Note: -EPIPE, -ENOENT, -ECONNRESET, and
-EREMOTEIO aren't considered to be transaction errors.)
When the completion handler returns, the core will automatically call
usb_clear_halt(), which will also reset the endpoint on the host side
and will restart the queue. This also happens after SetConfiguration
and SetInterface, either explicitly or implicitly.
For -EPIPE (device sent a STALL token), the class driver has to clear
the halt itself. This is because stalls aren't errors; they are an
intentional part of the USB protocol.
-ENOENT and -ECONNRESET (URB was unlinked) and -EREMOTEIO (short packet
received with URB_SHORT_NOT_OK set) are a little trickier. The HCD may
or may not need to stop the queue for an unlink, possibly depending on
whether the URB being unlinked is the active one. When a short packet
is received, the HC hardware may or may not stop its queue. Either way,
the class driver shouldn't need to take any special recovery action; any
necessary actions should be taken automatically by the HCD and the core.
All of this applies only to bulk and interrupt endpoints. Control
endpoints generally need error recovery only on the host side, because
the device resets automatically when it gets a new SETUP packet, and so
the HCD should handle whatever is needed. Isochronous endpoints don't
ever halt and they shouldn't need to be reset when an error occurs.
Overall, this seems simpler than anything else we have discussed.
Alan Stern
^ permalink raw reply
* [usb:usb-testing] BUILD SUCCESS 1df7a7652f032cf1abe1c102a031c2128e24c31d
From: kernel test robot @ 2026-04-04 1:19 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: linux-usb
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-testing
branch HEAD: 1df7a7652f032cf1abe1c102a031c2128e24c31d Revert "dt-bindings: usb: cdns,usb3: document USBSSP controller support"
elapsed time: 730m
configs tested: 242
configs skipped: 2
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc-15.2.0
alpha allyesconfig gcc-15.2.0
alpha defconfig gcc-15.2.0
arc allmodconfig clang-16
arc allnoconfig gcc-15.2.0
arc allyesconfig clang-23
arc defconfig gcc-15.2.0
arc randconfig-001-20260403 gcc-10.5.0
arc randconfig-001-20260404 gcc-15.2.0
arc randconfig-002-20260403 gcc-10.5.0
arc randconfig-002-20260404 gcc-15.2.0
arm allnoconfig gcc-15.2.0
arm allyesconfig clang-16
arm defconfig gcc-15.2.0
arm randconfig-001-20260403 gcc-10.5.0
arm randconfig-001-20260404 gcc-15.2.0
arm randconfig-002-20260403 gcc-10.5.0
arm randconfig-002-20260404 gcc-15.2.0
arm randconfig-003-20260403 gcc-10.5.0
arm randconfig-003-20260404 gcc-15.2.0
arm randconfig-004-20260403 gcc-10.5.0
arm randconfig-004-20260404 gcc-15.2.0
arm64 allmodconfig clang-23
arm64 allnoconfig gcc-15.2.0
arm64 defconfig gcc-15.2.0
arm64 randconfig-001-20260403 gcc-13.4.0
arm64 randconfig-001-20260404 gcc-15.2.0
arm64 randconfig-002-20260403 gcc-13.4.0
arm64 randconfig-002-20260404 gcc-15.2.0
arm64 randconfig-003-20260403 gcc-13.4.0
arm64 randconfig-003-20260404 gcc-15.2.0
arm64 randconfig-004-20260403 gcc-13.4.0
arm64 randconfig-004-20260404 gcc-15.2.0
csky allmodconfig gcc-15.2.0
csky allnoconfig gcc-15.2.0
csky defconfig gcc-15.2.0
csky randconfig-001-20260403 gcc-13.4.0
csky randconfig-001-20260404 gcc-15.2.0
csky randconfig-002-20260403 gcc-13.4.0
csky randconfig-002-20260404 gcc-15.2.0
hexagon allmodconfig gcc-15.2.0
hexagon allnoconfig gcc-15.2.0
hexagon defconfig gcc-15.2.0
hexagon randconfig-001-20260403 clang-23
hexagon randconfig-001-20260404 gcc-15.2.0
hexagon randconfig-002-20260403 clang-23
hexagon randconfig-002-20260404 gcc-15.2.0
i386 allmodconfig clang-20
i386 allnoconfig gcc-15.2.0
i386 allyesconfig clang-20
i386 buildonly-randconfig-001-20260403 gcc-14
i386 buildonly-randconfig-001-20260404 clang-20
i386 buildonly-randconfig-002-20260403 gcc-14
i386 buildonly-randconfig-002-20260404 clang-20
i386 buildonly-randconfig-003-20260403 gcc-14
i386 buildonly-randconfig-003-20260404 clang-20
i386 buildonly-randconfig-004-20260403 gcc-14
i386 buildonly-randconfig-004-20260404 clang-20
i386 buildonly-randconfig-005-20260403 gcc-14
i386 buildonly-randconfig-005-20260404 clang-20
i386 buildonly-randconfig-006-20260403 gcc-14
i386 buildonly-randconfig-006-20260404 clang-20
i386 defconfig gcc-15.2.0
i386 randconfig-001-20260404 clang-20
i386 randconfig-002-20260404 clang-20
i386 randconfig-003-20260404 clang-20
i386 randconfig-004-20260404 clang-20
i386 randconfig-005-20260404 clang-20
i386 randconfig-006-20260404 clang-20
i386 randconfig-007-20260404 clang-20
i386 randconfig-011-20260403 clang-20
i386 randconfig-011-20260404 clang-20
i386 randconfig-012-20260403 clang-20
i386 randconfig-012-20260404 clang-20
i386 randconfig-013-20260403 clang-20
i386 randconfig-013-20260404 clang-20
i386 randconfig-014-20260403 clang-20
i386 randconfig-014-20260404 clang-20
i386 randconfig-015-20260403 clang-20
i386 randconfig-015-20260404 clang-20
i386 randconfig-016-20260403 clang-20
i386 randconfig-016-20260404 clang-20
i386 randconfig-017-20260403 clang-20
i386 randconfig-017-20260404 clang-20
loongarch allmodconfig clang-23
loongarch allnoconfig gcc-15.2.0
loongarch defconfig clang-19
loongarch randconfig-001-20260403 clang-23
loongarch randconfig-001-20260404 gcc-15.2.0
loongarch randconfig-002-20260403 clang-23
loongarch randconfig-002-20260404 gcc-15.2.0
m68k allmodconfig gcc-15.2.0
m68k allnoconfig gcc-15.2.0
m68k allyesconfig clang-16
m68k defconfig clang-19
microblaze allnoconfig gcc-15.2.0
microblaze allyesconfig gcc-15.2.0
microblaze defconfig clang-19
microblaze mmu_defconfig gcc-15.2.0
mips allmodconfig gcc-15.2.0
mips allnoconfig gcc-15.2.0
mips allyesconfig gcc-15.2.0
nios2 allmodconfig clang-23
nios2 allnoconfig clang-23
nios2 defconfig clang-19
nios2 randconfig-001-20260403 clang-23
nios2 randconfig-001-20260404 gcc-15.2.0
nios2 randconfig-002-20260403 clang-23
nios2 randconfig-002-20260404 gcc-15.2.0
openrisc allmodconfig clang-23
openrisc allnoconfig clang-23
openrisc defconfig gcc-15.2.0
parisc allmodconfig gcc-15.2.0
parisc allnoconfig clang-23
parisc allyesconfig clang-19
parisc defconfig gcc-15.2.0
parisc randconfig-001-20260403 gcc-10.5.0
parisc randconfig-001-20260404 gcc-10.5.0
parisc randconfig-002-20260403 gcc-10.5.0
parisc randconfig-002-20260404 gcc-10.5.0
parisc64 defconfig clang-19
powerpc allmodconfig gcc-15.2.0
powerpc allnoconfig clang-23
powerpc mpc83xx_defconfig clang-23
powerpc randconfig-001-20260403 gcc-10.5.0
powerpc randconfig-001-20260404 gcc-10.5.0
powerpc randconfig-002-20260403 gcc-10.5.0
powerpc randconfig-002-20260404 gcc-10.5.0
powerpc storcenter_defconfig gcc-15.2.0
powerpc64 randconfig-001-20260403 gcc-10.5.0
powerpc64 randconfig-001-20260404 gcc-10.5.0
powerpc64 randconfig-002-20260403 gcc-10.5.0
powerpc64 randconfig-002-20260404 gcc-10.5.0
riscv alldefconfig gcc-15.2.0
riscv allmodconfig clang-23
riscv allnoconfig clang-23
riscv allyesconfig clang-16
riscv defconfig gcc-15.2.0
riscv randconfig-001-20260403 clang-23
riscv randconfig-001-20260404 clang-20
riscv randconfig-002-20260403 clang-23
riscv randconfig-002-20260404 clang-20
s390 allmodconfig clang-19
s390 allnoconfig clang-23
s390 allyesconfig gcc-15.2.0
s390 defconfig gcc-15.2.0
s390 randconfig-001-20260403 clang-23
s390 randconfig-001-20260404 clang-20
s390 randconfig-002-20260403 clang-23
s390 randconfig-002-20260404 clang-20
sh allmodconfig gcc-15.2.0
sh allnoconfig clang-23
sh allyesconfig clang-19
sh apsh4ad0a_defconfig gcc-15.2.0
sh defconfig gcc-14
sh randconfig-001-20260403 clang-23
sh randconfig-001-20260404 clang-20
sh randconfig-002-20260403 clang-23
sh randconfig-002-20260404 clang-20
sh se7751_defconfig gcc-15.2.0
sparc allnoconfig clang-23
sparc defconfig gcc-15.2.0
sparc randconfig-001-20260403 clang-20
sparc randconfig-001-20260404 clang-20
sparc randconfig-002-20260403 clang-20
sparc randconfig-002-20260404 clang-20
sparc64 allmodconfig clang-23
sparc64 defconfig gcc-14
sparc64 randconfig-001-20260403 clang-20
sparc64 randconfig-001-20260404 clang-20
sparc64 randconfig-002-20260403 clang-20
sparc64 randconfig-002-20260404 clang-20
um allmodconfig clang-19
um allnoconfig clang-23
um allyesconfig gcc-15.2.0
um defconfig gcc-14
um i386_defconfig gcc-14
um randconfig-001-20260403 clang-20
um randconfig-001-20260404 clang-20
um randconfig-002-20260403 clang-20
um randconfig-002-20260404 clang-20
um x86_64_defconfig gcc-14
x86_64 allmodconfig clang-20
x86_64 allnoconfig clang-23
x86_64 allyesconfig clang-20
x86_64 buildonly-randconfig-001-20260403 clang-20
x86_64 buildonly-randconfig-001-20260404 gcc-13
x86_64 buildonly-randconfig-002-20260403 clang-20
x86_64 buildonly-randconfig-002-20260404 gcc-13
x86_64 buildonly-randconfig-003-20260403 clang-20
x86_64 buildonly-randconfig-003-20260404 gcc-13
x86_64 buildonly-randconfig-004-20260403 clang-20
x86_64 buildonly-randconfig-004-20260404 gcc-13
x86_64 buildonly-randconfig-005-20260403 clang-20
x86_64 buildonly-randconfig-005-20260404 gcc-13
x86_64 buildonly-randconfig-006-20260403 clang-20
x86_64 buildonly-randconfig-006-20260404 gcc-13
x86_64 defconfig gcc-14
x86_64 kexec clang-20
x86_64 randconfig-001-20260404 gcc-14
x86_64 randconfig-002-20260404 gcc-14
x86_64 randconfig-003-20260404 gcc-14
x86_64 randconfig-004-20260404 gcc-14
x86_64 randconfig-005-20260404 gcc-14
x86_64 randconfig-006-20260404 gcc-14
x86_64 randconfig-011-20260403 gcc-14
x86_64 randconfig-011-20260404 gcc-14
x86_64 randconfig-012-20260403 gcc-14
x86_64 randconfig-012-20260404 gcc-14
x86_64 randconfig-013-20260403 gcc-14
x86_64 randconfig-013-20260404 gcc-14
x86_64 randconfig-014-20260403 gcc-14
x86_64 randconfig-014-20260404 gcc-14
x86_64 randconfig-015-20260403 gcc-14
x86_64 randconfig-015-20260404 gcc-14
x86_64 randconfig-016-20260403 gcc-14
x86_64 randconfig-016-20260404 gcc-14
x86_64 randconfig-071-20260403 gcc-14
x86_64 randconfig-071-20260404 gcc-14
x86_64 randconfig-072-20260403 gcc-14
x86_64 randconfig-072-20260404 gcc-14
x86_64 randconfig-073-20260403 gcc-14
x86_64 randconfig-073-20260404 gcc-14
x86_64 randconfig-074-20260403 gcc-14
x86_64 randconfig-074-20260404 gcc-14
x86_64 randconfig-075-20260403 gcc-14
x86_64 randconfig-075-20260404 gcc-14
x86_64 randconfig-076-20260403 gcc-14
x86_64 randconfig-076-20260404 gcc-14
x86_64 rhel-9.4 clang-20
x86_64 rhel-9.4-bpf gcc-14
x86_64 rhel-9.4-func clang-20
x86_64 rhel-9.4-kselftests clang-20
x86_64 rhel-9.4-kunit gcc-14
x86_64 rhel-9.4-ltp gcc-14
x86_64 rhel-9.4-rust clang-20
xtensa allnoconfig clang-23
xtensa allyesconfig clang-23
xtensa randconfig-001-20260403 clang-20
xtensa randconfig-001-20260404 clang-20
xtensa randconfig-002-20260403 clang-20
xtensa randconfig-002-20260404 clang-20
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [RFC PATCH 1/2] xhci: prevent automatic endpoint restart after stall or error
From: Thinh Nguyen @ 2026-04-04 1:15 UTC (permalink / raw)
To: stern@rowland.harvard.edu
Cc: Thinh Nguyen, Mathias Nyman, linux-usb@vger.kernel.org,
michal.pecio@gmail.com, oneukum@suse.com,
niklas.neronin@linux.intel.com
In-Reply-To: <28a00143-85fa-4043-93a0-c2b687ff1bcd@rowland.harvard.edu>
On Thu, Apr 02, 2026, stern@rowland.harvard.edu wrote:
> On Fri, Apr 03, 2026 at 01:59:58AM +0000, Thinh Nguyen wrote:
> > On Wed, Apr 01, 2026, stern@rowland.harvard.edu wrote:
> > > On Thu, Apr 02, 2026 at 01:08:31AM +0300, Mathias Nyman wrote:
> > > > On 3/31/26 18:31, stern@rowland.harvard.edu wrote:
> > > > >
> > > > > How about this instead? We add a "halted" flag to the usb_host_endpoint
> > > > > structure, and the core will set this flag whenever a bulk or interrupt
> > > > > URB gets a status other than 0 (before putting the URB on the bh list).
> > > > > If an URB has one of these statuses, when its completion handler returns
> > > > > the core will unlink all the URBs queued to the same endpoint. Finally,
> > > > > the "halted" flag should be cleared after a completion handler returns
> > > > > if there are no more unlinked URBs still in the queue or URBs waiting on
> > > > > the bh list to be given back.
> > > > >
> > > > > The result of this is that any URB remaining in the queue when the flag
> > > > > is cleared must have been submitted by the class driver _after_ the
> > > > > failing URB's completion handler has run. We can assume the class
> > > > > driver knows what it's doing in this case.
> > > > >
> > > > > The endpoint queue shouldn't be restarted until the "halted" flag is
> > > > > cleared. Either right away, if there are any URBs in the queue, or not
> > > > > until the next URB is submitted. Doing this might require a new HCD
> > > > > callback. (It would also mean the kerneldoc for usb_unlink_urb() would
> > > > > need to be updated, because the endpoint might restart before all the
> > > > > completion handlers for the unlinked URBs have run.)
> > > > >
> > > > > What I'm trying to do here is come up with a single, consistent proposal
> > > > > for exactly when halted endpoint queues should restart. Maybe someone
> > > > > else has a better suggestion.
>
> > How about this:
> >
> > Introduce a halted flag the following conditions:
> >
> > * Introduce the halted flag in usb_host_endpoint
> > * The halted flag must be implemented as a bit in a unsigned long so
> > we can use atomic bit operation
>
> I don't see why it needs to use atomic operations. Unless you're
> thinking that we might want to add other bitflags into the same unsigned
> long?
Now that I think about it again, it's not needed if we have the
requirement for clearing the flag only after usb_reset_endpoint.
>
> > * Only the HCD may set the halted flag, and only upon checking the
> > first URB completing with a halted status
>
> Every status other than 0 should mean that the endpoint's queue is
> halted. But not all statuses require a clear-halt or reset-endpoint to
> recover. For instance, a short transfer when the URB_SHORT_NOT_OK flag
> is set.
It seems we're using the "halted" flag for different things. The halted
flag to me is the endpoint's state and rather than the endpoint queue
state. That is, if the endpoint is halted, there's an error that was
reported on the pipe. So, an -ECONNRESET would not cause a halted
endpoint.
>
> Why do you want the HCD to set the flag instead of
> usb_hcd_giveback_urb()? Just one central place is simpler than in every
> HCD.
I'm just thinking in term of whose role to return the pending URBs.
Typically the HCD handles when to give back URBs. If the HCD were to
handle giving back pending URBs due to halted endpoint, then it should
be the one to set the halted flag. However, if the core tracks and does
both setting and clearing of the halted flag, then the core should
handle canceling the URBs. As you said, if we can shift the burden to
the core, that would help keep the flow consistent and centralized.
>
> > * Only the USB core may clear the halted flag, and only after
> > usb_reset_endpoint returns (this makes sure the HCD drained and reset
> > the endpoint before the flag is cleared and new URBs are accepted)
> > * The usb_reset_endpoint must be called after clear-halt, SetInterface,
> > and SetConfiguration.
>
> That's easy to do just by adding it into the appropriate core routines.
Yes.
>
> > * The USB core will not attempt to unlink pending URBs due to halted
> > condition
> > * The HCD is responsible for completing or canceling queued URBs
> > when the halted flag is set. Cancelled and newly submitted URBs will
> > be returned with -EPIPE as long as the halted flag is set
>
> Why make the HCD responsible for draining the queue? It's like setting
> the halted flag; one central place is simpler and less error-prone than
> lots of separate places.
>
> For newly submitted URBs, should the submission fail with -EPIPE, or
> should the submission succeed and then the URB complete with -EPIPE?
> The first is simpler, but drivers probably aren't prepared for it -- it
> would mean adding error handling to the submission code as well as to
> the completion handler code.
>
> (Actually, that wouldn't matter unless the driver was queuing up
> multiple URBs, in which case it should be prepared to handle submission
> errors in the middle.)
I didn't think about failing immediately on submission because we would
need to audit every class driver for that. Perhaps the core can
intercept the URBs and immediately schedule a completion handler with
the updated URB's status?
>
> > * The class driver is responsible to check the halted flag to
> > determine whether to initiate error recovery via usb_clear_halt
> >
> > I'm trying to keep a clear separation of responsibilities between HCD
> > and the USB core. Also, I try to keep the halted flag more closely match
> > the state of the endpoint.
> >
> > Let me know what you think?
>
> Making the flag match the endpoint state is a good idea. But there is
> some ambiguity: Do you mean the state in the device, or the state in the
> HC hardware, or the state in the HCD? After all, these aren't always
> the same. For instance, unlinking an URB won't affect the device's
> state but it will affect the state on the host side.
>
The HCD state. If we can let the core manage the halted state, then here
are the points where the halted state is updated (hopefully I didn't
miss any other ones):
Endpoint is halted (reported by HCD):
* URB returned with -EPROTO or -EPIPE
Endpoint is active (updated by the core):
* SetConfiguration, SetInterface, clear-halt
Thanks,
Thinh
ps. I'll be out of town next week. Apologies if my response will be
delayed...
^ permalink raw reply
* [PATCH v4 8/9] driver core: Replace dev->of_node_reused with dev_of_node_reused()
From: Douglas Anderson @ 2026-04-04 0:05 UTC (permalink / raw)
To: Greg Kroah-Hartman, Rafael J . Wysocki, Danilo Krummrich,
Alan Stern
Cc: Saravana Kannan, Christoph Hellwig, Eric Dumazet, Johan Hovold,
Leon Romanovsky, Alexander Lobakin, Alexey Kardashevskiy,
Robin Murphy, Douglas Anderson, Mark Brown, alexander.stein,
andrew, andrew, andriy.shevchenko, bhelgaas, brgl, davem,
devicetree, driver-core, hkallweit1, jirislaby, joel, kees, kuba,
lgirdwood, linux-arm-kernel, linux-aspeed, linux-kernel,
linux-pci, linux-serial, linux-usb, linux, mani, netdev, pabeni,
robh
In-Reply-To: <20260404000644.522677-1-dianders@chromium.org>
In C, bitfields are not necessarily safe to modify from multiple
threads without locking. Switch "of_node_reused" over to the "flags"
field so modifications are safe.
Cc: Johan Hovold <johan@kernel.org>
Acked-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
---
Not fixing any known bugs; problem is theoretical and found by code
inspection. Change is done somewhat manually and only lightly tested
(mostly compile-time tested).
Changes in v4:
- Use accessor functions for flags
Changes in v3:
- New
drivers/base/core.c | 2 +-
drivers/base/pinctrl.c | 2 +-
drivers/base/platform.c | 2 +-
drivers/net/pcs/pcs-xpcs-plat.c | 2 +-
drivers/of/device.c | 6 +++---
drivers/pci/of.c | 2 +-
drivers/pci/pwrctrl/core.c | 2 +-
drivers/regulator/bq257xx-regulator.c | 2 +-
drivers/regulator/rk808-regulator.c | 2 +-
drivers/tty/serial/serial_base_bus.c | 2 +-
drivers/usb/gadget/udc/aspeed-vhub/dev.c | 2 +-
include/linux/device.h | 7 ++++---
12 files changed, 17 insertions(+), 16 deletions(-)
diff --git a/drivers/base/core.c b/drivers/base/core.c
index 531f02a5469a..f12f3b53b4d0 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -5281,7 +5281,7 @@ void device_set_of_node_from_dev(struct device *dev, const struct device *dev2)
{
of_node_put(dev->of_node);
dev->of_node = of_node_get(dev2->of_node);
- dev->of_node_reused = true;
+ dev_set_of_node_reused(dev);
}
EXPORT_SYMBOL_GPL(device_set_of_node_from_dev);
diff --git a/drivers/base/pinctrl.c b/drivers/base/pinctrl.c
index 6e250272c843..0bbc83231234 100644
--- a/drivers/base/pinctrl.c
+++ b/drivers/base/pinctrl.c
@@ -24,7 +24,7 @@ int pinctrl_bind_pins(struct device *dev)
{
int ret;
- if (dev->of_node_reused)
+ if (dev_of_node_reused(dev))
return 0;
dev->pins = devm_kzalloc(dev, sizeof(*(dev->pins)), GFP_KERNEL);
diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index d44591d52e36..199e6fb25770 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -856,7 +856,7 @@ struct platform_device *platform_device_register_full(
pdev->dev.parent = pdevinfo->parent;
pdev->dev.fwnode = pdevinfo->fwnode;
pdev->dev.of_node = of_node_get(to_of_node(pdev->dev.fwnode));
- pdev->dev.of_node_reused = pdevinfo->of_node_reused;
+ dev_assign_of_node_reused(&pdev->dev, pdevinfo->of_node_reused);
if (pdevinfo->dma_mask) {
pdev->platform_dma_mask = pdevinfo->dma_mask;
diff --git a/drivers/net/pcs/pcs-xpcs-plat.c b/drivers/net/pcs/pcs-xpcs-plat.c
index b8c48f9effbf..f4b1b8246ce9 100644
--- a/drivers/net/pcs/pcs-xpcs-plat.c
+++ b/drivers/net/pcs/pcs-xpcs-plat.c
@@ -349,7 +349,7 @@ static int xpcs_plat_init_dev(struct dw_xpcs_plat *pxpcs)
* up later. Make sure DD-core is aware of the OF-node being re-used.
*/
device_set_node(&mdiodev->dev, fwnode_handle_get(dev_fwnode(dev)));
- mdiodev->dev.of_node_reused = true;
+ dev_set_of_node_reused(&mdiodev->dev);
/* Pass the data further so the DW XPCS driver core could use it */
mdiodev->dev.platform_data = (void *)device_get_match_data(dev);
diff --git a/drivers/of/device.c b/drivers/of/device.c
index f7e75e527667..be4e1584e0af 100644
--- a/drivers/of/device.c
+++ b/drivers/of/device.c
@@ -26,7 +26,7 @@
const struct of_device_id *of_match_device(const struct of_device_id *matches,
const struct device *dev)
{
- if (!matches || !dev->of_node || dev->of_node_reused)
+ if (!matches || !dev->of_node || dev_of_node_reused(dev))
return NULL;
return of_match_node(matches, dev->of_node);
}
@@ -192,7 +192,7 @@ ssize_t of_device_modalias(struct device *dev, char *str, ssize_t len)
{
ssize_t sl;
- if (!dev || !dev->of_node || dev->of_node_reused)
+ if (!dev || !dev->of_node || dev_of_node_reused(dev))
return -ENODEV;
sl = of_modalias(dev->of_node, str, len - 2);
@@ -254,7 +254,7 @@ int of_device_uevent_modalias(const struct device *dev, struct kobj_uevent_env *
{
int sl;
- if ((!dev) || (!dev->of_node) || dev->of_node_reused)
+ if ((!dev) || (!dev->of_node) || dev_of_node_reused(dev))
return -ENODEV;
/* Devicetree modalias is tricky, we add it in 2 steps */
diff --git a/drivers/pci/of.c b/drivers/pci/of.c
index 9f8eb5df279e..1f9b669abdb0 100644
--- a/drivers/pci/of.c
+++ b/drivers/pci/of.c
@@ -38,7 +38,7 @@ int pci_set_of_node(struct pci_dev *dev)
struct device *pdev __free(put_device) =
bus_find_device_by_of_node(&platform_bus_type, node);
if (pdev)
- dev->bus->dev.of_node_reused = true;
+ dev_set_of_node_reused(&dev->bus->dev);
device_set_node(&dev->dev, of_fwnode_handle(no_free_ptr(node)));
return 0;
diff --git a/drivers/pci/pwrctrl/core.c b/drivers/pci/pwrctrl/core.c
index 7754baed67f2..72963a92362a 100644
--- a/drivers/pci/pwrctrl/core.c
+++ b/drivers/pci/pwrctrl/core.c
@@ -39,7 +39,7 @@ static int pci_pwrctrl_notify(struct notifier_block *nb, unsigned long action,
* If we got here then the PCI device is the second after the
* power control platform device. Mark its OF node as reused.
*/
- dev->of_node_reused = true;
+ dev_set_of_node_reused(dev);
break;
}
diff --git a/drivers/regulator/bq257xx-regulator.c b/drivers/regulator/bq257xx-regulator.c
index dab8f1ab4450..40e0f1a7ae81 100644
--- a/drivers/regulator/bq257xx-regulator.c
+++ b/drivers/regulator/bq257xx-regulator.c
@@ -143,7 +143,7 @@ static int bq257xx_regulator_probe(struct platform_device *pdev)
struct regulator_config cfg = {};
pdev->dev.of_node = pdev->dev.parent->of_node;
- pdev->dev.of_node_reused = true;
+ dev_set_of_node_reused(&pdev->dev);
pdata = devm_kzalloc(&pdev->dev, sizeof(struct bq257xx_reg_data), GFP_KERNEL);
if (!pdata)
diff --git a/drivers/regulator/rk808-regulator.c b/drivers/regulator/rk808-regulator.c
index e66408f23bb6..8297d31cde9f 100644
--- a/drivers/regulator/rk808-regulator.c
+++ b/drivers/regulator/rk808-regulator.c
@@ -2115,7 +2115,7 @@ static int rk808_regulator_probe(struct platform_device *pdev)
int ret, i, nregulators;
pdev->dev.of_node = pdev->dev.parent->of_node;
- pdev->dev.of_node_reused = true;
+ dev_set_of_node_reused(&pdev->dev);
regmap = dev_get_regmap(pdev->dev.parent, NULL);
if (!regmap)
diff --git a/drivers/tty/serial/serial_base_bus.c b/drivers/tty/serial/serial_base_bus.c
index a12935f6b992..5f23284a8778 100644
--- a/drivers/tty/serial/serial_base_bus.c
+++ b/drivers/tty/serial/serial_base_bus.c
@@ -74,7 +74,7 @@ static int serial_base_device_init(struct uart_port *port,
dev->parent = parent_dev;
dev->bus = &serial_base_bus_type;
dev->release = release;
- dev->of_node_reused = true;
+ dev_set_of_node_reused(dev);
device_set_node(dev, fwnode_handle_get(dev_fwnode(parent_dev)));
diff --git a/drivers/usb/gadget/udc/aspeed-vhub/dev.c b/drivers/usb/gadget/udc/aspeed-vhub/dev.c
index 2ecd049dacc2..8b9449d16324 100644
--- a/drivers/usb/gadget/udc/aspeed-vhub/dev.c
+++ b/drivers/usb/gadget/udc/aspeed-vhub/dev.c
@@ -593,7 +593,7 @@ int ast_vhub_init_dev(struct ast_vhub *vhub, unsigned int idx)
d->gadget.max_speed = USB_SPEED_HIGH;
d->gadget.speed = USB_SPEED_UNKNOWN;
d->gadget.dev.of_node = vhub->pdev->dev.of_node;
- d->gadget.dev.of_node_reused = true;
+ dev_set_of_node_reused(&d->gadget.dev);
rc = usb_add_gadget_udc(d->port_dev, &d->gadget);
if (rc != 0)
diff --git a/include/linux/device.h b/include/linux/device.h
index fca986cef2ed..8132aab17e04 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -483,6 +483,8 @@ struct device_physical_location {
* driver/bus sync_state() callback.
* @DEV_FLAG_DMA_COHERENT: This particular device is dma coherent, even if the
* architecture supports non-coherent devices.
+ * @DEV_FLAG_OF_NODE_REUSED: Set if the device-tree node is shared with an
+ * ancestor device.
*/
enum struct_device_flags {
DEV_FLAG_READY_TO_PROBE = 0,
@@ -492,6 +494,7 @@ enum struct_device_flags {
DEV_FLAG_DMA_OPS_BYPASS = 4,
DEV_FLAG_STATE_SYNCED = 5,
DEV_FLAG_DMA_COHERENT = 6,
+ DEV_FLAG_OF_NODE_REUSED = 7,
DEV_FLAG_COUNT
};
@@ -573,8 +576,6 @@ enum struct_device_flags {
*
* @offline_disabled: If set, the device is permanently online.
* @offline: Set after successful invocation of bus type's .offline().
- * @of_node_reused: Set if the device-tree node is shared with an ancestor
- * device.
* @flags: DEV_FLAG_XXX flags. Use atomic bitfield operations to modify.
*
* At the lowest level, every device in a Linux system is represented by an
@@ -681,7 +682,6 @@ struct device {
bool offline_disabled:1;
bool offline:1;
- bool of_node_reused:1;
DECLARE_BITMAP(flags, DEV_FLAG_COUNT);
};
@@ -715,6 +715,7 @@ __create_dev_flag_accessors(dma_skip_sync, DEV_FLAG_DMA_SKIP_SYNC);
__create_dev_flag_accessors(dma_ops_bypass, DEV_FLAG_DMA_OPS_BYPASS);
__create_dev_flag_accessors(state_synced, DEV_FLAG_STATE_SYNCED);
__create_dev_flag_accessors(dma_coherent, DEV_FLAG_DMA_COHERENT);
+__create_dev_flag_accessors(of_node_reused, DEV_FLAG_OF_NODE_REUSED);
/**
* struct device_link - Device link representation.
--
2.53.0.1213.gd9a14994de-goog
^ permalink raw reply related
* [PATCH v4 0/9] driver core: Fix some race conditions
From: Douglas Anderson @ 2026-04-04 0:04 UTC (permalink / raw)
To: Greg Kroah-Hartman, Rafael J . Wysocki, Danilo Krummrich,
Alan Stern
Cc: Saravana Kannan, Christoph Hellwig, Eric Dumazet, Johan Hovold,
Leon Romanovsky, Alexander Lobakin, Alexey Kardashevskiy,
Robin Murphy, Douglas Anderson, Andrew Morton, Frank.Li,
Jason Gunthorpe, alex, alexander.stein, andre.przywara, andrew,
andrew, andriy.shevchenko, aou, ardb, bhelgaas, brgl, broonie,
catalin.marinas, chleroy, davem, david, devicetree, dmaengine,
driver-core, gbatra, gregory.clement, hkallweit1, iommu,
jirislaby, joel, joro, kees, kevin.brodsky, kuba, lenb, lgirdwood,
linux-acpi, linux-arm-kernel, linux-aspeed, linux-cxl,
linux-kernel, linux-mips, linux-mm, linux-pci, linux-riscv,
linux-serial, linux-snps-arc, linux-usb, linux, linuxppc-dev,
m.szyprowski, maddy, mani, maz, miko.lenczewski, mpe, netdev,
npiggin, osalvador, oupton, pabeni, palmer, peter.ujfalusi,
peterz, pjw, robh, sebastian.hesselbarth, tglx, tsbogend, vgupta,
vkoul, will, willy, yangyicong, yeoreum.yun
The main goal of this series is to fix the observed bug talked about
in the first patch ("driver core: Don't let a device probe until it's
ready"). That patch fixes a problem that has been observed in the real
world and could land even if the rest of the patches are found
unacceptable or need to be spun.
That said, during patch review Danilo correctly pointed out that many
of the bitfield accesses in "struct device" are unsafe. I added a
bunch of patches in the series to address each one.
Danilo said he's most worried about "can_match", so I put that one
first. After that, I tried to transition bitfields to flags in reverse
order to when the bitfield was added.
Even if transitioning from bitfields to flags isn't truly needed for
correctness, it seems silly (and wasteful of space in struct device)
to have some in bitfields and some as flags. Thus I didn't spend time
for each bitfield showing that it's truly needed for correctness.
Transition was done semi manually. Presumably someone skilled at
coccinelle could do a better job, but I just used sed in a heavy-
handed manner and then reviewed/fixed the results, undoing anything my
script got wrong. My terrible/ugly script was:
var=can_match
caps="${var^^}"
for f in $(git grep -l "[>\.]${var}[^1-9_a-zA-Z\[]"); do
echo $f
sed -i~ -e "s/\([a-zA-Z_0-9\.>()-][a-zA-Z_0-9\.>()-]*\)->${var} = true/set_bit(DEV_FLAG_${caps}, \&\\1->flags)/" "$f"
sed -i~ -e "s/\([a-zA-Z_0-9\.>()-][a-zA-Z_0-9\.>()-]*\)\.${var} = true/dev_set_${caps}(\&\\1)/" "$f"
sed -i~ -e "s/\([a-zA-Z_0-9\.>()-][a-zA-Z_0-9\.>()-]*\)->${var} = false/clear_bit(DEV_FLAG_${caps}, \&\\1->flags)/" "$f"
sed -i~ -e "s/\([a-zA-Z_0-9\.>()-][a-zA-Z_0-9\.>()-]*\)\.${var} = false/dev_clear_${caps}(\&\\1)/" "$f"
sed -i~ -e "s/\([a-zA-Z_0-9\.>()-][a-zA-Z_0-9\.>()-]*\)->${var} = \([^;]*\)/assign_bit(DEV_FLAG_${caps}, \&\\1->flags, \\2)/" "$f"
sed -i~ -e "s/\([a-zA-Z_0-9\.>()-][a-zA-Z_0-9\.>()-]*\)\.${var} = \([^;]*\)/dev_assign_${caps}(\&\\1, \\2)/" "$f"
sed -i~ -e "s/\([a-zA-Z_0-9\.>()-][a-zA-Z_0-9\.>()-]*\)->${var}\([^1-9_a-zA-Z\[]\)/test_bit(DEV_FLAG_${caps}, \&\\1->flags)\\2/" "$f"
sed -i~ -e "s/\([a-zA-Z_0-9\.>()-][a-zA-Z_0-9\.>()-]*\)\.${var}\([^1-9_a-zA-Z\[]\)/dev_${caps}(\&\\1)\\2/" "$f"
done
From v3 to v4, I transitioned to accessor functions with another ugly
sed script. I had git format the old patches, then transformed them
with:
for f in *.patch; do
echo $f
sed -i~ -e "s/test_and_set_bit(DEV_FLAG_\([^,]*\), \&\(.*\)->flags)/dev_test_and_set_\\L\\1(\\2)/" "$f"
sed -i~ -e "s/test_and_set_bit(DEV_FLAG_\([^,]*\), \(.*\)\.flags)/dev_test_and_set_\\L\\1(\\2)/" "$f"
sed -i~ -e "s/test_bit(DEV_FLAG_\([^,]*\), \&\(.*\)->flags)/dev_\\L\\1(\\2)/" "$f"
sed -i~ -e "s/test_bit(DEV_FLAG_\([^,]*\), \(.*\)\.flags)/dev_\\L\\1(\\2)/" "$f"
sed -i~ -e "s/set_bit(DEV_FLAG_\([^,]*\), \&\(.*\)->flags)/dev_set_\\L\\1(\\2)/" "$f"
sed -i~ -e "s/set_bit(DEV_FLAG_\([^,]*\), \(.*\)\.flags)/dev_set_\\L\\1(\\2)/" "$f"
sed -i~ -e "s/clear_bit(DEV_FLAG_\([^,]*\), \&\(.*\)->flags)/dev_clear_\\L\\1(\\2)/" "$f"
sed -i~ -e "s/clear_bit(DEV_FLAG_\([^,]*\), \(.*\)\.flags)/dev_clear_\\L\\1(\\2)/" "$f"
sed -i~ -e "s/assign_bit(DEV_FLAG_\([^,]*\), \&\(.*\)->flags, \(.*\))/dev_assign_\\L\\1(\\2, \\3)/" "$f"
sed -i~ -e "s/assign_bit(DEV_FLAG_\([^,]*\), \(.*\)\.flags, \(.*\))/dev_assign_\\L\\1(\\2, \\3)/" "$f"
done
...and then did a few manual touchups for spacing.
NOTE: one potentially "controversial" choice I made in some patches
was to always reserve a flag ID even if a flag is only used under
certain CONFIG_ settings. This is a change from how things were
before. Keeping the numbering consistent and allowing easy
compile-testing of both CONFIG settings seemed worth it, especially
since it won't take up any extra space until we've added a lot more
flags.
I only marked the first patch as a "Fix" since it is the only one
fixing observed problems. Other patches could be considered fixes too
if folks want.
I tested the first patch in the series backported to kernel 6.6 on the
Pixel phone that was experiencing the race. I added extra printouts to
make sure that the problem was hitting / addressed. The rest of the
patches are tested with allmodconfig with arm32, arm64, ppc, and
x86. I boot tested on an arm64 Chromebook running mainline.
Changes in v4:
- Use accessor functions for flags
Changes in v3:
- Use a new "flags" bitfield
- Add missing \n in probe error message
Changes in v2:
- Instead of adjusting the ordering, use "ready_to_probe" flag
Douglas Anderson (9):
driver core: Don't let a device probe until it's ready
driver core: Replace dev->can_match with dev_can_match()
driver core: Replace dev->dma_iommu with dev_dma_iommu()
driver core: Replace dev->dma_skip_sync with dev_dma_skip_sync()
driver core: Replace dev->dma_ops_bypass with dev_dma_ops_bypass()
driver core: Replace dev->state_synced with dev_state_synced()
driver core: Replace dev->dma_coherent with dev_dma_coherent()
driver core: Replace dev->of_node_reused with dev_of_node_reused()
driver core: Replace dev->offline + ->offline_disabled with accessors
arch/arc/mm/dma.c | 4 +-
arch/arm/mach-highbank/highbank.c | 2 +-
arch/arm/mach-mvebu/coherency.c | 2 +-
arch/arm/mm/dma-mapping-nommu.c | 4 +-
arch/arm/mm/dma-mapping.c | 28 ++--
arch/arm64/kernel/cpufeature.c | 2 +-
arch/arm64/mm/dma-mapping.c | 2 +-
arch/mips/mm/dma-noncoherent.c | 2 +-
arch/powerpc/kernel/dma-iommu.c | 8 +-
.../platforms/pseries/hotplug-memory.c | 4 +-
arch/riscv/mm/dma-noncoherent.c | 2 +-
drivers/acpi/scan.c | 2 +-
drivers/base/core.c | 53 +++++---
drivers/base/cpu.c | 4 +-
drivers/base/dd.c | 28 ++--
drivers/base/memory.c | 2 +-
drivers/base/pinctrl.c | 2 +-
drivers/base/platform.c | 2 +-
drivers/dma/ti/k3-udma-glue.c | 6 +-
drivers/dma/ti/k3-udma.c | 6 +-
drivers/iommu/dma-iommu.c | 9 +-
drivers/iommu/iommu.c | 5 +-
drivers/net/pcs/pcs-xpcs-plat.c | 2 +-
drivers/of/device.c | 6 +-
drivers/pci/of.c | 2 +-
drivers/pci/pwrctrl/core.c | 2 +-
drivers/regulator/bq257xx-regulator.c | 2 +-
drivers/regulator/rk808-regulator.c | 2 +-
drivers/tty/serial/serial_base_bus.c | 2 +-
drivers/usb/gadget/udc/aspeed-vhub/dev.c | 2 +-
include/linux/device.h | 120 ++++++++++++------
include/linux/dma-map-ops.h | 6 +-
include/linux/dma-mapping.h | 2 +-
include/linux/iommu-dma.h | 3 +-
kernel/cpu.c | 4 +-
kernel/dma/mapping.c | 12 +-
mm/hmm.c | 2 +-
37 files changed, 206 insertions(+), 142 deletions(-)
--
2.53.0.1213.gd9a14994de-goog
^ permalink raw reply
* Re: [PATCH net-next v6 0/2] r8152: Add support for the RTL8157 5Gbit USB Ethernet chip
From: Jakub Kicinski @ 2026-04-03 23:06 UTC (permalink / raw)
To: Birger Koblitz
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Paolo Abeni,
linux-usb, netdev, linux-kernel, Chih Kai Hsu
In-Reply-To: <20260402-rtl8157_next-v6-0-a9b77c0931ef@birger-koblitz.de>
On Thu, 02 Apr 2026 10:28:12 +0200 Birger Koblitz wrote:
> Add support for the RTL8157, which is a 5GBit USB-Ethernet adapter
> chip in the RTL815x family of chips.
no longer applies, please rebase & repost
--
pw-bot: cr
^ permalink raw reply
* Re: [PATCH v1 2/2] usb: typec: cros_ec_ucsi: Load driver from OF and ACPI definitions
From: Benson Leung @ 2026-04-03 22:47 UTC (permalink / raw)
To: Jameson Thies
Cc: robh, krzk+dt, conor+dt, abhishekpandit, bleung, heikki.krogerus,
akuchynski, gregkh, devicetree, chrome-platform, linux-usb,
linux-kernel
In-Reply-To: <20260403223357.1896403-3-jthies@google.com>
[-- Attachment #1: Type: text/plain, Size: 3053 bytes --]
On Fri, Apr 03, 2026 at 10:33:27PM +0000, Jameson Thies wrote:
> Add support for cros_ec_ucsi to load based on "google,cros-ec-ucsi"
> compatible devices and "GOOG0021" ACPI nodes.
>
> Signed-off-by: Jameson Thies <jthies@google.com>
Reviewed-by: Benson Leung <bleung@chromium.org>
> ---
> drivers/usb/typec/ucsi/cros_ec_ucsi.c | 26 ++++++++++++++++++++++++--
> 1 file changed, 24 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/usb/typec/ucsi/cros_ec_ucsi.c b/drivers/usb/typec/ucsi/cros_ec_ucsi.c
> index 6bca2dce211c..251aa7251ce6 100644
> --- a/drivers/usb/typec/ucsi/cros_ec_ucsi.c
> +++ b/drivers/usb/typec/ucsi/cros_ec_ucsi.c
> @@ -5,11 +5,13 @@
> * Copyright 2024 Google LLC.
> */
>
> +#include <linux/acpi.h>
> #include <linux/container_of.h>
> #include <linux/dev_printk.h>
> #include <linux/jiffies.h>
> #include <linux/mod_devicetable.h>
> #include <linux/module.h>
> +#include <linux/of.h>
> #include <linux/platform_data/cros_ec_commands.h>
> #include <linux/platform_data/cros_usbpd_notify.h>
> #include <linux/platform_data/cros_ec_proto.h>
> @@ -257,7 +259,6 @@ static void cros_ucsi_destroy(struct cros_ucsi_data *udata)
> static int cros_ucsi_probe(struct platform_device *pdev)
> {
> struct device *dev = &pdev->dev;
> - struct cros_ec_dev *ec_data = dev_get_drvdata(dev->parent);
> struct cros_ucsi_data *udata;
> int ret;
>
> @@ -265,9 +266,16 @@ static int cros_ucsi_probe(struct platform_device *pdev)
> if (!udata)
> return -ENOMEM;
>
> + /* ACPI and OF FW nodes for cros_ec_ucsi are children of the ChromeOS EC. If the
> + * cros_ec_ucsi device has an ACPI or OF FW node, its parent is the ChromeOS EC device.
> + * Platforms without a FW node for cros_ec_ucsi may add it as a subdevice of cros_ec_dev.
> + */
> udata->dev = dev;
> + if (is_acpi_device_node(dev->fwnode) || is_of_node(dev->fwnode))
> + udata->ec = dev_get_drvdata(dev->parent);
> + else
> + udata->ec = ((struct cros_ec_dev *)dev_get_drvdata(dev->parent))->ec_dev;
>
> - udata->ec = ec_data->ec_dev;
> if (!udata->ec)
> return dev_err_probe(dev, -ENODEV, "couldn't find parent EC device\n");
>
> @@ -348,10 +356,24 @@ static const struct platform_device_id cros_ucsi_id[] = {
> };
> MODULE_DEVICE_TABLE(platform, cros_ucsi_id);
>
> +static const struct acpi_device_id cros_ec_ucsi_acpi_device_ids[] = {
> + { "GOOG0021", 0 },
> + { }
> +};
> +MODULE_DEVICE_TABLE(acpi, cros_ec_ucsi_acpi_device_ids);
> +
> +static const struct of_device_id cros_ucsi_of_match[] = {
> + { .compatible = "google,cros-ec-ucsi", },
> + {}
> +};
> +MODULE_DEVICE_TABLE(of, cros_ucsi_of_match);
> +
> static struct platform_driver cros_ucsi_driver = {
> .driver = {
> .name = KBUILD_MODNAME,
> .pm = &cros_ucsi_pm_ops,
> + .acpi_match_table = cros_ec_ucsi_acpi_device_ids,
> + .of_match_table = cros_ucsi_of_match,
> },
> .id_table = cros_ucsi_id,
> .probe = cros_ucsi_probe,
> --
> 2.53.0.1213.gd9a14994de-goog
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v1 1/2] dt-bindings: chrome: Add cros-ec-ucsi compatibility to typec binding
From: Benson Leung @ 2026-04-03 22:45 UTC (permalink / raw)
To: Jameson Thies
Cc: robh, krzk+dt, conor+dt, abhishekpandit, bleung, heikki.krogerus,
akuchynski, gregkh, devicetree, chrome-platform, linux-usb,
linux-kernel
In-Reply-To: <20260403223357.1896403-2-jthies@google.com>
[-- Attachment #1: Type: text/plain, Size: 2790 bytes --]
On Fri, Apr 03, 2026 at 10:33:26PM +0000, Jameson Thies wrote:
> Chrome OS devices with discrete power delivery controllers (PDCs) allow
> the host to read port status and control port behavior through a USB
> Type-C Connector System Software (UCSI) interface with the embedded
> controller (EC). This uses a separate interface driver than other
> Chrome OS devices with a Type-C port manager in the EC FW. Those use
> a host command interface supported by cros-ec-typec. Add a cros-ec-ucsi
> compatibility string to the existing cros-ec-typec binding.
>
> Additionally, update maintainer list to reflect cros-ec-ucsi and
> cros-ec-typec driver maintainers.
>
> Signed-off-by: Jameson Thies <jthies@google.com>
Reviewed-by: Benson Leung <bleung@chromium.org>
> ---
> .../bindings/chrome/google,cros-ec-typec.yaml | 19 +++++++++++++++----
> 1 file changed, 15 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/chrome/google,cros-ec-typec.yaml b/Documentation/devicetree/bindings/chrome/google,cros-ec-typec.yaml
> index 9f9816fbecbc..fd1a459879bd 100644
> --- a/Documentation/devicetree/bindings/chrome/google,cros-ec-typec.yaml
> +++ b/Documentation/devicetree/bindings/chrome/google,cros-ec-typec.yaml
> @@ -8,17 +8,28 @@ title: Google Chrome OS EC(Embedded Controller) Type C port driver.
>
> maintainers:
> - Benson Leung <bleung@chromium.org>
> - - Prashant Malani <pmalani@chromium.org>
> + - Abhishek Pandit-Subedi <abhishekpandit@chromium.org>
> + - Andrei Kuchynski <akuchynski@chromium.org>
> + - Łukasz Bartosik <ukaszb@chromium.org>
> + - Jameson Thies <jthies@google.com>
>
> description:
> Chrome OS devices have an Embedded Controller(EC) which has access to
> Type C port state. This node is intended to allow the host to read and
> - control the Type C ports. The node for this device should be under a
> - cros-ec node like google,cros-ec-spi.
> + control the Type C ports. This binding is compatible with both the
> + cros-ec-typec and cros-ec-ucsi drivers. The cros-ec-typec driver
> + supports the host command interface used by the Chrome OS EC with a
> + built-in Type-C port manager and external Type-C Port Controller
> + (TCPC). The cros-ec-ucsi driver supports the USB Type-C Connector
> + System Software (UCSI) interface used by the Chrome OS EC when the
> + platform has a separate power delivery controller (PDC). The node for
> + this device should be under a cros-ec node like google,cros-ec-spi.
>
> properties:
> compatible:
> - const: google,cros-ec-typec
> + enum:
> + - google,cros-ec-typec
> + - google,cros-ec-ucsi
>
> '#address-cells':
> const: 1
> --
> 2.53.0.1213.gd9a14994de-goog
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* [PATCH v1 2/2] usb: typec: cros_ec_ucsi: Load driver from OF and ACPI definitions
From: Jameson Thies @ 2026-04-03 22:33 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, abhishekpandit, bleung, heikki.krogerus,
akuchynski
Cc: gregkh, devicetree, chrome-platform, linux-usb, linux-kernel,
Jameson Thies
In-Reply-To: <20260403223357.1896403-1-jthies@google.com>
Add support for cros_ec_ucsi to load based on "google,cros-ec-ucsi"
compatible devices and "GOOG0021" ACPI nodes.
Signed-off-by: Jameson Thies <jthies@google.com>
---
drivers/usb/typec/ucsi/cros_ec_ucsi.c | 26 ++++++++++++++++++++++++--
1 file changed, 24 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/typec/ucsi/cros_ec_ucsi.c b/drivers/usb/typec/ucsi/cros_ec_ucsi.c
index 6bca2dce211c..251aa7251ce6 100644
--- a/drivers/usb/typec/ucsi/cros_ec_ucsi.c
+++ b/drivers/usb/typec/ucsi/cros_ec_ucsi.c
@@ -5,11 +5,13 @@
* Copyright 2024 Google LLC.
*/
+#include <linux/acpi.h>
#include <linux/container_of.h>
#include <linux/dev_printk.h>
#include <linux/jiffies.h>
#include <linux/mod_devicetable.h>
#include <linux/module.h>
+#include <linux/of.h>
#include <linux/platform_data/cros_ec_commands.h>
#include <linux/platform_data/cros_usbpd_notify.h>
#include <linux/platform_data/cros_ec_proto.h>
@@ -257,7 +259,6 @@ static void cros_ucsi_destroy(struct cros_ucsi_data *udata)
static int cros_ucsi_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
- struct cros_ec_dev *ec_data = dev_get_drvdata(dev->parent);
struct cros_ucsi_data *udata;
int ret;
@@ -265,9 +266,16 @@ static int cros_ucsi_probe(struct platform_device *pdev)
if (!udata)
return -ENOMEM;
+ /* ACPI and OF FW nodes for cros_ec_ucsi are children of the ChromeOS EC. If the
+ * cros_ec_ucsi device has an ACPI or OF FW node, its parent is the ChromeOS EC device.
+ * Platforms without a FW node for cros_ec_ucsi may add it as a subdevice of cros_ec_dev.
+ */
udata->dev = dev;
+ if (is_acpi_device_node(dev->fwnode) || is_of_node(dev->fwnode))
+ udata->ec = dev_get_drvdata(dev->parent);
+ else
+ udata->ec = ((struct cros_ec_dev *)dev_get_drvdata(dev->parent))->ec_dev;
- udata->ec = ec_data->ec_dev;
if (!udata->ec)
return dev_err_probe(dev, -ENODEV, "couldn't find parent EC device\n");
@@ -348,10 +356,24 @@ static const struct platform_device_id cros_ucsi_id[] = {
};
MODULE_DEVICE_TABLE(platform, cros_ucsi_id);
+static const struct acpi_device_id cros_ec_ucsi_acpi_device_ids[] = {
+ { "GOOG0021", 0 },
+ { }
+};
+MODULE_DEVICE_TABLE(acpi, cros_ec_ucsi_acpi_device_ids);
+
+static const struct of_device_id cros_ucsi_of_match[] = {
+ { .compatible = "google,cros-ec-ucsi", },
+ {}
+};
+MODULE_DEVICE_TABLE(of, cros_ucsi_of_match);
+
static struct platform_driver cros_ucsi_driver = {
.driver = {
.name = KBUILD_MODNAME,
.pm = &cros_ucsi_pm_ops,
+ .acpi_match_table = cros_ec_ucsi_acpi_device_ids,
+ .of_match_table = cros_ucsi_of_match,
},
.id_table = cros_ucsi_id,
.probe = cros_ucsi_probe,
--
2.53.0.1213.gd9a14994de-goog
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox