Re: [PATCH v5] usb: misc: add USB251xB/xBi Hi-Speed Hub Controller Driver

[Richard Leitner]

On 02/16/2017 03:30 AM, Rob Herring wrote:

On Fri, Feb 10, 2017 at 09:19:27AM +0100, Richard Leitner wrote:

This patch adds a driver for configuration of the Microchip USB251xB/xBi
USB 2.0 hub controller series with USB 2.0 upstream connectivity, SMBus
configuration interface and two to four USB 2.0 downstream ports.

Furthermore add myself as a maintainer for this driver.

The datasheet can be found at the manufacturers website, see [1]. All
device-tree exposed configuration features have been tested on a i.MX6
platform with a USB2512B hub.

[1] http://ww1.microchip.com/downloads/en/DeviceDoc/1692C.pdf

Signed-off-by: Richard Leitner 
---
CHANGES v5:


V5 and the first I see it?


Just double-checked it, you (robh...@kernel.org) were on CC since v1.

@greg-kh: I got the notification that v5 was already applied to your usb 
tree. So how should I proceed here? Send a v6 or send a separate patch 
fixing the dt issues mentioned by robh?





- Put includes in alphabetical order
- Fix some indentations
- Replace {set,clr}_bit_in_byte with BIT() macros
- Fix multiline comments
- Use of_property_read_u32() instead of of_get_property() where possible
- Use min_t() instead of by-hand implemented if's
- Use strlcpy and ternary operator instead of strncpy in if/else
- Remove useless & improve some other outputs
- Omit i2c remove function
- Use module_i2c_driver() instead of module_{init,exit}()
CHANGES v4:
- use utf8s_to_utf16s() instead of ascii2utf16le()
- remove ascii2utf16le() in lib/string.c again
- remove changes in drivers/usb/core/hcd.c again
  (I will post a separate patch for using utf8s_to_utf16s()
  in there too)

CHANGES v3:
- move ascii2utf16le() to lib/string.c and also use it also for
ascii2desc in drivers/usb/core/hcd.c
- remove platform data support from usb251xb driver

CHANGES v2:
- fix max-{b,s}p-current property name
- add descriptor string handling from platform_data
- fix non-dt handling
---
 Documentation/devicetree/bindings/usb/usb251xb.txt |  83 +++
 MAINTAINERS|   8 +
 drivers/usb/misc/Kconfig   |   9 +
 drivers/usb/misc/Makefile  |   1 +
 drivers/usb/misc/usb251xb.c| 605 +
 5 files changed, 706 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/usb/usb251xb.txt
 create mode 100644 drivers/usb/misc/usb251xb.c

diff --git a/Documentation/devicetree/bindings/usb/usb251xb.txt 
b/Documentation/devicetree/bindings/usb/usb251xb.txt
new file mode 100644
index 000..0c065f7
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/usb251xb.txt
@@ -0,0 +1,83 @@
+Microchip USB 2.0 Hi-Speed Hub Controller
+
+The device node for the configuration of a Microchip USB251xB/xBi USB 2.0
+Hi-Speed Controller.
+
+Required properties :
+ - compatible : Should be "microchip,usb251xb" or one of the specific types:
+   "microchip,usb2512b", "microchip,usb2512bi", "microchip,usb2513b",
+   "microchip,usb2513bi", "microchip,usb2514b", "microchip,usb2514bi"
+ - hub-reset-gpios : Should specify the gpio for hub reset


Just "reset-gpios". And you need to define the active state.


OK.




+
+Optional properties :
+ - reg : I2C address on the selected bus (default is <0x2C>)


Why is this optional?


Due to the fact the address is hardcoded insinde the chip I thought we 
could set it to 0x2C by default if reg is not given.


Should it be required?




+ - skip-config : Skip Hub configuration, but only send the USB-Attach command
+ - vendor-id : USB Vendor ID of the hub (16 bit, default is 0x0424)
+ - product-id : USB Product ID of the hub (16 bit, default depends on type)


These are to set the ids or need to match what they are set too?


These are to set the VID/PID of the Hub.




+ - device-id : USB Device ID of the hub (16 bit, default is 0x0bb3)
+ - language-id : USB Language ID (16 bit, default is 0x)
+ - manufacturer : USB Manufacturer string (max 31 characters long)
+ - product : USB Product string (max 31 characters long)
+ - serial : USB Serial string (max 31 characters long)
+ - {bus,self}-powered : selects between self- and bus-powered operation 
(default
+   is self-powered)
+ - disable-hi-speed : disable USB Hi-Speed support
+ - {multi,single}-tt : selects between multi- and single-transaction-translator
+   (default is multi-tt)
+ - disable-eop : disable End of Packet generation in full-speed mode
+ - {ganged,individual}-sensing : select over-current sense type in self-powered
+   mode (default is individual)
+ - {ganged,individual}-port-switching : select port power switching mode
+   (default is individual)
+ - dynamic-power-switching : enable auto-switching from self- to bus-powered
+   operation if the 

Re: [PATCH v5 0/5] dmaengine: cppi41: Make CPPI 4.1 driver more generic

[Vinod Koul]

On Wed, Feb 15, 2017 at 02:56:31PM +0100, Alexandre Bailon wrote:
> This series intend to make the CPPI 4.1 more generic in order to
> add a new platform (the DA8xx).
> To achieve that, all the IRQ code present in CPPI 4.1 driver has been moved
> to MUSB DSPS driver.
> Other changes mainly update the glue layer and platform code to make the
> whole driver more generic.
> 
> Changes in v5:
>  - Rebase on linux-next
>  - No dependencies on other series anymore (they have been applied)

Not really, we dont apply patches on linux-next but on subsystem tree's.
So since we are soo close to merge window, am going to defer this series and
apply once merge window closes.

> 
> Changes in v4:
>  - Remove dev argument in patch 4
>  - Remove the isr callback from glue
> 
> Changes in v3:
> - To prevent build error report from kbuild test robot, move the first
>   patch of v2 to another patchset.
> - Make CPPI 4.1 driver compatible with old and new binddings.
> - Remove the patch updating the am33xx-usb binddings.
> - Remove useless changes in patch 4
> - Remove a patch that was fixing PM runtime issue that was happenning
>   during a teardown. Tony Lindgren's patches fix the issue.
> 
> Alexandre Bailon (5):
>   dmaengine: cppi41: Remove usbss_mem
>   dmaengine: cppi41: rename platform variables
>   dmaengine: cppi41: Move some constants to glue layer
>   dmaengine: cppi41: init_sched(): Get number of channels from DT
>   dmaengine: cppi41: Remove isr callback from glue layer
> 
>  drivers/dma/cppi41.c | 79 
> ++--
>  1 file changed, 46 insertions(+), 33 deletions(-)
> 
> -- 
> 2.10.2
> 

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

Re: [RFC][PATCH] usb: dwc2: Make sure we disconnect the gadget state

[John Youn]

On 2/13/2017 8:08 PM, John Stultz wrote:
> Just wanted to get some early feedback on this before I submit
> it for real for the 4.12 timeframe. This is the last patch, that
> isn't already queued, which I need to get hikey's USB working
> properly.
>
> Feedback would be greatly appreciated!
>


It looks good to me.

Acked-by: John Youn 

Regards,
John



> thanks
> -john
>
>
> I had seen some odd behavior with HiKey's usb-gadget interface
> that I finally seemed to have chased down. Basically every other
> time I pluged in the OTG port, the gadget interface would
> properly initialize. The other times, I'd get a big WARN_ON
> in dwc2_hsotg_init_fifo() about the fifo_map not being clear.
>
> Ends up if we don't disconnect the gadget state, the fifo-map
> doesn't get cleared properly, which causes WARN_ON messages and
> also results in the device not properly being setup as a gadget
> every other time the OTG port is connected.
>
> So this patch adds a call to dwc2_hsotg_disconnect() in the
> reset path so the state is properly cleared.
>
> With it, the gadget interface initializes properly on every
> plug in.
>
> Cc: Wei Xu 
> Cc: Guodong Xu 
> Cc: Amit Pundir 
> Cc: Rob Herring 
> Cc: John Youn 
> Cc: Douglas Anderson 
> Cc: Chen Yu 
> Cc: Felipe Balbi 
> Cc: Greg Kroah-Hartman 
> Cc: linux-usb@vger.kernel.org
> Signed-off-by: John Stultz 
> ---
>  drivers/usb/dwc2/hcd.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
> index 90bd248..067202d 100644
> --- a/drivers/usb/dwc2/hcd.c
> +++ b/drivers/usb/dwc2/hcd.c
> @@ -3266,6 +3266,7 @@ static void dwc2_conn_id_status_change(struct 
> work_struct *work)
>   dwc2_core_init(hsotg, false);
>   dwc2_enable_global_interrupts(hsotg);
>   spin_lock_irqsave(>lock, flags);
> + dwc2_hsotg_disconnect(hsotg);
>   dwc2_hsotg_core_init_disconnected(hsotg, false);
>   spin_unlock_irqrestore(>lock, flags);
>   dwc2_hsotg_core_connect(hsotg);
>

--
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 v5] usb: misc: add USB251xB/xBi Hi-Speed Hub Controller Driver

[Rob Herring]

On Fri, Feb 10, 2017 at 09:19:27AM +0100, Richard Leitner wrote:
> This patch adds a driver for configuration of the Microchip USB251xB/xBi
> USB 2.0 hub controller series with USB 2.0 upstream connectivity, SMBus
> configuration interface and two to four USB 2.0 downstream ports.
> 
> Furthermore add myself as a maintainer for this driver.
> 
> The datasheet can be found at the manufacturers website, see [1]. All
> device-tree exposed configuration features have been tested on a i.MX6
> platform with a USB2512B hub.
> 
> [1] http://ww1.microchip.com/downloads/en/DeviceDoc/1692C.pdf
> 
> Signed-off-by: Richard Leitner 
> ---
> CHANGES v5:

V5 and the first I see it?

>   - Put includes in alphabetical order
>   - Fix some indentations
>   - Replace {set,clr}_bit_in_byte with BIT() macros
>   - Fix multiline comments
>   - Use of_property_read_u32() instead of of_get_property() where possible
>   - Use min_t() instead of by-hand implemented if's
>   - Use strlcpy and ternary operator instead of strncpy in if/else
>   - Remove useless & improve some other outputs
>   - Omit i2c remove function
>   - Use module_i2c_driver() instead of module_{init,exit}()
> CHANGES v4:
>   - use utf8s_to_utf16s() instead of ascii2utf16le()
>   - remove ascii2utf16le() in lib/string.c again
>   - remove changes in drivers/usb/core/hcd.c again
> (I will post a separate patch for using utf8s_to_utf16s()
> in there too)
> 
> CHANGES v3:
>   - move ascii2utf16le() to lib/string.c and also use it also for
>   ascii2desc in drivers/usb/core/hcd.c
>   - remove platform data support from usb251xb driver
> 
> CHANGES v2:
>   - fix max-{b,s}p-current property name
>   - add descriptor string handling from platform_data
>   - fix non-dt handling
> ---
>  Documentation/devicetree/bindings/usb/usb251xb.txt |  83 +++
>  MAINTAINERS|   8 +
>  drivers/usb/misc/Kconfig   |   9 +
>  drivers/usb/misc/Makefile  |   1 +
>  drivers/usb/misc/usb251xb.c| 605 
> +
>  5 files changed, 706 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/usb/usb251xb.txt
>  create mode 100644 drivers/usb/misc/usb251xb.c
> 
> diff --git a/Documentation/devicetree/bindings/usb/usb251xb.txt 
> b/Documentation/devicetree/bindings/usb/usb251xb.txt
> new file mode 100644
> index 000..0c065f7
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/usb/usb251xb.txt
> @@ -0,0 +1,83 @@
> +Microchip USB 2.0 Hi-Speed Hub Controller
> +
> +The device node for the configuration of a Microchip USB251xB/xBi USB 2.0
> +Hi-Speed Controller.
> +
> +Required properties :
> + - compatible : Should be "microchip,usb251xb" or one of the specific types:
> + "microchip,usb2512b", "microchip,usb2512bi", "microchip,usb2513b",
> + "microchip,usb2513bi", "microchip,usb2514b", "microchip,usb2514bi"
> + - hub-reset-gpios : Should specify the gpio for hub reset

Just "reset-gpios". And you need to define the active state.

> +
> +Optional properties :
> + - reg : I2C address on the selected bus (default is <0x2C>)

Why is this optional? 

> + - skip-config : Skip Hub configuration, but only send the USB-Attach command
> + - vendor-id : USB Vendor ID of the hub (16 bit, default is 0x0424)
> + - product-id : USB Product ID of the hub (16 bit, default depends on type)

These are to set the ids or need to match what they are set too?

> + - device-id : USB Device ID of the hub (16 bit, default is 0x0bb3)
> + - language-id : USB Language ID (16 bit, default is 0x)
> + - manufacturer : USB Manufacturer string (max 31 characters long)
> + - product : USB Product string (max 31 characters long)
> + - serial : USB Serial string (max 31 characters long)
> + - {bus,self}-powered : selects between self- and bus-powered operation 
> (default
> + is self-powered)
> + - disable-hi-speed : disable USB Hi-Speed support
> + - {multi,single}-tt : selects between multi- and 
> single-transaction-translator
> + (default is multi-tt)
> + - disable-eop : disable End of Packet generation in full-speed mode
> + - {ganged,individual}-sensing : select over-current sense type in 
> self-powered
> + mode (default is individual)
> + - {ganged,individual}-port-switching : select port power switching mode
> + (default is individual)
> + - dynamic-power-switching : enable auto-switching from self- to bus-powered
> + operation if the local power source is removed or unavailable
> + - oc-delay-{100us,4ms,8ms,16ms} : set over current timer delay (default is 
> 8ms)

Make the property value be the time (e.g. oc-delay-us).

> + - compound-device : indicated the hub is part of a compound device
> + - port-mapping-mode : enable port mapping mode
> + - string-support : enable string descriptor support (required for 
> 

Re: [RESEND PATCH v2 1/2] Documentation: dt: dwc2: amend clocks property

[Rob Herring]

On Fri, Feb 10, 2017 at 11:06:26AM +0800, Frank Wang wrote:
> Move 'clocks' to optional properties since not every platform
> is going to need to specify it and add pmu/utmi/ulpi/utmifs
> optional clocks into 'clock-names' list.
> 
> Signed-off-by: Frank Wang 
> ---
>  Documentation/devicetree/bindings/usb/dwc2.txt | 13 ++---
>  1 file changed, 10 insertions(+), 3 deletions(-)

Acked-by: Rob Herring  

It would be good to get some acks from others familar with this block.

Rob
--
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/1] extcon: ext-usb-gpio: do not enable USB as wakeup source by default

