-Original Message-
From: Hans de Goede [mailto:hdego...@redhat.com]
Sent: Wednesday, September 10, 2014 8:33 PM
To: Peter Hurley; Greg Kroah-Hartman
Cc: linux-usb@vger.kernel.org; linux-s...@vger.kernel.org;
sta...@vger.kernel.org; Sharma, Sanjeev; Peter Zijlstra; Ingo Molnar
Subject: Re:
-Original Message-
From: Greg Kroah-Hartman [mailto:gre...@linuxfoundation.org]
Sent: Wednesday, September 10, 2014 7:21 PM
To: Hans de Goede
Cc: Oliver Neukum; linux-usb@vger.kernel.org; linux-s...@vger.kernel.org;
sta...@vger.kernel.org; Sharma, Sanjeev
Subject: Re: [PATCH 01/21] uas: r
Hi,
On Thursday, September 11, 2014 1:52 AM, "Julius Werner"
wrote
right, use that to call phy_init() at the right time, then you need to
add a new ->calibrate() method which, likely, will only be used by you
;-)
so you mean, the xhci should itself call phy_init() at a time suitable,
s
On Wed, Sep 03, 2014 at 09:48:27AM +0200, Antoine Tenart wrote:
> Document the USB2 ChipIdea driver (ci13xxx) bindings.
>
> Signed-off-by: Antoine Tenart
> ---
> .../devicetree/bindings/usb/ci-hdrc-usb2.txt | 22
> ++
> 1 file changed, 22 insertions(+)
> create mode 1
On Wed, Sep 03, 2014 at 09:48:26AM +0200, Antoine Tenart wrote:
> Add a USB2 ChipIdea driver for ci13xxx, with optional PHY, clock
> and DMA mask, to support USB2 ChipIdea controllers that don't need
> specific functions.
>
> Tested on the Marvell Berlin SoCs USB controllers.
>
> Signed-off-by: A
On Wed, Sep 03, 2014 at 09:40:40AM +0200, Antoine Tenart wrote:
> This patch adds support of the PHY framework for ChipIdea drivers.
> Changes are done in both the ChipIdea common code and in the drivers
> accessing the PHY. This is done by adding a new PHY member in
> ChipIdea's structures and by
On Wed, Sep 03, 2014 at 09:40:38AM +0200, Antoine Tenart wrote:
> This patch prepares the introduction of the generic PHY support in the
> USB ChipIdea common functions. The USB PHY member of the ChipIdea
> structure ('transceiver') is renamed to 'usb_phy', the 'phy' member of
> the ChipIdea pdata
On Wed, Sep 03, 2014 at 09:40:39AM +0200, Antoine Tenart wrote:
> Move the usb_otg member from struct usb_phy to struct ci_hdrc. Rework
> its initialization taking in account this modification.
>
> Signed-off-by: Antoine Tenart
> ---
> drivers/usb/chipidea/ci.h | 1 +
> drivers/usb/chipide
Hi Morimoto-san,
(2014/09/11 8:56), Kuninori Morimoto wrote:
>
> Hi Shimoda-san
>
>> --- a/drivers/usb/renesas_usbhs/mod_gadget.c
>> +++ b/drivers/usb/renesas_usbhs/mod_gadget.c
>> @@ -602,6 +602,9 @@ static int usbhsg_ep_disable(struct usb_ep *ep)
>> struct usbhsg_uep *uep = usbhsg_ep_to_u
Hi Greg,
Below patches are fixes for qualcomm part at chipidea, the user
needs it very much, thanks.
http://www.spinics.net/lists/linux-usb/msg113233.html
Ivan T. Ivanov (2):
usb: chipidea: msm: Use USB PHY API to control PHY state
usb: chipidea: msm: Initialize PHY on reset event
drivers/
Hi,
(2014/09/10 22:49), Felipe Balbi wrote:
> On Wed, Sep 10, 2014 at 07:33:40PM +0900, Yoshihiro Shimoda wrote:
>> This patch fixes an issue that the NULL pointer dereference happens
>> when we use g_audio driver. Since the g_audio driver will call
>> usb_ep_disable() in afunc_set_alt() before it
Hi Felipe,
(2014/09/10 22:49), Felipe Balbi wrote:
> On Wed, Sep 10, 2014 at 07:33:27PM +0900, Yoshihiro Shimoda wrote:
>> If we tested this driver as gadget, some issues below happened:
>> - Oops happened if g_audio.
>> - A usb enumeration may fail if we do insmod during connected the usb cable
On Thu, Sep 11, 2014 at 07:57:12AM +0800, Peter Chen wrote:
> On Fri, Sep 05, 2014 at 10:08:02AM -0400, Alan Stern wrote:
> > On Fri, 5 Sep 2014, Peter Chen wrote:
> >
> > > On Thu, Sep 04, 2014 at 11:12:42AM -0400, Alan Stern wrote:
> > > > On Thu, 4 Sep 2014, Peter Chen wrote:
> > > >
> > > > >
On Fri, Sep 05, 2014 at 10:08:02AM -0400, Alan Stern wrote:
> On Fri, 5 Sep 2014, Peter Chen wrote:
>
> > On Thu, Sep 04, 2014 at 11:12:42AM -0400, Alan Stern wrote:
> > > On Thu, 4 Sep 2014, Peter Chen wrote:
> > >
> > > > On Wed, Sep 03, 2014 at 09:48:15PM -0400, Alan Stern wrote:
> > > > > On
Hi Shimoda-san
> --- a/drivers/usb/renesas_usbhs/mod_gadget.c
> +++ b/drivers/usb/renesas_usbhs/mod_gadget.c
> @@ -602,6 +602,9 @@ static int usbhsg_ep_disable(struct usb_ep *ep)
> struct usbhsg_uep *uep = usbhsg_ep_to_uep(ep);
> struct usbhs_pipe *pipe = usbhsg_uep_to_pipe(uep);
>
>
On Wednesday 10 September 2014 17:18:27 Alan Stern did opine
And Gene did reply:
> On Wed, 10 Sep 2014, Gene Heskett wrote:
> > On Wednesday 10 September 2014 15:17:24 Randy Dunlap wrote:
> >
> > Adding linux-usb, perhaps someone there can tell me how to tame this
> > beast.
> >
> > > On 09/10/14
On Wed, 10 Sep 2014, Gene Heskett wrote:
> On Wednesday 10 September 2014 15:17:24 Randy Dunlap wrote:
>
> Adding linux-usb, perhaps someone there can tell me how to tame this
> beast.
>
> > On 09/10/14 12:02, Gene Heskett wrote:
> > > On Wednesday 10 September 2014 14:30:22 Randy Dunlap wrote:
On Wednesday 10 September 2014 15:17:24 Randy Dunlap wrote:
Adding linux-usb, perhaps someone there can tell me how to tame this
beast.
> On 09/10/14 12:02, Gene Heskett wrote:
> > On Wednesday 10 September 2014 14:30:22 Randy Dunlap wrote:
> >> On 09/10/14 07:47, Gene Heskett wrote:
> >>> Greet
On 14-09-10 08:13 AM, Hans de Goede wrote:
Hi All,
I'm mailing all of you because you've reported various problems
with the new uas support in kernel 3.16 and later.
I've been working on making the uas driver more resilient to
errors, as well as improved logging so we can easier figure
out the
On Tue, Sep 09, 2014 at 10:44:51AM +0200, Robert Baldyga wrote:
> Hi,
>
> I have splitted my patchset "usb: dwc2/gadget: fix series" into two series.
> This patch series contains improvements for dwc2/gadget driver. It's intended
> for 3.18.
>
> Andrzej Pietrasiewicz (1):
> usb: dwc2/gadget: Fi
On Wed, 10 Sep 2014, Felipe Balbi wrote:
> Hi,
>
> On Wed, Sep 10, 2014 at 11:02:23PM +0400, Matwey V. Kornilov wrote:
> > 2014-09-10 19:53 GMT+04:00 Felipe Balbi :
> > > you probably need a USB sniffer. usbmon (Documentation/usb/usbmon.txt)
> > > will help to some extent, but some details can on
On Wed, Sep 10, 2014 at 03:43:08PM -0400, Alan Stern wrote:
> On Wed, 10 Sep 2014, Joe Lawrence wrote:
>
> > Hi Alan,
> >
> > Here is a revised patch for yesterday's use-after-free bug report. I
> > moved the hdev assignment and reference inside the hub_event_lock, then
> > returned the ref on t
>> right, use that to call phy_init() at the right time, then you need to
>> add a new ->calibrate() method which, likely, will only be used by you
>> ;-)
> so you mean, the xhci should itself call phy_init() at a time suitable,
> so that ->calibrate() is not required at all ?
I'm not sure if tha
Hi,
On Wed, Sep 10, 2014 at 11:02:23PM +0400, Matwey V. Kornilov wrote:
> 2014-09-10 19:53 GMT+04:00 Felipe Balbi :
> > you probably need a USB sniffer. usbmon (Documentation/usb/usbmon.txt)
> > will help to some extent, but some details can only be seen with a hw
> > sniffer.
>
> Hi
>
> To this
On Wed, 10 Sep 2014, Joe Lawrence wrote:
> Hi Alan,
>
> Here is a revised patch for yesterday's use-after-free bug report. I
> moved the hdev assignment and reference inside the hub_event_lock, then
> returned the ref on the way out of hub_events.
>
> Ordering is now symmetric:
>
> kref_get(&h
On Tue, 9 Sep 2014 14:29:11 -0400
Alan Stern wrote:
> On Tue, 9 Sep 2014, Joe Lawrence wrote:
>
> > On Tue, 9 Sep 2014 11:30:24 -0400
> > Alan Stern wrote:
> >
> > > On Tue, 9 Sep 2014, Joe Lawrence wrote:
> >
> > > > In summary, khubd has initialized the usb_device maxchild to 8 and
> > > >
Hi Alan,
Here is a revised patch for yesterday's use-after-free bug report. I
moved the hdev assignment and reference inside the hub_event_lock, then
returned the ref on the way out of hub_events.
Ordering is now symmetric:
kref_get(&hub->kref)
usb_get_dev(hdev)
usb_lock_device(hdev)
...
usb_un
2014-09-10 19:53 GMT+04:00 Felipe Balbi :
> you probably need a USB sniffer. usbmon (Documentation/usb/usbmon.txt)
> will help to some extent, but some details can only be seen with a hw
> sniffer.
Hi
To this moment I've found the following. Angstrom 3.8 works as
expected, 3.16 also works until i
Hi Robert,
On 09/10/2014 06:08 PM, Elliott, Robert (Server Storage) wrote:
>
>
>> -Original Message-
>> From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi-
>> ow...@vger.kernel.org] On Behalf Of Hans de Goede
>> Sent: Wednesday, 10 September, 2014 6:47 AM
>> To: Greg Kroah-Hartman
On Wed, Sep 10, 2014 at 05:50:25PM +0200, Michal Nazarewicz wrote:
> Even though the BUG() in __ffs_event_add is a dead-code, it is still
> better to warn rather then crash the system if that code ever gets
> executed.
>
> Suggested-by: Felipe Balbi
> Signed-off-by: Michal Nazarewicz
> ---
> Th
> -Original Message-
> From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi-
> ow...@vger.kernel.org] On Behalf Of Hans de Goede
> Sent: Wednesday, 10 September, 2014 6:47 AM
> To: Greg Kroah-Hartman
> Cc: linux-usb@vger.kernel.org; linux-s...@vger.kernel.org;
> sta...@vger.kernel.or
On Wed, Sep 10, 2014 at 06:45:32PM +0400, Matwey V. Kornilov wrote:
> 2014-09-10 17:52 GMT+04:00 Felipe Balbi :
> > Hi,
> >
> > On Wed, Sep 10, 2014 at 11:06:05AM +0400, Matwey V. Kornilov wrote:
> >> 2014-09-09 22:20 GMT+04:00 Felipe Balbi :
> >> > oh, so it's not really a BBB. I have never seen a
Instead of using variable length array, use a static length equal to
the size of the ffs->ev.types array. This gets rid of a sparse warning:
drivers/usb/gadget/function/f_fs.c:401:44: warning:
Variable length array is used.
and makes it more explicit that the array has a very tig
Even though the BUG() in __ffs_event_add is a dead-code, it is still
better to warn rather then crash the system if that code ever gets
executed.
Suggested-by: Felipe Balbi
Signed-off-by: Michal Nazarewicz
---
This has been compile tested only.
drivers/usb/gadget/function/f_fs.c | 4 +++-
1 f
On Wed, Sep 10, 2014 at 09:21:24AM +0200, Hans de Goede wrote:
> I've applied the patch, this results in the following new dmesg output
> when using uas:
>
> [ 120.602632] initialized host-wide tag map!
>
> Thank you for looking into this.
So we're initializing the tag map, but scsi_activate_tc
Hi,
On 09/10/2014 04:38 PM, Peter Hurley wrote:
> [ +cc Peter Zijlstra, Ingo Molnar ]
>
> On 09/10/2014 07:46 AM, Hans de Goede wrote:
>> From: Sanjeev Sharma
>>
>> On some architecture spin_is_locked() always return false in
>> uniprocessor configuration and therefore it would be advise to repl
On Wed, 10 Sep 2014, Kasberger Andreas wrote:
> We have a problem with a CDC device that simulates a serial
> interface. Problem is that the host stops CDC BULK IN transfers after
> a while on those USB2.0 ports that are connected to the chip set's
> internal rate matching hub, others seem to work
2014-09-10 17:52 GMT+04:00 Felipe Balbi :
> Hi,
>
> On Wed, Sep 10, 2014 at 11:06:05AM +0400, Matwey V. Kornilov wrote:
>> 2014-09-09 22:20 GMT+04:00 Felipe Balbi :
>> > oh, so it's not really a BBB. I have never seen an EMBEST RevB3. Do you
>> > have access to that board's accessory and/or a real
[ +cc Peter Zijlstra, Ingo Molnar ]
On 09/10/2014 07:46 AM, Hans de Goede wrote:
> From: Sanjeev Sharma
>
> On some architecture spin_is_locked() always return false in
> uniprocessor configuration and therefore it would be advise to replace
> with lockdep_assert_held().
>
> Signed-off-by: Sanj
On Wed, 10 Sep 2014, Oliver Neukum wrote:
> On Tue, 2014-09-09 at 14:33 -0400, Alan Stern wrote:
>
> > Only runtime D3cold would be affected. System suspend would still be
> > able to use D3cold.
>
> Yes. But it looks like system suspend is on the way out in the long run.
Regardless, this is
On Wednesday 10 September 2014 19:25:11 sundeep subbaraya wrote:
> > that's not exactly what I asked Usually you only add COMPILE_TEST
> > when you have an ARCH dependency. So something like:
> >
> > depends on ARCH_ARM || COMPILE_TEST
> >
> > would make it clear that this driver is only a
Hi,
On 09/10/2014 04:10 PM, Oliver Neukum wrote:
> On Wed, 2014-09-10 at 13:46 +0200, Hans de Goede wrote:
>> uas_log_cmd_state(cmnd, __func__);
>> - /* all urbs are killed, clear inflight bits */
>> - cmdinfo->state &= ~(COMMAND_INFLIGHT |
>> -
On Wed, 2014-09-10 at 13:46 +0200, Hans de Goede wrote:
> uas_log_cmd_state(cmnd, __func__);
> - /* all urbs are killed, clear inflight bits */
> - cmdinfo->state &= ~(COMMAND_INFLIGHT |
> - DATA_IN_URB_INFLIGHT |
> -
Hi,
On 09/10/2014 04:06 PM, Oliver Neukum wrote:
> On Wed, 2014-09-10 at 13:46 +0200, Hans de Goede wrote:
>> I've access to a number of different uas devices now, and none of them use
>> old style sense urbs. The only case where these code-paths trigger is with
>> the asm1051 and there they do th
On Wed, 2014-09-10 at 13:46 +0200, Hans de Goede wrote:
> I've access to a number of different uas devices now, and none of them use
> old style sense urbs. The only case where these code-paths trigger is with
> the asm1051 and there they do the wrong thing, as the asm1051 sends 8 bytes
> status iu
Hi,
On 09/10/2014 04:00 PM, Oliver Neukum wrote:
> On Wed, 2014-09-10 at 13:46 +0200, Hans de Goede wrote:
>> Check for both type of cancellation codes for sense and data urbs.
>
> Then you should also check for -ESHUTDOWN (unplug of HC)
The intent here is to stop log pollution when cancelling b
On Wed, 2014-09-10 at 13:46 +0200, Hans de Goede wrote:
> Check for both type of cancellation codes for sense and data urbs.
Then you should also check for -ESHUTDOWN (unplug of HC)
Regards
Oliver
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
Hi Felipe,
On Thu, Aug 21, 2014 at 7:30 PM, Felipe Balbi wrote:
> On Thu, Aug 21, 2014 at 12:19:03PM +0530, sundeep subbaraya wrote:
>> Hi Daniel,
>>
>> On Tue, Aug 19, 2014 at 3:26 PM, Daniel Mack wrote:
>> > Hi,
>> >
>> > On 07/22/2014 11:08 AM, Subbaraya Sundeep Bhatta wrote:
>> >> This patch
Xilinx USB2 device is a soft IP which supports both full
and high speed USB 2.0 data transfers. This patch adds
xilinx usb2 device driver support.
Signed-off-by: Subbaraya Sundeep Bhatta
---
Changes for v5:
- used devm_kzalloc instead of kzalloc
- used snprintf instead of sprintf
Add devicetree bindings for Xilinx udc driver.
Signed-off-by: Subbaraya Sundeep Bhatta
---
Changes for v5:
- None
Changes for v4:
- renamed xlnx,axi-usb2-device-4.00.a to xlnx,usb2-device-4.00.a
Changes for v3:
- None
Changes for v2:
- replaced xlnx,include-dma wit
Hi,
On Wed, Sep 10, 2014 at 11:06:05AM +0400, Matwey V. Kornilov wrote:
> 2014-09-09 22:20 GMT+04:00 Felipe Balbi :
> > oh, so it's not really a BBB. I have never seen an EMBEST RevB3. Do you
> > have access to that board's accessory and/or a real BBB to check ?
>
> They claim it is just A5A. So,
On Wed, Sep 10, 2014 at 03:15:41PM +0200, Hans de Goede wrote:
> Hi,
>
> On 09/10/2014 02:54 PM, Oliver Neukum wrote:
> > On Wed, 2014-09-10 at 14:00 +0200, Hans de Goede wrote:
> >> Hi,
> >>
> >> On 09/10/2014 01:56 PM, Oliver Neukum wrote:
> >>> On Wed, 2014-09-10 at 13:48 +0200, Hans de Goede w
On Wed, Sep 10, 2014 at 07:34:13PM +0900, Yoshihiro Shimoda wrote:
> Since the DCPCTR doesn't have the ACLRM bit, the usbus_pipe_clear()
> should not call the usbhsp_pipectrl_set() with ACLRM.
> So, this patch fixes this issue to add the usbhs_fifo_clear_dcp()
> in fifo.c because the controller nee
On Wed, Sep 10, 2014 at 07:34:05PM +0900, Yoshihiro Shimoda wrote:
> According to the datasheet, this driver should clear the INTSTS0.CTRT
> bit before this controller detects the next stage transition. Otherwise,
> the driver may not be able to clear the bit after the controller went to
> the next
On Wed, Sep 10, 2014 at 07:33:52PM +0900, Yoshihiro Shimoda wrote:
> This patch fixes an issue that this driver always enable the D+ pullup
> after it detected the VBUS connection even though this usb controller
> can control the D+ pullup timing by software. So, this driver should
> enable the D+
Hi,
First of all, thank you for reviewing this.
On 09/10/2014 03:40 PM, Oliver Neukum wrote:
> On Wed, 2014-09-10 at 13:46 +0200, Hans de Goede wrote:
>> - Make sure we always hold the lock when setting / checking resetting
>> - Check resetting before checking urb->status
>> - Add missing check f
On Wed, Sep 10, 2014 at 07:33:27PM +0900, Yoshihiro Shimoda wrote:
> If we tested this driver as gadget, some issues below happened:
> - Oops happened if g_audio.
> - A usb enumeration may fail if we do insmod during connected the usb cable.
> - A transaction will not finish if g_zero.
> - A us
On Wed, Sep 10, 2014 at 07:33:40PM +0900, Yoshihiro Shimoda wrote:
> This patch fixes an issue that the NULL pointer dereference happens
> when we use g_audio driver. Since the g_audio driver will call
> usb_ep_disable() in afunc_set_alt() before it calls usb_ep_enable(),
> the uep->pipe of renesas
Hi,
On Wed, Sep 10, 2014 at 03:36:44PM +0200, François MULLER wrote:
> >you haven't missed anything, you're correct. Do you want to send this in
> >a proper patch format so it's included in all supported kernels which
> >are affected by this bug ?
> >
> >Please have a read at Documentation/CodingS
On Wed, 2014-09-10 at 13:46 +0200, Hans de Goede wrote:
> - Make sure we always hold the lock when setting / checking resetting
> - Check resetting before checking urb->status
> - Add missing check for resetting to uas_data_cmplt
> - Add missing check for resetting to uas_do_work
Why is the checki
Hi,
Le 09/09/2014 16:57, Felipe Balbi a écrit :
you haven't missed anything, you're correct. Do you want to send this in
a proper patch format so it's included in all supported kernels which
are affected by this bug ?
Please have a read at Documentation/CodingStyle,
Documentation/SubmittingPatc
On Wed, 2014-09-10 at 13:46 +0200, Hans de Goede wrote:
> This commit removes the abort / lun-reset error handling paths, and also the
> taks-mgmt code since those are the only 2 task-mgmt users. Leaving only the
> (tested and testable) usb-device-reset error handling path in place.
>
> Note I re
Hi,
On 09/10/2014 02:54 PM, Oliver Neukum wrote:
> On Wed, 2014-09-10 at 14:00 +0200, Hans de Goede wrote:
>> Hi,
>>
>> On 09/10/2014 01:56 PM, Oliver Neukum wrote:
>>> On Wed, 2014-09-10 at 13:48 +0200, Hans de Goede wrote:
Hi,
Note this series is NOT intended for stable, but I acc
Hi Andreas,
I'd like to reproduce this problem in the lab. How can I get a CDC device?
Thanks,
-baolu
On 9/10/2014 3:04 PM, Kasberger Andreas wrote:
So I am back with more tests on this problem.
Intel itself told us it is a problem on the driver for the XHCI host
controller. I will put some s
On Wed, 2014-09-10 at 14:00 +0200, Hans de Goede wrote:
> Hi,
>
> On 09/10/2014 01:56 PM, Oliver Neukum wrote:
> > On Wed, 2014-09-10 at 13:48 +0200, Hans de Goede wrote:
> >> Hi,
> >>
> >> Note this series is NOT intended for stable, but I accidentally
> >> had "cc = sta...@vger.kernel.org" in my
On Wed, Sep 03, 2014 at 10:37:39AM -0500, Sergio De León wrote:
> On 09/03/2014 03:43 AM, Johan Hovold wrote:
> > On Tue, Sep 02, 2014 at 03:43:52PM -0500, Sergio De León wrote:
> >> Here are the debug logs you asked me
> >>
> >> * dmesg output while connecting the device without dynamic debug
> >
Hi All,
I'm mailing all of you because you've reported various problems
with the new uas support in kernel 3.16 and later.
I've been working on making the uas driver more resilient to
errors, as well as improved logging so we can easier figure
out the cause of errors.
I would like to ask you all
Hi,
On 09/10/2014 01:56 PM, Oliver Neukum wrote:
> On Wed, 2014-09-10 at 13:48 +0200, Hans de Goede wrote:
>> Hi,
>>
>> Note this series is NOT intended for stable, but I accidentally
>> had "cc = sta...@vger.kernel.org" in my .git/config when sending
>> this series, please ignore for stable.
>>
>
-Original Message-
From: Oliver Neukum [mailto:oneu...@suse.de]
Sent: Wednesday, September 10, 2014 5:26 PM
To: Hans de Goede
Cc: Greg Kroah-Hartman; linux-usb@vger.kernel.org; linux-s...@vger.kernel.org;
sta...@vger.kernel.org; Sharma, Sanjeev
Subject: Re: [PATCH 01/21] uas: replace WARN
On Wed, 2014-09-10 at 13:48 +0200, Hans de Goede wrote:
> Hi,
>
> Note this series is NOT intended for stable, but I accidentally
> had "cc = sta...@vger.kernel.org" in my .git/config when sending
> this series, please ignore for stable.
>
> NACK for stable.
If this is not for stable, what do yo
Now that we no longer drop our lock to unlink the data urbs, we can simply
free them on completion, making their handling consistent with the other urbs.
Signed-off-by: Hans de Goede
---
drivers/usb/storage/uas.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/us
- Make sure we always hold the lock when setting / checking resetting
- Check resetting before checking urb->status
- Add missing check for resetting to uas_data_cmplt
- Add missing check for resetting to uas_do_work
Signed-off-by: Hans de Goede
---
drivers/usb/storage/uas.c | 49 +++
Hi,
Note this series is NOT intended for stable, but I accidentally
had "cc = sta...@vger.kernel.org" in my .git/config when sending
this series, please ignore for stable.
NACK for stable.
Sorry & Regards,
Hans
On 09/10/2014 01:46 PM, Hans de Goede wrote:
> From: Sanjeev Sharma
>
> On some
The data urbs are all killed before calling zap_pending, and their completion
handler should have cleared their inflight flag.
Do not 0 the data inflight flags, and add a check for try_complete succeeding,
as it should always succeed when called from zap_pending.
Signed-off-by: Hans de Goede
---
Factor out the mapping of scsi-tags -> uas-tags/stream-ids to a helper function
so that there is a single place where this "magic" happens.
Signed-off-by: Hans de Goede
---
drivers/usb/storage/uas.c | 33 +
1 file changed, 21 insertions(+), 12 deletions(-)
diff -
Do not keep references around to a cmnd which is under error handling.
Signed-off-by: Hans de Goede
---
drivers/usb/storage/uas.c | 47 ---
1 file changed, 44 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/storage/uas.c b/drivers/usb/storage/u
It was only used to sanity check against completing the same cmnd twice,
but that is the case we're likely operating on free-ed memory, and doing
sanity checks on free-ed memory is not really helpful.
Signed-off-by: Hans de Goede
---
drivers/usb/storage/uas.c | 10 +++---
1 file changed, 3 i
Check for both type of cancellation codes for sense and data urbs.
Signed-off-by: Hans de Goede
---
drivers/usb/storage/uas.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/storage/uas.c b/drivers/usb/storage/uas.c
index 685eb37..46b8788 100644
--- a/drive
The purpose of uas_pre_reset is to:
1) Stop any new commands from being submitted while an externally triggered
usb-device-reset is running
2) Wait for any pending commands to finish before allowing the usb-device-reset
to continue
The purpose of uas_suspend is to:
2) Wait for any pending c
Drop the whole dance with first moving cmnds to a dead-list. The resetting
flag ensures that no new cmds / urbs will be submitted, and that any urb
completions are short-circuited without trying to complete the scsi cmnd.
Signed-off-by: Hans de Goede
---
drivers/usb/storage/uas.c | 43 ++
There are various bug reports about oopses / hangs with the uas driver,
which all point to the abort-command and logical-unit-reset (task-management)
error handling paths.
Getting these right is very hard, there are quite a few corner cases, and
testing is almost impossible since under normal oper
We've removed all hack from the driver for pre-production hardware.
Signed-off-by: Hans de Goede
---
drivers/usb/storage/uas.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/usb/storage/uas.c b/drivers/usb/storage/uas.c
index 23c0b97..a7f16c4 100644
--- a/drivers/usb/storage/uas.c
From: Sanjeev Sharma
On some architecture spin_is_locked() always return false in
uniprocessor configuration and therefore it would be advise to replace
with lockdep_assert_held().
Signed-off-by: Sanjeev Sharma
Signed-off-by: Hans de Goede
---
drivers/usb/storage/uas.c | 8
1 file ch
Limit the no-streams case to speeds less then USB_SPEED_SUPER.
Signed-off-by: Hans de Goede
---
drivers/usb/storage/uas.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/storage/uas.c b/drivers/usb/storage/uas.c
index aaca65b..685eb37 100644
--- a/drivers/usb/stor
Using scsi_host_find_tag with tags returned by the device is unsafe for
multiple reasons:
1) It returns tags->rqs[tag], which may be non NULL even when the cmnd is
not owned by us
2) It returns tags->rqs[tag], without holding any locks protecting it
3) It returns tags->rqs[tag], without doing a
Use scsi_print_command to print commands during errors, rather then printing
the rather meaningless pointer to the command.
Signed-off-by: Hans de Goede
---
drivers/usb/storage/uas.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/storage/uas.c b/drivers/usb/
We've the same info doubled in both the inflight list and the cmnd array,
drop the list.
Signed-off-by: Hans de Goede
---
drivers/usb/storage/uas.c | 31 ---
1 file changed, 16 insertions(+), 15 deletions(-)
diff --git a/drivers/usb/storage/uas.c b/drivers/usb/storag
It is not strictly necessary for the cmd urb to have a reference to the
cmnd, and without this reference it becomes easier to drop all references to
a cmnd on an abort.
Signed-off-by: Hans de Goede
---
drivers/usb/storage/uas.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff
The status urb should not complete before the command has been submitted, nor
should we get a second status urb for the same tag after a IU_ID_STATUS.
Data urbs should not complete before the command has been submitted, but may
complete after the IU_ID_STATUS.
Signed-off-by: Hans de Goede
---
d
Not all urbs we've allocated are necessarily also submitted, non-submitted
urbs will not be free-ed by their completion handler. So we need to free
them manually.
There are 2 scenarios where this can happen:
1) We have failed to submit some urbs at abort / disconnect
2) When running over usb-2 we
I've access to a number of different uas devices now, and none of them use
old style sense urbs. The only case where these code-paths trigger is with
the asm1051 and there they do the wrong thing, as the asm1051 sends 8 bytes
status iu-s when it does not have any sense data, but uses new style
sens
There is no need for all the trickery with dropping the lock, we can
simply reference the urbs while we hold the lock to ensure the urbs don't
disappear beneath us, and do the actual unlink (+ unreference) after we've
dropped the lock.
This also fixes a race where we may loose of cmnd ownership to
Hi Greg, et al,
Since we've been receiving multiple bug reports with crashes / oopses related
to uas error handling, I've spend the last 7 days rewriting the error handling
code. This new code has been extensively tested, doing externally triggered
usb-device-resets and scsi bus resets while havin
Dear All,
I'm writing to let you know that three series of patch:
>From mailing list:
- Add import from/export to file functionality
- Small fixes and clean up
Form pull request to libusbg:
- Fix out-of-tree builds[1]
Has been merged into master branch of my github repository[2]. Feel free
to
On Tue, Sep 09, 2014 at 06:37:02PM +0200, Michal Nazarewicz wrote:
> On Tue, Sep 09 2014, Dan Carpenter wrote:
> > On Tue, Sep 09, 2014 at 03:57:26PM +0200, Michal Nazarewicz wrote:
> >> On Tue, Sep 09 2014, Dan Carpenter wrote:
> >> > Btw, there is a sparse warning:
> >> >
> >> > drivers/usb/gad
> On Fri, 2014-09-05 at 09:01 +0800, Peter Chen wrote:
> > On Thu, Sep 04, 2014 at 07:47:40AM -0700, Tim Bird wrote:
> > > On Fri, Aug 15, 2014 at 12:08 AM, Ivan T. Ivanov
> wrote:
> > > > On Fri, 2014-08-15 at 08:23 +0800, Peter Chen wrote:
> > > >> On Thu, Aug 14, 2014 at 11:54:02AM -0500, Fel
Since the DCPCTR doesn't have the ACLRM bit, the usbus_pipe_clear()
should not call the usbhsp_pipectrl_set() with ACLRM.
So, this patch fixes this issue to add the usbhs_fifo_clear_dcp()
in fifo.c because the controller needs the CFIFO to clear the
DCP PIPE.
Signed-off-by: Yoshihiro Shimoda
---
According to the datasheet, this driver should clear the INTSTS0.CTRT
bit before this controller detects the next stage transition. Otherwise,
the driver may not be able to clear the bit after the controller went to
the next stage transition. After that, the driver will not be able to
clear the INT
This patch fixes an issue that this driver always enable the D+ pullup
after it detected the VBUS connection even though this usb controller
can control the D+ pullup timing by software. So, this driver should
enable the D+ pullup after a gadget driver called usb_gadget_connect().
Signed-off-by: T
If we tested this driver as gadget, some issues below happened:
- Oops happened if g_audio.
- A usb enumeration may fail if we do insmod during connected the usb cable.
- A transaction will not finish if g_zero.
- A usb enumeration may fail after we re-connected the usb cable.
This patch seria
1 - 100 of 121 matches
Mail list logo
