Re: [PATCH] usb-storage: stop using block layer bounce buffers

[Christoph Hellwig]

On Sun, Apr 15, 2018 at 11:24:11AM -0400, Alan Stern wrote:
> On Sun, 15 Apr 2018, Christoph Hellwig wrote:
> 
> > USB host controllers now must handle highmem, so we can get rid of bounce
> > buffering highmem pages in the block layer.
> 
> Sorry, I don't quite understand what you are saying.  Do you mean that
> all USB host controllers now magically _do_ handle highmem?  Or do you
> mean that if they _don't_ handle highmem, we will not support them any
> more?

USB controller themselves never cared about highmem, drivers did.  For
PIO based controllers they'd have to kmap any address no in the kernel
drirect mapping.

Nothing in drivers/usb/host or the other diretories related to host
drivers calls page_address (only used in a single gadget) or sg_virt
(only used in a few upper level drivers), which makes me assume
semi-confidently that no USB host driver is not highmem aware these
days.

Greg, does this match your observation as the USB maintainer?
--
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] USB: serial: option: adding support for ublox R410M

[林上智]

> 
> Option is likely the right driver for this device.
> 
> qcaux was mainly for mobile phones that have a TTY (often cdc-acm) as the 
> modem port
> and a secondary DIAG/DM port driven by qcaux.  The DM port doesn't have an 
> interrupt
> endpoint thus it's not a normal modem port requiring the larger buffers of 
> option and its
> control signaling.
> 
> qcserial (as Bjorn mentioned) is only for actual Gobi-type devices with the 
> specific layouts
> and the firmware loading requirement where the 1K and 2K devices start in a 
> special
> 1-port mode waiting for firmware and then become 4-port devices on firmware 
> reboot.
> 
> Dan

Thank you all. I believe that many people are confused in selecting serial 
driver (option and qcserial) 
for QUALCOMM based module. This thread has provided clearly and properly 
presented the different
between them.

SZ

Re: [RFC PATCH] usb: gadget: composite Allow for larger configuration descriptors

[Joel Pepper]

And here is the actual packet capture that should have been attached in
the last mail


On 26.04.2018 20:26, Joel Pepper wrote:
> I have been doing some work with uvc gadgets, which mirrors the
> capabilities of actual webcams attached to a host port.
> During testing I ran into -EPIPE errors when trying to retrieve
> configurations for more complex devices.
>
> I tracked the errors down to running over the rather conservative
> buffer size of 1024 bytes for config descriptors. This size is
> insufficient when dealing with more realistic uvc gadgets,
> which need around 50 bytes per framesize per format.
> I have attached a packet capture from the setup of a Logitech C270
> (a very common webcam), which sends a config descriptor of 2530 bytes.
>
> I would have liked to go to 8192 immediately, but I have insufficient
> knowledge of the USB spec in general and linux
> and hardware implementations in particular, hence this RFC and the more
> conservative choice of 4096, which allows for a single versatile
> uvc-gadget while leaving headroom for other functions.
>
>
> Joel Pepper (1):
>   usb: gadget: composite Allow for larger configuration descriptors
>
>  include/linux/usb/composite.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>



logitech-c270-conf-desc-only.pcapng
Description: application/pcapng

Re: [PATCH stable v4.4+] r8152: add Linksys USB3GIGV1 id

[Grant Grundler]

On Thu, Apr 26, 2018 at 12:56 AM, Krzysztof Kozlowski  wrote:
> On Thu, Apr 26, 2018 at 2:40 AM, Grant Grundler  wrote:
>> On Wed, Apr 25, 2018 at 2:54 AM, Krzysztof Kozlowski 
>> wrote:
>>>
>>> commit 90841047a01b452cc8c3f9b990698b264143334a upstream
>>>
>>> This linksys dongle by default comes up in cdc_ether mode.
>>> This patch allows r8152 to claim the device:
>>>Bus 002 Device 002: ID 13b1:0041 Linksys
>>>
>>> Signed-off-by: Grant Grundler 
>>> Reviewed-by: Douglas Anderson 
>>> Signed-off-by: David S. Miller 
>>> [krzk: Rebase on v4.4]'
>>
>>
>> thanks krzk!
>>
>> FTR, to support RTL8153B (HW ID 0x6010), the follow patch series to bring
>> r8152 v1.09.9 driver from 4.14 kernel.org to 3 (of 5) older Chrome OS
>> kernels:
>>
>> 3.14:
>> https://chromium-review.googlesource.com/q/topic:%22update_r8152-3.14%22+(status:open%20OR%20status:merged)
>> 3.18:
>> https://chromium-review.googlesource.com/q/topic:%2522update-r8152-3.18%2522+(status:open+OR+status:merged)
>> 4.4:
>> https://chromium-review.googlesource.com/q/topic:%2522update_r8152-4.4%2522+(status:open+OR+status:merged)
>>
>> caveat: These series are not suitable directly for kernel.org submission
>> (extraneous stuff in the commit messages, order is different). Using the
>> original SHA1 (in each commit message), this can all be fixed up by
>> hand/simple scripts.
>
> Hi Grant,
>
> These are regular feature/patch backports so they do not fit into
> stable process. Only new quirks and IDs are accepted for stable.

Hi Krzysztof!
Sorry, I wasn't advocating for -stable inclusion. I shared in case
someone has unusually high USB ethernet requirements similar to Chrome
OS test lab which nearly all dongles I've tested can't provide.

Chrome OS test lab needs a USB ethernet dongle that reliably
negotiates a link (e.g. 10k iterations in a row). RTL8153 in general
are good (> 99.99% gets GigE link speed) but RTL8153B is the first
dongle that meets Chrome OS test lab requirements. The patch series
above is required to support RTL8153B.

cheers,
grant
--
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] USB: serial: option: adding support for ublox R410M

[Dan Williams]

On Thu, 2018-04-26 at 18:29 +0200, Johan Hovold wrote:
> On Thu, Apr 26, 2018 at 11:22:25PM +0700, Lars Melin wrote:
> > On 4/26/2018 23:12, Johan Hovold wrote:
> > > On Thu, Apr 26, 2018 at 06:40:46PM +0700, Lars Melin wrote:
> > > > On 4/26/2018 18:39, Lars Melin wrote:
> > > > > On 4/26/2018 18:19, Bjørn Mork wrote:
> > > > > > Anyway, Qualcomm based designs are definitely handled by
> > > > > > both drivers.
> > > > > > Using qcserial only makes sense if the interface layout
> > > > > > matches one of
> > > > > > the defined shared schemes, which currently are:
> > > > > > 
> > > > > >  QCSERIAL_G2K = 0,/* Gobi 2000 */
> > > > > >  QCSERIAL_G1K = 1,/* Gobi 1000 */
> > > > > >  QCSERIAL_SWI = 2,/* Sierra Wireless */
> > > > > >  QCSERIAL_HWI = 3,/* Huawei */
> > > > > 
> > > > > It seems to me that this Quectel device matches the interface
> > > > > layout for
> > > > > Gobi1K:
> > > Yeah, but qcserial appears to select a different altsetting for
> > > the DM
> > > port for Gobi 1000, an altsetting which this particular device
> > > does not
> > > have.
> > > 
> > > I didn't re-read the full thread I referred to earlier, but I
> > > think in
> > > it, Dan mentioned Gobi 1000 device requiring firmware to be
> > > loaded too.
> > > 
> > > So if it's not a G1K device, we probably shouldn't be using
> > > qcserial
> > > even if the interface layout happens to match.
> > Good point, I forgot about the required firmware loading for
> > Gobi1K.
> > So this device should be handled by the option driver.
> 
> Yeah, we probably should document all of this at some point. :)
> 
> I didn't include the patch in this weeks -rc updates, but I've queued
> it
> up for the next batch.

Option is likely the right driver for this device.

qcaux was mainly for mobile phones that have a TTY (often cdc-acm) as
the modem port and a secondary DIAG/DM port driven by qcaux.  The DM
port doesn't have an interrupt endpoint thus it's not a normal modem
port requiring the larger buffers of option and its control signaling.

qcserial (as Bjorn mentioned) is only for actual Gobi-type devices with
the specific layouts and the firmware loading requirement where the 1K
and 2K devices start in a special 1-port mode waiting for firmware and
then become 4-port devices on firmware reboot.

Dan
--
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 mouse and PS2 Keyboard freeze all of a sudden in Ubuntu Mate 16.04.4

[Greg KH]

On Thu, Apr 26, 2018 at 05:45:46PM +0300, Kyprianos Papadimitriou wrote:
> 
> 
> On 26/04/2018 01:12 μμ, Kyprianos Papadimitriou wrote:
> > 
> > 
> > On 26/04/2018 11:39 πμ, Greg KH wrote:
> > > A: Because it messes up the order in which people normally read text.
> > > Q: Why is top-posting such a bad thing?
> > > A: Top-posting.
> > > Q: What is the most annoying thing in e-mail?
> > > 
> > > A: No.
> > > Q: Should I include quotations after my reply?
> > > 
> > > http://daringfireball.net/2007/07/on_top
> > > 
> > > On Thu, Apr 26, 2018 at 11:31:23AM +0300, Kyprianos Papadimitriou wrote:
> > > > Dear Greg,
> > > > 
> > > > With regard to buffer overflow, check the following thread, at the end
> > > > 
> > > > https://ubuntuforums.org/showthread.php?t=2342985
> > > Ah, you were referring to a device bug, not a kernel issue, that makes
> > > more sense.
> > > 
> > > Did you try the "always poll" quirk for this device to see if that
> > > solved the issue for you?  That might be all that is needed.
> > > 
> > > thanks,
> > > 
> > > greg k-h
> > > .
> > > 
> > 
> > you mean the following in /etc/default/grub/
> > 
> > GRUB_CMDLINE_LINUX_DEFAULT="quiet splash usbcore.autosuspend=-1
> > usbhid.quirks=0x046d:0xc404:0x0400"
> > 
> > ?
> > 
> > Command "lsusb" gives for the  TrackMan Wheel :
> > Bus 002 Device 009: ID 046d:c404 Logitech, Inc. TrackMan Wheel
> > 
> > 
> Is this a device bug, or a kernel bug?
> 
> According to the following thread, I thought it is a kernel bug
> 
> https://ubuntuforums.org/showthread.php?t=2342985
> 
> 
> And the contributor at the end suggests sending an e-mail to fix it in the
> upcoming kernel, to linux-usb@vger.kernel.org
> 

If the above command line works, then yes, we need to add a quirk to the
kernel to handle this hardware.

thanks,

greg k-h
--
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 mouse and PS2 Keyboard freeze all of a sudden in Ubuntu Mate 16.04.4

[Greg KH]

On Thu, Apr 26, 2018 at 01:12:19PM +0300, Kyprianos Papadimitriou wrote:
> 
> On 26/04/2018 11:39 πμ, Greg KH wrote:
> > A: Because it messes up the order in which people normally read text.
> > Q: Why is top-posting such a bad thing?
> > A: Top-posting.
> > Q: What is the most annoying thing in e-mail?
> > 
> > A: No.
> > Q: Should I include quotations after my reply?
> > 
> > http://daringfireball.net/2007/07/on_top
> > 
> > On Thu, Apr 26, 2018 at 11:31:23AM +0300, Kyprianos Papadimitriou wrote:
> > > Dear Greg,
> > > 
> > > With regard to buffer overflow, check the following thread, at the end
> > > 
> > > https://ubuntuforums.org/showthread.php?t=2342985
> > Ah, you were referring to a device bug, not a kernel issue, that makes
> > more sense.
> > 
> > Did you try the "always poll" quirk for this device to see if that
> > solved the issue for you?  That might be all that is needed.
> > 
> > thanks,
> > 
> > greg k-h
> > .
> > 
> 
> you mean the following in /etc/default/grub/
> 
> GRUB_CMDLINE_LINUX_DEFAULT="quiet splash usbcore.autosuspend=-1
> usbhid.quirks=0x046d:0xc404:0x0400"
> 
> ?
> 
> Command "lsusb" gives for the  TrackMan Wheel :
> Bus 002 Device 009: ID 046d:c404 Logitech, Inc. TrackMan Wheel

Yes, did you try that?  What happened if you do?

thanks,

greg k-h
--
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

[RFC PATCH] usb: gadget: composite Allow for larger configuration descriptors

[Joel Pepper]

The composite framework allows us to create gadgets composed from many
different functions, which need to fit into a single configuration
descriptor.

Some functions (like uvc) can produce configuration descriptors upwards
of 2500 bytes on their own.

This patch increases the limit from 1024 bytes to 4096.

Signed-off-by: Joel Pepper 
---
 include/linux/usb/composite.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/usb/composite.h b/include/linux/usb/composite.h
index 4b6b928..8675e14 100644
--- a/include/linux/usb/composite.h
+++ b/include/linux/usb/composite.h
@@ -52,7 +52,7 @@
 #define USB_GADGET_DELAYED_STATUS   0x7fff /* Impossibly large value */
 
 /* big enough to hold our biggest descriptor */
-#define USB_COMP_EP0_BUFSIZ1024
+#define USB_COMP_EP0_BUFSIZ4096
 
 /* OS feature descriptor length <= 4kB */
 #define USB_COMP_EP0_OS_DESC_BUFSIZ4096
