[possible fix] HL-340 USB don't work correctly (ch340 based usb-rs232 adapter)

[Eddi De Pieri]

Hi list,

I've got recently following device.

Bus 003 Device 014: ID 1a86:7523 QinHeng Electronics HL-340 USB-Serial adapter

ch431 kernel driver don't work correctly with this device,
when URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER answer/send wrong character

After some experiment  by passing command retrieved from usbsnoop log
it seems that ch341.c  starts working if comment out following line

// r = ch341_control_out(dev, 0x9a, 0x2518, 0x0050);

my windows driver usbsnoop  | grep "18 25"
07: 03 ms 000398 ms c0 95 18 25 00 00 02 00 <<<  c3 00
36: 04 ms 000620 ms 40 9a 18 25 c2 00 00 00 >>>
75: 03 ms 011673 ms 40 9a 18 25 c3 00 00 00 >>>

as you can see I get c3 while who first logged windows driver sniff get 56.

So it seems that windows driver read 2518 registry...
it mask some byte and write back
finally it restore it back to original value before communication starts.

please note that my device after following command
r = ch341_control_in(dev, 0x5f, 0, 0, buffer, size); (
answer 0x3000, so it should be a more recent hardware version.

ch34x linux driver from the oem confirmed that 0x5f means hardware version)

I need someone that have same device or other devices that needs
ch341.ko to check that it works properly even if you comment out
before sending a patch back to the ML.

Regards

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

RE: USB Gadgetfs

[Ashwin A Deshpande]

Hello Alern San,

Thank you so much for your reply, I will make sure that I forward these 
questions to linux-usb mailing list (CC'ed).

I successfully cross complied usb.c on my Ubuntu machine, also I changed my 
controller to the SabreSD specific (ci_hdrc_imx),  after executing it on 
target, it gave me following output : 
--
gadgetfs: bound to ci_hdrc_imx driver 
/dev/gadget/ci_hdrc_imx ep0 configured  
serial="xce5r4f5wv60w958rm8yqv71ur7bk6nwmvoy87o7q0gimixl55lck514kbtj0bv"
--

Thank you for your guidance, I am exploring it more for image transfer. In case 
of any further question I will post it to you with linux-usb CC'ed.

Thanks and Regards
Ashwin Deshpande



From: Alan Stern [st...@rowland.harvard.edu]
Sent: 04 February 2015 23:16
To: Ashwin A Deshpande
Cc: USB list
Subject: Re: USB Gadgetfs

On -1 xxx -1 ashwin.deshpa...@igate.com wrote:

> Hello Alern San,
>
> This is with reference to 
> http://libusb.6.n5.nabble.com/How-to-send-receive-data-using-gadgetfs-bulk-endpoint-td5076584.html

Questions like this should be sent to the linux-usb mailing list
(CC'ed).

> I am trying to configure freescale's iMX6 SabreSD board as device and
> UBUNTU Desktop as a host and transfer images over USB using gadgetfs,
> i have googled so many links but I am not clear about the exact
> procedure to follow.
>
> All examples states, run usb.c, but how to make an executable for my
> target board (iMX6 SabreSD).

Compile usb.c.  Or cross-compile it on a different computer, if you
don't have a compiler that runs on the SabreSD.

> Also the controllers stated in autoconfig() functions doesn't match
> with the one used in SabreSD.

I don't think that matters very much, so long as your controller
provides the necessary endpoints.

> If i follow the procedure
> 1) mkdir /dev/gadget
> 2) modprobe gadgetfs
> 3) mount -t gadgetfs none /dev/gadget
>
> I get an error "nop ci_hdrc.0: failed to start (null): -120"

Somebody who is more familiar with the ci_hdrc driver will have to
answer this.

> If you can guide with step by step procedure, I would be thankful
>
> Thanks and Regards
> Ashwin Deshpande

Alan Stern


~~Disclaimer~~~
Information contained and transmitted by this e-mail is confidential and 
proprietary to IGATE and its affiliates and is intended for use only by the 
recipient. If you are not the intended recipient, you are hereby notified that 
any dissemination, distribution, copying or use of this e-mail is strictly 
prohibited and you are requested to delete this e-mail immediately and notify 
the originator or mailad...@igate.com . IGATE does 
not enter into any agreement with any party by e-mail. Any views expressed by 
an individual do not necessarily reflect the view of IGATE. IGATE is not 
responsible for the consequences of any actions taken on the basis of 
information provided, through this email. The contents of an attachment to this 
e-mail may contain software viruses, which could damage your own computer 
system. While IGATE has taken every reasonable precaution to minimise this 
risk, we cannot accept liability for any damage which you sustain as a result 
of software viruses. You should carry out your own virus checks before opening 
an attachment. To know more about IGATE please visit www.igate.com 
.


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

Re: [PATCH 2/2] usb: dwc2: gadget reuse ahbcfg assigned from platform

[Zhangfei Gao]

Hi Yousaf

On 4 February 2015 at 17:41, Kaukab, Yousaf  wrote:
>> diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c index
>> d5197d4..8d388cc 100644
>> --- a/drivers/usb/dwc2/core.c
>> +++ b/drivers/usb/dwc2/core.c
>> @@ -2563,7 +2563,7 @@ void dwc2_set_param_reload_ctl(struct dwc2_hsotg
>> *hsotg, int val)
>>
>>  void dwc2_set_param_ahbcfg(struct dwc2_hsotg *hsotg, int val)  {
>> - if (val != -1)
>> + if (val)
>>   hsotg->core_params->ahbcfg = val;
>>   else
>>   hsotg->core_params->ahbcfg =
>> GAHBCFG_HBSTLEN_INCR4 << diff --git a/drivers/usb/dwc2/gadget.c
>> b/drivers/usb/dwc2/gadget.c index 15aa578..20085de 100644
>> --- a/drivers/usb/dwc2/gadget.c
>> +++ b/drivers/usb/dwc2/gadget.c
>> @@ -2314,9 +2314,13 @@ void s3c_hsotg_core_init_disconnected(struct
>> dwc2_hsotg *hsotg,
>>   GINTSTS_USBSUSP | GINTSTS_WKUPINT,
>>   hsotg->regs + GINTMSK);
>>
>> + if ((hsotg->core_params) && (hsotg->core_params->ahbcfg != -
>> 1))
>> + val = hsotg->core_params->ahbcfg &
>> ~GAHBCFG_CTRL_MASK;
>> + else
>> + val = GAHBCFG_HBSTLEN_INCR4 <<
>> GAHBCFG_HBSTLEN_SHIFT;
>> +
>>   if (using_dma(hsotg))
>> - writel(GAHBCFG_GLBL_INTR_EN |
>> GAHBCFG_DMA_EN |
>> -(GAHBCFG_HBSTLEN_INCR4 <<
>> GAHBCFG_HBSTLEN_SHIFT),
>> + writel(GAHBCFG_GLBL_INTR_EN |
>> GAHBCFG_DMA_EN | val,
>>  hsotg->regs + GAHBCFG);
>>   else
>>   writel(((hsotg->dedicated_fifos) ?
>> (GAHBCFG_NP_TXF_EMP_LVL |
>
> There are other bits in GAHBCFG that can be set from platform. They will be 
> preserved by your patch, as they are not part of GAHBCFG_CTRL_MASK, but only 
> in case dma is enabled. Perhaps preserve them in non-dma case as well.

Here may have issue if also set hsotg->core_params->ahbcfg for non-dma case,
since GAHBCFG[4:1] may be set.

Though from drivers/usb/dwc2/core.h we can not see @ahbcfg is
specifically used for dma case,
most case in drivers/usb/dwc2/platform.c use ahbcfg is set hbstlen,
GAHBCFG[4:1].
For example, our platform set GAHBCFG_HBSTLEN_INCR16.

So I just assume @ahbcfg is used for dma case.
What do you think.

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

Re: [PATCH 2/2] usb: dwc2: gadget reuse ahbcfg assigned from platform

[Zhangfei Gao]

On 4 February 2015 at 21:51, Sergei Shtylyov
 wrote:
>> diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
>> index 15aa578..20085de 100644
>> --- a/drivers/usb/dwc2/gadget.c
>> +++ b/drivers/usb/dwc2/gadget.c
>> @@ -2314,9 +2314,13 @@ void s3c_hsotg_core_init_disconnected(struct
>> dwc2_hsotg *hsotg,
>> GINTSTS_USBSUSP | GINTSTS_WKUPINT,
>> hsotg->regs + GINTMSK);
>>
>> +   if ((hsotg->core_params) && (hsotg->core_params->ahbcfg != -1))
>
>
>Inner pares not needed, especially the first ones.

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

RE: [PATCH v4] ehci-pci: disable for Intel MID platforms (update)

[Peter Chen]

 
> 
> On Wed, 2015-02-04 at 08:04 +0800, Peter Chen wrote:
> > On Tue, Feb 03, 2015 at 06:08:39PM +0200, Andy Shevchenko wrote:
> 
> > > + *
> > > + * Note: ehci-pci driver may try to probe the device first. You
> > > + have to add an
> > > + * ID to the bypass_pci_id_table in ehci-pci driver to prevent this.
> > >   */
> >
> > This one is the same with your v3.
> 
> Correct.
> 
> > > --
> >
> > I have no idea for this change.
> >
> > If Greg has still not queued your pci patch, you can squash all your
> > versions for pci and chipidea to one patch set, in this set, one patch
> > for pci, and another for chipidea.
> 
> We discussed with him and agreed on one patch to update what was applied to
> what is in v3.
> 

So no patch I need to queue in chipidea tree, right?

For this patch:

Acked-by: Peter Chen 

Peter

Re: [PATCH 3/5] fs: remove ki_nbytes

[Al Viro]

On Wed, Feb 04, 2015 at 03:30:32PM -0500, Alan Stern wrote:
> > * this one.  Note that you are not guaranteed that ep_config() won't
> > be called more than once - two threads might race in write(2), with the 
> > loser
> > getting through mutex_lock_interruptible(&data->lock); in ep_config() only
> > after the winner has already gotten through write(), switched ->f_op, 
> > returned
> > to userland and started doing read()/write()/etc.  If nothing else,
> > the contents of data->desc and data->hs_desc can be buggered by arbitrary
> > data, no matter how bogus, right as the first thread is doing IO.
> 
> Well, this one certainly can be fixed to avoid altering ->f_op, at the 
> cost of adding an extra check at the start of each I/O operation.
 
> > Um...  readv() is also going through ->aio_read().
> 
> Why does readv() do this but not read()?  Wouldn't it make more sense 
> to have all the read* calls use the same internal interface?

Because there are two partially overlapping classes wrt vector IO semantics:
1) datagram-style.  Vectored read/write is equivalent to simple
read/write done on each vector component.  And IO boundaries matter - if
your driver treats any write() as datagram that starts e.g. with
fixed-sized table in the beginning + arbitrary amount of data following
it, you will get very different results from write(fd, buf, 200) and
writev(fd, (struct iovec[2]){{buf, 100}, {buf+100, 100}}, 2).  A _lot_ of
drivers are like that - they supply ->read() and ->write() for single-range
IO and VFS construct the rest of operations out of those.

2) stream-style.  Vectored read is guaranteed to behave the same
way as simple read on a range with size being the sum of vector element
sizes, except that the data ends in ranges covered by vector elements instead
of a single array.  Vectored write is guaranteed to behave the same way
as simple write from a buffer containing the concatenation of ranges covered
by vector elements.  Boundaries between the elements do not matter at all.
Regular files on storage filesystems are like that.  So are FIFOs and pipes
and so are sockets.  Even for datagram protocols, boundaries between the
vector elements are ignored; boundaries between syscalls provide the datagram
boundaries, but you can e.g. do writev(udp_socket_fd, (struct iovec[3]){
{const_header, sizeof(const_header)}, {&n, 4}, {s, strlen(s)}}, 3) and have
only one UDP packet sent.  IOW, it's general-purpose scatter-gather for read
and write.

The last example shows that (2) isn't a subset of (1) - it's not
always possible to call ->write() in loop and get the right behaviour.
For regular files (and pure stream sockets, etc.) it would work, but for
stuff like UDP sockets it would break.  Moreover, even for regular files on
storage filesystems it would be quite inefficient - we'd need to acquire and
release a bunch of locks, poke through metadata, etc., for each segment.

As the result, there was a couple of new methods added, inventively
called ->readv() and ->writev().  do_sync_read() was supposed to be used
as ->read() instance - it's "feed a single-element vector to ->readv()" and
similar for s/read/write/.

Note that both (1) and (2) satisfy the following sanity requirement -
single-element readv() is always equivalent to single-element() read().  You
could violate that, by providing completely unrelated ->read() and ->readv(),
but very few drivers went for that - too insane.

Then, when AIO had been added, those had grown an argument pointing
to iocb (instead of file and ppos - for those we use iocb->ki_filp and
&iocb->ki_pos resp.) and they got renamed into ->aio_read() and ->aio_write().
Note that non-vectored AIO uses the same methods - ->read() and ->write() had
too many instances to convert and most of those would end up just using those
two iocb fields instead of the old arguments - tons of churn for no good
reason.  ->readv() and ->writev() had fewer instances (very common was the
use of generic_file_aio_{read,write}()) and conversion was less painful.
So there was no ->aio_read() and ->aio_write().  That, in principle, was a
bit of constraint - you couldn't make single-element AIO_PREADV behave
different from AIO_PREAD, but nobody had been insane enough to ask for that.

Moreover, keeping ->readv() and ->writev() was pointless. There is
cheap way to tell whether ->aio_{read,write}() call is due to io_submit(2)
or to readv()/writev() - is_sync_kiocb(iocb) tells which one it is, so if
driver really wanted different semantics for sync vs. async, it could check
that.

So we ended up with ->read/->write for sync non-vectored and
->aio_read()/->aio_write() for sync vectored *and* async anything.  Usually
you provide one or the other - NULL ->aio_... means loop calling ->read/write
on each element, NULL ->read/write (or do_sync_... for them - it's the same
thing) means feeding sync iocb and single-element vector to ->aio_
You *can* pro

Re: Control message failures kill entire XHCI stack

[Alistair Grant]

Hi Mathias,

On Wed, Feb 4, 2015 at 5:26 PM, Mathias Nyman
 wrote:
> On 27.01.2015 00:20, Alistair Grant wrote:
>> I've come across what appears to be another xHCI issue - attempting to
>> format a disk with gparted is causing a kernel Oops.  This may not be
>> related to the issue you're currently investigating, but wanted to
>> pass it on in case it is (if it isn't let me know and I'll either keep
>> quiet or raise it separately, whatever you prefer).
>>
>> I can easily reproduce the crash running 3.19rc6 with Mathias
>> additional error and debugging messages (debugging switched off).  I
>> wasn't able to reproduce the issue with xhci debugging enabled, i.e.:
>>
>
> I got a some new patches to test, added to the same for-usb-next-test
> branch in git://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git
>
> Alistair, did you manage to Oops the kernel without the debug patches?
> It might be caused by them (trying to access non-existing ep->ring->td_list 
> pointer).
>
> If you are able to reproduce the HDD gparted format oops on a normal (without 
> my testpaches)
> kernel then I think it should be reported as a separate issue.

You're correct, the Oops only happened with your original set of
patches.  After adding the latest patches it no longer occurs.

However I still get other errors, with vanilla 3.19rc7, your patched
3.19rc5 kernel and my 3.19rc7 with all your patches applied.  All of
the log reports look similar to me.

I'll submit a separate report for this issue.

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

Re: [PATCH] net: usb: sr9700: Use 'SR_' prefix for the common register macros

[David Miller]

From: Chen Gang S 
Date: Tue, 03 Feb 2015 05:00:40 +0800

> The commone register macors (e.g. RSR) is too commont to drivers, it may
> be conflict with the architectures (e.g. xtensa, sh).
> 
> The related warnings (with allmodconfig under xtensa):
> 
> CC [M]  drivers/net/usb/sr9700.o
>   In file included from drivers/net/usb/sr9700.c:24:0:
>   drivers/net/usb/sr9700.h:65:0: warning: "RSR" redefined
>#define RSR   0x06
>^
>   In file included from ./arch/xtensa/include/asm/bitops.h:22:0,
>from include/linux/bitops.h:36,
>from include/linux/kernel.h:10,
>from include/linux/list.h:8,
>from include/linux/module.h:9,
>from drivers/net/usb/sr9700.c:13:
>   ./arch/xtensa/include/asm/processor.h:190:0: note: this is the location of 
> the previous definition
>#define RSR(v,sr) __asm__ __volatile__ ("rsr %0,"__stringify(sr) : 
> "=a"(v));
>^
> 
> Signed-off-by: Chen Gang 

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

Re: [PATCH 3/5] fs: remove ki_nbytes

[Alan Stern]

On Wed, 4 Feb 2015, Al Viro wrote:

> On Wed, Feb 04, 2015 at 01:17:30PM -0500, Alan Stern wrote:
> > On Wed, 4 Feb 2015, Al Viro wrote:
> > 
> > > [USB folks Cc'd]
> > 
> > Incidentally, Al, have you seen this email?
> > 
> > http://marc.info/?l=linux-usb&m=142295011402339&w=2
> > 
> > I encouraged the writer to send in a patch but so far there has been no 
> > reply.
> 
> Yecchhh...  Anything that changes ->f_op *after* return from ->open() is
> doing a nasty, nasty thing.  What's to guarantee that any checks for
> NULL fields will stay valid, etc.?
> 
> FWIW, in all the tree there are only 4 places where that would be happening;
>   * i810_map_buffer() screwing around with having vm_mmap() done,
> only it wants its own thing called as ->mmap() (and a bit of extra data
> stashed for it).  Racy as hell (if another thread calls mmap() on the
> same file, you'll get a nasty surprise).  Driver's too old and brittle to
> touch, according to drm folks...
>   * TTY hangup logics.  Nasty (and might be broken around ->fasync()),
> but it's a very special case.
>   * snd_card_disconnect().  Analogue of TTY hangup, actually; both are
> trying to do a form of revoke().
>   * this one.  Note that you are not guaranteed that ep_config() won't
> be called more than once - two threads might race in write(2), with the loser
> getting through mutex_lock_interruptible(&data->lock); in ep_config() only
> after the winner has already gotten through write(), switched ->f_op, returned
> to userland and started doing read()/write()/etc.  If nothing else,
> the contents of data->desc and data->hs_desc can be buggered by arbitrary
> data, no matter how bogus, right as the first thread is doing IO.

Well, this one certainly can be fixed to avoid altering ->f_op, at the 
cost of adding an extra check at the start of each I/O operation.

> > >  it halts the
> > > sucker and fails with EBADMSG, while ep_aio_read() handles all write 
> > > endpoints
> > > as isochronous ones - fails with EINVAL; FWIW, I agree that it's probably
> > > a bug]
> > 
> > It's not a bug; it's by design.  That's how you halt an endpoint in 
> > gadgetfs -- by doing a synchronous I/O call in the "wrong" direction.
> 
> Yes, but you have readv() on single-element vector behave different from
> read(), which is surprising, to put it mildly.
> 
> > > I plan to pull the fix for use-after-free in the beginning of that queue
> > > (in an easy to backport form) and then have ep_aio_read/ep_aio_write
> > > start doing the halt-related bits as in ep_read/ep_write.  With that it's
> > > trivial to convert that sucker along the same lines as function/f_fs.c.
> > 
> > I don't think there's any need to make the async routines do the
> > halt-related stuff.  After all, it's silly for users to call an async
> > I/O routine to perform a synchronous action like halting an endpoint.
> 
> Um...  readv() is also going through ->aio_read().

Why does readv() do this but not read()?  Wouldn't it make more sense 
to have all the read* calls use the same internal interface?

>  I can tie that to
> sync vs. async, though - is_sync_kiocb() will do just that, if you are
> OK with having readv() act the same as read() in that respect.

I don't really care one way or the other.  In fact, it doesn't matter
if the same behavior applies to all the async calls as well as the sync
calls -- I just doubt that anybody will ever use them.

Alan Stern

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

Re: [PATCH v4] ehci-pci: disable for Intel MID platforms (update)

[Sergei Shtylyov]

Hello.

On 02/04/2015 02:24 AM, Greg Kroah-Hartman wrote:


This is a follow up to the previously submitted commit cefa9a31a5f0 (ehci-pci:
disable for Intel MID platforms).



It includes the following changes:
- table and function are renamed to reflect this is not only about ChipIdea
- ChipIdea PCI driver (ci_hdrc_pci.c) gets the comment about the table in
   ehci-pci.c
- MIPS IDs removed from the list since it was discovered and tested on Intel
   MID platforms



Reviewed-by: Alexander Shishkin 
Signed-off-by: Andy Shevchenko 



[...]

diff --git a/drivers/usb/host/ehci-pci.c b/drivers/usb/host/ehci-pci.c
index 9652021..2a5d2fd 100644
--- a/drivers/usb/host/ehci-pci.c
+++ b/drivers/usb/host/ehci-pci.c
@@ -42,18 +42,22 @@ static inline bool is_intel_quark_x1000(struct pci_dev 
*pdev)
pdev->device == PCI_DEVICE_ID_INTEL_QUARK_X1000_SOC;
  }

-static const struct pci_device_id ci_hdrc_pci_id_table[] = {
-   { PCI_DEVICE(0x153F, 0x1004), },
-   { PCI_DEVICE(0x153F, 0x1006), },
+/*
+ * This is the list of PCI IDs for the devices that have EHCI USB class and
+ * specific drivers for that. One of the example is a ChipIdea device installed
+ * on some Intel MID platforms.
+ */
+static const struct pci_device_id bypass_pci_id_table[] = {
+   /* ChipIdea on Intel MID platform */
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x0811), },
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x0829), },
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0xe006), },