[Chanwoo Choi]

On 2017년 02월 13일 18:21, Peter Chen wrote:
> Whether the USB port as a wakeup source should be determined by user,
> but not enabled by default.
>
> Signed-off-by: Peter Chen 
> ---
>  drivers/extcon/extcon-usb-gpio.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/extcon/extcon-usb-gpio.c 
> b/drivers/extcon/extcon-usb-gpio.c
> index a5e1882..66c749d 100644
> --- a/drivers/extcon/extcon-usb-gpio.c
> +++ b/drivers/extcon/extcon-usb-gpio.c
> @@ -195,7 +195,7 @@ static int usb_extcon_probe(struct platform_device *pdev)
>   }
>  
>   platform_set_drvdata(pdev, info);
> - device_init_wakeup(dev, true);
> + device_set_wakeup_capable(>dev, true);
>  
>   /* Perform initial detection */
>   usb_extcon_detect_cable(>wq_detcable.work);

Applied it.
Thanks.

-- 
Best Regards,
Chanwoo Choi
Samsung Electronics

--
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: v4.10-rc8 (-rc6) boot regression on Intel desktop, does not boot after cold boots, boots after reboot

[Linus Torvalds]

On Wed, Feb 15, 2017 at 3:20 PM, Pavel Machek  wrote:
> 4.10-rc4 broken
> 4.10-rc3 ok

Hmm. If those actually end up being reliable, then there's not a whole
lot in between them wrt PCI or USB.

What looked like the most likely candidate seems to be xhci-specific, though.

But maybe it's something that isn't directly in drivers/{pci,usb}/ and
just interacts badly.

 Linus
--
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: v4.10-rc8 (-rc6) boot regression on Intel desktop, does not boot after cold boots, boots after reboot

[Pavel Machek]

On Wed 2017-02-15 18:23:03, Pavel Machek wrote:
> On Tue 2017-02-14 11:12:26, Linus Torvalds wrote:
> > On Feb 14, 2017 9:59 AM, "Pavel Machek"  wrote:
> > 
> > Hi!
> > 
> > > >
> > > > Booting to grub, then hitting ctrl-alt-del is enough to make it work.
> > Ouch.
> > > >
> > > > It happens with current Linus' tree.
> > >
> > > v4.10-rc6-feb3 : broken
> > > v4.9 : ok
> > 
> > I wonder if you could bisect it now that you've figured out the rules for
> > when it breaks...
> 
> I guess that's what I'll need to do. It is my main machine, so it is a
> bit painful.
> 
> Anyway, it seems that "nosmp" makes it hang at similar place, but
> makes it hang reliably, reboot or cold poweroff. So I guess that's
> what I'll use for bisection -- should be possible to do automatically
> that way.

I was mistaken. "nosmp" does not seem to make the hang reliable.

my-4.10-r8+ broken
4.10-rc8 broken
4.10-rc4 broken
4.10-rc3 ok
4.10-rc2 ok?

I started bisect, 168 revisions to go.

Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [PATCH 2/3] usb: add DT bindings for farady fotg2 host controller

[Rob Herring]

On Wed, Feb 08, 2017 at 09:00:09PM +0100, Hans Ulli Kroll wrote:
> This adds DT bindings for the Faraday FOTG2 host controller.
> 
> Signed-off-by: Hans Ulli Kroll 
> ---
>  Documentation/devicetree/bindings/usb/fotg2-host.txt | 15 +++
>  1 file changed, 15 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/usb/fotg2-host.txt
> 
> diff --git a/Documentation/devicetree/bindings/usb/fotg2-host.txt 
> b/Documentation/devicetree/bindings/usb/fotg2-host.txt
> new file mode 100644
> index ..4c07566a4bf5
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/usb/fotg2-host.txt
> @@ -0,0 +1,15 @@
> +Faraday FOTG Host controller
> +
> +Required properties:
> +
> +- compatible: should be "faraday,fotg210-hcd"

hcd as in "host controller driver"? Bindings describe h/w not drivers.

It's an OTG controller or host controller?

> +- reg: should contain one register range i.e. start and length
> +- interrupts: description of the interrupt line
> +
> +Example for Gemini:
> +
> +usb@6800 {
> + compatible = "faraday,fotg210-hcd";
> + reg = <0x6800 0x1000>;
> + interrupts = <10 IRQ_TYPE_LEVEL_HIGH>;
> +};
> -- 
> 2.11.0
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/3] DT: add Faraday Tec. as vendor

[Rob Herring]

On Sun, Feb 12, 2017 at 09:37:37PM +0100, Linus Walleij wrote:
> On Wed, Feb 8, 2017 at 9:00 PM, Hans Ulli Kroll
>  wrote:
> 
> > add Faraday Technology Corporation as vendor faraday for DT
> >
> > Signed-off-by: Hans Ulli Kroll 
> 
> I realized a lot of Gemini IP blocks are actually from Faraday, so now
> I'm editing the drivers a bit...
> 
> Rob could you pick this patch directly to the DT tree so we need
> not worry about the vendor thing?

Done.

Rob
--
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: v4.10-rc8 (-rc6) boot regression on Intel desktop, does not boot after cold boots, boots after reboot

[Pavel Machek]

On Tue 2017-02-14 11:12:26, Linus Torvalds wrote:
> On Feb 14, 2017 9:59 AM, "Pavel Machek"  wrote:
> 
> Hi!
> 
> > >
> > > Booting to grub, then hitting ctrl-alt-del is enough to make it work.
> Ouch.
> > >
> > > It happens with current Linus' tree.
> >
> > v4.10-rc6-feb3 : broken
> > v4.9 : ok
> 
> I wonder if you could bisect it now that you've figured out the rules for
> when it breaks...

I guess that's what I'll need to do. It is my main machine, so it is a
bit painful.

Anyway, it seems that "nosmp" makes it hang at similar place, but
makes it hang reliably, reboot or cold poweroff. So I guess that's
what I'll use for bisection -- should be possible to do automatically
that way.

> I don't think I've seen any similar reports, so we don't have a lot of
> clues to go by otherwise, I think.

:-(.
Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [PATCH 2/2] USB: serial: keyspan: drop header file

[Johan Hovold]

On Wed, Feb 15, 2017 at 06:39:52AM -0800, Greg Kroah-Hartman wrote:
> On Wed, Feb 15, 2017 at 11:09:51AM +0100, Johan Hovold wrote:
> > Move all declarations and definitions in keyspan.h to keyspan.c, which
> > is the only place were they are used.
> > 
> > This specifically moves the driver device-id tables and usb-serial
> > driver definitions to the source file where they are expected to be
> > found.
> > 
> > While at it, fix up some multi-line comments and minor white-space
> > issues (spaces instead of tabs and superfluous white space).
> > 
> > Note that the information in the comment header of the removed header
> > file is also present in the source file.
> > 
> > Signed-off-by: Johan Hovold 
> 
> Reviewed-by: Greg Kroah-Hartman 

Thanks for the review, both patches now applied.

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

Re: Periodic reconnects of USB mouse on Dell PowerEdge R730

[Johan Hovold]

On Wed, Feb 15, 2017 at 03:31:28PM +0100, Oliver Neukum wrote:
> Am Mittwoch, den 08.02.2017, 17:54 +0100 schrieb Johan Hovold:
> > > Also, I am unable to reproduce this problem with the *same* mice on
> > a 
> > > laptop with a USB3 – it’s blue – port.
> > 
> > Ok, then the quirk is probably not the right solution (even if it
> > could
> > possibly help with the disconnects).
> 
> An assumption of consistency in buggy firmware is rather bold.
> The behavior otherwise really looks like the device needs the quirk.

Heh. Yeah, I agree it's a bit of a long shot, but the first set of
reported symptoms do indeed look familiar.

Did you ever see a change in the repeated-disconnect behaviour depending
on the HCD for any of the device you enabled the always-poll quirk for?

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

Re: [usb-storage] [PATCH] usb: storage: add missing pre-increment to variable

[Alan Stern]

On Wed, 15 Feb 2017, Gustavo A. R. Silva wrote:

> Add missing pre-increment to 'waitcount' variable used in do-while loop.
> 
> Addresses-Coverity-ID: 1011631
> Signed-off-by: Gustavo A. R. Silva 
> ---
>  drivers/usb/storage/jumpshot.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/storage/jumpshot.c b/drivers/usb/storage/jumpshot.c
> index 011e527..a26c4bb 100644
> --- a/drivers/usb/storage/jumpshot.c
> +++ b/drivers/usb/storage/jumpshot.c
> @@ -313,7 +313,7 @@ static int jumpshot_write_data(struct us_data *us,
>   //
>   msleep(50); 
>   }
> - } while ((result != USB_STOR_TRANSPORT_GOOD) && (waitcount < 
> 10));
> + } while ((result != USB_STOR_TRANSPORT_GOOD) && (++waitcount < 
> 10));
>  
>   if (result != USB_STOR_TRANSPORT_GOOD)
>   usb_stor_dbg(us, "Gah!  Waitcount = 10.  Bad 
> write!?\n");
> 

This has already been reported and fixed.  See

http://marc.info/?l=linux-usb=148604164024557=2

Alan Stern

--
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/3] usb: dwc3: use BIT() macro where possible

[Roger Quadros]

On 15/02/17 13:44, Felipe Balbi wrote:
> 
> Hi,
> 
> Roger Quadros  writes:
>> To avoid checkpatch warnings with new patches let's
>> start using the BIT() macro wherever possible.
>>
>> Signed-off-by: Roger Quadros 
>> ---
>>  drivers/usb/dwc3/core.h  | 192 
>> +--
>>  drivers/usb/dwc3/dwc3-omap.c |  48 +--
>>  drivers/usb/dwc3/gadget.h|  20 ++---
>>  3 files changed, 130 insertions(+), 130 deletions(-)
>>
>> diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
>> index 14b7602..d514dca 100644
>> --- a/drivers/usb/dwc3/core.h
>> +++ b/drivers/usb/dwc3/core.h
>> @@ -65,7 +65,7 @@
>>  #define DWC3_DEVICE_EVENT_OVERFLOW  11
>>  
>>  #define DWC3_GEVNTCOUNT_MASK0xfffc
>> -#define DWC3_GEVNTCOUNT_EHB (1 << 31)
>> +#define DWC3_GEVNTCOUNT_EHB BIT(31)
> 
> don't you need to include  for this?
> 

I didn't get any build errors though.

-- 
cheers,
-roger
--
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: serial: keyspan: drop header file

[Greg KH]

On Wed, Feb 15, 2017 at 11:09:51AM +0100, Johan Hovold wrote:
> Move all declarations and definitions in keyspan.h to keyspan.c, which
> is the only place were they are used.
> 
> This specifically moves the driver device-id tables and usb-serial
> driver definitions to the source file where they are expected to be
> found.
> 
> While at it, fix up some multi-line comments and minor white-space
> issues (spaces instead of tabs and superfluous white space).
> 
> Note that the information in the comment header of the removed header
> file is also present in the source file.
> 
> Signed-off-by: Johan Hovold 

Reviewed-by: Greg Kroah-Hartman 
--
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: serial: io_edgeport: drop io-tables header file

[Greg KH]

On Wed, Feb 15, 2017 at 11:09:50AM +0100, Johan Hovold wrote:
> Move the driver device-id tables and usb-serial driver definitions to
> the source file where they are expected to be found.
> 
> Signed-off-by: Johan Hovold 

Reviewed-by: Greg Kroah-Hartman 
--
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: Periodic reconnects of USB mouse on Dell PowerEdge R730

[Oliver Neukum]

Am Mittwoch, den 08.02.2017, 17:54 +0100 schrieb Johan Hovold:
> > Also, I am unable to reproduce this problem with the *same* mice on
> a 
> > laptop with a USB3 – it’s blue – port.
> 
> Ok, then the quirk is probably not the right solution (even if it
> could
> possibly help with the disconnects).

An assumption of consistency in buggy firmware is rather bold.
The behavior otherwise really looks like the device needs the quirk.

Regards
Oliver

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

[PATCH v6 0/4] usb: musb: da8xx: Add DMA support

[Alexandre Bailon]

This series update MUSB driver to add DMA support to DA8xx.
It should be applied on top of:
"[PATCH v4 0/3] dmaengine: cppi41: Add dma support to da8xx" and
"[PATCH v3] ARM: davinci: Make the usb20 clock available to PM runtime"

Changes in v6:
- Rebased on linux-next. Some patches were conflicting with a series
  adding suspend and resume support.

Changes in v5:
- Fix a typo in commit message of patch 4

Changes in v4:
- Update and clarify the commit message of patch 5
- Fix the typo in patch 3

Changes in v3:
- Remove PM runtime callbacks.
  I have update arch/arm/mach-davinci/pm_domain.c to let PM runtime control
  the usb20 clock.
- Only use PM runtime sync operation.

Changes in v2:
- Clock and IRQ management has been moved to MUSB DA8xx glue
  (was in CPPI 4.1 driver)
- I have added a partial support PM runtime. The goal was to use PM
  runtime to manage clock of MUSB and CPPI 4.1 (they use the same clock).
- CPPI 4.1 is now achild of MUSB DA8xx glue.

Alexandre Bailon (4):
  usb: musb: Use shared irq
  usb: musb: Add support of CPPI 4.1 DMA controller to DA8xx
  usb: musb: musb_cppi41: Workaround DMA stall issue during teardown
  usb: musb: da8xx: Add a primary support of PM runtime

 drivers/usb/musb/Kconfig   |  4 +--
 drivers/usb/musb/da8xx.c   | 63 --
 drivers/usb/musb/musb_core.c   |  2 +-
 drivers/usb/musb/musb_core.h   |  1 +
 drivers/usb/musb/musb_cppi41.c |  4 +++
 5 files changed, 51 insertions(+), 23 deletions(-)

-- 
2.10.2

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

[PATCH v6 4/4] usb: musb: da8xx: Add a primary support of PM runtime

[Alexandre Bailon]

Currently, MUSB DA8xx glue driver doesn't have PM runtime support.
Because the CPPI 4.1 is using the same clock as MUSB DA8xx and
CPPI 4.1 is a child of MUSB DA8xx glue, add support of PM runtime
to the DA8xx glue driver in order to let the CPPI 4.1 driver manage
the clock by using PM runtime.

Signed-off-by: Alexandre Bailon 
---
 drivers/usb/musb/da8xx.c | 27 ---
 1 file changed, 8 insertions(+), 19 deletions(-)

diff --git a/drivers/usb/musb/da8xx.c b/drivers/usb/musb/da8xx.c
index ed28afd..89e12f6 100644
--- a/drivers/usb/musb/da8xx.c
+++ b/drivers/usb/musb/da8xx.c
@@ -30,7 +30,6 @@
  */
 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -86,7 +85,6 @@ struct da8xx_glue {
struct device   *dev;
struct platform_device  *musb;
struct platform_device  *usb_phy;
-   struct clk  *clk;
struct phy  *phy;
 };
 
