[PATCH 2/4] doc: dt-binding: ci-hdrc-usb2: add i.mx specific binding "need-three-clocks"

Some SoCs needs three clock to let controller work, but others only need one, add one property to differentiate this. Signed-off-by: Peter Chen --- Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt | 3 +++ 1 file changed, 3 insertions(+) diff --git

[PATCH 4/4] usb: chipidea: imx: refine clock operations to adapt for all platforms

Some i.mx platforms need three clocks to let controller work, but others only need one, refine clock operation to adapt for all platforms. Cc: Fabio Estevam Signed-off-by: Peter Chen --- drivers/usb/chipidea/ci_hdrc_imx.c | 138

[PATCH 3/4] ARM: dts: imx27.dtsi: change the clock information for usb

For imx27, it needs three clocks to let the controller work, the old code is wrong, and will cause below data abort when accass usbmisc registers. usbcore: registered new interface driver usb-storage Unhandled fault: external abort on non-linefetch (0x008) at 0xf4424600 pgd = c0004000 [f4424600]

[PATCH 1/4] doc: dt-binding: ci-hdrc-usb2: split vendor specific properties

Each vendor may have its specific properties, they are not belonged to common optional properties, split them from common's. Signed-off-by: Peter Chen --- Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt | 10 ++ 1 file changed, 6 insertions(+), 4

Re: [PATCH v2 2/5] usb: dwc3: gadget: start using Update Transfer more often

Hi Felipe, It's dangerous to use Update Transfer when the DWC3_TRB_CTRL_LST bit might be set in one of the TRBs. The reason is, there is a window between checking that the transfer has not completed yet and issuing the Update Transfer command. If the hardware happens to complete the transfer and

Re: [PATCH 3/4] ARM: dts: imx27.dtsi: change the clock information for usb

On Tue, Sep 15, 2015 at 10:49 PM, Peter Chen wrote: > For imx27, it needs three clocks to let the controller work, > the old code is wrong, and will cause below data abort when > accass usbmisc registers. > > usbcore: registered new interface driver usb-storage >

Re: [PATCH 4/4] usb: chipidea: imx: refine clock operations to adapt for all platforms

On Tue, Sep 15, 2015 at 10:49 PM, Peter Chen wrote: > Some i.mx platforms need three clocks to let controller work, but > others only need one, refine clock operation to adapt for all > platforms. > > Cc: Fabio Estevam > Signed-off-by: Peter

Re: [PATCH 3/4] ARM: dts: imx27.dtsi: change the clock information for usb

On Wed, Sep 16, 2015 at 12:25:17AM -0300, Fabio Estevam wrote: > On Tue, Sep 15, 2015 at 10:49 PM, Peter Chen wrote: > > For imx27, it needs three clocks to let the controller work, > > the old code is wrong, and will cause below data abort when > > accass usbmisc

Re: [PATCH 3/4] ARM: dts: imx27.dtsi: change the clock information for usb

On Tue, Sep 15, 2015 at 11:31 PM, Peter Chen wrote: >> mx25.dtsi and mx35.dtsi also need to be changed. > > If you can help to test, I will update. Sure, I can test it on mx25pdk tomorrow. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the

Re: [Y2038] [PATCH] dummy_hcd: replace timeval with timespec64

On Tuesday, September 15, 2015 10:49 PM, Arnd Bergmann wrote: > On Tuesday 15 September 2015 10:40:24 Alan Stern wrote: >> On Tue, 15 Sep 2015, Arnd Bergmann wrote: >> > Do you know the specific requirement on the USB frame numbers? I don't > know > enough about USB to tell if

RE: [PATCH] Revert "usb: chipidea: usbmisc_imx: delete clock information"

> > On Mon, Sep 14, 2015 at 11:32 PM, Fabio Estevam > wrote: > > > This did not help. > > > > It is getting late here, so I will be able to try more things tomorrow. > > I was able to fix it. Your initial patch had a missing 'return 0' in > imx_prepare_enable_clks(),

Gelten Sie für dringende Darlehen bieten1.1%

-- BancoPosta Loans Viale Europa, 175-00144 Roma, Italy. Email: bancopost...@gmail.com Guten Tag meine Damen und Herren, Brauchen Sie ein Darlehen für einen bestimmten Zweck? BancoPosta Bank in Italien haben einen günstigen Kredit für Sie. Wir bieten gesicherten und ungesicherten

Re: [PATCH 3/4] ARM: dts: imx27.dtsi: change the clock information for usb

On Tue, Sep 15, 2015 at 10:49 PM, Peter Chen wrote: > For imx27, it needs three clocks to let the controller work, > the old code is wrong, and will cause below data abort when > accass usbmisc registers. s/acass/accessing > > usbcore: registered new interface driver

