Re: [PATCH v2] dt-bindings: usb: renesas_gen3: Rename bindings documentation file to reflect IP block

2019-08-19 Thread Simon Horman
On Sat, Aug 10, 2019 at 01:14:55PM +0200, Greg Kroah-Hartman wrote:
> On Sat, Aug 10, 2019 at 08:40:15AM +0200, Geert Uytterhoeven wrote:
> > Hi Simon,
> > 
> > On Fri, Aug 9, 2019 at 11:37 PM Simon Horman  
> > wrote:
> > > For consistency with the naming of (most) other documentation files for DT
> > > bindings for Renesas IP blocks rename the Renesas USB3.0 peripheral
> > > documentation file from renesas,usb3.txt to renesas,usb3-peri.txt
> > >
> > > This refines a recent rename from renesas_usb3.txt to renesas-usb3.txt.
> > 
> > s/renesas-usb3.txt/renesas,usb3.txt/
> 
> I'll fix it up now, no need for a resend...

Thanks, much appreciated.


[PATCH v2] dt-bindings: usb: renesas_gen3: Rename bindings documentation file to reflect IP block

2019-08-09 Thread Simon Horman
For consistency with the naming of (most) other documentation files for DT
bindings for Renesas IP blocks rename the Renesas USB3.0 peripheral
documentation file from renesas,usb3.txt to renesas,usb3-peri.txt

This refines a recent rename from renesas_usb3.txt to renesas-usb3.txt.
The motivation is to more accurately reflect the IP block documented in
this file.

Signed-off-by: Simon Horman 
Reviewed-by: Geert Uytterhoeven 
---
* Based on v5.3-rc1

v2
* Add review tag
* Correct changelog
---
 .../devicetree/bindings/usb/{renesas,usb3.txt => renesas,usb3-peri.txt}   | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 rename Documentation/devicetree/bindings/usb/{renesas,usb3.txt => 
renesas,usb3-peri.txt} (100%)

diff --git a/Documentation/devicetree/bindings/usb/renesas,usb3.txt 
b/Documentation/devicetree/bindings/usb/renesas,usb3-peri.txt
similarity index 100%
rename from Documentation/devicetree/bindings/usb/renesas,usb3.txt
rename to Documentation/devicetree/bindings/usb/renesas,usb3-peri.txt
-- 
2.11.0



Re: [PATCH] usb: host: xhci-rcar: Fix timeout in xhci_suspend()

2019-08-09 Thread Simon Horman
On Fri, Aug 02, 2019 at 05:33:35PM +0900, Yoshihiro Shimoda wrote:
> When a USB device is connected to the host controller and
> the system enters suspend, the following error happens
> in xhci_suspend():
> 
>   xhci-hcd ee00.usb: WARN: xHC CMD_RUN timeout
> 
> Since the firmware/internal CPU control the USBSTS.STS_HALT
> and the process speed is down when the roothub port enters U3,
> long delay for the handshake of STS_HALT is neeed in xhci_suspend().
> So, this patch adds to set the XHCI_SLOW_SUSPEND.
> 
> Fixes: 435cc1138ec9 ("usb: host: xhci-plat: set resume_quirk() for R-Car 
> controllers")
> Cc:  # v4.12+
> Signed-off-by: Yoshihiro Shimoda 

Reviewed-by: Simon Horman 

> ---
>  drivers/usb/host/xhci-rcar.c | 9 +++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/usb/host/xhci-rcar.c b/drivers/usb/host/xhci-rcar.c
> index 671bce1..8616c52 100644
> --- a/drivers/usb/host/xhci-rcar.c
> +++ b/drivers/usb/host/xhci-rcar.c
> @@ -238,10 +238,15 @@ int xhci_rcar_init_quirk(struct usb_hcd *hcd)
>* pointers. So, this driver clears the AC64 bit of xhci->hcc_params
>* to call dma_set_coherent_mask(dev, DMA_BIT_MASK(32)) in
>* xhci_gen_setup().
> +  *
> +  * And, since the firmware/internal CPU control the USBSTS.STS_HALT
> +  * and the process speed is down when the roothub port enters U3,
> +  * long delay for the handshake of STS_HALT is neeed in xhci_suspend().
>*/
>   if (xhci_rcar_is_gen2(hcd->self.controller) ||
> - xhci_rcar_is_gen3(hcd->self.controller))
> - xhci->quirks |= XHCI_NO_64BIT_SUPPORT;
> + xhci_rcar_is_gen3(hcd->self.controller)) {
> + xhci->quirks |= XHCI_NO_64BIT_SUPPORT | XHCI_SLOW_SUSPEND;
> + }


nit: As there is still only one line guarded by the conditional I don't
think that { } need to be added.

>  
>   if (!xhci_rcar_wait_for_pll_active(hcd))
>   return -ETIMEDOUT;
> -- 
> 2.7.4
> 


PARTNERSHIP REQUEST,

2019-08-06 Thread Simon Beron
Dear Friend,

I need you to please let me know if there are fast growing investments
in your country in which i can invest money in. I have access to a
huge amount of money, which i want to invest in your country, i want
to know if you can be an agent/partner to me and i will give you a
commission of 30% only If you agree to assist me, i will like to know
if the commission is ok for you, also i would love to know more about
you too. Get Back to me without delay if you are interested


Yours Faithfully

Simon Beron.


Re: [PATCH] dt-bindings: usb: renesas_gen3: Rename bindings documentation file to reflect IP block

2019-08-01 Thread Simon Horman
On Thu, Aug 01, 2019 at 11:18:36AM +0200, Geert Uytterhoeven wrote:
> On Thu, Aug 1, 2019 at 11:13 AM Simon Horman  
> wrote:
> > For consistency with the naming of (most) other documentation files for DT
> > bindings for Renesas IP blocks rename the Renesas USB3.0 peripheral
> > documentation file from renesas,gen3.txt to renesas,usb3-peri.txt
> 
> from renesas,usb3.txt
> 
> > This refines a recent rename from renesas,gen3.txt to renesas-gen3.txt.
> 
> Actually it was renamed from renesas_usb3.txt to renesas,usb3.txt.
> 
> > The motivation is to to more accurately reflect the IP block documented in
> 
> double to
> 
> > this file.
> >
> > Signed-off-by: Simon Horman 
> 
> With the above fixed:
> Reviewed-by: Geert Uytterhoeven 

Thanks, I'll fix this up.


Re: [PATCH v2 2/2] dt-bindings: usb: renesas_gen3: Rename bindings documentation file

2019-08-01 Thread Simon Horman
On Mon, Jul 29, 2019 at 08:25:24AM +, Yoshihiro Shimoda wrote:
> Hi Simon-san,
> 
> > From: Simon Horman, Sent: Monday, July 29, 2019 5:15 PM
> 
> > > > > > Unfortunately the previous version has already made it into usb-next
> > > > > > 23c46801d14cb647 dt-bindings: usb: renesas_gen3: Rename bindings
> > > > > > documentation file
> > > > >
> > > > > Ok, I guess we should go with that version.
> > > >
> > > > So can you resend this series based on 5.3-rc1 so I know what to apply?
> > >
> > > Since your usb-testing branch already has it which is merged from 
> > > Felipe's usb-next branch,
> > > I don't think Simon has to resend this series.
> > >
> > > https://www.spinics.net/lists/linux-usb/msg182103.html
> > 
> > Thanks and sorry for the confusion.
> > 
> > In v5.2-rc1 we had:
> > 
> >   devicetree/bindings/usb/renesas_usb3.txt
> >   devicetree/bindings/usb/renesas_usbhs.txt
> > 
> > 
> > In v5.3-rc1 we have:
> > 
> >   devicetree/bindings/usb/renesas,usb3.txt
> >   devicetree/bindings/usb/renesas,usbhs.txt
> > 
> > Which reflects v1 of this patchset. And I think this is an improvement.
> > 
> > Shimoda-san, can you let me know if you would like me to rebase v2
> > on v5.3-rc1? That would would give us:
> > 
> >   devicetree/bindings/usb/renesas,usb3-peri.txt
> >   devicetree/bindings/usb/renesas,usbhs.txt [unchanged]
> 
> Thank you for the detail. I would like you to rebase v2 like that, if 
> possible.

Thanks, I have posted this as:

[PATCH] dt-bindings: usb: renesas_gen3: Rename bindings documentation file to 
reflect IP block


[PATCH] dt-bindings: usb: renesas_gen3: Rename bindings documentation file to reflect IP block

2019-08-01 Thread Simon Horman
For consistency with the naming of (most) other documentation files for DT
bindings for Renesas IP blocks rename the Renesas USB3.0 peripheral
documentation file from renesas,gen3.txt to renesas,usb3-peri.txt

This refines a recent rename from renesas,gen3.txt to renesas-gen3.txt.
The motivation is to to more accurately reflect the IP block documented in
this file.

Signed-off-by: Simon Horman 
---
* Based on v5.3-rc1
---
 .../devicetree/bindings/usb/{renesas,usb3.txt => renesas,usb3-peri.txt}   | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 rename Documentation/devicetree/bindings/usb/{renesas,usb3.txt => 
renesas,usb3-peri.txt} (100%)

diff --git a/Documentation/devicetree/bindings/usb/renesas,usb3.txt 
b/Documentation/devicetree/bindings/usb/renesas,usb3-peri.txt
similarity index 100%
rename from Documentation/devicetree/bindings/usb/renesas,usb3.txt
rename to Documentation/devicetree/bindings/usb/renesas,usb3-peri.txt
-- 
2.11.0



Re: [PATCH v2 2/2] dt-bindings: usb: renesas_gen3: Rename bindings documentation file

2019-07-29 Thread Simon Horman
On Fri, Jul 26, 2019 at 01:22:48AM +, Yoshihiro Shimoda wrote:
> Hi Greg,
> 
> > From: Greg Kroah-Hartman, Sent: Thursday, July 25, 2019 6:10 PM
> > 
> > On Thu, Jul 11, 2019 at 10:03:03AM +0200, Simon Horman wrote:
> > > On Wed, Jul 03, 2019 at 02:28:51PM +0200, Geert Uytterhoeven wrote:
> > > > Hi Simon,
> > > >
> > > > On Wed, Jul 3, 2019 at 10:35 AM Simon Horman 
> > > >  wrote:
> > > > > For consistency with the naming of (most) other documentation files 
> > > > > for DT
> > > > > bindings for Renesas IP blocks rename the Renesas USB3.0 peripheral
> > > > > documentation file from renesas-gen3.txt to renesas,usb3-peri.txt
> > > > >
> > > > > Signed-off-by: Simon Horman 
> > > > > Reviewed-by: Geert Uytterhoeven 
> > > > > Reviewed-by: Yoshihiro Shimoda 
> > > > > Reviewed-by: Niklas Söderlund 
> > > > >
> > > > > ---
> > > > > v2
> > > > > * Accumulate review tags
> > > > > * Use renesas,usb3-peri.txt as new filename as suggested by 
> > > > > Shimoda-san
> > > >
> > > > Unfortunately the previous version has already made it into usb-next
> > > > 23c46801d14cb647 dt-bindings: usb: renesas_gen3: Rename bindings
> > > > documentation file
> > >
> > > Ok, I guess we should go with that version.
> > 
> > So can you resend this series based on 5.3-rc1 so I know what to apply?
> 
> Since your usb-testing branch already has it which is merged from Felipe's 
> usb-next branch,
> I don't think Simon has to resend this series.
> 
> https://www.spinics.net/lists/linux-usb/msg182103.html

Thanks and sorry for the confusion.

In v5.2-rc1 we had:

  devicetree/bindings/usb/renesas_usb3.txt
  devicetree/bindings/usb/renesas_usbhs.txt


In v5.3-rc1 we have:

  devicetree/bindings/usb/renesas,usb3.txt
  devicetree/bindings/usb/renesas,usbhs.txt

Which reflects v1 of this patchset. And I think this is an improvement.

Shimoda-san, can you let me know if you would like me to rebase v2
on v5.3-rc1? That would would give us:

  devicetree/bindings/usb/renesas,usb3-peri.txt
  devicetree/bindings/usb/renesas,usbhs.txt [unchanged]



Re: [PATCH v2 2/2] dt-bindings: usb: renesas_gen3: Rename bindings documentation file

2019-07-11 Thread Simon Horman
On Wed, Jul 03, 2019 at 02:28:51PM +0200, Geert Uytterhoeven wrote:
> Hi Simon,
> 
> On Wed, Jul 3, 2019 at 10:35 AM Simon Horman  
> wrote:
> > For consistency with the naming of (most) other documentation files for DT
> > bindings for Renesas IP blocks rename the Renesas USB3.0 peripheral
> > documentation file from renesas-gen3.txt to renesas,usb3-peri.txt
> >
> > Signed-off-by: Simon Horman 
> > Reviewed-by: Geert Uytterhoeven 
> > Reviewed-by: Yoshihiro Shimoda 
> > Reviewed-by: Niklas Söderlund 
> >
> > ---
> > v2
> > * Accumulate review tags
> > * Use renesas,usb3-peri.txt as new filename as suggested by Shimoda-san
> 
> Unfortunately the previous version has already made it into usb-next
> 23c46801d14cb647 dt-bindings: usb: renesas_gen3: Rename bindings
> documentation file

Ok, I guess we should go with that version.


Re: [PATCH v2] usb: renesas_usbhs: Use specific struct instead of USBHS_TYPE_* enums

2019-05-15 Thread Simon Horman
On Wed, May 15, 2019 at 06:57:17AM +, Yoshihiro Shimoda wrote:
> Hi Simon-san,
> 
> > From: Simon Horman, Sent: Monday, May 13, 2019 9:01 PM
> > 
> > On Mon, May 13, 2019 at 11:40:29AM +0900, Yoshihiro Shimoda wrote:
> > > This patch adds a specific struct "usbhs_of_data" to add a new SoC
> > > data easily instead of code basis in the future.
> > >
> > > Signed-off-by: Yoshihiro Shimoda 
> > > Reviewed-by: Geert Uytterhoeven 
> > 
> > Hi Shimoda-san,
> > 
> > the minor suggestion below not withstanding this looks good to me.
> > 
> > Reviewed-by: Simon Horman 
> 
> Thank you for your review!
> 
> > > ---
> > >  Changes from v1 [1]:
> > >  - Use sizeof(variable) instead of sizeof(type).
> > >  - Add Geert-san's reviewed-by (thanks!).
> > >
> > > [1]
> > > https://patchwork.kernel.org/patch/10938575/
> > >
> > >  drivers/usb/renesas_usbhs/common.c | 112 
> > > +
> > >  drivers/usb/renesas_usbhs/common.h |   5 ++
> > >  2 files changed, 70 insertions(+), 47 deletions(-)
> > >
> > > diff --git a/drivers/usb/renesas_usbhs/common.c 
> > > b/drivers/usb/renesas_usbhs/common.c
> > > index 249fbee..0ca89de 100644
> > > --- a/drivers/usb/renesas_usbhs/common.c
> > > +++ b/drivers/usb/renesas_usbhs/common.c
> 
> > > @@ -598,8 +638,15 @@ static struct renesas_usbhs_platform_info 
> > > *usbhs_parse_dt(struct device *dev)
> > >   if (!info)
> > >   return NULL;
> > >
> > > + data = of_device_get_match_data(dev);
> > > + if (!data)
> > > + return NULL;
> > > +
> > >   dparam = &info->driver_param;
> > > - dparam->type = (uintptr_t)of_device_get_match_data(dev);
> > > + memcpy(dparam, &data->param, sizeof(data->param));
> > > + memcpy(&info->platform_callback, data->platform_callback,
> > > +sizeof(*data->platform_callback));
> > 
> > Can we avoid the error-proneness of calls to sizeof() as follows?
> > 
> > *dparam = data->param;
> > info->platform_callback = *data->platform_callback;
> 
> Since Chris-san has submitted a patch series [1] that is based on this patch 
> today,
> I'd like to submit an incremental patch to avoid the error-proneness in the 
> renesas_usbhs
> (common.c and mod_host.c) later, if possible.
> 
> Greg-san, is it acceptable?

FWIIW that sounds entirely reasonable to me as
my suggestion is a cleanup.