@@ -376,11 +374,7 @@ static int da8xx_musb_init(struct musb *musb)
 
musb->mregs += DA8XX_MENTOR_CORE_OFFSET;
 
-   ret = clk_prepare_enable(glue->clk);
-   if (ret) {
-   dev_err(glue->dev, "failed to enable clock\n");
-   return ret;
-   }
+   pm_runtime_get_sync(musb->controller->parent);
 
/* Returns zero if e.g. not clocked */
rev = musb_readl(reg_base, DA8XX_USB_REVISION_REG);
@@ -423,7 +417,7 @@ static int da8xx_musb_init(struct musb *musb)
 err_phy_power_on:
phy_exit(glue->phy);
 fail:
-   clk_disable_unprepare(glue->clk);
+   pm_runtime_put(musb->controller->parent);
return ret;
 }
 
@@ -435,7 +429,7 @@ static int da8xx_musb_exit(struct musb *musb)
 
phy_power_off(glue->phy);
phy_exit(glue->phy);
-   clk_disable_unprepare(glue->clk);
+   pm_runtime_put(musb->controller->parent);
 
usb_put_phy(musb->xceiv);
 
@@ -519,7 +513,6 @@ static int da8xx_probe(struct platform_device *pdev)
struct musb_hdrc_platform_data  *pdata = dev_get_platdata(>dev);
struct da8xx_glue   *glue;
struct platform_device_info pinfo;
-   struct clk  *clk;
struct device_node  *np = pdev->dev.of_node;
int ret;
 
@@ -527,12 +520,6 @@ static int da8xx_probe(struct platform_device *pdev)
if (!glue)
return -ENOMEM;
 
-   clk = devm_clk_get(>dev, "usb20");
-   if (IS_ERR(clk)) {
-   dev_err(>dev, "failed to get clock\n");
-   return PTR_ERR(clk);
-   }
-
glue->phy = devm_phy_get(>dev, "usb-phy");
if (IS_ERR(glue->phy)) {
if (PTR_ERR(glue->phy) != -EPROBE_DEFER)
@@ -541,7 +528,6 @@ static int da8xx_probe(struct platform_device *pdev)
}
 
glue->dev   = >dev;
-   glue->clk   = clk;
 
if (IS_ENABLED(CONFIG_OF) && np) {
pdata = devm_kzalloc(>dev, sizeof(*pdata), GFP_KERNEL);
@@ -587,6 +573,8 @@ static int da8xx_probe(struct platform_device *pdev)
pinfo.data = pdata;
pinfo.size_data = sizeof(*pdata);
 
+   pm_runtime_enable(>dev);
+
glue->musb = platform_device_register_full();
ret = PTR_ERR_OR_ZERO(glue->musb);
if (ret) {
@@ -603,6 +591,7 @@ static int da8xx_remove(struct platform_device *pdev)
 
platform_device_unregister(glue->musb);
usb_phy_generic_unregister(glue->usb_phy);
+   pm_runtime_disable(>dev);
 
return 0;
 }
@@ -616,7 +605,7 @@ static int da8xx_suspend(struct device *dev)
ret = phy_power_off(glue->phy);
if (ret)
return ret;
-   clk_disable_unprepare(glue->clk);
+   pm_runtime_put_sync(dev);
 
return 0;
 }
@@ -626,7 +615,7 @@ static int da8xx_resume(struct device *dev)
int ret;
struct da8xx_glue *glue = dev_get_drvdata(dev);
 
-   ret = clk_prepare_enable(glue->clk);
+   ret = pm_runtime_get_sync(dev);
if (ret)
return ret;
return phy_power_on(glue->phy);
-- 
2.10.2

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

[PATCH v6 3/4] usb: musb: musb_cppi41: Workaround DMA stall issue during teardown

[Alexandre Bailon]

The DMA may hang up if a teardown is initiated while an endpoint is still
active (Advisory 2.3.27 of DA8xx errata).
To workaround this issue, add a delay before to initiate the teardown.

Signed-off-by: Alexandre Bailon 
---
 drivers/usb/musb/da8xx.c   | 2 +-
 drivers/usb/musb/musb_core.h   | 1 +
 drivers/usb/musb/musb_cppi41.c | 4 
 3 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/musb/da8xx.c b/drivers/usb/musb/da8xx.c
index 458a499..ed28afd 100644
--- a/drivers/usb/musb/da8xx.c
+++ b/drivers/usb/musb/da8xx.c
@@ -483,7 +483,7 @@ da8xx_dma_controller_create(struct musb *musb, void __iomem 
*base)
 
 static const struct musb_platform_ops da8xx_ops = {
.quirks = MUSB_INDEXED_EP | MUSB_PRESERVE_SESSION |
- MUSB_DMA_CPPI41,
+ MUSB_DMA_CPPI41 | MUSB_DA8XX,
.init   = da8xx_musb_init,
.exit   = da8xx_musb_exit,
 
diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index 5b708be..3e98d42 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -172,6 +172,7 @@ struct musb_io;
  */
 struct musb_platform_ops {
 
+#define MUSB_DA8XX BIT(8)
 #define MUSB_PRESERVE_SESSION  BIT(7)
 #define MUSB_DMA_UX500 BIT(6)
 #define MUSB_DMA_CPPI41BIT(5)
diff --git a/drivers/usb/musb/musb_cppi41.c b/drivers/usb/musb/musb_cppi41.c
index 00e272b..2df37be 100644
--- a/drivers/usb/musb/musb_cppi41.c
+++ b/drivers/usb/musb/musb_cppi41.c
@@ -552,6 +552,10 @@ static int cppi41_dma_channel_abort(struct dma_channel 
*channel)
}
}
 
+   /* DA8xx Advisory 2.3.27: wait 250 ms before to start the teardown */
+   if (musb->io.quirks & MUSB_DA8XX)
+   mdelay(250);
+
tdbit = 1 << cppi41_channel->port_num;
if (is_tx)
tdbit <<= 16;
-- 
2.10.2

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

[PATCH v6 1/4] usb: musb: Use shared irq

[Alexandre Bailon]

In the DA8xx, USB and CPPI 4.1 are sharing the same interrupt line.
Update the driver to request a shared irq.

Signed-off-by: Alexandre Bailon 
---
 drivers/usb/musb/musb_core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 892088f..c476265 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -2331,7 +2331,7 @@ musb_init_controller(struct device *dev, int nIrq, void 
__iomem *ctrl)
setup_timer(>otg_timer, musb_otg_timer_func, (unsigned long) 
musb);
 
