Re: [PATCH v2] dt-bindings: usb: renesas_gen3: Rename bindings documentation file to reflect IP block
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
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()
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,
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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?
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?
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?
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()
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
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
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
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
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
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
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
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
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"
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
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
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
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
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
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
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
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
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
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
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
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
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
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"
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
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
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
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
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
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
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
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()
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
> 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
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
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]
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
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
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
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
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]
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
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
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
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
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