-- 
2.1.4

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

[RFC PATCH] usb: gadget: composite Allow for larger configuration descriptors

[Joel Pepper]

I have been doing some work with uvc gadgets, which mirrors the
capabilities of actual webcams attached to a host port.
During testing I ran into -EPIPE errors when trying to retrieve
configurations for more complex devices.

I tracked the errors down to running over the rather conservative
buffer size of 1024 bytes for config descriptors. This size is
insufficient when dealing with more realistic uvc gadgets,
which need around 50 bytes per framesize per format.
I have attached a packet capture from the setup of a Logitech C270
(a very common webcam), which sends a config descriptor of 2530 bytes.

I would have liked to go to 8192 immediately, but I have insufficient
knowledge of the USB spec in general and linux
and hardware implementations in particular, hence this RFC and the more
conservative choice of 4096, which allows for a single versatile
uvc-gadget while leaving headroom for other functions.


Joel Pepper (1):
  usb: gadget: composite Allow for larger configuration descriptors

 include/linux/usb/composite.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

-- 
2.1.4

--
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: [GIT PULL] USB-serial fixes for v4.17-rc3

[Greg Kroah-Hartman]

On Thu, Apr 26, 2018 at 06:23:16PM +0200, Johan Hovold wrote:
> The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
> 
>   Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
> 
> are available in the Git repository at:
> 
>   https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial.git 
> tags/usb-serial-4.17-rc3

Pulled and pushed out, thanks.

greg k-h
--
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] USB: serial: option: adding support for ublox R410M

[Johan Hovold]

On Thu, Apr 26, 2018 at 11:22:25PM +0700, Lars Melin wrote:
> On 4/26/2018 23:12, Johan Hovold wrote:
> > On Thu, Apr 26, 2018 at 06:40:46PM +0700, Lars Melin wrote:
> >> On 4/26/2018 18:39, Lars Melin wrote:
> >>> On 4/26/2018 18:19, Bjørn Mork wrote:
>  Anyway, Qualcomm based designs are definitely handled by both drivers.
>  Using qcserial only makes sense if the interface layout matches one of
>  the defined shared schemes, which currently are:
> 
>   QCSERIAL_G2K = 0,    /* Gobi 2000 */
>   QCSERIAL_G1K = 1,    /* Gobi 1000 */
>   QCSERIAL_SWI = 2,    /* Sierra Wireless */
>   QCSERIAL_HWI = 3,    /* Huawei */
> >>>
> >>> It seems to me that this Quectel device matches the interface layout for
> >>> Gobi1K:

> > Yeah, but qcserial appears to select a different altsetting for the DM
> > port for Gobi 1000, an altsetting which this particular device does not
> > have.
> > 
> > I didn't re-read the full thread I referred to earlier, but I think in
> > it, Dan mentioned Gobi 1000 device requiring firmware to be loaded too.
> > 
> > So if it's not a G1K device, we probably shouldn't be using qcserial
> > even if the interface layout happens to match.

> Good point, I forgot about the required firmware loading for Gobi1K.
> So this device should be handled by the option driver.

Yeah, we probably should document all of this at some point. :)

I didn't include the patch in this weeks -rc updates, but I've queued it
up for the next batch.

Thanks everyone.

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

[GIT PULL] USB-serial fixes for v4.17-rc3

[Johan Hovold]

The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:

  Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)

are available in the Git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial.git 
tags/usb-serial-4.17-rc3

for you to fetch changes up to 470b5d6f0cf4674be2d1ec94e54283a1770b6a1a:

  USB: serial: ftdi_sio: use jtag quirk for Arrow USB Blaster (2018-04-16 
11:19:21 +0200)


USB-serial fixes for v4.17-rc3

Here are a few device ids for -rc3, including a new "simple driver".

All have been in linux-next with no reported issues.

Signed-off-by: Johan Hovold 


Collin May (1):
  USB: serial: simple: add libtransistor console

Kyle Roeschley (1):
  USB: serial: cp210x: add ID for NI USB serial console

Vasyl Vavrychuk (1):
  USB: serial: ftdi_sio: use jtag quirk for Arrow USB Blaster

 drivers/usb/serial/Kconfig | 1 +
 drivers/usb/serial/cp210x.c| 1 +
 drivers/usb/serial/ftdi_sio.c  | 3 ++-
 drivers/usb/serial/usb-serial-simple.c | 7 +++
 4 files changed, 11 insertions(+), 1 deletion(-)
--
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] USB: serial: option: adding support for ublox R410M

[Lars Melin]

On 4/26/2018 23:12, Johan Hovold wrote:

On Thu, Apr 26, 2018 at 06:40:46PM +0700, Lars Melin wrote:

On 4/26/2018 18:39, Lars Melin wrote:

On 4/26/2018 18:19, Bjørn Mork wrote:

Anyway, Qualcomm based designs are definitely handled by both drivers.
Using qcserial only makes sense if the interface layout matches one of
the defined shared schemes, which currently are:

 QCSERIAL_G2K = 0,    /* Gobi 2000 */
 QCSERIAL_G1K = 1,    /* Gobi 1000 */
 QCSERIAL_SWI = 2,    /* Sierra Wireless */
 QCSERIAL_HWI = 3,    /* Huawei */


It seems to me that this Quectel device matches the interface layout for
Gobi1K:

   * Gobi 1K USB layout:
   * 0: DM/DIAG (use libqcdm from ModemManager for communication)
   * 1: serial port (doesn't respond)
   * 2: AT-capable modem port
   * 3: QMI/net
   */



Ublox, not Quectel..


Yeah, but qcserial appears to select a different altsetting for the DM
port for Gobi 1000, an altsetting which this particular device does not
have.

I didn't re-read the full thread I referred to earlier, but I think in
it, Dan mentioned Gobi 1000 device requiring firmware to be loaded too.

So if it's not a G1K device, we probably shouldn't be using qcserial
even if the interface layout happens to match.

Thanks,
Johan


Good point, I forgot about the required firmware loading for Gobi1K.
So this device should be handled by the option driver.

/Lars


--
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] USB: serial: option: adding support for ublox R410M

[Johan Hovold]

On Thu, Apr 26, 2018 at 06:40:46PM +0700, Lars Melin wrote:
> On 4/26/2018 18:39, Lars Melin wrote:
> > On 4/26/2018 18:19, Bjørn Mork wrote:
> >> Anyway, Qualcomm based designs are definitely handled by both drivers.
> >> Using qcserial only makes sense if the interface layout matches one of
> >> the defined shared schemes, which currently are:
> >>
> >> QCSERIAL_G2K = 0,    /* Gobi 2000 */
> >> QCSERIAL_G1K = 1,    /* Gobi 1000 */
> >> QCSERIAL_SWI = 2,    /* Sierra Wireless */
> >> QCSERIAL_HWI = 3,    /* Huawei */
> > 
> > It seems to me that this Quectel device matches the interface layout for 
> > Gobi1K:
> > 
> >   * Gobi 1K USB layout:
> >   * 0: DM/DIAG (use libqcdm from ModemManager for communication)
> >   * 1: serial port (doesn't respond)
> >   * 2: AT-capable modem port
> >   * 3: QMI/net
> >   */

> Ublox, not Quectel..

Yeah, but qcserial appears to select a different altsetting for the DM
port for Gobi 1000, an altsetting which this particular device does not
have.

I didn't re-read the full thread I referred to earlier, but I think in
it, Dan mentioned Gobi 1000 device requiring firmware to be loaded too. 

So if it's not a G1K device, we probably shouldn't be using qcserial
even if the interface layout happens to match.

Thanks,
Johan
--
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

[PATCH V2 3/3] usb: xhci: tegra: Add support for managing powergates

[Jon Hunter]

The Tegra XHCI controller requires that the XUSBA (for superspeed) and
XUSBC (for host) power-domains are enabled. Commit 8df127456f29
("soc/tegra: pmc: Enable XUSB partitions on boot") was added to force
on these power-domains if the XHCI driver is enabled while proper
power-domain support is added, to ensure the device did not hang on
boot. However, rather than forcing on these power-domains in the PMC
driver we can use the legacy Tegra powergate APIs to turn on these
power-domains during the probe of the Tegra XHCI driver.

In the near future we plan to move the Tegra XHCI driver to use the
generic PM domain framework for power-domains and so to prepare for
this only use the legacy Tegra powergate API if there is not PM
domain associated with device (ie. dev.pm_domain is NULL). Please
note that in the future the superspeed and host resets will be handled
by the generic PM domain provider and so these are only these are only
needed in the case where there is no generic PM domain.

Signed-off-by: Jon Hunter 
---

Changes since V1:
- None

 drivers/usb/host/xhci-tegra.c | 68 +++
 1 file changed, 49 insertions(+), 19 deletions(-)

diff --git a/drivers/usb/host/xhci-tegra.c b/drivers/usb/host/xhci-tegra.c
index 85f2381883ad..862f85f4c8bb 100644
--- a/drivers/usb/host/xhci-tegra.c
+++ b/drivers/usb/host/xhci-tegra.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "xhci.h"
 
@@ -975,20 +976,6 @@ static int tegra_xusb_probe(struct platform_device *pdev)
if (IS_ERR(tegra->padctl))
return PTR_ERR(tegra->padctl);
 
-   tegra->host_rst = devm_reset_control_get(>dev, "xusb_host");
-   if (IS_ERR(tegra->host_rst)) {
-   err = PTR_ERR(tegra->host_rst);
-   dev_err(>dev, "failed to get xusb_host reset: %d\n", err);
-   goto put_padctl;
-   }
-
-   tegra->ss_rst = devm_reset_control_get(>dev, "xusb_ss");
-   if (IS_ERR(tegra->ss_rst)) {
-   err = PTR_ERR(tegra->ss_rst);
-   dev_err(>dev, "failed to get xusb_ss reset: %d\n", err);
-   goto put_padctl;
-   }
-
tegra->host_clk = devm_clk_get(>dev, "xusb_host");
if (IS_ERR(tegra->host_clk)) {
err = PTR_ERR(tegra->host_clk);
@@ -1052,11 +1039,48 @@ static int tegra_xusb_probe(struct platform_device 
*pdev)
goto put_padctl;
}
 
+   if (!pdev->dev.pm_domain) {
+   tegra->host_rst = devm_reset_control_get(>dev,
+"xusb_host");
+   if (IS_ERR(tegra->host_rst)) {
+   err = PTR_ERR(tegra->host_rst);
+   dev_err(>dev,
+   "failed to get xusb_host reset: %d\n", err);
+   goto put_padctl;
+   }
+
+   tegra->ss_rst = devm_reset_control_get(>dev, "xusb_ss");
+   if (IS_ERR(tegra->ss_rst)) {
+   err = PTR_ERR(tegra->ss_rst);
+   dev_err(>dev, "failed to get xusb_ss reset: %d\n",
+   err);
+   goto put_padctl;
+   }
+
+   err = tegra_powergate_sequence_power_up(TEGRA_POWERGATE_XUSBA,
+   tegra->ss_clk,
+   tegra->ss_rst);
+   if (err) {
+   dev_err(>dev,
+   "failed to enable XUSBA domain: %d\n", err);
+   goto put_padctl;
+   }
+
+   err = tegra_powergate_sequence_power_up(TEGRA_POWERGATE_XUSBC,
+   tegra->host_clk,
+   tegra->host_rst);
+   if (err) {
+   dev_err(>dev,
+   "failed to enable XUSBC domain: %d\n", err);
+   goto disable_xusba;
+   }
+   }
+
tegra->supplies = devm_kcalloc(>dev, tegra->soc->num_supplies,
   sizeof(*tegra->supplies), GFP_KERNEL);
if (!tegra->supplies) {
err = -ENOMEM;
-   goto put_padctl;
+   goto disable_xusbc;
}
 
for (i = 0; i < tegra->soc->num_supplies; i++)
@@ -1066,7 +1090,7 @@ static int tegra_xusb_probe(struct platform_device *pdev)
  tegra->supplies);
if (err) {
dev_err(>dev, "failed to get regulators: %d\n", err);
-   goto put_padctl;
+   goto disable_xusbc;
}
 
for (i = 0; i < tegra->soc->num_types; i++)
@@ -1076,7 +1100,7 @@ static int tegra_xusb_probe(struct platform_device *pdev)
   sizeof(*tegra->phys), GFP_KERNEL);
if 

[PATCH V2 2/3] usb: xhci: tegra: Add runtime PM support

[Jon Hunter]

Add runtime PM support to the Tegra XHCI driver and move the function
calls to enable/disable the clocks, regulators and PHY into the runtime
PM callbacks.

Signed-off-by: Jon Hunter 
---

Changes since V1:
- Re-worked change to handle case where runtime PM is disabled.

 drivers/usb/host/xhci-tegra.c | 89 ++-
 1 file changed, 63 insertions(+), 26 deletions(-)

diff --git a/drivers/usb/host/xhci-tegra.c b/drivers/usb/host/xhci-tegra.c
index 02b0b24faa58..85f2381883ad 100644
--- a/drivers/usb/host/xhci-tegra.c
+++ b/drivers/usb/host/xhci-tegra.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -761,6 +762,50 @@ static void tegra_xusb_phy_disable(struct tegra_xusb 
*tegra)
}
 }
 