/* attach to the IRQ */
-   if (request_irq(nIrq, musb->isr, 0, dev_name(dev), musb)) {
+   if (request_irq(nIrq, musb->isr, IRQF_SHARED, dev_name(dev), musb)) {
dev_err(dev, "request_irq %d failed!\n", nIrq);
status = -ENODEV;
goto fail3;
-- 
2.10.2

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

[PATCH v6 2/4] usb: musb: Add support of CPPI 4.1 DMA controller to DA8xx

[Alexandre Bailon]

Currently, only the PIO mode is supported.
This add support of CPPI 4.1 to DA8xx.
As the In DA8xx the CPPI 4.1 DMA is a part of the USB.
Create the CPPI 4.1 device as a child of USB.

Signed-off-by: Alexandre Bailon 
---
 drivers/usb/musb/Kconfig |  4 ++--
 drivers/usb/musb/da8xx.c | 36 +++-
 2 files changed, 37 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig
index 72a2a50..5506a9c 100644
--- a/drivers/usb/musb/Kconfig
+++ b/drivers/usb/musb/Kconfig
@@ -160,8 +160,8 @@ config USB_TI_CPPI_DMA
  Enable DMA transfers when TI CPPI DMA is available.
 
 config USB_TI_CPPI41_DMA
-   bool 'TI CPPI 4.1 (AM335x)'
-   depends on ARCH_OMAP && DMADEVICES
+   bool 'TI CPPI 4.1'
+   depends on (ARCH_OMAP || ARCH_DAVINCI_DA8XX) && DMADEVICES
select TI_CPPI41
 
 config USB_TUSB_OMAP_DMA
diff --git a/drivers/usb/musb/da8xx.c b/drivers/usb/musb/da8xx.c
index d79c288..458a499 100644
--- a/drivers/usb/musb/da8xx.c
+++ b/drivers/usb/musb/da8xx.c
@@ -33,6 +33,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -456,12 +457,41 @@ static inline u8 get_vbus_power(struct device *dev)
return current_uA / 1000 / 2;
 }
 
+#ifdef CONFIG_USB_TI_CPPI41_DMA
+static void da8xx_dma_controller_callback(struct dma_controller *c)
+{
+   struct musb *musb = c->musb;
+   void __iomem *reg_base = musb->ctrl_base;
+
+   musb_writel(reg_base, DA8XX_USB_END_OF_INTR_REG, 0);
+}
+
+static struct dma_controller *
+da8xx_dma_controller_create(struct musb *musb, void __iomem *base)
+{
+   struct dma_controller *controller;
+
+   controller = cppi41_dma_controller_create(musb, base);
+   if (IS_ERR_OR_NULL(controller))
+   return controller;
+
+   controller->dma_callback = da8xx_dma_controller_callback;
+
+   return controller;
+}
+#endif
+
 static const struct musb_platform_ops da8xx_ops = {
-   .quirks = MUSB_INDEXED_EP | MUSB_PRESERVE_SESSION,
+   .quirks = MUSB_INDEXED_EP | MUSB_PRESERVE_SESSION |
+ MUSB_DMA_CPPI41,
.init   = da8xx_musb_init,
.exit   = da8xx_musb_exit,
 
.fifo_mode  = 2,
+#ifdef CONFIG_USB_TI_CPPI41_DMA
+   .dma_init   = da8xx_dma_controller_create,
+   .dma_exit   = cppi41_dma_controller_destroy,
+#endif
.enable = da8xx_musb_enable,
.disable= da8xx_musb_disable,
 
@@ -533,6 +563,10 @@ static int da8xx_probe(struct platform_device *pdev)
}
platform_set_drvdata(pdev, glue);
 
+   ret = of_platform_populate(pdev->dev.of_node, NULL, NULL, >dev);
+   if (ret)
+   return ret;
+
memset(musb_resources, 0x00, sizeof(*musb_resources) *
ARRAY_SIZE(musb_resources));
 
-- 
2.10.2

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

[PATCH v5 3/5] dmaengine: cppi41: Move some constants to glue layer

[Alexandre Bailon]

Some constants are defined and use by the driver whereas they are
specifics to AM335x.
Add new variables to the glue layer, initialize them with the constants,
and use them in the driver.

Signed-off-by: Alexandre Bailon 
---
 drivers/dma/cppi41.c | 20 ++--
 1 file changed, 14 insertions(+), 6 deletions(-)

diff --git a/drivers/dma/cppi41.c b/drivers/dma/cppi41.c
index d1b5569..676228f 100644
--- a/drivers/dma/cppi41.c
+++ b/drivers/dma/cppi41.c
@@ -68,7 +68,6 @@
 #define QMGR_MEMCTRL_IDX_SH16
 #define QMGR_MEMCTRL_DESC_SH   8
 
-#define QMGR_NUM_PEND  5
 #define QMGR_PEND(x)   (0x90 + (x) * 4)
 
 #define QMGR_PENDING_SLOT_Q(x) (x / 32)
@@ -138,6 +137,8 @@ struct cppi41_dd {
const struct chan_queues *queues_rx;
const struct chan_queues *queues_tx;
struct chan_queues td_queue;
+   u16 first_completion_queue;
+   u16 qmgr_num_pend;
 
struct list_head pending;   /* Pending queued transfers */
spinlock_t lock;/* Lock for pending list */
@@ -148,7 +149,6 @@ struct cppi41_dd {
bool is_suspended;
 };
 
-#define FIST_COMPLETION_QUEUE  93
 static struct chan_queues am335x_usb_queues_tx[] = {
/* USB0 ENDP 1 */
[ 0] = { .submit = 32, .complete =  93},
@@ -226,6 +226,8 @@ struct cppi_glue_infos {
const struct chan_queues *queues_rx;
const struct chan_queues *queues_tx;
struct chan_queues td_queue;
+   u16 first_completion_queue;
+   u16 qmgr_num_pend;
 };
 
 static struct cppi41_channel *to_cpp41_chan(struct dma_chan *c)
@@ -284,19 +286,21 @@ static u32 cppi41_pop_desc(struct cppi41_dd *cdd, 
unsigned queue_num)
 static irqreturn_t cppi41_irq(int irq, void *data)
 {
struct cppi41_dd *cdd = data;
+   u16 first_completion_queue = cdd->first_completion_queue;
+   u16 qmgr_num_pend = cdd->qmgr_num_pend;
struct cppi41_channel *c;
int i;
 
-   for (i = QMGR_PENDING_SLOT_Q(FIST_COMPLETION_QUEUE); i < QMGR_NUM_PEND;
+   for (i = QMGR_PENDING_SLOT_Q(first_completion_queue); i < qmgr_num_pend;
i++) {
u32 val;
u32 q_num;
 
val = cppi_readl(cdd->qmgr_mem + QMGR_PEND(i));
-   if (i == QMGR_PENDING_SLOT_Q(FIST_COMPLETION_QUEUE) && val) {
+   if (i == QMGR_PENDING_SLOT_Q(first_completion_queue) && val) {
u32 mask;
/* set corresponding bit for completetion Q 93 */
-   mask = 1 << QMGR_PENDING_BIT_Q(FIST_COMPLETION_QUEUE);
+   mask = 1 << QMGR_PENDING_BIT_Q(first_completion_queue);
/* not set all bits for queues less than Q 93 */
mask--;
/* now invert and keep only Q 93+ set */
@@ -884,7 +888,7 @@ static int init_cppi41(struct device *dev, struct cppi41_dd 
*cdd)
return -ENOMEM;
 
cppi_writel(cdd->scratch_phys, cdd->qmgr_mem + QMGR_LRAM0_BASE);
-   cppi_writel(QMGR_SCRATCH_SIZE, cdd->qmgr_mem + QMGR_LRAM_SIZE);
+   cppi_writel(TOTAL_DESCS_NUM, cdd->qmgr_mem + QMGR_LRAM_SIZE);
cppi_writel(0, cdd->qmgr_mem + QMGR_LRAM1_BASE);
 
ret = init_descs(dev, cdd);
@@ -967,6 +971,8 @@ static const struct cppi_glue_infos am335x_usb_infos = {
.queues_rx = am335x_usb_queues_rx,
.queues_tx = am335x_usb_queues_tx,
.td_queue = { .submit = 31, .complete = 0 },
+   .first_completion_queue = 93,
+   .qmgr_num_pend = 5,
 };
 
 static const struct of_device_id cppi41_dma_ids[] = {
@@ -1049,6 +1055,8 @@ static int cppi41_dma_probe(struct platform_device *pdev)
cdd->queues_rx = glue_info->queues_rx;
cdd->queues_tx = glue_info->queues_tx;
cdd->td_queue = glue_info->td_queue;
+   cdd->qmgr_num_pend = glue_info->qmgr_num_pend;
+   cdd->first_completion_queue = glue_info->first_completion_queue;
 
ret = init_cppi41(dev, cdd);
if (ret)
-- 
2.10.2

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

[PATCH v5 2/5] dmaengine: cppi41: rename platform variables

[Alexandre Bailon]

Currently, only the AM335x is supported by the driver.
Though the driver has a glue layer to support different platforms,
some platform variable names are not prefixed with the platform name.
To facilitate the addition of a new platform,
rename some variables owned by the AM335x glue.

Signed-off-by: Alexandre Bailon 
---
 drivers/dma/cppi41.c | 17 +
 1 file changed, 9 insertions(+), 8 deletions(-)

diff --git a/drivers/dma/cppi41.c b/drivers/dma/cppi41.c
index 34a8156..d1b5569 100644
--- a/drivers/dma/cppi41.c
+++ b/drivers/dma/cppi41.c
@@ -149,7 +149,7 @@ struct cppi41_dd {
 };
 
 #define FIST_COMPLETION_QUEUE  93
-static struct chan_queues usb_queues_tx[] = {
+static struct chan_queues am335x_usb_queues_tx[] = {
/* USB0 ENDP 1 */
[ 0] = { .submit = 32, .complete =  93},
[ 1] = { .submit = 34, .complete =  94},
@@ -185,7 +185,7 @@ static struct chan_queues usb_queues_tx[] = {
[29] = { .submit = 90, .complete = 139},
 };
 
-static const struct chan_queues usb_queues_rx[] = {
+static const struct chan_queues am335x_usb_queues_rx[] = {
/* USB0 ENDP 1 */
[ 0] = { .submit =  1, .complete = 109},
[ 1] = { .submit =  2, .complete = 110},
@@ -932,8 +932,9 @@ static bool cpp41_dma_filter_fn(struct dma_chan *chan, void 
*param)
else
queues = cdd->queues_rx;
 
-   BUILD_BUG_ON(ARRAY_SIZE(usb_queues_rx) != ARRAY_SIZE(usb_queues_tx));
-   if (WARN_ON(cchan->port_num > ARRAY_SIZE(usb_queues_rx)))
+   BUILD_BUG_ON(ARRAY_SIZE(am335x_usb_queues_rx) !=
+ARRAY_SIZE(am335x_usb_queues_tx));
+   if (WARN_ON(cchan->port_num > ARRAY_SIZE(am335x_usb_queues_rx)))
return false;
 
cchan->q_num = queues[cchan->port_num].submit;
@@ -961,15 +962,15 @@ static struct dma_chan *cppi41_dma_xlate(struct 
of_phandle_args *dma_spec,
_spec->args[0]);
 }
 
-static const struct cppi_glue_infos usb_infos = {
+static const struct cppi_glue_infos am335x_usb_infos = {
.isr = cppi41_irq,
-   .queues_rx = usb_queues_rx,
-   .queues_tx = usb_queues_tx,
+   .queues_rx = am335x_usb_queues_rx,
+   .queues_tx = am335x_usb_queues_tx,
.td_queue = { .submit = 31, .complete = 0 },
 };
 
 static const struct of_device_id cppi41_dma_ids[] = {
-   { .compatible = "ti,am3359-cppi41", .data = _infos},
+   { .compatible = "ti,am3359-cppi41", .data = _usb_infos},
{},
 };
 MODULE_DEVICE_TABLE(of, cppi41_dma_ids);
-- 
2.10.2

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

[PATCH v5 4/5] dmaengine: cppi41: init_sched(): Get number of channels from DT

[Alexandre Bailon]

Despite the driver is already using DT to get the number of channels,
init_sched() is using an hardcoded value to get it.
Use DT to get the number of channels.

Signed-off-by: Alexandre Bailon 
---
 drivers/dma/cppi41.c | 20 
 1 file changed, 12 insertions(+), 8 deletions(-)

diff --git a/drivers/dma/cppi41.c b/drivers/dma/cppi41.c
index 676228f..54337cd 100644
--- a/drivers/dma/cppi41.c
+++ b/drivers/dma/cppi41.c
@@ -139,6 +139,8 @@ struct cppi41_dd {
struct chan_queues td_queue;
u16 first_completion_queue;
u16 qmgr_num_pend;
+   u32 n_chans;
+   u8 platform;
 
struct list_head pending;   /* Pending queued transfers */
spinlock_t lock;/* Lock for pending list */
@@ -742,13 +744,8 @@ static int cppi41_add_chans(struct device *dev, struct 
cppi41_dd *cdd)
 {
struct cppi41_channel *cchan;
int i;
-   int ret;
-   u32 n_chans;
+   u32 n_chans = cdd->n_chans;
 
-   ret = of_property_read_u32(dev->of_node, "#dma-channels",
-   _chans);
-   if (ret)
-   return ret;
/*
 * The channels can only be used as TX or as RX. So we add twice
 * that much dma channels because USB can only do RX or TX.
@@ -862,7 +859,7 @@ static void init_sched(struct cppi41_dd *cdd)
 
word = 0;
cppi_writel(0, cdd->sched_mem + DMA_SCHED_CTRL);
-   for (ch = 0; ch < 15 * 2; ch += 2) {
+   for (ch = 0; ch < cdd->n_chans; ch += 2) {
 
reg = SCHED_ENTRY0_CHAN(ch);
reg |= SCHED_ENTRY1_CHAN(ch) | SCHED_ENTRY1_IS_RX;
@@ -872,7 +869,7 @@ static void init_sched(struct cppi41_dd *cdd)
cppi_writel(reg, cdd->sched_mem + DMA_SCHED_WORD(word));
word++;
}
-   reg = 15 * 2 * 2 - 1;
+   reg = cdd->n_chans * 2 - 1;
reg |= DMA_SCHED_CTRL_EN;
cppi_writel(reg, cdd->sched_mem + DMA_SCHED_CTRL);
 }
@@ -897,6 +894,7 @@ static int init_cppi41(struct device *dev, struct cppi41_dd 
*cdd)
 
cppi_writel(cdd->td_queue.submit, cdd->ctrl_mem + DMA_TDFDQ);
init_sched(cdd);
+
return 0;
 err_td:
deinit_cppi41(dev, cdd);
@@ -1058,6 +1056,11 @@ static int cppi41_dma_probe(struct platform_device *pdev)
cdd->qmgr_num_pend = glue_info->qmgr_num_pend;
cdd->first_completion_queue = glue_info->first_completion_queue;
 
+   ret = of_property_read_u32(dev->of_node,
+  "#dma-channels", >n_chans);
+   if (ret)
+   goto err_get_n_chans;
+
ret = init_cppi41(dev, cdd);
if (ret)
goto err_init_cppi;
@@ -1100,6 +1103,7 @@ static int cppi41_dma_probe(struct platform_device *pdev)
deinit_cppi41(dev, cdd);
 err_init_cppi:
pm_runtime_dont_use_autosuspend(dev);
+err_get_n_chans:
 err_get_sync:
pm_runtime_put_sync(dev);
pm_runtime_disable(dev);
-- 
2.10.2

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

[PATCH v5 0/5] dmaengine: cppi41: Make CPPI 4.1 driver more generic

[Alexandre Bailon]

This series intend to make the CPPI 4.1 more generic in order to
add a new platform (the DA8xx).
To achieve that, all the IRQ code present in CPPI 4.1 driver has been moved
to MUSB DSPS driver.
Other changes mainly update the glue layer and platform code to make the
whole driver more generic.

Changes in v5:
 - Rebase on linux-next
 - No dependencies on other series anymore (they have been applied)

Changes in v4:
 - Remove dev argument in patch 4
 - Remove the isr callback from glue

Changes in v3:
- To prevent build error report from kbuild test robot, move the first
  patch of v2 to another patchset.
- Make CPPI 4.1 driver compatible with old and new binddings.
- Remove the patch updating the am33xx-usb binddings.
- Remove useless changes in patch 4
- Remove a patch that was fixing PM runtime issue that was happenning
  during a teardown. Tony Lindgren's patches fix the issue.

Alexandre Bailon (5):
  dmaengine: cppi41: Remove usbss_mem
  dmaengine: cppi41: rename platform variables
  dmaengine: cppi41: Move some constants to glue layer
  dmaengine: cppi41: init_sched(): Get number of channels from DT
  dmaengine: cppi41: Remove isr callback from glue layer

 drivers/dma/cppi41.c | 79 ++--
 1 file changed, 46 insertions(+), 33 deletions(-)

-- 
2.10.2

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

[PATCH v5 5/5] dmaengine: cppi41: Remove isr callback from glue layer

[Alexandre Bailon]

All the platform code to manage IRQ has been moved to MUSB,
and now the interrupt handler is completely generic.
Remove the isr callback that is not useful anymore.

Signed-off-by: Alexandre Bailon 
---
 drivers/dma/cppi41.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/dma/cppi41.c b/drivers/dma/cppi41.c
index 54337cd..4573080 100644
--- a/drivers/dma/cppi41.c
+++ b/drivers/dma/cppi41.c
@@ -224,7 +224,6 @@ static const struct chan_queues am335x_usb_queues_rx[] = {
 };
 
 struct cppi_glue_infos {
-   irqreturn_t (*isr)(int irq, void *data);
const struct chan_queues *queues_rx;
const struct chan_queues *queues_tx;
struct chan_queues td_queue;
@@ -965,7 +964,6 @@ static struct dma_chan *cppi41_dma_xlate(struct 
of_phandle_args *dma_spec,
 }
 
 static const struct cppi_glue_infos am335x_usb_infos = {
-   .isr = cppi41_irq,
.queues_rx = am335x_usb_queues_rx,
.queues_tx = am335x_usb_queues_tx,
.td_queue = { .submit = 31, .complete = 0 },
@@ -1075,7 +1073,7 @@ static int cppi41_dma_probe(struct platform_device *pdev)
goto err_irq;
}
 
-   ret = devm_request_irq(>dev, irq, glue_info->isr, IRQF_SHARED,
+   ret = devm_request_irq(>dev, irq, cppi41_irq, IRQF_SHARED,
dev_name(dev), cdd);
if (ret)
goto err_irq;
-- 
2.10.2

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

[PATCH] usb: add CONFIG_USB_PCI for system have both PCI HW and non-PCI based USB HW

[yuan linyu]

From: yuan linyu 

a lot of embeded system SOC (e.g. freescale T2080) have both
PCI and USB modules. But USB module is controlled by registers directly,
it have no relationship with PCI module.

when say N here it will not build PCI related code in USB driver.

Cc: Alan Stern 
Signed-off-by: yuan linyu 
---
 drivers/usb/Kconfig| 12 +++-
 drivers/usb/Makefile   |  2 +-
 drivers/usb/chipidea/Kconfig   |  2 +-
 drivers/usb/core/Makefile  |  2 +-
 drivers/usb/dwc2/Kconfig   |  2 +-
 drivers/usb/dwc3/Kconfig   |  2 +-
 drivers/usb/gadget/udc/Kconfig |  8 
 drivers/usb/gadget/udc/bdc/Kconfig |  2 +-
 drivers/usb/gadget/udc/net2272.c   |  8 
 drivers/usb/gadget/udc/net2272.h   |  2 +-
 drivers/usb/host/Kconfig   | 10 +-
 drivers/usb/host/ehci-dbg.c|  2 +-
 drivers/usb/host/ohci-hcd.c|  2 +-
 drivers/usb/host/ohci.h|  2 +-
 drivers/usb/host/pci-quirks.h  |  4 ++--
 drivers/usb/host/uhci-hcd.c|  2 +-
 drivers/usb/host/uhci-hcd.h|  2 +-
 drivers/usb/host/xhci.c|  2 +-
 drivers/usb/isp1760/isp1760-if.c   |  8 
 include/linux/usb/hcd.h|  4 ++--
 20 files changed, 45 insertions(+), 35 deletions(-)

diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig
index fbe493d..8578b94 100644
--- a/drivers/usb/Kconfig
+++ b/drivers/usb/Kconfig
@@ -35,7 +35,6 @@ config USB_COMMON
 config USB_ARCH_HAS_HCD
def_bool y
 
-# ARM SA chips have a non-PCI based "OHCI-compatible" USB host interface.
 config USB
tristate "Support for Host-side USB"
depends on USB_ARCH_HAS_HCD
@@ -73,6 +72,17 @@ config USB
  To compile this driver as a module, choose M here: the
  module will be called usbcore.
 
+config USB_PCI
+   bool "PCI based USB host interface"
+   depends on PCI
+   default y
+   ---help---
+ a lot of embeded system SOC (e.g. freescale T2080) have both
+ PCI and USB modules. But USB module is controlled by registers 
directly,
+ it have no relationship with PCI module.
+
+ when say N here it will  not build PCI related code in USB driver.
+
 if USB
 
 source "drivers/usb/core/Kconfig"
diff --git a/drivers/usb/Makefile b/drivers/usb/Makefile
index 7791af6..4e1cf09 100644
--- a/drivers/usb/Makefile
+++ b/drivers/usb/Makefile
@@ -14,7 +14,7 @@ obj-$(CONFIG_USB_ISP1760) += isp1760/
 obj-$(CONFIG_USB_MON)  += mon/
 obj-$(CONFIG_USB_MTU3) += mtu3/
 
-obj-$(CONFIG_PCI)  += host/
+obj-$(CONFIG_USB_PCI)  += host/
 obj-$(CONFIG_USB_EHCI_HCD) += host/
 obj-$(CONFIG_USB_ISP116X_HCD)  += host/
 obj-$(CONFIG_USB_OHCI_HCD) += host/
diff --git a/drivers/usb/chipidea/Kconfig b/drivers/usb/chipidea/Kconfig
index 5e5b9eb..7e915a8 100644
--- a/drivers/usb/chipidea/Kconfig
+++ b/drivers/usb/chipidea/Kconfig
@@ -19,7 +19,7 @@ config USB_CHIPIDEA_OF
 
 config USB_CHIPIDEA_PCI
tristate
-   depends on PCI
+   depends on USB_PCI
depends on NOP_USB_XCEIV
default USB_CHIPIDEA
 
diff --git a/drivers/usb/core/Makefile b/drivers/usb/core/Makefile
index b99b871..250ec1d 100644
--- a/drivers/usb/core/Makefile
+++ b/drivers/usb/core/Makefile
@@ -8,7 +8,7 @@ usbcore-y += devio.o notify.o generic.o quirks.o devices.o
 usbcore-y += port.o
 
 usbcore-$(CONFIG_OF)   += of.o
-usbcore-$(CONFIG_PCI)  += hcd-pci.o
+usbcore-$(CONFIG_USB_PCI)  += hcd-pci.o
 usbcore-$(CONFIG_ACPI) += usb-acpi.o
 
 obj-$(CONFIG_USB)  += usbcore.o
diff --git a/drivers/usb/dwc2/Kconfig b/drivers/usb/dwc2/Kconfig
index e838701..b6a495e 100644
--- a/drivers/usb/dwc2/Kconfig
+++ b/drivers/usb/dwc2/Kconfig
@@ -54,7 +54,7 @@ endchoice
 
 config USB_DWC2_PCI
tristate "DWC2 PCI"
-   depends on PCI
+   depends on USB_PCI
depends on USB_GADGET || !USB_GADGET
default n
select NOP_USB_XCEIV
diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
index c5aa235..4c9e56d 100644
--- a/drivers/usb/dwc3/Kconfig
+++ b/drivers/usb/dwc3/Kconfig
@@ -70,7 +70,7 @@ config USB_DWC3_EXYNOS
 
 config USB_DWC3_PCI
tristate "PCIe-based Platforms"
-   depends on PCI && ACPI
+   depends on USB_PCI && ACPI
default USB_DWC3
help
  If you're using the DesignWare Core IP with a PCIe, please say
diff --git a/drivers/usb/gadget/udc/Kconfig b/drivers/usb/gadget/udc/Kconfig
index 658b8da..5761767 100644
--- a/drivers/usb/gadget/udc/Kconfig
+++ b/drivers/usb/gadget/udc/Kconfig
@@ -263,7 +263,7 @@ source "drivers/usb/gadget/udc/bdc/Kconfig"
 
 config USB_AMD5536UDC
tristate "AMD5536 UDC"
-   depends on PCI
+   depends on USB_PCI
help
   The AMD5536 UDC is part of the AMD Geode CS5536, an x86 southbridge.
   It is a USB 

[PATCH] usb: dwc3: gadget: Fix system suspend/resume on TI platforms

[Roger Quadros]

On TI platforms (dra7, am437x), the DWC3_DSTS_DEVCTRLHLT bit is not set
after the device controller is stopped via DWC3_DCTL_RUN_STOP.

If we don't disconnect and stop the gadget, it stops working after a
system resume with the trace below.

There is no point in preventing gadget disconnect and gadget stop during
system suspend/resume as we're going to suspend in any case, whether
DEVCTRLHLT timed out or not.

[  141.727480] [ cut here ]
[  141.732349] WARNING: CPU: 1 PID: 2135 at drivers/usb/dwc3/gadget.c:2384 
dwc3_stop_active_transfer.constprop.4+0xc4/0xe4 [dwc3]
[  141.744299] Modules linked in: usb_f_ss_lb g_zero libcomposite xhci_plat_hcd 
xhci_hcd usbcore dwc3 evdev udc_core m25p80 usb_common spi_nor 
snd_soc_davinci_mcasp snd_soc_simple_card snd_soc_edma snd_soc_tlv3e
[  141.792163] CPU: 1 PID: 2135 Comm: irq/456-dwc3 Not tainted 4.10.0-rc8 #1138
[  141.799547] Hardware name: Generic DRA74X (Flattened Device Tree)
[  141.805940] [] (unwind_backtrace) from [] 
(show_stack+0x10/0x14)
[  141.814066] [] (show_stack) from [] 
(dump_stack+0xac/0xe0)
[  141.821648] [] (dump_stack) from [] (__warn+0xd8/0x104)
[  141.828955] [] (__warn) from [] 
(warn_slowpath_null+0x20/0x28)
[  141.836902] [] (warn_slowpath_null) from [] 
(dwc3_stop_active_transfer.constprop.4+0xc4/0xe4 [dwc3])
[  141.848329] [] (dwc3_stop_active_transfer.constprop.4 [dwc3]) from 
[] (__dwc3_gadget_ep_disable+0x64/0x528 [dwc3])
[  141.861034] [] (__dwc3_gadget_ep_disable [dwc3]) from [] 
(dwc3_gadget_ep_disable+0x3c/0xc8 [dwc3])
[  141.872280] [] (dwc3_gadget_ep_disable [dwc3]) from [] 
(usb_ep_disable+0x11c/0x18c [udc_core])
[  141.883160] [] (usb_ep_disable [udc_core]) from [] 
(disable_ep+0x18/0x54 [usb_f_ss_lb])
[  141.893408] [] (disable_ep [usb_f_ss_lb]) from [] 
(disable_endpoints+0x18/0x50 [usb_f_ss_lb])
[  141.904168] [] (disable_endpoints [usb_f_ss_lb]) from [] 
(disable_source_sink+0x2c/0x34 [usb_f_ss_lb])
[  141.915771] [] (disable_source_sink [usb_f_ss_lb]) from 
[] (reset_config+0x48/0x7c [libcomposite])
[  141.927012] [] (reset_config [libcomposite]) from [] 
(composite_disconnect+0x2c/0x54 [libcomposite])
[  141.938444] [] (composite_disconnect [libcomposite]) from 
[] (usb_gadget_udc_reset+0x10/0x34 [udc_core])
[  141.950237] [] (usb_gadget_udc_reset [udc_core]) from [] 
(dwc3_gadget_reset_interrupt+0x64/0x698 [dwc3])
[  141.962022] [] (dwc3_gadget_reset_interrupt [dwc3]) from 
[] (dwc3_thread_interrupt+0x618/0x1a3c [dwc3])
[  141.973723] [] (dwc3_thread_interrupt [dwc3]) from [] 
(irq_thread_fn+0x1c/0x54)
[  141.983215] [] (irq_thread_fn) from [] 
(irq_thread+0x120/0x1f0)
[  141.991247] [] (irq_thread) from [] (kthread+0xf8/0x138)
[  141.998641] [] (kthread) from [] 
(ret_from_fork+0x14/0x24)
[  142.006213] ---[ end trace b4ecfe9f175b9a9c ]---

Signed-off-by: Roger Quadros 
---
 drivers/usb/dwc3/gadget.c | 7 +--
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 204c754c..1341ed4 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -3118,15 +3118,10 @@ void dwc3_gadget_exit(struct dwc3 *dwc)
 
 int dwc3_gadget_suspend(struct dwc3 *dwc)
 {
-   int ret;
-
if (!dwc->gadget_driver)
return 0;
 
-   ret = dwc3_gadget_run_stop(dwc, false, false);
-   if (ret < 0)
-   return ret;
-
+   dwc3_gadget_run_stop(dwc, false, false);
dwc3_disconnect_gadget(dwc);
__dwc3_gadget_stop(dwc);
 
-- 
2.7.4

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

Re: [PATCH v13 06/12] usb: xhci: use bus->sysdev for DMA configuration

[Felipe Balbi]

Hi,

Roger Quadros  writes:
 Why are we using sysdev to read DT property? We should be using the
 XHCI device (>dev) here, no?
>>>
>>> If I remember correctly, this is one of the cases where pdev does not
>>> have a device node attached to it because it was created by the driver
>>> of the parent device on the fly in case of dwc3. When you have a pure 
>>> xhci
>>> device in DT, the two pointers are the same.
>>
>> From drivers/usb/dwc3/host.c
>>
>>> if (dwc->usb3_lpm_capable) {
>>> props[0].name = "usb3-lpm-capable";
>>> ret = platform_device_add_properties(xhci, props);
>>> if (ret) {
>>> dev_err(dwc->dev, "failed to add properties to 
>>> xHCI\n");
>>> goto err1;
>>> }
>>> }
>>
>> So it is setting the usb3-lpm-capable property into the xhci platform 
>> device
>> and we should be reading the property from there.

 Why dwc3 needs another "snps,usb3_lpm_capable"? Why not using
 "usb3-lpm-capable" at firmware directly?
>>>
>>> dwc3 is not setting "snps,usb3_lpm_capable" but "usb3-lpm-capable" for the
>>> xhci platform device.
>>>
>>> What did you mean by firmware? Did you mean something like BIOS?
>>> At least TI platforms don't use any firmware like BIOS. So dwc3 driver
>>> needs to create a platform device for xhci on the fly and set the DT 
>>> properties.
>>>
>> 
>> By readying code, the dwc3 calls dwc3_get_properties to set
>> dwc->usb3_lpm_capable, and at dwc3/host.c, it sets property
>> "usb3-lpm-capable" according to this flag, why not let common
>> code xhci-plat.c to get this property from sysdev which is DT
>> nodes for dwc3?
>> 
>
> Felipe, any comments?

Won't work. We have quirk flags which are based on DWC3's revision which
is not accessible by xhci-plat. Also, we can't call
device_add_property() because it's not really *adding*. It's *setting*,
meaning that we would loose all other properties.

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH 2/3] usb: dwc3: use BIT() macro where possible

[Felipe Balbi]

Hi,

Roger Quadros  writes:
> To avoid checkpatch warnings with new patches let's
> start using the BIT() macro wherever possible.
>
> Signed-off-by: Roger Quadros 
> ---
>  drivers/usb/dwc3/core.h  | 192 
> +--
>  drivers/usb/dwc3/dwc3-omap.c |  48 +--
>  drivers/usb/dwc3/gadget.h|  20 ++---
>  3 files changed, 130 insertions(+), 130 deletions(-)
>
> diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
> index 14b7602..d514dca 100644
> --- a/drivers/usb/dwc3/core.h
> +++ b/drivers/usb/dwc3/core.h
> @@ -65,7 +65,7 @@
>  #define DWC3_DEVICE_EVENT_OVERFLOW   11
>  
>  #define DWC3_GEVNTCOUNT_MASK 0xfffc
> -#define DWC3_GEVNTCOUNT_EHB  (1 << 31)
> +#define DWC3_GEVNTCOUNT_EHB  BIT(31)

don't you need to include  for this?

-- 
balbi


signature.asc
Description: PGP signature

[PATCH 3/3] usb: otg-fsm: Prevent build warning "VDBG" redefined

[Roger Quadros]

If usb/otg-fsm.h and usb/composite.h are included together
then it results in the build warning [1].

Prevent that by defining VDBG locally.

Also get rid of MPC_LOC which doesn't seem to be used
by anyone.

[1] - warning fixed by this patch:

In file included from drivers/usb/dwc3/core.h:33,
   from drivers/usb/dwc3/ep0.c:33:
   include/linux/usb/otg-fsm.h:30:1: warning: "VDBG" redefined
   In file included from drivers/usb/dwc3/ep0.c:31:
   include/linux/usb/composite.h:615:1: warning: this is the location
   of the previous definition

Signed-off-by: Roger Quadros 
Reviewed-by: Jun Li 
Acked-by: Peter Chen 
---
 drivers/usb/common/usb-otg-fsm.c |  7 +++
 drivers/usb/phy/phy-fsl-usb.c|  7 +++
 include/linux/usb/otg-fsm.h  | 15 ---
 3 files changed, 14 insertions(+), 15 deletions(-)

diff --git a/drivers/usb/common/usb-otg-fsm.c b/drivers/usb/common/usb-otg-fsm.c
index 2f537bb..b8fe31e 100644
--- a/drivers/usb/common/usb-otg-fsm.c
+++ b/drivers/usb/common/usb-otg-fsm.c
@@ -31,6 +31,13 @@
 #include 
 #include 
 
+#ifdef VERBOSE
+#define VDBG(fmt, args...) pr_debug("[%s]  " fmt, \
+__func__, ## args)
+#else
+#define VDBG(stuff...) do {} while (0)
+#endif
+
 /* Change USB protocol when there is a protocol change */
 static int otg_set_protocol(struct otg_fsm *fsm, int protocol)
 {
diff --git a/drivers/usb/phy/phy-fsl-usb.c b/drivers/usb/phy/phy-fsl-usb.c
index 94eb292..a8784ec 100644
--- a/drivers/usb/phy/phy-fsl-usb.c
+++ b/drivers/usb/phy/phy-fsl-usb.c
@@ -44,6 +44,13 @@
 
 #include "phy-fsl-usb.h"
 
+#ifdef VERBOSE
+#define VDBG(fmt, args...) pr_debug("[%s]  " fmt, \
+__func__, ## args)
+#else
+#define VDBG(stuff...) do {} while (0)
+#endif
+
 #define DRIVER_VERSION "Rev. 1.55"
 #define DRIVER_AUTHOR "Jerry Huang/Li Yang"
 #define DRIVER_DESC "Freescale USB OTG Transceiver Driver"
diff --git a/include/linux/usb/otg-fsm.h b/include/linux/usb/otg-fsm.h
index 7a03505..a0a8f87 100644
--- a/include/linux/usb/otg-fsm.h
+++ b/include/linux/usb/otg-fsm.h
@@ -21,21 +21,6 @@
 #include 
 #include 
 
-#undef VERBOSE
-
-#ifdef VERBOSE
-#define VDBG(fmt, args...) pr_debug("[%s]  " fmt , \
-__func__, ## args)
-#else
-#define VDBG(stuff...) do {} while (0)
-#endif
-
-#ifdef VERBOSE
-#define MPC_LOC printk("Current Location [%s]:[%d]\n", __FILE__, __LINE__)
-#else
-#define MPC_LOC do {} while (0)
-#endif
-
 #define PROTO_UNDEF(0)
 #define PROTO_HOST (1)
 #define PROTO_GADGET   (2)
-- 
2.7.4

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

[PATCH 1/3] usb: dwc3-omap: Fix missing break in dwc3_omap_set_mailbox()

[Roger Quadros]

We need to break from all cases if we want to treat
each one of them separately.

Reported-by: Gustavo A. R. Silva 
Fixes: d2728fb3e01f ("usb: dwc3: omap: Pass VBUS and ID events transparently")
Cc:  #v4.8+
Signed-off-by: Roger Quadros 
---
 drivers/usb/dwc3/dwc3-omap.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
index eb1b9cb..35b6351 100644
--- a/drivers/usb/dwc3/dwc3-omap.c
+++ b/drivers/usb/dwc3/dwc3-omap.c
@@ -250,6 +250,7 @@ static void dwc3_omap_set_mailbox(struct dwc3_omap *omap,
val = dwc3_omap_read_utmi_ctrl(omap);
val |= USBOTGSS_UTMI_OTG_CTRL_IDDIG;
dwc3_omap_write_utmi_ctrl(omap, val);
+   break;
 
case OMAP_DWC3_VBUS_OFF:
val = dwc3_omap_read_utmi_ctrl(omap);
-- 
2.7.4

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

[PATCH 2/3] usb: dwc3: use BIT() macro where possible

[Roger Quadros]

To avoid checkpatch warnings with new patches let's
start using the BIT() macro wherever possible.

Signed-off-by: Roger Quadros 
---
 drivers/usb/dwc3/core.h  | 192 +--
 drivers/usb/dwc3/dwc3-omap.c |  48 +--
 drivers/usb/dwc3/gadget.h|  20 ++---
 3 files changed, 130 insertions(+), 130 deletions(-)

diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 14b7602..d514dca 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -65,7 +65,7 @@
 #define DWC3_DEVICE_EVENT_OVERFLOW 11
 
 #define DWC3_GEVNTCOUNT_MASK   0xfffc
-#define DWC3_GEVNTCOUNT_EHB(1 << 31)
+#define DWC3_GEVNTCOUNT_EHBBIT(31)
 #define DWC3_GSNPSID_MASK  0x
 #define DWC3_GSNPSREV_MASK 0x
 
@@ -175,11 +175,11 @@
 /* Global RX Threshold Configuration Register */
 #define DWC3_GRXTHRCFG_MAXRXBURSTSIZE(n) (((n) & 0x1f) << 19)
 #define DWC3_GRXTHRCFG_RXPKTCNT(n) (((n) & 0xf) << 24)
-#define DWC3_GRXTHRCFG_PKTCNTSEL (1 << 29)
+#define DWC3_GRXTHRCFG_PKTCNTSEL BIT(29)
 
 /* Global Configuration Register */
 #define DWC3_GCTL_PWRDNSCALE(n)((n) << 19)
-#define DWC3_GCTL_U2RSTECN (1 << 16)
+#define DWC3_GCTL_U2RSTECN BIT(16)
 #define DWC3_GCTL_RAMCLKSEL(x) (((x) & DWC3_GCTL_CLK_MASK) << 6)
 #define DWC3_GCTL_CLK_BUS  (0)
 #define DWC3_GCTL_CLK_PIPE (1)
@@ -192,24 +192,24 @@
 #define DWC3_GCTL_PRTCAP_DEVICE2
 #define DWC3_GCTL_PRTCAP_OTG   3
 
-#define DWC3_GCTL_CORESOFTRESET(1 << 11)
-#define DWC3_GCTL_SOFITPSYNC   (1 << 10)
+#define DWC3_GCTL_CORESOFTRESETBIT(11)
+#define DWC3_GCTL_SOFITPSYNC   BIT(10)
 #define DWC3_GCTL_SCALEDOWN(n) ((n) << 4)
 #define DWC3_GCTL_SCALEDOWN_MASK   DWC3_GCTL_SCALEDOWN(3)
-#define DWC3_GCTL_DISSCRAMBLE  (1 << 3)
-#define DWC3_GCTL_U2EXIT_LFPS  (1 << 2)
-#define DWC3_GCTL_GBLHIBERNATIONEN (1 << 1)
-#define DWC3_GCTL_DSBLCLKGTNG  (1 << 0)
+#define DWC3_GCTL_DISSCRAMBLE  BIT(3)
+#define DWC3_GCTL_U2EXIT_LFPS  BIT(2)
+#define DWC3_GCTL_GBLHIBERNATIONEN BIT(1)
+#define DWC3_GCTL_DSBLCLKGTNG  BIT(0)
 
 /* Global User Control 1 Register */
-#define DWC3_GUCTL1_DEV_L1_EXIT_BY_HW  (1 << 24)
+#define DWC3_GUCTL1_DEV_L1_EXIT_BY_HW  BIT(24)
 
 /* Global USB2 PHY Configuration Register */
-#define DWC3_GUSB2PHYCFG_PHYSOFTRST(1 << 31)
-#define DWC3_GUSB2PHYCFG_U2_FREECLK_EXISTS (1 << 30)
-#define DWC3_GUSB2PHYCFG_SUSPHY(1 << 6)
-#define DWC3_GUSB2PHYCFG_ULPI_UTMI (1 << 4)
-#define DWC3_GUSB2PHYCFG_ENBLSLPM  (1 << 8)
+#define DWC3_GUSB2PHYCFG_PHYSOFTRSTBIT(31)
+#define DWC3_GUSB2PHYCFG_U2_FREECLK_EXISTS BIT(30)
+#define DWC3_GUSB2PHYCFG_SUSPHYBIT(6)
+#define DWC3_GUSB2PHYCFG_ULPI_UTMI BIT(4)
+#define DWC3_GUSB2PHYCFG_ENBLSLPM  BIT(8)
 #define DWC3_GUSB2PHYCFG_PHYIF(n)  (n << 3)
 #define DWC3_GUSB2PHYCFG_PHYIF_MASKDWC3_GUSB2PHYCFG_PHYIF(1)
 #define DWC3_GUSB2PHYCFG_USBTRDTIM(n)  (n << 10)
@@ -220,25 +220,25 @@
 #define UTMI_PHYIF_8_BIT   0
 
 /* Global USB2 PHY Vendor Control Register */
-#define DWC3_GUSB2PHYACC_NEWREGREQ (1 << 25)
-#define DWC3_GUSB2PHYACC_BUSY  (1 << 23)
-#define DWC3_GUSB2PHYACC_WRITE (1 << 22)
+#define DWC3_GUSB2PHYACC_NEWREGREQ BIT(25)
+#define DWC3_GUSB2PHYACC_BUSY  BIT(23)
+#define DWC3_GUSB2PHYACC_WRITE BIT(22)
 #define DWC3_GUSB2PHYACC_ADDR(n)   (n << 16)
 #define DWC3_GUSB2PHYACC_EXTEND_ADDR(n)(n << 8)
 #define DWC3_GUSB2PHYACC_DATA(n)   (n & 0xff)
 
 /* Global USB3 PIPE Control Register */
-#define DWC3_GUSB3PIPECTL_PHYSOFTRST   (1 << 31)
-#define DWC3_GUSB3PIPECTL_U2SSINP3OK   (1 << 29)
-#define DWC3_GUSB3PIPECTL_DISRXDETINP3 (1 << 28)
-#define DWC3_GUSB3PIPECTL_REQP1P2P3(1 << 24)
+#define DWC3_GUSB3PIPECTL_PHYSOFTRST   BIT(31)
+#define DWC3_GUSB3PIPECTL_U2SSINP3OK   BIT(29)
+#define DWC3_GUSB3PIPECTL_DISRXDETINP3 BIT(28)
+#define DWC3_GUSB3PIPECTL_REQP1P2P3BIT(24)
 #define DWC3_GUSB3PIPECTL_DEP1P2P3(n)  ((n) << 19)
 #define DWC3_GUSB3PIPECTL_DEP1P2P3_MASKDWC3_GUSB3PIPECTL_DEP1P2P3(7)
 #define DWC3_GUSB3PIPECTL_DEP1P2P3_EN  DWC3_GUSB3PIPECTL_DEP1P2P3(1)
-#define DWC3_GUSB3PIPECTL_DEPOCHANGE   (1 << 18)
-#define DWC3_GUSB3PIPECTL_SUSPHY   (1 << 17)
-#define DWC3_GUSB3PIPECTL_LFPSFILT (1 << 9)
-#define DWC3_GUSB3PIPECTL_RX_DETOPOLL  (1 << 8)
+#define DWC3_GUSB3PIPECTL_DEPOCHANGE   BIT(18)
+#define DWC3_GUSB3PIPECTL_SUSPHY   BIT(17)
+#define DWC3_GUSB3PIPECTL_LFPSFILT BIT(9)
+#define DWC3_GUSB3PIPECTL_RX_DETOPOLL  BIT(8)
 #define DWC3_GUSB3PIPECTL_TX_DEEPH_MASKDWC3_GUSB3PIPECTL_TX_DEEPH(3)
 #define DWC3_GUSB3PIPECTL_TX_DEEPH(n)  ((n) << 1)
 
@@ -247,7 +247,7 @@
 #define DWC3_GTXFIFOSIZ_TXFSTADDR(n)   ((n) & 0x)
 
 /* Global Event Size Registers */
-#define DWC3_GEVNTSIZ_INTMASK  (1 << 31)
+#define DWC3_GEVNTSIZ_INTMASK  

[PATCH 0/3] usb: dwc3: trivial fixes.

[Roger Quadros]

Hi Felipe,

These are some trivial fixes. First patch is tagged for stable.
You might want to pick it up for v4.11. Thanks.

cheers,
-roger

Roger Quadros (3):
  usb: dwc3-omap: Fix missing break in dwc3_omap_set_mailbox()
  usb: dwc3: use BIT() macro where possible
  usb: otg-fsm: Prevent build warning "VDBG" redefined

 drivers/usb/common/usb-otg-fsm.c |   7 ++
 drivers/usb/dwc3/core.h  | 192 +++
 drivers/usb/dwc3/dwc3-omap.c |  49 +-
 drivers/usb/dwc3/gadget.h|  20 ++--
 drivers/usb/phy/phy-fsl-usb.c|   7 ++
 include/linux/usb/otg-fsm.h  |  15 ---
 6 files changed, 145 insertions(+), 145 deletions(-)

-- 
2.7.4

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

[PATCH 1/2] USB: serial: io_edgeport: drop io-tables header file

[Johan Hovold]

Move the driver device-id tables and usb-serial driver definitions to
the source file where they are expected to be found.

Signed-off-by: Johan Hovold 
---
 drivers/usb/serial/io_edgeport.c | 217 +++-
 drivers/usb/serial/io_tables.h   | 232 ---
 2 files changed, 215 insertions(+), 234 deletions(-)
 delete mode 100644 drivers/usb/serial/io_tables.h

diff --git a/drivers/usb/serial/io_edgeport.c b/drivers/usb/serial/io_edgeport.c
index 92abf92e5669..bb7673e80a57 100644
--- a/drivers/usb/serial/io_edgeport.c
+++ b/drivers/usb/serial/io_edgeport.c
@@ -57,6 +57,88 @@
 
 #define OPEN_TIMEOUT   (5*HZ)  /* 5 seconds */
 
+static const struct usb_device_id edgeport_2port_id_table[] = {
+   { USB_DEVICE(USB_VENDOR_ID_ION, ION_DEVICE_ID_EDGEPORT_2) },
+   { USB_DEVICE(USB_VENDOR_ID_ION, ION_DEVICE_ID_EDGEPORT_2I) },
+   { USB_DEVICE(USB_VENDOR_ID_ION, ION_DEVICE_ID_EDGEPORT_421) },
+   { USB_DEVICE(USB_VENDOR_ID_ION, ION_DEVICE_ID_EDGEPORT_21) },
+   { USB_DEVICE(USB_VENDOR_ID_ION, ION_DEVICE_ID_EDGEPORT_2_DIN) },
+   { }
+};
+
+static const struct usb_device_id edgeport_4port_id_table[] = {
+   { USB_DEVICE(USB_VENDOR_ID_ION, ION_DEVICE_ID_EDGEPORT_4) },
+   { USB_DEVICE(USB_VENDOR_ID_ION, ION_DEVICE_ID_RAPIDPORT_4) },
+   { USB_DEVICE(USB_VENDOR_ID_ION, ION_DEVICE_ID_EDGEPORT_4T) },
+   { USB_DEVICE(USB_VENDOR_ID_ION, ION_DEVICE_ID_MT4X56USB) },
+   { USB_DEVICE(USB_VENDOR_ID_ION, ION_DEVICE_ID_EDGEPORT_4I) },
+   { USB_DEVICE(USB_VENDOR_ID_ION, ION_DEVICE_ID_EDGEPORT_8_DUAL_CPU) },
+   { USB_DEVICE(USB_VENDOR_ID_ION, ION_DEVICE_ID_EDGEPORT_4_DIN) },
+   { USB_DEVICE(USB_VENDOR_ID_ION, ION_DEVICE_ID_EDGEPORT_22I) },
+   { USB_DEVICE(USB_VENDOR_ID_ION, ION_DEVICE_ID_EDGEPORT_412_4) },
+   { USB_DEVICE(USB_VENDOR_ID_ION, ION_DEVICE_ID_EDGEPORT_COMPATIBLE) },
+   { }
+};
+
+static const struct usb_device_id edgeport_8port_id_table[] = {
+   { USB_DEVICE(USB_VENDOR_ID_ION, ION_DEVICE_ID_EDGEPORT_8) },
+   { USB_DEVICE(USB_VENDOR_ID_ION, ION_DEVICE_ID_EDGEPORT_16_DUAL_CPU) },
+   { USB_DEVICE(USB_VENDOR_ID_ION, ION_DEVICE_ID_EDGEPORT_8I) },
+   { USB_DEVICE(USB_VENDOR_ID_ION, ION_DEVICE_ID_EDGEPORT_8R) },
+   { USB_DEVICE(USB_VENDOR_ID_ION, ION_DEVICE_ID_EDGEPORT_8RR) },
+   { USB_DEVICE(USB_VENDOR_ID_ION, ION_DEVICE_ID_EDGEPORT_412_8) },
+   { }
+};
+
+static const struct usb_device_id Epic_port_id_table[] = {
+   { USB_DEVICE(USB_VENDOR_ID_NCR, NCR_DEVICE_ID_EPIC_0202) },
+   { USB_DEVICE(USB_VENDOR_ID_NCR, NCR_DEVICE_ID_EPIC_0203) },
+   { USB_DEVICE(USB_VENDOR_ID_NCR, NCR_DEVICE_ID_EPIC_0310) },
+   { USB_DEVICE(USB_VENDOR_ID_NCR, NCR_DEVICE_ID_EPIC_0311) },
+   { USB_DEVICE(USB_VENDOR_ID_NCR, NCR_DEVICE_ID_EPIC_0312) },
+   { USB_DEVICE(USB_VENDOR_ID_AXIOHM, AXIOHM_DEVICE_ID_EPIC_A758) },
+   { USB_DEVICE(USB_VENDOR_ID_AXIOHM, AXIOHM_DEVICE_ID_EPIC_A794) },
+   { USB_DEVICE(USB_VENDOR_ID_AXIOHM, AXIOHM_DEVICE_ID_EPIC_A225) },
+   { }
+};
+
+/* Devices that this driver supports */
+static const struct usb_device_id id_table_combined[] = {
+   { USB_DEVICE(USB_VENDOR_ID_ION, ION_DEVICE_ID_EDGEPORT_4) },
+   { USB_DEVICE(USB_VENDOR_ID_ION, ION_DEVICE_ID_RAPIDPORT_4) },
+   { USB_DEVICE(USB_VENDOR_ID_ION, ION_DEVICE_ID_EDGEPORT_4T) },
+   { USB_DEVICE(USB_VENDOR_ID_ION, ION_DEVICE_ID_MT4X56USB) },
+   { USB_DEVICE(USB_VENDOR_ID_ION, ION_DEVICE_ID_EDGEPORT_2) },
+   { USB_DEVICE(USB_VENDOR_ID_ION, ION_DEVICE_ID_EDGEPORT_4I) },
+   { USB_DEVICE(USB_VENDOR_ID_ION, ION_DEVICE_ID_EDGEPORT_2I) },
+   { USB_DEVICE(USB_VENDOR_ID_ION, ION_DEVICE_ID_EDGEPORT_421) },
+   { USB_DEVICE(USB_VENDOR_ID_ION, ION_DEVICE_ID_EDGEPORT_21) },
+   { USB_DEVICE(USB_VENDOR_ID_ION, ION_DEVICE_ID_EDGEPORT_8_DUAL_CPU) },
+   { USB_DEVICE(USB_VENDOR_ID_ION, ION_DEVICE_ID_EDGEPORT_8) },
+   { USB_DEVICE(USB_VENDOR_ID_ION, ION_DEVICE_ID_EDGEPORT_2_DIN) },
+   { USB_DEVICE(USB_VENDOR_ID_ION, ION_DEVICE_ID_EDGEPORT_4_DIN) },
+   { USB_DEVICE(USB_VENDOR_ID_ION, ION_DEVICE_ID_EDGEPORT_16_DUAL_CPU) },
+   { USB_DEVICE(USB_VENDOR_ID_ION, ION_DEVICE_ID_EDGEPORT_22I) },
+   { USB_DEVICE(USB_VENDOR_ID_ION, ION_DEVICE_ID_EDGEPORT_412_4) },
+   { USB_DEVICE(USB_VENDOR_ID_ION, ION_DEVICE_ID_EDGEPORT_COMPATIBLE) },
+   { USB_DEVICE(USB_VENDOR_ID_ION, ION_DEVICE_ID_EDGEPORT_8I) },
+   { USB_DEVICE(USB_VENDOR_ID_ION, ION_DEVICE_ID_EDGEPORT_8R) },
+   { USB_DEVICE(USB_VENDOR_ID_ION, ION_DEVICE_ID_EDGEPORT_8RR) },
+   { USB_DEVICE(USB_VENDOR_ID_ION, ION_DEVICE_ID_EDGEPORT_412_8) },
+   { USB_DEVICE(USB_VENDOR_ID_NCR, NCR_DEVICE_ID_EPIC_0202) },
+   { USB_DEVICE(USB_VENDOR_ID_NCR, NCR_DEVICE_ID_EPIC_0203) },
+   { USB_DEVICE(USB_VENDOR_ID_NCR, NCR_DEVICE_ID_EPIC_0310) },
+   { USB_DEVICE(USB_VENDOR_ID_NCR, NCR_DEVICE_ID_EPIC_0311) },
+   

[PATCH 2/2] USB: serial: keyspan: drop header file

[Johan Hovold]

Move all declarations and definitions in keyspan.h to keyspan.c, which
is the only place were they are used.

This specifically moves the driver device-id tables and usb-serial
driver definitions to the source file where they are expected to be
found.

While at it, fix up some multi-line comments and minor white-space
issues (spaces instead of tabs and superfluous white space).

Note that the information in the comment header of the removed header
file is also present in the source file.

Signed-off-by: Johan Hovold 
---
 drivers/usb/serial/keyspan.c | 592 +++-
 drivers/usb/serial/keyspan.h | 629 ---
 2 files changed, 589 insertions(+), 632 deletions(-)
 delete mode 100644 drivers/usb/serial/keyspan.h

diff --git a/drivers/usb/serial/keyspan.c b/drivers/usb/serial/keyspan.c
index 1f9414bdd649..5662d324edd2 100644
--- a/drivers/usb/serial/keyspan.c
+++ b/drivers/usb/serial/keyspan.c
@@ -41,11 +41,508 @@
 #include 
 #include 
 #include 
-#include "keyspan.h"
 
 #define DRIVER_AUTHOR "Hugh Blemings 

Re: [PATCH v13 06/12] usb: xhci: use bus->sysdev for DMA configuration

[Roger Quadros]

+Felipe,

On 15/02/17 10:51, Peter Chen wrote:
> On Wed, Feb 15, 2017 at 10:18:03AM +0200, Roger Quadros wrote:
>> Peter,
>>
>> On 15/02/17 03:35, Peter Chen wrote:
>>> On Tue, Feb 14, 2017 at 01:58:40PM +0100, Arnd Bergmann wrote:
 On Tue, Feb 14, 2017 at 1:26 PM, Roger Quadros  wrote:
> On 14/02/17 13:44, Arnd Bergmann wrote:
>> On Tue, Feb 14, 2017 at 11:36 AM, Roger Quadros  wrote:

>>> Why are we using sysdev to read DT property? We should be using the
>>> XHCI device (>dev) here, no?
>>
>> If I remember correctly, this is one of the cases where pdev does not
>> have a device node attached to it because it was created by the driver
>> of the parent device on the fly in case of dwc3. When you have a pure 
>> xhci
>> device in DT, the two pointers are the same.
>
> From drivers/usb/dwc3/host.c
>
>> if (dwc->usb3_lpm_capable) {
>> props[0].name = "usb3-lpm-capable";
>> ret = platform_device_add_properties(xhci, props);
>> if (ret) {
>> dev_err(dwc->dev, "failed to add properties to 
>> xHCI\n");
>> goto err1;
>> }
>> }
>
> So it is setting the usb3-lpm-capable property into the xhci platform 
> device
> and we should be reading the property from there.
>>>
>>> Why dwc3 needs another "snps,usb3_lpm_capable"? Why not using
>>> "usb3-lpm-capable" at firmware directly?
>>
>> dwc3 is not setting "snps,usb3_lpm_capable" but "usb3-lpm-capable" for the
>> xhci platform device.
>>
>> What did you mean by firmware? Did you mean something like BIOS?
>> At least TI platforms don't use any firmware like BIOS. So dwc3 driver
>> needs to create a platform device for xhci on the fly and set the DT 
>> properties.
>>
> 
> By readying code, the dwc3 calls dwc3_get_properties to set
> dwc->usb3_lpm_capable, and at dwc3/host.c, it sets property
> "usb3-lpm-capable" according to this flag, why not let common
> code xhci-plat.c to get this property from sysdev which is DT
> nodes for dwc3?
> 

Felipe, any comments?

-- 
cheers,
-roger
--
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: How to get related device pointer via DT?

[Peter Chen]

On Wed, Feb 15, 2017 at 02:21:55AM +, Yoshihiro Shimoda wrote:
> Hi,
> 
> I would like to get a related device pointer on usb EHCI drivers (or USB 
> framework)
> because related device (e.g. OHCI or UHCI, called "companion controllers") 
> has to
> finish resuming. I discussed this topic with Alan:
> http://marc.info/?t=14865351421=1=2
> 
> In PCI bus, USB framework already has such a feature in 
> drivers/usb/core/hcd-pci.c.
> However, in platform devices, we don't have it for now. So, I would like to 
> add it.
> 
> Then, I have 2 ideas to get the related device pointer:
> 
> A) We add a new property "companion" as usb-generic.txt and EHCI node(s) have
>such a property to bind a companion controller.
> B) We assume EHCI controller binds a companion controller if some resources
>(irq or clock) are the same and it has a compatible strings as 
> "generic-[uo]hci"
>for instance.
> 
> My environment is R-Car H3, and it has 3 EHCI and 3 OHCI controllers.
> For example (I only wrote channel 0 of EHCI and OHCI):
>   ehci0: usb@ee080100 {
>   compatible = "generic-ehci";
>   reg = <0 0xee080100 0 0x100>;
>   interrupts = ;
>   clocks = < CPG_MOD 703>;
>   phys = <_phy0>;
>   phy-names = "usb";
>   power-domains = < R8A7795_PD_ALWAYS_ON>;
>   status = "disabled";
>   };
> 
>   ohci0: usb@ee08 {
>   compatible = "generic-ohci";
>   reg = <0 0xee08 0 0x100>;
>   interrupts = ;
>   clocks = < CPG_MOD 703>;
>   phys = <_phy0>;
>   phy-names = "usb";
>   power-domains = < R8A7795_PD_ALWAYS_ON>;
>   status = "disabled";
>   };
> 
> If my idea A), ehci0 will have companion = <>;
> If my idea B), no need to add any property.
> 
> What do you think?
> Anyway, I will start to study DT programming :)
> 

>From my point, idea A is better. It seems you have similar idea when you
tried Dual-role framework before. [1]

[1] https://patchwork.kernel.org/patch/9169745/

-- 

Best Regards,
Peter Chen
--
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: class: remove logically dead code

[Oliver Neukum]

Am Dienstag, den 14.02.2017, 21:10 -0600 schrieb Gustavo A. R. Silva:
> Remove logically dead code.
> 'cntr' is always equal to zero when the following line of code is
> executed:
> rv = cntr ? cntr : -EAGAIN;
> 
> Addresses-Coverity-ID: 113227
> Signed-off-by: Gustavo A. R. Silva 
> 
Acked-by: Oliver Neukum 

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

[PATCH v2] HID: hiddev: allocate minor number hiddev's USB interface is bound to

[Jaejoong Kim]

When HID device connected to the PC, HID device driver announces which
driver is loaded with a kernel info message. In this case, hiddev's minor
number is always '0' even though hiddev's real minor number is not zero.

To display hiddev with minor number asked from usb core, we need
to fill hiddev's minor number this interface is bound to.

Signed-off-by: Jaejoong Kim 
---
Changes in v2:
 - fix typo in commit message
---

 drivers/hid/usbhid/hiddev.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/hid/usbhid/hiddev.c b/drivers/hid/usbhid/hiddev.c
index 700145b..27e1f8d 100644
--- a/drivers/hid/usbhid/hiddev.c
+++ b/drivers/hid/usbhid/hiddev.c
@@ -910,6 +910,7 @@ int hiddev_connect(struct hid_device *hid, unsigned int 
force)
kfree(hiddev);
return -1;
}
+   hid->minor = usbhid->intf->minor;
return 0;
 }
 
-- 
2.7.4

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

Re: [PATCH 1/6] usb: xhci: add xhci_log_cmd trace events

[Lu Baolu]

Hi,

On 02/15/2017 04:56 PM, Felipe Balbi wrote:
> Hi,
>
> Lu Baolu  writes:
>>> Lu Baolu  writes:
 diff --git a/drivers/usb/host/xhci-trace.h b/drivers/usb/host/xhci-trace.h
 index 1ac2cdf..c31eeaf 100644
 --- a/drivers/usb/host/xhci-trace.h
 +++ b/drivers/usb/host/xhci-trace.h
 @@ -285,6 +285,96 @@ DEFINE_EVENT(xhci_log_urb, xhci_urb_dequeue,
TP_ARGS(urb)
  );
  
 +DECLARE_EVENT_CLASS(xhci_log_cmd,
 +  TP_PROTO(struct xhci_command *cmd),
 +  TP_ARGS(cmd),
 +  TP_STRUCT__entry(
 +  __field(struct xhci_command *, cmd)
 +  __field(struct xhci_container_ctx *, in_ctx)
 +  __field(union xhci_trb *, cmd_trb)
 +  __field(int, slot_id)
 +  __field(int, status)
 +  __field(int, type)
 +  ),
 +  TP_fast_assign(
 +  __entry->cmd = cmd;
 +  __entry->in_ctx = cmd->in_ctx;
 +  __entry->cmd_trb = cmd->command_trb;
 +  __entry->slot_id = cmd->slot_id;
 +  __entry->status = cmd->status;
 +  __entry->type = 
 TRB_FIELD_TO_TYPE(le32_to_cpu(cmd->command_trb->generic.field[3]))
 +  ),
 +  TP_printk("cmd @%p: %s: in_ctx=@%p, slot_id=%d, cmd_trb=@%p, status=%d",
 +  __entry->cmd, xhci_trb_type_string(__entry->type),
 +  __entry->in_ctx, __entry->slot_id, __entry->cmd_trb,
 +  __entry->status
 +  )
 +);
>>> we already have a generic TRB tracer that decodes every single TRB. What
>>> is this bringing that the previous doesn't provide?
>> This tracer traces the life cycle of a command. It gives,
>>
>> 1) Which function started an xhci command?
>> 2) What was name of that command?
>> 3) Did hardware respond to it, or timed out?
>> 4) If hardware responded, what was the execution result?
>> 5) If timed out, did 'abort command ring operation' abort it successfully?
>> 6) Was the command structure freed at last?
> We already have all that, AFAICT. Command is enqueued, then an event
> triggers for command completion, then we look at results.

The TRB tracer can directly tell us above 2 and 4 by tracing the enqueue
and dequeue of command trbs. It doesn't tell us 1 and 6. For 3 and 5, we
might be able to get to know, but it needs deep understand of the driver
code and many efforts to look through the trace log.

This command tracer will make the life easier when we are debugging
command related issues in xhci driver.


>  The only thing
> missing for completeness is slot/EP context tracers (which I've pointed
> you to) so we can see what changes each command cause to the different
> contexts.
>
> Frankly, I don't think printing out context pointers brings
> anything. What can you do with that address? :-p Same goes for cmd
> pointer, it brings nothing; gives no insight into the problem
> whatsoever.
>
> We certainly need to know which command was enqueued, the slot, etc. But
> addresses... not so sure.

My thought was 'if we find a command failed, we might want to
know what parameters did we feed hardware'. The trb and ctx
pointers will let us go through the trb and context trace log.

For the command pointer, it can help us to grep the trace log
of a single command, so we are able to know how did the
command go.

Best regards,
Lu Baolu

>
>>> BTW, I also have
>>> ready Slot and EP context tracers, I didn't send before because I
>>> already had quite a large series pending for Mathias :-p
>> Sorry for the duplication.
> no need to apologize, you didn't know :-)
>

--
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 0/4 linux-next] usb: gadget: udc: atmel: Endpoint allocation scheme fixes

[Nicolas Ferre]

Le 14/02/2017 à 17:09, cristian.bir...@microchip.com a écrit :
> From: Cristian Birsan 
> 
> This patch series provides fixes, based on the feedback received on the 
> mailing list, for
> the following:
>   - fifo table parameters validation against device tree values
>   - coding style
>   - message display for EP configuration error
>   - Kconfig comments for fifo_mode=0
> 
> Cristian Birsan (4):
>   usb: gadget: udc: atmel: Check fifo configuration values against
> device tree
>   usb: gadget: udc: atmel: Minor code cleanup
>   usb: gadget: udc: atmel: Use dev_warn() to display EP configuration
> error
>   usb: gadget: udc: atmel: Update Kconfig help for fifo_mode = 0
> 
>  drivers/usb/gadget/udc/Kconfig  |  5 ++--
>  drivers/usb/gadget/udc/atmel_usba_udc.c | 47 
> ++---
>  2 files changed, 35 insertions(+), 17 deletions(-)

I'm okay with the whole series:
Acked-by: Nicolas Ferre 

Thanks, regards,
-- 
Nicolas Ferre
--
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: class: remove logically dead code

[Peter Senna Tschudin]

On Tue, Feb 14, 2017 at 09:10:52PM -0600, Gustavo A. R. Silva wrote:
> Remove logically dead code.
> 'cntr' is always equal to zero when the following line of code is executed:
> rv = cntr ? cntr : -EAGAIN;
> 
> Addresses-Coverity-ID: 113227
> Signed-off-by: Gustavo A. R. Silva 
Reviewed-by: Peter Senna Tschudin 
> ---
>  drivers/usb/class/cdc-wdm.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/class/cdc-wdm.c b/drivers/usb/class/cdc-wdm.c
> index 0a63695..8fda45a 100644
> --- a/drivers/usb/class/cdc-wdm.c
> +++ b/drivers/usb/class/cdc-wdm.c
> @@ -531,7 +531,7 @@ static ssize_t wdm_read
>   i++;
>   if (file->f_flags & O_NONBLOCK) {
>   if (!test_bit(WDM_READ, >flags)) {
> - rv = cntr ? cntr : -EAGAIN;
> + rv = -EAGAIN;
>   goto err;
>   }
>   rv = 0;
> -- 
> 2.5.0
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/6] usb: xhci: add xhci_log_cmd trace events

[Felipe Balbi]

Hi,

Lu Baolu  writes:
>> Lu Baolu  writes:
>>> diff --git a/drivers/usb/host/xhci-trace.h b/drivers/usb/host/xhci-trace.h
>>> index 1ac2cdf..c31eeaf 100644
>>> --- a/drivers/usb/host/xhci-trace.h
>>> +++ b/drivers/usb/host/xhci-trace.h
>>> @@ -285,6 +285,96 @@ DEFINE_EVENT(xhci_log_urb, xhci_urb_dequeue,
>>> TP_ARGS(urb)
>>>  );
>>>  
>>> +DECLARE_EVENT_CLASS(xhci_log_cmd,
>>> +   TP_PROTO(struct xhci_command *cmd),
>>> +   TP_ARGS(cmd),
>>> +   TP_STRUCT__entry(
>>> +   __field(struct xhci_command *, cmd)
>>> +   __field(struct xhci_container_ctx *, in_ctx)
>>> +   __field(union xhci_trb *, cmd_trb)
>>> +   __field(int, slot_id)
>>> +   __field(int, status)
>>> +   __field(int, type)
>>> +   ),
>>> +   TP_fast_assign(
>>> +   __entry->cmd = cmd;
>>> +   __entry->in_ctx = cmd->in_ctx;
>>> +   __entry->cmd_trb = cmd->command_trb;
>>> +   __entry->slot_id = cmd->slot_id;
>>> +   __entry->status = cmd->status;
>>> +   __entry->type = 
>>> TRB_FIELD_TO_TYPE(le32_to_cpu(cmd->command_trb->generic.field[3]))
>>> +   ),
>>> +   TP_printk("cmd @%p: %s: in_ctx=@%p, slot_id=%d, cmd_trb=@%p, status=%d",
>>> +   __entry->cmd, xhci_trb_type_string(__entry->type),
>>> +   __entry->in_ctx, __entry->slot_id, __entry->cmd_trb,
>>> +   __entry->status
>>> +   )
>>> +);
>> we already have a generic TRB tracer that decodes every single TRB. What
>> is this bringing that the previous doesn't provide?
>
> This tracer traces the life cycle of a command. It gives,
>
> 1) Which function started an xhci command?
> 2) What was name of that command?
> 3) Did hardware respond to it, or timed out?
> 4) If hardware responded, what was the execution result?
> 5) If timed out, did 'abort command ring operation' abort it successfully?
> 6) Was the command structure freed at last?

