Re: USB driver resets

[Mika Westerberg]

Hi,

On Tue, Dec 04, 2018 at 04:02:56PM +, Richard van der Hoff wrote:
> Mathias, Mika, thanks very much for your help.
> 
> On 04/12/2018 15:09, Mika Westerberg wrote:
> > On Tue, Dec 04, 2018 at 04:45:33PM +0200, Mathias Nyman wrote:
> > > > On 19/11/2018 15:27, Richard van der Hoff wrote:
> > > > > I have a USB-3.1 dock, which I use for video (via displayport alt 
> > > > > mode) and power delivery, as well as keyboard, mouse, etc.
> > > > > 
> > > > > From time to time, all connectivity with the dock drops out for a few 
> > > > > seconds, before resetting itself. I'm trying to pin down if this is a 
> > > > > problem with the usb drivers, pci drivers, laptop hardware, or the 
> > > > > dock. It looks to me from the dmesg output like it could be a problem 
> > > > > at the PCI layer, but I am only speculating really.
> > > > > 
> > > > > Attached are the dmesg output during the problem, lsusb -v, and lspci 
> > > > > -v. They are all recorded with a 4.15.0 kernel; I've seen exactly the 
> > > > > same symptoms with a number of kernels between 4.8 and 4.15.
> > > > > 
> > > 
> > > Mika (cc) would be the right person to contact about these kind of 
> > > thunderbolt related issues.
> > > I'm sure he would appreciate logs with a 4.19 - 4.20-rcx kernel.
> 
> I've attached the kernel log output from a 4.19 kernel. I've actually had
> some other problems with a 4.19 kernel [1] so have gone back to the 4.15
> kernel for now, but please do let me know if there is anything specific I
> should try.
> 
> I've also re-attached the lsusb -v and lspci -v output (from a 4.15 kernel)
> for your reference.
> 
> > Right, those would help and also some knowledge about which system and
> > dock we are dealing with :)
> 
> Sorry. The system is a Dell XPS13 9350, with an Intel DSL6340 Thunderbolt 3
> bridge.
> 
> The dock is a Plugable UD-CA1 [2].
> 
> > Also if you have dual boot or similar, do you experience similar issue
> > in Windows side?
> 
> I do have dual-boot, though I very rarely boot into Windows. Since the issue
> is somewhat intermittent (for some reason it seems to happen particularly
> when I'm in a video conference...) I wouldn't have a huge amount of
> confidence of being able to reproduce it under Windows.
> 
> Thanks again.
> 
> 
> [1] https://bugzilla.kernel.org/show_bug.cgi?id=201853
> [2] https://plugable.com/products/ud-ca1/

This seems to be normal USB-C dock (not TBT). In the logs it looks like
at some point the USB link just goes down which makes the host side to
hot-remove xHCI and the intermediate PCIe ports.

The UD-CA1 dock site you linked above mentions connection issues with
some systems so I'm suspecting it is an issue with the dock itself not
with the kernel. It would be good if you could try to reproduce on
Windows side as well, basically doing the same things you do in Linux
(assuming it is possible) and see if it triggers.

Re: USB driver resets

[Mika Westerberg]

On Tue, Dec 04, 2018 at 04:45:33PM +0200, Mathias Nyman wrote:
> On 03.12.2018 12:36, Richard van der Hoff wrote:
> > Does anybody have any suggestions as to how I could set about debugging 
> > this? I'm seeing the same symptoms on a 4.19 kernel.
> > 
> > 
> > On 19/11/2018 15:27, Richard van der Hoff wrote:
> > > I have a USB-3.1 dock, which I use for video (via displayport alt mode) 
> > > and power delivery, as well as keyboard, mouse, etc.
> > > 
> > > From time to time, all connectivity with the dock drops out for a few 
> > > seconds, before resetting itself. I'm trying to pin down if this is a 
> > > problem with the usb drivers, pci drivers, laptop hardware, or the dock. 
> > > It looks to me from the dmesg output like it could be a problem at the 
> > > PCI layer, but I am only speculating really.
> > > 
> > > Attached are the dmesg output during the problem, lsusb -v, and lspci -v. 
> > > They are all recorded with a 4.15.0 kernel; I've seen exactly the same 
> > > symptoms with a number of kernels between 4.8 and 4.15.
> > > 
> > > Advice appreciated!
> > > 
> 
> Mika (cc) would be the right person to contact about these kind of 
> thunderbolt related issues.
> I'm sure he would appreciate logs with a 4.19 - 4.20-rcx kernel.

Right, those would help and also some knowledge about which system and
dock we are dealing with :)

Also if you have dual boot or similar, do you experience similar issue
in Windows side?

Re: [REGRESSION] xHCI host controller not responding, assume dead on Dell XPS 13 9360

[Mika Westerberg]

On Thu, May 03, 2018 at 06:53:13PM +0200, Esokrates wrote:
> Hi,
> 
> Thanks very much for pointing out that commit!
> Indeed, reverting makes the problem go away!
> Also, interestingly it also makes the errors in
> https://bugzilla.kernel.org/show_bug.cgi?id=199557
> go away, tested using 4.16.7!

OK, good.

Could you then attach full dmesg of the failure without revert to the
bugzilla bug?
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [REGRESSION] xHCI host controller not responding, assume dead on Dell XPS 13 9360

[Mika Westerberg]

On Thu, May 03, 2018 at 04:13:05PM +0300, Mathias Nyman wrote:
> On 03.05.2018 12:30, Esokrates wrote:
> > Hi,> Beginning with Linux 4.16 rc7 (4.16 rc6 was NOT affected), I do
> > find the following regularly in dmesg (often it does not happen during
> > boot, but after suspend to ram / resume):
> > 
> 
> Hi
> 
> Can you try 'git bisect' to find the patch that causes the issues?
> (Adding Mika to Cc)

