Re: USB driver resets

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,

Re: USB driver resets

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

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

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!

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

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): >

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

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

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

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

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

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

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

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

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

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

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

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: > > > >

Re: Dell thunderbolt docking station not working

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 thunder

Re: Dell thunderbolt docking station not working

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

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

ent 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

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

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.int

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

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

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

. 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/hos

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

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

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

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,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Re: pl2303 driver regression after commit 61fa8d694b854

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

Re: pl2303 driver regression after commit 61fa8d694b854

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

Re: pl2303 driver regression after commit 61fa8d694b854

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

pl2303 driver regression after commit 61fa8d694b854

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