Hello,
there is a spec from USB regarding high current charging (on top of USB3.0).
Do you know if there is any driver support required, and if so, when will this
be available with Linux?
Best regards
Carsten
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of
copies of the original
message.
> -Original Message-
> From: Greg KH [mailto:gre...@linuxfoundation.org]
> Sent: Mittwoch, 25. Februar 2015 16:45
> To: Schmid, Carsten
> Cc: linux-usb@vger.kernel.org
> Subject: Re: USB driver support for high current charging
>
>
Hi,
some weeks ago, when stabilizing a production kernel,
i have fixed a bug in the xhci driver.
Mathias (Nyman) was involved checking the patch, and he wrote:
..
Subject: Re: help needed - kernel crash in USB driver
Hi Zainie
I can look at a upstream fix for usb core,
but we
Hi,
two weeks ago i sent this mail to the linux-usb mailing list but got no answer.
Maybe this has fallen through your filters?
So resending it and adding Mathias in CC.
Best regards
Carsten
-Ursprüngliche Nachricht-
Von: Schmid, Carsten
Gesendet: Donnerstag, 25. April 2019 17:20
An
Hi USB maintainers,
we recently have seen a problem with usb-storage when trying to read from a
device.
This happened on a 4.14.86 kernel.
The kernel's dmesg shows: (log has been submitted via DLT)
1200.862250 kernel: usb 1-3.1: reset high-speed USB device number 10 using
xhci_hcd
1285.466289 k
> Wow that's an old kernel.
Indeed. Long running project.
> Can you reproduce this on a "clean" 5.1 kernel release?
As this is an automotive embedded target, we currently have 4.14.102 as the
newest custom kernel.
Porting a 5.1 will take a lot of effort.
Anyway, thanks for quick response.
I'll c
> > > Wow that's an old kernel.
> > Indeed. Long running project.
> >
> > > Can you reproduce this on a "clean" 5.1 kernel release?
> > As this is an automotive embedded target, we currently have 4.14.102 as the
> > newest custom kernel.
>
> 4.14.102 is still old.
I agree
> > Porting a 5.1 will
> > >
> > > 4.14.102 is still old.
> > I agree
> >
> > > > Porting a 5.1 will take a lot of effort.
> > >
> > > Then that implies you have an SoC with a few million lines of code added
> > > to the kernel, right? Nothing we can do here about that mess, you need
> > > to go ask for support from the
> On Thu, 23 May 2019, Schmid, Carsten wrote:
>
> > Hi USB maintainers,
> >
> > we recently have seen a problem with usb-storage when trying to read
> from a device.
> > This happened on a 4.14.86 kernel.
> >
> > The kernel's dmesg shows: (log
> A more detailed look through the email archives and git log finds the
> following two commits, either of which might be relevant:
>
> 511833acfc06 ("SCSI: fix regression in scsi_send_eh_cmnd()")
> f45681f9beca ("USB: Add quirk to support DJI CineSSD")
>
> For the second commit, it m
> Von: Sasha Levin [mailto:sas...@kernel.org]
> Gesendet: Mittwoch, 29. Mai 2019 15:15
> An: Sasha Levin ; Mathias Nyman
> ; Schmid, Carsten
> ; gre...@linuxfoundation.org
> Cc: linux-usb@vger.kernel.org; Stable ;
> sta...@vger.kernel.org
> Betreff: Re: [PATCH 3/5] usb: xhci: av
helps :-)
Best regards
Carsten
Von: Sasha Levin
Gesendet: Mittwoch, 29. Mai 2019 15:14
An: Sasha Levin; Mathias Nyman; Schmid, Carsten; gre...@linuxfoundation.org
Cc: linux-usb@vger.kernel.org; Stable; sta...@vger.kernel.org
Betreff: Re: [PATCH 3/5] usb
> Hi Sasha,
>
> i have (back)ported the patch to the older kernels mentioned below
> where the original patch failed.
>
> The patch appended to this mail applies to v4.14.121, v4.9.178, v4.4.180 and
> v3.18.140.
> Some changes within the xhci driver prevented git from finding the correct
> positi
> >
> > Facing kernel "Unhandled fault: imprecise external abort (0x1406)"
> > when trying to load xhci_pci.ko module for uPD720202. Receiving this
> > fault straight-away when driver trying to setup device.
> >
I had "imprecise external abort" on ARM systems in the following cases:
- Subsystem tha
Hi all having use-after-free issues in USB shutdowns:
I hunted for a similar case in the intel_xhci_usb_sw driver.
What i have found and proposed is (from yesterday):
---
[PATCH] kernel/resource.c: invalidate parent when freed resource has childs
When a resource is freed and has children, the chil
> -Ursprüngliche Nachricht-
> Von: Greg KH [mailto:gre...@linuxfoundation.org]
> Gesendet: Freitag, 9. August 2019 09:56
> An: Schmid, Carsten
> Cc: Alan Stern ; Andrey Konovalov
> ; Oliver Neukum ;
> syzkaller-bugs ; syzbot
> ; USB list
> ; Hillf Danton
>
>
> We are talking memory-mapped io here, so it cannot just be "re-used", it
> is wat it is. I guess the PCI BAR could be released and then the physical
> address the resource was at could be re-used for another piece of MMIo,
> but AFAIK outside of PI=CI hotplug we never release BARs.
>
> Maybe
Hi again,
>>
>> Hey, i did not want to trigger an eartquake in the basement of the kernel ;-)
>> My intention was to prevent some crashes, and help developers to find their
>> bugs.
>> I think my patch exactly does this.
>
> Hehe, actually drivers not being able to block unbind has been bugging
>>
>> @Greg:
>> I am still confident that my patch in __release_region should be taken in.
>
> Ok, submit it in a "real" way and we can consider it :)
>
> thanks,
>
> greg k-h
Already done, linux-ker...@vger.kernel.org, see
https://www.spinics.net/lists/kernel/msg3218180.html
Thanks, and have a n
[Resend - had mailer errors ]
Hi Florian,
today i have seen a strange behaviour of two D-Link DUB-1312 adapters (same
Revision A1).
Plugging them into the same port (!) on my device one of them is recognized as
SuperSpeed, the other as high speed ???
(working on 4.14.129 LTS)
>From dmesg, the
>> Plugging them into the same port (!) on my device one of them is
>> recognized as SuperSpeed, the other as high speed ???
>> (working on 4.14.129 LTS)
>>
>> From dmesg, the "faulty" one:
>> [ 530.585871] usb 1-2: new high-speed USB device number 4 using
>> xhci_hcd < HUH
>>
> XH
>>> Plugging them into the same port (!) on my device one of them is
>>> recognized as SuperSpeed, the other as high speed ???
>>> (working on 4.14.129 LTS)
>>>
>>> From dmesg, the "faulty" one:
>>> [ 530.585871] usb 1-2: new high-speed USB device number 4 using
>>> xhci_hcd < HUH
>
On driver removal, the platform_device_unregister call
attached through devm_add_action_or_reset was executed
after usb_hcd_pci_remove.
This lead to a use-after-free for the iomem resorce of
the xhci-ext-caps driver in the platform removal
because the parent of the resource was freed earlier.
Fix
> > On driver removal, the platform_device_unregister call
> > attached through devm_add_action_or_reset was executed
> > after usb_hcd_pci_remove.
> > This lead to a use-after-free for the iomem resorce of
> > the xhci-ext-caps driver in the platform removal
> > because the parent of the resource
On driver removal, the platform_device_unregister call
attached through devm_add_action_or_reset was executed
after usb_hcd_pci_remove.
This lead to a use-after-free for the iomem resorce of
the xhci-ext-caps driver in the platform removal
because the parent of the resource was freed earlier.
Fix
>> I don't think its a regression.
>
> It would be better to know than to assume.
>
Happens with kernel 4.14.102 also, not only with 4.14.129.
Looks more HW related.
>
>> Is there something i can do to force an error message to be seen
>> when the ETH2USB adapter stalls?
>
> You can activate dynam
On driver removal, the platform_device_unregister call
attached through devm_add_action_or_reset was executed
after usb_hcd_pci_remove.
This lead to a use-after-free for the iomem resource of
the xhci-ext-caps driver in the platform removal
because the parent of the resource was freed earlier.
Fix
On driver removal, the platform_device_unregister call
attached through devm_add_action_or_reset was executed
after usb_hcd_pci_remove.
This lead to a use-after-free for the iomem resource of
the xhci-ext-caps driver in the platform removal
because the parent of the resource was freed earlier.
Fix
> >> I don't think its a regression.
> >
> > It would be better to know than to assume.
> >
> Happens with kernel 4.14.102 also, not only with 4.14.129.
> Looks more HW related.
>
Confirmed: HW issue.
Best regards
Carsten
Hi all,
we had a look at the adapters, and it's really a HW issue.
Nothing we can follow up here anymore.
Let's close it.
Thanks!
Best regards
Carsten
Von: Oliver Neukum
Gesendet: Montag, 19. August 2019 14:11
An: Schmid, Carsten; f.faine...
Hi Walter,
i had a similar issue with a different device.
Please check, if you have dynamic debug enabled in your kernel
(/sys/kernel/debug/dynamic_debug/control exists)
Then you can enable additional kernel messages using
echo -n 'module xhci_hcd =p' > /sys/kernel/debug/dynamic_debug/control
ech
> > (doing a "cat /sys/kernel/debug/dynamic_debug/control | grep usb" helps
> much)
> >
> I see a bunch of messages. what do you expect me to do ? I have 412 lines,
> should
> i send them ?
>
From the log of your kernel messages, it seems that uhci_hcd takes over the
transport.
So you should do
>
> Different computer but same cables i guess the device is ok.
>
But maybe the USB port of the computer is broken.
> NTL I found that little gem:
> https://www.fclose.com/linux-kernels/594677/usb-io_ti-add-heartbeat-to-
> keep-idle-ep-416-ports-from-disconnecting-linux-4-3/
>
> The behavior
>
> uname -a
> Linux omnfrmo10 4.12.14-lp151.28.10-vanilla #1 SMP Sat Jul 13 17:59:31 UTC
> 2019 (0ab03b7) x86_64 x86_64 x86_64 GNU/Linux
>
4.12.14 - it should have the heartbeat patch introduced in 4.3
> i see a lot, see attached file
The dyndbg for the driver is active :-)
The log you sent
>
> Have a question that: Can I disable PCIe power management completely
> using some kernel CONFIG option OR boot parameter? If yes then how?
>
> Thanks
>
See CONFIG_PM and what it depends on.
BR
Carsten
>
> Occasionally we see crash at boot too without even reaching stage of
> loading xhci-pci.ko driver.
>
> Log is below. Is this can be because of again uPD connected on PCIe
> bus (through PCIe switch)?
>
> [8.263117] Unhandled fault: imprecise external abort (0x1406) at
> 0xfaf06a5b
Look
> On 22-08-19 17:23, Mathias Nyman wrote:
> > On 16.8.2019 12.03, Schmid, Carsten wrote:
> >> On driver removal, the platform_device_unregister call
> >> attached through devm_add_action_or_reset was executed
> >> after usb_hcd_pci_remove.
> >> This le
On driver removal, the platform_device_unregister call
attached through devm_add_action_or_reset was executed
after usb_hcd_pci_remove.
This lead to a use-after-free for the iomem resource of
the xhci-ext-caps driver in the platform removal
because the parent of the resource was freed earlier.
Fix
> > On driver removal, the platform_device_unregister call
> > attached through devm_add_action_or_reset was executed
> > after usb_hcd_pci_remove.
> > This lead to a use-after-free for the iomem resource of
> > the xhci-ext-caps driver in the platform removal
> > because the parent of the resource
Using managed device resources in usb_hcd_pci_probe() allows devm usage for
resource subranges, such as the mmio resource for the platform device
created to control host/device mode mux, which is a xhci extended
capability, and sits inside the xhci mmio region.
If managed device resources are not
>> Upstream version of driver is identical in the affected code.
>> Fix was tested successfully on 4.14.129.
>> Provided patch applies and compiles on v5.2.8 stable.
>> As this is also a bugfix, please consider it to go to stable trees too.
>
> How far back should it go, just 4.14? Was this caused
>>> Upstream version of driver is identical in the affected code.
>>> Fix was tested successfully on 4.14.129.
>>> Provided patch applies and compiles on v5.2.8 stable.
>>> As this is also a bugfix, please consider it to go to stable trees too.
>>
>> How far back should it go, just 4.14? Was this
>
> Thanks for fixing this, it solves a real upstream xhci related issue since
> 4.19.
> Fix is outside xhci so accepting this is no longer up to me, but for Greg:
>
> Reviewed-by: Mathias Nyman
> Fixes: fa31b3cb2ae1 ("xhci: Add Intel extended cap / otg phy mux handling")
> Cc: # v4.19+
Anyth
43 matches
Mail list logo