Could you try to revert:

  13d3047c8150 ("ACPI / hotplug / PCI: Check presence of slot itself in 
get_slot_status()")

and see if the problem goes away?

> > [  216.443309] pcieport :00:1c.0: AER: Corrected error received: id=00e0
> > [  216.443951] pcieport :00:1c.0: PCIe Bus Error: severity=Corrected, 
> > type=Physical Layer, id=00e0(Receiver ID)
> > [  216.444607] pcieport :00:1c.0:   device [8086:9d10] error 
> > status/mask=0001/2000
> > [  216.445300] pcieport :00:1c.0:    [ 0] Receiver Error (First)
> > [  216.517886] xhci_hcd :39:00.0: remove, state 4
> > [  216.518573] usb usb4: USB disconnect, device number 1
> > [  216.519438] xhci_hcd :39:00.0: USB bus 4 deregistered
> > [  216.520320] xhci_hcd :39:00.0: xHCI host controller not responding, 
> > assume dead
> > [  216.521908] xhci_hcd :39:00.0: remove, state 4
> > [  216.522950] usb usb3: USB disconnect, device number 1
> > [  216.523891] xhci_hcd :39:00.0: Host halt failed, -19
> > [  216.524994] xhci_hcd :39:00.0: Host not accessible, reset failed.
> > [  216.526153] xhci_hcd :39:00.0: USB bus 3 deregistered
> > 
> > 
> > Running 4.16.0 I also observed
> > 
> > [   31.509282] ACPI: Waking up from system sleep state S3
> > [   31.809429] ACPI: EC: interrupt unblocked
> > [   31.828849] pci_raw_set_power_state: 62 callbacks suppressed
> > [   31.828852] pcieport :01:00.0: Refused to change power state, 
> > currently in D3
> > [   31.830422] pcieport :02:01.0: Refused to change power state, 
> > currently in D3
> > [   31.830423] pcieport :02:02.0: Refused to change power state, 
> > currently in D3
> > [   31.848853] pcieport :02:00.0: Refused to change power state, 
> > currently in D3
> > [   31.852520] xhci_hcd :39:00.0: Refused to change power state, 
> > currently in D3
> > [   31.872529] thunderbolt :03:00.0: Refused to change power state, 
> > currently in D3
> > [   31.933970] thunderbolt :03:00.0: control channel starting...
> > [   31.937403] ACPI: EC: event unblocked
> > [   31.938385] sd 2:0:0:0: [sda] Starting disk
> > [   31.938886] ACPI: button: The lid device is not compliant to SW_LID.
> > [   31.956574] xhci_hcd :39:00.0: Refused to change power state, 
> > currently in D3
> > [   31.956624] xhci_hcd :39:00.0: WARN: xHC restore state timeout
> > [   31.956631] xhci_hcd :39:00.0: PCI post-resume error -110!
> > [   31.956656] xhci_hcd :39:00.0: HC died; cleaning up
> > [   31.956658] xhci_hcd :39:00.0: HC died; cleaning up
> > [   31.956664] dpm_run_callback(): pci_pm_resume+0x0/0xb0 returns -110
> > [   31.956668] PM: Device :39:00.0 failed to resume async: error -110
> > 
> > Furthermore sometimes I also get a bunch of these errors before the errors 
> > above:
> > May 03 10:58:49 debian kernel: usb 1-3: device descriptor read/64, error -71
> > May 03 10:58:49 debian kernel: usb 1-3: device descriptor read/64, error -71
> > May 03 10:58:50 debian kernel: usb 1-3: device descriptor read/64, error -71
> > May 03 10:58:50 debian kernel: usb 1-3: device descriptor read/64, error -71
> > May 03 10:58:51 debian kernel: usb 1-3: device not accepting address 2, 
> > error -71
> > 
> > All of this never happened before 4.16rc7. All kernels since 4.16.rc7 are 
> > reproducibly affected (suspend/resume helps triggering), including 
> > 4.17.0rc3.
> > 
> > My hardware is a XPS 13 9360 Kabylake, lsub and lspci output are attached.
> > 
> > I am not subscribed to the mailing list, so please CC me when replying to 
> > the list.
> > 
> > Thanks very much!
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: USB-C Devices only show up if connected at boot

[Mika Westerberg]

On Sun, Feb 11, 2018 at 06:59:52PM +, Mike Lothian wrote:
> This a final patch ever get sent out?

I'll send it out tomorrow once merge window is closed.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: USB-C Devices only show up if connected at boot

[Mika Westerberg]

On Sat, Jan 27, 2018 at 01:31:00PM +, Mike Lothian wrote:
> On 26 January 2018 at 09:53, Mike Lothian <m...@fireburn.co.uk> wrote:
> > On 26 January 2018 at 08:31, Mika Westerberg
> > <mika.westerb...@linux.intel.com> wrote:
> >> On Fri, Jan 26, 2018 at 08:07:56AM +, Mike Lothian wrote:
> >>> Whether CONFIG_HOTPLUG_PCI_ACPI=y or CONFIG_HOTPLUG_PCI_ACPI=n the
> >>> device doesn't show unless echo 1 > /sys/bus/pci/rescan is issued
> >>
> >> That's not how it is supposed to work. Please send me full dmesg and in
> >> addition acpidump of the system (or attach it to the bugzilla bug). Also
> >> share your .config.
> >
> > I've attached my full dmesg and .config to the bug. The acpidump info
> > can be found at https://bugzilla.kernel.org/show_bug.cgi?id=198051,
> > the current kernel has the attached patch to enable
> > AcpiGbl_ParseTableAsTermList, the bug also contains a dmesg without it
> 
> I've attached the dmesg to the bug
> https://bugzilla.kernel.org/show_bug.cgi?id=198557
> 
> The important lines I think are:
> 
> [   26.988174] ACPI: \_SB_.PCI0.RP01: acpiphp_glue: Bus check in 
> hotplug_event()
> [  129.086070] ACPI: \_SB_.PCI0.RP01: acpiphp_glue: Bus check in 
> hotplug_event()

Indeed. Thanks! Let's continue debugging on bugzilla.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: USB-C Devices only show up if connected at boot

[Mika Westerberg]

On Fri, Jan 26, 2018 at 08:07:56AM +, Mike Lothian wrote:
> Whether CONFIG_HOTPLUG_PCI_ACPI=y or CONFIG_HOTPLUG_PCI_ACPI=n the
> device doesn't show unless echo 1 > /sys/bus/pci/rescan is issued

That's not how it is supposed to work. Please send me full dmesg and in
addition acpidump of the system (or attach it to the bugzilla bug). Also
share your .config.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: USB-C Devices only show up if connected at boot

[Mika Westerberg]

On Thu, Jan 25, 2018 at 10:20:02PM +, Mike Lothian wrote:
> I've just tried this and the USB-C device was detected :D This is the
> first time it's ever been detected after boot
> 
> 02:00.0 PCI bridge: Intel Corporation DSL6340 Thunderbolt 3 Bridge
> [Alpine Ridge 2C 2015]
>Kernel driver in use: pcieport
> 03:00.0 PCI bridge: Intel Corporation DSL6340 Thunderbolt 3 Bridge
> [Alpine Ridge 2C 2015]
>Kernel driver in use: pcieport
> 03:01.0 PCI bridge: Intel Corporation DSL6340 Thunderbolt 3 Bridge
> [Alpine Ridge 2C 2015]
>Kernel driver in use: pcieport
> 03:02.0 PCI bridge: Intel Corporation DSL6340 Thunderbolt 3 Bridge
> [Alpine Ridge 2C 2015]
>Kernel driver in use: pcieport
> 39:00.0 USB controller: Intel Corporation DSL6340 USB 3.1 Controller
> [Alpine Ridge]
>Subsystem: Device :
>Kernel driver in use: xhci_hcd

Yes, this is how it should work. All those PCI bridges + xHCI are
hotplugged when you plug in a USB-C device.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: USB-C Devices only show up if connected at boot

[Mika Westerberg]

On Thu, Jan 25, 2018 at 09:31:08PM +, Mike Lothian wrote:
> I've tried with and without those being set, neither help,  having
> CONFIG_HOTPLUG_PCI_ACPI=y on causes my NVMe drive to disappear after
> suspend

You *must* have those set, othewise the xHCI will not work. Can you do
so that you enable those options, boot without anything connected to the
USB-C port. Then when the system is up and running plug in your USB-C
device and see if it works or not. If it does not then send me full dmesg.

NVMe missing after suspend is a different issue, though.

> I'll switch back into windows and check I've the latest firmware for
> Thunderbolt, is there a way to do that on linux too?

I don't think that is needed since hotplug works in Windows. You can
upgrade NVM from Linux as well. See Documentation/admin-guide/thunderbolt.rst.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: USB-C Devices only show up if connected at boot

[Mika Westerberg]

On Thu, Jan 25, 2018 at 12:35:49PM +0200, Heikki Krogerus wrote:
> +Mika
> 
> On Tue, Jan 23, 2018 at 05:43:27PM +, Mike Lothian wrote:
> > On Tue, 23 Jan 2018 at 17:30 Greg KH  wrote:
> > >
> > > On Tue, Jan 23, 2018 at 05:12:03PM +, Mike Lothian wrote:
> > > > Hi
> > > >
> > > > I raised https://bugzilla.kernel.org/show_bug.cgi?id=198557 but was
> > > > informed by Greg bugs should be raised on the mailing list not in
> > > > bugzilla
> > > >
> > > > So USB-C devices only show up in dmesg or for use if they are
> > > > connected during boot
> > > >
> > > > Once booted and the device is disconnected the following message
> > > > appears in the dmesg:
> > > >
> > > > [  100.814687] usb 3-1: USB disconnect, device number 3
> > > > [  100.882840] xhci_hcd :39:00.0: xHCI host controller not
> > > > responding, assume dead
> > > > [  100.882843] xhci_hcd :39:00.0: HC died; cleaning up
> > > >
> > > > No further connections or disconnections display anything further in
> > > > the dmesg, the device works fine if connected via USB-A
> > > >
> > > > I've witnessed this behaviour since getting the laptop at the end of
> > > > 2015 so this isn't a regression
> > >
> > > Is there a BIOS update for the laptop?  This has been seen a lot in the
> > > past on lots of different laptops but was always resolved by the BIOS
> > > update (the latest one for mine also updates the xhci controller as
> > > well.)
> > >
> > > thanks,
> > >
> > > greg k-h
> > 
> > 
> > Hi
> > 
> > I've applied all BIOS updates for my laptop including the pulled one
> > for Spectre/Meltdown & ME bugs the other week
> > http://www.dell.com/support/home/uk/en/ukdhs1/product-support/servicetag/8k5w662/drivers
> > 
> > If it helps, I don't have this issue in Windows but I rarely have it booted
> > 
> > I thought it might have something to do with an ACPI failure (see bug
> > https://bugzilla.kernel.org/show_bug.cgi?id=198051)
> 
> Did you update the Thunderbolt firmware?
> 
> Mika, perhaps you can provide steps how to do that?

If it works in Windows then I suspect this is not related to the
firmware.

Mike, do you have PCI hotplug enabled in your .config? Following needs
to be set:

CONFIG_HOTPLUG_PCI=y
CONFIG_HOTPLUG_PCI_ACPI=y

If not, please enabled them and try again.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Dell thunderbolt docking station not working

[Mika Westerberg]

On Tue, Oct 10, 2017 at 03:42:10PM -0700, Stephen Hemminger wrote:
> On Tue, 10 Oct 2017 22:31:34 +0300
> Mika Westerberg <mika.westerb...@linux.intel.com> wrote:
> 
> > On Tue, Oct 10, 2017 at 12:11:49PM -0700, Stephen Hemminger wrote:
> > > The Dell thunderbolt docking brick (TB16) does not appear to be fully 
> > > supported in Linux.
> > > When I connect my Dell XPS 13 (running Ubuntu) to the dock, the multiple 
> > > displays work
> > > correctly but the USB keyboard, mouse and wired Ethernet do not.
> > > (Of course this all works with the other Windows laptop so it is not a 
> > > hardware BIOS issue).  
> > 
> > TB16 should be working fine, that's one of the devices I use for my
> > testing. Looking at your dmesg, it seems to be fine.
> > 
> > Have you authorized the devices you connected?
> > 
> > https://www.kernel.org/doc/html/latest/admin-guide/thunderbolt.html
> 
> Thanks, once I authorized 0-301 it worked.

Cool!

There is also a userspace "tbtadm" tool that makes authorizing lot more
easier here:

https://github.com/01org/thunderbolt-software-user-space
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Dell thunderbolt docking station not working

[Mika Westerberg]

On Tue, Oct 10, 2017 at 12:11:49PM -0700, Stephen Hemminger wrote:
> The Dell thunderbolt docking brick (TB16) does not appear to be fully 
> supported in Linux.
> When I connect my Dell XPS 13 (running Ubuntu) to the dock, the multiple 
> displays work
> correctly but the USB keyboard, mouse and wired Ethernet do not.
> (Of course this all works with the other Windows laptop so it is not a 
> hardware BIOS issue).

TB16 should be working fine, that's one of the devices I use for my
testing. Looking at your dmesg, it seems to be fine.

Have you authorized the devices you connected?

https://www.kernel.org/doc/html/latest/admin-guide/thunderbolt.html
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] PCI / PM: Avoid using device_may_wakeup() for runtime PM

[Mika Westerberg]

On Fri, Jun 30, 2017 at 12:37:00AM +0200, Rafael J. Wysocki wrote:
> On Friday, June 23, 2017 02:58:11 PM Rafael J. Wysocki wrote:
> > From: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
> > 
> > pci_target_state() calls device_may_wakeup() which checks whether
> > or not the device may wake up the system from sleep states, but
> > pci_target_state() is used for runtime PM too.
> > 
> > Since runtime PM is expected to always enable remote wakeup if
> > possible, modify pci_target_state() to take additional argument
> > indicating whether or not it should look for a state from which
> > the device can signal wakeup and pass either the return value
> > of device_can_wakeup(), or "false" (if the device itself is not
> > wakeup-capable) to it from the code related to runtime PM.
> > 
> > While at it, fix the comment in pci_dev_run_wake() which is not
> > about sleep states.
> > 
> > Signed-off-by: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
> > ---
> > 
> > -> v2:
> > 
> > Passing "true" as the second argument to pci_target_state() for runtime PM
> > might trigger suboptimal state choices to be made, so pass the return value
> > of device_can_wakeup() to it instead and pass "false" to it in 
> > pci_dev_run_wake(),
> > because that assumes device_can_wakeup() to return "false" already.
> 
> This was sent a week ago without any response so far.
> 
> Any concerns?

No concerns from me.

Reviewed-by: Mika Westerberg <mika.westerb...@linux.intel.com>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv15 2/3] usb: USB Type-C connector class