> [1]
> https://patchwork.kernel.org/project/linux-renesas-soc/list/?series=117459
> 
> Best regards,
> Yoshihiro Shimoda
> 
> > > +
> > >   if (!of_property_read_u32(dev->of_node, "renesas,buswait", &tmp))
> > >   dparam->buswait_bwait = tmp;
> > >   gpio = of_get_named_gpio_flags(dev->of_node, "renesas,enable-gpio", 0,
> > > @@ -607,19 +654,6 @@ static struct renesas_usbhs_platform_info 
> > > *usbhs_parse_dt(struct device *dev)
> > >   if (gpio > 0)
> > >   dparam->enable_gpio = gpio;
> > >
> > > - if (dparam->type == USBHS_TYPE_RCAR_GEN2 ||
> > > - dparam->type == USBHS_TYPE_RCAR_GEN3 ||
> > > - dparam->type == USBHS_TYPE_RCAR_GEN3_WITH_PLL) {
> > > - dparam->has_usb_dmac = 1;
> > > - dparam->pipe_configs = usbhsc_new_pipe;
> > > - dparam->pipe_size = ARRAY_SIZE(usbhsc_new_pipe);
> > > - }
> > > -
> > > - if (dparam->type == USBHS_TYPE_RZA1) {
> > > - dparam->pipe_configs = usbhsc_new_pipe;
> > > - dparam->pipe_size = ARRAY_SIZE(usbhsc_new_pipe);
> > > - }
> > > -
> > >   return info;
> > >  }
> > >
> > > @@ -676,29 +710,13 @@ static int usbhs_probe(struct platform_device *pdev)
> > >  &info->driver_param,
> > >  sizeof(struct renesas_usbhs_driver_param));
> > 
> > Likewise in the (otherwise unchanged) use of memcpy above.
> > 
> > >
> > > - switch (priv->dparam.type) {
> > > - case USBHS_TYPE_RCAR_GEN2:
> > > - priv->pfunc = usbhs_rcar2_ops;
> > > - break;
> > > - case USBHS_TYPE_RCAR_GEN3:
> > > - priv->pfunc = usbhs_rcar3_ops;
> > > - break;
> > > - case USBHS_TYPE_RCAR_GEN3_WITH_PLL:
> > > - priv->pfunc = usbhs_rcar3_with_pll_op

Re: [PATCH v3 12/15] dt-bindings: usb: renesas_usbhs: Add support for r7s9210

2019-05-15 Thread Simon Horman
On Tue, May 14, 2019 at 09:56:02AM -0500, Chris Brandt wrote:
> Add support for r7s9210 (RZ/A2M) SoC
> 
> Signed-off-by: Chris Brandt 

Reviewed-by: Simon Horman 



Re: [PATCH v3 11/15] usb: renesas_usbhs: Add support for RZ/A2

2019-05-15 Thread Simon Horman
On Tue, May 14, 2019 at 09:56:01AM -0500, Chris Brandt wrote:
> The RZ/A2 is similar to the R-Car Gen3 with some small differences.
> 
> Signed-off-by: Chris Brandt 

Reviewed-by: Simon Horman 



Re: [PATCH v3 10/15] usb: renesas_usbhs: support byte addressable CFIFO

2019-05-15 Thread Simon Horman
On Tue, May 14, 2019 at 09:56:00AM -0500, Chris Brandt wrote:
> Some SoC have a CFIFO register that is byte addressable. This means
> when the CFIFO access is set to 32-bit, you can write 8-bit values to
> addresses CFIFO+0, CFIFO+1, CFIFO+2, CFIFO+3.
> 
> Signed-off-by: Chris Brandt 

Reviewed-by: Simon Horman 


Re: [PATCH v3 03/15] phy: renesas: rcar-gen3-usb2: detect usb_x1 clock

2019-05-15 Thread Simon Horman
On Tue, May 14, 2019 at 09:55:53AM -0500, Chris Brandt wrote:
> The RZ/A2 has an optional dedicated 48MHz clock input for the PLL.
> If a clock node named 'usb_x1' exists and set to non-zero, then we can
> assume we want it use it.
> 
> Signed-off-by: Chris Brandt 

Reviewed-by: Simon Horman 



Re: [PATCH v3 05/15] phy: renesas: rcar-gen3-usb2: Check dr_mode when not using OTG

2019-05-15 Thread Simon Horman
On Tue, May 14, 2019 at 09:55:55AM -0500, Chris Brandt wrote:
> When not using OTG, the PHY will need to know if it should function as
> host or peripheral by checking dr_mode in the PHY node (not the parent
> controller node).
> 
> Signed-off-by: Chris Brandt 

Reviewed-by: Simon Horman 


Re: [PATCH v3 04/15] dt-bindings: rcar-gen3-phy-usb2: Document use of usb_x1

2019-05-15 Thread Simon Horman
On Tue, May 14, 2019 at 09:55:54AM -0500, Chris Brandt wrote:
> Document the USB_X1 input and add clock-names to identify
> functional and USB_X1 clocks.
> 
> Signed-off-by: Chris Brandt 

Reviewed-by: Simon Horman 



Re: [PATCH v3 06/15] dt-bindings: rcar-gen3-phy-usb2: Document dr_mode

2019-05-15 Thread Simon Horman
On Tue, May 14, 2019 at 09:55:56AM -0500, Chris Brandt wrote:
> Document the optional dr_mode property
> 
> Signed-off-by: Chris Brandt 

Reviewed-by: Simon Horman 



Re: [PATCH v3 07/15] dt-bindings: rcar-gen3-phy-usb2: Add r7s9210 support

2019-05-15 Thread Simon Horman
On Tue, May 14, 2019 at 09:55:57AM -0500, Chris Brandt wrote:
> Document RZ/A2 (R7S9210) SoC bindings.
> 
> Signed-off-by: Chris Brandt 

Reviewed-by: Simon Horman 



Re: [PATCH v3 09/15] usb: renesas_usbhs: add support for CNEN bit

2019-05-15 Thread Simon Horman
On Tue, May 14, 2019 at 09:55:59AM -0500, Chris Brandt wrote:
> For some SoC, CNEN must be set for USB Device mode operation.
> 
> Signed-off-by: Chris Brandt 

Reviewed-by: Simon Horman 



Re: [PATCH v3 08/15] usb: renesas_usbhs: move flags to param

2019-05-15 Thread Simon Horman
On Tue, May 14, 2019 at 09:55:58AM -0500, Chris Brandt wrote:
> Move options from 'flags' field in private structure to param structure
> where other options are already being kept.
> 
> Signed-off-by: Chris Brandt 

Reviewed-by: Simon Horman 



Re: [PATCH v3 02/15] ARM: dts: rza2mevb: Add 48MHz USB clock

2019-05-15 Thread Simon Horman
On Wed, May 15, 2019 at 09:43:02AM +0200, Geert Uytterhoeven wrote:
> Hi Chris,
> 
> On Tue, May 14, 2019 at 4:57 PM Chris Brandt  wrote:
> > The RZ/A2M EVB has a 48MHz clock attached to USB_X1.
> >
> > Signed-off-by: Chris Brandt 
> > Reviewed-by: Simon Horman 
> 
> Reviewed-by: Geert Uytterhoeven 

Thanks, applied for v5.3.

> > --- a/arch/arm/boot/dts/r7s9210-rza2mevb.dts
> > +++ b/arch/arm/boot/dts/r7s9210-rza2mevb.dts
> > @@ -58,6 +58,11 @@
> > clock-frequency = <32768>;
> >  };
> >
> > +/* USB_X1 */
> > +&usb_x1_clk {
> > +   clock-frequency = <4800>;
> > +};
> > +
> >  &pinctrl {
> > /* Serial Console */
> > scif4_pins: serial4 {
> 
> BTW, it looks like this file can use a sorting sweep.

Thanks, I'll look into it.


Re: [PATCH v3 01/15] ARM: dts: r7s9210: Add USB clock

2019-05-15 Thread Simon Horman
On Wed, May 15, 2019 at 09:38:32AM +0200, Geert Uytterhoeven wrote:
> On Tue, May 14, 2019 at 4:56 PM Chris Brandt  wrote:
> > Add USB clock node. If present, this clock input must be 48MHz.
> >
> > Signed-off-by: Chris Brandt 
> > Reviewed-by: Simon Horman 
> 
> Reviewed-by: Geert Uytterhoeven 

Thanks, applied for v5.3.


Re: [PATCH v2 01/15] ARM: dts: r7s9210: Add USB clock

2019-05-13 Thread Simon Horman
On Thu, May 09, 2019 at 03:11:28PM -0500, Chris Brandt wrote:
> Add USB clock node. If present, this clock input must be 48MHz.
> 
> Signed-off-by: Chris Brandt 

Thanks,

This looks fine to me but I will wait to see if there are other reviews
before applying.

Reviewed-by: Simon Horman 


Re: [PATCH v2 02/15] ARM: dts: rza2mevb: Add 48MHz USB clock

2019-05-13 Thread Simon Horman
On Thu, May 09, 2019 at 03:11:29PM -0500, Chris Brandt wrote:
> The RZ/A2M EVB has a 48MHz clock attached to USB_X1.
> 
> Signed-off-by: Chris Brandt 

Thanks,

This looks fine to me but I will wait to see if there are other reviews
before applying.

Reviewed-by: Simon Horman 


Re: [PATCH v2] usb: renesas_usbhs: Use specific struct instead of USBHS_TYPE_* enums

2019-05-13 Thread Simon Horman
On Mon, May 13, 2019 at 11:40:29AM +0900, Yoshihiro Shimoda wrote:
> This patch adds a specific struct "usbhs_of_data" to add a new SoC
> data easily instead of code basis in the future.
> 
> Signed-off-by: Yoshihiro Shimoda 
> Reviewed-by: Geert Uytterhoeven 

Hi Shimoda-san,

the minor suggestion below not withstanding this looks good to me.

Reviewed-by: Simon Horman 

> ---
>  Changes from v1 [1]:
>  - Use sizeof(variable) instead of sizeof(type).
>  - Add Geert-san's reviewed-by (thanks!).
> 
> [1]
> https://patchwork.kernel.org/patch/10938575/
> 
>  drivers/usb/renesas_usbhs/common.c | 112 
> +
>  drivers/usb/renesas_usbhs/common.h |   5 ++
>  2 files changed, 70 insertions(+), 47 deletions(-)
> 
> diff --git a/drivers/usb/renesas_usbhs/common.c 
> b/drivers/usb/renesas_usbhs/common.c
> index 249fbee..0ca89de 100644
> --- a/drivers/usb/renesas_usbhs/common.c
> +++ b/drivers/usb/renesas_usbhs/common.c
> @@ -535,53 +535,92 @@ static int usbhsc_drvcllbck_notify_hotplug(struct 
> platform_device *pdev)
>   return 0;
>  }
>  
> +static const struct usbhs_of_data rcar_gen2_data = {
> + .platform_callback = &usbhs_rcar2_ops,
> + .param = {
> + .type = USBHS_TYPE_RCAR_GEN2,
> + .has_usb_dmac = 1,
> + .pipe_configs = usbhsc_new_pipe,
> + .pipe_size = ARRAY_SIZE(usbhsc_new_pipe),
> + }
> +};
> +
> +static const struct usbhs_of_data rcar_gen3_data = {
> + .platform_callback = &usbhs_rcar3_ops,
> + .param = {
> + .type = USBHS_TYPE_RCAR_GEN3,
> + .has_usb_dmac = 1,
> + .pipe_configs = usbhsc_new_pipe,
> + .pipe_size = ARRAY_SIZE(usbhsc_new_pipe),
> + }
> +};
> +
> +static const struct usbhs_of_data rcar_gen3_with_pll_data = {
> + .platform_callback = &usbhs_rcar3_with_pll_ops,
> + .param = {
> + .type = USBHS_TYPE_RCAR_GEN3_WITH_PLL,
> + .has_usb_dmac = 1,
> + .pipe_configs = usbhsc_new_pipe,
> + .pipe_size = ARRAY_SIZE(usbhsc_new_pipe),
> + }
> +};
> +
> +static const struct usbhs_of_data rza1_data = {
> + .platform_callback = &usbhs_rza1_ops,
> + .param = {
> + .type = USBHS_TYPE_RZA1,
> + .pipe_configs = usbhsc_new_pipe,
> + .pipe_size = ARRAY_SIZE(usbhsc_new_pipe),
> + }
> +};
> +
>  /*
>   *   platform functions
>   */
>  static const struct of_device_id usbhs_of_match[] = {
>   {
>   .compatible = "renesas,usbhs-r8a774c0",
> - .data = (void *)USBHS_TYPE_RCAR_GEN3_WITH_PLL,
> + .data = &rcar_gen3_with_pll_data,
>   },
>   {
>   .compatible = "renesas,usbhs-r8a7790",
> - .data = (void *)USBHS_TYPE_RCAR_GEN2,
> + .data = &rcar_gen2_data,
>   },
>   {
>   .compatible = "renesas,usbhs-r8a7791",
> - .data = (void *)USBHS_TYPE_RCAR_GEN2,
> + .data = &rcar_gen2_data,
>   },
>   {
>   .compatible = "renesas,usbhs-r8a7794",
> - .data = (void *)USBHS_TYPE_RCAR_GEN2,
> + .data = &rcar_gen2_data,
>   },
>   {
>   .compatible = "renesas,usbhs-r8a7795",
> - .data = (void *)USBHS_TYPE_RCAR_GEN3,
> + .data = &rcar_gen3_data,
>   },
>   {
>   .compatible = "renesas,usbhs-r8a7796",
> - .data = (void *)USBHS_TYPE_RCAR_GEN3,
> + .data = &rcar_gen3_data,
>   },
>   {
>   .compatible = "renesas,usbhs-r8a77990",
> - .data = (void *)USBHS_TYPE_RCAR_GEN3_WITH_PLL,
> + .data = &rcar_gen3_with_pll_data,
>   },
>   {
>   .compatible = "renesas,usbhs-r8a77995",
> - .data = (void *)USBHS_TYPE_RCAR_GEN3_WITH_PLL,
> + .data = &rcar_gen3_with_pll_data,
>   },
>   {
>   .compatible = "renesas,rcar-gen2-usbhs",
> - .data = (void *)USBHS_TYPE_RCAR_GEN2,
> + .data = &rcar_gen2_data,
>   },
>   {
>   .compatible = "renesas,rcar-gen3-usbhs",
> - .data = (void *)USBHS_TYPE_RCAR_GEN3,
> + .data = &rcar_gen3_data,
>   },
>   {
>   .compatible = "renesas,rza1-usbhs",
> - .data = (void *)USBHS_TYPE_RZA1,
> + .data = &rza1_data,
>   },
>   { }

Re: [PATCH 0/4] Add USB-HOST support to cat874

2019-03-06 Thread Simon Horman
On Fri, Mar 01, 2019 at 11:05:44AM +, Fabrizio Castro wrote:
> While trying to add USB-HOST support to the cat874 board,
> it came up that of_usb_get_dr_mode_by_phy was selecting
> the wrong DT node to use for dr_mode.
> Also, drivers/phy/renesas/phy-rcar-gen3-usb2.c was registering
> IRQs, no matter the dr_mode.
> 
> This series adds all that is required to add USB-HOST support
> to the cat874 board, and also removes the hsusb from Draak's DT
> as not necessary anymore.
> 
> Thanks,
> Fab
> 
> Fabrizio Castro (4):
>   usb: common: Consider only available nodes for dr_mode
>   phy: renesas: rcar-gen3-usb2: No need to request IRQ for non-OTG

Hi Fabrizio,

I am marking the patches below deferred pending acceptance of the patches
above.

>   arm64: dts: renesas: r8a774c0-cat874: Add USB-HOST support
>   arm64: dts: renesas: r8a77995: draak: Remove hsusb node
> 
>  arch/arm64/boot/dts/renesas/r8a774c0-cat874.dts | 15 ++
>  arch/arm64/boot/dts/renesas/r8a77995-draak.dts  |  5 -
>  drivers/phy/renesas/phy-rcar-gen3-usb2.c| 26 
> -
>  drivers/usb/common/common.c |  2 ++
>  4 files changed, 30 insertions(+), 18 deletions(-)
> 
> -- 
> 2.7.4
> 


Re: [PATCH 0/9] Add USB3.0 and TI HD3SS3220 driver support

2019-03-06 Thread Simon Horman
On Wed, Mar 06, 2019 at 09:07:17AM +, Biju Das wrote:
> This series adds USB 3.0 support for the CAT874 platform, including a
> new driver for the TI HD3SS3220 USB Type-C DRP port controller.
> 
> This patch series supports:
> 1) Host hotplug operation
> 2) Device hot plug operation
> 3) USB type-C data_role switch 
>(Tested with 2 RZ/G2E boards connected with a Type-C cable)
> 
> This patchset is based on usb_next and renesas-devel-20190304-v5.0 branch.
> 
> Biju Das (9):
>   dt-bindings: usb: hd3ss3220 device tree binding document
>   dt-bindings: usb: renesas_usb3: add extcon support
>   usb: typec: driver for TI HD3SS3220 USB Type-C DRP port controller
>   usb: gadget: udc: renesas_usb3: use extcon framework to receive
> connect/disconnect

Hi Biju,

I am marking the patches below as deffered pending acceptance of
the dt-bindings patches above.

>   arm64: defconfig: enable TYPEC_HD3SS3220 config option
>   arm64: renesas_defconfig: Enable TYPEC_HD3SS3220 config option
>   arm64: dts: renesas: r8a774c0-cat874: enable USB3.0 host/peripheral
> device node
>   arm64: dts: renesas: r8a774c0-cat874: Enable TI HD3SS3220 support
>   arm64: dts: renesas: r8a774c0-cat874: Enable extcon support
> 
>  .../devicetree/bindings/usb/renesas_usb3.txt   |   2 +
>  .../devicetree/bindings/usb/ti,hd3ss3220.txt   |  15 ++
>  arch/arm64/boot/dts/renesas/r8a774c0-cat874.dts|  31 +++
>  arch/arm64/configs/defconfig   |   2 +
>  arch/arm64/configs/renesas_defconfig   |   2 +
>  drivers/usb/gadget/udc/renesas_usb3.c  | 115 +++--
>  drivers/usb/typec/Kconfig  |  10 +
>  drivers/usb/typec/Makefile |   1 +
>  drivers/usb/typec/hd3ss3220.c  | 284 
> +
>  9 files changed, 446 insertions(+), 16 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/usb/ti,hd3ss3220.txt
>  create mode 100644 drivers/usb/typec/hd3ss3220.c
> 
> -- 
> 2.7.4
> 


Re: Location of HUB USB Report Descriptors?

2019-02-14 Thread Simon Wood
On Thu, February 14, 2019 11:10 am, Alan Stern wrote:

>> The 'HUB descriptor' is not contained within the 'descriptors' file
>> from the '/sys' interface, although I suspect that it can be accessed
>> via _another_ file within '/sys' hopefully someone can point me at
>> it.
>
> No, there is no sysfs file containing the content of the hub
> descriptor.