Re: [PATCH 2/4] doc: dt-binding: ci-hdrc-usb2: add i.mx specific binding "need-three-clocks"

On Tue, Sep 15, 2015 at 11:24 PM, Peter Chen wrote: > but drivers/usb/gadget/udc/fsl_mxc_udc.c has three clocks Ok, looking at the clock driver I see that they used to associate three clocks with mxc-ehci: clk_register_clkdev(clk[usb_div], "per", "mxc-ehci.0");

Re: [PATCH 4/4] usb: chipidea: imx: refine clock operations to adapt for all platforms

On Tue, Sep 15, 2015 at 10:49 PM, Peter Chen wrote: > Some i.mx platforms need three clocks to let controller work, but > others only need one, refine clock operation to adapt for all > platforms. It would be better to mention that this is fixing a regression on mx27.

Re: [PATCH 2/4] doc: dt-binding: ci-hdrc-usb2: add i.mx specific binding "need-three-clocks"

On Tue, Sep 15, 2015 at 10:49 PM, Peter Chen wrote: > Some SoCs needs three clock to let controller work, but others only > need one, add one property to differentiate this. > > Signed-off-by: Peter Chen > --- >

Re: First kernel patch (optimization)

On Tue, Sep 15, 2015 at 12:53 PM, Eric Curtin wrote: > Signed-off-by: Eric Curtin > > diff --git a/tools/usb/usbip/src/usbip_detach.c > b/tools/usb/usbip/src/usbip_detach.c > index 05c6d15..9db9d21 100644 > --- a/tools/usb/usbip/src/usbip_detach.c

Re: [PATCH 2/4] doc: dt-binding: ci-hdrc-usb2: add i.mx specific binding "need-three-clocks"

On Wed, Sep 16, 2015 at 12:23:26AM -0300, Fabio Estevam wrote: > On Tue, Sep 15, 2015 at 10:49 PM, Peter Chen wrote: > > Some SoCs needs three clock to let controller work, but others only > > need one, add one property to differentiate this. > > > > Signed-off-by: Peter

Re: [PATCH] usb: chipidea: reuse the platform_data to store the ci info

On Tue, Sep 15, 2015 at 01:40:30PM +0800, Barry Song wrote: > 2015-09-14 15:17 GMT+08:00 Peter Chen : > > On Tue, Aug 11, 2015 at 09:43:13AM +, Barry Song wrote: > >> From: Rong Wang > >> > >> Chipidea puts ci information to drvdata, but this

Re: [PATCH 0/5] usb: dwc3: throughput improvement

Hi, On Tue, Sep 15, 2015 at 12:52:17PM -0500, Felipe Balbi wrote: > Hi, > > with these patches (and, no, the mass storage patch is not important; > at least not for USB2, I tested without that as well), I increased > USB2 on a AM437x board with g_mass_storage using RAM as backing store > from

[PATCH v2 3/3] usb: phy: phy-am335x: bypass first VBUS sensing for host-only mode

To prevent VBUS contention, the am335x MUSB phy senses VBUS first before transitioning to host mode. However, for host-only mode, VBUS could be directly tied to 5V power rail which could prevent MUSB transitions to host mode. This change receives dr_mode of the controller then bypass the first

[PATCH v2 0/3] usb: phy: phy-am335x: support tying VBUS to 5V in host-only mode

To save cost and simply the design, most host-only application will directly tie VBUS to 5V power rail, but this prevents AM335x MUSB to transition to host mode due VBUS sensing for OTG state machine. These patches disable the first VBUS sensing in AM335x MUSB for host-only mode to enable this

[PATCH v2 0/5] usb: dwc3: throughput improvement

Hi, with these patches (and, no, the mass storage patch is not extremely important although it gives some nice extra improvement - about 1 MiB/sec extra in some cases - at least not for USB2, I tested without that as well), I increased USB2 on a AM437x board with g_mass_storage using RAM as

[PATCH v2 5/5] usb: gadget: mass_storage: allow for deeper queue lengths

Instead of allowing a range of 2 to 4 requests, let's allow the user choose up to 32 requests as that will give us a better chance of keeping controller busy. We still maintain default of 2 so users shouldn't be affected. Signed-off-by: Felipe Balbi --- drivers/usb/gadget/Kconfig

[PATCH v2 1/5] usb: dwc3: gadget: start requests as soon as they come

In an attempt to make dwc3 slightly faster, let's start usb_requests as soon as they come as that will let us avoid a XFER_NOT_READY event and save a little bit of time. Signed-off-by: Felipe Balbi --- drivers/usb/dwc3/gadget.c | 16 1 file changed, 16