+static int tegra_xusb_runtime_suspend(struct device *dev)
+{
+   struct tegra_xusb *tegra = dev_get_drvdata(dev);
+
+   tegra_xusb_phy_disable(tegra);
+   regulator_bulk_disable(tegra->soc->num_supplies, tegra->supplies);
+   tegra_xusb_clk_disable(tegra);
+
+   return 0;
+}
+
+static int tegra_xusb_runtime_resume(struct device *dev)
+{
+   struct tegra_xusb *tegra = dev_get_drvdata(dev);
+   int err;
+
+   err = tegra_xusb_clk_enable(tegra);
+   if (err) {
+   dev_err(dev, "failed to enable clocks: %d\n", err);
+   return err;
+   }
+
+   err = regulator_bulk_enable(tegra->soc->num_supplies, tegra->supplies);
+   if (err) {
+   dev_err(dev, "failed to enable regulators: %d\n", err);
+   goto disable_clk;
+   }
+
+   err = tegra_xusb_phy_enable(tegra);
+   if (err < 0) {
+   dev_err(dev, "failed to enable PHYs: %d\n", err);
+   goto disable_regulator;
+   }
+
+   return 0;
+
+disable_regulator:
+   regulator_bulk_disable(tegra->soc->num_supplies, tegra->supplies);
+disable_clk:
+   tegra_xusb_clk_disable(tegra);
+   return err;
+}
+
+
 static int tegra_xusb_load_firmware(struct tegra_xusb *tegra)
 {
unsigned int code_tag_blocks, code_size_blocks, code_blocks;
@@ -1067,22 +1112,15 @@ static int tegra_xusb_probe(struct platform_device 
*pdev)
 */
platform_set_drvdata(pdev, tegra);
 
-   err = tegra_xusb_clk_enable(tegra);
-   if (err) {
-   dev_err(>dev, "failed to enable clocks: %d\n", err);
-   goto put_usb2;
-   }
+   pm_runtime_enable(>dev);
+   if (!pm_runtime_enabled(>dev))
+   err = pm_runtime_get_sync(>dev);
+   else
+   err = tegra_xusb_runtime_resume(>dev);
 
-   err = regulator_bulk_enable(tegra->soc->num_supplies, tegra->supplies);
-   if (err) {
-   dev_err(>dev, "failed to enable regulators: %d\n", err);
-   goto disable_clk;
-   }
-
-   err = tegra_xusb_phy_enable(tegra);
if (err < 0) {
-   dev_err(>dev, "failed to enable PHYs: %d\n", err);
-   goto disable_regulator;
+   dev_err(>dev, "failed to enable device: %d\n", err);
+   goto disable_rpm;
}
 
tegra_xusb_ipfs_config(tegra, regs);
@@ -1090,7 +1128,7 @@ static int tegra_xusb_probe(struct platform_device *pdev)
err = tegra_xusb_load_firmware(tegra);
if (err < 0) {
dev_err(>dev, "failed to load firmware: %d\n", err);
-   goto disable_phy;
+   goto put_rpm;
}
 
tegra->hcd->regs = tegra->regs;
@@ -1100,7 +1138,7 @@ static int tegra_xusb_probe(struct platform_device *pdev)
err = usb_add_hcd(tegra->hcd, tegra->xhci_irq, IRQF_SHARED);
if (err < 0) {
dev_err(>dev, "failed to add USB HCD: %d\n", err);
-   goto disable_phy;
+   goto put_rpm;
}
 
device_wakeup_enable(tegra->hcd->self.controller);
@@ -1155,13 +1193,11 @@ static int tegra_xusb_probe(struct platform_device 
*pdev)
usb_put_hcd(xhci->shared_hcd);
 remove_usb2:
usb_remove_hcd(tegra->hcd);
-disable_phy:
-   tegra_xusb_phy_disable(tegra);
-disable_regulator:
-   regulator_bulk_disable(tegra->soc->num_supplies, tegra->supplies);
-disable_clk:
-   tegra_xusb_clk_disable(tegra);
-put_usb2:
+put_rpm:
+   if (!pm_runtime_status_suspended(>dev))
+   tegra_xusb_runtime_suspend(>dev);
+disable_rpm:
+   pm_runtime_disable(>dev);
usb_put_hcd(tegra->hcd);
 put_padctl:
tegra_xusb_padctl_put(tegra->padctl);
@@ -1181,9 +1217,8 @@ static int tegra_xusb_remove(struct platform_device *pdev)
dma_free_coherent(>dev, tegra->fw.size, tegra->fw.virt,
  tegra->fw.phys);
 
-   tegra_xusb_phy_disable(tegra);
-   regulator_bulk_disable(tegra->soc->num_supplies, tegra->supplies);
-   tegra_xusb_clk_disable(tegra);
+   pm_runtime_put_sync(>dev);
+   pm_runtime_disable(>dev);
 

[PATCH V2 1/3] usb: xhci: tegra: Prepare for adding runtime PM support

[Jon Hunter]

When adding runtime PM support to the Tegra XHCI driver, it is desirable
to move the function calls to enable the clocks, regulators and PHY from
the tegra_xusb_probe into the runtime PM handlers. Currently, the
clocks, regulators and PHY are all enabled before we call
usb_create_hcd() in tegra_xusb_probe(), however, we cannot call
pm_runtime_get_sync() at this point because the platform device data is
not yet initialised. Fortunately, the function usb_create_hcd() can be
called before we enable the clocks, regulators and PHY and so prepare
for adding runtime PM support, by moving the call to usb_create_hcd()
before we enable the hardware.

Signed-off-by: Jon Hunter 
---

Changes since V1:
- None

 drivers/usb/host/xhci-tegra.c | 34 +-
 1 file changed, 17 insertions(+), 17 deletions(-)

diff --git a/drivers/usb/host/xhci-tegra.c b/drivers/usb/host/xhci-tegra.c
index 2c076ea80522..02b0b24faa58 100644
--- a/drivers/usb/host/xhci-tegra.c
+++ b/drivers/usb/host/xhci-tegra.c
@@ -1054,10 +1054,23 @@ static int tegra_xusb_probe(struct platform_device 
*pdev)
}
}
 
+   tegra->hcd = usb_create_hcd(_xhci_hc_driver, >dev,
+   dev_name(>dev));
+   if (!tegra->hcd) {
+   err = -ENOMEM;
+   goto put_padctl;
+   }
+
+   /*
+* This must happen after usb_create_hcd(), because usb_create_hcd()
+* will overwrite the drvdata of the device with the hcd it creates.
+*/
+   platform_set_drvdata(pdev, tegra);
+
err = tegra_xusb_clk_enable(tegra);
if (err) {
dev_err(>dev, "failed to enable clocks: %d\n", err);
-   goto put_padctl;
+   goto put_usb2;
}
 
err = regulator_bulk_enable(tegra->soc->num_supplies, tegra->supplies);
@@ -1080,19 +1093,6 @@ static int tegra_xusb_probe(struct platform_device *pdev)
goto disable_phy;
}
 
-   tegra->hcd = usb_create_hcd(_xhci_hc_driver, >dev,
-   dev_name(>dev));
-   if (!tegra->hcd) {
-   err = -ENOMEM;
-   goto disable_phy;
-   }
-
-   /*
-* This must happen after usb_create_hcd(), because usb_create_hcd()
-* will overwrite the drvdata of the device with the hcd it creates.
-*/
-   platform_set_drvdata(pdev, tegra);
-
tegra->hcd->regs = tegra->regs;
tegra->hcd->rsrc_start = regs->start;
tegra->hcd->rsrc_len = resource_size(regs);
@@ -1100,7 +1100,7 @@ static int tegra_xusb_probe(struct platform_device *pdev)
err = usb_add_hcd(tegra->hcd, tegra->xhci_irq, IRQF_SHARED);
if (err < 0) {
dev_err(>dev, "failed to add USB HCD: %d\n", err);
-   goto put_usb2;
+   goto disable_phy;
}
 
device_wakeup_enable(tegra->hcd->self.controller);
@@ -1155,14 +1155,14 @@ static int tegra_xusb_probe(struct platform_device 
*pdev)
usb_put_hcd(xhci->shared_hcd);
 remove_usb2:
usb_remove_hcd(tegra->hcd);
-put_usb2:
-   usb_put_hcd(tegra->hcd);
 disable_phy:
tegra_xusb_phy_disable(tegra);
 disable_regulator:
regulator_bulk_disable(tegra->soc->num_supplies, tegra->supplies);
 disable_clk:
tegra_xusb_clk_disable(tegra);
+put_usb2:
+   usb_put_hcd(tegra->hcd);
 put_padctl:
tegra_xusb_padctl_put(tegra->padctl);
return err;
-- 
2.7.4

--
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 1/3] usb: musb: gadget: fix to_musb_request() to not return NULL

[Bin Liu]

On Thu, Apr 26, 2018 at 11:25:16AM +0530, Sekhar Nori wrote:
> On Thursday 26 April 2018 11:23 AM, Sekhar Nori wrote:
> > On Thursday 19 April 2018 01:35 AM, Bin Liu wrote:
> >> The gadget function drivers should ensure the usb_request parameter
> >> passed in is not NULL. UDC core doesn't check if it is NULL, so MUSB
> >> driver shouldn't have to check it either.
> >>
> >> Convert to_musb_request() to a simple macro to not directly return NULL
> >> to avoid warnings from code static analysis tools.
> >>
> >> Signed-off-by: Bin Liu 
> >> ---
> >>  drivers/usb/musb/musb_gadget.h | 5 +
> >>  1 file changed, 1 insertion(+), 4 deletions(-)
> >>
> >> diff --git a/drivers/usb/musb/musb_gadget.h 
> >> b/drivers/usb/musb/musb_gadget.h
> >> index 9c34aca06db6..466877b471ef 100644
> >> --- a/drivers/usb/musb/musb_gadget.h
> >> +++ b/drivers/usb/musb/musb_gadget.h
> >> @@ -60,10 +60,7 @@ struct musb_request {
> >>enum buffer_map_state map_state;
> >>  };
> >>  
> >> -static inline struct musb_request *to_musb_request(struct usb_request 
> >> *req)
> >> -{
> >> -  return req ? container_of(req, struct musb_request, request) : NULL;
> >> -}
> >> +#define to_musb_request(r)(container_of(r, struct musb_request, 
> >> request))
> > 
> > Unnecessary parens over container_of
> 
> And 'r' can actually be parenthesized for safety.

Thanks. v2 is sent.

Regards,
-Bin.
--
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

[PATCH 3/3] usb: musb: host: fix potential NULL pointer dereference

[Bin Liu]

musb_start_urb() doesn't check the 3rd pass-in parameter if it is NULL.
But in musb_bulk_nak_timeout() the parameter passed to musb_start_urb()
is returned from first_qh(), which could be NULL.

So wrap the musb_start_urb() call here with a if condition check to
avoid the potential NULL pointer dereference.

Signed-off-by: Bin Liu 
---
v2: no changes.

 drivers/usb/musb/musb_host.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
index e50438ae241e..218aadef5bbf 100644
--- a/drivers/usb/musb/musb_host.c
+++ b/drivers/usb/musb/musb_host.c
@@ -990,7 +990,9 @@ static void musb_bulk_nak_timeout(struct musb *musb, struct 
musb_hw_ep *ep,
/* set tx_reinit and schedule the next qh */
ep->tx_reinit = 1;
}
-   musb_start_urb(musb, is_in, next_qh);
+
+   if (next_qh)
+   musb_start_urb(musb, is_in, next_qh);
}
 }
 
-- 
1.9.1

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

[PATCH v2 2/3] usb: musb: gadget: fix to_musb_ep() to not return NULL

[Bin Liu]

UDC core ensures the usb_ep parameter passed in is not NULL, so
checking if (ep != NULL) is pointless.

Convert to_musb_ep() to a simple macro to not directly return NULL to
avoid warnings from code static analysis tools.

Signed-off-by: Bin Liu 
---
v2: revised the parentheses.

 drivers/usb/musb/musb_gadget.h | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/usb/musb/musb_gadget.h b/drivers/usb/musb/musb_gadget.h
index 06d60848337f..d02663660813 100644
--- a/drivers/usb/musb/musb_gadget.h
+++ b/drivers/usb/musb/musb_gadget.h
@@ -96,10 +96,7 @@ struct musb_ep {
u8  hb_mult;
 };
 