:-(

>
> On the other hand, it's not too hard to write a program to retrieve the
> hub descriptor from a hub via usbfs or using libusb.  Or you can just copy
> the code in lsusb.

I will attempt coding something, or take some other approach in my
investigations.

Thank you both so much for your replies,
Simon



Re: Location of HUB USB Report Descriptors?

2019-02-14 Thread Simon Wood
On Thu, February 14, 2019 9:42 am, Greg KH wrote:

> That's because Android is using toybox's version of 'lsusb'.  I
> recommend using the real version if you need this information.

I would if I could, I do not control the BSP for this hardware :-(

>> I have found the 'descriptors' file for the USB device under the '/sys'
>>  interface, however this does not appear to contain the HUB specific
>> details.
>
> Really?  It should, why does it not contain that information?  That's a
> binary file that lists the USB descriptor information.  You are going to
> have to "parse it by hand".

Attached is a snap-shot of a (random) hub on Desktop linux.

The 'HUB descriptor' is not contained within the 'descriptors' file from
the '/sys' interface, although I suspect that it can be accessed via
_another_ file within '/sys' hopefully someone can point me at it.

Decoding is not hard with the power of the interwebs:
https://eleccelerator.com/usbdescreqparser/


The 'descriptors' file from my suspect device (on Android) was attached to
original post.

Thanks,
Simon.root@smart:/sys/bus/usb/devices/usb1/1-1/1-1.1# cat idProduct 
0605

root@smart:/sys/bus/usb/devices/usb1/1-1/1-1.1# lsusb
Bus 002 Device 003: ID 045e:0040 Microsoft Corp. Wheel Mouse Optical
Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 006 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 004: ID 05e3:0605 Genesys Logic, Inc. USB 2.0 Hub 
<-- this device
Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 002: ID 046d:c31c Logitech, Inc. Keyboard K120
Bus 003 Device 004: ID 18a5:0302 Verbatim, Ltd Flash Drive
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

root@smart:/sys/bus/usb/devices/usb1/1-1/1-1.1# hexdump -C descriptors 
  12 01 00 02 09 00 01 40  e3 05 05 06 0b 06 00 01  |...@|
0010  00 01 09 02 19 00 01 01  00 e0 32 09 04 00 00 01  |..2.|
0020  09 00 00 00 07 05 81 03  01 00 0c |...|
002b
root@smart:/sys/bus/usb/devices/usb1/1-1/1-1.1# lsusb -vv
...
Bus 001 Device 004: ID 05e3:0605 Genesys Logic, Inc. USB 2.0 Hub
Device Descriptor: <- this is in the 'descriptors' 
file
  bLength18
  bDescriptorType 1
  bcdUSB   2.00
  bDeviceClass9 Hub
  bDeviceSubClass 0 Unused
  bDeviceProtocol 1 Single TT
  bMaxPacketSize064
  idVendor   0x05e3 Genesys Logic, Inc.
  idProduct  0x0605 USB 2.0 Hub
  bcdDevice6.0b
  iManufacturer   0 
  iProduct1 USB2.0 Hub
  iSerial 0 
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength   25
bNumInterfaces  1
bConfigurationValue 1
iConfiguration  0 
bmAttributes 0xe0
  Self Powered
  Remote Wakeup
MaxPower  100mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   1
  bInterfaceClass 9 Hub
  bInterfaceSubClass  0 Unused
  bInterfaceProtocol  0 Full speed (or root) hub
  iInterface  0 
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81  EP 1 IN
bmAttributes3
  Transfer TypeInterrupt
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0001  1x 1 bytes
bInterval  12
Hub Descriptor: <--- this does NOT appear in 
'descriptors'.
  bLength   9
  bDescriptorType  41
  nNbrPorts 4
  wHubCharacteristic 0x00e0
Ganged power switching
Ganged overcurrent protection
TT think time 32 FS bits
Port indicators
  bPwrOn2PwrGood   50 * 2 milli seconds
  bHubContrCurrent100 milli Ampere
  DeviceRemovable0x00
  PortPwrCtrlMask0xff
 Hub Port Status:
   Port 1: .0100 power
   Port 2: .0100 power
   Port 3: .0100 power
   Port 4: .0100 power
Device Qualifier (for other device speed):
  bLength10
  bDescriptorType 6
  bcdUSB   2.00
  bDeviceClass9 Hub
  bDeviceSubClass 0 Unused
  bDeviceProtocol 0 Full speed (or root) hub
  bMaxPacketSize064
  bNumConfigurations  1
Device Status: 0x0001
  Self Powered
...


Decode 'descriptors' via the interwebs...
https://el

Location of HUB USB Report Descriptors?

2019-02-14 Thread Simon Wood
I am attempted to debug an android problem related to USB hubs.

On desktop Linux 'lsusb -vv' details the HUB description, but 'lsusb' on
Android is the simple cousin and does not know this information.

I have found the 'descriptors' file for the USB device under the '/sys'
interface, however this does not appear to contain the HUB specific
details.

Is there another file somewhere, and can someone point me at it?

Specifically I am looking for the binary file which decodes like this...
--
Hub Descriptor:
  bLength   9
  bDescriptorType  41
  nNbrPorts 4
  wHubCharacteristic 0x00e0
Ganged power switching
Ganged overcurrent protection
TT think time 32 FS bits
Port indicators
  bPwrOn2PwrGood   50 * 2 milli seconds
  bHubContrCurrent100 milli Ampere
  DeviceRemovable0x00
  PortPwrCtrlMask0xff
 Hub Port Status:
   Port 1: .0100 power
   Port 2: .0100 power
   Port 3: .0100 power
   Port 4: .0100 power
Device Qualifier (for other device speed):
  bLength10
  bDescriptorType 6
  bcdUSB   2.00
  bDeviceClass9 Hub
  bDeviceSubClass 0 Unused
  bDeviceProtocol 0 Full speed (or root) hub
  bMaxPacketSize064
  bNumConfigurations  1
Device Status: 0x0001
  Self Powered
--

Many thanks in advance,
Simon.   12 01 10 02 09 00 02 40 E3 05 10 06 03 93 01 02   ...@ã...
0010   00 01 09 02 29 00 01 01 00 E0 32 09 04 00 00 01   )à2.
0020   09 00 01 00 07 05 81 03 01 00 0C 09 04 00 01 01   
0030   09 00 02 00 07 05 81 03 01 00 0C  ... 


0x12,// bLength
0x01,// bDescriptorType (Device)
0x10, 0x02,  // bcdUSB 2.10
0x09,// bDeviceClass (Hub)
0x00,// bDeviceSubClass 
0x02,// bDeviceProtocol (High Speed Hub with multiple TT)
0x40,// bMaxPacketSize0 64
0xE3, 0x05,  // idVendor 0x05E3
0x10, 0x06,  // idProduct 0x0610
0x03, 0x93,  // bcdDevice 240.03
0x01,// iManufacturer (String Index)
0x02,// iProduct (String Index)
0x00,// iSerialNumber (String Index)
0x01,// bNumConfigurations 1

0x09,// bLength
0x02,// bDescriptorType (Configuration)
0x29, 0x00,  // wTotalLength 41
0x01,// bNumInterfaces 1
0x01,// bConfigurationValue
0x00,// iConfiguration (String Index)
0xE0,// bmAttributes Remote Wakeup, Self Powered
0x32,// bMaxPower 100mA

0x09,// bLength
0x04,// bDescriptorType (Interface)
0x00,// bInterfaceNumber 0
0x00,// bAlternateSetting
0x01,// bNumEndpoints 1
0x09,// bInterfaceClass
0x00,// bInterfaceSubClass
0x01,// bInterfaceProtocol
0x00,// iInterface (String Index)

0x07,// bLength
0x05,// bDescriptorType (Endpoint)
0x81,// bEndpointAddress (IN/D2H)
0x03,// bmAttributes (Interrupt)
0x01, 0x00,  // wMaxPacketSize 1
0x0C,// bInterval 12 (unit depends on device speed)

0x09,// bLength
0x04,// bDescriptorType (Interface)
0x00,// bInterfaceNumber 0
0x01,// bAlternateSetting
0x01,// bNumEndpoints 1
0x09,// bInterfaceClass
0x00,// bInterfaceSubClass
0x02,// bInterfaceProtocol
0x00,// iInterface (String Index)

0x07,// bLength
0x05,// bDescriptorType (Endpoint)
0x81,// bEndpointAddress (IN/D2H)
0x03,// bmAttributes (Interrupt)
0x01, 0x00,  // wMaxPacketSize 1
0x0C,// bInterval 12 (unit depends on device speed)

// 59 bytes

Re: [PATCH] usb: renesas_usbhs: replace udelay() with usleep_range()

2019-01-17 Thread Simon Horman
On Thu, Jan 17, 2019 at 04:24:15PM +0900, Yoshihiro Shimoda wrote:
> According to Documentation/timers/timers-howto.txt, a driver should
> use usleep_range() instead of udelay() on NON-ATOMIC CONTEXT if
> "SLEEPING FOR ~USECS OR SMALL MSECS ( 10us - 20ms)".
> 
> Since the .hardware_init() and .power_ctrl() will run on NON-ATOMIC
> CONTEXT, this patch replaces udelay() with usleep_range().
> 
> Signed-off-by: Yoshihiro Shimoda 

Reviewed-by: Simon Horman 



Re: [PATCH] usb: gadget: udc: renesas_usb3: add support for r8a774c0

2018-12-16 Thread Simon Horman
On Thu, Dec 13, 2018 at 08:23:55PM +, Fabrizio Castro wrote:
> RZ/G2E USB 3.0 implementation is like the one found on R-Car E3,
> therefore add the same quirk.
> 
> Signed-off-by: Fabrizio Castro 

Reviewed-by: Simon Horman 



Re: [PATCH] usb: gadget: udc: renesas_usb3: Add bindings for r8a774c0

2018-12-16 Thread Simon Horman
On Thu, Dec 13, 2018 at 08:22:18PM +, Fabrizio Castro wrote:
> Document RZ/G2E (R8A774C0) SoC bindings.
> 
> Signed-off-by: Fabrizio Castro 

Reviewed-by: Simon Horman 



Re: [PATCH] dt-bindings: usb: renesas_usbhs: Add r8a774c0 support

2018-12-15 Thread Simon Horman
On Thu, Dec 13, 2018 at 08:21:03PM +, Fabrizio Castro wrote:
> Document RZ/G2E (R8A774C0) SoC bindings.
> 
> Signed-off-by: Fabrizio Castro 

Reviewed-by: Simon Horman 



Re: [PATCH] usb: renesas_usbhs: add support for RZ/G2E

2018-12-15 Thread Simon Horman
On Fri, Dec 14, 2018 at 08:27:03AM +, Fabrizio Castro wrote:
> HS-USB found in RZ/G2E (a.k.a. r8a774c0) is very similar to the
> one found in R-Car E3 (a.k.a. r8a77990), as it needs to release
> the PLL reset by the UGCTRL register like R-Car E3, therefore add
> r8a774c0 support in a similar fashion to what was done for the
> r8a77990.
> 
> Signed-off-by: Fabrizio Castro 

Reviewed-by: Simon Horman 



Re: [PATCH] dt-bindings: usb-xhci: Add r8a774c0 support

2018-12-14 Thread Simon Horman
On Thu, Dec 13, 2018 at 08:21:11PM +, Fabrizio Castro wrote:
> Document RZ/G2E (R8A774C0) SoC bindings.
> 
> Signed-off-by: Fabrizio Castro 

Reviewed-by: Simon Horman 


Re: Logitech G27 leds no more supported

2018-10-23 Thread Simon Wood
On Sun, October 21, 2018 10:43 am, elrond...@protonmail.com wrote:
> SOLVED that's due to this is compiled as modules:
> CONFIG_LEDS_SYSCON
> CONFIG_LEDS_SYSCON
>
>
> and not as YES option

I'm not seeing the connection between this being a module and breaking
(specifically) the Logitech driver. We're only checking
'CONFIG_LEDS_CLASS'.

Did you have 'CONFIG_LEDS_CLASS' compiled as a module as well?

I did a workaround for this in the SteelSeries driver...
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/hid/hid-steelseries.c?h=v4.19#n20
--
#if IS_BUILTIN(CONFIG_LEDS_CLASS) || \
(IS_MODULE(CONFIG_LEDS_CLASS) && IS_MODULE(CONFIG_HID_STEELSERIES))
#define SRWS1_NUMBER_LEDS 15
struct steelseries_srws1_data {
__u16 led_state;
/* the last element is used for setting all leds simultaneously */
struct led_classdev *led[SRWS1_NUMBER_LEDS + 1];
};
#endif
--

Cheers,
Simon


https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/leds/Kconfig?h=v4.19
--
config LEDS_SYSCON
bool "LED support for LEDs on system controllers"
depends on LEDS_CLASS=y
depends on MFD_SYSCON
depends on OF
help
  This option enables support for the LEDs on syscon type
  devices. This will only work with device tree enabled
  devices.
--

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/hid/Kconfig?h=v4.19#n548
--
config LOGIWHEELS_FF
bool "Logitech wheels configuration and force feedback support"
depends on HID_LOGITECH
select INPUT_FF_MEMLESS
default LOGITECH_FF
help
  Say Y here if you want to enable force feedback and range setting(*)
  support for following Logitech wheels:
  - Logitech G25 (*)
  - Logitech G27 (*)
  - Logitech G29 (*)
  - Logitech Driving Force
  - Logitech Driving Force Pro (*)
  - Logitech Driving Force GT (*)
  - Logitech Driving Force EX/RX
  - Logitech Driving Force Wireless
  - Logitech Speed Force Wireless
  - Logitech MOMO Force
  - Logitech MOMO Racing Force
  - Logitech Formula Force GP
  - Logitech Formula Force EX/RX
  - Logitech Wingman Formula Force GP
--


https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/hid/hid-lg4ff.c?h=v4.19#n1087
--
#ifdef CONFIG_LEDS_CLASS
static void lg4ff_set_leds(struct hid_device *hid, u8 leds)
{
--



Re: Logitech G27 leds no more supported

2018-10-19 Thread Simon Wood
On Fri, October 19, 2018 4:46 pm, Simon Wood wrote:

> Thanks for the report, and yes it does seem broken. I tried on
> 4.17.0-rc5+
> and it seems that the 'hid-logitech' module does not know the device ID of
>  the G29 anymore.

Oh, how easily we forget things... there's a switch on the top wheel
(close to LEDs) which changes the wheel into a compatibility mode.

Flipping this get wheel recognized and working on 4.17.0-rc5+
--
root@thevoid:/sys/class/leds# ls
0003:046D:C24F.0009::RPM1  0003:046D:C24F.0009::RPM4  input3::numlock
input8::compose  input8::scrolllock
0003:046D:C24F.0009::RPM2  0003:046D:C24F.0009::RPM5  input3::scrolllock 
input8::kana
0003:046D:C24F.0009::RPM3  input3::capslock   input8::capslock   
input8::numlock
root@thevoid:/sys/class/leds# cd 0003\:046D\:C24F.0009\:\:RPM4
root@thevoid:/sys/class/leds/0003:046D:C24F.0009::RPM4# ls
brightness  device  max_brightness  power  subsystem  trigger  uevent
root@thevoid:/sys/class/leds/0003:046D:C24F.0009::RPM4# cat max_brightness
> brightness
--

I'll rebuild HEAD to confirm it still works.
Simon.

PS. We should maybe pick up that other USB Id.



Re: Logitech G27 leds no more supported

2018-10-19 Thread Simon Wood
On Wed, October 17, 2018 11:21 pm, Greg KH wrote:
> On Wed, Oct 17, 2018 at 02:44:51PM +, elrond...@protonmail.com wrote:
>> No more leds subdirectory for this wheel, someone reports me G29 leds
>> stays supported correctly.
>>
>> No more path: /sys/class/leds/logitechwheelpath, just my keyboard leds
>> are detected. Force feedback are correctly supported.
>>

> What kernel version did this work properly on?
>
>
> And I think the linux-input mailing list would want to know about this,
> this isn't a usb-core specific issue.  I've added them to the cc: here.
> thanks,

Thanks for the report, and yes it does seem broken. I tried on 4.17.0-rc5+
and it seems that the 'hid-logitech' module does not know the device ID of
the G29 anymore.

Support was originally added in 29fae1c85166ef525b8b6518e749295e0c9d1e20,
but that was a long time ago and it seems that the 'hid-core.c' stuff has
somewhat changed

Will continue looking for cause.
Simon
Syslog on insert
--
Oct 19 16:16:04 thevoid kernel: [33656.156644] usb 1-2: new full-speed USB 
device number 12 using xhci_hcd
Oct 19 16:16:05 thevoid kernel: [33656.306093] usb 1-2: New USB device found, 
idVendor=046d, idProduct=c260, bcdDevice=89.00
Oct 19 16:16:05 thevoid kernel: [33656.306106] usb 1-2: New USB device strings: 
Mfr=1, Product=2, SerialNumber=0
Oct 19 16:16:05 thevoid kernel: [33656.306114] usb 1-2: Product: G29 Driving 
Force Racing Wheel
Oct 19 16:16:05 thevoid kernel: [33656.306122] usb 1-2: Manufacturer: Logitech
Oct 19 16:16:05 thevoid kernel: [33656.314487] input: Logitech G29 Driving 
Force Racing Wheel as 
/devices/pci:00/:00:14.0/usb1/1-2/1-2:1.0/0003:046D:C260.0006/input/input22
Oct 19 16:16:05 thevoid kernel: [33656.373288] hid-generic 0003:046D:C260.0006: 
input,hiddev3,hidraw5: USB HID v1.10 Joystick [Logitech G29 Driving Force 
Racing Wheel] on usb-:00:14.0-2/input0
Oct 19 16:16:05 thevoid mtp-probe: checking bus 1, device 12: 
"/sys/devices/pci:00/:00:14.0/usb1/1-2"
Oct 19 16:16:05 thevoid mtp-probe: bus: 1, device: 12 was not an MTP device
Oct 19 16:16:05 thevoid upowerd[1405]: unhandled action 'bind' on 
/sys/devices/pci:00/:00:14.0/usb1/1-2/1-2:1.0/0003:046D:C260.0006
Oct 19 16:16:05 thevoid upowerd[1405]: unhandled action 'bind' on 
/sys/devices/pci:00/:00:14.0/usb1/1-2/1-2:1.0
Oct 19 16:16:05 thevoid upowerd[1405]: unhandled action 'bind' on 
/sys/devices/pci:00/:00:14.0/usb1/1-2
--

lsusb -vv
--
Bus 001 Device 012: ID 046d:c260 Logitech, Inc. 
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   1.00
  bDeviceClass0 (Defined at Interface level)
  bDeviceSubClass 0 
  bDeviceProtocol 0 
  bMaxPacketSize064
  idVendor   0x046d Logitech, Inc.
  idProduct  0xc260 
  bcdDevice   89.00
  iManufacturer   1 
  iProduct2 
  iSerial 0 
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength   41
bNumInterfaces  1
bConfigurationValue 1
iConfiguration  0 
bmAttributes 0x80
  (Bus Powered)
MaxPower  200mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   2
  bInterfaceClass 3 Human Interface Device
  bInterfaceSubClass  0 No Subclass
  bInterfaceProtocol  0 None
  iInterface  0 
HID Device Descriptor:
  bLength 9
  bDescriptorType33
  bcdHID   1.10
  bCountryCode0 Not supported
  bNumDescriptors 1
  bDescriptorType34 Report
  wDescriptorLength 160
 Report Descriptors: 
   ** UNAVAILABLE **
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x03  EP 3 OUT
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
bmAttributes3
  Transfer TypeInterrupt
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0040  1x 64 bytes
bInterval   5
--

uname -a
--
Linux thevoid 4.17.0-rc5+ #11 SMP Sat May 19 11:08:23 MDT 2018 x86_64 x86_64 
x86_64 GNU/Linux
--
filename: 

Re: [PATCH] usb: gadget: udc: renesas_usb3: Fix b-device mode for "workaround"

2018-10-04 Thread Simon Horman
On Tue, Oct 02, 2018 at 08:57:44PM +0900, Yoshihiro Shimoda wrote:
> If the "workaround_for_vbus" is true, the driver will not call
> usb_disconnect(). So, since the controller keeps some registers'
> value, the driver doesn't re-enumarate suitable speed after
> the b-device mode is disabled. To fix the issue, this patch
> adds usb_disconnect() calling in renesas_usb3_b_device_write()
> if workaround_for_vbus is true.
> 
> Fixes: 43ba968b00ea ("usb: gadget: udc: renesas_usb3: add debugfs to set the 
> b-device mode")
> Cc:  # v4.14+
> Signed-off-by: Yoshihiro Shimoda 

Reviewed-by: Simon Horman 

> ---
>  drivers/usb/gadget/udc/renesas_usb3.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/usb/gadget/udc/renesas_usb3.c 
> b/drivers/usb/gadget/udc/renesas_usb3.c
> index e1656f3..67d8a50 100644
> --- a/drivers/usb/gadget/udc/renesas_usb3.c
> +++ b/drivers/usb/gadget/udc/renesas_usb3.c
> @@ -2437,6 +2437,9 @@ static ssize_t renesas_usb3_b_device_write(struct file 
> *file,
>   else
>   usb3->forced_b_device = false;
>  
> + if (usb3->workaround_for_vbus)
> + usb3_disconnect(usb3);
> +
>   /* Let this driver call usb3_connect() anyway */
>   usb3_check_id(usb3);
>  
> -- 
> 1.9.1
> 


Re: [PATCH] dt-bindings: usb-xhci: Document r8a7744 support

2018-10-01 Thread Simon Horman
On Thu, Sep 27, 2018 at 02:42:38PM +0100, Biju Das wrote:
> Document r8a7744 xhci support. The driver will use the fallback
> compatible string "renesas,rcar-gen2-xhci", therefore no driver
> change is needed.

Reviewed-by: Simon Horman 



Re: [PATCH] dt-bindings: usb: renesas_usbhs: Add support for r8a7744

2018-10-01 Thread Simon Horman
On Thu, Sep 27, 2018 at 02:01:16PM +0100, Biju Das wrote:
> Document support for RZ/G1N (R8A7744) SoC.
> 
> Signed-off-by: Biju Das 
> Reviewed-by: Chris Paterson 

Reviewed-by: Simon Horman 



Re: [PATCH 0/5] usb: renesas_usbhs: use otg mode and add support for R-Car E3

2018-09-25 Thread Simon Horman
On Fri, Sep 21, 2018 at 09:26:27PM +0900, Yoshihiro Shimoda wrote:
> This patch set is based on the latest Greg's usb.git / usb-testing branch
> (the commit id is ae8a2ca8a2215c7e31e6d874f7303801bb15fbbc)
> 
> The previous code set the mode as peripheral mode by the UGCTRL2 register
> for R-Car D3. But, this SoC can select OTG mode in fact. So, at first,
> I'd like to revert related patches I submitted in patch 1 and 2.
> Then, in patch 3, it sets the mode as "OTG" and in patch 4 and 5, it
> supports for R-Car E3.
> 
> To use this controller for R-Car D3 and E3, we need the following
> patch set. Otherwize, the mode will not be changed to peripheral mode
> by the phy's COMMCTRL register:
>  https://patchwork.kernel.org/project/linux-renesas-soc/list/?series=21629

Reviewed-by: Simon Horman 



Re: [PATCH 2/2] dt-bindings: usb: ohci: Add clocks description for R-Car Gen3

2018-09-11 Thread Simon Horman
On Mon, Sep 10, 2018 at 08:15:48PM +0900, Yoshihiro Shimoda wrote:
> This patch adds detailed information of an optional property "clocks"
> description for R-Car Gen3.
> 
> Signed-off-by: Yoshihiro Shimoda 

Reviewed-by: Simon Horman 



Re: [PATCH 1/2] dt-bindings: usb: ehci: Add clocks description for R-Car Gen3

2018-09-11 Thread Simon Horman
On Mon, Sep 10, 2018 at 08:15:47PM +0900, Yoshihiro Shimoda wrote:
> This patch adds detailed information of an optional property "clocks"
> description for R-Car Gen3.
> 
> Signed-off-by: Yoshihiro Shimoda 

Reviewed-by: Simon Horman 



Re: [PATCH/RFC v3 3/4] usb: gadget: udc: renesas_usb3: use usb role switch API

2018-05-15 Thread Simon Horman
On Tue, May 15, 2018 at 08:02:00AM +, Yoshihiro Shimoda wrote:
> Hi Simon-san,
> 
> Thank you for your review!
> 
> > From: Simon Horman, Sent: Tuesday, May 15, 2018 4:54 PM
> > On Mon, May 14, 2018 at 06:15:59PM +0900, Yoshihiro Shimoda wrote:
> 
> > >  static void usb3_set_mode(struct renesas_usb3 *usb3, bool host)
> > >  {
> > > - _usb3_set_mode(usb3, host);
> > > + if (usb3->role_sw)
> > > + usb_role_switch_set_role(usb3->role_sw, host ?
> > > +  USB_ROLE_HOST : USB_ROLE_DEVICE);
> > > + else
> > > + _usb3_set_mode(usb3, host);
> > >  }
> > >
> > >  static void usb3_vbus_out(struct renesas_usb3 *usb3, bool enable)
> > > @@ -672,8 +676,8 @@ static void usb3_mode_config(struct renesas_usb3 
> > > *usb3, bool host, bool a_dev)
> > >  {
> > >   unsigned long flags;
> > >
> > > - spin_lock_irqsave(&usb3->lock, flags);
> > >   usb3_set_mode(usb3, host);
> > > + spin_lock_irqsave(&usb3->lock, flags);
> > 
> > Hi Shimoda-san,
> > 
> > could you clarify why moving this lock is safe?
> 
> The usb3_set_mode() is possible to call usb_role_switch_set_role() API
> and usb_role_switch_set_role() calls mutex_lock().
> So, this moving this lock (especially avoiding irqsave) needs.

Thanks, that make sense.

But usb3_set_mode() may also call _usb3_set_mode().
It is safe to call _usb3_set_mode() without holding the lock?

> Best regards,
> Yoshihiro Shimoda
> 
> > >   usb3_vbus_out(usb3, a_dev);
> > >   /* for A-Peripheral or forced B-device mode */
> > >   if ((!host && a_dev) ||
> > > --
> > > 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 v2 6/6] usb: gadget: udc: renesas_usb3: disable the controller's irqs for reconnecting

2018-05-15 Thread Simon Horman
On Tue, May 15, 2018 at 07:49:44AM +, Yoshihiro Shimoda wrote:
> Hi Simon-san,
> 
> Thank you for your review!
> 
> > From: Simon Horman, Sent: Tuesday, May 15, 2018 4:35 PM
> > 
> > On Tue, Apr 10, 2018 at 02:38:54PM +0900, Yoshihiro Shimoda wrote:
> > > This patch fixes an issue that reconnection is possible to fail
> > > because unexpected state handling happens by the irqs. To fix the issue,
> > > the driver disables the controller's irqs when disconnected.
> > >
> > > Fixes: 746bfe63bba3 ("usb: gadget: renesas_usb3: add support for Renesas 
> > > USB3.0 peripheral controller")
> > > Cc:  # v4.5+
> > > Signed-off-by: Yoshihiro Shimoda 
> > > ---
> > >
> > > Remarks:
> > >  - A new file in v2
> > >
> > >  drivers/usb/gadget/udc/renesas_usb3.c | 7 +++
> > >  1 file changed, 7 insertions(+)
> > >
> > > diff --git a/drivers/usb/gadget/udc/renesas_usb3.c 
> > > b/drivers/usb/gadget/udc/renesas_usb3.c
> > > index 0e70163..5caf78b 100644
> > > --- a/drivers/usb/gadget/udc/renesas_usb3.c
> > > +++ b/drivers/usb/gadget/udc/renesas_usb3.c
> > > @@ -623,6 +623,13 @@ static void usb3_disconnect(struct renesas_usb3 
> > > *usb3)
> > >   usb3_usb2_pullup(usb3, 0);
> > >   usb3_clear_bit(usb3, USB30_CON_B3_CONNECT, USB3_USB30_CON);
> > >   usb3_reset_epc(usb3);
> > > + usb3_disable_irq_1(usb3, USB_INT_1_B2_RSUM | USB_INT_1_B3_PLLWKUP |
> > > +USB_INT_1_B3_LUPSUCS | USB_INT_1_B3_DISABLE |
> > > +USB_INT_1_SPEED | USB_INT_1_B3_WRMRST |
> > > +USB_INT_1_B3_HOTRST | USB_INT_1_B2_SPND |
> > > +USB_INT_1_B2_L1SPND | USB_INT_1_B2_USBRST);
> > 
> > Hi Shimoda-san,
> > 
> > is it intentional that USB_INT_1_VBUS_CNG is not disabled above?
> 
> Yes, because the USB_INT_1_VBUS_CNG is enabled in usb3_init_epc_registers() 
> below.

Thanks for the clarification,

Reviewed-by: Simon Horman 

> 
> > > + usb3_clear_bit(usb3, USB_COM_CON_SPD_MODE, USB3_USB_COM_CON);
> > > + usb3_init_epc_registers(usb3);
> 
> Best regards,
> Yoshihiro Shimoda
> 
> > >   if (usb3->driver)
> > >   usb3->driver->disconnect(&usb3->gadget);
> > > --
> > > 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/RFC v3 3/4] usb: gadget: udc: renesas_usb3: use usb role switch API

2018-05-15 Thread Simon Horman
On Mon, May 14, 2018 at 06:15:59PM +0900, Yoshihiro Shimoda wrote:
> This patch uses usb role switch API if the register suceeeded.
> 
> Signed-off-by: Yoshihiro Shimoda 
> ---
>  drivers/usb/gadget/udc/renesas_usb3.c | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/usb/gadget/udc/renesas_usb3.c 
> b/drivers/usb/gadget/udc/renesas_usb3.c
> index c878449..bfb5803 100644
> --- a/drivers/usb/gadget/udc/renesas_usb3.c
> +++ b/drivers/usb/gadget/udc/renesas_usb3.c
> @@ -657,7 +657,11 @@ static void _usb3_set_mode(struct renesas_usb3 *usb3, 
> bool host)
>  
>  static void usb3_set_mode(struct renesas_usb3 *usb3, bool host)
>  {
> - _usb3_set_mode(usb3, host);
> + if (usb3->role_sw)
> + usb_role_switch_set_role(usb3->role_sw, host ?
> +  USB_ROLE_HOST : USB_ROLE_DEVICE);
> + else
> + _usb3_set_mode(usb3, host);
>  }
>  
>  static void usb3_vbus_out(struct renesas_usb3 *usb3, bool enable)
> @@ -672,8 +676,8 @@ static void usb3_mode_config(struct renesas_usb3 *usb3, 
> bool host, bool a_dev)
>  {
>   unsigned long flags;
>  
> - spin_lock_irqsave(&usb3->lock, flags);
>   usb3_set_mode(usb3, host);
> + spin_lock_irqsave(&usb3->lock, flags);

Hi Shimoda-san,

could you clarify why moving this lock is safe?

>   usb3_vbus_out(usb3, a_dev);
>   /* for A-Peripheral or forced B-device mode */
>   if ((!host && a_dev) ||
> -- 
> 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 v2 6/6] usb: gadget: udc: renesas_usb3: disable the controller's irqs for reconnecting

2018-05-15 Thread Simon Horman
On Tue, Apr 10, 2018 at 02:38:54PM +0900, Yoshihiro Shimoda wrote:
> This patch fixes an issue that reconnection is possible to fail
> because unexpected state handling happens by the irqs. To fix the issue,
> the driver disables the controller's irqs when disconnected.
> 
> Fixes: 746bfe63bba3 ("usb: gadget: renesas_usb3: add support for Renesas 
> USB3.0 peripheral controller")
> Cc:  # v4.5+
> Signed-off-by: Yoshihiro Shimoda 
> ---
> 
> Remarks:
>  - A new file in v2
> 
>  drivers/usb/gadget/udc/renesas_usb3.c | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/drivers/usb/gadget/udc/renesas_usb3.c 
> b/drivers/usb/gadget/udc/renesas_usb3.c
> index 0e70163..5caf78b 100644
> --- a/drivers/usb/gadget/udc/renesas_usb3.c
> +++ b/drivers/usb/gadget/udc/renesas_usb3.c
> @@ -623,6 +623,13 @@ static void usb3_disconnect(struct renesas_usb3 *usb3)
>   usb3_usb2_pullup(usb3, 0);
>   usb3_clear_bit(usb3, USB30_CON_B3_CONNECT, USB3_USB30_CON);
>   usb3_reset_epc(usb3);
> + usb3_disable_irq_1(usb3, USB_INT_1_B2_RSUM | USB_INT_1_B3_PLLWKUP |
> +USB_INT_1_B3_LUPSUCS | USB_INT_1_B3_DISABLE |
> +USB_INT_1_SPEED | USB_INT_1_B3_WRMRST |
> +USB_INT_1_B3_HOTRST | USB_INT_1_B2_SPND |
> +USB_INT_1_B2_L1SPND | USB_INT_1_B2_USBRST);

Hi Shimoda-san,

is it intentional that USB_INT_1_VBUS_CNG is not disabled above?

> + usb3_clear_bit(usb3, USB_COM_CON_SPD_MODE, USB3_USB_COM_CON);
> + usb3_init_epc_registers(usb3);
>  
>   if (usb3->driver)
>   usb3->driver->disconnect(&usb3->gadget);
> -- 
> 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 v2 5/6] usb: gadget: udc: renesas_usb3: should fail if devm_phy_get() returns error

2018-05-15 Thread Simon Horman
On Tue, Apr 10, 2018 at 02:38:53PM +0900, Yoshihiro Shimoda wrote:
> This patch fixes an issue that this driver ignores errors other than
> the non-existence of the device, f.e. a memory allocation failure
> in devm_phy_get(). So, this patch replaces devm_phy_get() with
> devm_phy_optional_get().
> 
> Reported-by: Simon Horman 
> Fixes: 279d4bc64060 ("usb: gadget: udc: renesas_usb3: add support for generic 
> phy")
> Cc:  # v4.15+
> Signed-off-by: Yoshihiro Shimoda 

Reviewed-by: Simon Horman 

> ---
> Remarks:
>  - A new file in v2
> 
>  drivers/usb/gadget/udc/renesas_usb3.c | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/usb/gadget/udc/renesas_usb3.c 
> b/drivers/usb/gadget/udc/renesas_usb3.c
> index 233bc04..0e70163 100644
> --- a/drivers/usb/gadget/udc/renesas_usb3.c
> +++ b/drivers/usb/gadget/udc/renesas_usb3.c
> @@ -2636,9 +2636,11 @@ static int renesas_usb3_probe(struct platform_device 
> *pdev)
>* This is optional. So, if this driver cannot get a phy,
>* this driver will not handle a phy anymore.
>*/
> - usb3->phy = devm_phy_get(&pdev->dev, "usb");
> - if (IS_ERR(usb3->phy))
> - usb3->phy = NULL;
> + usb3->phy = devm_phy_optional_get(&pdev->dev, "usb");
> + if (IS_ERR(usb3->phy)) {
> + ret = PTR_ERR(usb3->phy);
> + goto err_add_udc;
> + }
>  
>   pm_runtime_enable(&pdev->dev);
>   ret = usb_add_gadget_udc(&pdev->dev, &usb3->gadget);
> -- 
> 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 v1 0/2] usb: dwc2: gadget: Fixes for LPM

2018-05-07 Thread Simon Shields
Hi Grigor,

On Wed, May 02, 2018 at 10:12:27AM +, Grigor Tovmasyan wrote:
> Hi Simon,
> 
> On 4/21/2018 4:52 PM, Simon Shields wrote:
> > Hi Grigor,
> > 
> > On Fri, Apr 20, 2018 at 01:00:16PM +, Grigor Tovmasyan wrote:
> >> Hi Simon,
> >>
> >> On 4/19/2018 8:31 PM, Simon Shields wrote:
> >>> Hi all,
> >>>
> >>> On 10/04/2018 10:21 PM, Grigor Tovmasyan wrote:
> >>>> Here are two little fixes for LPM feature.
> >>>>
> >>>> First one is coverity warning fix.
> >>>>
> >>>> The Second one was asserted by Stefan Wahren.
> >>>>
> >>>> Changes from version 0:
> >>>>
> >>>> 1/2:
> >>>>   - Instead of converting parameter in the CHECK_RANGE macro
> >>>> to int, changed hird_threshold type from u8 to int.
> >>>>
> >>>>
> >>>> Grigor Tovmasyan (2):
> >>>>  usb: dwc2: gadget: Fix coverity issue
> >>>>  usb: dwc2: gadget: Change LPM default values
> >>>>
> >>>> drivers/usb/dwc2/core.h   | 2 +-
> >>>> drivers/usb/dwc2/params.c | 8 
> >>>> 2 files changed, 5 insertions(+), 5 deletions(-)
> >>>
> >>> The second patch in this series fixes a regression in 4.17-rc1 using dwc2 
> >>> in gadget
> >>> mode on Exynos4412, introduced by commit 7455f8b7f0b3 ("usb: dwc2: Enable
> >>> LPM"). The regression is that using the cdc_acm serial gadget (and
> >>> presumably other gadgets) serial console output will only sporadically
> >>> show up on the host (it seems to only show up as input is sent).
> >>>
> >> The second patch is not fix for described by you issue. We will try to
> >> reproduce your issue and provide fix. Could you provide some logs or usb
> >> traces for issue?
> > 
> > Here's a log[0]. The log is pretty big: I generated it with both regular 
> > and verbose
> > debugging enabled for DWC2. However, I suspect the relevant line is
> > probably:
> > 
> > [   95.222330] dwc2 1248.hsotg: dwc2_hsotg_ep_queue: submit request 
> > only in active state
> > 
> > Which occurs whenever the controller is in LPM mode. I guess that input
> > makes it "work" because it reawakens the controller -- but I'm just
> > spitballing :-). Let me know if you need any more information from my
> > side.
> > 
> > [0]: 
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__forkwhiletrue.me_-7Esimon_midas-5Fdwc2-5Flpm-5Fverbose.log&d=DwIBAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=K1ULVL1slpLXpMJJlAXSOxws4tRq0IkTBqxDkyW2hUQ&m=fkdnWR9_dgHLGH5-mN9lDclJ58GWR__m7hS3zz3am28&s=aind-wCFaB40EyTcHvphrqt6SngQTnf3CYXJxOfBjWc&e=
> > 
> >>
> >>> However, I'm unsure if completely disabling LPM is the correct fix, as 
> >>> the dwc2
> >>> revision in Exynos4412 (0x4f54281a) should support LPM according to the
> >>> source
> >> Yes, we can enable LPM based on hardware configuration.
> >>
> >>> I'm not really sure how to debug this any further (vendor kernel
> >>> releases contain no mention of LPM in the gadget drivers), so any pointers
> >>> in that direction would be much appreciated.
> >>>
> >>> Cheers,
> >>> Simon
> >>>
> >>
> > 
> > Cheers,
> > Simon
> > 
> 
> Could you please revert "usb: dwc2: Add core state checking" patch and 
> try again.

This doesn't really fix the issue, but it does change the results. Now, input 
works
as expected, but output is still only shown after input is given (e.g.
the output of "dmesg" only shows if I press a key after executing dmesg).
However, after a few seconds the USB serial device disappears from the
host entirely. Once this has happened, reading the "regdump" of dwc2's debugfs
appears to hang the system (i.e. it no longer responds to UART). I've attached
another log[0].

[0]: https://forkwhiletrue.me/~simon/midas_dwc2_revert_verbose.log

> 
> Let me know about result.
> 
> Thanks,
> Grigor.

Cheers,
Simon
--
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 v1 0/2] usb: dwc2: gadget: Fixes for LPM

2018-04-21 Thread Simon Shields
Hi Grigor,

On Fri, Apr 20, 2018 at 01:00:16PM +, Grigor Tovmasyan wrote:
> Hi Simon,
> 
> On 4/19/2018 8:31 PM, Simon Shields wrote:
> > Hi all,
> > 
> > On 10/04/2018 10:21 PM, Grigor Tovmasyan wrote:
> >> Here are two little fixes for LPM feature.
> >>
> >> First one is coverity warning fix.
> >>
> >> The Second one was asserted by Stefan Wahren.
> >>
> >> Changes from version 0:
> >>
> >> 1/2:
> >>  - Instead of converting parameter in the CHECK_RANGE macro
> >>to int, changed hird_threshold type from u8 to int.
> >>
> >>
> >> Grigor Tovmasyan (2):
> >> usb: dwc2: gadget: Fix coverity issue
> >> usb: dwc2: gadget: Change LPM default values
> >>
> >>drivers/usb/dwc2/core.h   | 2 +-
> >>drivers/usb/dwc2/params.c | 8 
> >>2 files changed, 5 insertions(+), 5 deletions(-)
> > 
> > The second patch in this series fixes a regression in 4.17-rc1 using dwc2 
> > in gadget
> > mode on Exynos4412, introduced by commit 7455f8b7f0b3 ("usb: dwc2: Enable
> > LPM"). The regression is that using the cdc_acm serial gadget (and
> > presumably other gadgets) serial console output will only sporadically
> > show up on the host (it seems to only show up as input is sent).
> > 
> The second patch is not fix for described by you issue. We will try to 
> reproduce your issue and provide fix. Could you provide some logs or usb 
> traces for issue?

Here's a log[0]. The log is pretty big: I generated it with both regular and 
verbose
debugging enabled for DWC2. However, I suspect the relevant line is
probably:

[   95.222330] dwc2 1248.hsotg: dwc2_hsotg_ep_queue: submit request only in 
active state

Which occurs whenever the controller is in LPM mode. I guess that input
makes it "work" because it reawakens the controller -- but I'm just
spitballing :-). Let me know if you need any more information from my
side.

[0]: https://forkwhiletrue.me/~simon/midas_dwc2_lpm_verbose.log

> 
> > However, I'm unsure if completely disabling LPM is the correct fix, as the 
> > dwc2
> > revision in Exynos4412 (0x4f54281a) should support LPM according to the
> > source
> Yes, we can enable LPM based on hardware configuration.
> 
> > I'm not really sure how to debug this any further (vendor kernel
> > releases contain no mention of LPM in the gadget drivers), so any pointers
> > in that direction would be much appreciated.
> > 
> > Cheers,
> > Simon
> > 
> 

Cheers,
Simon
--
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 v1 0/2] usb: dwc2: gadget: Fixes for LPM