We already have all that, AFAICT. Command is enqueued, then an event
triggers for command completion, then we look at results. The only thing
missing for completeness is slot/EP context tracers (which I've pointed
you to) so we can see what changes each command cause to the different
contexts.

Frankly, I don't think printing out context pointers brings
anything. What can you do with that address? :-p Same goes for cmd
pointer, it brings nothing; gives no insight into the problem
whatsoever.

We certainly need to know which command was enqueued, the slot, etc. But
addresses... not so sure.

>> BTW, I also have
>> ready Slot and EP context tracers, I didn't send before because I
>> already had quite a large series pending for Mathias :-p
>
> Sorry for the duplication.

no need to apologize, you didn't know :-)

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH v13 06/12] usb: xhci: use bus->sysdev for DMA configuration

[Peter Chen]

On Wed, Feb 15, 2017 at 10:18:03AM +0200, Roger Quadros wrote:
> Peter,
> 
> On 15/02/17 03:35, Peter Chen wrote:
> > On Tue, Feb 14, 2017 at 01:58:40PM +0100, Arnd Bergmann wrote:
> >> On Tue, Feb 14, 2017 at 1:26 PM, Roger Quadros  wrote:
> >>> On 14/02/17 13:44, Arnd Bergmann wrote:
>  On Tue, Feb 14, 2017 at 11:36 AM, Roger Quadros  wrote:
> >>
> > Why are we using sysdev to read DT property? We should be using the
> > XHCI device (>dev) here, no?
> 
>  If I remember correctly, this is one of the cases where pdev does not
>  have a device node attached to it because it was created by the driver
>  of the parent device on the fly in case of dwc3. When you have a pure 
>  xhci
>  device in DT, the two pointers are the same.
> >>>
> >>> From drivers/usb/dwc3/host.c
> >>>
>  if (dwc->usb3_lpm_capable) {
>  props[0].name = "usb3-lpm-capable";
>  ret = platform_device_add_properties(xhci, props);
>  if (ret) {
>  dev_err(dwc->dev, "failed to add properties to 
>  xHCI\n");
>  goto err1;
>  }
>  }
> >>>
> >>> So it is setting the usb3-lpm-capable property into the xhci platform 
> >>> device
> >>> and we should be reading the property from there.
> > 
> > Why dwc3 needs another "snps,usb3_lpm_capable"? Why not using
> > "usb3-lpm-capable" at firmware directly?
> 
> dwc3 is not setting "snps,usb3_lpm_capable" but "usb3-lpm-capable" for the
> xhci platform device.
> 
> What did you mean by firmware? Did you mean something like BIOS?
> At least TI platforms don't use any firmware like BIOS. So dwc3 driver
> needs to create a platform device for xhci on the fly and set the DT 
> properties.
> 

By readying code, the dwc3 calls dwc3_get_properties to set
dwc->usb3_lpm_capable, and at dwc3/host.c, it sets property
"usb3-lpm-capable" according to this flag, why not let common
code xhci-plat.c to get this property from sysdev which is DT
nodes for dwc3?

-- 

Best Regards,
Peter Chen
--
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/6] usb: xhci: enhance xhci_log_ctx trace events