[PATCH v2 2/3] usb: phy: correct the am335x phy header filename

The filename of am35x-phy-control.h is confusing. The header is used by the am335x phy driver, but the filename refers to am35x. Even worse there is indeed another device called am35x but it does not use this header at all. Signed-off-by: Bin Liu --- v2: no change

[PATCH v2 1/3] usb: of: add an api to get dr_mode by the phy node

Some USB phy drivers have different handling for the controller in each dr_mode. But the phy driver does not have visibility to the dr_mode of the controller. This adds an api to return the dr_mode of the controller which associates the given phy node. Signed-off-by: Bin Liu ---

Re: [PATCH 5/5] usb: gadget: mass_storage: allow for deeper queue lengths

On Tue, 15 Sep 2015, Felipe Balbi wrote: > Instead of allowing a range of 2 to 4 requests, > let's allow the user choose up to 32 requests > as that will give us a better chance of keeping > controller busy. > > We still maintain default of 2 so users shouldn't > be affected. Was this change

Re: [PATCH 5/5] usb: gadget: mass_storage: allow for deeper queue lengths

On Tue, Sep 15, 2015 at 03:04:58PM -0400, Alan Stern wrote: > On Tue, 15 Sep 2015, Felipe Balbi wrote: > > > Instead of allowing a range of 2 to 4 requests, > > let's allow the user choose up to 32 requests > > as that will give us a better chance of keeping > > controller busy. > > > > We still

[PATCH v2 4/5] usb: dwc3: gadget: remove 'start_new' parameter

The start_new parameter for dwc3_gadget_kick_transfer() is now rendered pointless since driver understands that it should use Update Transfer command when the queue is busy. Let's remove that parameter and make sure we can update transfers which are still in flight. Signed-off-by: Felipe Balbi

[PATCH v2 3/5] usb: dwc3: gadget: clear DWC3_PENDING_REQUEST when request is queued

Instead of clearing DWC3_PENDING_REQUEST when we start transfer, let's do it when the request is actually queued, that way we know for sure that we're clearing in the right time. Signed-off-by: Felipe Balbi --- drivers/usb/dwc3/gadget.c | 5 - 1 file changed, 4 insertions(+),

[PATCH v2 2/5] usb: dwc3: gadget: start using Update Transfer more often

We can infer Update Transfer by the fact that req_queue is empty and DWC3_EP_BUSY isn't set. This let's us a) rely on Update Transfer more often (should be good for deeper queue lengths) and b) remove the extra start_new parameter (done on a follow-up patch) Signed-off-by: Felipe Balbi

Re: [PATCH v2 2/2] usb: chipidea: imx: fix a typo for imx6sx

On Wed, Sep 09, 2015 at 11:19:44AM +0800, Li Jun wrote: > Use imx6sx instead of imx6sl's platform flags for imx6sx. > > Signed-off-by: Li Jun > --- > drivers/usb/chipidea/ci_hdrc_imx.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git

Re: [PATCH 04/26] usb: gadget: introduce 'enabled' flag in struct usb_ep

On 09/15/2015 05:43 PM, Felipe Balbi wrote: > On Tue, Sep 15, 2015 at 05:37:27PM +0200, Krzysztof Opasiak wrote: >> Hello, >> >> On 09/15/2015 04:26 PM, Robert Baldyga wrote: >>> This patch introduces 'enabled' flag in struct usb_ep, and modifies >>> usb_ep_enable() and usb_ep_disable() functions

Re: [PATCH 04/26] usb: gadget: introduce 'enabled' flag in struct usb_ep

Hi, On Tue, Sep 15, 2015 at 05:57:53PM +0200, Robert Baldyga wrote: > On 09/15/2015 05:43 PM, Felipe Balbi wrote: > > On Tue, Sep 15, 2015 at 05:37:27PM +0200, Krzysztof Opasiak wrote: > >> Hello, > >> > >> On 09/15/2015 04:26 PM, Robert Baldyga wrote: > >>> This patch introduces 'enabled' flag

Re: [PATCH 04/26] usb: gadget: introduce 'enabled' flag in struct usb_ep

Hi, On Tue, Sep 15, 2015 at 06:15:25PM +0200, Krzysztof Opasiak wrote: > >>>+ } > >>>+ > >>>+ return ret; > >>> } > >>> > >> > >>Personally I don't like this convention. In my opinion usb_ep_disable() & > >>usb_ep_enable() should fail if ep is already disabled/enabled. Then in > >>function

Re: [PATCH 04/26] usb: gadget: introduce 'enabled' flag in struct usb_ep