[Mika Westerberg]

On Mon, Jan 16, 2017 at 04:35:24PM +0100, Greg KH wrote:
> On Mon, Jan 16, 2017 at 05:56:13PM +0300, Heikki Krogerus wrote:
> > The purpose of USB Type-C connector class is to provide
> > unified interface for the user space to get the status and
> > basic information about USB Type-C connectors on a system,
> > control over data role swapping, and when the port supports
> > USB Power Delivery, also control over power role swapping
> > and Alternate Modes.
> > 
> > Signed-off-by: Heikki Krogerus <heikki.kroge...@linux.intel.com>
> > Reviewed-by: Mika Westerberg <mika.westerb...@linux.intel.com>
> 
> I asked for signed-off-by or reviewed-by from other Intel kernel
> developers before I would look at this again.

Well, I reviewed this and I work for Intel as kernel developer :-)

> You did run this through the Intel internal kernel developer mailing
> list before sending this here, right?  If not, please go do that now,
> we've reviewed this enough, you need to burn some Intel resources on
> this before I am going to take the time again...

This and the previous version were submitted to the internal list and
was reviewed by me there.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv14 2/3] usb: USB Type-C connector class

[Mika Westerberg]

On Thu, Jan 05, 2017 at 02:01:18PM +0300, Heikki Krogerus wrote:
> The purpose of USB Type-C connector class is to provide
> unified interface for the user space to get the status and
> basic information about USB Type-C connectors on a system,
> control over data role swapping, and when the port supports
> USB Power Delivery, also control over power role swapping
> and Alternate Modes.