[Lu Baolu]

Hi,

On 02/15/2017 04:00 PM, Felipe Balbi wrote:
> Hi,
>
> Lu Baolu  writes:
>> XHCI driver has defined xhci_log_ctx trace events to trace
>> the change of an xhci input or output context. This patch
>> extends the trace class of xhci_log_ctx to print out the
>> contents of a context block in a human readable way.
>>
>> This patch also adds some other xhci_log_ctx based events
>> where the xhci input or output context changes.
>>
>> Signed-off-by: Lu Baolu 
> how about?
>
> https://git.kernel.org/cgit/linux/kernel/git/balbi/usb.git/commit/?h=xhci-cleanup=4c45cec9f399fb3a53b77c4bb63d5e8fbe382171
>

Great. I will look into this.

Best regards,
Lu Baolu
--
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/6] usb: xhci: add xhci_log_cmd trace events

[Lu Baolu]

Hi,

On 02/15/2017 03:58 PM, Felipe Balbi wrote:
> Hi,
>
> Lu Baolu  writes:
>> diff --git a/drivers/usb/host/xhci-trace.h b/drivers/usb/host/xhci-trace.h
>> index 1ac2cdf..c31eeaf 100644
>> --- a/drivers/usb/host/xhci-trace.h
>> +++ b/drivers/usb/host/xhci-trace.h
>> @@ -285,6 +285,96 @@ DEFINE_EVENT(xhci_log_urb, xhci_urb_dequeue,
>>  TP_ARGS(urb)
>>  );
>>  
>> +DECLARE_EVENT_CLASS(xhci_log_cmd,
>> +TP_PROTO(struct xhci_command *cmd),
>> +TP_ARGS(cmd),
>> +TP_STRUCT__entry(
>> +__field(struct xhci_command *, cmd)
>> +__field(struct xhci_container_ctx *, in_ctx)
>> +__field(union xhci_trb *, cmd_trb)
>> +__field(int, slot_id)
>> +__field(int, status)
>> +__field(int, type)
>> +),
>> +TP_fast_assign(
>> +__entry->cmd = cmd;
>> +__entry->in_ctx = cmd->in_ctx;
>> +__entry->cmd_trb = cmd->command_trb;
>> +__entry->slot_id = cmd->slot_id;
>> +__entry->status = cmd->status;
>> +__entry->type = 
>> TRB_FIELD_TO_TYPE(le32_to_cpu(cmd->command_trb->generic.field[3]))
>> +),
>> +TP_printk("cmd @%p: %s: in_ctx=@%p, slot_id=%d, cmd_trb=@%p, status=%d",
>> +__entry->cmd, xhci_trb_type_string(__entry->type),
>> +__entry->in_ctx, __entry->slot_id, __entry->cmd_trb,
>> +__entry->status
>> +)
>> +);
> we already have a generic TRB tracer that decodes every single TRB. What
> is this bringing that the previous doesn't provide?