2018-04-19 Thread Simon Shields
Hi all,

On 10/04/2018 10:21 PM, Grigor Tovmasyan wrote:
> Here are two little fixes for LPM feature.
>
> First one is coverity warning fix.
>
> The Second one was asserted by Stefan Wahren.
>
> Changes from version 0:
>
> 1/2:
> - Instead of converting parameter in the CHECK_RANGE macro
>   to int, changed hird_threshold type from u8 to int.
>
>
> Grigor Tovmasyan (2):
>usb: dwc2: gadget: Fix coverity issue
>usb: dwc2: gadget: Change LPM default values
>
>   drivers/usb/dwc2/core.h   | 2 +-
>   drivers/usb/dwc2/params.c | 8 
>   2 files changed, 5 insertions(+), 5 deletions(-)

The second patch in this series fixes a regression in 4.17-rc1 using dwc2 in 
gadget
mode on Exynos4412, introduced by commit 7455f8b7f0b3 ("usb: dwc2: Enable
LPM"). The regression is that using the cdc_acm serial gadget (and
presumably other gadgets) serial console output will only sporadically
show up on the host (it seems to only show up as input is sent).

However, I'm unsure if completely disabling LPM is the correct fix, as the dwc2
revision in Exynos4412 (0x4f54281a) should support LPM according to the
source.