Disclaimer: I'm not familiar with USB Type-C, so my comments are pretty
much limited to generic/stylistic issues.

Overall this looks good. Please find a couple of nitpicks below.

[snip]

> +++ b/Documentation/usb/typec.txt
> @@ -0,0 +1,181 @@
> +USB Type-C connector class
> +==

You might want to convert this to the new .rst format at some point.

[snip]

> +++ b/drivers/usb/typec/Kconfig
> @@ -0,0 +1,7 @@
> +
> +menu "USB Power Delivery and Type-C drivers"

This could use a help text telling why the user wants to select this.

> +
> +config TYPEC
> + tristate
> +
> +endmenu
> diff --git a/drivers/usb/typec/Makefile b/drivers/usb/typec/Makefile
> new file mode 100644
> index ..1012a8bed6d5
> --- /dev/null
> +++ b/drivers/usb/typec/Makefile
> @@ -0,0 +1 @@
> +obj-$(CONFIG_TYPEC)  += typec.o
> diff --git a/drivers/usb/typec/typec.c b/drivers/usb/typec/typec.c
> new file mode 100644
> index ..fe6571ca4d81
> --- /dev/null
> +++ b/drivers/usb/typec/typec.c
> @@ -0,0 +1,1190 @@
> +/*
> + * USB Type-C Connector Class
> + *
> + * Copyright (C) 2017, Intel Corporation
> + * Author: Heikki Krogerus 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/* XXX: Once we have a header for USB Power Delivery, this belongs there */
> +#define ALTMODE_MAX_N_MODES  7

ALTMODE_MAX_MODES looks better.

> +
> +struct typec_mode {
> + int index;
> + u32 vdo;
> + char*desc;
> + enum typec_port_typeroles;
> +
> + struct typec_altmode*alt_mode;
> +
> + unsigned intactive:1;
> +
> + chargroup_name[6];
> + struct attribute_group  group;
> + struct attribute*attrs[5];
> + struct device_attribute vdo_attr;
> + struct device_attribute desc_attr;
> + struct device_attribute active_attr;
> + struct device_attribute roles_attr;
> +};
> +
> +struct typec_altmode {
> + struct device   dev;
> + u16 svid;
> + int n_modes;
> + struct typec_mode   modes[ALTMODE_MAX_N_MODES];
> + const struct attribute_group*mode_groups[ALTMODE_MAX_N_MODES];
> +};
> +
> +struct typec_plug {
> + struct device   dev;
> + enum typec_plug_index   index;
> +};
> +
> +struct typec_cable {
> + struct device   dev;
> + u16 pd_revision;
> + enum typec_plug_typetype;
> + u32 vdo;
> + unsigned intactive:1;
> +};
> +
> +struct typec_partner {
> + struct device   dev;
> + u16 pd_revision;
> + u32 vdo;
> + enum typec_accessoryaccessory;
> +};
> +
> +struct typec_port {
> + unsigned intid;
> + struct device   dev;
> +
> + int prefer_role;
> + enum typec_data_roledata_role;
> + enum typec_role pwr_role;
> + enum typec_role vconn_role;
> + enum typec_pwr_opmode   pwr_opmode;
> +
> + const struct typec_capability   *cap;
> +};
> +
> +#define to_typec_port(_dev_) container_of(_dev_, struct typec_port, dev)
> +#define to_typec_plug(_dev_) container_of(_dev_, struct typec_plug, dev)
> +#define to_typec_cable(_dev_) container_of(_dev_, struct typec_cable, dev)
> +#define to_typec_partner(_dev_) container_of(_dev_, struct typec_partner, 
> dev)
> +#define to_altmode(_dev_) container_of(_dev_, struct typec_altmode, dev)
> +
> +static const struct device_type typec_partner_dev_type;
> +static const struct device_type typec_cable_dev_type;
> +static const struct device_type typec_plug_dev_type;
> +static const struct device_type typec_port_dev_type;
> +
> +#define is_typec_partner(_dev_) (_dev_->type == _partner_dev_type)
> +#define is_typec_cable(_dev_) (_dev_->type == _cable_dev_type)
> +#define is_typec_plug(_dev_) (_dev_->type == _plug_dev_type)
> +#define is_typec_port(_dev_) (_dev_->type == _port_dev_type)
> +
> +static DEFINE_IDA(typec_index_ida);
> +static struct class *typec_class;
> +
> +/* Common attributes */
> +
> +static 

[PATCH] xhci: Fix memory leak in xhci_pme_acpi_rtd3_enable()

[Mika Westerberg]