On 09/15/2015 05:43 PM, Felipe Balbi wrote: On Tue, Sep 15, 2015 at 05:37:27PM +0200, Krzysztof Opasiak wrote: Hello, On 09/15/2015 04:26 PM, Robert Baldyga wrote: This patch introduces 'enabled' flag in struct usb_ep, and modifies usb_ep_enable() and usb_ep_disable() functions to

Re: similar files: fusbh200-hcd.c and fotg210-hcd.c

On Tue, Sep 15, 2015 at 4:33 PM, Felipe Balbi wrote: > On Mon, Sep 14, 2015 at 07:50:02PM +0200, Peter Senna Tschudin wrote: >> On Mon, Sep 14, 2015 at 5:01 PM, Felipe Balbi wrote: >> > On Sat, Sep 12, 2015 at 03:14:50PM +0200, Peter Senna Tschudin wrote: >> >> >>

Re: xhci woes continued

On 14.09.2015 22:18, Alan Stern wrote: On Sun, 13 Sep 2015, Hans-Peter Jansen wrote: usbmon log attached. It wasn't attached. Hrmpf. Hopefully now... This time the trace wasn't so useful. It doesn't show any obvious reason for the disconnections. It only shows that the port's link

[PATCH 0/5] usb: dwc3: throughput improvement

Hi, with these patches (and, no, the mass storage patch is not important; at least not for USB2, I tested without that as well), I increased USB2 on a AM437x board with g_mass_storage using RAM as backing store from 17MiB/sec to 39MiB/sec as measured by dd (with oflag/iflag=direct depending on

[PATCH 2/5] usb: dwc3: gadget: start using Update Transfer more often

We can infer Update Transfer by the fact that req_queue is empty and DWC3_EP_BUSY isn't set. This let's us a) rely on Update Transfer more often (should be good for deeper queue lengths) and b) remove the extra start_new parameter (done on a follow-up patch) Signed-off-by: Felipe Balbi

[PATCH 5/5] usb: gadget: mass_storage: allow for deeper queue lengths

Instead of allowing a range of 2 to 4 requests, let's allow the user choose up to 32 requests as that will give us a better chance of keeping controller busy. We still maintain default of 2 so users shouldn't be affected. Signed-off-by: Felipe Balbi --- drivers/usb/gadget/Kconfig

[PATCH 1/5] usb: dwc3: gadget: start requests as soon as they come

In an attempt to make dwc3 slightly faster, let's start usb_requests as soon as they come as that will let us avoid a XFER_NOT_READY event and save a little bit of time. Signed-off-by: Felipe Balbi --- drivers/usb/dwc3/gadget.c | 15 +++ 1 file changed, 15

[PATCH 3/5] usb: dwc3: gadget: clear DWC3_PENDING_REQUEST when request is queued

Instead of clearing DWC3_PENDING_REQUEST when we start transfer, let's do it when the request is actually queued, that way we know for sure that we're clearing in the right time. Signed-off-by: Felipe Balbi --- drivers/usb/dwc3/gadget.c | 5 - 1 file changed, 4 insertions(+),

[PATCH 4/5] usb: dwc3: gadget: remove 'start_new' parameter

The start_new parameter for dwc3_gadget_kick_transfer() is now rendered pointless since driver understands that it should use Update Transfer command when the queue is busy. Let's remove that parameter and make sure we can update transfers which are still in flight. Signed-off-by: Felipe Balbi

Re: [PATCH 05/26] usb: gadget: f_ecm: eliminate abuse of ep->driver data

On 09/15/2015 04:26 PM, Robert Baldyga wrote: Since ep->driver_data is not used for endpoint claiming, neither for enabled/disabled state storing, we can reduce number of places where we read or modify it's value, as now it has no particular meaning for function or framework logic. In case of

Re: similar files: fusbh200-hcd.c and fotg210-hcd.c

Hi, On Tue, Sep 15, 2015 at 06:41:55PM +0200, Peter Senna Tschudin wrote: > On Tue, Sep 15, 2015 at 4:33 PM, Felipe Balbi wrote: > > On Mon, Sep 14, 2015 at 07:50:02PM +0200, Peter Senna Tschudin wrote: > >> On Mon, Sep 14, 2015 at 5:01 PM, Felipe Balbi wrote: > >> >

Re: [PATCH 04/26] usb: gadget: introduce 'enabled' flag in struct usb_ep

Hello, On 09/15/2015 04:26 PM, Robert Baldyga wrote: This patch introduces 'enabled' flag in struct usb_ep, and modifies usb_ep_enable() and usb_ep_disable() functions to encapsulate endpoint enabled/disabled state. It helps to avoid enabling endpoints which are already enabled, and disabling