I'm not really sure how to debug this any further (vendor kernel
releases contain no mention of LPM in the gadget drivers), so any pointers
in that direction would be much appreciated.

Cheers,
Simon
--
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/2] usb: gadget: udc: renesas_usb3: add property "renesas,ignore-id"

2018-04-11 Thread Simon Horman
On Tue, Apr 10, 2018 at 09:13:53PM +0900, Yoshihiro Shimoda wrote:
> This patch adds a new property to ignore the ID signal on a board.
> 
> Signed-off-by: Yoshihiro Shimoda 
> ---
>  Documentation/devicetree/bindings/usb/renesas_usb3.txt |  2 ++
>  drivers/usb/gadget/udc/renesas_usb3.c  | 10 ++
>  2 files changed, 12 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/usb/renesas_usb3.txt 
> b/Documentation/devicetree/bindings/usb/renesas_usb3.txt
> index 2c071bb..53949bd 100644
> --- a/Documentation/devicetree/bindings/usb/renesas_usb3.txt
> +++ b/Documentation/devicetree/bindings/usb/renesas_usb3.txt
> @@ -19,6 +19,8 @@ Required properties:
>  Optional properties:
>- phys: phandle + phy specifier pair
>- phy-names: must be "usb"
> +  - renesas,ignore-id: when a board doesn't use ID pin, you can add this
> +property to ignore the ID state.
>  
>  Example of R-Car H3 ES1.x:
>   usb3_peri0: usb@ee02 {
> diff --git a/drivers/usb/gadget/udc/renesas_usb3.c 
> b/drivers/usb/gadget/udc/renesas_usb3.c
> index 409cde4..59e1485 100644
> --- a/drivers/usb/gadget/udc/renesas_usb3.c
> +++ b/drivers/usb/gadget/udc/renesas_usb3.c
> @@ -350,6 +350,7 @@ struct renesas_usb3 {
>   bool extcon_host;   /* check id and set EXTCON_USB_HOST */
>   bool extcon_usb;/* check vbus and set EXTCON_USB */
>   bool forced_b_device;
> + bool ignore_id;
>  };
>  
>  #define gadget_to_renesas_usb3(_gadget)  \
> @@ -645,6 +646,9 @@ static void usb3_check_vbus(struct renesas_usb3 *usb3)
>  
>  static void usb3_set_mode(struct renesas_usb3 *usb3, bool host)
>  {
> + if (usb3->ignore_id && !usb3->forced_b_device)
> + return;
> +
>   if (host)
>   usb3_clear_bit(usb3, DRD_CON_PERI_CON, USB3_DRD_CON);
>   else
> @@ -675,6 +679,9 @@ static void usb3_mode_config(struct renesas_usb3 *usb3, 
> bool host, bool a_dev)
>  
>  static bool usb3_is_a_device(struct renesas_usb3 *usb3)
>  {
> + if (usb3->ignore_id)
> + return false;
> +
>   return !(usb3_read(usb3, USB3_USB_OTG_STA) & USB_OTG_IDMON);
>  }
>  
> @@ -2632,6 +2639,9 @@ static int renesas_usb3_probe(struct platform_device 
> *pdev)
>   if (ret < 0)
>   goto err_add_udc;
>  
> + if (of_property_read_bool(pdev->dev.of_node, "renesas,no-id"))
> + usb3->ignore_id = true;

I wonder if this is better expressed as:

usb3->ignore_id = of_property_read_bool(pdev->dev.of_node,
"renesas,no-id"));

> +
>   ret = device_create_file(&pdev->dev, &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


Re: [PATCH 4/4] usb: gadget: udc: renesas_usb3: should call devm_phy_get() before add udc

2018-04-11 Thread Simon Horman
On Tue, Apr 10, 2018 at 09:44:31AM +, Yoshihiro Shimoda wrote:
> Hi Simon-san,
> 
> > From: Simon Horman, Sent: Tuesday, April 10, 2018 6:34 PM
> > 
> > On Tue, Apr 10, 2018 at 01:28:33AM +, Yoshihiro Shimoda wrote:
> > > Hi Simon-san,
> > >
> > > > From: Simon Horman, Sent: Monday, April 9, 2018 8:58 PM
> > > >
> > > > On Mon, Apr 02, 2018 at 09:21:34PM +0900, Yoshihiro Shimoda wrote:
> > > > > This patch fixes an issue that this driver cannot call phy_init()
> > > > > if a gadget driver is alreadly loaded because usb_add_gadget_udc()
> > > > > might call renesas_usb3_start() via .udc_start.
> > > > >
> > > > > Fixes: 279d4bc64060 ("usb: gadget: udc: renesas_usb3: add support for 
> > > > > generic phy")
> > > > > Cc:  # v4.15+
> > > > > Signed-off-by: Yoshihiro Shimoda 
> > > > > ---
> > > > >  drivers/usb/gadget/udc/renesas_usb3.c | 16 
> > > > >  1 file changed, 8 insertions(+), 8 deletions(-)
> > > >
> > > > Reviewed-by: Simon Horman 
> > > >
> > > >
> > > > Please see some suggestions for follow-up lower-priority patches below.
> > >
> > > Thank you for the review and suggestions!
> > >
> > > > >
> > > > > diff --git a/drivers/usb/gadget/udc/renesas_usb3.c 
> > > > > b/drivers/usb/gadget/udc/renesas_usb3.c
> > > > > index 738b734..671bac3 100644
> > > > > --- a/drivers/usb/gadget/udc/renesas_usb3.c
> > > > > +++ b/drivers/usb/gadget/udc/renesas_usb3.c
> > > > > @@ -2632,6 +2632,14 @@ static int renesas_usb3_probe(struct 
> > > > > platform_device *pdev)
> > > > >   if (ret < 0)
> > > > >   goto err_alloc_prd;
> > > > >
> > > > > + /*
> > > > > +  * This is an optional. So, if this driver cannot get a phy,
> > > > > +  * this driver will not handle a phy anymore.
> > > > > +  */
> > > >
> > > > nit: s/an optional/optional/
> > >
> > > Oops. I will fix and submit v2 patches.
> > >
> > > > > + usb3->phy = devm_phy_get(&pdev->dev, "usb");
> > > > > + if (IS_ERR(usb3->phy))
> > > > > + usb3->phy = NULL;
> > > >
> > > > I think this will unintentionally ignore errors other than the
> > > > non-existence of the device, f.e. a memory allocation failure
> > > > in devm_phy_get().
> > > >
> > > > So perhaps something like this, as per phy_optional_get(), would be 
> > > > better?
> > > >
> > > > usb3->phy = devm_phy_get(&pdev->dev, "usb");
> > > > if (IS_ERR(usb3->phy) && (PTR_ERR(usb3->phy) == -ENODEV))
> > > > usb3->phy = NULL;
> > >
> > > Thank you for the suggestion. I agree with you.
> > > I think I should use devm_phy_optional_get() instead of dev_phy_get(), as 
> > > you mentioned :)
> > > So, I will fix the code by using devm_phy_optional_get() first, and then 
> > > fix this.
> > 
> > Thanks, I agree that would be a good fix.
> > 
> > But perhaps it is better as a follow-up?
> 
> Oops. Yes, I changed my mind after prepared the patch v2 and submitted v2.
> I should have sent an email about this to you...
> Anyway, thank you very much for reviewing the v2 patches!

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


Re: [PATCH v2 5/6] usb: gadget: udc: renesas_usb3: should fail if devm_phy_get() returns error

2018-04-10 Thread Simon Horman
On Tue, Apr 10, 2018 at 02:38:53PM +0900, Yoshihiro Shimoda wrote:
> This patch fixes an issue that this driver ignores errors other than
> the non-existence of the device, f.e. a memory allocation failure
> in devm_phy_get(). So, this patch replaces devm_phy_get() with
> devm_phy_optional_get().
> 
> Reported-by: Simon Horman 
> Fixes: 279d4bc64060 ("usb: gadget: udc: renesas_usb3: add support for generic 
> phy")
> Cc:  # v4.15+
> Signed-off-by: Yoshihiro Shimoda 

Reviewed-by: Simon Horman 

> ---
> Remarks:
>  - A new file in v2
> 
>  drivers/usb/gadget/udc/renesas_usb3.c | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/usb/gadget/udc/renesas_usb3.c 
> b/drivers/usb/gadget/udc/renesas_usb3.c
> index 233bc04..0e70163 100644
> --- a/drivers/usb/gadget/udc/renesas_usb3.c
> +++ b/drivers/usb/gadget/udc/renesas_usb3.c
> @@ -2636,9 +2636,11 @@ static int renesas_usb3_probe(struct platform_device 
> *pdev)
>* This is optional. So, if this driver cannot get a phy,
>* this driver will not handle a phy anymore.
>*/
> - usb3->phy = devm_phy_get(&pdev->dev, "usb");
> - if (IS_ERR(usb3->phy))
> - usb3->phy = NULL;
> + usb3->phy = devm_phy_optional_get(&pdev->dev, "usb");
> + if (IS_ERR(usb3->phy)) {
> + ret = PTR_ERR(usb3->phy);
> + goto err_add_udc;
> + }
>  
>   pm_runtime_enable(&pdev->dev);
>   ret = usb_add_gadget_udc(&pdev->dev, &usb3->gadget);
> -- 
> 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 v2 6/6] usb: gadget: udc: renesas_usb3: disable the controller's irqs for reconnecting

2018-04-10 Thread Simon Horman
On Tue, Apr 10, 2018 at 02:38:54PM +0900, Yoshihiro Shimoda wrote:
> This patch fixes an issue that reconnection is possible to fail
> because unexpected state handling happens by the irqs. To fix the issue,
> the driver disables the controller's irqs when disconnected.
> 
> Fixes: 746bfe63bba3 ("usb: gadget: renesas_usb3: add support for Renesas 
> USB3.0 peripheral controller")
> Cc:  # v4.5+
> Signed-off-by: Yoshihiro Shimoda 

Reviewed-by: Simon Horman 

> ---
> 
> Remarks:
>  - A new file in v2
> 
>  drivers/usb/gadget/udc/renesas_usb3.c | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/drivers/usb/gadget/udc/renesas_usb3.c 
> b/drivers/usb/gadget/udc/renesas_usb3.c
> index 0e70163..5caf78b 100644
> --- a/drivers/usb/gadget/udc/renesas_usb3.c
> +++ b/drivers/usb/gadget/udc/renesas_usb3.c
> @@ -623,6 +623,13 @@ static void usb3_disconnect(struct renesas_usb3 *usb3)
>   usb3_usb2_pullup(usb3, 0);
>   usb3_clear_bit(usb3, USB30_CON_B3_CONNECT, USB3_USB30_CON);
>   usb3_reset_epc(usb3);
> + usb3_disable_irq_1(usb3, USB_INT_1_B2_RSUM | USB_INT_1_B3_PLLWKUP |
> +USB_INT_1_B3_LUPSUCS | USB_INT_1_B3_DISABLE |
> +USB_INT_1_SPEED | USB_INT_1_B3_WRMRST |
> +USB_INT_1_B3_HOTRST | USB_INT_1_B2_SPND |
> +USB_INT_1_B2_L1SPND | USB_INT_1_B2_USBRST);
> + usb3_clear_bit(usb3, USB_COM_CON_SPD_MODE, USB3_USB_COM_CON);
> + usb3_init_epc_registers(usb3);
>  
>   if (usb3->driver)
>   usb3->driver->disconnect(&usb3->gadget);
> -- 
> 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 4/4] usb: gadget: udc: renesas_usb3: should call devm_phy_get() before add udc

2018-04-10 Thread Simon Horman
On Tue, Apr 10, 2018 at 01:28:33AM +, Yoshihiro Shimoda wrote:
> Hi Simon-san,
> 
> > From: Simon Horman, Sent: Monday, April 9, 2018 8:58 PM
> > 
> > On Mon, Apr 02, 2018 at 09:21:34PM +0900, Yoshihiro Shimoda wrote:
> > > This patch fixes an issue that this driver cannot call phy_init()
> > > if a gadget driver is alreadly loaded because usb_add_gadget_udc()
> > > might call renesas_usb3_start() via .udc_start.
> > >
> > > Fixes: 279d4bc64060 ("usb: gadget: udc: renesas_usb3: add support for 
> > > generic phy")
> > > Cc:  # v4.15+
> > > Signed-off-by: Yoshihiro Shimoda 
> > > ---
> > >  drivers/usb/gadget/udc/renesas_usb3.c | 16 
> > >  1 file changed, 8 insertions(+), 8 deletions(-)
> > 
> > Reviewed-by: Simon Horman 
> > 
> > 
> > Please see some suggestions for follow-up lower-priority patches below.
> 
> Thank you for the review and suggestions!
> 
> > >
> > > diff --git a/drivers/usb/gadget/udc/renesas_usb3.c 
> > > b/drivers/usb/gadget/udc/renesas_usb3.c
> > > index 738b734..671bac3 100644
> > > --- a/drivers/usb/gadget/udc/renesas_usb3.c
> > > +++ b/drivers/usb/gadget/udc/renesas_usb3.c
> > > @@ -2632,6 +2632,14 @@ static int renesas_usb3_probe(struct 
> > > platform_device *pdev)
> > >   if (ret < 0)
> > >   goto err_alloc_prd;
> > >
> > > + /*
> > > +  * This is an optional. So, if this driver cannot get a phy,
> > > +  * this driver will not handle a phy anymore.
> > > +  */
> > 
> > nit: s/an optional/optional/
> 
> Oops. I will fix and submit v2 patches.
> 
> > > + usb3->phy = devm_phy_get(&pdev->dev, "usb");
> > > + if (IS_ERR(usb3->phy))
> > > + usb3->phy = NULL;
> > 
> > I think this will unintentionally ignore errors other than the
> > non-existence of the device, f.e. a memory allocation failure
> > in devm_phy_get().
> > 
> > So perhaps something like this, as per phy_optional_get(), would be better?
> > 
> > usb3->phy = devm_phy_get(&pdev->dev, "usb");
> > if (IS_ERR(usb3->phy) && (PTR_ERR(usb3->phy) == -ENODEV))
> > usb3->phy = NULL;
> 
> Thank you for the suggestion. I agree with you.
> I think I should use devm_phy_optional_get() instead of dev_phy_get(), as you 
> mentioned :)
> So, I will fix the code by using devm_phy_optional_get() first, and then fix 
> this.

Thanks, I agree that would be a good fix.

But perhaps it is better as a follow-up?
--
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 4/4] usb: gadget: udc: renesas_usb3: should call devm_phy_get() before add udc

2018-04-09 Thread Simon Horman
On Mon, Apr 02, 2018 at 09:21:34PM +0900, Yoshihiro Shimoda wrote:
> This patch fixes an issue that this driver cannot call phy_init()
> if a gadget driver is alreadly loaded because usb_add_gadget_udc()
> might call renesas_usb3_start() via .udc_start.
> 
> Fixes: 279d4bc64060 ("usb: gadget: udc: renesas_usb3: add support for generic 
> phy")
> Cc:  # v4.15+
> Signed-off-by: Yoshihiro Shimoda 
> ---
>  drivers/usb/gadget/udc/renesas_usb3.c | 16 
>  1 file changed, 8 insertions(+), 8 deletions(-)

Reviewed-by: Simon Horman 


Please see some suggestions for follow-up lower-priority patches below.

> 
> diff --git a/drivers/usb/gadget/udc/renesas_usb3.c 
> b/drivers/usb/gadget/udc/renesas_usb3.c
> index 738b734..671bac3 100644
> --- a/drivers/usb/gadget/udc/renesas_usb3.c
> +++ b/drivers/usb/gadget/udc/renesas_usb3.c
> @@ -2632,6 +2632,14 @@ static int renesas_usb3_probe(struct platform_device 
> *pdev)
>   if (ret < 0)
>   goto err_alloc_prd;
>  
> + /*
> +  * This is an optional. So, if this driver cannot get a phy,
> +  * this driver will not handle a phy anymore.
> +  */

nit: s/an optional/optional/

> + usb3->phy = devm_phy_get(&pdev->dev, "usb");
> + if (IS_ERR(usb3->phy))
> + usb3->phy = NULL;

I think this will unintentionally ignore errors other than the
non-existence of the device, f.e. a memory allocation failure
in devm_phy_get().

So perhaps something like this, as per phy_optional_get(), would be better?

usb3->phy = devm_phy_get(&pdev->dev, "usb");
if (IS_ERR(usb3->phy) && (PTR_ERR(usb3->phy) == -ENODEV))
usb3->phy = NULL;

> +
>   pm_runtime_enable(&pdev->dev);
>   ret = usb_add_gadget_udc(&pdev->dev, &usb3->gadget);
>   if (ret < 0)
> @@ -2641,14 +2649,6 @@ static int renesas_usb3_probe(struct platform_device 
> *pdev)
>   if (ret < 0)
>   goto err_dev_create;
>  
> - /*
> -  * This is an optional. So, if this driver cannot get a phy,
> -  * this driver will not handle a phy anymore.
> -  */
> - usb3->phy = devm_phy_get(&pdev->dev, "usb");
> - if (IS_ERR(usb3->phy))
> - usb3->phy = NULL;
> -
>   usb3->workaround_for_vbus = priv->workaround_for_vbus;
>  
>   renesas_usb3_debugfs_init(usb3, &pdev->dev);
> -- 
> 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 3/4] usb: gadget: udc: renesas_usb3: should call pm_runtime_enable() before add udc

2018-04-09 Thread Simon Horman
On Mon, Apr 02, 2018 at 09:21:33PM +0900, Yoshihiro Shimoda wrote:
> This patch fixes an issue that this driver causes panic if a gadget
> driver is already loaded because usb_add_gadget_udc() might call
> renesas_usb3_start() via .udc_start, and then pm_runtime_get_sync()
> in renesas_usb3_start() doesn't work correctly.
> Note that the usb3_to_dev() macro should not be called at this timing
> because the macro uses the gadget structure.
> 
> Fixes: cf06df3fae28 ("usb: gadget: udc: renesas_usb3: move 
> pm_runtime_{en,dis}able()")
> Cc:  # v4.15+
> Signed-off-by: Yoshihiro Shimoda 

Reviewed-by: Simon Horman 

--
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 2/4] usb: gadget: udc: renesas_usb3: should remove debugfs

2018-04-09 Thread Simon Horman
On Mon, Apr 02, 2018 at 09:21:32PM +0900, Yoshihiro Shimoda wrote:
> This patch fixes an issue that this driver doesn't remove its debugfs.
> 
> Fixes: 43ba968b00ea ("usb: gadget: udc: renesas_usb3: add debugfs to set the 
> b-device mode")
> Cc:  # v4.14+
> Signed-off-by: Yoshihiro Shimoda 

Reviewed-by: Simon Horman 

--
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/4] usb: gadget: udc: renesas_usb3: fix double phy_put()

2018-04-09 Thread Simon Horman
On Mon, Apr 02, 2018 at 09:21:31PM +0900, Yoshihiro Shimoda wrote:
> This patch fixes an issue that this driver cause double phy_put()
> calling. This driver must not call phy_put() in the remove because
> the driver calls devm_phy_get() in the probe.
> 
> Fixes: 279d4bc64060 ("usb: gadget: udc: renesas_usb3: add support for generic 
> phy")
> Cc:  # v4.15+
> Signed-off-by: Yoshihiro Shimoda 

Reviewed-by: Simon Horman 

--
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 2/2] usb: gadget: udc: renesas_usb3: add binging for r8a77965

2018-03-06 Thread Simon Horman
On Tue, Feb 27, 2018 at 05:16:03PM +0900, Yoshihiro Shimoda wrote:
> This patch adds binding for r8a77965 (R-Car M3-N).
> 
> Signed-off-by: Yoshihiro Shimoda 

Reviewed-by: Simon Horman 
--
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/2] usb: renesas_usbhs: add binding for r8a77965