There is a memory leak because acpi_evaluate_dsm() actually returns an
object which the caller is supposed to release. Fix this by calling
ACPI_FREE() for the returned object (this expands to kfree() so passing
NULL there is fine as well).

While there correct indentation in !CONFIG_ACPI case.

Signed-off-by: Mika Westerberg <mika.westerb...@linux.intel.com>
---
 drivers/usb/host/xhci-pci.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
index 17f6897acde2..c62109091d12 100644
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -188,10 +188,14 @@ static void xhci_pme_acpi_rtd3_enable(struct pci_dev *dev)
0xb7, 0x0c, 0x34, 0xac, 0x01, 0xe9, 0xbf, 0x45,
0xb7, 0xe6, 0x2b, 0x34, 0xec, 0x93, 0x1e, 0x23,
};
-   acpi_evaluate_dsm(ACPI_HANDLE(>dev), intel_dsm_uuid, 3, 1, NULL);
+   union acpi_object *obj;
+
+   obj = acpi_evaluate_dsm(ACPI_HANDLE(>dev), intel_dsm_uuid, 3, 1,
+   NULL);
+   ACPI_FREE(obj);
 }
 #else
-   static void xhci_pme_acpi_rtd3_enable(struct pci_dev *dev) { }
+static void xhci_pme_acpi_rtd3_enable(struct pci_dev *dev) { }
 #endif /* CONFIG_ACPI */
 
 /* called during probe() after chip reset completes */
-- 
2.6.2

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC/PATCH] extcon: otg_gpio: add driver for USB OTG port controlled by GPIO(s)

[Mika Westerberg]

On Tue, Feb 17, 2015 at 11:35:23AM -0800, David Cohen wrote:
 Hi,
 
 Adding Mika.
 
 On Tue, Feb 17, 2015 at 01:25:00PM -0600, Felipe Balbi wrote:
  Hi,
  
  On Tue, Feb 17, 2015 at 11:18:44AM -0800, David Cohen wrote:
   (3) Platform has 2 USB controllers connected to same port: one for
   device and one for host role. D+/- are switched between phys
   by GPIO.
  
  so you have discrete mux with a GPIO select signal, like below ?
  
  
   .---..  ..
   |   ||  ||  D+
   |   ||  ||-.
   |   ||  ||  |
   |   |USB Host--|P   |  |
   |   ||  |H   |  |
   |   ||  |Y   |D-|
   |   ''  |0   |.|
   |   |   || ||
   |   |   ''  ..  D+
   |   |   ||--
   |   SOCGPIO | -||
   |   |   |   MUX  |
   |   |   ||--
   |   |   ..  ''  D-
   |   ..  ||   D-  |  |
   |   ||  |P   |--'  |
   |   ||  |H   |  |
   |   ||  |Y   |  |
   |   |   USB Device   --|1   |  |
   |   ||  ||  D+  |
   |   ||  ||-'
   |   ||  ||
   '---''  ''
 
 Nice ASCII pic :)

asciio ftw \o/

 Yes, that's the case.

alright

  I have been on and off about writing a pinctrl-gpio.c driver which 
  would
  allow us to hide this detail from users. It shouldn't really matter
  which modes are available behind the mux, but we should be able to 
  tell
  the mux to go into mode 0 or mode 1 by toggling its select signal. 
  And
  it shouldn't really matter that we have a GPIO pin. The problem is: 
  I
  don't really know if pinctrl would be able to handle discrete muxes.
  
  Adding Linus W to ask. Linus, what do you think ? Should we have a
  pinctrl-gpio.c for such cases ? In TI we too have quite a few boards
  which different modes hidden behind discrete muxes.
 
 An input from Linus would fine in this case.
 
  
   As per initial version, this driver has the duty to control 
   whether
   USB-Host cable is plugged in or not:
- If yes, OTG port is configured for host role
- If no, by standard, the OTG port is configured for device role
  
  correct, this default-B is mandated by OTG spec anyway.
  
   Signed-off-by: David Cohen david.a.co...@linux.intel.com
   ---
   
   Hi,
   
   Some Intel Bay Trail boards have an unusual way to handle the USB 
   OTG port:
- The USB ID pin is connected directly to GPIO on SoC
- When in host role, VBUS is provided by enabling a GPIO
- Device and host roles are supported by 2 independent 
   controllers with D+/-
  pins from port switched between different phys according a 
   GPIO level.
   
   The ACPI table describes this USB port as a (virtual) device with 
   all the
   necessary GPIOs. This driver implements support to this virtual 
   device as an
   extcon class driver. All drivers that depend on the USB OTG port 
   state (USB phy,
   PMIC, charge detection) will listen to extcon events.
  
  Right I think you're almost there, but I still think that this 
  needs to
  be a bit broken down. First, we need some generic DRD library under
  drivers/usb/common, and that should be the one listening to extcon 
  cable
  events. But your extcon driver should be doing only that: checking 
  which
  cable was attached, it shouldn't be doing the switch by itself. That
  should be part of the DRD library.
  
  That DRD library would also be the one enabling the (optional) VBUS
  regulator.
  
  George Cherian tried to implement a generic DRD library but I think
  there are still too many changes happening on usbcore and udc-core. 
  Most
  of the pieces are already there (usb_del_hcd() and 
  usb_del_gadget_udc()
  know how to properly unload an hcd/udc), but there are details 
  missing,
  no doubt.
  
  If we can find a way to broadcast (probably not the best term, but
  whatever) a Hey ID pin was just grounded 

Re: [PATCH] pl2303: restore the old baud rate encoding for HXD (and newer) chips

[Mika Westerberg]

On Fri, Nov 01, 2013 at 08:08:31AM -0700, Greg KH wrote:
 I'll go revert all of these for now and send it to Linus for 3.12-final,
 and then we can start fresh in resolving this issue.

I tested again with the reverts and now my TU-S9 USB-serial converter works
fine. 

Thanks everyone.

Frank, Johan,

I can test your upcoming patches on my HW if needed.
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] pl2303: restore the old baud rate encoding for HXD (and newer) chips

[Mika Westerberg]

On Sun, Nov 03, 2013 at 03:26:24PM +0100, Johan Hovold wrote:
 On Sun, Nov 03, 2013 at 02:39:32PM +0200, Mika Westerberg wrote:
  On Fri, Nov 01, 2013 at 08:08:31AM -0700, Greg KH wrote:
   I'll go revert all of these for now and send it to Linus for 3.12-final,
   and then we can start fresh in resolving this issue.
  
  I tested again with the reverts and now my TU-S9 USB-serial converter works
  fine. 
  
  Thanks everyone.
  
  Frank, Johan,
  
  I can test your upcoming patches on my HW if needed.
 
 Great. Which type of pl2303 is the TU-S9?

It's HXD.
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] pl2303: restore the old baud rate encoding for HXD (and newer) chips

[Mika Westerberg]