This tracer traces the life cycle of a command. It gives,

1) Which function started an xhci command?
2) What was name of that command?
3) Did hardware respond to it, or timed out?
4) If hardware responded, what was the execution result?
5) If timed out, did 'abort command ring operation' abort it successfully?
6) Was the command structure freed at last?

> BTW, I also have
> ready Slot and EP context tracers, I didn't send before because I
> already had quite a large series pending for Mathias :-p
>

Sorry for the duplication.

Best regards,
Lu Baolu
--
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 v13 06/12] usb: xhci: use bus->sysdev for DMA configuration

[Roger Quadros]

Peter,

On 15/02/17 03:35, Peter Chen wrote:
> On Tue, Feb 14, 2017 at 01:58:40PM +0100, Arnd Bergmann wrote:
>> On Tue, Feb 14, 2017 at 1:26 PM, Roger Quadros  wrote:
>>> On 14/02/17 13:44, Arnd Bergmann wrote:
 On Tue, Feb 14, 2017 at 11:36 AM, Roger Quadros  wrote:
>>
> Why are we using sysdev to read DT property? We should be using the
> XHCI device (>dev) here, no?

 If I remember correctly, this is one of the cases where pdev does not
 have a device node attached to it because it was created by the driver
 of the parent device on the fly in case of dwc3. When you have a pure xhci
 device in DT, the two pointers are the same.