2018-03-06 Thread Simon Horman
On Tue, Feb 27, 2018 at 05:16:02PM +0900, Yoshihiro Shimoda wrote:
> This patch adds binding for r8a77965 (R-Car M3-N).
> 
> Signed-off-by: Yoshihiro Shimoda 

Reviewed-by: Simon Horman 

--
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: host: xhci-rcar: add support for r8a77965

2018-03-06 Thread Simon Horman
On Tue, Feb 27, 2018 at 05:15:20PM +0900, Yoshihiro Shimoda wrote:
> This patch adds support for r8a77965 (R-Car M3-N).
> 
> Signed-off-by: Yoshihiro Shimoda 

Reviewed-by: Simon Horman 
--
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 v3 0/3] usb: renesas_usbhs: Add RZ/A1 support

2018-01-09 Thread Simon Horman
On Mon, Jan 08, 2018 at 01:15:08PM +0100, Geert Uytterhoeven wrote:
> Hi Chris,
> 
> On Mon, Jan 8, 2018 at 12:59 PM, Chris Brandt  
> wrote:
> > On Monday, January 08, 2018, Geert Uytterhoeven wrote:
> >> Thanks for the update, but I think there has been a misunderstanding.
> >> I didn't mean to drop "renesas,usbhs-r7s72100" everywhere, only from
> >> the matching in the driver.
> >
> > Opps, I was all kinds of confused then.
> >
> > So, before I submit a V4, here is my understanding:
> >
> > drivers/.../common.c
> >  * contains -only-  '.compatible = "renesas,rza1-usbhs"'
> 
> OK.
> 
> > Documentation/.../renesas_usbhs.txt
> >  * contains both "renesas,usbhs-r7s72100" and "renesas,rza1-usbhs"
> 
> OK.
> 
> > r7s72100.dtsi
> > * usbhs0: usb@e801 {
> > compatible = "renesas,usbhs-r7s72100", "renesas,rza1-usbhs";
> 
> OK.
> 
> > Is this correct?
> 
> Yes.

Ack.
--
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 v4 2/3] dt-bindings: usb: renesas_usbhs: Add support for RZ/A1

2018-01-09 Thread Simon Horman
On Mon, Jan 08, 2018 at 07:30:54AM -0500, Chris Brandt wrote:
> Document support for RZ/A1 SoCs
> 
> Signed-off-by: Chris Brandt 
> Reviewed-by: Geert Uytterhoeven 

Reviewed-by: Simon Horman 

> ---
> v4:
>  * Re-added "renesas,usbhs-r7s72100"
> v3:
>  * Removed "renesas,usbhs-r7s72100"
> v2:
>  * Added Reviewed-by
> ---
>  Documentation/devicetree/bindings/usb/renesas_usbhs.txt | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/usb/renesas_usbhs.txt 
> b/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
> index 47394ab788e3..d060172f1529 100644
> --- a/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
> +++ b/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
> @@ -13,8 +13,10 @@ Required properties:
>   - "renesas,usbhs-r8a7795" for r8a7795 (R-Car H3) compatible device
>   - "renesas,usbhs-r8a7796" for r8a7796 (R-Car M3-W) compatible device
>   - "renesas,usbhs-r8a77995" for r8a77995 (R-Car D3) compatible device
> + - "renesas,usbhs-r7s72100" for r7s72100 (RZ/A1) compatible device
>   - "renesas,rcar-gen2-usbhs" for R-Car Gen2 or RZ/G1 compatible devices
>   - "renesas,rcar-gen3-usbhs" for R-Car Gen3 compatible device
> + - "renesas,rza1-usbhs" for RZ/A1 compatible device
>  
>   When compatible with the generic version, nodes must list the
>   SoC-specific version corresponding to the platform first followed
> -- 
> 2.15.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 v3 2/3] dt-bindings: usb: renesas_usbhs: Add support for RZ/A1

2018-01-07 Thread Simon Horman
On Fri, Jan 05, 2018 at 05:46:46PM -0500, Chris Brandt wrote:
> Document support for RZ/A1 SoCs
> 
> Signed-off-by: Chris Brandt 
> Reviewed-by: Geert Uytterhoeven 
> ---
> v3:
>  * Removed "renesas,usbhs-r7s72100"

Unless I am mistaken you want both renesas,usbhs-r7s72100, for the SoC
and renesas,rza1-usbhs for the family[*] of SoCs (which currently only has one
member upstream).

Similar to the way there are per-SoC compat strings for R-Car Gen2 and Gen3
SoCs, and per-SoC family fallback compat strings to Gen2 and Gen3.

The motivation for this that empirically SoC families seem to be able to
share the implementation on the driver-side, so only the fallback compat
strings need to be implemented in the driver by defining per-SoC compat
strings we have the flexibility to implement them if differences emerge
between SoCs in the same family.

[*] I used the term family here to group SoCs together. I acknowledge that
Renesas may not refer to them in this way.



> v2:
>  * Added Reviewed-by
> ---
>  Documentation/devicetree/bindings/usb/renesas_usbhs.txt | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/Documentation/devicetree/bindings/usb/renesas_usbhs.txt 
> b/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
> index 47394ab788e3..fa16d8d33815 100644
> --- a/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
> +++ b/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
> @@ -15,6 +15,7 @@ Required properties:
>   - "renesas,usbhs-r8a77995" for r8a77995 (R-Car D3) compatible device
>   - "renesas,rcar-gen2-usbhs" for R-Car Gen2 or RZ/G1 compatible devices
>   - "renesas,rcar-gen3-usbhs" for R-Car Gen3 compatible device
> + - "renesas,rza1-usbhs" for RZ/A1 compatible device
>  
>   When compatible with the generic version, nodes must list the
>   SoC-specific version corresponding to the platform first followed
> -- 
> 2.15.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 v3 3/3] ARM: dts: r7s72100: add USB device to device tree

2018-01-07 Thread Simon Horman
On Fri, Jan 05, 2018 at 05:46:47PM -0500, Chris Brandt wrote:
> Add USB device support.
> 
> Signed-off-by: Chris Brandt 
> Reviewed-by: Geert Uytterhoeven 
> ---
> v3:
>  * Changed from "renesas,usbhs-r7s72100" to "renesas,rza1-usbhs"

I think you want both. The SoC-specific compat string followed by a fallback
compat string for something broader:

Like this:

compatible = "renesas,usbhs-r7s72100", "renesas,rza1-usbhs";

> v2:
>  * Node name is now generic 'usb@'
>  * GIC_SPI (73-32) is now just GIC_SPI 41
>  * All hex number are lower case
>  * Added Reviewed-by
> ---
>  arch/arm/boot/dts/r7s72100.dtsi | 20 
>  1 file changed, 20 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/r7s72100.dtsi b/arch/arm/boot/dts/r7s72100.dtsi
> index ab9645a42eca..d94431767913 100644
> --- a/arch/arm/boot/dts/r7s72100.dtsi
> +++ b/arch/arm/boot/dts/r7s72100.dtsi
> @@ -667,4 +667,24 @@
>   power-domains = <&cpg_clocks>;
>   status = "disabled";
>   };
> +
> + usbhs0: usb@e801 {
> + compatible = "renesas,rza1-usbhs";
> + reg = <0xe801 0x1a0>;
> + interrupts = ;
> + clocks = <&mstp7_clks R7S72100_CLK_USB0>;
> + renesas,buswait = <4>;
> + power-domains = <&cpg_clocks>;
> + status = "disabled";
> + };
> +
> + usbhs1: usb@e8207000 {
> + compatible = "renesas,rza1-usbhs";
> + reg = <0xe8207000 0x1a0>;
> + interrupts = ;
> + clocks = <&mstp7_clks R7S72100_CLK_USB1>;
> + renesas,buswait = <4>;
> + power-domains = <&cpg_clocks>;
> + status = "disabled";
> + };
>  };
> -- 
> 2.15.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 3/3] ARM: dts: r7s72100: add USB device to device tree

2018-01-05 Thread Simon Horman
On Thu, Jan 04, 2018 at 03:01:50PM -0500, Chris Brandt wrote:
> Add USB device support.
> 
> Signed-off-by: Chris Brandt 

Hi Chris,

it looks like there have been some requests for (minor) changes to this
patch. Please consider addressing those and reposting.
--
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 2/2] ARM: dts: r8a7743: Add xhci support to SoC dtsi

2017-10-17 Thread Simon Horman
On Tue, Oct 17, 2017 at 01:39:33AM +, Yoshihiro Shimoda wrote:
> Hi Biju-san,
> 
> IIUC, when we submitted a patch for dts[i] file,
> we don't need to submit such a patch to usb maintainers.
> 
> > From: Biju Das, Sent: Monday, October 16, 2017 7:13 PM
> > 
> > From: Fabrizio Castro 
> > 
> > Add node for xhci. Boards DT files will enable it if needed.
> > 
> > Signed-off-by: Fabrizio Castro 
> > ---
> >  arch/arm/boot/dts/r8a7743.dtsi | 20 
> >  1 file changed, 20 insertions(+)
> > 
> > diff --git a/arch/arm/boot/dts/r8a7743.dtsi b/arch/arm/boot/dts/r8a7743.dtsi
> > index 699c040..386bf07 100644
> > --- a/arch/arm/boot/dts/r8a7743.dtsi
> > +++ b/arch/arm/boot/dts/r8a7743.dtsi
> > @@ -931,6 +931,26 @@
> > status = "disabled";
> > };
> > 
> > +   /*
> > +* pci1 and xhci share the same phy, therefore only one of them
> > +* can be active at any one time. If both of them are enabled,
> > +* a race condition will determine who'll control the phy.
> > +* A firmware file is needed by the xhci driver in order for
> > +* USB 3.0 to work properly.
> > +*/
> > +   xhci: usb@ee00 {
> > +   compatible = "renesas,xhci-r8a7743",
> > +"renesas,rcar-gen2-xhci";
> > +   reg = <0 0xee00 0 0xc00>;
> > +   interrupts = ;
> > +   clocks = <&cpg CPG_MOD 328>;
> > +   power-domains = <&sysc R8A7743_PD_ALWAYS_ON>;
> > +   resets = <&cpg 328>;
> > +   phys = <&usb2 1>;
> > +   phy-names = "usb";
> > +   status = "disabled";
> > +   };
> > +
> > sdhi0: sd@ee10 {
> > compatible = "renesas,sdhi-r8a7743";
> > reg = <0 0xee10 0 0x328>;
> 
> It seems good to me. So,
> 
> Reviewed-by: Yoshihiro Shimoda 

Thanks, applied.
--
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/2] dt-bindings: usb-xhci: Document r8a7743 support

2017-10-17 Thread Simon Horman
On Mon, Oct 16, 2017 at 11:12:48AM +0100, Biju Das wrote:
> From: Fabrizio Castro 
> 
> Document r8a7743 xhci support. The driver will use the fallback
> compatible string "renesas,rcar-gen2-xhci", therefore no driver
> change is needed.
> 
> Signed-off-by: Fabrizio Castro 

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


Re: [PATCH v2] usb: renesas_usbhs: Add compatible string for r8a7743/5

2017-10-08 Thread Simon Horman
On Fri, Oct 06, 2017 at 05:49:34PM +0100, Biju Das wrote:
> This patch adds support for r8a7743/5 SoCs. The Renesas RZ/G1[ME]
> (R8A7743/5) usbhs is identical to the R-Car Gen2 family.
> 
> No driver change is needed due to the fallback compatible value
> "renesas,rcar-gen2-usbhs".
> Adding the SoC-specific compatible values here has two purposes:
>   1. Document which SoCs have this hardware module,
>   2. Allow checkpatch to validate compatible values.

3. Allow the driver to support SoC specific implementations in future
   as necessary.

Acked-by: Simon Horman 

> Signed-off-by: Biju Das 
> Signed-off-by: Chris Paterson 
> Reviewed-by: Yoshihiro Shimoda 
> Reviewed-by: Geert Uytterhoeven 
> ---
> v1-->v2
>* Modified the patch description
>* Rebased on the below R-Car D3 patch
>  https://patchwork.kernel.org/patch/9982267/
> 
> This patch is tested against Linux next tag next-20170929 +
>   https://patchwork.kernel.org/patch/9982267/
> 
>  Documentation/devicetree/bindings/usb/renesas_usbhs.txt | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/usb/renesas_usbhs.txt 
> b/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
> index e79f6e4..47394ab 100644
> --- a/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
> +++ b/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
> @@ -3,6 +3,8 @@ Renesas Electronics USBHS driver
>  Required properties:
>- compatible: Must contain one or more of the following:
>  
> + - "renesas,usbhs-r8a7743" for r8a7743 (RZ/G1M) compatible device
> + - "renesas,usbhs-r8a7745" for r8a7745 (RZ/G1E) compatible device
>   - "renesas,usbhs-r8a7790" for r8a7790 (R-Car H2) compatible device
>   - "renesas,usbhs-r8a7791" for r8a7791 (R-Car M2-W) compatible device
>   - "renesas,usbhs-r8a7792" for r8a7792 (R-Car V2H) compatible device
> @@ -11,7 +13,7 @@ Required properties:
>   - "renesas,usbhs-r8a7795" for r8a7795 (R-Car H3) compatible device
>   - "renesas,usbhs-r8a7796" for r8a7796 (R-Car M3-W) compatible device
>   - "renesas,usbhs-r8a77995" for r8a77995 (R-Car D3) compatible device
> - - "renesas,rcar-gen2-usbhs" for R-Car Gen2 compatible device
> + - "renesas,rcar-gen2-usbhs" for R-Car Gen2 or RZ/G1 compatible devices
>   - "renesas,rcar-gen3-usbhs" for R-Car Gen3 compatible device
>  
>   When compatible with the generic version, nodes must list the
> -- 
> 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: host: xhci-plat: Use of_device_get_match_data() helper

2017-10-06 Thread Simon Horman
On Thu, Oct 05, 2017 at 01:12:01PM +0300, Mathias Nyman wrote:
> On 05.10.2017 12:19, Simon Horman wrote:
> >On Wed, Oct 04, 2017 at 02:25:03PM +0200, Geert Uytterhoeven wrote:
> >>Use the of_device_get_match_data() helper instead of open coding.
> >>
> >>Signed-off-by: Geert Uytterhoeven 
> >
> >Reviewed-by: Simon Horman 
> >
> >
> 
> Thanks, I already applied and sent forward before this new reviewed-by tag

Thanks, sorry for not noticing that.
--
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: renesas_usbhs: Use of_device_get_match_data() helper

2017-10-05 Thread Simon Horman
On Wed, Oct 04, 2017 at 02:26:48PM +0200, Geert Uytterhoeven wrote:
> Use the of_device_get_match_data() helper instead of open coding.
> 
> Signed-off-by: Geert Uytterhoeven 

Reviewed-by: Simon Horman 

--
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: host: xhci-plat: Use of_device_get_match_data() helper

2017-10-05 Thread Simon Horman
On Wed, Oct 04, 2017 at 02:25:03PM +0200, Geert Uytterhoeven wrote:
> Use the of_device_get_match_data() helper instead of open coding.
> 
> Signed-off-by: Geert Uytterhoeven 

Reviewed-by: Simon Horman 


--
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: gadget: udc: renesas_usb3: Use of_device_get_match_data() helper

2017-10-05 Thread Simon Horman
On Wed, Oct 04, 2017 at 02:23:31PM +0200, Geert Uytterhoeven wrote:
> Use the of_device_get_match_data() helper instead of open coding,
> postponing the matching until when it's really needed.
> Note that the renesas_usb3 driver is used with DT only, so there's
> always a valid match.
> 
> Signed-off-by: Geert Uytterhoeven 

Reviewed-by: Simon Horman 

--
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: Flood of hub_ext_port_status failed (err = -71) messages

2016-11-22 Thread Simon Arlott
On 22/11/16 08:37, Mathias Nyman wrote:
> On 21.11.2016 23:52, Simon Arlott wrote:
>> 2016-06-17T09:56:09.219+01:00  kernel: xhci_hcd :00:14.0: URB 
>> transfer length is wrong, xHC issue? req. len = 4, act. len = 4294967292
> 
> Your broken hardware triggered another interesting issue.
> The len value 4294967292 looks like a u32 wrapped around.
> 
> What kernelversion was this?

These versions:

  4 Linux version 4.2.0-34-generic (buildd@lgw01-54) (gcc version 5.2.1 
20151010 (Ubuntu 5.2.1-22ubuntu2) ) #39-Ubuntu SMP Thu Mar 10 22:13:01 UTC 2016 
(Ubuntu 4.2.0-34.39-generic 4.2.8-ckt4)
  1 xhci_hcd :00:14.0: URB transfer length is wrong, xHC issue? req. 
len = 0, act. len = 4294967288

  1 Linux version 4.2.0-35-generic (buildd@lgw01-43) (gcc version 5.2.1 
20151010 (Ubuntu 5.2.1-22ubuntu2) ) #40-Ubuntu SMP Tue Mar 15 22:15:45 UTC 2016 
(Ubuntu 4.2.0-35.40-generic 4.2.8-ckt5)
 11 xhci_hcd :00:14.0: URB transfer length is wrong, xHC issue? req. 
len = 0, act. len = 4294967288

  1 Linux version 4.4.0-22-generic (buildd@lgw01-41) (gcc version 5.3.1 
20160413 (Ubuntu 5.3.1-14ubuntu2) ) #40-Ubuntu SMP Thu May 12 22:03:46 UTC 2016 
(Ubuntu 4.4.0-22.40-generic 4.4.8)
  1 xhci_hcd :00:14.0: URB transfer length is wrong, xHC issue? req. 
len = 0, act. len = 4294967288
 82 xhci_hcd :00:14.0: URB transfer length is wrong, xHC issue? req. 
len = 4, act. len = 4294967292
  2 xhci_hcd :00:14.0: URB transfer length is wrong, xHC issue? req. 
len = 0, act. len = 4294967288

  1 Linux version 4.4.0-24-generic (buildd@lgw01-12) (gcc version 5.3.1 
20160413 (Ubuntu 5.3.1-14ubuntu2.1) ) #43-Ubuntu SMP Wed Jun 8 19:27:37 UTC 
2016 (Ubuntu 4.4.0-24.43-generic 4.4.10)
 134694 xhci_hcd :00:14.0: URB transfer length is wrong, xHC issue? req. 
len = 4, act. len = 4294967292

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


Flood of hub_ext_port_status failed (err = -71) messages

2016-11-21 Thread Simon Arlott
ion 
Star
2016-06-17T09:56:13.471+01:00  kernel: hid-generic 0003:0835:8502.000E: 
hiddev0,hidraw3: USB HID v1.11 Device [Action Star USB HID] on 
usb-:00:14.0-13.5.1/input0

-- 
Simon Arlott
--
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: Tascam US-122L - Corrupt USB descriptor

2016-04-14 Thread Simon Wood
On Thu, April 14, 2016 1:35 am, Clemens Ladisch wrote:
> Simon Wood wrote:
>
>> The card shows up under '/proc/asound/cards', but only as Midi.
>>
>
> Apparently, there is no PCM device. This driver creates a special
> hardware-dependent device which is intended to be used with the Jack driver
> "usb_stream".
>
>
> It might be possible to use the ALSA "usb_stream" plugin:
> <http://www.alsa-project.org/main/index.php/Matrix:Module-usb-us122l>