On Fri, Nov 01, 2013 at 11:06:40AM +0100, Frank Schäfer wrote:
 No need to revert all these patches, removing the calculation of the
 resulting baud rateat the end of fcn pl2303_baudrate_encode_divisor()
 should fix this issue.
 The remaining question is, does the HXD work with the improved divisor
 method or do we have to reintroduce the old method ?

It works, with only removing the baud rate calculation.
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] pl2303: restore the old baud rate encoding for HXD (and newer) chips

[Mika Westerberg]

On Fri, Nov 01, 2013 at 11:45:32AM +0100, Frank Schäfer wrote:
 Am 01.11.2013 11:39, schrieb Mika Westerberg:
  On Fri, Nov 01, 2013 at 11:06:40AM +0100, Frank Schäfer wrote:
  No need to revert all these patches, removing the calculation of the
  resulting baud rateat the end of fcn pl2303_baudrate_encode_divisor()
  should fix this issue.
  The remaining question is, does the HXD work with the improved divisor
  method or do we have to reintroduce the old method ?
  It works, with only removing the baud rate calculation.
 For both baud rates = 115200 AND  115200 ?

Yes.
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC/RFT PATCH] pl2303: avoid data corruption with some chip types

[Mika Westerberg]

On Fri, Nov 01, 2013 at 12:49:22PM +0100, Frank Schäfer wrote:
 Some PL2303 chips are reported to lose bytes if the serial settings are set to
 the same values as before.
 At least HXD chips are affected, HX chips seem to be ok.
 The current code tries to avoid this by calling tty_termios_hw_change(), but
 this check isn't sufficient because different requested baud rates can result
 in identic encoded baud rates.
 The solution is to save and compare the encoded settings instead.

I tried this on top of rc7 and I can still see data get corrupted (both
115200 and 460800 bps).
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] pl2303: restore the old baud rate encoding for HXD (and newer) chips

[Mika Westerberg]

On Wed, Oct 30, 2013 at 11:14:34PM +0100, Frank Schäfer wrote:
 Hmm... try to replace the whole pl2303.c from 3.12 with the one from 3.11.
 If it makes no difference, it's not a pl2303 issue.

I did that and the 3.11 pl2303.c works (whereas 3.12 doesn't).

Can you tell me why do we even want to use this divisor based calculation
if we can do the same with direct method?

I mean why the driver can't do this:

 1) Try direct method for *all* chips.
 2) If it succeeds, use that value. Then we don't get any difference
between actual and set baud rate.
 3) If it fails, then and only then use divisor based method.

I would expect that the above cures my problem and possibly others who
might have affected by this regression.
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] pl2303: restore the old baud rate encoding for HXD (and newer) chips

[Mika Westerberg]

On Thu, Oct 31, 2013 at 01:09:55PM +0200, Mika Westerberg wrote:
 On Wed, Oct 30, 2013 at 11:14:34PM +0100, Frank Schäfer wrote:
  Hmm... try to replace the whole pl2303.c from 3.12 with the one from 3.11.
  If it makes no difference, it's not a pl2303 issue.
 
 I did that and the 3.11 pl2303.c works (whereas 3.12 doesn't).
 
 Can you tell me why do we even want to use this divisor based calculation
 if we can do the same with direct method?
 
 I mean why the driver can't do this:
 
  1) Try direct method for *all* chips.
  2) If it succeeds, use that value. Then we don't get any difference
 between actual and set baud rate.
  3) If it fails, then and only then use divisor based method.
 
 I would expect that the above cures my problem and possibly others who
 might have affected by this regression.

Something like the patch below.

diff --git a/drivers/usb/serial/pl2303.c b/drivers/usb/serial/pl2303.c
index bedf8e47713b..85f3fa4afc81 100644
--- a/drivers/usb/serial/pl2303.c
+++ b/drivers/usb/serial/pl2303.c
@@ -461,11 +461,11 @@ static void pl2303_encode_baudrate(struct tty_struct *tty,
enum pl2303_type type,
u8 buf[4])
 {
-   int baud;
+   int baud_req, baud;
 
-   baud = tty_get_baud_rate(tty);
-   dev_dbg(port-dev, baud requested = %d\n, baud);
-   if (!baud)
+   baud_req = tty_get_baud_rate(tty);
+   dev_dbg(port-dev, baud requested = %d\n, baud_req);
+   if (!baud_req)
return;
/*
 * There are two methods for setting/encoding the baud rate
@@ -480,10 +480,10 @@ static void pl2303_encode_baudrate(struct tty_struct *tty,
 * the device likely uses the same baud rate generator for both methods
 * so that there is likley no difference.
 */
-   if (type == type_0 || type == type_1 || type == HX_CLONE)
-   baud = pl2303_baudrate_encode_direct(baud, type, buf);
-   else
-   baud = pl2303_baudrate_encode_divisor(baud, type, buf);
+   baud = pl2303_baudrate_encode_direct(baud_req, type, buf);
+   if (baud != baud_req)
+   baud = pl2303_baudrate_encode_divisor(baud_req, type, buf);
+
/* Save resulting baud rate */
tty_encode_baud_rate(tty, baud, baud);
dev_dbg(port-dev, baud set = %d\n, baud);
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] pl2303: restore the old baud rate encoding for HXD (and newer) chips

[Mika Westerberg]

On Thu, Oct 31, 2013 at 01:02:56PM +0100, Frank Schäfer wrote:
 2) comment out the following line at the end of
 pl2303_baudrate_encode_divisor_HXD():
 
 baud = 1200 * 32 / ((1  buf[1]) * buf[0]);

This seems to fix the problem :)

Once the line is commented out, the serial console works fine with the
speeds I've been testing (115200, 230400 and 460800).
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] pl2303: restore the old baud rate encoding for HXD (and newer) chips

[Mika Westerberg]

On Tue, Oct 29, 2013 at 06:42:49PM +0100, Frank Schäfer wrote:
 Am 29.10.2013 18:12, schrieb Frank Schäfer:
  Am 29.10.2013 10:07, schrieb Mika Westerberg:
  On Mon, Oct 28, 2013 at 07:50:44PM +0100, Frank Schäfer wrote:
  Mika Westerberg has reported that the fixed+improved divisor based baud 
  rate 
  encoding method doesn't work anymore with his HXD device.
  So until we've found out what's going on, reintroduce the old encoding 
  algorithm
  and use it for this and all newer chips for baud rates  115200 baud.
  Also switch back to the direct encoding method for baud rates = 115200, 
  because
  it's unclear if the old divisor based encoding algorithm works for them.
 
  Reported-by: Mika Westerberg mika.westerb...@linux.intel.com
  Signed-off-by: Frank Schäfer fschaefer@googlemail.com
  Tried this and with 115200 it works and fixes the problem. However, with
  speeds like 230400 and 460800 it still corrupts data.
  Well, with this patch we go back to what we did since kernel 3.1 (since
  commit 8d48fdf689fe USB: PL2303: correctly handle baudrates above
  115200), so you should face the same problems with these kernels, too.
 I've double checked that. With this patch applied to 3.12-rc the baud
 rate encoding is exactly the same as in 3.11 (for HXD chips).
 
 Are you sure your test setup is reliable / comparable ? Could you please
 re-check your results ?

