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 a/drivers/usb/chipidea/ci_hdrc_imx.c
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
state
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
Cc: linux-ker...@vger.kernel.org
Cc: Arnd Berg
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.
>
>
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:
clk_disable_unprepare(data-
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 previous
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: P
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
---
drivers/usb/com
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 nee
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
---
drivers/usb/phy/phy-am335x-control.c
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 use
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
VB
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 d
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
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 poi
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 endpoi
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 cl
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
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 endpoi
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 endpoint
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 p
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 c
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 endpoint
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
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 ep->driver_d
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 ep->driver_data
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 easy way, that
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
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 po
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 endpoin
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
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 endpoint
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 poi
The 'driver_data' field in ep0 is never set to pointer to cdev, so we
have to obtain it from another source as in this context ep->driver_data
contains invalid data.
Signed-off-by: Robert Baldyga
---
drivers/usb/gadget/function/f_ncm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
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 either of those matter.
> >
> > Using jiffies_to_msecs() here is a nice way. According to USB 2.0 Spec,
> > however, the frame time
Hi Felipe,
There is my next patches series containing few fixes and slightly
reworking USB gadget function API. It introduces ep->enabled flag which
indicates whether endpointis enabled or not, and encapsulates its checking
and setting into usb_ep_enable() and usb_ep_disable() functions. So now
th
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
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
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
---
drive
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 funct
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 +
include/linux/usb/gadget.h | 2 ++
2
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 poi
On 06/09/15 05:20, Peter Chen wrote:
> On Wed, Sep 02, 2015 at 09:43:38AM -0500, Felipe Balbi wrote:
>> Hi,
>>
>>> +
>>> +static irqreturn_t dwc3_otg_irq(int irq, void *_dwc)
>>> +{
>>> + struct dwc3 *dwc = _dwc;
>>> + irqreturn_t ret = IRQ_NONE;
>>> + u32 reg;
>>> +
>>> + spin_lock(&dwc->l
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_mass_storage we only need to store in ep->driver
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 either of those matter.
> > >
> > > Using jiffies_to_msecs() here
currently, when a zlp flag is set and an urb/usb_request
buffer is filled without a short packet, transfer() leaves
its status at -EINPROGRESS and does not rescan for short
packet.
In a scenario where ep.maxpacket bytes are copied,
URB_ZERO_PACKET is set, urb buffer is filled and usb_request
buffe
Fix some issues with dummy_hcd transfer simulation - incorrect
short packets and overwritten bandwidth limits.
Igor Kotrasinski (4):
usb: gadget: dummy_hcd: emulate sending zlp in packet logic
usb: gadget: dummy_hcd: fix unneeded else-if condition
usb: gadget: dummy_hcd: fix rescan logic for
dummy_timer uses transfer() to update transfer limit. However,
limit passed to dummy_timer changes depending on transfer type,
so the actual limit is overwritten.
This can cause unpredictably slow / fast bulk transfers when
coupled with control / interrupt transfers.
Fix by returning actual amoun
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
---
drivers/usb/gadget/udc/dummy_hcd.c | 13 -
1 fi
We already know at this point that to_host is false.
Signed-off-by: Igor Kotrasinski
---
drivers/usb/gadget/udc/dummy_hcd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/udc/dummy_hcd.c
b/drivers/usb/gadget/udc/dummy_hcd.c
index df11021..da38475 100644
-
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 en
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.
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
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 t
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 in
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 encapsulat
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 code
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:
>> >> >> Should these files be consolidat
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:
> >> > On Sat, Sep 12, 2015 at 03:1
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 whe
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
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 insertions(+)
diff --git a
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(+), 1 deletion(-)
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
--
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
---
driv
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 17M
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 use
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
drivers/usb/phy/phy-am335x-con
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
---
v2: move drivers
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
VBU
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 ins
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
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
--
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(+), 1 deletion(-)
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
---
driv
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 backin
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
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 insertions(+)
diff --git
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
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:
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
>
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.
--
To unsubscribe from this list: send
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" in
the body of a message to majord..
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" in
the body of a message to majord...
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 "unsubscribe linux-usb" in
the body of a mes
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 linux-usb" in
the body of a message to major
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
b/tools/usb/usbip/src/usbip_detach.c
index 05c6d1
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 subjec
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
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
b/tools/usb/usbip/src/usbip_detach.c
index 05
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 CO
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
>
> diff --git a/t
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 y
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
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 s
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
> +++ b/tools/usb/usbip/src/usbip_detach.c
> @@
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 either
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 a/Documentation/devicetree/bindings/usb/
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 -
1 file changed, 120 insertio
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] *
1 - 100 of 127 matches
Mail list logo