-static inline struct musb_ep *to_musb_ep(struct usb_ep *ep)
-{
-   return ep ? container_of(ep, struct musb_ep, end_point) : NULL;
-}
+#define to_musb_ep(ep) container_of((ep), struct musb_ep, end_point)
 
 static inline struct musb_request *next_request(struct musb_ep *ep)
 {
-- 
1.9.1

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

[PATCH v2 1/3] usb: musb: gadget: fix to_musb_request() to not return NULL

[Bin Liu]

The gadget function drivers should ensure the usb_request parameter
passed in is not NULL. UDC core doesn't check if it is NULL, so MUSB
driver shouldn't have to check it either.

Convert to_musb_request() to a simple macro to not directly return NULL
to avoid warnings from code static analysis tools.

Signed-off-by: Bin Liu 
---
v2: revised the parentheses.

 drivers/usb/musb/musb_gadget.h | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/usb/musb/musb_gadget.h b/drivers/usb/musb/musb_gadget.h
index 9c34aca06db6..06d60848337f 100644
--- a/drivers/usb/musb/musb_gadget.h
+++ b/drivers/usb/musb/musb_gadget.h
@@ -60,10 +60,7 @@ struct musb_request {
enum buffer_map_state map_state;
 };
 
-static inline struct musb_request *to_musb_request(struct usb_request *req)
-{
-   return req ? container_of(req, struct musb_request, request) : NULL;
-}
+#define to_musb_request(r) container_of((r), struct musb_request, request)
 
 extern struct usb_request *
 musb_alloc_request(struct usb_ep *ep, gfp_t gfp_flags);
-- 
1.9.1

--
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] USB: serial: option: adding support for ublox R410M

[Lars Melin]

On 4/26/2018 18:39, Lars Melin wrote:

On 4/26/2018 18:19, Bjørn Mork wrote:

Anyway, Qualcomm based designs are definitely handled by both drivers.
Using qcserial only makes sense if the interface layout matches one of
the defined shared schemes, which currently are:

QCSERIAL_G2K = 0,    /* Gobi 2000 */
QCSERIAL_G1K = 1,    /* Gobi 1000 */
QCSERIAL_SWI = 2,    /* Sierra Wireless */
QCSERIAL_HWI = 3,    /* Huawei */


It seems to me that this Quectel device matches the interface layout for 
Gobi1K:


  * Gobi 1K USB layout:
  * 0: DM/DIAG (use libqcdm from ModemManager for communication)
  * 1: serial port (doesn't respond)
  * 2: AT-capable modem port
  * 3: QMI/net
  */

/Lars


Ublox, not Quectel..

--
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] USB: serial: option: adding support for ublox R410M

[Lars Melin]

On 4/26/2018 18:19, Bjørn Mork wrote:

Anyway, Qualcomm based designs are definitely handled by both drivers.
Using qcserial only makes sense if the interface layout matches one of
the defined shared schemes, which currently are:

QCSERIAL_G2K = 0,   /* Gobi 2000 */
QCSERIAL_G1K = 1,   /* Gobi 1000 */
QCSERIAL_SWI = 2,   /* Sierra Wireless */
QCSERIAL_HWI = 3,   /* Huawei */