I re-tested with 3.11 and 3.12-rc7 with this patch applied. With 3.11 all
tried speeds (115200, 230400 and 460800) work fine. With 3.12-rc7 + this
patch, 115200 works but 230400 and 460800 corrupt data.

My test setup is such that I just start getty on ttyUSB0 with given speed
and then connect to it using picocom. Once logged in, command like 'ls'
will return listing that is corrupted somehow:

[root@tbt02 /]# ls
NH$�j�I[0m/ init*linuxrc@ opt/ run@ tmp/r/
etc/ lib/ media/   proc/sbin/usr/

It is supposed to look like:

[root@tbt02 /]# ls
bin/ home/lib32@   mnt/ root/sys/ var/
dev/ init*linuxrc@ opt/ run@ tmp/
etc/ lib/ media/   proc/sbin/usr/
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] pl2303: restore the old baud rate encoding for HXD (and newer) chips

[Mika Westerberg]

On Mon, Oct 28, 2013 at 07:50:44PM +0100, Frank Schäfer wrote:
 Mika Westerberg has reported that the fixed+improved divisor based baud rate 
 encoding method doesn't work anymore with his HXD device.
 So until we've found out what's going on, reintroduce the old encoding 
 algorithm
 and use it for this and all newer chips for baud rates  115200 baud.
 Also switch back to the direct encoding method for baud rates = 115200, 
 because
 it's unclear if the old divisor based encoding algorithm works for them.
 
 Reported-by: Mika Westerberg mika.westerb...@linux.intel.com
 Signed-off-by: Frank Schäfer fschaefer@googlemail.com

Tried this and with 115200 it works and fixes the problem. However, with
speeds like 230400 and 460800 it still corrupts data.

I also got few whitespace warnings when applied this using 'git am'.
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: pl2303 driver regression after commit 61fa8d694b854

[Mika Westerberg]

On Fri, Oct 25, 2013 at 03:43:03PM +0200, Frank Schäfer wrote:
 Am 25.10.2013 15:17, schrieb Mika Westerberg:
  On Fri, Oct 25, 2013 at 03:01:37PM +0200, Frank Schäfer wrote:
  Tried few other baudrates  115200 and they don't work either.
  Urgh... has this device ever been working at baud rates  115200 ?
  I have only used it as a serial console for a device and never tried baud
  rates higher than 115200 before today.
 Could you at least test kernel 3.11 ?

Tried on v3.11 following rates: 115200, 230400, 460800, and they all work.
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: pl2303 driver regression after commit 61fa8d694b854

[Mika Westerberg]

On Thu, Oct 24, 2013 at 03:20:02PM +0200, Frank Schäfer wrote:
 Ok, this seems to be a HXD (HX rev. D) chip.
 Could you please validate by checking what Prolifics CheckChipVersion
 tool toll sais ?

It says: This is a PL-2303 HXD chip.

 It would also be very nice if you could provide a USB-log of what this
 tool does, because we are currently not able to distinguish between HXD
 and EA, RA, SA chips.

Attached is the exchange (in *.csv) that I got from USB analyzator. Hope it
helps. Please let me know if you need something more.

 Are baudrates  115200 working ?

