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, I've booted into Angstrom with kernel
3.8.6 (which is preinstalled on eMMC), and U
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 stuff here now what I goo from Intel:
Let me explain why I came back to you with this problem.
We have already tried the same thing with an "echo device"
On 09/09/2014 07:15 PM, Greg KH wrote:
> On Tue, Sep 09, 2014 at 10:48:10AM +0200, Robert Baldyga wrote:
>> Hi,
>>
>> This patch series contains fixes for dwc2/gadget driver. It's intended
>> for 3.16-stable.
>
> That's not how stable patch submission works :(
>
> The patches need to be in Linus'
Hi,
On 09/09/2014 05:27 PM, Christoph Hellwig wrote:
> On Tue, Sep 09, 2014 at 11:15:24AM +0200, Hans de Goede wrote:
>> Taking the uas.c file from 3.17, and building it for 3.16 restores
>> the use of tcq (debugged by adding a printk blk_rq_tagged + request->tag).
>>
>> So either uas is doing som
On Wed, Sep 10, 2014 at 10:53 AM, Vivek Gautam wrote:
> On Wed, Sep 10, 2014 at 10:23 AM, Felipe Balbi wrote:
>> On Wed, Sep 10, 2014 at 09:09:57AM +0530, Vivek Gautam wrote:
>>> On Wed, Sep 10, 2014 at 9:07 AM, Vivek Gautam
>>> wrote:
>>> > adding Julius here,
>>>
>>> i think i had missed addi
On Sun, Aug 31, 2014 at 11:24:56PM +0800, Wang YanQing wrote:
> PL2303 USB Serial devices may has GPIOs, this patch add
> basic PL2303 gpio support.
>
> Known issue:
> If gpios are in use(export to userspace through sysfs interface, etc),
> then call pl2303_release(unplug usb-serial convertor, mod
On Tue, Sep 09, 2014 at 07:28:00PM +0200, Oliver Neukum wrote:
> On Tue, 2014-09-09 at 12:53 -0400, Alan Stern wrote:
> > On Tue, 9 Sep 2014, Oliver Neukum wrote:
> >
> > > On Tue, 2014-09-09 at 11:23 -0400, Alan Stern wrote:
> > > > On Tue, 9 Sep 2014, Oliver Neukum wrote:
> > > >
> > > > > Hi,
Hello Dan,
On 9/9/2014 2:32 PM, Dan Carpenter wrote:
Hello Amit Virdi,
The patch ef11982dd7a6: "usb: gadget: zero: Add support for interrupt
EP" from Aug 22, 2014, leads to the following static checker warning:
drivers/usb/gadget/function/f_sourcesink.c:1498
f_ss_opts_int_interval_sto
Hi,
On 09/09/2014 09:21 PM, Hans de Goede wrote:
> Hi,
>
> On 09/09/2014 06:01 PM, Christoph Hellwig wrote:
>> On Tue, Sep 09, 2014 at 04:59:59PM +0200, Hans de Goede wrote:
>>> asm1051e usb <-> sata bridges hang when receiving a report opcodes scsi
>>> cmnd.
>>> Take a page out of the usb-stora
On Wed, 2014-09-10 at 10:08 +0200, Johan Hovold wrote:
> On Tue, Sep 09, 2014 at 07:28:00PM +0200, Oliver Neukum wrote:
> > I think the only way to do that is to tell usbcore to honour
> > needs_remote_wakeup for suspend but not power off by means
> > of an additional flag.
>
> But this wouldn't
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.
> Also, if the user doesn't care about the touchscreen, you could unbind
>
On Wed, Sep 10, 2014 at 10:24:26AM +0200, Oliver Neukum wrote:
> On Wed, 2014-09-10 at 10:08 +0200, Johan Hovold wrote:
> > On Tue, Sep 09, 2014 at 07:28:00PM +0200, Oliver Neukum wrote:
>
> > > I think the only way to do that is to tell usbcore to honour
> > > needs_remote_wakeup for suspend but
There are a large numbers of issues with ASM1051 devices in uas mode:
1) They do not support REPORT SUPPORTED OPERATION CODES
2) They use out of spec 8 byte status iu-s when they have no sense data,
switching to normal 16 byte status iu-s when they do have sense data.
3) They hang / crash whe
Hi Greg,
Here is v2 of my ASM1051 blacklist patch. The commit message and some of
the log messages have been changed to reflect that my vision on the ASM1051
woes has shifted from: "too bad we need to blacklist this because it does not
work in some cases", to: "this thing is just too buggy to try
On Wed, 2014-09-10 at 10:41 +0200, Johan Hovold wrote:
> On Wed, Sep 10, 2014 at 10:24:26AM +0200, Oliver Neukum wrote:
> > On Wed, 2014-09-10 at 10:08 +0200, Johan Hovold wrote:
> > > On Tue, Sep 09, 2014 at 07:28:00PM +0200, Oliver Neukum wrote:
> >
> > > > I think the only way to do that is to
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, Felipe Balbi wrot
On Wed, 2014-09-10 at 07:04 +, 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 stuff here now what I goo from Intel:
>
> Let me explain why I came back to you with thi
Yes I tried Sarah's suggestions and disabled power management.
but same results.
The time how long it takes until XHCI stops responding is sometimes only 1
second, sometimes several minutes
> Subject: Re: PROBLEM: XHCI Host Controller on Intel Panther Poi
On Wed, 2014-09-10 at 09:48 +, Kasberger Andreas wrote:
> Yes I tried Sarah's suggestions and disabled power management.
> but same results.
> The time how long it takes until XHCI stops responding is sometimes only 1
> second, sometimes several minutes
How did you disable power management?
On 09/09/2014 07:09 PM, Andrew Bresticker wrote:
> On Tue, Sep 9, 2014 at 1:21 AM, Tomeu Vizoso wrote:
>> On 8 September 2014 18:22, Andrew Bresticker wrote:
>>> On Mon, Sep 8, 2014 at 8:34 AM, Tomeu Vizoso wrote:
On 2 September 2014 23:34, Andrew Bresticker wrote:
>
> Tested on Ve
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 usbhs driver will be NULL. So, this patch
adds a condition to avoid the oo
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
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
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
> 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
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
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
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
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
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
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
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
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
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
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
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 ++
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
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
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 -
- 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 +++
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
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
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
-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
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.
>>
>
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
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
> >
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
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
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
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,
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:
> - 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,
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, 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
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
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: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+
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: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 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
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,
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
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,
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:
> 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: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:
> 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: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 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
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
[ +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
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
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
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, 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
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 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
> -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 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
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
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 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
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
> > > >
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
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
>> 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
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
1 - 100 of 121 matches
Mail list logo