I have this '.asoundrc' file (made before previous postings), but that
does not seem to make a usable card.

I'm expecting that a PCM device should /just/ appear under 'aplay -l', but
that is not happening. Perhaps there is a step I am missing, or I am just
confused about what qualifies a 'working' US-122L.

Do I need to be using a specific version of (userland) Alsa?

It would be nice to get a 'nod' from a person who has the US-122L workin
on their system. But I do appreciate Clemens' help and guidance,
Simon.

--
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: Tascam US-122L - Corrupt USB descriptor

2016-04-13 Thread Simon Wood
On Wed, April 13, 2016 3:01 am, Clemens Ladisch wrote:
> Simon Wood wrote:
>
>> I have been struggling for the past few days to get a Tascam US-122L
>> (USB
>> sound-card/midi interface) working, despite reading numerous forum
>> postings I have only been able to get the midi portion working.
>
> Does it show up with "aplay -l"?

The card shows up under '/proc/asound/cards', but only as Midi. See
attached for full listing.


>> I note that the USB descriptor seems to be corrupt. It declares 2
>> interfaces, but then describes 3 separate with the same interface number
>>  for the last 2.
>
> The descriptors describe two alternate settings for the same interface.
> This is a feature, which is required for audio devices.
>
>
>> iManufacturer   1 (error)<-- Here be 
>> Errors! iProduct
>> 2 (error)
>> iSerial 3 (error)
>
> It's possible that lsusb does not have the permissions needed to send
> the messages to ask for the strings.  Try running it as root.

Was running as root (on Xubuntu, 2 different machines, different installs).

I note that sometimes this is OK, ie when I do '# echo 0 >
/sys/bus/usb/devices/1-2/bConfigurationValue', but then I have no
interfaces at all (no midi, no listing).

Can anyone confirm they have a US-122L working on a new kernel. Is the USB
descriptor the same as what I'm seeing, perhaps hardware changed at some
point.
Cheers,
Simon# cat /proc/asound/cards  > aplay_l.txt
 0 [Audigy2]: Audigy2 - SB Audigy 2 ZS [SB0350]
  SB Audigy 2 ZS [SB0350] (rev.4, serial:0x20021102) at 
0xccc0, irq 27
 1 [US122L ]: USB US-122L - TASCAM US-122L
  TASCAM US-122L (644:800e if 0 at 001/005)

# aplaymidi -l >> aplay_l.txt
 PortClient name  Port name
 14:0Midi Through Midi Through Port-0
 16:0SB Audigy 2 ZS [SB0350]  Audigy MPU-401 (UART)
 16:32   SB Audigy 2 ZS [SB0350]  Audigy MPU-401 #2
 17:0Emu10k1 WaveTableEmu10k1 Port 0
 17:1Emu10k1 WaveTableEmu10k1 Port 1
 17:2Emu10k1 WaveTableEmu10k1 Port 2
 17:3Emu10k1 WaveTableEmu10k1 Port 3
 20:0TASCAM US-122L   TASCAM US-122L MIDI 1

# aplay -l >> aplay_l.txt
 List of PLAYBACK Hardware Devices 
card 0: Audigy2 [SB Audigy 2 ZS [SB0350]], device 0: emu10k1 [ADC 
Capture/Standard PCM Playback]
  Subdevices: 32/32
  Subdevice #0: subdevice #0
  Subdevice #1: subdevice #1
  Subdevice #2: subdevice #2
  Subdevice #3: subdevice #3
  Subdevice #4: subdevice #4
  Subdevice #5: subdevice #5
  Subdevice #6: subdevice #6
  Subdevice #7: subdevice #7
  Subdevice #8: subdevice #8
  Subdevice #9: subdevice #9
  Subdevice #10: subdevice #10
  Subdevice #11: subdevice #11
  Subdevice #12: subdevice #12
  Subdevice #13: subdevice #13
  Subdevice #14: subdevice #14
  Subdevice #15: subdevice #15
  Subdevice #16: subdevice #16
  Subdevice #17: subdevice #17
  Subdevice #18: subdevice #18
  Subdevice #19: subdevice #19
  Subdevice #20: subdevice #20
  Subdevice #21: subdevice #21
  Subdevice #22: subdevice #22
  Subdevice #23: subdevice #23
  Subdevice #24: subdevice #24
  Subdevice #25: subdevice #25
  Subdevice #26: subdevice #26
  Subdevice #27: subdevice #27
  Subdevice #28: subdevice #28
  Subdevice #29: subdevice #29
  Subdevice #30: subdevice #30
  Subdevice #31: subdevice #31
card 0: Audigy2 [SB Audigy 2 ZS [SB0350]], device 2: emu10k1 efx [Multichannel 
Capture/PT Playback]
  Subdevices: 8/8
  Subdevice #0: subdevice #0
  Subdevice #1: subdevice #1
  Subdevice #2: subdevice #2
  Subdevice #3: subdevice #3
  Subdevice #4: subdevice #4
  Subdevice #5: subdevice #5
  Subdevice #6: subdevice #6
  Subdevice #7: subdevice #7
card 0: Audigy2 [SB Audigy 2 ZS [SB0350]], device 3: emu10k1 [Multichannel 
Playback]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: Audigy2 [SB Audigy 2 ZS [SB0350]], device 4: p16v [p16v]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

Tascam US-122L - Corrupt USB descriptor

2016-04-13 Thread Simon Wood
Hi all,
I have been struggling for the past few days to get a Tascam US-122L (USB
sound-card/midi interface) working, despite reading numerous forum
postings I have only been able to get the midi portion working.

I note that the USB descriptor seems to be corrupt. It declares 2
interfaces, but then describes 3 separate with the same interface number
for the last 2... could it be that this is confusing the Linux USB stack?

I have attached a copy of the descriptor and an annotated 'lsusb -vv'.


>From my experience with the HID subsystem, they have a mechanism for
patching HID descriptors, is the same possible for the base USB
descriptor? Trolling through 'drivers/usb' I didn't see anything... any
suggestions?

If this is possible I can try to increase the interface count and renumber
the last one.

Cheers,
Simon.

PS. For reference the device is:
Model No: US-122L
Serial: (21)0120xxx
Other barcode: 043774021628  12 01 00 02 00 00 00 40  44 06 0e 80 00 01 01 02  |...@D...|
0010  03 01 09 02 48 00 02 01  00 80 f0 09 04 00 00 00  |H...|
0020  ff 00 00 00 09 04 01 00  00 ff 00 00 00 09 04 01  ||
0030  01 04 ff 00 00 00 09 05  81 05 4e 00 01 00 00 09  |..N.|
0040  05 02 05 4e 00 01 00 00  09 05 83 02 09 00 04 00  |...N|
0050  00 09 05 04 02 00 02 04  00 00|..|
005a



Bus 001 Device 042: ID 0644:800e TEAC Corp. TASCAM US-122L
--
  12 01 00 02 00 00 00 40  44 06 0e 80 00 01 01 02  |...@D...|
0010  03 01 __  |H...|
--
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   2.00
  bDeviceClass0 (Defined at Interface level)
  bDeviceSubClass 0 
  bDeviceProtocol 0 
  bMaxPacketSize064
  idVendor   0x0644 TEAC Corp.
  idProduct  0x800e TASCAM US-122L
  bcdDevice1.00
  iManufacturer   1 (error) <-- Here be 
Errors!
  iProduct2 (error)
  iSerial 3 (error)
  bNumConfigurations  1

  Configuration Descriptor:
--
0010  _ 09 02 48 00 02 01  00 80 f0 __  |H...|
--
bLength 9
bDescriptorType 2
wTotalLength   72
bNumInterfaces  2   <--- 2 
interfaces
bConfigurationValue 1
iConfiguration  0 
bmAttributes 0x80
  (Bus Powered)
MaxPower  480mA


Interface Descriptor:   <-- that's 1
--
0010  _ 09 04 00 00 00  |H...|
0020  ff 00 00 00   ||
--
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   0
  bInterfaceClass   255 Vendor Specific Class
  bInterfaceSubClass  0 
  bInterfaceProtocol  0 
  iInterface  0 

Interface Descriptor:   <-- that's 2
--
0020  ___ 09 04 01 00  00 ff 00 00 00   ||
--
  bLength 9
  bDescriptorType 4
  bInterfaceNumber1
  bAlternateSetting   0
  bNumEndpoints   0
  bInterfaceClass   255 Vendor Specific Class
  bInterfaceSubClass  0 
  bInterfaceProtocol  0 
  iInterface  0 

Interface Descriptor:   <-- that's 
3, err wait...
--
0020  ___ 09 04 01  ||
0030  01 04 ff 00 00 00 __  |..N.|
--
  bLength 9
  bDescriptorType 4
  bInterfaceNumber1 <-- 
interface duplicate!!
  bAlternateSetting   1
  bNumEndpoints   4
  bInterfaceClass   255 Vendor Specific Class
  bInterfaceSubClass  0 
  bInterfaceProtocol  0 
  iInterface  0 

  Endpoint Descriptor:
--
0030  _ 09 05  81 05 4e 00 01 00 00 __  |..N.|
--
bLength 9
bDescriptorType 5
bEndpointAddress 0x81  EP 1 IN
bmAttributes5
  Transfer TypeIsochronous
  Synch Type   Asynchronous
  Usage Type   Data
wMaxPacketSize 0x004e  1x 78 bytes
bInterval   1
bRefresh0
bSynchAddress   0

  Endpoint Descriptor:
--
0030  _

[PATCH] usb: gadget: renesas_usb3: Use ARCH_RENESAS

2016-03-01 Thread Simon Horman
Make use of ARCH_RENESAS in place of ARCH_SHMOBILE.

This is part of an ongoing process to migrate from ARCH_SHMOBILE to
ARCH_RENESAS the motivation for which being that RENESAS seems to be a more
appropriate name than SHMOBILE for the majority of Renesas ARM based SoCs.

Signed-off-by: Simon Horman 
---
 drivers/usb/gadget/udc/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

 Based on usb-gadget/next

diff --git a/drivers/usb/gadget/udc/Kconfig b/drivers/usb/gadget/udc/Kconfig
index ff4f8a6735d6..7c289416f87d 100644
--- a/drivers/usb/gadget/udc/Kconfig
+++ b/drivers/usb/gadget/udc/Kconfig
@@ -176,7 +176,7 @@ config USB_RENESAS_USBHS_UDC
 
 config USB_RENESAS_USB3
tristate 'Renesas USB3.0 Peripheral controller'
-   depends on ARCH_SHMOBILE || COMPILE_TEST
+   depends on ARCH_RENESAS || COMPILE_TEST
help
   Renesas USB3.0 Peripheral controller is a USB peripheral controller
   that supports super, high, and full speed USB 3.0 data transfers.
-- 
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 2/2] usb: host: xhci-rcar: Use ARCH_RENESAS

2016-02-18 Thread Simon Horman
Make use of ARCH_RENESAS in place of ARCH_SHMOBILE.

This is part of an ongoing process to migrate from ARCH_SHMOBILE to
ARCH_RENESAS the motivation for which being that RENESAS seems to be a more
appropriate name than SHMOBILE for the majority of Renesas ARM based SoCs.

Signed-off-by: Simon Horman 
---
 drivers/usb/host/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 438dcf6289b0..ed9a90f601e8 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -64,7 +64,7 @@ config USB_XHCI_MVEBU
 config USB_XHCI_RCAR
tristate "xHCI support for Renesas R-Car SoCs"
select USB_XHCI_PLATFORM
-   depends on ARCH_SHMOBILE || COMPILE_TEST
+   depends on ARCH_RENESAS || COMPILE_TEST
---help---
  Say 'Y' to enable the support for the xHCI host controller
  found in Renesas R-Car ARM SoCs.
-- 
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 1/2] usb: renesas_usbhs: Use ARCH_RENESAS

2016-02-18 Thread Simon Horman
Make use of ARCH_RENESAS in place of ARCH_SHMOBILE.

This is part of an ongoing process to migrate from ARCH_SHMOBILE to
ARCH_RENESAS the motivation for which being that RENESAS seems to be a more
appropriate name than SHMOBILE for the majority of Renesas ARM based SoCs.

Signed-off-by: Simon Horman 
---
 drivers/usb/renesas_usbhs/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/renesas_usbhs/Kconfig 
b/drivers/usb/renesas_usbhs/Kconfig
index ebc99ee076ce..b26d7c339c05 100644
--- a/drivers/usb/renesas_usbhs/Kconfig
+++ b/drivers/usb/renesas_usbhs/Kconfig
@@ -5,7 +5,7 @@
 config USB_RENESAS_USBHS
tristate 'Renesas USBHS controller'
depends on USB_GADGET
-   depends on ARCH_SHMOBILE || SUPERH || COMPILE_TEST
+   depends on ARCH_RENESAS || SUPERH || COMPILE_TEST
depends on EXTCON || !EXTCON # if EXTCON=m, USBHS cannot be built-in
default n
help
-- 
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 0/2] usb: Use ARCH_RENESAS

2016-02-18 Thread Simon Horman
Hi,

this short series makes use of of ARCH_RENESAS in place of ARCH_SHMOBILE.

This is part of an ongoing process to migrate from ARCH_SHMOBILE to
ARCH_RENESAS the motivation for which being that RENESAS seems to be a more
appropriate name than SHMOBILE for the majority of Renesas ARM based SoCs.

Simon Horman (2):
  usb: renesas_usbhs: Use ARCH_RENESAS
  usb: host: xhci-rcar: Use ARCH_RENESAS

 drivers/usb/host/Kconfig  | 2 +-
 drivers/usb/renesas_usbhs/Kconfig | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

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


[PATCHv2] net2280.h: fix endpoint max packet for super speed connections

2016-02-09 Thread Simon Appleby
This patch fixes the register offset used for super-speed connection's
max packet size. Without it using the 338x series of devices in enhanced
mode will only allow full or high speed operation to function correctly.

Signed-off-by: Simon Appleby 