Tried few other baudrates  115200 and they don't work either.
# Total Phase Data Center(tm) v6.60
# (c) 2005-2013 Total Phase, Inc.
# www.totalphase.com
#
# 
#
# Level,Sp,Index,m:s.ms.us,Dur,Len,Err,Dev,Ep,Record,Data,Summary,ASCII
0,,0,0:00.000.000,,Capture started (Aggregate),,[10/25/13 12:44:46],
0,,1,0:00.000.000,,Host connected,,,
0,FS,2,0:00.000.014,,Full-speed,,,
0,FS,3,0:00.000.015,750 ns,1 B,I,,,NAK packet,5A,,Z
0,FS,5,0:01.308.880,53.083 us,1 B,,05,00,Control Transfer,02,,.
1,FS,6,0:01.308.880,12.500 us,8 B,,05,00,   SETUP txn,C0 01 84 84 00 00 01 00,,
2,FS,7,0:01.308.880,2.083 us,3 B,,05,00,  SETUP packet,2D 05 D0,,-..
2,FS,8,0:01.308.884,7.416 us,11 B,,05,00,  DATA0 packet,C3 C0 01 84 84 00 00 01 00 4C AE,,.L.
2,FS,9,0:01.308.892,750 ns,1 B,,05,00,  ACK packet,D2,,.
1,FS,10,0:01.308.907,8.083 us,1 B,,05,00,   IN txn,02,,.
2,FS,11,0:01.308.907,2.083 us,3 B,,05,00,  IN packet,69 05 D0,,i..
2,FS,12,0:01.308.911,2.850 us,4 B,,05,00,  DATA1 packet,4B 02 C1 7E,,K..~
2,FS,13,0:01.308.915,750 ns,1 B,,05,00,  ACK packet,D2,,.
1,FS,14,0:01.308.926,7.166 us,0 B,,05,00,   OUT txn,,,
2,FS,15,0:01.308.926,2.083 us,3 B,,05,00,  OUT packet,E1 05 D0,,...
2,FS,16,0:01.308.929,2.083 us,3 B,,05,00,  DATA1 packet,4B 00 00,,K..
2,FS,17,0:01.308.933,750 ns,1 B,,05,00,  ACK packet,D2,,.
0,FS,19,0:01.311.385,35.166 us,0 B,,05,00,Control Transfer,,,
1,FS,20,0:01.311.385,12.500 us,8 B,,05,00,   SETUP txn,40 01 04 04 00 00 00 00,,@...
2,FS,21,0:01.311.385,2.083 us,3 B,,05,00,  SETUP packet,2D 05 D0,,-..
2,FS,22,0:01.311.388,7.416 us,11 B,,05,00,  DATA0 packet,C3 40 01 04 04 00 00 00 00 5B 40,,.@...[@
2,FS,23,0:01.311.396,750 ns,1 B,,05,00,  ACK packet,D2,,.
1,FS,24,0:01.311.412,7.333 us,0 B,,05,00,   IN txn,,,
2,FS,25,0:01.311.412,2.083 us,3 B,,05,00,  IN packet,69 05 D0,,i..
2,FS,26,0:01.311.416,2.083 us,3 B,,05,00,  DATA1 packet,4B 00 00,,K..
2,FS,27,0:01.311.419,750 ns,1 B,,05,00,  ACK packet,D2,,.
0,FS,29,0:01.324.425,118.000 us,1 B,,05,00,Control Transfer,02,,.
1,FS,30,0:01.324.425,12.500 us,8 B,,05,00,   SETUP txn,C0 01 84 84 00 00 01 00,,
2,FS,31,0:01.324.425,2.083 us,3 B,,05,00,  SETUP packet,2D 05 D0,,-..
2,FS,32,0:01.324.428,7.416 us,11 B,,05,00,  DATA0 packet,C3 C0 01 84 84 00 00 01 00 4C AE,,.L.
2,FS,33,0:01.324.437,750 ns,1 B,,05,00,  ACK packet,D2,,.
1,FS,34,0:01.324.447,8.083 us,1 B,,05,00,   IN txn,02,,.
2,FS,35,0:01.324.447,2.083 us,3 B,,05,00,  IN packet,69 05 D0,,i..
2,FS,36,0:01.324.450,2.850 us,4 B,,05,00,  DATA1 packet,4B 02 C1 7E,,K..~
2,FS,37,0:01.324.454,750 ns,1 B,,05,00,  ACK packet,D2,,.
1,FS,38,0:01.324.536,7.083 us,0 B,,05,00,   OUT txn,,,
2,FS,39,0:01.324.536,2.083 us,3 B,,05,00,  OUT packet,E1 05 D0,,...
2,FS,40,0:01.324.539,2.083 us,3 B,,05,00,  DATA1 packet,4B 00 00,,K..
2,FS,41,0:01.324.542,750 ns,1 B,,05,00,  ACK packet,D2,,.
0,FS,43,0:01.326.799,52.833 us,1 B,,05,00,Control Transfer,FF,,.
1,FS,44,0:01.326.799,12.500 us,8 B,,05,00,   SETUP txn,C0 01 83 83 00 00 01 00,,
2,FS,45,0:01.326.799,2.083 us,3 B,,05,00,  SETUP packet,2D 05 D0,,-..
2,FS,46,0:01.326.802,7.516 us,11 B,,05,00,  DATA0 packet,C3 C0 01 83 83 00 00 01 00 F8 D9,,...
2,FS,47,0:01.326.811,750 ns,1 B,,05,00,  ACK packet,D2,,.
1,FS,48,0:01.326.826,8.083 us,1 B,,05,00,   IN txn,FF,,.
2,FS,49,0:01.326.826,2.083 us,3 B,,05,00,  IN packet,69 05 D0,,i..
2,FS,50,0:01.326.829,2.916 us,4 B,,05,00,  DATA1 packet,4B FF 00 FF,,K...
2,FS,51,0:01.326.833,750 ns,1 B,,05,00,  ACK packet,D2,,.
1,FS,52,0:01.326.845,7.166 us,0 B,,05,00,   OUT txn,,,
2,FS,53,0:01.326.845,2.083 us,3 B,,05,00,  OUT packet,E1 05 D0,,...
2,FS,54,0:01.326.848,2.083 us,3 B,,05,00,  DATA1 packet,4B 00 00,,K..
2,FS,55,0:01.326.851,750 ns,1 B,,05,00,  ACK packet,D2,,.
0,FS,57,0:01.340.406,50.416 us,1 B,,05,00,Control Transfer,02,,.
1,FS,58,0:01.340.406,12.500 us,8 B,,05,00,   SETUP txn,C0 01 84 84 00 00 01 00,,
2,FS,59,0:01.340.406,2.083 us,3 B,,05,00,  SETUP packet,2D 05 D0,,-..
2,FS,60,0:01.340.410,7.416 us,11 B,,05,00,  DATA0 packet,C3 C0 01 84 84 00 00 01 00 4C AE,,.L.
2,FS,61,0:01.340.418,750 ns,1 B,,05,00,  ACK packet,D2,,.
1,FS,62,0:01.340.431,8.083 us,1 B,,05,00,   IN txn,02,,.
2,FS,63,0:01.340.431,2.083 us,3 B,,05,00,  IN packet,69 05 D0,,i..
2,FS,64,0:01.340.434,2.850 

Re: pl2303 driver regression after commit 61fa8d694b854

[Mika Westerberg]

On Fri, Oct 25, 2013 at 03:01:37PM +0200, Frank Schäfer wrote:
  Tried few other baudrates  115200 and they don't work either.
 Urgh... has this device ever been working at baud rates  115200 ?

I have only used it as a serial console for a device and never tried baud
rates higher than 115200 before today.

 If yes, what's the last working kernel version ?
 Commit 8d48fdf689fe USB: PL2303: correctly handle baudrates above
 115200 could be relevant.
 
 Btw: do you have a TRENDnet TU-S9 v1.xR or v2.0R ?

It is v1.xR I believe.
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

pl2303 driver regression after commit 61fa8d694b854

[Mika Westerberg]

Hi,

Just noticed that after commit 61fa8d694b854 (usb: pl2303: also use the
divisor based baud rate encoding method for baud rates  115200 with HX
chips) my TRENDnet TU-S9 USB-to-serial adapter started corrupting data.

I added baud = 115200 check back to the comparison which makes the device
work for me again (I'm using it at 115200 bps):

if (type == type_0 || type == type_1 || type == HX_CLONE || baud = 115200)
baud = pl2303_baudrate_encode_direct(baud, type, buf);

The PL2303 chip has following markings if it helps:

PL-2303HX
LF10482D
TP37331HD

and here is the output of 'lsusb -vv' of that device:

Bus 002 Device 116: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   1.10
  bDeviceClass0 (Defined at Interface level)
  bDeviceSubClass 0 
  bDeviceProtocol 0 
  bMaxPacketSize064
  idVendor   0x067b Prolific Technology, Inc.
  idProduct  0x2303 PL2303 Serial Port
  bcdDevice4.00
  iManufacturer   1 Prolific Technology Inc. 
  iProduct2 USB-Serial Controller D
  iSerial 0 
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength   39
bNumInterfaces  1
bConfigurationValue 1
iConfiguration  0 
bmAttributes 0x80
  (Bus Powered)
MaxPower  100mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   3
  bInterfaceClass   255 Vendor Specific Class
  bInterfaceSubClass  0 
  bInterfaceProtocol  0 
  iInterface  0 
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81  EP 1 IN
bmAttributes3
  Transfer TypeInterrupt
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x000a  1x 10 bytes
bInterval   1
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02  EP 2 OUT
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0040  1x 64 bytes
bInterval   0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83  EP 3 IN
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0040  1x 64 bytes
bInterval   0
Device Status: 0x
  (Bus Powered)
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html