Re: [PATCH 04/26] usb: gadget: introduce 'enabled' flag in struct usb_ep

On Tue, Sep 15, 2015 at 05:37:27PM +0200, Krzysztof Opasiak wrote: > Hello, > > On 09/15/2015 04:26 PM, Robert Baldyga wrote: > >This patch introduces 'enabled' flag in struct usb_ep, and modifies > >usb_ep_enable() and usb_ep_disable() functions to encapsulate endpoint > >enabled/disabled state.

Re: [PATCH 5/5] usb: gadget: mass_storage: allow for deeper queue lengths

On Tue, Sep 15, 2015 at 02:14:14PM -0500, Felipe Balbi wrote: > On Tue, Sep 15, 2015 at 03:04:58PM -0400, Alan Stern wrote: > > On Tue, 15 Sep 2015, Felipe Balbi wrote: > > > > > Instead of allowing a range of 2 to 4 requests, > > > let's allow the user choose up to 32 requests > > > as that will

tools: usbip: detach: avoid calling strlen() at each iteration

Instead of calling strlen on every iteration of the for loop, just call it once and cache the result in a temporary local variable which will be used in the for loop instead. Signed-off-by: Eric Curtin diff --git a/tools/usb/usbip/src/usbip_detach.c

Re: [PATCH 4/5] qmi-wwan: use common parser

From: Oliver Neukum Date: Mon, 7 Sep 2015 16:05:41 +0200 > This moves qmi-wwan to the common parser for CDC user > to reduce code duplication. > > Signed-off-by: Oliver Neukum Applied. -- To unsubscribe from this list: send the line "unsubscribe linux-usb"

Re: [PATCH 1/5] CDC: common parser for extra headers

From: Oliver Neukum Date: Mon, 7 Sep 2015 16:05:38 +0200 > CDC drivers all implement their own parser for the extra headers. > This patch fixes the code duplication introducing a single common > parser in usbnet. > > Signed-off-by: Oliver Neukum Applied.

Re: [PATCH 2/5] cdc-ncm: use common parser

From: Oliver Neukum Date: Mon, 7 Sep 2015 16:05:39 +0200 > This moves cdc-ncm to the common parser for CDC user > to reduce code duplication. > > Signed-off-by: Oliver Neukum Applied. -- To unsubscribe from this list: send the line "unsubscribe linux-usb"

Re: [PATCH 3/5] cdc-ether: switch to common CDC parser

From: Oliver Neukum Date: Mon, 7 Sep 2015 16:05:40 +0200 > This patch uses the common parser to parse extra CDC > headers in order to reduce code duplication. > > Signed-off-by: Oliver Neukum Applied. -- To unsubscribe from this list: send the line

Re: [PATCH v2 5/5] usb: gadget: mass_storage: allow for deeper queue lengths