>>>
>>> From drivers/usb/dwc3/host.c
>>>
 if (dwc->usb3_lpm_capable) {
 props[0].name = "usb3-lpm-capable";
 ret = platform_device_add_properties(xhci, props);
 if (ret) {
 dev_err(dwc->dev, "failed to add properties to 
 xHCI\n");
 goto err1;
 }
 }
>>>
>>> So it is setting the usb3-lpm-capable property into the xhci platform device
>>> and we should be reading the property from there.
> 
> Why dwc3 needs another "snps,usb3_lpm_capable"? Why not using
> "usb3-lpm-capable" at firmware directly?

dwc3 is not setting "snps,usb3_lpm_capable" but "usb3-lpm-capable" for the
xhci platform device.

What did you mean by firmware? Did you mean something like BIOS?
At least TI platforms don't use any firmware like BIOS. So dwc3 driver
needs to create a platform device for xhci on the fly and set the DT properties.

> 
> Peter
> 
>>
>> Hmm, ideally we would only have properties on one of the two, since we
>> refer to the sysdev for the properties regarding DMA and PHY among other
>> things, but I guess that's not an option here, since we can't call
>> platform_device_add_properties() on a dwc_pci device and have to
>> use the xhci pdev instead.
>>
>>  Arnd
>>

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

[PATCH] usb: musb: cppi_dma.c: use DIV_ROUND_UP macro in cppi_next_(r|t)x_segment()

[Ivan Safonov]

DIV_ROUND_UP is bit useful than series of "/" and "%" operations.
Replace "/%" sequence with DIV_ROUND_UP macro.

Signed-off-by: Ivan Safonov 
---
 drivers/usb/musb/cppi_dma.c | 10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/musb/cppi_dma.c b/drivers/usb/musb/cppi_dma.c
index 1ae48e6..d376188 100644
--- a/drivers/usb/musb/cppi_dma.c
+++ b/drivers/usb/musb/cppi_dma.c
@@ -582,9 +582,9 @@ cppi_next_tx_segment(struct musb *musb, struct cppi_channel 
*tx)
maxpacket = length;
n_bds = 1;
} else {
-   n_bds = length / maxpacket;
-   if (!length || (length % maxpacket))
-   n_bds++;
+   n_bds = DIV_ROUND_UP(length, maxpacket);
+   if (length == 0)
+   n_bds = 1;
n_bds = min(n_bds, (unsigned) NUM_TXCHAN_BD);
length = min(n_bds * maxpacket, length);
}
@@ -790,9 +790,7 @@ cppi_next_rx_segment(struct musb *musb, struct cppi_channel 
*rx, int onepacket)
n_bds = 0x / maxpacket;
length = n_bds * maxpacket;
} else {
-   n_bds = length / maxpacket;
-   if (length % maxpacket)
-   n_bds++;
+   n_bds = DIV_ROUND_UP(length, maxpacket);
}
if (n_bds == 1)
onepacket = 1;
-- 
2.10.2

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

Re: [PATCH 2/6] usb: xhci: enhance xhci_log_ctx trace events

[Felipe Balbi]

Hi,

Lu Baolu  writes:
> XHCI driver has defined xhci_log_ctx trace events to trace
> the change of an xhci input or output context. This patch
> extends the trace class of xhci_log_ctx to print out the
> contents of a context block in a human readable way.
>
> This patch also adds some other xhci_log_ctx based events
> where the xhci input or output context changes.
>
> Signed-off-by: Lu Baolu 

how about?

https://git.kernel.org/cgit/linux/kernel/git/balbi/usb.git/commit/?h=xhci-cleanup=4c45cec9f399fb3a53b77c4bb63d5e8fbe382171

-- 
balbi


signature.asc
Description: PGP signature