It seems to me that this Quectel device matches the interface layout for 
Gobi1K:


 * Gobi 1K USB layout:
 * 0: DM/DIAG (use libqcdm from ModemManager for communication)
 * 1: serial port (doesn't respond)
 * 2: AT-capable modem port
 * 3: QMI/net
 */

/Lars
--
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

[PATCH/RFC v2 5/6] usb: gadget: udc: renesas_usb3: add support for a usb role switch

[Yoshihiro Shimoda]

This patch adds support for a usb role switch driver. And then,
this driver uses the usb role switch APIs instead of hardware
access to initialize usb host side at specific timings.

Signed-off-by: Yoshihiro Shimoda 
---
 drivers/usb/gadget/udc/Kconfig|  1 +
 drivers/usb/gadget/udc/renesas_usb3.c | 34 --
 2 files changed, 29 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/gadget/udc/Kconfig b/drivers/usb/gadget/udc/Kconfig
index 0875d38..7e4a5dd 100644
--- a/drivers/usb/gadget/udc/Kconfig
+++ b/drivers/usb/gadget/udc/Kconfig
@@ -193,6 +193,7 @@ config USB_RENESAS_USB3
tristate 'Renesas USB3.0 Peripheral controller'
depends on ARCH_RENESAS || COMPILE_TEST
depends on EXTCON && HAS_DMA
+   select USB_ROLE_SWITCH
help
   Renesas USB3.0 Peripheral controller is a USB peripheral controller
   that supports super, high, and full speed USB 3.0 data transfers.
diff --git a/drivers/usb/gadget/udc/renesas_usb3.c 
b/drivers/usb/gadget/udc/renesas_usb3.c
index 409cde4..5b7b1ce 100644
--- a/drivers/usb/gadget/udc/renesas_usb3.c
+++ b/drivers/usb/gadget/udc/renesas_usb3.c
@@ -23,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /* register definitions */
 #define USB3_AXI_INT_STA   0x008
@@ -330,6 +331,7 @@ struct renesas_usb3 {
 
struct usb_gadget gadget;
struct usb_gadget_driver *driver;
+   struct usb_role_switch *role_sw;/* Optional */
struct extcon_dev *extcon;
struct work_struct extcon_work;
struct phy *phy;
@@ -454,7 +456,11 @@ static void usb3_disable_pipe_irq(struct renesas_usb3 
*usb3, int num)
 
 static bool usb3_is_host(struct renesas_usb3 *usb3)
 {
-   return !(usb3_read(usb3, USB3_DRD_CON) & DRD_CON_PERI_CON);
+   if (usb3->role_sw)
+   return usb_role_switch_get_role(usb3->role_sw) ==
+   USB_ROLE_HOST ? true : false;
+   else
+   return !(usb3_read(usb3, USB3_DRD_CON) & DRD_CON_PERI_CON);
 }
 
 static void usb3_init_axi_bridge(struct renesas_usb3 *usb3)
@@ -645,10 +651,16 @@ static void usb3_check_vbus(struct renesas_usb3 *usb3)
 
 static void usb3_set_mode(struct renesas_usb3 *usb3, bool host)
 {
-   if (host)
-   usb3_clear_bit(usb3, DRD_CON_PERI_CON, USB3_DRD_CON);
-   else
-   usb3_set_bit(usb3, DRD_CON_PERI_CON, USB3_DRD_CON);
+   if (usb3->role_sw) {
+   enum usb_role role = host ? USB_ROLE_HOST : USB_ROLE_DEVICE;
+
+   usb_role_switch_set_role(usb3->role_sw, role);
+   } else {
+   if (host)
+   usb3_clear_bit(usb3, DRD_CON_PERI_CON, USB3_DRD_CON);
+   else
+   usb3_set_bit(usb3, DRD_CON_PERI_CON, USB3_DRD_CON);
+   }
 }
 
 static void usb3_vbus_out(struct renesas_usb3 *usb3, bool enable)
@@ -663,8 +675,8 @@ static void usb3_mode_config(struct renesas_usb3 *usb3, 
bool host, bool a_dev)
 {
unsigned long flags;
 
-   spin_lock_irqsave(>lock, flags);
usb3_set_mode(usb3, host);
+   spin_lock_irqsave(>lock, flags);
usb3_vbus_out(usb3, a_dev);
/* for A-Peripheral or forced B-device mode */
if ((!host && a_dev) ||
@@ -2238,6 +2250,10 @@ static int renesas_usb3_start(struct usb_gadget *gadget,
/* hook up the driver */
usb3->driver = driver;
 
+   usb3->role_sw = usb_role_switch_get_by_graph(usb3_to_dev(usb3), 0, 0);
+   if (IS_ERR_OR_NULL(usb3->role_sw))
+   usb3->role_sw = NULL;
+
if (usb3->phy)
phy_init(usb3->phy);
 
@@ -2260,6 +2276,8 @@ static int renesas_usb3_stop(struct usb_gadget *gadget)
if (usb3->phy)
phy_exit(usb3->phy);
 
+   usb_role_switch_put(usb3->role_sw);
+
pm_runtime_put(usb3_to_dev(usb3));
 
return 0;
@@ -2632,6 +2650,10 @@ static int renesas_usb3_probe(struct platform_device 
*pdev)
if (ret < 0)
goto err_add_udc;
 
+   ret = devm_of_platform_populate(>dev);
+   if (ret < 0)
+   goto err_dev_create;
+
ret = device_create_file(>dev, _attr_role);
if (ret < 0)
goto err_dev_create;
-- 
1.9.1

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

[PATCH/RFC v2 4/6] usb: role: rcar-usb3-role-switch: add support for R-Car SoCs

[Yoshihiro Shimoda]

This patch adds role switch support for R-Car SoCs. Some R-Car SoCs
(e.g. R-Car H3) have USB 3.0 dual-role device controller which has
the USB 3.0 xHCI host and Renesas USB 3.0 peripheral.

Unfortunately, the mode change register contains the USB 3.0 peripheral
controller side only. So, the USB 3.0 peripheral driver (renesas_usb3)
manages this register. However, in peripheral mode, the host should
stop. Also the host hardware needs to reinitialize its own registers
when the mode changes from peripheral to host mode. Otherwise,
the host cannot work correctly (e.g. detect a device as high-speed).

To achieve this by a driver, this role switch driver manages
the mode change register and attach/release the xhci-plat driver.
The renesas_usb3 udc driver should call devm_of_platform_populate()
to probe this driver.

Signed-off-by: Yoshihiro Shimoda 
---
 drivers/usb/roles/Kconfig |  13 ++
 drivers/usb/roles/Makefile|   1 +
 drivers/usb/roles/rcar-usb3-role-switch.c | 190 ++
 3 files changed, 204 insertions(+)
 create mode 100644 drivers/usb/roles/rcar-usb3-role-switch.c

diff --git a/drivers/usb/roles/Kconfig b/drivers/usb/roles/Kconfig
index f5a5e6f..a44cbc7 100644
--- a/drivers/usb/roles/Kconfig
+++ b/drivers/usb/roles/Kconfig
@@ -11,4 +11,17 @@ config USB_ROLES_INTEL_XHCI
  To compile the driver as a module, choose M here: the module will
  be called intel-xhci-usb-role-switch.
 
+config USB_ROLES_RCAR_USB3
+   tristate "Renesas R-Car USB3.0 Role Switch"
+   depends on OF
+   depends on ARCH_RENESAS || COMPILE_TEST
+   help
+ Driver for the internal USB role switch for switching the USB data
+ lines between the xHCI host controller and the Renesas gadget
+ controller (by using renesas_usb3 driver) found on various Renesas
+ R-Car SoCs.
+
+ To compile the driver as a module, choose M here: the module will
+ be called rcar-usb3-role-switch.
+
 endif # USB_ROLE_SWITCH
diff --git a/drivers/usb/roles/Makefile b/drivers/usb/roles/Makefile
index e44b179..7ce3be3 100644
--- a/drivers/usb/roles/Makefile
+++ b/drivers/usb/roles/Makefile
@@ -1 +1,2 @@
 obj-$(CONFIG_USB_ROLES_INTEL_XHCI) += intel-xhci-usb-role-switch.o
+obj-$(CONFIG_USB_ROLES_RCAR_USB3) += rcar-usb3-role-switch.o
diff --git a/drivers/usb/roles/rcar-usb3-role-switch.c 
b/drivers/usb/roles/rcar-usb3-role-switch.c
new file mode 100644
index 000..2bcab60
--- /dev/null
+++ b/drivers/usb/roles/rcar-usb3-role-switch.c
@@ -0,0 +1,190 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Renesas R-Car USB 3.0 role switch driver
+ *
+ * Copyright (C) 2018  Renesas Electronics Corporation
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define USB3_DRD_CON   0x218
+#define DRD_CON_PERI_CON   BIT(24)
+
+struct rcar_usb3_role_switch {
+   struct usb_role_switch *role_sw;
+   void __iomem *reg;
+   struct device *host_dev;
+   enum usb_role save_role;/* for suspend/resume */
+};
+
+static enum usb_role
+rcar_usb3_role_switch_get_mode(struct rcar_usb3_role_switch *rcar_sw)
+{
+   u32 val = readl(rcar_sw->reg + USB3_DRD_CON);
+
+   if (val & DRD_CON_PERI_CON)
+   return USB_ROLE_DEVICE;
+
+   return USB_ROLE_HOST;
+}
+
+static void
+rcar_usb3_role_switch_set_mode(struct rcar_usb3_role_switch *rcar_sw,
+  bool host)
+{
+   void __iomem *drd_con = rcar_sw->reg + USB3_DRD_CON;
+
+   if (host)
+   writel(readl(drd_con) & ~DRD_CON_PERI_CON, drd_con);
+   else
+   writel(readl(drd_con) | DRD_CON_PERI_CON, drd_con);
+}
+
+static int rcar_usb3_role_switch_set_role(struct device *dev,
+ enum usb_role role)
+{
+   struct rcar_usb3_role_switch *rcar_sw = dev_get_drvdata(dev);
+   struct device *host = rcar_sw->host_dev;
+   enum usb_role cur_role;
+
+   pm_runtime_get_sync(dev->parent);
+
+   cur_role = rcar_usb3_role_switch_get_mode(rcar_sw);
+   if (cur_role == USB_ROLE_HOST && role == USB_ROLE_DEVICE) {
+   device_release_driver(host);
+   rcar_usb3_role_switch_set_mode(rcar_sw, false);
+   } else if (cur_role == USB_ROLE_DEVICE && role == USB_ROLE_HOST) {
+   /* Must set the mode before device_attach of the host */
+   rcar_usb3_role_switch_set_mode(rcar_sw, true);
+   if (device_attach(host) < 0)
+   dev_err(dev, "device_attach(usb3_port) failed\n");
+   }
+
+   pm_runtime_put(dev->parent);
+
+   return 0;
+}
+
+static enum usb_role rcar_usb3_role_switch_get_role(struct device *dev)
+{
+   struct rcar_usb3_role_switch *rcar_sw = dev_get_drvdata(dev);
+   enum usb_role cur_role;
+
+   pm_runtime_get(dev->parent);
+   cur_role = rcar_usb3_role_switch_get_mode(rcar_sw);
+   

[PATCH/RFC v2 2/6] base: devcon: add a new API to find the graph

[Yoshihiro Shimoda]

This patch adds a new API "device_connection_find_by_graph()" to
find device connection by using graph.

Signed-off-by: Yoshihiro Shimoda 
---
 Documentation/driver-api/device_connection.rst |  4 +--
 drivers/base/devcon.c  | 43 ++
 include/linux/device.h |  2 ++
 3 files changed, 47 insertions(+), 2 deletions(-)

diff --git a/Documentation/driver-api/device_connection.rst 
b/Documentation/driver-api/device_connection.rst
index affbc556..2e2d26f 100644
--- a/Documentation/driver-api/device_connection.rst
+++ b/Documentation/driver-api/device_connection.rst
@@ -19,7 +19,7 @@ Device connections alone do not create a dependency between 
the two devices.
 They are only descriptions which are not tied to either of the devices 
directly.
 A dependency between the two devices exists only if one of the two endpoint
 devices requests a reference to the other. The descriptions themselves can be
-defined in firmware (not yet supported) or they can be built-in.
+defined in firmware or they can be built-in.
 
 Usage
 -
@@ -40,4 +40,4 @@ API
 ---
 
 .. kernel-doc:: drivers/base/devcon.c
-   : functions: device_connection_find_match device_connection_find 
device_connection_add device_connection_remove
+   : functions: device_connection_find_match device_connection_find 
device_connection_add device_connection_remove device_connection_find_by_graph
diff --git a/drivers/base/devcon.c b/drivers/base/devcon.c
index d427e80..5a0da33 100644
--- a/drivers/base/devcon.c
+++ b/drivers/base/devcon.c
@@ -7,6 +7,7 @@
  */
 
 #include 
+#include 
 
 static DEFINE_MUTEX(devcon_lock);
 static LIST_HEAD(devcon_list);
@@ -134,3 +135,45 @@ void device_connection_remove(struct device_connection 
*con)
mutex_unlock(_lock);
 }
 EXPORT_SYMBOL_GPL(device_connection_remove);
+
+static int generic_graph_match(struct device *dev, void *fwnode)
+{
+   return dev->fwnode == fwnode;
+}
+
+/**
+ * device_connection_find_by_graph - Find two devices connected together
+ * @dev: Device to find connected device
+ * @port: identifier of the @dev port node
+ * @endpoint: identifier of the @dev endpoint node
+ *
+ * Find a connection with @port and @endpoint by using graph between @dev and
+ * another device. On success returns handle to the device that is connected
+ * to @dev, with the reference count for the found device incremented. Returns
+ * NULL if no matching connection was found, or ERR_PTR(-EPROBE_DEFER) when
+ * a connection was found but the other device has not been enumerated yet.
+ */
+struct device *device_connection_find_by_graph(struct device *dev, u32 port,
+  u32 endpoint)
+{
+   struct bus_type *bus;
+   struct fwnode_handle *remote;
+   struct device *conn;
+
+   remote = fwnode_graph_get_remote_node(dev_fwnode(dev), port, endpoint);
+   if (!remote)
+   return NULL;
+
+   for (bus = generic_match_buses[0]; bus; bus++) {
+   conn = bus_find_device(bus, NULL, remote, generic_graph_match);
+   if (conn)
+   return conn;
+   }
+
+   /*
+* We only get called if a connection was found, tell the caller to
+* wait for the other device to show up.
+*/
+   return ERR_PTR(-EPROBE_DEFER);
+}
+EXPORT_SYMBOL_GPL(device_connection_find_by_graph);
diff --git a/include/linux/device.h b/include/linux/device.h
index 0059b99..58f8544 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -751,6 +751,8 @@ void *device_connection_find_match(struct device *dev, 
const char *con_id,
 
 void device_connection_add(struct device_connection *con);
 void device_connection_remove(struct device_connection *con);
+struct device *device_connection_find_by_graph(struct device *dev, u32 port,
+  u32 endpoint);
 
 /**
  * enum device_link_state - Device link states.
-- 
1.9.1

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

[PATCH/RFC v2 3/6] usb: common: roles: add a new API to find the graph

[Yoshihiro Shimoda]

This patch adds a new API "usb_role_switch_get_by_graph()" to find
device connection by using graph.

Signed-off-by: Yoshihiro Shimoda 
---
 drivers/usb/common/roles.c | 30 ++
 include/linux/usb/role.h   |  2 ++
 2 files changed, 32 insertions(+)

diff --git a/drivers/usb/common/roles.c b/drivers/usb/common/roles.c
index 15cc76e..9fa26c1 100644
--- a/drivers/usb/common/roles.c
+++ b/drivers/usb/common/roles.c
@@ -114,6 +114,36 @@ struct usb_role_switch *usb_role_switch_get(struct device 
*dev)
 }
 EXPORT_SYMBOL_GPL(usb_role_switch_get);
 
+static int by_graph_match(struct device *dev, void *parent)
+{
+   return dev->parent == parent;
+}
+
+/**
+ * usb_role_switch_get_by_graph - Find USB role switch linked with the caller
+ * @dev: The caller device
+ * @port: identifier of the @dev port node
+ * @endpoint: identifier of the @dev endpoint node
+ *
+ * Finds and returns role switch linked with @dev, port and endpoint.
+ * The reference count for the found switch is incremented.
+ */
+struct usb_role_switch *usb_role_switch_get_by_graph(struct device *dev,
+u32 port, u32 endpoint)
+{
+   struct device *conn;
+   struct device *sw;
+
+   conn = device_connection_find_by_graph(dev, port, endpoint);
+   if (IS_ERR_OR_NULL(conn))
+   return ERR_PTR(-EPROBE_DEFER);
+
+   sw = device_find_child(conn, conn, by_graph_match);
+
+   return !IS_ERR(sw) ? to_role_switch(sw) : ERR_PTR(-EPROBE_DEFER);
+}
+EXPORT_SYMBOL_GPL(usb_role_switch_get_by_graph);
+
 /**
  * usb_role_switch_put - Release handle to a switch
  * @sw: USB Role Switch
diff --git a/include/linux/usb/role.h b/include/linux/usb/role.h
index edc51be..6573fdd 100644
--- a/include/linux/usb/role.h
+++ b/include/linux/usb/role.h
@@ -43,6 +43,8 @@ struct usb_role_switch_desc {
 int usb_role_switch_set_role(struct usb_role_switch *sw, enum usb_role role);
 enum usb_role usb_role_switch_get_role(struct usb_role_switch *sw);
 struct usb_role_switch *usb_role_switch_get(struct device *dev);
+struct usb_role_switch *usb_role_switch_get_by_graph(struct device *dev,
+u32 port, u32 endpoint);
 void usb_role_switch_put(struct usb_role_switch *sw);
 
 struct usb_role_switch *
-- 
1.9.1

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

[PATCH/RFC v2 6/6] arm64: dts: renesas: r8a7795: add OF graph for usb role switch

[Yoshihiro Shimoda]

This patch adds OF graph properties for usb role switch in r8a7795.

TODO:
 - separate a few patches to add new properties into each node.

Signed-off-by: Yoshihiro Shimoda 
---
 arch/arm64/boot/dts/renesas/r8a7795.dtsi | 38 
 1 file changed, 38 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi 
b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index 5ae85d8..2e52835 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -2206,6 +2206,12 @@
power-domains = < R8A7795_PD_ALWAYS_ON>;
resets = < 328>;
status = "disabled";
+
+   port {
+   usb3_host_ep: endpoint {
+   remote-endpoint = <_host_ep>;
+   };
+   };
};
 
usb3_peri0: usb@ee02 {
@@ -2217,6 +2223,38 @@
power-domains = < R8A7795_PD_ALWAYS_ON>;
resets = < 328>;
status = "disabled";
+
+   port {
+   usb3_peri_ep: endpoint {
+   remote-endpoint = <_peri_sw>;
+   };
+   };
+
+   usb3_role_sw0: usb3-role-sw {
+   compatible = "renesas,rcar-usb3-role-switch";
+   renesas,host = <>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+
+   usb3_host_sw: endpoint {
+   remote-endpoint = 
<_host_ep>;
+   };
+   };
+
+   port@1 {
+   reg = <1>;
+
+   usb3_peri_sw: endpoint {
+   remote-endpoint = 
<_peri_ep>;
+   };
+   };
+   };
+   };
};
 
ohci0: usb@ee08 {
-- 
1.9.1

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

[PATCH/RFC v2 1/6] dt-bindings: usb: add Renesas R-Car USB 3.0 role switch

[Yoshihiro Shimoda]

This patch adds a new documentation for Renesas R-Car USB 3.0 role
switch that can change the USB 3.0 role to either host or peripheral
by a hardware register that is included in USB3.0 peripheral module.

Signed-off-by: Yoshihiro Shimoda 
---
 .../bindings/usb/renesas,rcar-usb3-role-sw.txt | 47 ++
 1 file changed, 47 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/usb/renesas,rcar-usb3-role-sw.txt

diff --git 
a/Documentation/devicetree/bindings/usb/renesas,rcar-usb3-role-sw.txt 
b/Documentation/devicetree/bindings/usb/renesas,rcar-usb3-role-sw.txt
new file mode 100644
index 000..e074c03
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/renesas,rcar-usb3-role-sw.txt
@@ -0,0 +1,47 @@
+Renesas Electronics R-Car USB 3.0 role switch
+
+A renesas_usb3's node can contain this node.
+
+Required properties:
+ - compatible: Must contain "renesas,rcar-usb3-role-switch".
+
+Required nodes:
+ - The connection to a usb3.0 host node needs by using OF graph bindings.
+  - port@0 = USB 3.0 host port
+  - port@1 = USB 3.0 peripheral port
+
+Example of R-Car H3 ES2.0:
+   usb3_peri0: usb@ee02 {
+   compatible = "renesas,r8a7795-usb3-peri",
+"renesas,rcar-gen3-usb3-peri";
+   reg = <0 0xee02 0 0x400>;
+   interrupts = ;
+   clocks = < CPG_MOD 328>;
+   power-domains = < R8A7795_PD_ALWAYS_ON>;
+   resets = < 328>;
+
+   usb3-role-sw {
+   compatible = "renesas,rcar-usb3-role-switch";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+
+   usb3_host_sw: endpoint {
+   remote-endpoint = 
<_host_ep>;
+   };
+   };
+
+   port@1 {
+   reg = <1>;
+
+   usb3_peri_sw: endpoint {
+   remote-endpoint = 
<_peri_ep>;
+   };
+   };
+   };
+   };
+   };
-- 
1.9.1

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

[PATCH/RFC v2 0/6] usb: role: rcar-usb3-role-switch: add support for R-Car SoCs

[Yoshihiro Shimoda]

This patch set is based on renesas-drivers-2018-04-17-v4.17-rc1 tag
of renesas-drivers.git

In last week, I submitted a patch as RFC [1]. But, I completely
misunderstood the discussion of previous' one [2].

I marked this patch set as "RFC" because dtsi patch and udc patch
are not good for upstreaming (should separate a few patches).
I would like to know whether this way is good or not.

[1] https://patchwork.kernel.org/patch/10347511/
[2] https://patchwork.kernel.org/patch/10332865/

Changes from RFC:
 - Remove "device-connection-id" and "usb role switch driver" dt-bingings.
 - Remove drivers/of code.
 - Add a new API for find the connection by using graph on devcon.c and roles.c.
 - Use each new API on the rcar usb role switch and renesas_usb3 drivers.
 - Update the dtsi file for r8a7795.

Yoshihiro Shimoda (6):
  dt-bindings: usb: add Renesas R-Car USB 3.0 role switch
  base: devcon: add a new API to find the graph
  usb: common: roles: add a new API to find the graph
  usb: role: rcar-usb3-role-switch: add support for R-Car SoCs
  usb: gadget: udc: renesas_usb3: add support for a usb role switch
  arm64: dts: renesas: r8a7795: add OF graph for usb role switch

 .../bindings/usb/renesas,rcar-usb3-role-sw.txt |  47 +
 Documentation/driver-api/device_connection.rst |   4 +-
 arch/arm64/boot/dts/renesas/r8a7795.dtsi   |  38 +
 drivers/base/devcon.c  |  43 +
 drivers/usb/common/roles.c |  30 
 drivers/usb/gadget/udc/Kconfig |   1 +
 drivers/usb/gadget/udc/renesas_usb3.c  |  34 +++-
 drivers/usb/roles/Kconfig  |  13 ++
 drivers/usb/roles/Makefile |   1 +
 drivers/usb/roles/rcar-usb3-role-switch.c  | 190 +
 include/linux/device.h |   2 +
 include/linux/usb/role.h   |   2 +
 12 files changed, 397 insertions(+), 8 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/usb/renesas,rcar-usb3-role-sw.txt
 create mode 100644 drivers/usb/roles/rcar-usb3-role-switch.c

-- 
1.9.1

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

[PATCH] thermal: samsung: Remove support for Exynos5440

[Bartlomiej Zolnierkiewicz]

From: Krzysztof Kozlowski 
Subject: [PATCH] thermal: samsung: Remove support for Exynos5440

The Exynos5440 is not actively developed, there are no development
boards available and probably there are no real products with it.
Remove wide-tree support for Exynos5440.

Signed-off-by: Krzysztof Kozlowski 
[b.zolnierkie: ported over driver changes]
Signed-off-by: Bartlomiej Zolnierkiewicz 
---
Eduardo, here is a version which applies on top of pending Exynos
thermal changes (https://lkml.org/lkml/2018/4/16/256).

 Documentation/devicetree/bindings/thermal/exynos-thermal.txt |   14 
 drivers/thermal/samsung/exynos_tmu.c |  161 ---
 2 files changed, 4 insertions(+), 171 deletions(-)

Index: b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
===
--- a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt  
2018-04-26 12:29:42.716294204 +0200
+++ b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt  
2018-04-26 12:29:42.716294204 +0200
@@ -12,7 +12,6 @@
   "samsung,exynos5420-tmu-ext-triminfo" for TMU channels 2, 3 and 4
Exynos5420 (Must pass triminfo base and triminfo clock)
"samsung,exynos5433-tmu"
-  "samsung,exynos5440-tmu"
   "samsung,exynos7-tmu"
 - interrupt-parent : The phandle for the interrupt controller
 - reg : Address range of the thermal registers. For soc's which has multiple
@@ -68,18 +67,7 @@ Example 1):
#thermal-sensor-cells = <0>;
};
 
-Example 2):
-
-   tmuctrl_0: tmuctrl@160118 {
-   compatible = "samsung,exynos5440-tmu";
-   reg = <0x160118 0x230>, <0x160368 0x10>;
-   interrupts = <0 58 0>;
-   clocks = < 21>;
-   clock-names = "tmu_apbif";
-   #thermal-sensor-cells = <0>;
-   };
-
-Example 3): (In case of Exynos5420 "with misplaced TRIMINFO register")
+Example 2): (In case of Exynos5420 "with misplaced TRIMINFO register")
tmu_cpu2: tmu@10068000 {
compatible = "samsung,exynos5420-tmu-ext-triminfo";
reg = <0x10068000 0x100>, <0x1006c000 0x4>;
Index: b/drivers/thermal/samsung/exynos_tmu.c
===
--- a/drivers/thermal/samsung/exynos_tmu.c  2018-04-26 12:29:42.716294204 
+0200
+++ b/drivers/thermal/samsung/exynos_tmu.c  2018-04-26 12:30:52.648295965 
+0200
@@ -126,28 +126,6 @@
 
 #define EXYNOS5433_G3D_BASE0x1007
 
-/*exynos5440 specific registers*/
-#define EXYNOS5440_TMU_S0_7_TRIM   0x000
-#define EXYNOS5440_TMU_S0_7_CTRL   0x020
-#define EXYNOS5440_TMU_S0_7_DEBUG  0x040
-#define EXYNOS5440_TMU_S0_7_TEMP   0x0f0
-#define EXYNOS5440_TMU_S0_7_TH00x110
-#define EXYNOS5440_TMU_S0_7_TH10x130
-#define EXYNOS5440_TMU_S0_7_TH20x150
-#define EXYNOS5440_TMU_S0_7_IRQEN  0x210
-#define EXYNOS5440_TMU_S0_7_IRQ0x230
-/* exynos5440 common registers */
-#define EXYNOS5440_TMU_IRQ_STATUS  0x000
-#define EXYNOS5440_TMU_PMIN0x004
-
-#define EXYNOS5440_TMU_INTEN_RISE0_SHIFT   0
-#define EXYNOS5440_TMU_INTEN_RISE1_SHIFT   1
-#define EXYNOS5440_TMU_INTEN_RISE2_SHIFT   2
-#define EXYNOS5440_TMU_INTEN_RISE3_SHIFT   3
-#define EXYNOS5440_TMU_INTEN_FALL0_SHIFT   4
-#define EXYNOS5440_TMU_TH_RISE4_SHIFT  24
-#define EXYNOS5440_EFUSE_SWAP_OFFSET   8
-
 /* Exynos7 specific registers */
 #define EXYNOS7_THD_TEMP_RISE7_6   0x50
 #define EXYNOS7_THD_TEMP_FALL7_6   0x60
@@ -184,7 +162,6 @@ enum soc_type {
SOC_ARCH_EXYNOS5420,
SOC_ARCH_EXYNOS5420_TRIMINFO,
SOC_ARCH_EXYNOS5433,
-   SOC_ARCH_EXYNOS5440,
SOC_ARCH_EXYNOS7,
 };
 
@@ -619,57 +596,6 @@ out:
return ret;
 }
 
-static int exynos5440_tmu_initialize(struct platform_device *pdev)
-{
-   struct exynos_tmu_data *data = platform_get_drvdata(pdev);
-   unsigned int trim_info = 0, con, rising_threshold;
-   int threshold_code;
-   int crit_temp = 0;
-
-   /*
-* For exynos5440 soc triminfo value is swapped between TMU0 and
-* TMU2, so the below logic is needed.
-*/
-   switch (data->id) {
-   case 0:
-   trim_info = readl(data->base + EXYNOS5440_EFUSE_SWAP_OFFSET +
-EXYNOS5440_TMU_S0_7_TRIM);
-   break;
-   case 1:
-   trim_info = readl(data->base + EXYNOS5440_TMU_S0_7_TRIM);
-   break;
-   case 2:
-   trim_info = readl(data->base - EXYNOS5440_EFUSE_SWAP_OFFSET +
- EXYNOS5440_TMU_S0_7_TRIM);
-   }
-   

Re: [PATCH] USB: serial: option: adding support for ublox R410M

[Bjørn Mork]

Johan Hovold  writes:
> On Thu, Apr 26, 2018 at 02:48:54PM +0700, Lars Melin wrote:
>> On 4/26/2018 14:09, Johan Hovold wrote:
>> > On Thu, Apr 26, 2018 at 02:28:31PM +0800, SZ Lin (林上智) wrote:
>> >> This patch adds support for ublox R410M PID 0x90b2 USB modem to option
>> >> driver, this module supports LTE Cat M1 / NB1.
>> >>
>> >> Interface layout:
>> >> 0: QCDM/DIAG
>> >> 1: ADB
>> >> 2: AT
>> >> 3: RMNET
>> >>
>> >> Signed-off-by: SZ Lin (林上智) 
>> >> Cc: stable 
>> > 
>> > Applied, thanks.
>> > 
>> > Johan
>> 
>> With a Qualcomm Device Management interface, shouldn't this modem be 
>> driven by qcserial?
>
> Hmm, we already have some QCDM interfaces handled by option and qcaux so
> it's not that clear-cut.
>
> Dan and Björn had a discussion about this a while back, so adding them
> on CC. It seems to me that this device does not fit the intended use (or
> Gobi 1000 layout) for qcserial, but I may be mistaken.

tl;dr; I don't think qcserial is relevant unless a device matches one of
the pre-defined layout schemes.

But I'm too new in this game to say anything about the initial
intentions... 

My view of the present situation is that qcserial handles interface
layouts shared among many devices, while option handles interface
layouts which are unique per device, and vendor+class based function
mappings.  But I could be wrong.

Anyway, Qualcomm based designs are definitely handled by both drivers.
Using qcserial only makes sense if the interface layout matches one of
the defined shared schemes, which currently are:

QCSERIAL_G2K = 0,   /* Gobi 2000 */
QCSERIAL_G1K = 1,   /* Gobi 1000 */
QCSERIAL_SWI = 2,   /* Sierra Wireless */
QCSERIAL_HWI = 3,   /* Huawei */

or if similar logic is added for a new vendor/shceme

And I see multi-vendor-id usage as the main reason for these
schemes. There isn't much reason if you can make it a single match
against a vendor-id.

The original Gobi devices are obviously multi-vendor, and Sierra
Wireless and Huwaei are OEMs making devices for a number of laptop
vendors. This causes traditional vendor-id matching to fail, as e.g. a
HP device can be made by either OEMs (or others). qcserial has become a
convenient way to map a long list of full device IDs to a specific OEM
layout.


Bjørn



--
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 v8 0/6] typec: tcpm: Add sink side support for PPS

[Sebastian Reichel]

Hi,

On Thu, Apr 26, 2018 at 09:33:26AM +0200, Greg Kroah-Hartman wrote:
> On Wed, Apr 25, 2018 at 02:30:45PM +0200, Greg Kroah-Hartman wrote:
> > On Wed, Apr 25, 2018 at 01:26:33AM +0200, Sebastian Reichel wrote:
> > > Hi Greg,
> > > 
> > > On Tue, Apr 24, 2018 at 03:57:49PM +0200, Greg Kroah-Hartman wrote:
> > > > On Mon, Apr 23, 2018 at 03:10:55PM +0100, Adam Thomson wrote:
> > > > > This patch set adds sink side support for the PPS feature introduced 
> > > > > in the
> > > > > USB PD 3.0 specification.
> > > > > 
> > > > > The source PPS supply is represented using the Power Supply framework 
> > > > > to provide
> > > > > access and control APIs for dealing with it's operating voltage and 
> > > > > current,
> > > > > and switching between a standard PDO and PPS APDO operation. During 
> > > > > standard PDO
> > > > > operation the voltage and current is read-only, but for APDO PPS 
> > > > > these are
> > > > > writable as well to allow for control.
> > > > > 
> > > > > It should be noted that the keepalive for PPS is not handled within 
> > > > > TCPM. The
> > > > > expectation is that the external user will be required to ensure 
> > > > > re-requests
> > > > > occur regularly to ensure PPS remains and the source does not hard 
> > > > > reset.
> > > > 
> > > > Sebastian, any objection from me taking this series through my USB tree?
> > > 
> > > I currently have the power-supply bits in a local branch for
> > > testing. I would like to have this in the power-supply
> > > tree, since there is at least one pending driver which could
> > > directly use the newly introduced usb_type.
> > > 
> > > I can either provide an immutable branch with a signed tag, or
> > > you can merged it and provide me an immutable branch.
> > > 
> > > If you merge it via the USB tree patch 2-4 are
> > > 
> > > Reviewed-by: Sebastian Reichel 
> > 
> > I've applied these to a testing branch in my usb tree, and if they
> > survive the 0-day bot, I'll move them to a branch that you can pull from
> > that will not change.
> > 
> > Oh, I had to add a follow-on patch to fix up a gcc warning that really
> > wasn't a warning, but it saves us problems of people complaining about
> > it.
> 
> All looks good now.
> 
> Here's the signed tag you can pull from, with the full information of
> all of the other USB patches that you are going to be getting here
> (sorry about that).

Thanks, merged.

-- Sebastian


signature.asc
Description: PGP signature

Re: [PATCH] NET: usb: qmi_wwan: add support for ublox R410M PID 0x90b2

[Bjørn Mork]

"SZ Lin (林上智)"  writes:

> This patch adds support for PID 0x90b2 of ublox R410M.

Acked-by: Bjørn Mork 
--
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

[PATCH v6 0/2] Fix host unable to negotiate framesizes other than first

[Joel Pepper]

This patch set is mostly concerned with fixing a bug with the driver
setting incorrect bFrameIndexes, for details refer to the second patch.
However part of the fix also depends on fixing an unrelated bug,
which involved the "linked" flag on formats not beig set.

v6: This is mostly a resubmit of v5 which got buried ahead of the last merge 
window and never got reviewed. The addition to the Documentation has been 
updated to reflect this. Also moved version comments out of the actual commit 
message (Thanks, Felipe.)


Joel Pepper (2):
  usb/gadget/uvc-configfs Fix linked flag in a format not being set when
format is linked into streaming header
  usb/gadget/uvc-configfs Fix host unable to negotiate framesizes other
than first

 Documentation/ABI/testing/configfs-usb-gadget-uvc | 18 ++
 drivers/usb/gadget/function/uvc_configfs.c| 67 +++
 2 files changed, 85 insertions(+)

-- 
2.1.4

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

[PATCH v6 1/2] usb/gadget/uvc-configfs Fix linked flag in a format not being set when format is linked into streaming header

[Joel Pepper]

While checks are in place to avoid attributes and children of a format
being manipulated after the format is linked into the streaming header,
the linked flag was never actually set, invalidating the protections.

Signed-off-by: Joel Pepper 
---
 drivers/usb/gadget/function/uvc_configfs.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/usb/gadget/function/uvc_configfs.c 
b/drivers/usb/gadget/function/uvc_configfs.c
index c9b8cc4a..7a98f9f 100644
--- a/drivers/usb/gadget/function/uvc_configfs.c
+++ b/drivers/usb/gadget/function/uvc_configfs.c
@@ -760,6 +760,7 @@ static int uvcg_streaming_header_allow_link(struct 
config_item *src,
format_ptr->fmt = target_fmt;
list_add_tail(_ptr->entry, _hdr->formats);
++src_hdr->num_fmt;
+   ++target_fmt->linked;
 
 out:
mutex_unlock(>lock);
@@ -797,6 +798,8 @@ static void uvcg_streaming_header_drop_link(struct 
config_item *src,
break;
}
 
+   --target_fmt->linked;
+
 out:
mutex_unlock(>lock);
mutex_unlock(su_mutex);
-- 
2.1.4

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

[PATCH v6 2/2] usb/gadget/uvc-configfs Fix host unable to negotiate framesizes other than first

[Joel Pepper]

- Add bFrameIndex as a UVCG_FRAME_ATTR_RO for each frame size.
- Automatically assign ascending bFrameIndex to each frame in a format.

Before all "bFrameindex" attributes were set to "1" with no way to
configure the gadget otherwise. This resulted in the host always
negotiating for bFrameIndex 1 (i.e. the first framesize of the gadget).
After the negotiation the host driver will set the user or application
selected framesize, while the gadget is actually set to the first
framesize.

Now, when the containing format is linked into the streaming header,
iterate over all child frame descriptors and assign ascending indices.
The automatically assigned indices can be read from the new read only
bFrameIndex configsfs attribute in each frame descriptor item.

Signed-off-by: Joel Pepper 
---

v2: Add the new attribute to both MJPEG and uncompressed frame descriptors
in Documentation/ABI, with note that it was added only in a later
kernel version

v3: Changed from simply allowing user to set the value for bFrameIndex to
automatically assigning correct distinct frame indexes. Changed
bFrameIndex from RW to RO

v4: Actually include updated patch

v5: bFrameIndex now returns -EBUSY if the parent fmt is not linked yet

v6: Resubmit for next merge window; Documentation change updated to reflect 
that; Move version comments below tearline

 Documentation/ABI/testing/configfs-usb-gadget-uvc | 18 +++
 drivers/usb/gadget/function/uvc_configfs.c| 64 +++
 2 files changed, 82 insertions(+)

diff --git a/Documentation/ABI/testing/configfs-usb-gadget-uvc 
b/Documentation/ABI/testing/configfs-usb-gadget-uvc
index 1ba0d0f..86c9b2e 100644
--- a/Documentation/ABI/testing/configfs-usb-gadget-uvc
+++ b/Documentation/ABI/testing/configfs-usb-gadget-uvc
@@ -194,6 +194,14 @@ Description:   Specific MJPEG frame descriptors
bmCapabilities  - still image support, fixed frame-rate
support
 
+Date:  May 2018
+KernelVersion: 4.18
+
+   bFrameIndex - unique id for this framedescriptor;
+   only defined after parent format is
+   linked into the streaming header;
+   read-only
+
 What:  
/config/usb-gadget/gadget/functions/uvc.name/streaming/uncompressed
 Date:  Dec 2014
 KernelVersion: 4.0
@@ -241,6 +249,16 @@ Description:   Specific uncompressed frame descriptors
bmCapabilities  - still image support, fixed frame-rate
support
 
+Date:   May 2018
+KernelVersion:  4.18
+
+bFrameIndex - unique id for this framedescriptor;
+only defined after parent format is
+linked into the streaming header;
+read-only
+
+
+
 What:  /config/usb-gadget/gadget/functions/uvc.name/streaming/header
 Date:  Dec 2014
 KernelVersion: 4.0
diff --git a/drivers/usb/gadget/function/uvc_configfs.c 
b/drivers/usb/gadget/function/uvc_configfs.c
index 7a98f9f..37b4a14 100644
--- a/drivers/usb/gadget/function/uvc_configfs.c
+++ b/drivers/usb/gadget/function/uvc_configfs.c
@@ -32,6 +32,7 @@ static struct configfs_attribute prefix##attr_##cname = { \
 }
 
 static inline struct f_uvc_opts *to_f_uvc_opts(struct config_item *item);
+static void __uvcg_fmt_set_indices(struct config_group *fmt);
 
 /* control/header/ */
 DECLARE_UVC_HEADER_DESCRIPTOR(1);
@@ -751,6 +752,8 @@ static int uvcg_streaming_header_allow_link(struct 
config_item *src,
if (!target_fmt)
goto out;
 
+   __uvcg_fmt_set_indices(to_config_group(target));
+
format_ptr = kzalloc(sizeof(*format_ptr), GFP_KERNEL);
if (!format_ptr) {
ret = -ENOMEM;
@@ -991,8 +994,46 @@ end:   
\
\
 UVC_ATTR(uvcg_frame_, cname, aname);
 
+
+static ssize_t uvcg_frame_b_frame_index_show(struct config_item *item,
+   char *page)
+{
+   struct uvcg_frame *f = to_uvcg_frame(item);
+   struct uvcg_format *fmt;
+   struct f_uvc_opts *opts;
+   struct config_item *opts_item;
+   struct config_item *fmt_item;
+   struct mutex *su_mutex = >item.ci_group->cg_subsys->su_mutex;
+   int result;
+
+   mutex_lock(su_mutex); /* for navigating configfs hierarchy */
+
+   fmt_item = f->item.ci_parent;
+   fmt = to_uvcg_format(fmt_item);
+
+   if (!fmt->linked) {
+   result = -EBUSY;
+   goto out;
+   }
+
+   opts_item = fmt_item->ci_parent->ci_parent->ci_parent;
+   opts = to_f_uvc_opts(opts_item);
+
+   mutex_lock(>lock);
+   result = sprintf(page, 

Re: USB mouse and PS2 Keyboard freeze all of a sudden in Ubuntu Mate 16.04.4

[Greg KH]

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

A: No.
Q: Should I include quotations after my reply?

http://daringfireball.net/2007/07/on_top

On Thu, Apr 26, 2018 at 11:31:23AM +0300, Kyprianos Papadimitriou wrote:
> Dear Greg,
> 
> With regard to buffer overflow, check the following thread, at the end
> 
> https://ubuntuforums.org/showthread.php?t=2342985

Ah, you were referring to a device bug, not a kernel issue, that makes
more sense.

Did you try the "always poll" quirk for this device to see if that
solved the issue for you?  That might be all that is needed.

thanks,

greg k-h
--
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] USB: serial: option: adding support for ublox R410M

[Johan Hovold]

On Thu, Apr 26, 2018 at 02:48:54PM +0700, Lars Melin wrote:
> On 4/26/2018 14:09, Johan Hovold wrote:
> > On Thu, Apr 26, 2018 at 02:28:31PM +0800, SZ Lin (林上智) wrote:
> >> This patch adds support for ublox R410M PID 0x90b2 USB modem to option
> >> driver, this module supports LTE Cat M1 / NB1.
> >>
> >> Interface layout:
> >> 0: QCDM/DIAG
> >> 1: ADB
> >> 2: AT
> >> 3: RMNET
> >>
> >> Signed-off-by: SZ Lin (林上智) 
> >> Cc: stable 
> > 
> > Applied, thanks.
> > 
> > Johan
> 
> With a Qualcomm Device Management interface, shouldn't this modem be 
> driven by qcserial?

Hmm, we already have some QCDM interfaces handled by option and qcaux so
it's not that clear-cut.

Dan and Björn had a discussion about this a while back, so adding them
on CC. It seems to me that this device does not fit the intended use (or
Gobi 1000 layout) for qcserial, but I may be mistaken.

Thanks,
Johan
--
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 06/10] thermal: samsung: Remove support for Exynos5440

[Krzysztof Kozlowski]

On Thu, Apr 26, 2018 at 3:41 AM, Chanwoo Choi  wrote:
> Hi Krzysztof,
>
> On 2018년 04월 25일 05:32, Krzysztof Kozlowski wrote:
>> The Exynos5440 is not actively developed, there are no development
>> boards available and probably there are no real products with it.
>> Remove wide-tree support for Exynos5440.
>>
>> Signed-off-by: Krzysztof Kozlowski 
>> ---
>>  .../devicetree/bindings/thermal/exynos-thermal.txt |  14 +-
>>  drivers/thermal/samsung/exynos_tmu.c   | 155 
>> +
>>  drivers/thermal/samsung/exynos_tmu.h   |   1 -
>>  3 files changed, 4 insertions(+), 166 deletions(-)
>
>
> After applied this patch, I tested the build and found out
> 'exynos5440' keyword. There is one comment including 'exynos5440' as 
> following:
>
> diff --git a/drivers/thermal/samsung/exynos_tmu.c 
> b/drivers/thermal/samsung/exynos_tmu.c
> index f92f470bce21..cb525228cfe1 100644
> --- a/drivers/thermal/samsung/exynos_tmu.c
> +++ b/drivers/thermal/samsung/exynos_tmu.c
> @@ -943,7 +943,7 @@ static void exynos4210_tmu_clear_irqs(struct 
> exynos_tmu_data *data)
>  * Exynos3250, Exynos4412, Exynos5250 and Exynos5260 incorrectly
>  * states that INTCLEAR register has a different placing of bits
>  * responsible for FALL IRQs than INTSTAT register.  Exynos5420
> -* and Exynos5440 documentation is correct (Exynos4210 doesn't
> +* documentation is correct (Exynos4210 doesn't
>  * support FALL IRQs at all).
>  */
> writel(val_irq, data->base + tmu_intclear);
>
> After removing it, looks good to me.
> Reviewed-by: Chanwoo Choi 

Thanks, I left this comment intentionally as it has some meaning even
when Exynos5440 is not supported.

Best regards,
Krzysztof
--
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 stable v4.4+] r8152: add Linksys USB3GIGV1 id

[Krzysztof Kozlowski]

On Thu, Apr 26, 2018 at 2:40 AM, Grant Grundler  wrote:
> On Wed, Apr 25, 2018 at 2:54 AM, Krzysztof Kozlowski 
> wrote:
>>
>> commit 90841047a01b452cc8c3f9b990698b264143334a upstream
>>
>> This linksys dongle by default comes up in cdc_ether mode.
>> This patch allows r8152 to claim the device:
>>Bus 002 Device 002: ID 13b1:0041 Linksys
>>
>> Signed-off-by: Grant Grundler 
>> Reviewed-by: Douglas Anderson 
>> Signed-off-by: David S. Miller 
>> [krzk: Rebase on v4.4]'
>
>
> thanks krzk!
>
> FTR, to support RTL8153B (HW ID 0x6010), the follow patch series to bring
> r8152 v1.09.9 driver from 4.14 kernel.org to 3 (of 5) older Chrome OS
> kernels:
>
> 3.14:
> https://chromium-review.googlesource.com/q/topic:%22update_r8152-3.14%22+(status:open%20OR%20status:merged)
> 3.18:
> https://chromium-review.googlesource.com/q/topic:%2522update-r8152-3.18%2522+(status:open+OR+status:merged)
> 4.4:
> https://chromium-review.googlesource.com/q/topic:%2522update_r8152-4.4%2522+(status:open+OR+status:merged)
>
> caveat: These series are not suitable directly for kernel.org submission
> (extraneous stuff in the commit messages, order is different). Using the
> original SHA1 (in each commit message), this can all be fixed up by
> hand/simple scripts.

Hi Grant,

These are regular feature/patch backports so they do not fit into
stable process. Only new quirks and IDs are accepted for stable.

Best regards,
Krzysztof
--
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] USB: serial: option: adding support for ublox R410M

[Lars Melin]

On 4/26/2018 14:09, Johan Hovold wrote:

On Thu, Apr 26, 2018 at 02:28:31PM +0800, SZ Lin (林上智) wrote:

This patch adds support for ublox R410M PID 0x90b2 USB modem to option
driver, this module supports LTE Cat M1 / NB1.

Interface layout:
0: QCDM/DIAG
1: ADB
2: AT
3: RMNET

Signed-off-by: SZ Lin (林上智) 
Cc: stable 


Applied, thanks.

Johan


With a Qualcomm Device Management interface, shouldn't this modem be 
driven by qcserial?


/Lars
--
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 mouse and PS2 Keyboard freeze all of a sudden in Ubuntu Mate 16.04.4

[Greg KH]

On Thu, Apr 26, 2018 at 10:27:17AM +0300, Kyprianos Papadimitriou wrote:
> 
> Thanks for the prompt response! see below
> 
> On 26/04/2018 09:58 πμ, Greg KH wrote:
> > On Wed, Apr 25, 2018 at 09:22:47PM +0300, Kyprianos Papadimitriou wrote:
> > > Dear sir/madam,
> > > 
> > > I am facing the following problem:
> > > 
> > > My computer randomly stops responding to the usb mouse and keyboard.
> > > Unplugging them and plugging them back into a different port does not fix
> > > the problem. Sometimes it is fixed after rebooting or after suspending, 
> > > then
> > > turning it on.
> > > 
> > > The problem is related to the Logitech trackman wheel & Mircosoft PS2
> > > Keyboard, both are old.
> > > 
> > > Command "lsusb" for the 2 devices gives:
> > > Bus 002 Device 009: ID 046d:c404 Logitech, Inc. TrackMan Wheel
> > > Bus 002 Device 010: ID 0a81:0205 Chesen Electronics Corp. PS/2
> > > Keyboard+Mouse Adapter
> > So this is a ps2 -> USB adapter for the keyboard, right?
> For the keyboard yes, it is ps2->USB. The TrackMan is USB.
> > 
> > > Command "tlp-stat -u" for the 2 devices gives:
> > > Bus 002 Device 009 ID 046d:c404 control = on, autosuspend_delay_ms = -1000
> > > -- Logitech, Inc. TrackMan Wheel (usbhid)
> > > Bus 002 Device 010 ID 0a81:0205 control = on, autosuspend_delay_ms = -1000
> > > -- Chesen Electronics Corp. PS/2 Keyboard+Mouse Adapter (usbhid)
> > > 
> > > "uname -ra" gives:
> > > Linux dell 4.13.0-39-generic #44~16.04.1-Ubuntu SMP Thu Apr 5 16:43:10 UTC
> > > 2018 x86_64 x86_64 x86_64 GNU/Linux
> > > 
> > > Can you please help me resolving this issue?
> > > 
> > > I think the problem is not related with autosuspend, but rather with 
> > > buffer
> > > overflow for the specific devices due to that they are not supported in 
> > > the
> > > kernel code.
> > Why would something be overflowing?  These devices should "just work" as
> > this is an old thing.
> > 
> > Have you tried turning autosuspend off for these devices?  Lots of old
> > USB devices do not like that at all.  I don't know what "tlp" does with
> > them, but I would suggest blacklisting them from it and see if that
> > resolves the issue.
> I think I have already done these.
> 
> "control = on" means that autosuspend is off. And when I run command "cat
> /sys/module/usbcore/parameters/autosuspend" , this gives -1.
> 
> Finally, in file /etc/default/tlp , I have added the line
> USB_BLACKLIST="046d:c404". I then executed "sudo tlp usb" (to apply the
> above), and rebooted.
> 
> What more should I do?

I really do not know what 'tlp' does, or how it does it at all, sorry.
If you disable tlp, does everything work properly?

Has this device _ever_ worked properly before on older versions of
Linux?

Are there any lines in the kernel log for when this happens?

If you do this:
sudo dmesg -c
before anything happens, it will clear out the kernel log.

Then, after the problem happens, you can look at the log by doing:
dmesg

It might be hard to do that if your keyboard is locked up, I know, any
way to use another keyboard when that happens?

thanks,

greg k-h
--
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 v8 0/6] typec: tcpm: Add sink side support for PPS

[Greg Kroah-Hartman]

On Wed, Apr 25, 2018 at 02:30:45PM +0200, Greg Kroah-Hartman wrote:
> On Wed, Apr 25, 2018 at 01:26:33AM +0200, Sebastian Reichel wrote:
> > Hi Greg,
> > 
> > On Tue, Apr 24, 2018 at 03:57:49PM +0200, Greg Kroah-Hartman wrote:
> > > On Mon, Apr 23, 2018 at 03:10:55PM +0100, Adam Thomson wrote:
> > > > This patch set adds sink side support for the PPS feature introduced in 
> > > > the
> > > > USB PD 3.0 specification.
> > > > 
> > > > The source PPS supply is represented using the Power Supply framework 
> > > > to provide
> > > > access and control APIs for dealing with it's operating voltage and 
> > > > current,
> > > > and switching between a standard PDO and PPS APDO operation. During 
> > > > standard PDO
> > > > operation the voltage and current is read-only, but for APDO PPS these 
> > > > are
> > > > writable as well to allow for control.
> > > > 
> > > > It should be noted that the keepalive for PPS is not handled within 
> > > > TCPM. The
> > > > expectation is that the external user will be required to ensure 
> > > > re-requests
> > > > occur regularly to ensure PPS remains and the source does not hard 
> > > > reset.
> > > 
> > > Sebastian, any objection from me taking this series through my USB tree?
> > 
> > I currently have the power-supply bits in a local branch for
> > testing. I would like to have this in the power-supply
> > tree, since there is at least one pending driver which could
> > directly use the newly introduced usb_type.
> > 
> > I can either provide an immutable branch with a signed tag, or
> > you can merged it and provide me an immutable branch.
> > 
> > If you merge it via the USB tree patch 2-4 are
> > 
> > Reviewed-by: Sebastian Reichel 
> 
> I've applied these to a testing branch in my usb tree, and if they
> survive the 0-day bot, I'll move them to a branch that you can pull from
> that will not change.
> 
> Oh, I had to add a follow-on patch to fix up a gcc warning that really
> wasn't a warning, but it saves us problems of people complaining about
> it.

All looks good now.

Here's the signed tag you can pull from, with the full information of
all of the other USB patches that you are going to be getting here
(sorry about that).

thanks,

greg k-h

-

The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:

  Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/ 
tags/tcpm-pps-4.18

for you to fetch changes up to 0c718676ab3f02e98e85e7049e03d2879c62cb10:

  typec: tcpm: fix compiler warning about stupid things (2018-04-25 14:24:34 
+0200)


Tag/Merge point for adding typeC power supply support

This is a signed tag/merge point to handle the cross-tree merge of the
USB and power supply subsystems for the patch series:
Subject: [PATCH v8 0/6] typec: tcpm: Add sink side support for PPS

It is based on the usb.git tree, in the usb-next branch, for merging in
4.18-rc1.

Signed-off-by: Greg Kroah-Hartman 


Adam Thomson (6):
  typec: tcpm: Add core support for sink side PPS
  Documentation: power: Initial effort to document power_supply ABI
  power: supply: Add error checking of psy desc during registration
  power: supply: Add 'usb_type' property and supporting code
  typec: tcpm: Represent source supply through power_supply
  typec: tcpm: Add support for sink PPS related messages

Dmitry Osipenko (3):
  usb: phy: tegra: Cleanup error messages
  usb: tegra: Move utmi-pads reset from ehci-tegra to tegra-phy
  usb: phy: Add Kconfig entry for Tegra PHY driver

Dominik Bozek (1):
  usb: hub: Don't wait for connect state at resume for powered-off ports

Geert Uytterhoeven (1):
  usb: Remove depends on HAS_DMA in case of platform dependency

Greg Kroah-Hartman (1):
  typec: tcpm: fix compiler warning about stupid things

Gregory CLEMENT (2):
  usb: host: xhci-plat: Remove useless test before clk_disable_unprepare
  usb: host: xhci-plat: Fix clock resource by adding a register clock

Gustavo A. R. Silva (1):
  usb: core: hcd: mark expected switch fall-through

Jia-Ju Bai (3):
  usb: storage: Replace mdelay with msleep in init_freecom
  usb: isp1760: Replace mdelay with msleep in isp1760_init_core
  usb: isp1760: Replace mdelay with msleep in isp1760_stop

Johan Hovold (6):
  USB: phy: drop unused legacy controller-phy bind helper
  USB: core: hcd: drop support for legacy phys
  USB: ehci-omap: drop unused legacy phy support
  USB: musb: omap2430: drop non-DT support
  USB: renesas_usbhs: drop unused legacy-phy support
  USB: phy: drop legacy board-file support

Li Jun (5):
  usb: typec: tcpm: pdo matching optimization
  usb: typec: fusb302: remove 

Re: [PATCH] USB: serial: option: adding support for ublox R410M

[Johan Hovold]

On Thu, Apr 26, 2018 at 02:28:31PM +0800, SZ Lin (林上智) wrote:
> This patch adds support for ublox R410M PID 0x90b2 USB modem to option
> driver, this module supports LTE Cat M1 / NB1.
> 
> Interface layout:
> 0: QCDM/DIAG
> 1: ADB
> 2: AT
> 3: RMNET
> 
> Signed-off-by: SZ Lin (林上智) 
> Cc: stable 

Applied, thanks.

Johan
--
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 mouse and PS2 Keyboard freeze all of a sudden in Ubuntu Mate 16.04.4

[Greg KH]

On Wed, Apr 25, 2018 at 09:22:47PM +0300, Kyprianos Papadimitriou wrote:
> 
> Dear sir/madam,
> 
> I am facing the following problem:
> 
> My computer randomly stops responding to the usb mouse and keyboard.
> Unplugging them and plugging them back into a different port does not fix
> the problem. Sometimes it is fixed after rebooting or after suspending, then
> turning it on.
> 
> The problem is related to the Logitech trackman wheel & Mircosoft PS2
> Keyboard, both are old.
> 
> Command "lsusb" for the 2 devices gives:
> Bus 002 Device 009: ID 046d:c404 Logitech, Inc. TrackMan Wheel
> Bus 002 Device 010: ID 0a81:0205 Chesen Electronics Corp. PS/2
> Keyboard+Mouse Adapter

So this is a ps2 -> USB adapter for the keyboard, right?

> Command "tlp-stat -u" for the 2 devices gives:
> Bus 002 Device 009 ID 046d:c404 control = on, autosuspend_delay_ms = -1000
> -- Logitech, Inc. TrackMan Wheel (usbhid)
> Bus 002 Device 010 ID 0a81:0205 control = on, autosuspend_delay_ms = -1000
> -- Chesen Electronics Corp. PS/2 Keyboard+Mouse Adapter (usbhid)
> 
> "uname -ra" gives:
> Linux dell 4.13.0-39-generic #44~16.04.1-Ubuntu SMP Thu Apr 5 16:43:10 UTC
> 2018 x86_64 x86_64 x86_64 GNU/Linux
> 
> Can you please help me resolving this issue?
> 
> I think the problem is not related with autosuspend, but rather with buffer
> overflow for the specific devices due to that they are not supported in the
> kernel code.

Why would something be overflowing?  These devices should "just work" as
this is an old thing.

Have you tried turning autosuspend off for these devices?  Lots of old
USB devices do not like that at all.  I don't know what "tlp" does with
them, but I would suggest blacklisting them from it and see if that
resolves the issue.

thanks,

greg k-h
--
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

[PATCH] NET: usb: qmi_wwan: add support for ublox R410M PID 0x90b2

[林上智]

This patch adds support for PID 0x90b2 of ublox R410M.

qmicli -d /dev/cdc-wdm0 --dms-get-manufacturer
[/dev/cdc-wdm0] Device manufacturer retrieved:
Manufacturer: 'u-blox'

qmicli -d /dev/cdc-wdm0 --dms-get-model
[/dev/cdc-wdm0] Device model retrieved:
Model: 'SARA-R410M-02B'

Signed-off-by: SZ Lin (林上智) 
Cc: stable 
---
 drivers/net/usb/qmi_wwan.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index c853e7410f5a..51c68fc416fa 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -1098,6 +1098,7 @@ static const struct usb_device_id products[] = {
{QMI_FIXED_INTF(0x05c6, 0x9080, 8)},
{QMI_FIXED_INTF(0x05c6, 0x9083, 3)},
{QMI_FIXED_INTF(0x05c6, 0x9084, 4)},
+   {QMI_FIXED_INTF(0x05c6, 0x90b2, 3)},/* ublox R410M */
{QMI_FIXED_INTF(0x05c6, 0x920d, 0)},
{QMI_FIXED_INTF(0x05c6, 0x920d, 5)},
{QMI_QUIRK_SET_DTR(0x05c6, 0x9625, 4)}, /* YUGA CLM920-NC5 */
-- 
2.17.0

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

[PATCH] USB: serial: option: adding support for ublox R410M

[林上智]

This patch adds support for ublox R410M PID 0x90b2 USB modem to option
driver, this module supports LTE Cat M1 / NB1.

Interface layout:
0: QCDM/DIAG
1: ADB
2: AT
3: RMNET

Signed-off-by: SZ Lin (林上智) 
Cc: stable 
---

Please refer to following lsusb output:

Bus 001 Device 003: ID 05c6:90b2 Qualcomm, Inc.
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   2.00
  bDeviceClass0 (Defined at Interface level)
  bDeviceSubClass 0
  bDeviceProtocol 0
  bMaxPacketSize064
  idVendor   0x05c6 Qualcomm, Inc.
  idProduct  0x90b2
  bcdDevice0.00
  iManufacturer   3 Qualcomm, Incorporated
  iProduct2 Qualcomm CDMA Technologies MSM
  iSerial 4 fb854106
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength  108
bNumInterfaces  4
bConfigurationValue 1
iConfiguration  1 Qualcomm Configuration
bmAttributes 0xe0
  Self Powered
  Remote Wakeup
MaxPower  500mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   2
  bInterfaceClass   255 Vendor Specific Class
  bInterfaceSubClass255 Vendor Specific Subclass
  bInterfaceProtocol255 Vendor Specific Protocol
  iInterface  0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81  EP 1 IN
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval   0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01  EP 1 OUT
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval   0
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber1
  bAlternateSetting   0
  bNumEndpoints   1
  bInterfaceClass   255 Vendor Specific Class
  bInterfaceSubClass255 Vendor Specific Subclass
  bInterfaceProtocol255 Vendor Specific Protocol
  iInterface  0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82  EP 2 IN
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval   0
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber2
  bAlternateSetting   0
  bNumEndpoints   3
  bInterfaceClass   255 Vendor Specific Class
  bInterfaceSubClass255 Vendor Specific Subclass
  bInterfaceProtocol255 Vendor Specific Protocol
  iInterface  0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83  EP 3 IN
bmAttributes3
  Transfer TypeInterrupt
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0040  1x 64 bytes
bInterval   5
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x84  EP 4 IN
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval   0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02  EP 2 OUT
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval   0
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber3
  bAlternateSetting   0
  bNumEndpoints   3
  bInterfaceClass   255 Vendor Specific Class
  bInterfaceSubClass255 Vendor Specific Subclass
  bInterfaceProtocol255 Vendor Specific Protocol
  iInterface  0