--- linux/drivers/usb/gadget/udc/net2280.h.orig 2016-02-08 09:31:10.0 
+
+++ linux/drivers/usb/gadget/udc/net2280.h  2016-02-08 09:25:32.0 
+
@@ -369,9 +369,20 @@ static inline void set_max_speed(struct 
static const u32 ep_enhanced[9] = { 0x10, 0x60, 0x30, 0x80,
  0x50, 0x20, 0x70, 0x40, 0x90 };
 
-   if (ep->dev->enhanced_mode)
+   if (ep->dev->enhanced_mode) {
reg = ep_enhanced[ep->num];
-   else{
+   switch (ep->dev->gadget.speed) {
+   case USB_SPEED_SUPER:
+   reg += 2;
+   break;
+   case USB_SPEED_FULL:
+   reg += 1;
+   break;
+   case USB_SPEED_HIGH:
+   default:
+   break;
+   }
+   } else {
reg = (ep->num + 1) * 0x10;
if (ep->dev->gadget.speed != USB_SPEED_HIGH)
reg += 1;

__
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
__
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [Patch] net2280.h: fix endpoint max packet for super speed connections

2016-02-08 Thread Simon Appleby

> On 8 Feb 2016, at 16:50, Greg KH  wrote:
> 
> On Mon, Feb 08, 2016 at 10:01:09AM +0000, Simon Appleby wrote:
>> This patch fixes the register offset used for super-speed connection¹s max
>> packet size.
>> Without it using the 338x series of devices in enhanced mode will only
>> allow full or high speed operation to function correctly.
>> 
>> 
>> Signed-off-by: Simon Appleby 
>> 
>> 
>> --- linux/drivers/usb/gadget/udc/net2280.h.orig 2016-02-08
>> 09:31:10.0 +
>> +++ linux/drivers/usb/gadget/udc/net2280.h  2016-02-08
>> 09:25:32.0 +
>> @@ -369,9 +369,20 @@ static inline void set_max_speed(struct
>>  static const u32 ep_enhanced[9] = { 0x10, 0x60, 0x30, 0x80,
>>  0x50, 0x20, 0x70, 0x40, 0x90 };
>> 
>> -if (ep->dev->enhanced_mode)
>> +if (ep->dev->enhanced_mode) {
>>  reg = ep_enhanced[ep->num];
> 
> Patch is line-wrapped and whitespace corrupted :(
> 


My apologies, first time submitting a patch. Trying with a different client.



This patch fixes the register offset used for super-speed connection’s max 
packet size.
Without it using the 338x series of devices in enhanced mode will only allow 
full or high speed operation to function correctly.

Signed-off-by: Simon Appleby 

--- linux/drivers/usb/gadget/udc/net2280.h.orig 2016-02-08 09:31:10.0 
+
+++ linux/drivers/usb/gadget/udc/net2280.h  2016-02-08 09:25:32.0 
+
@@ -369,9 +369,20 @@ static inline void set_max_speed(struct 
static const u32 ep_enhanced[9] = { 0x10, 0x60, 0x30, 0x80,
  0x50, 0x20, 0x70, 0x40, 0x90 };
 
-   if (ep->dev->enhanced_mode)
+   if (ep->dev->enhanced_mode) {
reg = ep_enhanced[ep->num];
-   else{
+   switch (ep->dev->gadget.speed) {
+   case USB_SPEED_SUPER:
+   reg += 2;
+   break;
+   case USB_SPEED_FULL:
+   reg += 1;
+   break;
+   case USB_SPEED_HIGH:
+   default:
+   break;
+   }
+   } else {
reg = (ep->num + 1) * 0x10;
if (ep->dev->gadget.speed != USB_SPEED_HIGH)
reg += 1;


__
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
__
N�r��yb�X��ǧv�^�)޺{.n�+{��^n�r���z���h�&���G���h�(�階�ݢj"���m��z�ޖ���f���h���~�m�

[Patch] net2280.h: fix endpoint max packet for super speed connections

2016-02-08 Thread Simon Appleby
This patch fixes the register offset used for super-speed connection¹s max
packet size.
Without it using the 338x series of devices in enhanced mode will only
allow full or high speed operation to function correctly.


Signed-off-by: Simon Appleby 


--- linux/drivers/usb/gadget/udc/net2280.h.orig 2016-02-08
09:31:10.0 +
+++ linux/drivers/usb/gadget/udc/net2280.h  2016-02-08
09:25:32.0 +
@@ -369,9 +369,20 @@ static inline void set_max_speed(struct
static const u32 ep_enhanced[9] = { 0x10, 0x60, 0x30, 0x80,
0x50, 0x20, 0x70, 0x40, 0x90 };
 
-   if (ep->dev->enhanced_mode)
+   if (ep->dev->enhanced_mode) {
reg = ep_enhanced[ep->num];
-   else{
+   switch (ep->dev->gadget.speed) {
+   case USB_SPEED_SUPER:
+   reg += 2;
+   break;
+   case USB_SPEED_FULL:
+   reg += 1;
+   break;
+   case USB_SPEED_HIGH:
+   default:
+   break;
+   }
+   } else {
reg = (ep->num + 1) * 0x10;
if (ep->dev->gadget.speed != USB_SPEED_HIGH)
reg += 1;
















__
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
__
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v4 0/3] usb: renesas_usbhs: More compat strings

2015-12-15 Thread Simon Horman

Hi,

this short series adds generic, and soc-specific r8a7792 and r8a7793 compat
strings to the Renesas USBHS driver. The intention is to provide a complete
set of compat strings for known R-Car SoCs.

Changes since v3:
* State that one or more compat string should be used

Changes since v2:
* Split documentation of SoC names into separate patch
* Use correct fallback compatibility string in example

Changes since v1:
* Add R-Car Gen2 and Gen3 fallback compatibility strings rather than
a single compatibility string for all of R-Car.

Simon Horman (3):
  usb: renesas_usbhs: add SoC names to compatibility string
documentation
  usb: renesas_usbhs: add fallback compatibility strings
  usb: renesas_usbhs: add device tree support for r8a779[23]

 .../devicetree/bindings/usb/renesas_usbhs.txt  | 22 --
 drivers/usb/renesas_usbhs/common.c |  9 +
 2 files changed, 25 insertions(+), 6 deletions(-)

-- 
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 v4 3/3] usb: renesas_usbhs: add device tree support for r8a779[23]

2015-12-15 Thread Simon Horman
Simply document new compatibility string.
As a previous patch adds a generic R-Car Gen2 compatibility string
there appears to be no need for a driver updates.

Signed-off-by: Simon Horman 
Acked-by: Rob Herring 
Acked-by: Kuninori Morimoto 
---
 Documentation/devicetree/bindings/usb/renesas_usbhs.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/usb/renesas_usbhs.txt 
b/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
index 45d9ae13ffa3..b6040563e51a 100644
--- a/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
+++ b/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
@@ -5,6 +5,8 @@ Required properties:
 
- "renesas,usbhs-r8a7790" for r8a7790 (R-Car H2) compatible device
- "renesas,usbhs-r8a7791" for r8a7791 (R-Car M2-W) compatible device
+   - "renesas,usbhs-r8a7792" for r8a7792 (R-Car V2H) compatible device
+   - "renesas,usbhs-r8a7793" for r8a7793 (R-Car M2-N) compatible device
- "renesas,usbhs-r8a7794" for r8a7794 (R-Car E2) compatible device
- "renesas,usbhs-r8a7795" for r8a7795 (R-Car H3) compatible device
- "renesas,rcar-gen2-usbhs" for R-Car Gen2 compatible device
-- 
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 v4 1/3] usb: renesas_usbhs: add SoC names to compatibility string documentation

2015-12-15 Thread Simon Horman
This extends the documentation of compatibility strings a little to
include the SoC names.

Signed-off-by: Simon Horman 
Acked-by: Kuninori Morimoto 

---
v3
* Split into separate patch
---
 Documentation/devicetree/bindings/usb/renesas_usbhs.txt | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/Documentation/devicetree/bindings/usb/renesas_usbhs.txt 
b/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
index 7d48f63db44e..a14c0bb561d5 100644
--- a/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
+++ b/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
@@ -2,10 +2,10 @@ Renesas Electronics USBHS driver
 
 Required properties:
   - compatible: Must contain one of the following:
-   - "renesas,usbhs-r8a7790"
-   - "renesas,usbhs-r8a7791"
-   - "renesas,usbhs-r8a7794"
-   - "renesas,usbhs-r8a7795"
+   - "renesas,usbhs-r8a7790" for r8a7790 (R-Car H2) compatible device
+   - "renesas,usbhs-r8a7791" for r8a7791 (R-Car M2-W) compatible device
+   - "renesas,usbhs-r8a7794" for r8a7794 (R-Car E2) compatible device
+   - "renesas,usbhs-r8a7795" for r8a7795 (R-Car H3) compatible device
   - reg: Base address and length of the register for the USBHS
   - interrupts: Interrupt specifier for the USBHS
   - clocks: A list of phandle + clock specifier pairs
-- 
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 v4 2/3] usb: renesas_usbhs: add fallback compatibility strings

2015-12-15 Thread Simon Horman
Add fallback compatibility strings for R-Car Gen2 and Gen3.
This is in keeping with the fallback scheme being adopted wherever
appropriate for drivers for Renesas SoCs.

Signed-off-by: Simon Horman 
Acked-by: Kuninori Morimoto 
---
v4
* State that one or more compat string should be used

v3
* Moved documentation of SoC names to a separate patch
* Use correct fallback compatibility string in example

v2
* Add R-Car Gen2 and Gen3 fallback compatibility strings rather than
  a single compatibility string for all of R-Car.
---
 Documentation/devicetree/bindings/usb/renesas_usbhs.txt | 12 ++--
 drivers/usb/renesas_usbhs/common.c  |  9 +
 2 files changed, 19 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/usb/renesas_usbhs.txt 
b/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
index a14c0bb561d5..45d9ae13ffa3 100644
--- a/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
+++ b/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
@@ -1,11 +1,19 @@
 Renesas Electronics USBHS driver
 
 Required properties:
-  - compatible: Must contain one of the following:
+  - compatible: Must contain one or more of the following:
+
- "renesas,usbhs-r8a7790" for r8a7790 (R-Car H2) compatible device
- "renesas,usbhs-r8a7791" for r8a7791 (R-Car M2-W) compatible device
- "renesas,usbhs-r8a7794" for r8a7794 (R-Car E2) compatible device
- "renesas,usbhs-r8a7795" for r8a7795 (R-Car H3) compatible device
+   - "renesas,rcar-gen2-usbhs" for R-Car Gen2 compatible device
+   - "renesas,rcar-gen3-usbhs" for R-Car Gen3 compatible device
+
+   When compatible with the generic version, nodes must list the
+   SoC-specific version corresponding to the platform first followed
+   by the generic version.
+
   - reg: Base address and length of the register for the USBHS
   - interrupts: Interrupt specifier for the USBHS
   - clocks: A list of phandle + clock specifier pairs
@@ -22,7 +30,7 @@ Optional properties:
 
 Example:
usbhs: usb@e659 {
-   compatible = "renesas,usbhs-r8a7790";
+   compatible = "renesas,usbhs-r8a7790", "renesas,rcar-gen2-usbhs";
reg = <0 0xe659 0 0x100>;
interrupts = <0 107 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&mstp7_clks R8A7790_CLK_HSUSB>;
diff --git a/drivers/usb/renesas_usbhs/common.c 
b/drivers/usb/renesas_usbhs/common.c
index d82fa36c3465..db9a17bd8997 100644
--- a/drivers/usb/renesas_usbhs/common.c
+++ b/drivers/usb/renesas_usbhs/common.c
@@ -481,6 +481,15 @@ static const struct of_device_id usbhs_of_match[] = {
.compatible = "renesas,usbhs-r8a7795",
.data = (void *)USBHS_TYPE_RCAR_GEN2,
},
+   {
+   .compatible = "renesas,rcar-gen2-usbhs",
+   .data = (void *)USBHS_TYPE_RCAR_GEN2,
+   },
+   {
+   /* Gen3 is compatible with Gen2 */
+   .compatible = "renesas,rcar-gen3-usbhs",
+   .data = (void *)USBHS_TYPE_RCAR_GEN2,
+   },
{ },
 };
 MODULE_DEVICE_TABLE(of, usbhs_of_match);
-- 
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: [PATCH v3 2/3] usb: renesas_usbhs: add fallback compatibility strings

2015-12-14 Thread Simon Horman
On Fri, Dec 11, 2015 at 03:24:27PM +0300, Sergei Shtylyov wrote:
> Hello.
> 
> On 12/11/2015 5:12 AM, Simon Horman wrote:
> 
> >Add fallback compatibility strings for R-Car Gen2 and Gen3.
> >This is in keeping with the fallback scheme being adopted wherever
> >appropriate for drivers for Renesas SoCs.
> >
> >Signed-off-by: Simon Horman 
> >---
> >v3
> >* Moved documentation of SoC names to a separate patch
> >* Use correct fallback compatibility string in example
> >
> >v2
> >* Add R-Car Gen2 and Gen3 fallback compatibility strings rather than
> >   a single compatibility string for all of R-Car.
> >---
> >  Documentation/devicetree/bindings/usb/renesas_usbhs.txt | 10 +-
> >  drivers/usb/renesas_usbhs/common.c  |  9 +
> >  2 files changed, 18 insertions(+), 1 deletion(-)
> >
> >diff --git a/Documentation/devicetree/bindings/usb/renesas_usbhs.txt 
> >b/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
> >index a14c0bb561d5..c55cf77006d0 100644
> >--- a/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
> >+++ b/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
> >@@ -2,10 +2,18 @@ Renesas Electronics USBHS driver
> >
> >  Required properties:
> >- compatible: Must contain one of the following:
> 
>Really?

Would "...one or more of the following" help?

> >+
> > - "renesas,usbhs-r8a7790" for r8a7790 (R-Car H2) compatible device
> > - "renesas,usbhs-r8a7791" for r8a7791 (R-Car M2-W) compatible device
> > - "renesas,usbhs-r8a7794" for r8a7794 (R-Car E2) compatible device
> > - "renesas,usbhs-r8a7795" for r8a7795 (R-Car H3) compatible device
> >+- "renesas,rcar-gen2-usbhs" for R-Car Gen2 compatible device
> >+- "renesas,rcar-gen3-usbhs" for R-Car Gen3 compatible device
> >+
> >+When compatible with the generic version, nodes must list the
> >+SoC-specific version corresponding to the platform first followed
> >+by the generic version.
> >+
> 
>This kinda contradicts the above claim.
> 
> [...]
> 
> MBR, Sergei
> 
--
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 v3 2/3] usb: renesas_usbhs: add fallback compatibility strings

2015-12-10 Thread Simon Horman
On Thu, Dec 10, 2015 at 09:56:24PM -0600, Rob Herring wrote:
> On Fri, Dec 11, 2015 at 11:12:26AM +0900, Simon Horman wrote:
> > Add fallback compatibility strings for R-Car Gen2 and Gen3.
> > This is in keeping with the fallback scheme being adopted wherever
> > appropriate for drivers for Renesas SoCs.
> > 
> > Signed-off-by: Simon Horman 
> 
> Binding looks okay, but one possible typo.
> 
> Acked-by: Rob Herring 
> 
> > --- a/drivers/usb/renesas_usbhs/common.c
> > +++ b/drivers/usb/renesas_usbhs/common.c
> > @@ -481,6 +481,15 @@ static const struct of_device_id usbhs_of_match[] = {
> > .compatible = "renesas,usbhs-r8a7795",
> > .data = (void *)USBHS_TYPE_RCAR_GEN2,
> > },
> > +   {
> > +   .compatible = "renesas,rcar-gen2-usbhs",
> > +   .data = (void *)USBHS_TYPE_RCAR_GEN2,
> > +   },
> > +   {
> > +   /* Gen3 is compatible with Gen2 */
> > +   .compatible = "renesas,rcar-gen3-usbhs",
> > +   .data = (void *)USBHS_TYPE_RCAR_GEN2,
> 
> This supposed to be GEN3?

Confusingly the symbol is called GEN2 as it was there for Gen 2
before Gen 3 came along and (so far) Gen 3 is compatible with Gen 2.

I'd be happy to change the name but I think that would be best
as an incremental change on top of this one.
--
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 v3 3/3] usb: renesas_usbhs: add device tree support for r8a779[23]

2015-12-10 Thread Simon Horman
Simply document new compatibility string.
As a previous patch adds a generic R-Car Gen2 compatibility string
there appears to be no need for a driver updates.

Signed-off-by: Simon Horman 
Acked-by: Rob Herring 
---
 Documentation/devicetree/bindings/usb/renesas_usbhs.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/usb/renesas_usbhs.txt 
b/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
index c55cf77006d0..471a0649e63e 100644
--- a/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
+++ b/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
@@ -5,6 +5,8 @@ Required properties:
 
- "renesas,usbhs-r8a7790" for r8a7790 (R-Car H2) compatible device
- "renesas,usbhs-r8a7791" for r8a7791 (R-Car M2-W) compatible device
+   - "renesas,usbhs-r8a7792" for r8a7792 (R-Car V2H) compatible device
+   - "renesas,usbhs-r8a7793" for r8a7793 (R-Car M2-N) compatible device
- "renesas,usbhs-r8a7794" for r8a7794 (R-Car E2) compatible device
- "renesas,usbhs-r8a7795" for r8a7795 (R-Car H3) compatible device
- "renesas,rcar-gen2-usbhs" for R-Car Gen2 compatible device
-- 
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 v3 2/3] usb: renesas_usbhs: add fallback compatibility strings

2015-12-10 Thread Simon Horman
Add fallback compatibility strings for R-Car Gen2 and Gen3.
This is in keeping with the fallback scheme being adopted wherever
appropriate for drivers for Renesas SoCs.

Signed-off-by: Simon Horman 
---
v3
* Moved documentation of SoC names to a separate patch
* Use correct fallback compatibility string in example

v2
* Add R-Car Gen2 and Gen3 fallback compatibility strings rather than
  a single compatibility string for all of R-Car.
---
 Documentation/devicetree/bindings/usb/renesas_usbhs.txt | 10 +-
 drivers/usb/renesas_usbhs/common.c  |  9 +
 2 files changed, 18 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/usb/renesas_usbhs.txt 
b/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
index a14c0bb561d5..c55cf77006d0 100644
--- a/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
+++ b/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
@@ -2,10 +2,18 @@ Renesas Electronics USBHS driver
 
 Required properties:
   - compatible: Must contain one of the following:
+
- "renesas,usbhs-r8a7790" for r8a7790 (R-Car H2) compatible device
- "renesas,usbhs-r8a7791" for r8a7791 (R-Car M2-W) compatible device
- "renesas,usbhs-r8a7794" for r8a7794 (R-Car E2) compatible device
- "renesas,usbhs-r8a7795" for r8a7795 (R-Car H3) compatible device
+   - "renesas,rcar-gen2-usbhs" for R-Car Gen2 compatible device
+   - "renesas,rcar-gen3-usbhs" for R-Car Gen3 compatible device
+
+   When compatible with the generic version, nodes must list the
+   SoC-specific version corresponding to the platform first followed
+   by the generic version.
+
   - reg: Base address and length of the register for the USBHS
   - interrupts: Interrupt specifier for the USBHS
   - clocks: A list of phandle + clock specifier pairs
@@ -22,7 +30,7 @@ Optional properties:
 
 Example:
usbhs: usb@e659 {
-   compatible = "renesas,usbhs-r8a7790";
+   compatible = "renesas,usbhs-r8a7790", "renesas,rcar-gen2-usbhs";
reg = <0 0xe659 0 0x100>;
interrupts = <0 107 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&mstp7_clks R8A7790_CLK_HSUSB>;
diff --git a/drivers/usb/renesas_usbhs/common.c 
b/drivers/usb/renesas_usbhs/common.c
index d82fa36c3465..db9a17bd8997 100644
--- a/drivers/usb/renesas_usbhs/common.c
+++ b/drivers/usb/renesas_usbhs/common.c
@@ -481,6 +481,15 @@ static const struct of_device_id usbhs_of_match[] = {
.compatible = "renesas,usbhs-r8a7795",
.data = (void *)USBHS_TYPE_RCAR_GEN2,
},
+   {
+   .compatible = "renesas,rcar-gen2-usbhs",
+   .data = (void *)USBHS_TYPE_RCAR_GEN2,
+   },
+   {
+   /* Gen3 is compatible with Gen2 */
+   .compatible = "renesas,rcar-gen3-usbhs",
+   .data = (void *)USBHS_TYPE_RCAR_GEN2,
+   },
{ },
 };
 MODULE_DEVICE_TABLE(of, usbhs_of_match);
-- 
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 v3 0/3] usb: renesas_usbhs: More compat strings

2015-12-10 Thread Simon Horman
Hi,

this short series adds generic, and soc-specific r8a7792 and r8a7793 compat
strings to the Renesas USBHS driver. The intention is to provide a complete
set of compat strings for known R-Car SoCs.

Changes since v2:
* Split documentation of SoC names into separate patch
* Use correct fallback compatibility string in example

Changes since v1:
* Add R-Car Gen2 and Gen3 fallback compatibility strings rather than
  a single compatibility string for all of R-Car.

Simon Horman (3):
  usb: renesas_usbhs: add SoC names to compatibility string
documentation
  usb: renesas_usbhs: add fallback compatibility strings
  usb: renesas_usbhs: add device tree support for r8a779[23]

 .../devicetree/bindings/usb/renesas_usbhs.txt| 20 +++-
 drivers/usb/renesas_usbhs/common.c   |  9 +
 2 files changed, 24 insertions(+), 5 deletions(-)

-- 
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 v3 1/3] usb: renesas_usbhs: add SoC names to compatibility string documentation

2015-12-10 Thread Simon Horman
This extends the documentation of compatibility strings a little to
include the SoC names.

Signed-off-by: Simon Horman 
---
v3
* Split into separate patch
---
 Documentation/devicetree/bindings/usb/renesas_usbhs.txt | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/Documentation/devicetree/bindings/usb/renesas_usbhs.txt 
b/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
index 7d48f63db44e..a14c0bb561d5 100644
--- a/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
+++ b/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
@@ -2,10 +2,10 @@ Renesas Electronics USBHS driver
 
 Required properties:
   - compatible: Must contain one of the following:
-   - "renesas,usbhs-r8a7790"
-   - "renesas,usbhs-r8a7791"
-   - "renesas,usbhs-r8a7794"
-   - "renesas,usbhs-r8a7795"
+   - "renesas,usbhs-r8a7790" for r8a7790 (R-Car H2) compatible device
+   - "renesas,usbhs-r8a7791" for r8a7791 (R-Car M2-W) compatible device
+   - "renesas,usbhs-r8a7794" for r8a7794 (R-Car E2) compatible device
+   - "renesas,usbhs-r8a7795" for r8a7795 (R-Car H3) compatible device
   - reg: Base address and length of the register for the USBHS
   - interrupts: Interrupt specifier for the USBHS
   - clocks: A list of phandle + clock specifier pairs
-- 
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: [PATCH v2 1/2] usb: renesas_usbhs: add fallback compatibility strings

2015-12-10 Thread Simon Horman
On Thu, Dec 10, 2015 at 07:28:06AM +, Kuninori Morimoto wrote:
> 
> Hi Simon
> 
> Thank you for your patch
> 
> > Add fallback compatibility strings for R-Car Gen2 and Gen3.
> > This is in keeping with the fallback scheme being adopted wherever
> > appropriate for drivers for Renesas SoCs.
> > 
> > Also add SoC names.
> > 
> > Signed-off-by: Simon Horman 
> > ---
> (snip)
> >  Required properties:
> >- compatible: Must contain one of the following:
> > -   - "renesas,usbhs-r8a7790"
> > -   - "renesas,usbhs-r8a7791"
> > -   - "renesas,usbhs-r8a7794"
> > -   - "renesas,usbhs-r8a7795"
> > +
> > +   - "renesas,usbhs-r8a7790" for r8a7790 (R-Car H2) compatible device
> > +   - "renesas,usbhs-r8a7791" for r8a7791 (R-Car M2-W) compatible device
> > +   - "renesas,usbhs-r8a7794" for r8a7794 (R-Car E2) compatible device
> > +   - "renesas,usbhs-r8a7795" for r8a7795 (R-Car H3) compatible device
> > +   - "renesas,rcar-gen2-usbhs" for R-Car Gen2 compatibile device
> > +   - "renesas,rcar-gen3-usbhs" for R-Car Gen3 compatibile device
> > +
> > +   When compatible with the generic version, nodes must list the
> > +   SoC-specific version corresponding to the platform first followed
> > +   by the generic version.
> 
> I think these can be separated ?
> 
>  1. document update for "renesas,usbhs-r8a77xx"
>  2. add new "rcar-genX" (this patch)

Sure, will do.

> >  Example:
> > usbhs: usb@e659 {
> > -   compatible = "renesas,usbhs-r8a7790";
> > +   compatible = "renesas,usbhs-r8a7790", "renesas,rcar-usbhs";
> 
> I think you want
> 
>  -compatible = "renesas,usbhs-r8a7790", "renesas,rcar-usbhs";
>  +compatible = "renesas,usbhs-r8a7790", "renesas,rcar-gen2-usbhs";

Thanks, I will fix that.
--
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


  1   2   3   >