I'd suggest using PCI_VDEVICE() here instead.



Not a big deal.


   Just an idea for a future patch. I might venture into doing such one in my 
copious free time... :-)


WBR, Sergei

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

Re: [PATCH 3/5] fs: remove ki_nbytes

[Al Viro]

On Wed, Feb 04, 2015 at 01:17:30PM -0500, Alan Stern wrote:
> On Wed, 4 Feb 2015, Al Viro wrote:
> 
> > [USB folks Cc'd]
> 
> Incidentally, Al, have you seen this email?
> 
>   http://marc.info/?l=linux-usb&m=142295011402339&w=2
> 
> I encouraged the writer to send in a patch but so far there has been no 
> reply.

Yecchhh...  Anything that changes ->f_op *after* return from ->open() is
doing a nasty, nasty thing.  What's to guarantee that any checks for
NULL fields will stay valid, etc.?

FWIW, in all the tree there are only 4 places where that would be happening;
* i810_map_buffer() screwing around with having vm_mmap() done,
only it wants its own thing called as ->mmap() (and a bit of extra data
stashed for it).  Racy as hell (if another thread calls mmap() on the
same file, you'll get a nasty surprise).  Driver's too old and brittle to
touch, according to drm folks...
* TTY hangup logics.  Nasty (and might be broken around ->fasync()),
but it's a very special case.
* snd_card_disconnect().  Analogue of TTY hangup, actually; both are
trying to do a form of revoke().
* this one.  Note that you are not guaranteed that ep_config() won't
be called more than once - two threads might race in write(2), with the loser
getting through mutex_lock_interruptible(&data->lock); in ep_config() only
after the winner has already gotten through write(), switched ->f_op, returned
to userland and started doing read()/write()/etc.  If nothing else,
the contents of data->desc and data->hs_desc can be buggered by arbitrary
data, no matter how bogus, right as the first thread is doing IO.

> > [Context for USB people: The difference in question is what ep_read() does
> > when it is called on write endpoint that isn't isochronous;
> 
> You're talking about drivers/usb/gadget/legacy/inode.c, right?

Yes.

> >  it halts the
> > sucker and fails with EBADMSG, while ep_aio_read() handles all write 
> > endpoints
> > as isochronous ones - fails with EINVAL; FWIW, I agree that it's probably
> > a bug]
> 
> It's not a bug; it's by design.  That's how you halt an endpoint in 
> gadgetfs -- by doing a synchronous I/O call in the "wrong" direction.

Yes, but you have readv() on single-element vector behave different from
read(), which is surprising, to put it mildly.

> > I plan to pull the fix for use-after-free in the beginning of that queue
> > (in an easy to backport form) and then have ep_aio_read/ep_aio_write
> > start doing the halt-related bits as in ep_read/ep_write.  With that it's
> > trivial to convert that sucker along the same lines as function/f_fs.c.
> 
> I don't think there's any need to make the async routines do the
> halt-related stuff.  After all, it's silly for users to call an async
> I/O routine to perform a synchronous action like halting an endpoint.

Um...  readv() is also going through ->aio_read().  I can tie that to
sync vs. async, though - is_sync_kiocb() will do just that, if you are
OK with having readv() act the same as read() in that respect.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] USB changes for v3.20

[Greg KH]

On Wed, Feb 04, 2015 at 11:21:03AM -0600, Felipe Balbi wrote:
> Hi Greg,
> 
> Here's a big pull request for v3.20. All patches have been around
> for quite a while. I have tested everything on AM437x SK, AM437x IDK,
> AM335x BeagleBoneBlack and AM57x Beagleboard X15.
> 
> Let me know if you want me to change anything.
> 
> cheers
> 
> The following changes since commit ec6f34e5b552fb0a52e6aae1a5afbbb1605cc6cc:
> 
>   Linux 3.19-rc5 (2015-01-18 18:02:20 +1200)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git 
> tags/usb-for-v3.20

Pulled and pushed out, thanks.

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

Re: [PATCH] pci-dma: Fix x86 dma_alloc_coherent to fully clear all pages returned

[Tim Chen]

On Mon, 2015-02-02 at 19:39 +0300, Sergei Shtylyov wrote:

> 
> > Hi, is this an open-coded version of PAGE_ALIGN?
> 
> Yes, it appears so. :-)
> 
> WBR, Sergei
> 

Thanks for the suggestion by Jiri. I updated the patch to use PAGE_ALIGN
below.

Regards,
Tim

--->8---
From: Tim Chen 
Subject: [PATCH] pci-dma: Fix x86 dma_alloc_coherent to fully clear all pages 
returned

Commit d92ef66c4f8f ("x86: make dma_alloc_coherent() return zeroed memory
if CMA is enabled") changed the dma_alloc_coherent page clearance from
using an __GFP_ZERO in page allocation to not setting the flag but doing
an explicit memory clear at the end.

However the memory clear only covered the memory size that
was requested, but may not be up to the full extent of the
last page, if the total pages returned exceed the
memory size requested.  This behavior has caused problem with XHCI
and caused it to hang:

kernel: xhci_hcd :00:14.0: Stopped the command ring failed, maybe the host 
is dead
kernel: xhci_hcd :00:14.0: Abort command ring failed
kernel: xhci_hcd :00:14.0: HC died; cleaning up
kernel: xhci_hcd :00:14.0: Error while assigning device slot ID
kernel: xhci_hcd :00:14.0: Max number of devices this xHCI host supports is 
64.

Other drivers may have similar issue if it assumes that the pages
allocated are completely zeroed.

This patch ensures that the pages returned are fully cleared.

Signed-off-by: Tim Chen 
Cc: sta...@vger.kernel.org
---
 arch/x86/kernel/pci-dma.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/x86/kernel/pci-dma.c b/arch/x86/kernel/pci-dma.c
index a25e202..3bdee55 100644
--- a/arch/x86/kernel/pci-dma.c
+++ b/arch/x86/kernel/pci-dma.c
@@ -125,6 +125,8 @@ again:
 
return NULL;
}
+   /* round up to full page size */
+   size = PAGE_ALIGN(size);
memset(page_address(page), 0, size);
*dma_addr = addr;
return page_address(page);
-- 
1.9.3

 

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

Re: [PATCH 3/5] fs: remove ki_nbytes

[Alan Stern]

On Wed, 4 Feb 2015, Al Viro wrote:

> [USB folks Cc'd]

Incidentally, Al, have you seen this email?

http://marc.info/?l=linux-usb&m=142295011402339&w=2

I encouraged the writer to send in a patch but so far there has been no 
reply.

> On Mon, Feb 02, 2015 at 03:26:17PM +0100, Christoph Hellwig wrote:
> 
> > I would bet the behavior difference is a bug, might be worth to Cc the
> > usb folks on this issue.  I bet we'd want the more complex behavior
> > for both variants.
> 
> [Context for USB people: The difference in question is what ep_read() does
> when it is called on write endpoint that isn't isochronous;

You're talking about drivers/usb/gadget/legacy/inode.c, right?

>  it halts the
> sucker and fails with EBADMSG, while ep_aio_read() handles all write endpoints
> as isochronous ones - fails with EINVAL; FWIW, I agree that it's probably
> a bug]

It's not a bug; it's by design.  That's how you halt an endpoint in 
gadgetfs -- by doing a synchronous I/O call in the "wrong" direction.

> Sadly, that's not the only problem in there ;-/  _This_ one really has
> the "what if single-segment AIO read tries to dereference iovec after
> the caller is gone" bug you suspected in fs/direct-io.c; we have
> static void ep_user_copy_worker(struct work_struct *work)
> {
> struct kiocb_priv *priv = container_of(work, struct kiocb_priv, work);
> struct mm_struct *mm = priv->mm;
> struct kiocb *iocb = priv->iocb;
> size_t ret;
> 
> use_mm(mm); 
> ret = ep_copy_to_user(priv);
> unuse_mm(mm);
> 
> /* completing the iocb can drop the ctx and mm, don't touch mm after 
> */
> aio_complete(iocb, ret, ret);
> 
> kfree(priv->buf);
> kfree(priv);
> }
> called via schedule_work() from ->complete() of usb_request allocated and
> queued by ->aio_read().  It very definitely _can_ be executed after return
> from ->aio_read() and aio_run_iocb().  And ep_copy_to_user() dereferences
> the iovec given to ->aio_read(); _not_ its copy as f_fs.c does.
> 
> Do io_submit(2) with several IOCB_CMD_PREAD requests, and you'll almost
> certainly get the data from the first one copied to the destination of
> the second one instead.  It shouldn't be hard to reproduce.  And that,
> of course, is not the worst possible outcome...
> 
> I'm going to add copying of iovec in async read case.  And AFAICS, that one
> is -stable fodder.  See vfs.git#gadget for f_fs.c conversion; I haven't
> pushed legacy/inode.c stuff yet - I need to pull the fix of the bug above
> into the beginning of that pile first.
> 
> FWIW, I don't believe that it makes sense to do iovec copying in
> aio_run_iocb(); note that most of the instances will be done with
> iovec before they return there.

That's true even for gadgetfs in the write case.

>  These two were the sole exceptions;
> function/f_fs.c did copying, legacy/inode.c didn't.  Most of the
> ->aio_read/->read_iter instances (including ones that *do* return
> EIOCBQUEUED) only access iovec synchronously; usually that's done
> by grabbing the pages to copy into before we get aronud to starting
> IO.  legacy/inode.c is the only instance to step into that kind of bug.
> function/f_fs.c also had a fun bug, BTW - failure in AIO ended up leaking
> io_data (plus iovec copy in case of aio_read()).  Looks like another
> -stable fodder, if less serious one...  See b17d2ded6 (gadget/function/f_fs.c:
> close leaks) in vfs.git#gadget for that one.
> 
> I plan to pull the fix for use-after-free in the beginning of that queue
> (in an easy to backport form) and then have ep_aio_read/ep_aio_write
> start doing the halt-related bits as in ep_read/ep_write.  With that it's
> trivial to convert that sucker along the same lines as function/f_fs.c.

I don't think there's any need to make the async routines do the
halt-related stuff.  After all, it's silly for users to call an async
I/O routine to perform a synchronous action like halting an endpoint.

On the other hand, it would be reasonable to replace the -EBADMSG with
some massaged version of the return code from usb_ep_set_halt(), which
is supposed to return -EAGAIN under some circumstances.  But that would
be an API change, so we probably shouldn't do it...

> All of that, assuming that anybody gives a damn about the driver in question.
> The things like
> spin_lock_irq (&dev->lock);
>   
> // FIXME don't call this with the spinlock held ...
> if (copy_to_user (buf, dev->req->buf, len))
> seem to indicate that nobody does, seeing that this bug had been there
> since 2003, complete with FIXME ;-/
> 
> If nobody cares about that sucker, git rm would be a better solution, IMO...

It is a legacy driver after all, but some people still use it.

Alan Stern

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

[PATCH] usb: gadget: function/f_sourcesink: fix sparse warning

[Lad Prabhakar]

From: "Lad, Prabhakar" 

this patch fixes following sparse warnings:

f_sourcesink.c:347:34: warning: symbol 'ss_int_source_comp_desc' was not 
declared. Should it be static?
f_sourcesink.c:365:34: warning: symbol 'ss_int_sink_comp_desc' was not 
declared. Should it be static?

Signed-off-by: Lad, Prabhakar 
---
 Found this issue on linux-next (gcc  version 4.8.2,
 sparse version  0.4.5-rc1)and applies on top linux-next.

 drivers/usb/gadget/function/f_sourcesink.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/gadget/function/f_sourcesink.c 
b/drivers/usb/gadget/function/f_sourcesink.c
index e07c50c..e3dae47 100644
--- a/drivers/usb/gadget/function/f_sourcesink.c
+++ b/drivers/usb/gadget/function/f_sourcesink.c
@@ -344,7 +344,7 @@ static struct usb_endpoint_descriptor ss_int_source_desc = {
.bInterval =USB_MS_TO_SS_INTERVAL(GZERO_INT_INTERVAL),
 };
 
-struct usb_ss_ep_comp_descriptor ss_int_source_comp_desc = {
+static struct usb_ss_ep_comp_descriptor ss_int_source_comp_desc = {
.bLength =  USB_DT_SS_EP_COMP_SIZE,
.bDescriptorType =  USB_DT_SS_ENDPOINT_COMP,
 
@@ -362,7 +362,7 @@ static struct usb_endpoint_descriptor ss_int_sink_desc = {
.bInterval =USB_MS_TO_SS_INTERVAL(GZERO_INT_INTERVAL),
 };
 
-struct usb_ss_ep_comp_descriptor ss_int_sink_comp_desc = {
+static struct usb_ss_ep_comp_descriptor ss_int_sink_comp_desc = {
.bLength =  USB_DT_SS_EP_COMP_SIZE,
.bDescriptorType =  USB_DT_SS_ENDPOINT_COMP,
 
-- 
1.9.1

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

[PATCH] usb: host/sl811-hcd: fix sparse warning

[Lad Prabhakar]

From: "Lad, Prabhakar" 

this patch fixes following sparse warning:
sl811-hcd.c:1804:24: warning: symbol 'sl811h_driver' was not declared. Should 
it be static?

Signed-off-by: Lad, Prabhakar 
---
 drivers/usb/host/sl811-hcd.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/host/sl811-hcd.c b/drivers/usb/host/sl811-hcd.c
index 4f4ba1e..aceddfd 100644
--- a/drivers/usb/host/sl811-hcd.c
+++ b/drivers/usb/host/sl811-hcd.c
@@ -1801,7 +1801,7 @@ sl811h_resume(struct platform_device *dev)
 
 
 /* this driver is exported so sl811_cs can depend on it */
-struct platform_driver sl811h_driver = {
+static struct platform_driver sl811h_driver = {
.probe =sl811h_probe,
.remove =   sl811h_remove,
 
-- 
1.9.1

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

[PATCH] usb: gadget: function/f_uac2: fix sparse warnings

[Lad Prabhakar]

From: "Lad, Prabhakar" 

this patch fixes following sparse warnings:
f_uac2.c:57:12: warning: symbol 'uac2_name' was not declared. Should it be 
static?
f_uac2.c:637:36: warning: symbol 'in_clk_src_desc' was not declared. Should it 
be static?
f_uac2.c:649:36: warning: symbol 'out_clk_src_desc' was not declared. Should it 
be static?
f_uac2.c:661:39: warning: symbol 'usb_out_it_desc' was not declared. Should it 
be static?
f_uac2.c:675:39: warning: symbol 'io_in_it_desc' was not declared. Should it be 
static?
f_uac2.c:689:40: warning: symbol 'usb_in_ot_desc' was not declared. Should it 
be static?
f_uac2.c:703:40: warning: symbol 'io_out_ot_desc' was not declared. Should it 
be static?
f_uac2.c:716:34: warning: symbol 'ac_hdr_desc' was not declared. Should it be 
static?
f_uac2.c:754:34: warning: symbol 'as_out_hdr_desc' was not declared. Should it 
be static?
f_uac2.c:767:38: warning: symbol 'as_out_fmt1_desc' was not declared. Should it 
be static?
f_uac2.c:775:32: warning: symbol 'fs_epout_desc' was not declared. Should it be 
static?
f_uac2.c:785:32: warning: symbol 'hs_epout_desc' was not declared. Should it be 
static?
f_uac2.c:831:34: warning: symbol 'as_in_hdr_desc' was not declared. Should it 
be static?
f_uac2.c:844:38: warning: symbol 'as_in_fmt1_desc' was not declared. Should it 
be static?
f_uac2.c:852:32: warning: symbol 'fs_epin_desc' was not declared. Should it be 
static?
f_uac2.c:862:32: warning: symbol 'hs_epin_desc' was not declared. Should it be 
static?
f_uac2.c:1566:21: warning: symbol 'afunc_alloc' was not declared. Should it be 
static?

Signed-off-by: Lad, Prabhakar 
---
 Found this issue on linux-next (gcc  version 4.8.2,
 sparse version  0.4.5-rc1)and applies on top linux-next.

 drivers/usb/gadget/function/f_uac2.c | 34 +-
 1 file changed, 17 insertions(+), 17 deletions(-)

diff --git a/drivers/usb/gadget/function/f_uac2.c 
b/drivers/usb/gadget/function/f_uac2.c
index 33e1665..6d3eb8b 100644
--- a/drivers/usb/gadget/function/f_uac2.c
+++ b/drivers/usb/gadget/function/f_uac2.c
@@ -54,7 +54,7 @@
 #define UNFLW_CTRL 8
 #define OVFLW_CTRL 10
 
-const char *uac2_name = "snd_uac2";
+static const char *uac2_name = "snd_uac2";
 
 struct uac2_req {
struct uac2_rtd_params *pp; /* parent param */
@@ -634,7 +634,7 @@ static struct usb_interface_descriptor std_ac_if_desc = {
 };
 
 /* Clock source for IN traffic */
-struct uac_clock_source_descriptor in_clk_src_desc = {
+static struct uac_clock_source_descriptor in_clk_src_desc = {
.bLength = sizeof in_clk_src_desc,
.bDescriptorType = USB_DT_CS_INTERFACE,
 
@@ -646,7 +646,7 @@ struct uac_clock_source_descriptor in_clk_src_desc = {
 };
 
 /* Clock source for OUT traffic */
-struct uac_clock_source_descriptor out_clk_src_desc = {
+static struct uac_clock_source_descriptor out_clk_src_desc = {
.bLength = sizeof out_clk_src_desc,
.bDescriptorType = USB_DT_CS_INTERFACE,
 
@@ -658,7 +658,7 @@ struct uac_clock_source_descriptor out_clk_src_desc = {
 };
 
 /* Input Terminal for USB_OUT */
-struct uac2_input_terminal_descriptor usb_out_it_desc = {
+static struct uac2_input_terminal_descriptor usb_out_it_desc = {
.bLength = sizeof usb_out_it_desc,
.bDescriptorType = USB_DT_CS_INTERFACE,
 
@@ -672,7 +672,7 @@ struct uac2_input_terminal_descriptor usb_out_it_desc = {
 };
 
 /* Input Terminal for I/O-In */
-struct uac2_input_terminal_descriptor io_in_it_desc = {
+static struct uac2_input_terminal_descriptor io_in_it_desc = {
.bLength = sizeof io_in_it_desc,
.bDescriptorType = USB_DT_CS_INTERFACE,
 
@@ -686,7 +686,7 @@ struct uac2_input_terminal_descriptor io_in_it_desc = {
 };
 
 /* Ouput Terminal for USB_IN */
-struct uac2_output_terminal_descriptor usb_in_ot_desc = {
+static struct uac2_output_terminal_descriptor usb_in_ot_desc = {
.bLength = sizeof usb_in_ot_desc,
.bDescriptorType = USB_DT_CS_INTERFACE,
 
@@ -700,7 +700,7 @@ struct uac2_output_terminal_descriptor usb_in_ot_desc = {
 };
 
 /* Ouput Terminal for I/O-Out */
-struct uac2_output_terminal_descriptor io_out_ot_desc = {
+static struct uac2_output_terminal_descriptor io_out_ot_desc = {
.bLength = sizeof io_out_ot_desc,
.bDescriptorType = USB_DT_CS_INTERFACE,
 
@@ -713,7 +713,7 @@ struct uac2_output_terminal_descriptor io_out_ot_desc = {
.bmControls = (CONTROL_RDWR << COPY_CTRL),
 };
 
-struct uac2_ac_header_descriptor ac_hdr_desc = {
+static struct uac2_ac_header_descriptor ac_hdr_desc = {
.bLength = sizeof ac_hdr_desc,
.bDescriptorType = USB_DT_CS_INTERFACE,
 
@@ -751,7 +751,7 @@ static struct usb_interface_descriptor std_as_out_if1_desc 
= {
 };
 
 /* Audio Stream OUT Intface Desc */
-struct uac2_as_header_descriptor as_out_hdr_desc = {
+static struct uac2_as_header_descriptor as_out_hdr_desc = {
.bLength = sizeof as_out_hdr_desc,
.bDescriptorType = USB_DT_CS_INTERFACE,
 
@@ -764,7 +764,7 @@ struct uac2_as_he

[PATCH] usb: gadget: function/f_hid: fix sparse warning

[Lad Prabhakar]

From: "Lad, Prabhakar" 

this patch fixes following sparse warning:
f_hid.c:572:30: warning: symbol 'f_hidg_fops' was not declared. Should it be 
static?

Signed-off-by: Lad, Prabhakar 
---
 Found this issue on linux-next (gcc  version 4.8.2,
 sparse version  0.4.5-rc1)and applies on top linux-next.

 drivers/usb/gadget/function/f_hid.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/gadget/function/f_hid.c 
b/drivers/usb/gadget/function/f_hid.c
index 426d69a..a2612fb 100644
--- a/drivers/usb/gadget/function/f_hid.c
+++ b/drivers/usb/gadget/function/f_hid.c
@@ -569,7 +569,7 @@ fail:
return status;
 }
 
-const struct file_operations f_hidg_fops = {
+static const struct file_operations f_hidg_fops = {
.owner  = THIS_MODULE,
.open   = f_hidg_open,
.release= f_hidg_release,
-- 
1.9.1

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

Re: USB Gadgetfs

[Alan Stern]

On -1 xxx -1 ashwin.deshpa...@igate.com wrote:

> Hello Alern San,
> 
> This is with reference to 
> http://libusb.6.n5.nabble.com/How-to-send-receive-data-using-gadgetfs-bulk-endpoint-td5076584.html

Questions like this should be sent to the linux-usb mailing list 
(CC'ed).

> I am trying to configure freescale's iMX6 SabreSD board as device and
> UBUNTU Desktop as a host and transfer images over USB using gadgetfs,
> i have googled so many links but I am not clear about the exact
> procedure to follow.
> 
> All examples states, run usb.c, but how to make an executable for my
> target board (iMX6 SabreSD).

Compile usb.c.  Or cross-compile it on a different computer, if you
don't have a compiler that runs on the SabreSD.

> Also the controllers stated in autoconfig() functions doesn't match
> with the one used in SabreSD.

I don't think that matters very much, so long as your controller 
provides the necessary endpoints.

> If i follow the procedure
> 1) mkdir /dev/gadget
> 2) modprobe gadgetfs
> 3) mount -t gadgetfs none /dev/gadget
> 
> I get an error "nop ci_hdrc.0: failed to start (null): -120"

Somebody who is more familiar with the ci_hdrc driver will have to 
answer this.

> If you can guide with step by step procedure, I would be thankful
> 
> Thanks and Regards
> Ashwin Deshpande

Alan Stern

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

[GIT PULL] USB changes for v3.20

[Felipe Balbi]

Hi Greg,

Here's a big pull request for v3.20. All patches have been around
for quite a while. I have tested everything on AM437x SK, AM437x IDK,
AM335x BeagleBoneBlack and AM57x Beagleboard X15.

Let me know if you want me to change anything.

cheers

The following changes since commit ec6f34e5b552fb0a52e6aae1a5afbbb1605cc6cc:

  Linux 3.19-rc5 (2015-01-18 18:02:20 +1200)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git tags/usb-for-v3.20

for you to fetch changes up to 9298b4aad37e8c6962edcdbd0b62620adb207d03:

  usb: musb: fix device hotplug behind hub (2015-02-04 11:16:47 -0600)


usb: patches for v3.20 merge window

Here's the big pull request for Gadgets and PHYs. It's
a total of 217 non-merge commits with pretty much everything
being touched.

The most important bits are a ton of new documentation for
almost all usb gadget functions, a new isp1760 UDC driver,
several improvements to the old net2280 UDC driver, and
some minor tracepoint improvements to dwc3.

Other than that, a big list of minor cleanups, smaller bugfixes
and new features all over the place.

Signed-off-by: Felipe Balbi 


Amit Virdi (2):
  usb: dwc3: gadget: Remove redundant check
  usb: dwc3: Remove current_trb as it is unused

Andrzej Pietrasiewicz (26):
  Documentation: usb: gadget_serial: update generic serial setup instruction
  Documentation: usb: ACM function testing
  Documentation: usb: ECM function testing
  Documentation: usb: ECM subset function testing
  Documentation: usb: EEM function testing
  Documentation: usb: FFS function testing
  Documentation: usb: HID function testing
  Documentation: usb: LOOPBACK function testing
  Documentation: usb: MASS STORAGE function testing
  Documentation: usb: MIDI function testing
  Documentation: usb: NCM function testing
  Documentation: usb: OBEX function testing
  Documentation: usb: PHONET function testing
  Documentation: usb: RNDIS function testing
  Documentation: usb: SERIAL function testing
  Documentation: usb: SOURCESINK function testing
  Documentation: usb: UAC1 function testing
  Documentation: usb: UAC2 function testing
  Documentation: usb: UVC function testing
  usb: gadget: hid: consistently use 2^n - 1 for max values
  usb: gadget: f_uvc: rename a macro to avoid conflicts
  usb: gadget: uvc: verify descriptors presence
  usb: gadget: uvc: configfs support in uvc function
  usb: gadget: uvc: preserve the address passed to kfree()
  usb: gadget: uvc: use explicit type instead of void *
  usb: gadget: uvc: comments for iterating over streaming hierarchy

Andy Shevchenko (1):
  usb: gadget: ethernet: re-use %pM specifier to print MAC

Arnd Bergmann (3):
  usb: musb: add generic usb phy dependencies
  usb: musb: add omap-control dependency
  usb: dwc2: fix USB core dependencies

Asaf Vertz (1):
  usb: gadget: zero: fix format string warnings

Bin Liu (3):
  usb: musb: cppi41: correct the macro name EP_MODE_AUTOREG_*
  usb: musb: cppi41: improve rx channel abort routine
  usb: musb: fix device hotplug behind hub

Boris Brezillon (4):
  usb: atmel_usba_udc: Rework at91sam9rl errata handling
  usb: atmel_usba_udc: Add at91sam9g45 and at91sam9x5 errata handling
  usb: atmel_usba_udc: Mask status with enabled irqs
  usb: gadget: atmel_usba: Cache INT_ENB register value

Christoph Jaeger (1):
  usb: gadget: Kconfig: use bool instead of boolean

Dan Carpenter (6):
  usb: gadget: udc: clean up a printk
  usb: gadget: udc: remove bogus NULL check
  usb: gadget: uvc: fix some error codes
  usb: gadget: uvc: remove an impossible condition
  usb: gadget: uvc: memory leak in uvcg_frame_make()
  usb: gadget: uvc: cleanup UVCG_FRAME_ATTR macro

Dmitry Torokhov (1):
  usb: musb: blackfin: remove incorrect __exit_p()

Fabio Estevam (2):
  Documentation: usb: phy: nop: Fix the description of 'vcc-supply'
  usb: phy: phy-generic: Fix USB PHY gpio reset

Felipe Balbi (6):
  Merge tag 'v3.19-rc5' into next
  usb: dwc3: gadget: avoid variable shadowing
  usb: dwc3: gadget: WARN() in case of unknown IRQ
  usb: dwc3: trace: add trace logs for core and gadget
  usb: dwc3: remove reliance on dev_vdbg()
  usb: dwc3: gadget: add missing spin_lock()

Gregory Herrero (20):
  usb: dwc2: gadget: register gadget handle to the phy
  usb: dwc2: gadget: write correct value in ahbcfg register
  usb: dwc2: gadget: don't erase gahbcfg register when enabling dma
  usb: dwc2: gadget: add device tree property to enable dma
  Documentation: dt-bindings: add dt binding info for dwc2 g-use-dma
  usb: dwc2: gadget: configure fifos from device tree
  Documentation: dt-bindings: add dt 

Re: OOPS: musb_am335x: __device_attach

[Matwey V. Kornilov]

Hi,

I was able to use some gdb to touch the issue:

(gdb) monitor lsmod
Module  Size  modstruct Used by
musb_am335x 1431  0xbf0002781  (Loading) 0xbf00 [ ]
(gdb) bt
#0  0x73256020 in ?? ()
#1  0xc07a68f8 in driver_match_device (dev=, drv=) at ../drivers/base/base.h:117
#2  __device_attach (drv=0xc0ed5708 , 
data=0xdb624210) at ../drivers/base/dd.c:409
#3  0xc07a4920 in bus_for_each_drv (bus=, start=, 
data=0xda0, fn=0xc07a68c8 <__device_attach>)
at ../drivers/base/bus.c:463
#4  0xc07a64ac in device_attach (dev=0xdb624210) at ../drivers/base/dd.c:447
#5  0xc07a599c in bus_probe_device (dev=0xdb624210) at ../drivers/base/bus.c:558
#6  0xc07a3a60 in device_add (dev=) at 
../drivers/base/core.c:1058
#7  0xc08b6c0c in of_device_add (ofdev=) at 
../drivers/of/device.c:66
#8  0xc08b75dc in of_platform_device_create_pdata (np=, 
bus_id=0x0 <__vectors_start>, platform_data=0x0 <__vectors_start>,
parent=) at ../drivers/of/platform.c:241
#9  0xc08b7718 in of_platform_bus_create (bus=0xdfa46780, matches=0x0 
<__vectors_start>, lookup=0x0 <__vectors_start>, parent=0xdb183410,
strict=true) at ../drivers/of/platform.c:414
#10 0xc08b7b6c in of_platform_populate (root=0xdb624210, matches=0xc0ed5708 
, lookup=0xda0,
parent=0xc07a68c8 <__device_attach>) at ../drivers/of/platform.c:501
#11 0xbf30 in am335x_child_probe (pdev=0xdb183400) at 
../drivers/usb/musb/musb_am335x.c:12
#12 0xc07a8578 in platform_drv_probe (_dev=0xdb183410) at 
../drivers/base/platform.c:512
#13 0xc07a6670 in really_probe (drv=, dev=) at 
../drivers/base/dd.c:302
#14 driver_probe_device (drv=0xbf000234, dev=0xdb183410) at 
../drivers/base/dd.c:399
#15 0xc07a69a8 in __driver_attach (dev=0xdb183410, data=0xbf000234) at 
../drivers/base/dd.c:477
#16 0xc07a4870 in bus_for_each_dev (bus=, start=, 
data=0xda0, fn=0xc07a852c )
at ../drivers/base/bus.c:313
#17 0xc07a6044 in driver_attach (drv=) at 
../drivers/base/dd.c:496
#18 0xc07a5c78 in bus_add_driver (drv=0xbf000234) at ../drivers/base/bus.c:694
#19 0xc07a7174 in driver_register (drv=0xbf000234) at 
../drivers/base/driver.c:167
#20 0xc0209c34 in do_one_initcall (fn=0xbf002000) at ../init/main.c:801
#21 0xc02e0494 in do_init_module (mod=) at 
../kernel/module.c:3142
#22 load_module (info=0xdb6adf54, uargs=, flags=) 
at ../kernel/module.c:3461
#23 0xc02e0a44 in SYSC_finit_module (flags=, uargs=, fd=) at ../kernel/module.c:3537
#24 SyS_finit_module (fd=7, uargs=-1226138708, flags=0) at 
../kernel/module.c:3518
#25 0xc021a680 in ?? ()

Here some strange stuff. And I have no idea what is spear13xx_pcie_driver.

(gdb) frame 11
#11 0xbf30 in am335x_child_probe (pdev=0xdb183400) at 
../drivers/usb/musb/musb_am335x.c:12
12  ../drivers/usb/musb/musb_am335x.c: Нет такого файла или каталога.
(gdb) print pdev->dev.of_node
$8 = (struct device_node *) 0xdfa46574
(gdb) print &pdev->dev
$9 = (struct device *) 0xdb183410
(gdb) frame 10
#10 0xc08b7b6c in of_platform_populate (root=0xdb624210, matches=0xc0ed5708 
, lookup=0xda0, 
parent=0xc07a68c8 <__device_attach>) at ../drivers/of/platform.c:501
501 ../drivers/of/platform.c: Нет такого файла или каталога.
(gdb) print root
$10 = (struct device_node *) 0xdb624210
(gdb) print parent
$11 = (struct device *) 0xc07a68c8 <__device_attach>

Something wrong has happened between 10 and 11 frames.

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

Re: [PATCH v4 7/7] usb: serial: modify ioctl TIOCGSERIAL for F81232

[Johan Hovold]

On Fri, Jan 30, 2015 at 02:13:41PM +0800, Peter Hung wrote:
> Set correct product type from 16654 to 16550A and
> fix the ioctl TIOCGSERIAL return struct values.
> 
> Signed-off-by: Peter Hung 
> ---
>  drivers/usb/serial/f81232.c | 13 +
>  1 file changed, 9 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/usb/serial/f81232.c b/drivers/usb/serial/f81232.c
> index 0ed7e36..4d3aba8 100644
> --- a/drivers/usb/serial/f81232.c
> +++ b/drivers/usb/serial/f81232.c
> @@ -518,13 +518,18 @@ static int f81232_ioctl(struct tty_struct *tty,
>  
>   switch (cmd) {
>   case TIOCGSERIAL:

First of all, please break this out into a f81232_get_serial_info helper
function.

> - memset(&ser, 0, sizeof ser);
> - ser.type = PORT_16654;
> + memset(&ser, 0, sizeof(ser));
> + ser.flags   = ASYNC_SKIP_TEST | ASYNC_AUTO_IRQ;
> + ser.xmit_fifo_size  = port->bulk_out_size;
> + ser.close_delay = 5*HZ;
> + ser.closing_wait= 30*HZ;

Spaces around *

> +

No newline.

> + ser.type = PORT_16550A;
>   ser.line = port->minor;
>   ser.port = port->port_number;
> - ser.baud_base = 460800;
> + ser.baud_base = 115200;
>  
> - if (copy_to_user((void __user *)arg, &ser, sizeof ser))
> + if (copy_to_user((void __user *)arg, &ser, sizeof(ser)))
>   return -EFAULT;
>  
>   return 0;

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

Re: Control message failures kill entire XHCI stack

[Mathias Nyman]

On 27.01.2015 00:20, Alistair Grant wrote:
> I've come across what appears to be another xHCI issue - attempting to
> format a disk with gparted is causing a kernel Oops.  This may not be
> related to the issue you're currently investigating, but wanted to
> pass it on in case it is (if it isn't let me know and I'll either keep
> quiet or raise it separately, whatever you prefer).
> 
> I can easily reproduce the crash running 3.19rc6 with Mathias
> additional error and debugging messages (debugging switched off).  I
> wasn't able to reproduce the issue with xhci debugging enabled, i.e.:
> 

I got a some new patches to test, added to the same for-usb-next-test
branch in git://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git

Alistair, did you manage to Oops the kernel without the debug patches?
It might be caused by them (trying to access non-existing ep->ring->td_list 
pointer).

If you are able to reproduce the HDD gparted format oops on a normal (without 
my testpaches) 
kernel then I think it should be reported as a separate issue.

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

Re: [PATCH v4 6/7] usb: serial: implement MCR/MSR function for F81232

[Johan Hovold]

On Fri, Jan 30, 2015 at 02:13:40PM +0800, Peter Hung wrote:
> This patch implement relative MCR/MSR function, such like
> tiocmget()/tiocmset()/dtr_rts().
> 
> The update_mctrl() replace set_control_lines() to do MCR control
> so we clean-up the set_control_lines() function.
> 
> Signed-off-by: Peter Hung 
> ---
>  drivers/usb/serial/f81232.c | 105 
> ++--
>  1 file changed, 83 insertions(+), 22 deletions(-)
> 
> diff --git a/drivers/usb/serial/f81232.c b/drivers/usb/serial/f81232.c
> index 248f40d..0ed7e36 100644
> --- a/drivers/usb/serial/f81232.c
> +++ b/drivers/usb/serial/f81232.c
> @@ -38,11 +38,7 @@ MODULE_DEVICE_TABLE(usb, id_table);
>  #define UART_STATE_TRANSIENT_MASK0x74
>  #define UART_DCD 0x01
>  #define UART_DSR 0x02
> -#define UART_BREAK_ERROR 0x04
>  #define UART_RING0x08
> -#define UART_FRAME_ERROR 0x10
> -#define UART_PARITY_ERROR0x20
> -#define UART_OVERRUN_ERROR   0x40
>  #define UART_CTS 0x80
>  
>  #define REGISTER_REQUEST 0xA0
> @@ -55,6 +51,7 @@ MODULE_DEVICE_TABLE(usb, id_table);
>  #define INTERRUPT_ENABLE_REGISTER  (0x01 + SERIAL_BASE_ADDRESS)
>  #define FIFO_CONTROL_REGISTER  (0x02 + SERIAL_BASE_ADDRESS)
>  #define LINE_CONTROL_REGISTER  (0x03 + SERIAL_BASE_ADDRESS)
> +#define MODEM_CONTROL_REGISTER (0x04 + SERIAL_BASE_ADDRESS)
>  #define MODEM_STATUS_REGISTER  (0x06 + SERIAL_BASE_ADDRESS)
>  struct f81232_private {
>   spinlock_t lock;
> @@ -165,6 +162,62 @@ static void f81232_read_msr(struct f81232_private *priv)
>  
>   dev_dbg(&dev->dev, "%s: %x\n", __func__, priv->line_status);
>  }
> +
> +static inline int update_mctrl(struct f81232_private *port_priv,
> +unsigned int set, unsigned int clear)

Rename this on f81232_set_mctrl or similar, and pass the usb-serial port
instead of port-data.

Drop the inline (from all you functions).

> +{
> + struct usb_device *dev = port_priv->port->serial->dev;
> + u8 urb_value;
> + int status;
> + unsigned long flags;
> +
> + if (((set | clear) & (TIOCM_DTR | TIOCM_RTS)) == 0) {
> + dev_dbg(&dev->dev, "%s fail - DTR|RTS %d\n",
> + __func__, __LINE__);

Just skip the dev_dbg.

> + return 0;   /* no change */
> + }
> +
> + clear &= ~set;  /* 'set' takes precedence over 'clear' */
> + urb_value = 8 | port_priv->line_control;

Use the UART_MCR_OUT2 define if needed (and comment on why).

> +
> + if (clear & TIOCM_DTR) {
> + urb_value &= ~UART_MCR_DTR;
> + dev_dbg(&dev->dev, "clear DTR\n");
> + }
> +
> + if (clear & TIOCM_RTS) {
> + urb_value &= ~UART_MCR_RTS;
> + dev_dbg(&dev->dev, "clear RTS\n");
> + }
> +
> + if (set & TIOCM_DTR) {
> + urb_value |= UART_MCR_DTR;
> + dev_dbg(&dev->dev, "set DTR\n");
> + }
> +
> + if (set & TIOCM_RTS) {
> + urb_value |= UART_MCR_RTS;
> + dev_dbg(&dev->dev, "set RTS\n");
> + }

You don't need all those dev_dbg, the one below should suffice.

> +
> + dev_dbg(&dev->dev, "%s n:%x o:%x\n", __func__, urb_value,
> + port_priv->line_control);

Use %02x, and it doesn't hurt spelling out "new" and "old".

> +
> + status = f81232_set_register(dev, MODEM_CONTROL_REGISTER, urb_value);
> +
> + if (status < 0) {
> + dev_dbg(&dev->dev, "%s read MSR status < 0\n", __func__);

dev_err, and the error message is incorrect (you're updating MCR).

> + } else {
> + spin_lock_irqsave(&port_priv->lock, flags);
> + port_priv->line_control = urb_value;
> + spin_unlock_irqrestore(&port_priv->lock, flags);
> + }
> +
> + f81232_read_msr(port_priv);

Won't you get an interrupt if MSR changes?

> +
> + return status;
> +}
> +
>  static void f81232_update_line_status(struct usb_serial_port *port,
> unsigned char *data,
> unsigned int actual_length)
> @@ -261,12 +314,6 @@ static void f81232_process_read_urb(struct urb *urb)
>  
>  }
>  
> -static int set_control_lines(struct usb_device *dev, u8 value)
> -{
> - /* FIXME - Stubbed out for now */
> - return 0;
> -}
> -
>  static void f81232_break_ctl(struct tty_struct *tty, int break_state)
>  {
>   /* FIXME - Stubbed out for now */
> @@ -383,14 +430,35 @@ static void f81232_set_termios(struct tty_struct *tty,
>  
>  static int f81232_tiocmget(struct tty_struct *tty)
>  {
> - /* FIXME - Stubbed out for now */
> - return 0;
> + int r;
> + struct usb_serial_port *port = tty->driver_data;
> + struct f81232_private *port_priv = usb_get_serial_port_data(port);
> + unsigned long flags;
> + u8 mcr, msr;
> +
> + spin_lock_irqsave(&port_priv->lock, flags);
> + mcr

Re: [PATCH v4 5/7] usb: serial: implement set_termios for F81232

[Johan Hovold]

On Fri, Jan 30, 2015 at 02:13:39PM +0800, Peter Hung wrote:
> The original driver had do not any h/w change in driver.
> This patch implements with configure H/W for
> baud/parity/word length/stop bits functional.
> 
> Signed-off-by: Peter Hung 
> ---
>  drivers/usb/serial/f81232.c | 144 
> +---
>  1 file changed, 137 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/usb/serial/f81232.c b/drivers/usb/serial/f81232.c
> index 12e1ae4..248f40d 100644
> --- a/drivers/usb/serial/f81232.c
> +++ b/drivers/usb/serial/f81232.c
> @@ -51,6 +51,10 @@ MODULE_DEVICE_TABLE(usb, id_table);
>  #define F81232_USB_TIMEOUT 3000
>  
>  #define SERIAL_BASE_ADDRESS (0x0120)
> +#define RECEIVE_BUFFER_REGISTER(0x00 + SERIAL_BASE_ADDRESS)
> +#define INTERRUPT_ENABLE_REGISTER  (0x01 + SERIAL_BASE_ADDRESS)
> +#define FIFO_CONTROL_REGISTER  (0x02 + SERIAL_BASE_ADDRESS)
> +#define LINE_CONTROL_REGISTER  (0x03 + SERIAL_BASE_ADDRESS)
>  #define MODEM_STATUS_REGISTER  (0x06 + SERIAL_BASE_ADDRESS)
>  struct f81232_private {
>   spinlock_t lock;
> @@ -61,6 +65,20 @@ struct f81232_private {
>   struct usb_serial_port *port;
>  };
>  
> +static inline int calc_baud_divisor(u32 baudrate)

No need for inline.

> +{
> + u32 divisor, rem;
> +
> + divisor = 115200L / baudrate;
> + rem = 115200L % baudrate;

Use a define for the base baud rate. Is 115200 really the maximum baud
rate?

> +
> + /* Round to nearest divisor */
> + if (((rem * 2) >= baudrate) && (baudrate != 110))
> + divisor++;

Can't you use DIV_ROUND_CLOSEST here as serial core does?

> +
> + return divisor;
> +}
> +
>  static inline int f81232_get_register(struct usb_device *dev,
> u16 reg, u8 *data)

No inline.

>  {
> @@ -84,6 +102,29 @@ static inline int f81232_get_register(struct usb_device 
> *dev,
>   return status;
>  }
>  
> +static inline int f81232_set_register(struct usb_device *dev,
> +   u16 reg, u8 data)

Pass the usb-serial port instead of usb device here as well.

> +{
> + int status;
> +
> + status = usb_control_msg(dev,
> + usb_sndctrlpipe(dev, 0),
> + REGISTER_REQUEST,
> + SET_REGISTER,
> + reg,
> + 0,
> + &data,
> + 1,

sizeof(data) for clarity?

> + F81232_USB_TIMEOUT);
> +
> + if (status < 0) {
> + dev_dbg(&dev->dev,
> + "%s status: %d\n", __func__, status);

dev_err, no line break

> + }
> +
> + return status;
> +}
> +
>  static void f81232_read_msr(struct f81232_private *priv)
>  {
>   int status;
> @@ -240,15 +281,104 @@ static void f81232_break_ctl(struct tty_struct *tty, 
> int break_state)
>  static void f81232_set_termios(struct tty_struct *tty,
>   struct usb_serial_port *port, struct ktermios *old_termios)
>  {
> - /* FIXME - Stubbed out for now */
> + u16 divisor;
> + u16 new_lcr = 0;

Why u16 for an 8-bit register?

> + u8 data;
> + int status;
> + struct ktermios *termios = &tty->termios;
> + struct usb_device *dev = port->serial->dev;
> + unsigned int cflag = termios->c_cflag;

Use the cflag macros directly below (e.g. C_PARENB(tty)) and you won't
need this (or termios above).

>  
> - /* Don't change anything if nothing has changed */
> - if (old_termios && !tty_termios_hw_change(&tty->termios, old_termios))
> - return;
> + divisor = calc_baud_divisor(tty_get_baud_rate(tty));

You get a division by zero here of the baud rate is 0 (B0 is used to
drop DTR/RTS).

> +
> + status = f81232_set_register(dev, LINE_CONTROL_REGISTER,
> +  UART_LCR_DLAB); /* DLAB */
> +

No newline before testing return values (again, applies to whole
series).

> + if (status < 0) {
> + dev_dbg(&dev->dev,
> + "%s status: %d line:%d\n", __func__, status, __LINE__);
> + }

Use dev_err for errors throughout, but remember that you already log
errors in the accessor function.

> +
> + status = f81232_set_register(dev, RECEIVE_BUFFER_REGISTER,
> +  divisor & 0x00ff); /* low */
> +
> + if (status < 0) {
> + dev_dbg(&dev->dev,
> + "%s status: %d line:%d\n", __func__, status, __LINE__);
> + }
> +
> + status = f81232_set_register(dev, INTERRUPT_ENABLE_REGISTER,
> +  (divisor & 0xff00) >> 8); /* high */
> +
> + if (status < 0) {
> + dev_dbg(&dev->dev,
> + "%s status: %d line:%d\n", __func__, status, __LINE__);
> + }
> +
> + status = f81232_set_register(dev, LINE_CONTROL_REGISTER, 0x00);
> +
> + if (status < 0) {
> + dev_dbg(&dev->dev,
> + "%s status: %d 

Re: f_hid, f_mass_storage, and f_rdnis via configfs on platform/intel-mid

[Chris McClimans]

Hi Andrzej,

Thank you for your time.

I'd like to take a stab at FunctionFS before I start looking at
backporting hid and uvc from 3.19+

I found a lot of information (mainly from you [1] [2]) on gadget
ConfigFS and hid, but I'm
having less luck finding information on FunctionFS and the required daemons.

On Thu, Jan 22, 2015 at 7:33 AM, Andrzej Pietrasiewicz
 wrote:

> These days instead of gadgetfs one should probably use FunctionFS.
> The purpose of the two is delegating actual usb function implementation
> to userspace with some filesystem being the interface to the kernel.

It looks like I should be able to combine Ethernet, Mass Storage, and
HID this way.
(and it's supported all the way back to 3.10)
However I haven't found any ffs-daemon examples, including the
hid-daemon mentioned
in the kernel source.

Also I'm not quite sure how the loading g_ffs enables Ethernet in the docs.
Is g_ffs loaded after a g_multi that included Ethernet?

""" from Documentation/usb/functionfs.txt
One can imagine a gadget that has an Ethernet, MTP and HID interfaces
where the last two are implemented via FunctionFS. On user space
level it would look like this:

$ insmod g_ffs.ko idVendor= iSerialNumber= functions=mtp,hid
$ mkdir /dev/ffs-mtp && mount -t functionfs mtp /dev/ffs-mtp
$ ( cd /dev/ffs-mtp && mtp-daemon ) &
$ mkdir /dev/ffs-hid && mount -t functionfs hid /dev/ffs-hid
$ ( cd /dev/ffs-hid && hid-daemon ) &
"""

[1] 
http://events.linuxfoundation.org/sites/events/files/slides/LinuxConNA2013-andrzej.pietrasiewicz-usb-gadget-configfs_0.pdf
[2] 
https://wiki.tizen.org/wiki/USB/Linux_USB_Layers/Configfs_Composite_Gadget/Usage_eq._to_g_hid.ko
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] usb: dwc2: gadget reuse ahbcfg assigned from platform

[Sergei Shtylyov]

Hello.

On 02/04/2015 11:01 AM, Zhangfei Gao wrote:


Gadget directly set GAHBCFG_HBSTLEN_INCR4, reuse ahbcfg if assigned from 
platform



Signed-off-by: Zhangfei Gao 


[...]


diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index 15aa578..20085de 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -2314,9 +2314,13 @@ void s3c_hsotg_core_init_disconnected(struct dwc2_hsotg 
*hsotg,
GINTSTS_USBSUSP | GINTSTS_WKUPINT,
hsotg->regs + GINTMSK);

+   if ((hsotg->core_params) && (hsotg->core_params->ahbcfg != -1))


   Inner pares not needed, especially the first ones.

[...]

WBR, Sergei

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

[PATCH] hso: Use static attribute groups for sysfs entry

[Takashi Iwai]

Pass the static attribute groups and the driver data via
tty_port_register_device_attr() instead of manual device_create_file()
and device_remove_file() calls.

Signed-off-by: Takashi Iwai 
---
 drivers/net/usb/hso.c | 17 ++---
 1 file changed, 10 insertions(+), 7 deletions(-)

diff --git a/drivers/net/usb/hso.c b/drivers/net/usb/hso.c
index 9c5aa922a9f4..1ecca185510d 100644
--- a/drivers/net/usb/hso.c
+++ b/drivers/net/usb/hso.c
@@ -533,6 +533,13 @@ static ssize_t hso_sysfs_show_porttype(struct device *dev,
 }
 static DEVICE_ATTR(hsotype, S_IRUGO, hso_sysfs_show_porttype, NULL);
 
+static struct attribute *hso_serial_dev_attrs[] = {
+   &dev_attr_hsotype.attr,
+   NULL
+};
+
+ATTRIBUTE_GROUPS(hso_serial_dev);
+
 static int hso_urb_to_index(struct hso_serial *serial, struct urb *urb)
 {
int idx;
@@ -2232,9 +2239,6 @@ static void hso_serial_common_free(struct hso_serial 
*serial)
 {
int i;
 
-   if (serial->parent->dev)
-   device_remove_file(serial->parent->dev, &dev_attr_hsotype);
-
tty_unregister_device(tty_drv, serial->minor);
 
for (i = 0; i < serial->num_rx_urbs; i++) {
@@ -2264,11 +2268,10 @@ static int hso_serial_common_create(struct hso_serial 
*serial, int num_urbs,
goto exit;
 
/* register our minor number */
-   serial->parent->dev = tty_port_register_device(&serial->port, tty_drv,
-   minor, &serial->parent->interface->dev);
+   serial->parent->dev = tty_port_register_device_attr(&serial->port,
+   tty_drv, minor, &serial->parent->interface->dev,
+   serial->parent, hso_serial_dev_groups);
dev = serial->parent->dev;
-   dev_set_drvdata(dev, serial->parent);
-   i = device_create_file(dev, &dev_attr_hsotype);
 
/* fill in specific data for later use */
serial->minor = minor;
-- 
2.2.2

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

Re: [PATCH v2 1/3] usb: XHCI: platform: Move the Marvell quirks after the enabling the clocks

[Greg Kroah-Hartman]

On Wed, Feb 04, 2015 at 10:35:22AM +0100, Maxime Ripard wrote:
> Hi Mathias, Greg,
> 
> On Mon, Jan 19, 2015 at 02:01:12PM +0100, Maxime Ripard wrote:
> > The commit 973747928514 ("usb: host: xhci-plat: add support for the Armada
> > 375/38x XHCI controllers") extended the xhci-plat driver to support the 
> > Armada
> > 375/38x SoCs, mostly by adding a quirk configuring the MBUS window.
> > 
> > However, that quirk was run before the clock the controllers needs has been
> > enabled. This usually worked because the clock was first enabled by the
> > bootloader, and left as such until the driver is probe, where it tries to
> > access the MBUS configuration registers before enabling the clock.
> > 
> > Things get messy when EPROBE_DEFER is involved during the probe, since as 
> > part
> > of its error path, the driver will rightfully disable the clock. When the
> > driver will be reprobed, it will retry to access the MBUS registers, but 
> > this
> > time with the clock disabled, which hangs forever.
> > 
> > Fix this by running the quirks after the clock has been enabled by the 
> > driver.
> > 
> > Signed-off-by: Maxime Ripard 
> > Cc:  # v3.16+
> 
> Any chance for this to go in 3.19?

For 3.19?  It's too late, I'm not sending anything else to Linus as 3.19
will be out in a few days.

thanks,

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

Re: [PATCH v4 4/7] usb: serial: reimplement RX bulk-in ep for F81232

[Johan Hovold]

On Fri, Jan 30, 2015 at 02:13:38PM +0800, Peter Hung wrote:
> The F81232 bulk-in is RX data channel. Data format is
> [LSR+Data][LSR+Data]. , We had reimplemented in this patch.
> 
> Signed-off-by: Peter Hung 
> ---
>  drivers/usb/serial/f81232.c | 47 
> +++--
>  1 file changed, 15 insertions(+), 32 deletions(-)
> 
> diff --git a/drivers/usb/serial/f81232.c b/drivers/usb/serial/f81232.c
> index 274120d..12e1ae4 100644
> --- a/drivers/usb/serial/f81232.c
> +++ b/drivers/usb/serial/f81232.c
> @@ -194,47 +194,30 @@ exit:
>  static void f81232_process_read_urb(struct urb *urb)
>  {
>   struct usb_serial_port *port = urb->context;
> - struct f81232_private *priv = usb_get_serial_port_data(port);
>   unsigned char *data = urb->transfer_buffer;
>   char tty_flag = TTY_NORMAL;
> - unsigned long flags;
> - u8 line_status;
> + u8 line_status = 0;
>   int i;
>  
> - /* update line status */
> - spin_lock_irqsave(&priv->lock, flags);
> - line_status = priv->line_status;
> - priv->line_status &= ~UART_STATE_TRANSIENT_MASK;
> - spin_unlock_irqrestore(&priv->lock, flags);
> -
>   if (!urb->actual_length)
>   return;
>  
> - /* break takes precedence over parity, */
> - /* which takes precedence over framing errors */
> - if (line_status & UART_BREAK_ERROR)
> - tty_flag = TTY_BREAK;
> - else if (line_status & UART_PARITY_ERROR)
> - tty_flag = TTY_PARITY;
> - else if (line_status & UART_FRAME_ERROR)
> - tty_flag = TTY_FRAME;
> - dev_dbg(&port->dev, "%s - tty_flag = %d\n", __func__, tty_flag);
> -
> - /* overrun is special, not associated with a char */
> - if (line_status & UART_OVERRUN_ERROR)
> - tty_insert_flip_char(&port->port, 0, TTY_OVERRUN);
> -
> - if (port->port.console && port->sysrq) {
> - for (i = 0; i < urb->actual_length; ++i)
> - if (!usb_serial_handle_sysrq_char(port, data[i]))
> - tty_insert_flip_char(&port->port, data[i],
> - tty_flag);
> - } else {
> - tty_insert_flip_string_fixed_flag(&port->port, data, tty_flag,
> - urb->actual_length);
> + /* bulk-in data: [LSR(1Byte)+DATA(1Byte)][LSR(1Byte)+DATA(1Byte)]... */
> +
> + if (urb->actual_length >= 2) {

Just return unless length < 2 and reduce indentation below.

Should should probably make sure the returned length is even as well.

> +
> + for (i = 0 ; i < urb->actual_length ; i += 2) {
> + line_status |= data[i+0];
> + tty_insert_flip_string_fixed_flag(&port->port,
> + &data[i+1], tty_flag, 1);
> + }
> +
> + if (unlikely(line_status & UART_LSR_OE))
> + tty_insert_flip_char(&port->port, 0, TTY_OVERRUN);

This needs some more work as you need to determine tty_flag for each
character based on the line status using the priorities that you remove
above (i.e. break takes precedence over parity, etc).

Also insert a overrun char for every individual overrun error.

> +
> + tty_flip_buffer_push(&port->port);
>   }
>  
> - tty_flip_buffer_push(&port->port);
>  }
>  
>  static int set_control_lines(struct usb_device *dev, u8 value)

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

Re: [PATCH v4 3/7] usb: serial: implement read IIR/MSR ep for F81232

[Johan Hovold]

On Fri, Jan 30, 2015 at 02:13:37PM +0800, Peter Hung wrote:
> The F81232 interrupt ep will continuously report IIR register value.
> We had implement the interrupt callback to read IIR, If noticed with
> MSR change, we will call worker to read MSR later.
> 
> Signed-off-by: Peter Hung 
> ---
>  drivers/usb/serial/f81232.c | 114 
> +---
>  1 file changed, 107 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/usb/serial/f81232.c b/drivers/usb/serial/f81232.c
> index 9ef9775..274120d 100644
> --- a/drivers/usb/serial/f81232.c
> +++ b/drivers/usb/serial/f81232.c
> @@ -23,6 +23,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  static const struct usb_device_id id_table[] = {
>   { USB_DEVICE(0x1934, 0x0706) },
> @@ -44,23 +45,112 @@ MODULE_DEVICE_TABLE(usb, id_table);
>  #define UART_OVERRUN_ERROR   0x40
>  #define UART_CTS 0x80

Now that your including serial_req and using the standard register
masks, you should remove the old (incorrect ones) at some point. Most
are left unused after the whole series has been applied (except UART_DCD
and that looks like a bug).

>  
> +#define REGISTER_REQUEST 0xA0
> +#define GET_REGISTER 0xc0
> +#define SET_REGISTER 0x40

Add a F81232-prefix to these (and other driver specific defines), and a
new line before the time out.

> +#define F81232_USB_TIMEOUT 3000
> +
> +#define SERIAL_BASE_ADDRESS (0x0120)

No parentheses.

> +#define MODEM_STATUS_REGISTER  (0x06 + SERIAL_BASE_ADDRESS)

Missing newline.

>  struct f81232_private {
>   spinlock_t lock;
>   u8 line_control;
>   u8 line_status;

How about renaming this one modem_status?

> +
> + struct work_struct int_worker;

Call this one interrupt_work instead.

> + struct usb_serial_port *port;
>  };
>  
> +static inline int f81232_get_register(struct usb_device *dev,
> +   u16 reg, u8 *data)

Let the compiler decide whether this should be inlined.

Should should probably also pass the usb-serial port rather than
usb_device and use &port->dev for the error message.

> +{
> + int status;
> +
> + status = usb_control_msg(dev,
> +  usb_rcvctrlpipe(dev, 0),
> +  REGISTER_REQUEST,
> +  GET_REGISTER,
> +  reg,
> +  0,
> +  data,
> +  sizeof(*data),
> +  F81232_USB_TIMEOUT);
> +
> + if (status < 0) {
> + dev_dbg(&dev->dev,
> + "%s status: %d\n", __func__, status);

dev_err.

Is the line break needed still?

> + }
> +
> + return status;
> +}
> +
> +static void f81232_read_msr(struct f81232_private *priv)
> +{
> + int status;
> + unsigned long flags;
> + u8 current_msr, old_msr;
> + struct usb_device *dev = priv->port->serial->dev;
> + struct tty_struct *tty;
> +
> + status = f81232_get_register(dev, MODEM_STATUS_REGISTER, ¤t_msr);
> +

No newline before checking the return value. Comment applies to whole series.

> + if (status < 0) {
> + dev_dbg(&dev->dev, "%s fail, status: %d\n", __func__, status);
> + return;
> + }

You already logged the error in get_register, but use dev_err (and
&port->dev) if you want this here.

> +
> + spin_lock_irqsave(&priv->lock, flags);
> + old_msr = priv->line_status;
> + spin_unlock_irqrestore(&priv->lock, flags);

You never use old_msr so just drop this bit.

> +
> + if (current_msr & UART_MSR_ANY_DELTA) {

Just return unless there has been a change and reduce the indentation
below.

> + tty = tty_port_tty_get(&priv->port->port);
> +
> + if (tty) {
> + if (current_msr & UART_MSR_DDCD) {
> + usb_serial_handle_dcd_change(priv->port,
> + tty, current_msr & UART_MSR_DCD);
> + }
> +
> + tty_kref_put(tty);
> + }
> +
> + spin_lock_irqsave(&priv->lock, flags);
> + priv->line_status = current_msr;
> + spin_unlock_irqrestore(&priv->lock, flags);
> +
> + wake_up_interruptible(&priv->port->port.delta_msr_wait);
> + }
> +
> + dev_dbg(&dev->dev, "%s: %x\n", __func__, priv->line_status);
> +}

Missing newline.

>  static void f81232_update_line_status(struct usb_serial_port *port,
> unsigned char *data,
> unsigned int actual_length)
>  {
> - /*
> -  * FIXME: Update port->icount, and call
> -  *
> -  *  wake_up_interruptible(&port->port.delta_msr_wait);
> -  *
> -  *on MSR changes.
> -  */
> + struct f81232_private *priv = usb_get_serial_port_data(port);
> + struct usb_device *dev = port->serial->dev;

Use &port->dev for debugging and d

Re: [PATCH v4 2/7] usb: serial: modify author for F81232

[Johan Hovold]

On Fri, Jan 30, 2015 at 02:13:36PM +0800, Peter Hung wrote:
> add co-author and fix no '>' in greg kh's email

This is trivial enough to be done in one patch I guess, but please put
this one last in the series.

Also for all your patches use a subject on the following format:

"USB: f81232: ..."

Please also include a cover-letter (e.g. use git format-patch
--cover-letter) where you can describe what has changed when you submit
a new revision of the series.

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

Re: [PATCH v4 1/7] usb: serial: modify bulk-in/out size for F81232

[Johan Hovold]

On Fri, Jan 30, 2015 at 02:13:35PM +0800, Peter Hung wrote:
> The F81232 real bulk-in/out ep buffer size is 64Bytes
> 
> Signed-off-by: Peter Hung 
> ---
>  drivers/usb/serial/f81232.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/usb/serial/f81232.c b/drivers/usb/serial/f81232.c
> index c5dc233..4f42e9d 100644
> --- a/drivers/usb/serial/f81232.c
> +++ b/drivers/usb/serial/f81232.c
> @@ -304,8 +304,8 @@ static struct usb_serial_driver f81232_device = {
>   },
>   .id_table = id_table,
>   .num_ports =1,
> - .bulk_in_size = 256,
> - .bulk_out_size =256,
> + .bulk_in_size = 64,
> + .bulk_out_size =64,

These buffer sizes can be larger than the endpoint sizes for increased
throughput (the host controller driver will break them up).

If you still want them to match the endpoint sizes you should just leave
them unset (0) and usb-serial core will set them for you.

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

Re: intensive IO on usb-storage device causing system lock

[Enrico Mioso]

The situation is unchanged, but I noticed there is a continous process of 
creating workers. They might die at some point, but I noticed them now.


Sorry for the verbosity. Here's the last trace:
http://cxg.de/_dedb43.htm

And process list:
  PID TTY  STAT   TIME COMMAND
1 ?Ss 0:01 /sbin/init auto
2 ?S  0:00 [kthreadd]
3 ?S  0:16 [ksoftirqd/0]
5 ?S< 0:00 [kworker/0:0H]
7 ?S< 0:00 [khelper]
8 ?S  0:00 [kdevtmpfs]
9 ?S< 0:00 [perf]
  107 ?S< 0:00 [writeback]
  110 ?S< 0:00 [crypto]
  111 ?S< 0:00 [bioset]
  113 ?S< 0:00 [kblockd]
  160 ?S< 0:00 [ata_sff]
  162 ?S  0:26 [kswapd0]
  163 ?S  0:00 [fsnotify_mark]
  167 ?S< 0:00 [kthrotld]
  420 ?S  0:10 [kworker/u2:2]
  421 ?S  0:00 [scsi_eh_0]
  438 ?S< 0:00 [scsi_tmf_0]
  441 ?S  0:00 [scsi_eh_1]
  442 ?S< 0:00 [scsi_tmf_1]
  468 ?S< 0:00 [deferwq]
  482 ?S< 0:00 [ext4-rsv-conver]
  499 ?S< 0:00 [ipv6_addrconf]
  536 ?Ss 0:06 /usr/lib/systemd/systemd-journald
  913 ?Ss 0:00 /usr/lib/systemd/systemd-udevd
  933 ?S< 0:00 [kpsmoused]
  961 ?Ss 0:01 /usr/lib/systemd/systemd-logind
  967 ?Ss 0:00 /usr/bin/dbus-daemon --system --address=systemd: 
--nofork --nopidfile --systemd-activation
  970 ?S< 0:00 [acpi_thermal_pm]
 1016 ?S< 0:00 [cfg80211]
 1036 ?S< 0:00 [hd-audio0]
 1037 ?Ss 0:00 /usr/bin/sshd -D
 1074 ?S< 0:01 [kworker/u3:0]
 1075 ?S< 0:00 [hci0]
 1076 ?S< 0:00 [hci0]
 1077 ?S< 0:01 [kworker/u3:1]
 1116 ?S  0:00 [scsi_eh_2]
 1121 ?S< 0:00 [scsi_tmf_2]
 1122 ?S  0:00 [usb-storage]
 1171 ?S< 0:00 [kworker/0:1H]
 1220 ?Ss 0:00 /usr/lib/bluetooth/bluetoothd
 1235 ?Rsl1:25 brltty -b al -d bluetooth:00:A0:96:31:E5:1E
 1244 ?S< 0:00 [krfcommd]
 1276 ?S  0:00 [scsi_eh_3]
 1278 ?S< 0:00 [scsi_tmf_3]
 1279 ?S  0:20 [usb-storage]
 1300 ?Ss 0:00 login -- mrkiko
 1302 ?Ss 0:00 login -- mrkiko
 1304 ?Ss 0:00 login -- mrkiko
 1312 ?Ss 0:00 login -- mrkiko
 1314 ?Ss 0:00 login -- mrkiko
 1316 ?Ss 0:00 login -- mrkiko
 1318 ?Ss 0:00 login -- mrkiko
 1319 ?Ss 0:00 login -- mrkiko
 1326 ?Ss 0:00 login -- mrkiko
 1332 ?Ss 0:00 login -- mrkiko
 1334 ?Ss 0:00 login -- mrkiko
 1337 tty2 Ss 0:00 -bash
 1351 ?Ssl0:00 /usr/lib/polkit-1/polkitd --no-debug
 1407 ?Ss 0:00 /usr/bin/dhcpcd -q -w enp3s0
 1410 tty3 Ss+0:00 -bash
 1417 tty4 Ss+0:00 -bash
 1424 tty5 Ss+0:00 -bash
 1431 tty6 Ss+0:00 -bash
 1438 tty7 Ss+0:00 -bash
 1445 tty8 Ss+0:00 -bash
 1452 tty9 Ss+0:00 -bash
 1459 tty10Ss+0:00 -bash
 1465 tty11Ss+0:00 -bash
 1473 tty12Ss 0:00 -bash
 1494 tty12S+ 0:07 finch
 1536 ?S< 0:00 [ext4-rsv-conver]
 1804 ?Dsl2:12 mpd .mpdconf
 3112 ?S< 0:00 [ext4-rsv-conver]
 3161 ?S  0:00 [kworker/u2:1]
 3166 tty2 S  0:00 sudo su root
 3167 tty2 S  0:00 su root
 3168 tty2 S  0:00 bash
 3178 tty2 D+ 0:00 dmesg
 3183 ?Ss 0:00 login -- mrkiko
 3205 ?S  0:00 [kworker/0:0]
 3240 tty1 Ss 0:00 -bash
 3535 ?S  0:00 [kworker/0:1]
 3545 ?S  0:00 [kworker/0:2]
 3561 tty1 S+ 0:00 alpine -i
 3565 tty1 S+ 0:00 nano /tmp/pico.05873
 3566 tty1 R+ 0:00 ps ax

Where kworkers with PID 3535 and 3545 looked interesting to me.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: intensive IO on usb-storage device causing system lock

[Enrico Mioso]

Another note - I noticed the load average doesn't go down 2.02; and top doesn't 
evidence any particularly CPU-hungry or memory-hungry process.
However, dmesg and mpd processes are still stuck, the rest of the system runs 
normally apparently. The USB disk spinned down, like thhere is no process 
accessing it - at the moment ony mpd was accessing it, rtorrent and screen 
where terminated before it was too late, strangely I got the chance to do so.

It's very interesting guys.
Enrico


On Tue, 3 Feb 2015, Alan Stern wrote:


Date: Tue, 3 Feb 2015 19:02:48
From: Alan Stern 
To: Enrico Mioso 
Cc: linux-usb@vger.kernel.org
Subject: Re: intensive IO on usb-storage device causing system lock

On Tue, 3 Feb 2015, Enrico Mioso wrote:


Hi guys.
I finally was able to obtain some informations about what was going on - infos 
I retained useful.
I am re-sending these, since it seems my previous message didn't get to the 
list - but might be I am wrong and didn't find it.
This time I posted all the traces to a pstebin, so that it's easier to read the
message and might be there are less problems with it in general.

1 - First trace: there where no problems
http://cxg.de/_298ad9.htm

2 - Trace immediately before the crash
http://cxg.de/_c43356.htm


Without CONFIG_FRAME_POINTER, the stack traces are not very helpful.



3 - lspci:
http://cxg.de/_4f202a.htm
4 - lsusb:
http://cxg.de/_223f6c.htm

Any help / hint would be very apreciated.


You have two USB mass storage devices.  Do you know which one is
connected to the problem?

You can try using usbmon to see what's going on at the USB level.  See
Documentation/usb/usbmon.txt for instructions.

Alan Stern



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

Re: intensive IO on usb-storage device causing system lock

[Enrico Mioso]

Sorry guys - I was wrong: the process appears in the traces.
And if I read the call trace correctly is's stuck in apic_write ?

Enrico
On Tue, 3 Feb 2015, Alan Stern wrote:


Date: Tue, 3 Feb 2015 19:02:48
From: Alan Stern 
To: Enrico Mioso 
Cc: linux-usb@vger.kernel.org
Subject: Re: intensive IO on usb-storage device causing system lock

On Tue, 3 Feb 2015, Enrico Mioso wrote:


Hi guys.
I finally was able to obtain some informations about what was going on - infos 
I retained useful.
I am re-sending these, since it seems my previous message didn't get to the 
list - but might be I am wrong and didn't find it.
This time I posted all the traces to a pstebin, so that it's easier to read the
message and might be there are less problems with it in general.

1 - First trace: there where no problems
http://cxg.de/_298ad9.htm

2 - Trace immediately before the crash
http://cxg.de/_c43356.htm


Without CONFIG_FRAME_POINTER, the stack traces are not very helpful.



3 - lspci:
http://cxg.de/_4f202a.htm
4 - lsusb:
http://cxg.de/_223f6c.htm

Any help / hint would be very apreciated.


You have two USB mass storage devices.  Do you know which one is
connected to the problem?

You can try using usbmon to see what's going on at the USB level.  See
Documentation/usb/usbmon.txt for instructions.

Alan Stern



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

Re: [PATCH v2] usb: gadget: OS desc type unicode multi

[Andrzej Pietrasiewicz]

Hi Mario,

sorry about the delay but I was busy with other things yesterday.

W dniu 02.02.2015 o 21:37, Mario Schuknecht pisze:

Hi Andrzej,

thank you for the comment.









I'm not sure I understand the logic of the below function well.


+static inline int usb_ext_prop_put_unicode_multi(u8 *buf, int pnl,
+   const char *string, int data_len)
+{
+   int outlen = 0;
+
+   put_unaligned_le32(data_len, usb_ext_prop_data_len_ptr(buf, pnl));
+
+   while (*string && outlen < data_len - 2) {



You keep looping as long as the source *string is not '\0'
and advance the string in each loop by adding (strlen() + 1) of
what is currently available starting at *string.
For example:

string: "a\0b\0and this is past the end of your source buffer"

first loop iteration:
len = strlen(string); /* len == 1 */
string += len + 1; /* string: "b\0and this is past the end of your source
buffer" */

second loop iteration:
len = strlen(string); /* len == 1 */
string += len + 1; /* string: "and this is past the end of your source
buffer" */

so effectively the first part of the while condition rarely ever becomes
"false".
In other words when you process all the source strings from "string" you, by
design,
end up one byte past the terminating '\0' of the source buffer. The contents
of this memory can be anything, there is just 1/256 chance it is zero,
so the "while (*string" part does not make sense to me.


The assumtion is that the input string is also double Nul-terminated.
E.g. "one\0two\0three\0\0"

Should I add a parameter "inlen" which contains the input buffer length?


Ah, right. Now I see your point. You need to be able to tell
whether the current "sub"string is the last one or not.


Or can I trust that the input string is double Nul-terminated?


Extended Properties support is meant primarily to be used with the
configfs interface. The user creates a directory in /interface..
The name of the directory becomes the name of the property. Inside
the directory there are two attribute files: "data" and "type".
The user stores numeric type id into "type", in this case "7".
And then the user stores property's contents into "data".
From this perspective double termination seems awkward,
as a user I would expect that I just store a sequence of
NUL-terminated strings without additional terminator.
But this approach implies passing some additional information
to usb_ext_prop_put_unicode_multi() instead.

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

Re: intensive IO on usb-storage device causing system lock

[Enrico Mioso]

Hello guys.
This time I am managing to use the system while in the "middle of the problem".

From the command: "ps aux"

USER   PID %CPU %MEMVSZ   RSS TTY  STAT START   TIME COMMAND
root 1  0.0  0.5  22852  2600 ?Ss   09:24   0:01 /sbin/init auto
root 2  0.0  0.0  0 0 ?S09:24   0:00 [kthreadd]
root 3  0.2  0.0  0 0 ?S09:24   0:15 [ksoftirqd/0]
root 5  0.0  0.0  0 0 ?S<   09:24   0:00 [kworker/0:0H]
root 7  0.0  0.0  0 0 ?S<   09:24   0:00 [khelper]
root 8  0.0  0.0  0 0 ?S09:24   0:00 [kdevtmpfs]
root 9  0.0  0.0  0 0 ?S<   09:24   0:00 [perf]
root   107  0.0  0.0  0 0 ?S<   09:24   0:00 [writeback]
root   110  0.0  0.0  0 0 ?S<   09:24   0:00 [crypto]
root   111  0.0  0.0  0 0 ?S<   09:24   0:00 [bioset]
root   113  0.0  0.0  0 0 ?S<   09:24   0:00 [kblockd]
root   160  0.0  0.0  0 0 ?S<   09:24   0:00 [ata_sff]
root   162  0.3  0.0  0 0 ?S09:24   0:26 [kswapd0]
root   163  0.0  0.0  0 0 ?S09:24   0:00 [fsnotify_mark]
root   167  0.0  0.0  0 0 ?S<   09:24   0:00 [kthrotld]
root   420  0.1  0.0  0 0 ?S09:24   0:10 [kworker/u2:2]
root   421  0.0  0.0  0 0 ?S09:24   0:00 [scsi_eh_0]
root   438  0.0  0.0  0 0 ?S<   09:24   0:00 [scsi_tmf_0]
root   441  0.0  0.0  0 0 ?S09:24   0:00 [scsi_eh_1]
root   442  0.0  0.0  0 0 ?S<   09:24   0:00 [scsi_tmf_1]
root   468  0.0  0.0  0 0 ?S<   09:24   0:00 [deferwq]
root   482  0.0  0.0  0 0 ?S<   09:24   0:00 
[ext4-rsv-conver]
root   499  0.0  0.0  0 0 ?S<   09:24   0:00 [ipv6_addrconf]
root   536  0.0  0.4   7924  2164 ?Ss   09:24   0:03 
/usr/lib/systemd/systemd-journald
root   913  0.0  0.2  11120  1068 ?Ss   09:24   0:00 
/usr/lib/systemd/systemd-udevd
root   933  0.0  0.0  0 0 ?S<   09:24   0:00 [kpsmoused]
root   961  0.0  0.2   3140  1380 ?Ss   09:24   0:01 
/usr/lib/systemd/systemd-logind
dbus   967  0.0  0.2   4656  1472 ?Ss   09:24   0:00 
/usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile 
--systemd-activation
root   970  0.0  0.0  0 0 ?S<   09:24   0:00 
[acpi_thermal_pm]
root  1016  0.0  0.0  0 0 ?S<   09:24   0:00 [cfg80211]
root  1036  0.0  0.0  0 0 ?S<   09:24   0:00 [hd-audio0]
root  1037  0.0  0.2   7276  1176 ?Ss   09:24   0:00 /usr/bin/sshd 
-D
root  1074  0.0  0.0  0 0 ?S<   09:24   0:00 [kworker/u3:0]
root  1075  0.0  0.0  0 0 ?S<   09:24   0:00 [hci0]
root  1076  0.0  0.0  0 0 ?S<   09:24   0:00 [hci0]
root  1077  0.0  0.0  0 0 ?S<   09:24   0:00 [kworker/u3:1]
root  1116  0.0  0.0  0 0 ?S09:24   0:00 [scsi_eh_2]
root  1121  0.0  0.0  0 0 ?S<   09:24   0:00 [scsi_tmf_2]
root  1122  0.0  0.0  0 0 ?S09:24   0:00 [usb-storage]
root  1171  0.0  0.0  0 0 ?S<   09:24   0:00 [kworker/0:1H]
root  1220  0.0  0.2   5532  1164 ?Ss   09:25   0:00 
/usr/lib/bluetooth/bluetoothd
root  1235  0.6  0.4  43472  2200 ?Ssl  09:25   0:50 brltty -b al 
-d bluetooth:00:A0:96:31:E5:1E
root  1244  0.0  0.0  0 0 ?S<   09:25   0:00 [krfcommd]
root  1276  0.0  0.0  0 0 ?S09:25   0:00 [scsi_eh_3]
root  1278  0.0  0.0  0 0 ?S<   09:25   0:00 [scsi_tmf_3]
root  1279  0.2  0.0  0 0 ?S09:25   0:20 [usb-storage]
root  1300  0.0  0.2   5420  1140 ?Ss   09:26   0:00 login -- mrkiko
root  1302  0.0  0.2   5420  1144 ?Ss   09:26   0:00 login -- mrkiko
root  1304  0.0  0.2   5420  1140 ?Ss   09:26   0:00 login -- mrkiko
root  1312  0.0  0.2   5420  1144 ?Ss   09:26   0:00 login -- mrkiko
root  1314  0.0  0.2   5420  1144 ?Ss   09:26   0:00 login -- mrkiko
root  1316  0.0  0.2   5420  1140 ?Ss   09:26   0:00 login -- mrkiko
root  1318  0.0  0.2   5420  1140 ?Ss   09:26   0:00 login -- mrkiko
root  1319  0.0  0.2   5420  1144 ?Ss   09:26   0:00 login -- mrkiko
root  1326  0.0  0.2   5420  1144 ?Ss   09:26   0:00 login -- mrkiko
root  1332  0.0  0.2   5420  1140 ?Ss   09:26   0:00 login -- mrkiko
root  1334  0.0  0.2   5420  1140 ?Ss   09:26   0:00 login -- mrkiko
mrkiko1337  0.0  0.3   5520  1976 tty2 Ss   09:26   0:00 -bash
polkitd   1351  0.0  1.0  71816  5432 ?Ssl  09:26   0:00 
/usr/lib/polkit

Re: [PATCH v4] ehci-pci: disable for Intel MID platforms (update)

[Andy Shevchenko]

On Wed, 2015-02-04 at 08:04 +0800, Peter Chen wrote:
> On Tue, Feb 03, 2015 at 06:08:39PM +0200, Andy Shevchenko wrote:

> > + *
> > + * Note: ehci-pci driver may try to probe the device first. You have to 
> > add an
> > + * ID to the bypass_pci_id_table in ehci-pci driver to prevent this.
> >   */
> 
> This one is the same with your v3.

Correct.

> > -- 
> 
> I have no idea for this change.
> 
> If Greg has still not queued your pci patch, you can squash all your
> versions for pci and chipidea to one patch set, in this set, one patch
> for pci, and another for chipidea.

We discussed with him and agreed on one patch to update what was applied
to what is in v3.

-- 
Andy Shevchenko 
Intel Finland Oy

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

RE: [PATCH 2/2] usb: dwc2: gadget reuse ahbcfg assigned from platform

[Kaukab, Yousaf]

> -Original Message-
> From: Zhangfei Gao [mailto:zhangfei@linaro.org]
> Sent: Wednesday, February 4, 2015 9:01 AM
> To: Kaukab, Yousaf; ba...@ti.com; john.y...@synopsys.com
> Cc: linux-usb@vger.kernel.org; Zhangfei Gao
> Subject: [PATCH 2/2] usb: dwc2: gadget reuse ahbcfg assigned from platform
> 
> Gadget directly set GAHBCFG_HBSTLEN_INCR4, reuse ahbcfg if assigned from
> platform
> 
> Signed-off-by: Zhangfei Gao 
> ---
>  drivers/usb/dwc2/core.c   | 2 +-
>  drivers/usb/dwc2/gadget.c | 8 ++--
>  2 files changed, 7 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c index
> d5197d4..8d388cc 100644
> --- a/drivers/usb/dwc2/core.c
> +++ b/drivers/usb/dwc2/core.c
> @@ -2563,7 +2563,7 @@ void dwc2_set_param_reload_ctl(struct dwc2_hsotg
> *hsotg, int val)
> 
>  void dwc2_set_param_ahbcfg(struct dwc2_hsotg *hsotg, int val)  {
> - if (val != -1)
> + if (val)
>   hsotg->core_params->ahbcfg = val;
>   else
>   hsotg->core_params->ahbcfg =
> GAHBCFG_HBSTLEN_INCR4 << diff --git a/drivers/usb/dwc2/gadget.c
> b/drivers/usb/dwc2/gadget.c index 15aa578..20085de 100644
> --- a/drivers/usb/dwc2/gadget.c
> +++ b/drivers/usb/dwc2/gadget.c
> @@ -2314,9 +2314,13 @@ void s3c_hsotg_core_init_disconnected(struct
> dwc2_hsotg *hsotg,
>   GINTSTS_USBSUSP | GINTSTS_WKUPINT,
>   hsotg->regs + GINTMSK);
> 
> + if ((hsotg->core_params) && (hsotg->core_params->ahbcfg != -
> 1))
> + val = hsotg->core_params->ahbcfg &
> ~GAHBCFG_CTRL_MASK;
> + else
> + val = GAHBCFG_HBSTLEN_INCR4 <<
> GAHBCFG_HBSTLEN_SHIFT;
> +
>   if (using_dma(hsotg))
> - writel(GAHBCFG_GLBL_INTR_EN |
> GAHBCFG_DMA_EN |
> -(GAHBCFG_HBSTLEN_INCR4 <<
> GAHBCFG_HBSTLEN_SHIFT),
> + writel(GAHBCFG_GLBL_INTR_EN |
> GAHBCFG_DMA_EN | val,
>  hsotg->regs + GAHBCFG);
>   else
>   writel(((hsotg->dedicated_fifos) ?
> (GAHBCFG_NP_TXF_EMP_LVL |

There are other bits in GAHBCFG that can be set from platform. They will be 
preserved by your patch, as they are not part of GAHBCFG_CTRL_MASK, but only in 
case dma is enabled. Perhaps preserve them in non-dma case as well.

> --
> 1.9.1

BR,
Yousaf

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

Re: [PATCH v2 1/3] usb: XHCI: platform: Move the Marvell quirks after the enabling the clocks

[Maxime Ripard]

Hi Mathias, Greg,

On Mon, Jan 19, 2015 at 02:01:12PM +0100, Maxime Ripard wrote:
> The commit 973747928514 ("usb: host: xhci-plat: add support for the Armada
> 375/38x XHCI controllers") extended the xhci-plat driver to support the Armada
> 375/38x SoCs, mostly by adding a quirk configuring the MBUS window.
> 
> However, that quirk was run before the clock the controllers needs has been
> enabled. This usually worked because the clock was first enabled by the
> bootloader, and left as such until the driver is probe, where it tries to
> access the MBUS configuration registers before enabling the clock.
> 
> Things get messy when EPROBE_DEFER is involved during the probe, since as part
> of its error path, the driver will rightfully disable the clock. When the
> driver will be reprobed, it will retry to access the MBUS registers, but this
> time with the clock disabled, which hangs forever.
> 
> Fix this by running the quirks after the clock has been enabled by the driver.
> 
> Signed-off-by: Maxime Ripard 
> Cc:  # v3.16+

Any chance for this to go in 3.19?

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


signature.asc
Description: Digital signature

Re: [PATCH v2 1/3] usb: phy: generic: migrate to gpio_desc

[Linus Walleij]

On Wed, Jan 28, 2015 at 7:54 PM, Robert Jarzmik  wrote:
> Felipe Balbi  writes:
>
>>> nop->gpiod_reset = devm_gpiod_get_optional(dev, "reset");
>>> if (gpiod_is_active_low(nop->gpiod_reset))
>>> gpiod_direction_output(nop->gpiod_reset, GPIOD_OUT_LOW);
>>> else
>>> gpiod_direction_output(nop->gpiod_reset, GPIOD_OUT_HIGH);
>>
>> won't the descriptor itself handle that for us ? Linus ?
>>
>> I want to hear from Linus W first.
>
> Yes, so do I.
>
> Let's add a bit of context for Linus :
>  1) In the past, the driver was doing a ;
> gpio_request_one()
>   -> gpiod_direction_output_raw()
>  2) After the conversion to gpio descriptors, it is doing :
> gpiod_get_optional(dev, "reset");
>   -> ...
> -> __gpiod_get_index(dev, "reset", 0, 0)
>   -> this of course doesn't call gpiod_direction()

But wait.

__gpiod_get_index() does call gpiod_direction_output()
if any dir bits are set.

> The problem is that we cannot call:
>   gpiod_get_optional(dev, "reset", GPIOD_OUT_LOW);
> because we don't know before the call if the GPIO is active high or low.

The call __gpiod_get_index() first sets the inversion
flag if applicable and if you pass GPIOD_OUT_HIGH
it should set the raw value to 0 if it was inverted.

Else find the bug... is the GPIO line clearly marked
as inverted wherever it is described?

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

Re: [PATCH 1/3] usb: gadget: function: phonet: balance usb_ep_disable calls

[Pavel Machek]

On Tue 2015-02-03 13:18:59, Felipe Balbi wrote:
> On Tue, Feb 03, 2015 at 05:17:28PM +0100, Pali Rohár wrote:
> > On Tuesday 03 February 2015 16:43:45 Felipe Balbi wrote:
> > > Hi,
> > > 
> > > On Tue, Feb 03, 2015 at 04:31:51PM +0100, Pali Rohár wrote:
> > > > On Tuesday 03 February 2015 00:15:19 Felipe Balbi wrote:
> > > > > f_phonet's ->set_alt() method will call usb_ep_disable()
> > > > > potentially on an endpoint which is already disabled.
> > > > > That's something the gadget/function driver must
> > > > > guarantee that it's always balanced.
> > > > > 
> > > > > In order to balance the calls, just make sure the endpoint
> > > > > was enabled before by means of checking the validity of
> > > > > driver_data.
> > > > > 
> > > > > Reported-by: Pali Rohár 
> > > > > Signed-off-by: Felipe Balbi 
> > > > > ---
> > > > 
> > > > Your patches cause that kernel does not print any error
> > > > message to n900 screen anymore and reboot device in 10
> > > > seconds. I did not loaded any external modules.
> > > 
> > > > In qemu I see this crash in early boot:
> > > alright, so n900's working fine. I'll wait until you debug
> > > qemu a little more, thank you
> > 
> > NO! It does not working, see . It break n900 totally!
> 
> settle down a bit more. I don't have the HW you have and things are
> working fine on boards I _do_ have, there's not much more I can do to
> help without you doing your homework. Debug a bit more and bring more
> information as to what's going on, until then you're on your own.

I'm not sure what you are smoking, but Pali is doing more then enough
of his homework. No, it is not okay for you to break n900, and it is
not okay for you to break qemu.

In fact, you should do _your_ homework and install n900 qemu now. It
is not Pali's homework to debug your stuff for you.

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 1/3] usb: phy: generic: migrate to gpio_desc

[Linus Walleij]

On Wed, Jan 28, 2015 at 4:44 PM, Felipe Balbi  wrote:
> On Wed, Jan 28, 2015 at 01:40:59PM -0200, Fabio Estevam wrote:
>> On Wed, Jan 28, 2015 at 12:04 PM, Felipe Balbi  wrote:
>>
>> > I don't want to change direction all the time, some controllers might
>> > not be glitch free, but I agree that direction has to be set. It looks
>> > like we're missing a gpiod_direction_output() call from probe() so that
>> > this gpiod_set_value() works fine.
>>
>> We could do like that:
>>
>> nop->gpiod_reset = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_LOW);
>>
>> and it works.
>>
>> However, the initial value can't be set to 0 always as it depends if
>> the pin is active low or high.
>>
>> I tried to do like this:
>>
>> nop->gpiod_reset = devm_gpiod_get_optional(dev, "reset");
>> if (gpiod_is_active_low(nop->gpiod_reset))
>> gpiod_direction_output(nop->gpiod_reset, GPIOD_OUT_LOW);
>> else
>> gpiod_direction_output(nop->gpiod_reset, GPIOD_OUT_HIGH);
>
> won't the descriptor itself handle that for us ? Linus ?

The descriptor table contains polarity information like this:
Documentation/gpio/board.txt
(same GPIO_ACTIVE_LOW/HIGH can be passed for device tree and
I guess also ACPI)

So you should only need to drive the output high, and the core will
invert it if needed.

So in this case I'd go back and check where the GPIOs are described
and make sure it is properly indicated which polarity it has.

If you're anyway doing manual control like this, you have to use
gpiod_direction_output_raw() to avoid the inversion in the core.

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

Re: [PATCH 3/5] fs: remove ki_nbytes

[Al Viro]

[USB folks Cc'd]

On Mon, Feb 02, 2015 at 03:26:17PM +0100, Christoph Hellwig wrote:

> I would bet the behavior difference is a bug, might be worth to Cc the
> usb folks on this issue.  I bet we'd want the more complex behavior
> for both variants.

[Context for USB people: The difference in question is what ep_read() does
when it is called on write endpoint that isn't isochronous; it halts the
sucker and fails with EBADMSG, while ep_aio_read() handles all write endpoints
as isochronous ones - fails with EINVAL; FWIW, I agree that it's probably
a bug]

Sadly, that's not the only problem in there ;-/  _This_ one really has
the "what if single-segment AIO read tries to dereference iovec after
the caller is gone" bug you suspected in fs/direct-io.c; we have
static void ep_user_copy_worker(struct work_struct *work)
{
struct kiocb_priv *priv = container_of(work, struct kiocb_priv, work);
struct mm_struct *mm = priv->mm;
struct kiocb *iocb = priv->iocb;
size_t ret;

use_mm(mm); 
ret = ep_copy_to_user(priv);
unuse_mm(mm);

/* completing the iocb can drop the ctx and mm, don't touch mm after */
aio_complete(iocb, ret, ret);

kfree(priv->buf);
kfree(priv);
}
called via schedule_work() from ->complete() of usb_request allocated and
queued by ->aio_read().  It very definitely _can_ be executed after return
from ->aio_read() and aio_run_iocb().  And ep_copy_to_user() dereferences
the iovec given to ->aio_read(); _not_ its copy as f_fs.c does.

Do io_submit(2) with several IOCB_CMD_PREAD requests, and you'll almost
certainly get the data from the first one copied to the destination of
the second one instead.  It shouldn't be hard to reproduce.  And that,
of course, is not the worst possible outcome...

I'm going to add copying of iovec in async read case.  And AFAICS, that one
is -stable fodder.  See vfs.git#gadget for f_fs.c conversion; I haven't
pushed legacy/inode.c stuff yet - I need to pull the fix of the bug above
into the beginning of that pile first.

FWIW, I don't believe that it makes sense to do iovec copying in
aio_run_iocb(); note that most of the instances will be done with
iovec before they return there.  These two were the sole exceptions;
function/f_fs.c did copying, legacy/inode.c didn't.  Most of the
->aio_read/->read_iter instances (including ones that *do* return
EIOCBQUEUED) only access iovec synchronously; usually that's done
by grabbing the pages to copy into before we get aronud to starting
IO.  legacy/inode.c is the only instance to step into that kind of bug.
function/f_fs.c also had a fun bug, BTW - failure in AIO ended up leaking
io_data (plus iovec copy in case of aio_read()).  Looks like another
-stable fodder, if less serious one...  See b17d2ded6 (gadget/function/f_fs.c:
close leaks) in vfs.git#gadget for that one.

I plan to pull the fix for use-after-free in the beginning of that queue
(in an easy to backport form) and then have ep_aio_read/ep_aio_write
start doing the halt-related bits as in ep_read/ep_write.  With that it's
trivial to convert that sucker along the same lines as function/f_fs.c.

All of that, assuming that anybody gives a damn about the driver in question.
The things like
spin_lock_irq (&dev->lock);

// FIXME don't call this with the spinlock held ...
if (copy_to_user (buf, dev->req->buf, len))
seem to indicate that nobody does, seeing that this bug had been there
since 2003, complete with FIXME ;-/

If nobody cares about that sucker, git rm would be a better solution, IMO...
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: intensive IO on usb-storage device causing system lock

[Enrico Mioso]

Hello guys!
I was lucky! :)
I was able to reproduce the crash in less time.

So - a big blob of infos about my system: complete dmesg, lspci, lsusb, kernel 
config and so on is at
http://www.gstorm.eu/info

The trace is:
http://cxg.de/_59153c.htm
I wasn't able to get other infos, the system wasn't able to read anything more from the 
internal flash memory; even the "tty" command wasn't returning.
thank you for the help.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] usb: phy: load usb phy earlier

[zhangfei]

On 02/04/2015 04:16 PM, Peter Chen wrote:

On Wed, Feb 4, 2015 at 4:01 PM, Zhangfei Gao  wrote:

Since phy is definitely used usb controller, load the phy
earlier rather than using defer probe to make boot time shorter.

Signed-off-by: Zhangfei Gao 
---
  drivers/usb/Makefile | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/Makefile b/drivers/usb/Makefile
index 2f1e2aa..d8926c6 100644
--- a/drivers/usb/Makefile
+++ b/drivers/usb/Makefile
@@ -5,6 +5,7 @@
  # Object files in subdirectories

  obj-$(CONFIG_USB)  += core/
+obj-$(CONFIG_USB_SUPPORT)  += phy/

  obj-$(CONFIG_USB_DWC3) += dwc3/
  obj-$(CONFIG_USB_DWC2) += dwc2/
@@ -48,7 +49,6 @@ obj-$(CONFIG_USB_MICROTEK)+= image/
  obj-$(CONFIG_USB_SERIAL)   += serial/

  obj-$(CONFIG_USB)  += misc/
-obj-$(CONFIG_USB_SUPPORT)  += phy/
  obj-$(CONFIG_EARLY_PRINTK_DBGP)+= early/

  obj-$(CONFIG_USB_ATM)  += atm/
--


The similar patch posted before, you may use probe deferral in your controller
driver if the PHY is not ready, besides, both controller and phy
driver may be built
as modules.


Yes, probe deferral is still used in the controller.
For example, dwc2 every time use defer probe to wait phy probe complete.

However since they are in the same folder, and we already know the 
sequence, is it better to change the sequence to make it quicker.


Thanks

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

Re: [PATCH 1/2] usb: phy: load usb phy earlier

[Peter Chen]

On Wed, Feb 4, 2015 at 4:01 PM, Zhangfei Gao  wrote:
> Since phy is definitely used usb controller, load the phy
> earlier rather than using defer probe to make boot time shorter.
>
> Signed-off-by: Zhangfei Gao 
> ---
>  drivers/usb/Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/usb/Makefile b/drivers/usb/Makefile
> index 2f1e2aa..d8926c6 100644
> --- a/drivers/usb/Makefile
> +++ b/drivers/usb/Makefile
> @@ -5,6 +5,7 @@
>  # Object files in subdirectories
>
>  obj-$(CONFIG_USB)  += core/
> +obj-$(CONFIG_USB_SUPPORT)  += phy/
>
>  obj-$(CONFIG_USB_DWC3) += dwc3/
>  obj-$(CONFIG_USB_DWC2) += dwc2/
> @@ -48,7 +49,6 @@ obj-$(CONFIG_USB_MICROTEK)+= image/
>  obj-$(CONFIG_USB_SERIAL)   += serial/
>
>  obj-$(CONFIG_USB)  += misc/
> -obj-$(CONFIG_USB_SUPPORT)  += phy/
>  obj-$(CONFIG_EARLY_PRINTK_DBGP)+= early/
>
>  obj-$(CONFIG_USB_ATM)  += atm/
> --

The similar patch posted before, you may use probe deferral in your controller
driver if the PHY is not ready, besides, both controller and phy
driver may be built
as modules.

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

[PATCH 2/2] usb: dwc2: gadget reuse ahbcfg assigned from platform

[Zhangfei Gao]

Gadget directly set GAHBCFG_HBSTLEN_INCR4, reuse ahbcfg if assigned from 
platform

Signed-off-by: Zhangfei Gao 
---
 drivers/usb/dwc2/core.c   | 2 +-
 drivers/usb/dwc2/gadget.c | 8 ++--
 2 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c
index d5197d4..8d388cc 100644
--- a/drivers/usb/dwc2/core.c
+++ b/drivers/usb/dwc2/core.c
@@ -2563,7 +2563,7 @@ void dwc2_set_param_reload_ctl(struct dwc2_hsotg *hsotg, 
int val)
 
 void dwc2_set_param_ahbcfg(struct dwc2_hsotg *hsotg, int val)
 {
-   if (val != -1)
+   if (val)
hsotg->core_params->ahbcfg = val;
else
hsotg->core_params->ahbcfg = GAHBCFG_HBSTLEN_INCR4 <<
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index 15aa578..20085de 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -2314,9 +2314,13 @@ void s3c_hsotg_core_init_disconnected(struct dwc2_hsotg 
*hsotg,
GINTSTS_USBSUSP | GINTSTS_WKUPINT,
hsotg->regs + GINTMSK);
 
+   if ((hsotg->core_params) && (hsotg->core_params->ahbcfg != -1))
+   val = hsotg->core_params->ahbcfg & ~GAHBCFG_CTRL_MASK;
+   else
+   val = GAHBCFG_HBSTLEN_INCR4 << GAHBCFG_HBSTLEN_SHIFT;
+
if (using_dma(hsotg))
-   writel(GAHBCFG_GLBL_INTR_EN | GAHBCFG_DMA_EN |
-  (GAHBCFG_HBSTLEN_INCR4 << GAHBCFG_HBSTLEN_SHIFT),
+   writel(GAHBCFG_GLBL_INTR_EN | GAHBCFG_DMA_EN | val,
   hsotg->regs + GAHBCFG);
else
writel(((hsotg->dedicated_fifos) ? (GAHBCFG_NP_TXF_EMP_LVL |
-- 
1.9.1

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

[PATCH 0/2] misc change

[Zhangfei Gao]

two misc changes, no function impact

Zhangfei Gao (2):
  usb: phy: load usb phy earlier
  usb: dwc2: gadget reuse ahbcfg assigned from platform

 drivers/usb/Makefile  | 2 +-
 drivers/usb/dwc2/core.c   | 2 +-
 drivers/usb/dwc2/gadget.c | 8 ++--
 3 files changed, 8 insertions(+), 4 deletions(-)

-- 
1.9.1

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

[PATCH 1/2] usb: phy: load usb phy earlier

[Zhangfei Gao]

Since phy is definitely used usb controller, load the phy
earlier rather than using defer probe to make boot time shorter.

Signed-off-by: Zhangfei Gao 
---
 drivers/usb/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/Makefile b/drivers/usb/Makefile
index 2f1e2aa..d8926c6 100644
--- a/drivers/usb/Makefile
+++ b/drivers/usb/Makefile
@@ -5,6 +5,7 @@
 # Object files in subdirectories
 
 obj-$(CONFIG_USB)  += core/
+obj-$(CONFIG_USB_SUPPORT)  += phy/
 
 obj-$(CONFIG_USB_DWC3) += dwc3/
 obj-$(CONFIG_USB_DWC2) += dwc2/
@@ -48,7 +49,6 @@ obj-$(CONFIG_USB_MICROTEK)+= image/
 obj-$(CONFIG_USB_SERIAL)   += serial/
 
 obj-$(CONFIG_USB)  += misc/
-obj-$(CONFIG_USB_SUPPORT)  += phy/
 obj-$(CONFIG_EARLY_PRINTK_DBGP)+= early/
 
 obj-$(CONFIG_USB_ATM)  += atm/
-- 
1.9.1

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