hi, On Tue, Sep 15, 2015 at 03:24:19PM -0400, Alan Stern wrote: > > @@ -2662,7 +2662,7 @@ EXPORT_SYMBOL_GPL(fsg_common_put); > > /* check if fsg_num_buffers is within a valid range */ > > static inline int fsg_num_buffers_validate(unsigned int fsg_num_buffers) > > { > > - if (fsg_num_buffers

Re: [PATCH v4 3/4] usb: gadget: dummy_hcd: fix rescan logic for transfer

On Tue, 15 Sep 2015, Igor Kotrasinski wrote: > transfer() schedules a rescan for transfers larger than > maxpacket, which is wrong for transfers that are multiples > of maxpacket. > > Rewrite to fix and clarify packet multiple / remainder > transfer logic. > > Signed-off-by: Igor Kotrasinski

First kernel patch (optimization)

My first kernel patch, hope I did everything correctly! Instead of calling strlen on every iteration of the for loop, just call it once instead and store in a variable. Signed-off-by: Eric Curtin diff --git a/tools/usb/usbip/src/usbip_detach.c

Re: First kernel patch (optimization)

On Tue, Sep 15, 2015 at 08:53:28PM +0100, Eric Curtin wrote: > My first kernel patch, hope I did everything correctly! Instead of calling > strlen on every iteration of the for loop, just call it once instead and > store in a variable. this should be broken up at 72 characters. Also, your

Re: [PATCH v2 5/5] usb: gadget: mass_storage: allow for deeper queue lengths

On Tue, 15 Sep 2015, Felipe Balbi wrote: > Instead of allowing a range of 2 to 4 requests, > let's allow the user choose up to 32 requests > as that will give us a better chance of keeping > controller busy. > > We still maintain default of 2 so users shouldn't > be affected. > > Signed-off-by:

Re: [PATCH 5/5] cdc-phonet: use common parser

From: Oliver Neukum Date: Mon, 7 Sep 2015 16:05:42 +0200 > This moves cdc-phonet to the common parser for CDC users > to reduce code duplication. > > Signed-off-by: Oliver Neukum Applied. -- To unsubscribe from this list: send the line "unsubscribe

Re: [PATCH v2 0/5] usb: dwc3: throughput improvement

On Tue, Sep 15, 2015 at 02:16:03PM -0500, Felipe Balbi wrote: > Hi, > > with these patches (and, no, the mass storage patch is not extremely important > although it gives some nice extra improvement - about 1 MiB/sec extra in some > cases - at least not for USB2, I tested without that as well), I

Re: tools: usbip: detach: avoid calling strlen() at each iteration

Hi, On Tue, Sep 15, 2015 at 09:27:20PM +0100, Eric Curtin wrote: > Instead of calling strlen on every iteration of the for loop, just call it > once and cache the result in a temporary local variable which will be used > in the for loop instead. > > Signed-off-by: Eric Curtin

Re: xhci_hcd: unstable communication with Opella-XD JTAG probe

Hi Mathias, On Tue, 2015-09-15 at 16:18 +0300, Mathias Nyman wrote: > On 10.09.2015 14:54, Alexey Brodkin wrote: > I'm not sure what happens here, have you tried the 4.2 kernel? I've just tried vanilla 4.3-rc1 and see exactly the same picture. > If I send additional xhci debugging patches can

Re: PROBLEM: lsusb -v freezes kernel on Acer ES1-111M

Hi Alan, > However, note that CONFIG_PM_RUNTIME doesn't exist any more in 4.2; it > is now covered by CONFIG_PM. That explains why the setting was disabled in the first place. I had taken a config from 4.2 and ran "make oldconfig" on it with the 3.17 kernel. Actually, the configurations with

Re: PROBLEM: lsusb -v freezes kernel on Acer ES1-111M

On Tue, 15 Sep 2015, Roland Weber wrote: > Hi Alan, > > > > ehci_halt: premature readl returned 10001 > > > > Note: 10001 instead of 1, which is what you saw in the other > > kernel. That could be highly relevant. > > Really? And I thought that was the least significant bit... It is the

[PATCH 06/26] usb: gadget: f_acm: eliminate abuse of ep->driver data

Since ep->driver_data is not used for endpoint claiming, neither for enabled/disabled state storing, we can reduce number of places where we read or modify it's value, as now it has no particular meaning for function or framework logic. In case of f_acm we only need to store in ep->driver_data

[PATCH 19/26] usb: gadget: f_subset: eliminate abuse of ep->driver data

Since ep->driver_data is not used for endpoint claiming, neither for enabled/disabled state storing, we can reduce number of places where we read or modify it's value, as now it has no particular meaning for function or framework logic. In case of f_subset, ep->driver_data was used only for

[PATCH 17/26] usb: gadget: f_serial: eliminate abuse of ep->driver data

Since ep->driver_data is not used for endpoint claiming, neither for enabled/disabled state storing, we can reduce number of places where we read or modify it's value, as now it has no particular meaning for function or framework logic. In case of f_serial, ep->driver_data was used only for

[PATCH 26/26] usb: gadget: legacy: tcm: eliminate abuse of ep->driver data

Since ep->driver_data is not used for endpoint claiming, neither for enabled/disabled state storing, we can reduce number of places where we read or modify it's value, as now it has no particular meaning for function or framework logic. In case of tcm, ep->driver_data was used only for endpoint

[PATCH 24/26] usb: gadget: u_serial: eliminate abuse of ep->driver data

Since ep->driver_data is not used for endpoint claiming, neither for enabled/disabled state storing, we can reduce number of places where we read or modify it's value, as now it has no particular meaning for function or framework logic. In case of u_serial ep->driver_data stores pointer to struct

[PATCH 20/26] usb: gadget: f_uac1: eliminate abuse of ep->driver data

Since ep->driver_data is not used for endpoint claiming, neither for enabled/disabled state storing, we can reduce number of places where we read or modify it's value, as now it has no particular meaning for function or framework logic. In case of f_uac1, ep->driver_data was used only for

[PATCH 23/26] usb: gadget: u_ether: eliminate abuse of ep->driver data

Since ep->driver_data is not used for endpoint claiming, neither for enabled/disabled state storing, we can reduce number of places where we read or modify it's value, as now it has no particular meaning for function or framework logic. In case of u_ether we only need to store in ep->driver_data

[PATCH 22/26] usb: gadget: f_uvc: eliminate abuse of ep->driver data

Since ep->driver_data is not used for endpoint claiming, neither for enabled/disabled state storing, we can reduce number of places where we read or modify it's value, as now it has no particular meaning for function or framework logic. In case of f_uvc, ep->driver_data was used only for endpoint

[PATCH 18/26] usb: gadget: f_sourcesink: eliminate abuse of ep->driver data

Since ep->driver_data is not used for endpoint claiming, neither for enabled/disabled state storing, we can reduce number of places where we read or modify it's value, as now it has no particular meaning for function or framework logic. In case of f_sourcesink we only need to store in

[PATCH 25/26] usb: gadget: legacy: dbgp: eliminate abuse of ep->driver data

Since ep->driver_data is not used for endpoint claiming, neither for enabled/disabled state storing, we can reduce number of places where we read or modify it's value, as now it has no particular meaning for function or framework logic. In case of dbgp, ep->driver_data was used only for endpoint

[PATCH 21/26] usb: gadget: f_uac2: eliminate abuse of ep->driver data

Since ep->driver_data is not used for endpoint claiming, neither for enabled/disabled state storing, we can reduce number of places where we read or modify it's value, as now it has no particular meaning for function or framework logic. In case of f_uac2, ep->driver_data was used only for

Re: similar files: fusbh200-hcd.c and fotg210-hcd.c

On Mon, Sep 14, 2015 at 07:50:02PM +0200, Peter Senna Tschudin wrote: > On Mon, Sep 14, 2015 at 5:01 PM, Felipe Balbi wrote: > > On Sat, Sep 12, 2015 at 03:14:50PM +0200, Peter Senna Tschudin wrote: > >> >> Should these files be consolidated? And if so how? > >> > if you can find an

[PATCH 15/26] usb: gadget: f_printer: eliminate abuse of ep->driver data

Since ep->driver_data is not used for endpoint claiming, neither for enabled/disabled state storing, we can reduce number of places where we read or modify it's value, as now it has no particular meaning for function or framework logic. In case of f_printer we only need to store in

[PATCH 2/3] usb: phy: correct the am335x phy header filename

The filename of am35x-phy-control.h is confusing. The header is used by the am335x phy driver, but the filename refers to am35x. Even worse there is indeed another device called am35x but it does not use this header at all. Signed-off-by: Bin Liu ---

[PATCH 0/3] usb: phy: phy-am335x: support tying VBUS to 5V in host-only mode

To save cost and simply the design, most host-only application will directly tie VBUS to 5V power rail, but this prevents AM335x MUSB to transition to host mode due VBUS sensing for OTG state machine. These patches disable the first VBUS sensing in AM335x MUSB for host-only mode to enable this

[PATCH 3/3] usb: phy: phy-am335x: ignore first VBUS sensing for host-only mode

To prevent VBUS contention, the am335x MUSB phy senses VBUS first before transitioning to host mode. However, for host-only mode, VBUS could be directly tied to 5V power rail which could prevent MUSB transitions to host mode. This change receives dr_mode of the controller then ignores the first

Re: [Y2038] [PATCH] dummy_hcd: replace timeval with timespec64

On Tuesday, September 15, 2015 09:14 PM, Arnd Bergmann wrote: > On Tuesday 15 September 2015 20:56:15 WEN Pingbo wrote: >> The millisecond of the last second will be normal if tv_sec is >> overflowed. But for y2038 consistency and demonstration purpose, >> and avoiding further risks, we still

Re: [Y2038] [PATCH] dummy_hcd: replace timeval with timespec64

On Tuesday 15 September 2015 21:43:19 Pingbo Wen wrote: > > On Tuesday, September 15, 2015 09:14 PM, Arnd Bergmann wrote: > > On Tuesday 15 September 2015 20:56:15 WEN Pingbo wrote: > >> The millisecond of the last second will be normal if tv_sec is > >> overflowed. But for y2038 consistency and

[PATCH] dummy_hcd: replace timeval with timespec64

The millisecond of the last second will be normal if tv_sec is overflowed. But for y2038 consistency and demonstration purpose, and avoiding further risks, we still need to fix it here, to avoid similair problems. Signed-off-by: Pingbo Wen Cc: Y2038

[PATCH 1/3] usb: of: add an api to get dr_mode by the phy node

Some USB phy drivers have different handling for the controller in each dr_mode. But the phy driver does not have visibility to the dr_mode of the controller. This adds an api to return the dr_mode of the controller which associates the given phy node. Signed-off-by: Bin Liu ---

Re: [Y2038] [PATCH] dummy_hcd: replace timeval with timespec64

On Tuesday 15 September 2015 20:10:10 Pingbo Wen wrote: > On Tuesday, September 15, 2015 02:38 PM, Arnd Bergmann wrote: > > On Tuesday 15 September 2015 09:48:10 Pingbo Wen wrote: > - does the driver use monotonic or real time > Real time. But only microsecond part is used. > >

Re: [Y2038] [PATCH] dummy_hcd: replace timeval with timespec64

On Tuesday 15 September 2015 20:56:15 WEN Pingbo wrote: > The millisecond of the last second will be normal if tv_sec is > overflowed. But for y2038 consistency and demonstration purpose, > and avoiding further risks, we still need to fix it here, > to avoid similair problems. > > Signed-off-by:

Re: xhci_hcd: unstable communication with Opella-XD JTAG probe

On 10.09.2015 14:54, Alexey Brodkin wrote: Hello, I'm seeing a problem when attaching USB device (in my case Ashling Opella-XD JTAG probe) in Dell e7440 laptop if USB 3.0 is enable in BIOS. If I disable USB 3.0 in BIOS the same device works perfectly fine. What's also interesting on my

Re: [PATCH] Revert "usb: chipidea: usbmisc_imx: delete clock information"

Hi Peter, On Mon, Sep 14, 2015 at 11:32 PM, Fabio Estevam wrote: > This did not help. > > It is getting late here, so I will be able to try more things tomorrow. I was able to fix it. Your initial patch had a missing 'return 0' in imx_prepare_enable_clks(), causing:

[PATCH 14/26] usb: gadget: f_phonet: eliminate abuse of ep->driver data

Since ep->driver_data is not used for endpoint claiming, neither for enabled/disabled state storing, we can reduce number of places where we read or modify it's value, as now it has no particular meaning for function or framework logic. In case of f_phonet we only need to store in ep->driver_data

[PATCH 11/26] usb: gadget: f_midi: eliminate abuse of ep->driver data

Since ep->driver_data is not used for endpoint claiming, neither for enabled/disabled state storing, we can reduce number of places where we read or modify it's value, as now it has no particular meaning for function or framework logic. In case of f_midi we only need to store in ep->driver_data

[PATCH 16/26] usb: gadget: f_rndis: eliminate abuse of ep->driver data

Since ep->driver_data is not used for endpoint claiming, neither for enabled/disabled state storing, we can reduce number of places where we read or modify it's value, as now it has no particular meaning for function or framework logic. In case of f_rndis, ep->driver_data was used only for

[PATCH 12/26] usb: gadget: f_ncm: eliminate abuse of ep->driver data

Since ep->driver_data is not used for endpoint claiming, neither for enabled/disabled state storing, we can reduce number of places where we read or modify it's value, as now it has no particular meaning for function or framework logic. In case of f_ncm, ep->driver_data was used only for endpoint

[PATCH 13/26] usb: gadget: f_obex: eliminate abuse of ep->driver data

Since ep->driver_data is not used for endpoint claiming, neither for enabled/disabled state storing, we can reduce number of places where we read or modify it's value, as now it has no particular meaning for function or framework logic. In case of f_obex, ep->driver_data was used only for

[PATCH 05/26] usb: gadget: f_ecm: eliminate abuse of ep->driver data

Since ep->driver_data is not used for endpoint claiming, neither for enabled/disabled state storing, we can reduce number of places where we read or modify it's value, as now it has no particular meaning for function or framework logic. In case of f_ecm, ep->driver_data was used only for endpoint

[PATCH 01/26] usb: gadget: fix few outdated comments

Fix comments in code to make them up to date. composite: claiming endpoint is now done by setting ep->claimed flag, not ep->driver_data. epautoconf: usb_ep_autoconfig() and usb_ep_autoconfig_ss() return claimed endpoint with ep->claimed flag already set. Signed-off-by: Robert Baldyga

[PATCH 04/26] usb: gadget: introduce 'enabled' flag in struct usb_ep

This patch introduces 'enabled' flag in struct usb_ep, and modifies usb_ep_enable() and usb_ep_disable() functions to encapsulate endpoint enabled/disabled state. It helps to avoid enabling endpoints which are already enabled, and disabling endpoints which are already disables. >From now USB

[PATCH 03/26] usb: gadget: epautoconf: add usb_ep_autoconfig_release() function

This patch introduces usb_ep_autoconfig_release() function which allows to release endpoint previously obtained from usb_ep_autoconfig() during USB function bind. Signed-off-by: Robert Baldyga --- drivers/usb/gadget/epautoconf.c | 17 +

[PATCH 08/26] usb: gadget: f_hid: eliminate abuse of ep->driver data

Since ep->driver_data is not used for endpoint claiming, neither for enabled/disabled state storing, we can reduce number of places where we read or modify it's value, as now it has no particular meaning for function or framework logic. In case of f_hid we only need to store in ep->driver_data

  1   2   >