Re: [PATCH v2] usb: dwc2: Remove unnecessary debug prints

[Razmik Karapetyan]

On 12/7/2017 11:18 PM, Joe Perches wrote:
> On Thu, 2017-12-07 at 11:17 -0800, Joe Perches wrote:
>> On Wed, 2017-12-06 at 17:57 +0400, Razmik Karapetyan wrote:
>>> Removed unnecessary debug prints about DMA mode for host side
>>> from dwc2_gahbcfg_init() function.
>>
>> What other functionality makes these unnecessary?
>> If any, it's nice to de
> 
> ... describe it in the changelog.
> 

Hi Joe,

No any other functionality makes them unnecessary.

In the driver we have debug info about DMA type only for host side, so 
operating in device mode DMA type can be different and those debug 
prints ("Using Buffer\Descriptor DMA mode\n") can cause confusions.

We can add debug prints for device mode also, but it is preferable to 
have less debug info in the log.

Thanks,
Razmik
--
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: hub: Delete an error message for a failed memory allocation in usb_hub_clear_tt_buffer()

[Geert Uytterhoeven]

Hi Alan,

On Thu, Dec 7, 2017 at 10:26 PM, Alan Stern  wrote:
> On Thu, 7 Dec 2017, Dan Carpenter wrote:
>> The standard is to treat them like errors and try press forward in a
>> degraded mode but don't print a message.  Checkpatch.pl complains if you
>> print a warning for allocation failures.  A lot of low level functions
>> handle their own messages pretty well but especially kmalloc() does.
>
> Which brings us back to my original objection.  If an allocation
> failure has localized effects, but the low-level warning is unable to
> specify what will be affected, how is the user supposed to connect the
> effect to the cause?

The backtrace would include usb_hub_clear_tt_buffer, so the user will
know USB is affected.
Note that the cause of the memory exhaustion is usually not the caller.
Unless it requests a real big block of memory, in which case that will be
mentioned in the backtrace, too.

In this particular case, the driver uses GFP_ATOMIC, so allocation failures
aren't that rare, and I think the driver should be prepared for that, and try
to recover gracefully.

The comment

/* FIXME recover somehow ... RESET_TT? */

makes me think it isn't.

As this is a pretty small allocation, perhaps it can be done beforehand, without
GFP_ATOMIC?

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
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 0/4] USB over IP Secuurity fixes

[Greg KH]

On Thu, Dec 07, 2017 at 02:16:46PM -0700, Shuah Khan wrote:
> Jakub Jirasek from Secunia Research at Flexera reported security
> vulnerabilities in the USB over IP driver. This patch series all
> the 4 reported problems.

Nice!

These should also all go to the stable kernels, right?

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 72/73] xfs: Convert mru cache to XArray

[Dave Chinner]

On Fri, Dec 08, 2017 at 01:45:52PM +0900, Byungchul Park wrote:
> On Fri, Dec 08, 2017 at 09:22:16AM +1100, Dave Chinner wrote:
> > On Thu, Dec 07, 2017 at 11:06:34AM -0500, Theodore Ts'o wrote:
> > > On Wed, Dec 06, 2017 at 06:06:48AM -0800, Matthew Wilcox wrote:
> > > > > Unfortunately for you, I don't find arguments along the lines of
> > > > > "lockdep will save us" at all convincing.  lockdep already throws
> > > > > too many false positives to be useful as a tool that reliably and
> > > > > accurately points out rare, exciting, complex, intricate locking
> > > > > problems.
> > > > 
> > > > But it does reliably and accurately point out "dude, you forgot to take
> > > > the lock".  It's caught a number of real problems in my own testing that
> > > > you never got to see.
> > > 
> > > The problem is that if it has too many false positives --- and it's
> > > gotten *way* worse with the completion callback "feature", people will
> > > just stop using Lockdep as being too annyoing and a waste of developer
> > > time when trying to figure what is a legitimate locking bug versus
> > > lockdep getting confused.
> > > 
> > > I can't even disable the new Lockdep feature which is throwing
> > > lots of new false positives --- it's just all or nothing.
> > > 
> > > Dave has just said he's already stopped using Lockdep, as a result.
> > 
> > This is compeltely OT, but FYI I stopped using lockdep a long time
> > ago.  We've spend orders of magnitude more time and effort to shut
> > up lockdep false positives in the XFS code than we ever have on
> > locking problems that lockdep has uncovered. And still lockdep
> > throws too many false positives on XFS workloads to be useful to me.
> > 
> > But it's more than that: I understand just how much lockdep *doesn't
> > check* and that means *I know I can't rely on lockdep* for potential
> > deadlock detection. e.g.  it doesn't cover semaphores, which means
> 
> Hello,
> 
> I'm careful in saying the following since you seem to feel not good at
> crossrelease and even lockdep. Now that cross-release has been
> introduced, semaphores can be covered as you might know. Actually, all
> general waiters can.

And all it will do is create a whole bunch more work for us XFS guys
to shut up all the the false positive crap that falls out from it
because the locking model we have is far more complex than any of
the lockdep developers thought was necessary to support, just like
happened with the XFS inode annotations all those years ago.

e.g. nobody has ever bothered to ask us what is needed to describe
XFS's semaphore locking model.  If you did that, you'd know that we
nest *thousands* of locked semaphores in compeltely random lock
order during metadata buffer writeback. And that this lock order
does not reflect the actual locking order rules we have for locking
buffers during transactions.

Oh, and you'd also know that a semaphore's lock order and context
can change multiple times during the life time of the buffer.  Say
we free a block and the reallocate it as something else before it is
reclaimed - that buffer now might have a different lock order. Or
maybe we promote a buffer to be a root btree block as a result of a
join - it's now the first buffer in a lock run, rather than a child.
Or we split a tree, and the root is now a node and so no longer is
the first buffer in a lock run. Or that we walk sideways along the
leaf nodes siblings during searches.  IOWs, there is no well defined
static lock ordering at all for buffers - and therefore semaphores -
in XFS at all.

And knowing that, you wouldn't simply mention that lockdep can
support semaphores now as though that is necessary to "make it work"
for XFS.  It's going to be much simpler for us to just turn off
lockdep and ignore whatever crap it sends our way than it is to
spend unplanned weeks of our time to try to make lockdep sorta work
again. Sure, we might get there in the end, but it's likely to take
months, if not years like it did with the XFS inode annotations.

> > it has zero coverage of the entire XFS metadata buffer subsystem and
> > the complex locking orders we have for metadata updates.
> > 
> > Put simply: lockdep doesn't provide me with any benefit, so I don't
> > use it...
> 
> Sad..

I don't think you understand. I'll try to explain.

The lockdep infrastructure by itself doesn't make lockdep a useful
tool - it mostly generates false positives because it has no
concept of locking models that don't match it's internal tracking
assumptions and/or limitations.

That means if we can't suppress the false positives, then lockdep is
going to be too noisy to find real problems.  It's taken the XFS
developers months of work over the past 7-8 years to suppress all
the *common* false positives that lockdep throws on XFS. And despite
all that work, there's still too many false positives occuring
because we can't easily suppress them with annotations. IOWs, the
signal to noise ratio is still too low for lockdep to find 

Re: [PATCH v4 72/73] xfs: Convert mru cache to XArray

[Byungchul Park]

On Fri, Dec 08, 2017 at 09:22:16AM +1100, Dave Chinner wrote:
> On Thu, Dec 07, 2017 at 11:06:34AM -0500, Theodore Ts'o wrote:
> > On Wed, Dec 06, 2017 at 06:06:48AM -0800, Matthew Wilcox wrote:
> > > > Unfortunately for you, I don't find arguments along the lines of
> > > > "lockdep will save us" at all convincing.  lockdep already throws
> > > > too many false positives to be useful as a tool that reliably and
> > > > accurately points out rare, exciting, complex, intricate locking
> > > > problems.
> > > 
> > > But it does reliably and accurately point out "dude, you forgot to take
> > > the lock".  It's caught a number of real problems in my own testing that
> > > you never got to see.
> > 
> > The problem is that if it has too many false positives --- and it's
> > gotten *way* worse with the completion callback "feature", people will
> > just stop using Lockdep as being too annyoing and a waste of developer
> > time when trying to figure what is a legitimate locking bug versus
> > lockdep getting confused.
> > 
> > I can't even disable the new Lockdep feature which is throwing
> > lots of new false positives --- it's just all or nothing.
> > 
> > Dave has just said he's already stopped using Lockdep, as a result.
> 
> This is compeltely OT, but FYI I stopped using lockdep a long time
> ago.  We've spend orders of magnitude more time and effort to shut
> up lockdep false positives in the XFS code than we ever have on
> locking problems that lockdep has uncovered. And still lockdep
> throws too many false positives on XFS workloads to be useful to me.
> 
> But it's more than that: I understand just how much lockdep *doesn't
> check* and that means *I know I can't rely on lockdep* for potential
> deadlock detection. e.g.  it doesn't cover semaphores, which means

Hello,

I'm careful in saying the following since you seem to feel not good at
crossrelease and even lockdep. Now that cross-release has been
introduced, semaphores can be covered as you might know. Actually, all
general waiters can.

> it has zero coverage of the entire XFS metadata buffer subsystem and
> the complex locking orders we have for metadata updates.
> 
> Put simply: lockdep doesn't provide me with any benefit, so I don't
> use it...

Sad..

> Cheers,
> 
> Dave.
> -- 
> Dave Chinner
> da...@fromorbit.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 4.4 13/49] usb: dwc2: Fix UDC state tracking

[Ben Hutchings]

On Thu, 2017-12-07 at 14:07 +0100, Greg Kroah-Hartman wrote:
> 4.4-stable review patch.  If anyone has any objections, please let me
> know.
> 
> --
> 
> From: John Stultz 
> 
> 
> [ Upstream commit ce2b21a4e5ce042c0a42c9db8fa9e0f849427d5e ]
> 
> It has been noticed that the dwc2 udc state reporting doesn't
> seem to work (at least on HiKey boards). Where after the initial
> setup, the sysfs /sys/class/udc/f72c.usb/state file would
> report "configured" no matter the state of the OTG port.
> 
> This patch adds a call so that we report to the UDC layer when
> the gadget device is disconnected.
> 
> This patch does depend on the previous patch ("usb: dwc2:
> Improve gadget state disconnection handling") in this patch set
> in order to properly work.

Then you should add that (commit d2471d4a24df).

Ben.

> Cc: Wei Xu 
> Cc: Guodong Xu 
> Cc: Amit Pundir 
> Cc: YongQin Liu 
> Cc: John Youn 
> Cc: Minas Harutyunyan 
> Cc: Douglas Anderson 
> Cc: Chen Yu 
> Cc: Felipe Balbi 
> Cc: Greg Kroah-Hartman 
> Cc: linux-usb@vger.kernel.org
> Acked-by: Minas Harutyunyan 
> Tested-by: Minas Harutyunyan 
> Reported-by: Amit Pundir 
> Signed-off-by: John Stultz 
> Signed-off-by: Felipe Balbi 
> Signed-off-by: Sasha Levin 
> Signed-off-by: Greg Kroah-Hartman 
> ---
>  drivers/usb/dwc2/gadget.c |2 ++
>  1 file changed, 2 insertions(+)
> 
> --- a/drivers/usb/dwc2/gadget.c
> +++ b/drivers/usb/dwc2/gadget.c
> @@ -2206,6 +2206,8 @@ void dwc2_hsotg_disconnect(struct dwc2_h
>  
>   call_gadget(hsotg, disconnect);
>   hsotg->lx_state = DWC2_L3;
> +
> + usb_gadget_set_state(>gadget, USB_STATE_NOTATTACHED);
>  }
>  
>  /**
> 
> 
> 
-- 
Ben Hutchings
Software Developer, Codethink Ltd.

--
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: Lockdep is less useful than it was

[Dave Chinner]

On Thu, Dec 07, 2017 at 02:38:03PM -0800, Matthew Wilcox wrote:
> On Thu, Dec 07, 2017 at 11:06:34AM -0500, Theodore Ts'o wrote:
> > The problem is that if it has too many false positives --- and it's
> > gotten *way* worse with the completion callback "feature", people will
> > just stop using Lockdep as being too annyoing and a waste of developer
> > time when trying to figure what is a legitimate locking bug versus
> > lockdep getting confused.
> > 
> > I can't even disable the new Lockdep feature which is throwing
> > lots of new false positives --- it's just all or nothing.
> 
> You *can* ... but it's way more hacking Kconfig than you ought to have
> to do (which is a separate rant ...)
> 
> You need to get LOCKDEP_CROSSRELEASE off.  I'd revert patches
> e26f34a407aec9c65bce2bc0c838fabe4f051fc6 and
> b483cf3bc249d7af706390efa63d6671e80d1c09
> 
> I think it was a mistake to force these on for everybody; they have a
> much higher false-positive rate than the rest of lockdep, so as you say
> forcing them on leads to fewer people using *any* of lockdep.
> 
> The bug you're hitting isn't Byungchul's fault; it's an annotation
> problem.  The same kind of annotation problem that we used to have with
> dozens of other places in the kernel which are now fixed.

That's one of the fundamental problem with lockdep - it throws the
difficulty of solving all these new false positives onto the
developers who know nothing about lockdep and don't follow it's
development. And until they do solve them - especially in critical
subsystems that everyone uses like the storage stack - lockdep is
essentially worthless.

> If you didn't
> have to hack Kconfig to get rid of this problem, you'd be happier, right?

I'd be much happier if it wasn't turned on by default in the first
place.  We gave plenty of warnings that there were still unsolved
false positive problems with the new checks in the storage stack.

Cheers,

Dave.
-- 
Dave Chinner
da...@fromorbit.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: RFC: FT232H based FPGA configuration adapter drivers

[Anatolij Gustschin]

On Thu, 7 Dec 2017 14:24:57 -0600
Alan Tull at...@kernel.org wrote:
...
>> Instead of MFD part as in previous version I intend to add an USB misc
>> driver for our FPGA configuration adapters under drivers/usb/misc.
>> When probing for VID/PID assigned to FIFO-FPP adapter type, this
>> driver will register CBUS GPIO controller, GPIO lookup tables for  
>
> I'm not clear how these lookup tables will be specified.  Is this
>platform using device tree?

No, this is x86 platform, not using device tree. Therefore we have
to specify device GPIOs for each dynamically added platform device,
e.g. like:

lookup->dev_id = devm_kstrdup(dev, dev_name(dev), GFP_KERNEL);
lookup->table[0].chip_hwnum = N; /* pin offset on this GPIO chip */
lookup->table[0].chip_label = priv->gpiochip->label;
lookup->table[0].con_id = "nconfig";
lookup->table[0].flags = GPIO_ACTIVE_LOW;

lookup->table[1].chip_hwnum = M;
lookup->table[1].chip_label = priv->gpiochip->label;
lookup->table[1].con_id = "conf_done";
lookup->table[1].flags = GPIO_ACTIVE_HIGH;

Then, gpiod_get(dev, "nconfig", GPIOD_OUT_HIGH) in platform driver will
find the appropriate GPIO descriptor.

...
>> Below simplified diagram shows the intended device and drivers
>> relationship for reworking the adapter drivers.
>>
>>+-+
>>| |
>>|  STRATIX V  |PS-SPI FT245 FIFO & GPIO
>>| +-++---+
>>|  on Board 1 | ++   |
>>| | ++---+
>>|  PCIe   |   ADBUS   |  CPLD  |
>>+---+-+ Connection Options  ++---+
>>^  (MPSSE or FIFO)  |
>>+  +  +--+---+
>>   altera-cvp  +---+--+   | FPP  |
>>   |FT232H|   |  |
>>   | 0x0403:0x7148|   |   ARRIA 10   |
>>   | 0x0403:0x7149|   |  |
>>   +--+---+   |  on Board 2  |
>>  |   |  |
>>  +---++  |PCIe  |
>> USB misc | fpga-cfg-intf USB misc |  +--+---+
>>   drv creates| bulk/ctrl xfer | ^
>> platform |ACBUS GPIO Ctrl (0x7148)| |
>>  devices |MPSSE GPIO Ctrl (0x7149)| |
>>   below  +---+---++ |
>>  |   |  |
>> for ++   +--+for|
>>  PID 0x7149 |   | PID 0x7148|
>>   +-++  +---+-+ |
>>   | ftdi-mpsse-spi + |  | | |
>>   | altera-ps-spi in |  |ftdi-fifo-fpp-mgr| |
>>   |  spi_board_info  |  | platform device | |
>>   +-++  +++ |
>> ^^  |
>>   drivers:  ||  |
>> +|  |
>>  MPSSE SPI master|  |
>> ^|  |
>> |+  +
>>   altera-ps-spiftdi-fifo-fppaltera-cvp
>>FPGA Manager FPGA Manager   FPGA Manager
>> ^^  ^
>> ||  |
>> +---+++-+
>>   fpga-mgr
>>  
>
>Just to be clear, this is several solutions that are being
>superimposed in one diagram, depending on which platform you are on,
>right?

Correct, we either have USB -> MPSSE -> PS-SPI -> Stratix V path on
one board, or USB -> FIFO-FPP -> CPLD -> Arria 10 path on another
board.

Anatolij
--
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: Lockdep is less useful than it was

[Matthew Wilcox]

On Thu, Dec 07, 2017 at 02:38:03PM -0800, Matthew Wilcox wrote:
> You need to get LOCKDEP_CROSSRELEASE off.  I'd revert patches
> e26f34a407aec9c65bce2bc0c838fabe4f051fc6 and
> b483cf3bc249d7af706390efa63d6671e80d1c09

Oops.  I meant to revert 2dcd5adfb7401b762ddbe4b86dcacc2f3de6b97b.
Or you could cherry-pick b483cf3bc249d7af706390efa63d6671e80d1c09.
--
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

Lockdep is less useful than it was

[Matthew Wilcox]

On Thu, Dec 07, 2017 at 11:06:34AM -0500, Theodore Ts'o wrote:
> The problem is that if it has too many false positives --- and it's
> gotten *way* worse with the completion callback "feature", people will
> just stop using Lockdep as being too annyoing and a waste of developer
> time when trying to figure what is a legitimate locking bug versus
> lockdep getting confused.
> 
> I can't even disable the new Lockdep feature which is throwing
> lots of new false positives --- it's just all or nothing.

You *can* ... but it's way more hacking Kconfig than you ought to have
to do (which is a separate rant ...)

You need to get LOCKDEP_CROSSRELEASE off.  I'd revert patches
e26f34a407aec9c65bce2bc0c838fabe4f051fc6 and
b483cf3bc249d7af706390efa63d6671e80d1c09

I think it was a mistake to force these on for everybody; they have a
much higher false-positive rate than the rest of lockdep, so as you say
forcing them on leads to fewer people using *any* of lockdep.

The bug you're hitting isn't Byungchul's fault; it's an annotation
problem.  The same kind of annotation problem that we used to have with
dozens of other places in the kernel which are now fixed.  If you didn't
have to hack Kconfig to get rid of this problem, you'd be happier, right?
--
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 72/73] xfs: Convert mru cache to XArray

[Dave Chinner]

On Thu, Dec 07, 2017 at 11:06:34AM -0500, Theodore Ts'o wrote:
> On Wed, Dec 06, 2017 at 06:06:48AM -0800, Matthew Wilcox wrote:
> > > Unfortunately for you, I don't find arguments along the lines of
> > > "lockdep will save us" at all convincing.  lockdep already throws
> > > too many false positives to be useful as a tool that reliably and
> > > accurately points out rare, exciting, complex, intricate locking
> > > problems.
> > 
> > But it does reliably and accurately point out "dude, you forgot to take
> > the lock".  It's caught a number of real problems in my own testing that
> > you never got to see.
> 
> The problem is that if it has too many false positives --- and it's
> gotten *way* worse with the completion callback "feature", people will
> just stop using Lockdep as being too annyoing and a waste of developer
> time when trying to figure what is a legitimate locking bug versus
> lockdep getting confused.
> 
> I can't even disable the new Lockdep feature which is throwing
> lots of new false positives --- it's just all or nothing.
> 
> Dave has just said he's already stopped using Lockdep, as a result.

This is compeltely OT, but FYI I stopped using lockdep a long time
ago.  We've spend orders of magnitude more time and effort to shut
up lockdep false positives in the XFS code than we ever have on
locking problems that lockdep has uncovered. And still lockdep
throws too many false positives on XFS workloads to be useful to me.

But it's more than that: I understand just how much lockdep *doesn't
check* and that means *I know I can't rely on lockdep* for potential
deadlock detection. e.g.  it doesn't cover semaphores, which means
it has zero coverage of the entire XFS metadata buffer subsystem and
the complex locking orders we have for metadata updates.

Put simply: lockdep doesn't provide me with any benefit, so I don't
use it...

Cheers,

Dave.
-- 
Dave Chinner
da...@fromorbit.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: USB: hub: Delete an error message for a failed memory allocation in usb_hub_clear_tt_buffer()

[Alan Stern]

On Thu, 7 Dec 2017, Dan Carpenter wrote:

> On Thu, Dec 07, 2017 at 10:12:27AM -0500, Alan Stern wrote:
> > The real problem is that the kernel development community doesn't have
> > a fixed policy on how to handle memory allocation errors.  There are
> > several possibilities:
> > 
> > Ignore them on the grounds that they will never happen.
> > (Really?  And what is the size limit above which they
> > might happen?)
> > 
> 
> It's pretty rare to ignore allocation failures these days.  It causes
> static checker warnings.
> 
> Sometimes it's accepted for people to ignore errors during boot but
> I hate that because how am I supposed to filter out those static checker
> warnings?  It's better to pretend that the kernel will still boot
> without essential hardware instead of wasting everyone's time who looks
> at checker output.
> 
> > Ignore them on the grounds that the machine will hang or
> > crash in the near future.  (Is this guaranteed?)
> 
> On boot sometimes yes.
> 
> > 
> > Treat them like other errors: try to press forward (perhaps
> > in a degraded mode).
> > 
> > Treat them like other errors: log an error message and try
> > to press forward.
> > 
> 
> The standard is to treat them like errors and try press forward in a
> degraded mode but don't print a message.  Checkpatch.pl complains if you
> print a warning for allocation failures.  A lot of low level functions
> handle their own messages pretty well but especially kmalloc() does.

Which brings us back to my original objection.  If an allocation 
failure has localized effects, but the low-level warning is unable to 
specify what will be affected, how is the user supposed to connect the 
effect to the cause?

Alan Stern

> 
> I also have a special static checker warning for when people do:
> 
>   foo = alloc();
>   BUG_ON(!foo);
> 
> People do that occasionally but fortunately it's pretty rare.  10 years
> ago that's how btrfs did error handling, but now there are only 4 of
> these still remaining in btrfs.
> 
> regards,
> dan carpenter
> 
> 
> 

--
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/4] usbip: fix stub_rx: get_pipe() to validate endpoint number

[Shuah Khan]

get_pipe() routine doesn't validate the input endpoint number
and uses to reference ep_in and ep_out arrays. Invalid endpoint
number can trigger BUG(). Range check the epnum and returning
error instead of calling BUG().

Change caller stub_recv_cmd_submit() to handle the get_pipe()
error return.

Signed-off-by: Shuah Khan 
---
 drivers/usb/usbip/stub_rx.c | 18 +++---
 1 file changed, 11 insertions(+), 7 deletions(-)

diff --git a/drivers/usb/usbip/stub_rx.c b/drivers/usb/usbip/stub_rx.c
index 536e037f541f..4d61063c259d 100644
--- a/drivers/usb/usbip/stub_rx.c
+++ b/drivers/usb/usbip/stub_rx.c
@@ -328,15 +328,15 @@ static int get_pipe(struct stub_device *sdev, int epnum, 
int dir)
struct usb_host_endpoint *ep;
struct usb_endpoint_descriptor *epd = NULL;
 
+   if (epnum < 0 || epnum > 15)
+   goto err_ret;
+
if (dir == USBIP_DIR_IN)
ep = udev->ep_in[epnum & 0x7f];
else
ep = udev->ep_out[epnum & 0x7f];
-   if (!ep) {
-   dev_err(>udev->dev, "no such endpoint?, %d\n",
-   epnum);
-   BUG();
-   }
+   if (!ep)
+   goto err_ret;
 
epd = >desc;
if (usb_endpoint_xfer_control(epd)) {
@@ -367,9 +367,10 @@ static int get_pipe(struct stub_device *sdev, int epnum, 
int dir)
return usb_rcvisocpipe(udev, epnum);
}
 
+err_ret:
/* NOT REACHED */
-   dev_err(>udev->dev, "get pipe, epnum %d\n", epnum);
-   return 0;
+   dev_err(>udev->dev, "get pipe() invalid epnum %d\n", epnum);
+   return -1;
 }
 
 static void masking_bogus_flags(struct urb *urb)
@@ -435,6 +436,9 @@ static void stub_recv_cmd_submit(struct stub_device *sdev,
struct usb_device *udev = sdev->udev;
int pipe = get_pipe(sdev, pdu->base.ep, pdu->base.direction);
 
+   if (pipe == -1)
+   return;
+
priv = stub_priv_alloc(sdev, pdu);
if (!priv)
return;
-- 
2.14.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/4] USB over IP Secuurity fixes

[Shuah Khan]

Jakub Jirasek from Secunia Research at Flexera reported security
vulnerabilities in the USB over IP driver. This patch series all
the 4 reported problems.

Jakub, could you please suggest an email address I can use for the
Reported-by tag?

Shuah Khan (4):
  usbip: fix stub_rx: get_pipe() to validate endpoint number
  usbip: fix stub_rx: harden CMD_SUBMIT path to handle malicious input
  usbip: prevent vhci_hcd driver from leaking a socket pointer address
  usbip: fix stub_send_ret_submit() vulnerability to null
transfer_buffer

 drivers/usb/usbip/stub_rx.c  | 51 +---
 drivers/usb/usbip/stub_tx.c  |  7 +
 drivers/usb/usbip/usbip_common.h |  1 +
 drivers/usb/usbip/vhci_sysfs.c   | 25 +++---
 tools/usb/usbip/libsrc/vhci_driver.c |  8 +++---
 5 files changed, 69 insertions(+), 23 deletions(-)

-- 
2.14.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 2/4] usbip: fix stub_rx: harden CMD_SUBMIT path to handle malicious input

[Shuah Khan]

Harden CMD_SUBMIT path to handle malicious input that could trigger
large memory allocations. Add checks to validate transfer_buffer_length
and number_of_packets to protect against bad input requesting for
unbounded memory allocations. Validate early in get_pipe() and return
failure.

Signed-off-by: Shuah Khan 
---
 drivers/usb/usbip/stub_rx.c | 35 +++
 1 file changed, 31 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/usbip/stub_rx.c b/drivers/usb/usbip/stub_rx.c
index 4d61063c259d..493ac2928391 100644
--- a/drivers/usb/usbip/stub_rx.c
+++ b/drivers/usb/usbip/stub_rx.c
@@ -322,11 +322,13 @@ static struct stub_priv *stub_priv_alloc(struct 
stub_device *sdev,
return priv;
 }
 
-static int get_pipe(struct stub_device *sdev, int epnum, int dir)
+static int get_pipe(struct stub_device *sdev, struct usbip_header *pdu)
 {
struct usb_device *udev = sdev->udev;
struct usb_host_endpoint *ep;
struct usb_endpoint_descriptor *epd = NULL;
+   int epnum = pdu->base.ep;
+   int dir = pdu->base.direction;
 
if (epnum < 0 || epnum > 15)
goto err_ret;
@@ -339,6 +341,15 @@ static int get_pipe(struct stub_device *sdev, int epnum, 
int dir)
goto err_ret;
 
epd = >desc;
+
+   /* validate transfer_buffer_length */
+   if (pdu->u.cmd_submit.transfer_buffer_length > INT_MAX) {
+   dev_err(>udev->dev,
+   "CMD_SUBMIT: -EMSGSIZE transfer_buffer_length %d\n",
+   pdu->u.cmd_submit.transfer_buffer_length);
+   return -1;
+   }
+
if (usb_endpoint_xfer_control(epd)) {
if (dir == USBIP_DIR_OUT)
return usb_sndctrlpipe(udev, epnum);
@@ -361,6 +372,21 @@ static int get_pipe(struct stub_device *sdev, int epnum, 
int dir)
}
 
if (usb_endpoint_xfer_isoc(epd)) {
+   /* validate packet size and number of packets */
+   unsigned int maxp, packets, bytes;
+
+   maxp = usb_endpoint_maxp(epd);
+   maxp *= usb_endpoint_maxp_mult(epd);
+   bytes = pdu->u.cmd_submit.transfer_buffer_length;
+   packets = DIV_ROUND_UP(bytes, maxp);
+
+   if (pdu->u.cmd_submit.number_of_packets < 0 ||
+   pdu->u.cmd_submit.number_of_packets > packets) {
+   dev_err(>udev->dev,
+   "CMD_SUBMIT: isoc invalid num packets %d\n",
+   pdu->u.cmd_submit.number_of_packets);
+   return -1;
+   }
if (dir == USBIP_DIR_OUT)
return usb_sndisocpipe(udev, epnum);
else
@@ -369,7 +395,7 @@ static int get_pipe(struct stub_device *sdev, int epnum, 
int dir)
 
 err_ret:
/* NOT REACHED */
-   dev_err(>udev->dev, "get pipe() invalid epnum %d\n", epnum);
+   dev_err(>udev->dev, "CMD_SUBMIT: invalid epnum %d\n", epnum);
return -1;
 }
 
@@ -434,7 +460,7 @@ static void stub_recv_cmd_submit(struct stub_device *sdev,
struct stub_priv *priv;
struct usbip_device *ud = >ud;
struct usb_device *udev = sdev->udev;
-   int pipe = get_pipe(sdev, pdu->base.ep, pdu->base.direction);
+   int pipe = get_pipe(sdev, pdu);
 
if (pipe == -1)
return;
@@ -456,7 +482,8 @@ static void stub_recv_cmd_submit(struct stub_device *sdev,
}
 
/* allocate urb transfer buffer, if needed */
-   if (pdu->u.cmd_submit.transfer_buffer_length > 0) {
+   if (pdu->u.cmd_submit.transfer_buffer_length > 0 &&
+   pdu->u.cmd_submit.transfer_buffer_length <= INT_MAX) {
priv->urb->transfer_buffer =
kzalloc(pdu->u.cmd_submit.transfer_buffer_length,
GFP_KERNEL);
-- 
2.14.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 4/4] usbip: fix stub_send_ret_submit() vulnerability to null transfer_buffer

[Shuah Khan]

stub_send_ret_submit() handles urb with a potential null transfer_buffer,
when it replays a packet with potential malicious data that could contain
a null buffer. Add a check for the condition when actual_length > 0 and
transfer_buffer is null.

Signed-off-by: Shuah Khan 
---
 drivers/usb/usbip/stub_tx.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/usb/usbip/stub_tx.c b/drivers/usb/usbip/stub_tx.c
index b18bce96c212..53172b1f6257 100644
--- a/drivers/usb/usbip/stub_tx.c
+++ b/drivers/usb/usbip/stub_tx.c
@@ -167,6 +167,13 @@ static int stub_send_ret_submit(struct stub_device *sdev)
memset(_header, 0, sizeof(pdu_header));
memset(, 0, sizeof(msg));
 
+   if (urb->actual_length > 0 && !urb->transfer_buffer) {
+   dev_err(>udev->dev,
+   "urb: actual_length %d transfer_buffer null\n",
+   urb->actual_length);
+   return -1;
+   }
+
if (usb_pipetype(urb->pipe) == PIPE_ISOCHRONOUS)
iovnum = 2 + urb->number_of_packets;
else
-- 
2.14.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 3/4] usbip: prevent vhci_hcd driver from leaking a socket pointer address

[Shuah Khan]

When a client has a USB device attached over IP, the vhci_hcd driver is
locally leaking a socket pointer address via the

/sys/devices/platform/vhci_hcd/status file (world-readable) and in debug
output when "usbip --debug port" is run.

Fix it to not leak. The socket pointer address is not used at the moment
and it was made visible as a convenient way to find IP address from socket
pointer address by looking up /proc/net/{tcp,tcp6}.

As this opens a security hole, the fix replaces socket pointer address with
sockfd.

Signed-off-by: Shuah Khan 
---
 drivers/usb/usbip/usbip_common.h |  1 +
 drivers/usb/usbip/vhci_sysfs.c   | 25 -
 tools/usb/usbip/libsrc/vhci_driver.c |  8 
 3 files changed, 21 insertions(+), 13 deletions(-)

diff --git a/drivers/usb/usbip/usbip_common.h b/drivers/usb/usbip/usbip_common.h
index e5de35c8c505..473fb8a87289 100644
--- a/drivers/usb/usbip/usbip_common.h
+++ b/drivers/usb/usbip/usbip_common.h
@@ -256,6 +256,7 @@ struct usbip_device {
/* lock for status */
spinlock_t lock;
 
+   int sockfd;
struct socket *tcp_socket;
 
struct task_struct *tcp_rx;
diff --git a/drivers/usb/usbip/vhci_sysfs.c b/drivers/usb/usbip/vhci_sysfs.c
index e78f7472cac4..091f76b7196d 100644
--- a/drivers/usb/usbip/vhci_sysfs.c
+++ b/drivers/usb/usbip/vhci_sysfs.c
@@ -17,15 +17,20 @@
 
 /*
  * output example:
- * hub port sta spd dev  socket   local_busid
- * hs   004 000  c5a7bb80 1-2.3
+ * hub port sta spd dev   sockfdlocal_busid
+ * hs   004 000   3 1-2.3
  * 
- * ss  0008 004 000  d8cee980 2-3.4
+ * ss  0008 004 000   4 2-3.4
  * 
  *
- * IP address can be retrieved from a socket pointer address by looking
- * up /proc/net/{tcp,tcp6}. Also, a userland program may remember a
- * port number and its peer IP address.
+ * Output includes socket fd instead of socket pointer address to avoid
+ * leaking kernel memory address in:
+ * /sys/devices/platform/vhci_hcd.0/status and in debug output.
+ * The socket pointer address is not used at the moment and it was made
+ * visible as a convenient way to find IP address from socket pointer
+ * address by looking up /proc/net/{tcp,tcp6}. As this opens a security
+ * hole, the change is made to use sockfd instead.
+ *
  */
 static void port_show_vhci(char **out, int hub, int port, struct vhci_device 
*vdev)
 {
@@ -39,8 +44,8 @@ static void port_show_vhci(char **out, int hub, int port, 
struct vhci_device *vd
if (vdev->ud.status == VDEV_ST_USED) {
*out += sprintf(*out, "%03u %08x ",
  vdev->speed, vdev->devid);
-   *out += sprintf(*out, "%16p %s",
- vdev->ud.tcp_socket,
+   *out += sprintf(*out, "%u %s",
+ vdev->ud.sockfd,
  dev_name(>udev->dev));
 
} else {
@@ -160,7 +165,8 @@ static ssize_t nports_show(struct device *dev, struct 
device_attribute *attr,
char *s = out;
 
/*
-* Half the ports are for SPEED_HIGH and half for SPEED_SUPER, thus the 
* 2.
+* Half the ports are for SPEED_HIGH and half for SPEED_SUPER,
+* thus the * 2.
 */
out += sprintf(out, "%d\n", VHCI_PORTS * vhci_num_controllers);
return out - s;
@@ -366,6 +372,7 @@ static ssize_t store_attach(struct device *dev, struct 
device_attribute *attr,
 
vdev->devid = devid;
vdev->speed = speed;
+   vdev->ud.sockfd = sockfd;
vdev->ud.tcp_socket = socket;
vdev->ud.status = VDEV_ST_NOTASSIGNED;
 
diff --git a/tools/usb/usbip/libsrc/vhci_driver.c 
b/tools/usb/usbip/libsrc/vhci_driver.c
index 8a1cd1616de4..d1fc0f9f00fb 100644
--- a/tools/usb/usbip/libsrc/vhci_driver.c
+++ b/tools/usb/usbip/libsrc/vhci_driver.c
@@ -50,14 +50,14 @@ static int parse_status(const char *value)
 
while (*c != '\0') {
int port, status, speed, devid;
-   unsigned long socket;
+   int sockfd;
char lbusid[SYSFS_BUS_ID_SIZE];
struct usbip_imported_device *idev;
char hub[3];
 
-   ret = sscanf(c, "%2s  %d %d %d %x %lx %31s\n",
+   ret = sscanf(c, "%2s  %d %d %d %x %u %31s\n",
hub, , , ,
-   , , lbusid);
+   , , lbusid);
 
if (ret < 5) {
dbg("sscanf failed: %d", ret);
@@ -66,7 +66,7 @@ static int parse_status(const char *value)
 
dbg("hub %s port %d status %d speed %d devid %x",
hub, port, status, speed, devid);
-   dbg("socket %lx lbusid 

Re: USB: hub: Delete an error message for a failed memory allocation in usb_hub_clear_tt_buffer()

[Dan Carpenter]

On Thu, Dec 07, 2017 at 10:12:27AM -0500, Alan Stern wrote:
> The real problem is that the kernel development community doesn't have
> a fixed policy on how to handle memory allocation errors.  There are
> several possibilities:
> 
>   Ignore them on the grounds that they will never happen.
>   (Really?  And what is the size limit above which they
>   might happen?)
> 

It's pretty rare to ignore allocation failures these days.  It causes
static checker warnings.

Sometimes it's accepted for people to ignore errors during boot but
I hate that because how am I supposed to filter out those static checker
warnings?  It's better to pretend that the kernel will still boot
without essential hardware instead of wasting everyone's time who looks
at checker output.

>   Ignore them on the grounds that the machine will hang or
>   crash in the near future.  (Is this guaranteed?)

On boot sometimes yes.

> 
>   Treat them like other errors: try to press forward (perhaps
>   in a degraded mode).
> 
>   Treat them like other errors: log an error message and try
>   to press forward.
> 

The standard is to treat them like errors and try press forward in a
degraded mode but don't print a message.  Checkpatch.pl complains if you
print a warning for allocation failures.  A lot of low level functions
handle their own messages pretty well but especially kmalloc() does.

I also have a special static checker warning for when people do:

foo = alloc();
BUG_ON(!foo);

People do that occasionally but fortunately it's pretty rare.  10 years
ago that's how btrfs did error handling, but now there are only 4 of
these still remaining in btrfs.

regards,
dan carpenter

--
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: RFC: FT232H based FPGA configuration adapter drivers

[Alan Tull]

On Thu, Dec 7, 2017 at 8:31 AM, Anatolij Gustschin  wrote:
> Hi,
>
> I have to rework drivers for custom FT232H based FPGA configuration
> adapters to make them suitable for including in mainline kernel. These
> adapters should be usable via low-level drivers for FPGA Manager
> framework. Two required low-level FPGA Manager drivers (for PS-SPI and
> CvP configurations) are already in mainline. The missing parts are the
> MPSSE SPI master driver (for attaching altera-ps-spi SPI devices) and
> the FTDI FIFO FPP interface driver for FPGA Manager. I'm CCing the
> relevant subsystem mailing lists and would like to get feedback to the
> draft below before rewriting the missing driver parts.
>
> A few words about our FPGA and FPGA configuration adapter hardware. We
> have FPGA PCIe boards with two different FT232H based configuration
> adapters. The first adapter type utilizes FT232H chip in MPSSE mode to
> connect ADBUS SPI/GPIO pins to Stratix-V PS-SPI interface. Another
> adapter type connects FT232H ADBUS (in FT245 FIFO mode) and two ACBUS
> GPIOs to a CPLD, the CPLD is connected to the Arria-10 FPP interface.
> Both FPGA boards are connected to the host via PCIe and USB (FT232H).
>
> Below simplified diagram shows the drivers relationship used in the
> first patch series [1] submitted to the FPGA and USB lists before
> (this series didn't yet include the MPSSE SPI master driver).
>
>+-+
>| |
>|  STRATIX V  |PS-SPI FT245 FIFO & GPIO
>| +-++---+
>|  on Board 1 | ||   |
>| | ++---+
>|  PCIe   |   ADBUS   |  CPLD  |
>+---+-+ Connection Options  ++---+
>^  (MPSSE or FIFO)  |
>|  |  +--+---+
>   altera-cvp  +---+--+   | FPP  |
>   |  |   |  |
>   | FT232H 0x0403:0x6014 |   |   ARRIA 10   |
>   |  |   |  |
>   +--+---+   |  on Board 2  |
>  |   |  |
>   MFD drv +--+---+   |PCIe  |
>   creates | ftdi-ft232h MFD drv  |   +--+---+
>  platform |  USB bulk/ctrl xfer  |  ^
>   devices +---+--+---+---+  |
>below  |  |   |  |
> +-+  |   +-+++
> || | |
>  +--+---+ +--+---+ +---+-+   |
>  |ftdi-mpsse-spi| |ftdi-cbus-gpio| |ftdi-fifo-fpp-mgr|   |
>  | platform dev | | platform dev | |  platform dev   |   |
>  +---+--+ +--+---+ +-+---+   |
>   platform   ^   ^   ^   |
>drivers:  +   +   |   |
>  MPSSE SPI master  ACBUS GPIO Ctrl +-++--+
>  ^   ^ |  |
>  |   | +  +
>altera-ps-spi \uses   ftdi-fifo-fpp altera-cvp
> FPGA Manager  --+ FPGA ManagerFPGA Manager
>  ^^   ^
>  ||   |
>  +-+  +  ++
>fpga-mgr
>
> The first FTDI FPP adapter driver patch series has some fundamental
> issues as discussed on the lists and I plan to rework the FT232H
> specific parts to prepare a new patch series. We have already
> reserved custom PIDs for both adapter types and can use them in
> adapter EEPROMs to ensure binding to the vendor specific drivers
> for SPI and FIFO FPP types.
>
> Instead of MFD part as in previous version I intend to add an USB misc
> driver for our FPGA configuration adapters under drivers/usb/misc.
> When probing for VID/PID assigned to FIFO-FPP adapter type, this
> driver will register CBUS GPIO controller, GPIO lookup tables for

 I'm not clear how these lookup tables will be specified.  Is this
platform using device tree?

> FIFO FPP device and will create a platform device for attaching the
> low-level FPGA manager driver for FIFO FPP interface. The attached
> FPGA manager driver will be similar to the ftdi-fifo-fpp driver and
> will reside in drivers/fpga. When probing for VID/PID assigned to
> MPSSE SPI adapter type, the USB misc driver will register MPSSE GPIO
> controller, GPIO lookup tables for altera-ps-spi control/status GPIOs
> and will create platform device for attaching MPSSE SPI master
> controller driver. The SPI master controller platform driver will
> register MPSSE SPI bus with SPI slave device from spi_board_info
> struct in its 

Re: [PATCH v2 0/8] lsusb: Add initial support for USB Audio Class 3

[Greg KH]

On Thu, Dec 07, 2017 at 07:24:35PM +, Michael Drake wrote:
> On 07/12/17 17:26, Greg KH wrote:
> > On Thu, Dec 07, 2017 at 05:14:10PM +, Michael Drake wrote:
> > > On 07/12/17 15:16, Greg KH wrote:
> > > > On Thu, Dec 07, 2017 at 04:01:23PM +0100, Greg KH wrote:
> > > > > Oops, I should have tested the code, it now crashes for me with the
> > > > > following error:
> > > > >   Floating point exception (core dumped)
> > > > > 
> > > > > Do you see this as well?
> > > 
> > > No, I don't see that.
> > > 
> > > > And it's crashing on my USB audio device.  Here's the output of it from
> > > > the "old" lsusb output.
> > > 
> > > [snip]
> > > 
> > > Does it still crash with the warning fixes I posted?  If so I'll
> > > look in detail tomorrow.
> > 
> > I will check when I get home tonight, I don't have the USB device on me
> > at the moment.
> 
> Thank you.  I believe I've guessed the problem and sent a patch.

Ok, that now works.

But there is a difference in the "old" and "new" outputs, here's a diff
of a full -v output of my laptop and a bunch of USB devices plugged in,
showing the fields that now look different.

The big one is the change from "streaming" to "control", is that
correct?

thanks,

greg k-h


--- lsusb-v.orig2017-12-07 21:01:26.153185002 +0100
+++ lsusb-v.new 2017-12-07 21:01:32.806517978 +0100
@@ -1110,9 +1110,9 @@
 bDescriptorType36
 bDescriptorSubtype  1 (HEADER)
 bcdADC   1.00
-wTotalLength   0x0028
+wTotalLength   40
 bInCollection   1
-baInterfaceNr(0)1
+baInterfaceNr( 0)   1
   AudioControl Interface Descriptor:
 bLength12
 bDescriptorType36
@@ -1142,10 +1142,10 @@
 bUnitID13
 bSourceID   1
 bControlSize1
-bmaControls(0)   0x01
+bmaControls( 0)  0x01
   Mute Control
-bmaControls(1)   0x00
-bmaControls(2)   0x00
+bmaControls( 1)  0x00
+bmaControls( 2)  0x00
 iFeature0 
 Interface Descriptor:
   bLength 9
@@ -1173,7 +1173,7 @@
 bDescriptorSubtype  1 (AS_GENERAL)
 bTerminalLink   1
 bDelay  1 frames
-wFormatTag 0x0001 PCM
+wFormatTag  1 PCM
   AudioStreaming Interface Descriptor:
 bLength20
 bDescriptorType36
@@ -1199,14 +1199,14 @@
 bInterval   4
 bRefresh0
 bSynchAddress 133
-AudioStreaming Endpoint Descriptor:
+AudioControl Endpoint Descriptor:
   bLength 7
   bDescriptorType37
   bDescriptorSubtype  1 (EP_GENERAL)
   bmAttributes 0x01
 Sampling Frequency
   bLockDelayUnits 0 Undefined
-  wLockDelay 0x
+  wLockDelay  0 Undefined
   Endpoint Descriptor:
 bLength 9
 bDescriptorType 5
@@ -1235,7 +1235,7 @@
 bDescriptorSubtype  1 (AS_GENERAL)
 bTerminalLink   1
 bDelay  1 frames
-wFormatTag 0x0001 PCM
+wFormatTag  1 PCM
   AudioStreaming Interface Descriptor:
 bLength20
 bDescriptorType36
@@ -1261,14 +1261,14 @@
 bInterval   4
 bRefresh0
 bSynchAddress 133
-AudioStreaming Endpoint Descriptor:
+AudioControl Endpoint Descriptor:
   bLength 7
   bDescriptorType37
   bDescriptorSubtype  1 (EP_GENERAL)
   bmAttributes 0x01
 Sampling Frequency
   bLockDelayUnits 0 Undefined
-  wLockDelay 0x
+  wLockDelay  0 Undefined
   Endpoint Descriptor:
 bLength 9
 bDescriptorType 5
--
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 v1 1/1] lsusb: Fix array entry count for variable sized entries.

[Greg KH]

On Thu, Dec 07, 2017 at 07:18:39PM +, Michael Drake wrote:
> This fixes a divide by zero which happened when an array,
> without an explicit entry count (ultimately calculated from
> the value in the descriptor data's bLength field) was used
> on field with a variable size.
> 
> The solultion is to use the get_entry_size() function on
> the array entry, which can get the entry size from a
> referenced field.
> 
> Signed-off-by: Michael Drake 
> ---
>  desc-dump.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Nice, that fixed the problem, thanks.

Now applied and pushed out.

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] usbnet: fix alignment for frames with no ethernet header

[David Miller]

From: Bjørn Mork 
Date: Thu, 07 Dec 2017 20:01:16 +0100

> David Miller  writes:
> 
>> From: Bjørn Mork 
>> Date: Wed,  6 Dec 2017 20:21:24 +0100
>>
>>> The qmi_wwan minidriver support a 'raw-ip' mode where frames are
>>> received without any ethernet header. This causes alignment issues
>>> because the skbs allocated by usbnet are "IP aligned".
>>> 
>>> Fix by allowing minidrivers to disable the additional alignment
>>> offset. This is implemented using a per-device flag, since the same
>>> minidriver also supports 'ethernet' mode.
>>> 
>>> Fixes: 32f7adf633b9 ("net: qmi_wwan: support "raw IP" mode")
>>> Reported-and-tested-by: Jay Foster 
>>> Signed-off-by: Bjørn Mork 
>>
>> Looks good, applied and queued up for -stable.
> 
> 
> Thanks. I can see it in the -stable queue, but it didn't show up here
> yet: https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git
> 
> Did it get stuck somewhere?

Caught again :-)

I do GIT work on two different machines (one at home and one at the
office) and sometimes I head to the office before pushing everything
out on the machine at home :-/

I've pushed this specific patch out to 'net'.
--
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 0/8] lsusb: Add initial support for USB Audio Class 3

[Michael Drake]

On 07/12/17 17:26, Greg KH wrote:

On Thu, Dec 07, 2017 at 05:14:10PM +, Michael Drake wrote:

On 07/12/17 15:16, Greg KH wrote:

On Thu, Dec 07, 2017 at 04:01:23PM +0100, Greg KH wrote:

Oops, I should have tested the code, it now crashes for me with the
following error:
Floating point exception (core dumped)

Do you see this as well?


No, I don't see that.


And it's crashing on my USB audio device.  Here's the output of it from
the "old" lsusb output.


[snip]

Does it still crash with the warning fixes I posted?  If so I'll
look in detail tomorrow.


I will check when I get home tonight, I don't have the USB device on me
at the moment.


Thank you.  I believe I've guessed the problem and sent a patch.

Cheers,

--
Michael Drake  http://www.codethink.co.uk/
--
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 v1 1/1] lsusb: Fix array entry count for variable sized entries.

[Michael Drake]

This fixes a divide by zero which happened when an array,
without an explicit entry count (ultimately calculated from
the value in the descriptor data's bLength field) was used
on field with a variable size.

The solultion is to use the get_entry_size() function on
the array entry, which can get the entry size from a
referenced field.

Signed-off-by: Michael Drake 
---
 desc-dump.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/desc-dump.c b/desc-dump.c
index 0df0e00..0adf39d 100644
--- a/desc-dump.c
+++ b/desc-dump.c
@@ -423,7 +423,7 @@ static unsigned int get_array_entry_count(
}
}
 
-   entries = size / array_entry->size;
+   entries = size / get_entry_size(buf, desc, array_entry);
}
 
return entries;
-- 
2.11.0

--
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 v1 0/1] lsusb: Fix potential floating point exception.

[Michael Drake]

This fixes the likely cause of a crash found by Greg.

Michael Drake (1):
  lsusb: Fix array entry count for variable sized entries.

 desc-dump.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

-- 
2.11.0

--
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: dwc2: Remove unnecessary debug prints

[Joe Perches]

On Thu, 2017-12-07 at 11:17 -0800, Joe Perches wrote:
> On Wed, 2017-12-06 at 17:57 +0400, Razmik Karapetyan wrote:
> > Removed unnecessary debug prints about DMA mode for host side
> > from dwc2_gahbcfg_init() function.
> 
> What other functionality makes these unnecessary?
> If any, it's nice to de

... describe it in the changelog.
--
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: dwc2: Remove unnecessary debug prints

[Joe Perches]

On Wed, 2017-12-06 at 17:57 +0400, Razmik Karapetyan wrote:
> Removed unnecessary debug prints about DMA mode for host side
> from dwc2_gahbcfg_init() function.

What other functionality makes these unnecessary?
If any, it's nice to de
--
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 0/8] lsusb: Add initial support for USB Audio Class 3

[Greg KH]

On Thu, Dec 07, 2017 at 06:26:30PM +0100, Greg KH wrote:
> On Thu, Dec 07, 2017 at 05:14:10PM +, Michael Drake wrote:
> > 
> > 
> > On 07/12/17 15:16, Greg KH wrote:
> > > On Thu, Dec 07, 2017 at 04:01:23PM +0100, Greg KH wrote:
> > > > On Thu, Dec 07, 2017 at 04:00:36PM +0100, Greg KH wrote:
> > > > > On Thu, Dec 07, 2017 at 10:26:21AM +, Michael Drake wrote:
> > > > > > This adds a new way of dumping descriptors, which splits the 
> > > > > > knowledge
> > > > > > of how to interpret descriptor data from the actual dumping. This 
> > > > > > has
> > > > > > two advantages:
> > > > > > 
> > > > > > 1. It is easy to add support for new descriptors, since they are now
> > > > > > simple definitions that resemble the tables in the USB 
> > > > > > specifications.
> > > > > > 
> > > > > > 2. The code for dumping descriptors is common, so the output is 
> > > > > > easy to
> > > > > > keep consistent. It is also consistent and thorough in its 
> > > > > > handling
> > > > > > of insufficient descriptor data buffer, and junk data at the 
> > > > > > end of
> > > > > > a descriptor.
> > > > > > 
> > > > > > UAC1 and UAC2 are converted to use the new mechanism, initial 
> > > > > > support
> > > > > > for UAC3 is added.  Finally, support for the USB3 BOS Configuration
> > > > > > Summary Descriptor is added.
> > > > > > 
> > > > > > This was previously opened as a github pull request here:
> > > > > > 
> > > > > >  https://github.com/gregkh/usbutils/pull/61
> > > > > 
> > > > > Thanks for this, all of the patches are now applied.
> > > > > 
> > > > > There were some intermediate build warnings, but future patches in the
> > > > > series fixed that up, next time be more careful, each patch should be
> > > > > "clean".
> > > > > 
> > > > > However the build now gets the following warnings:
> > > > > 
> > > > >CC   lsusb-lsusb.o
> > > > > lsusb.c:220:12: warning: ‘get_audioterminal_string’ defined but not 
> > > > > used [-Wunused-function]
> > > > >   static int get_audioterminal_string(char *buf, size_t size, 
> > > > > u_int16_t termt)
> > > > >  ^~~~
> > > > >CC   lsusb-lsusb-t.o
> > > > >CC   lsusb-desc-defs.o
> > > > >CC   lsusb-desc-dump.o
> > > > > desc-dump.c: In function ‘desc_bmcontrol_dump’:
> > > > > desc-dump.c:67:18: warning: comparison between pointer and zero 
> > > > > character constant [-Wpointer-compare]
> > > > > if (strings[0] != '\0') {
> > > > >^~
> > > > > desc-dump.c:67:7: note: did you mean to dereference the pointer?
> > > > > if (strings[0] != '\0') {
> > > > > ^
> > > > >CC   lsusb-names.o
> > > > > 
> > > > > 
> > > > > Can you fix this up and send a patch for them?
> > > > 
> > > > Oops, I should have tested the code, it now crashes for me with the
> > > > following error:
> > > > Floating point exception (core dumped)
> > > > 
> > > > Do you see this as well?
> > 
> > No, I don't see that.
> > 
> > > And it's crashing on my USB audio device.  Here's the output of it from
> > > the "old" lsusb output.
> > 
> > [snip]
> > 
> > Does it still crash with the warning fixes I posted?  If so I'll
> > look in detail tomorrow.
> 
> I will check when I get home tonight, I don't have the USB device on me
> at the moment.

Nope, same failure :(

I'll try to debug it tomorrow if you can't think of anything...

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] usbnet: fix alignment for frames with no ethernet header

[Bjørn Mork]

David Miller  writes:

> From: Bjørn Mork 
> Date: Wed,  6 Dec 2017 20:21:24 +0100
>
>> The qmi_wwan minidriver support a 'raw-ip' mode where frames are
>> received without any ethernet header. This causes alignment issues
>> because the skbs allocated by usbnet are "IP aligned".
>> 
>> Fix by allowing minidrivers to disable the additional alignment
>> offset. This is implemented using a per-device flag, since the same
>> minidriver also supports 'ethernet' mode.
>> 
>> Fixes: 32f7adf633b9 ("net: qmi_wwan: support "raw IP" mode")
>> Reported-and-tested-by: Jay Foster 
>> Signed-off-by: Bjørn Mork 
>
> Looks good, applied and queued up for -stable.


Thanks. I can see it in the -stable queue, but it didn't show up here
yet: https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git

Did it get stuck somewhere?


Bjørn
--
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 0/8] lsusb: Add initial support for USB Audio Class 3

[Greg KH]

On Thu, Dec 07, 2017 at 05:14:10PM +, Michael Drake wrote:
> 
> 
> On 07/12/17 15:16, Greg KH wrote:
> > On Thu, Dec 07, 2017 at 04:01:23PM +0100, Greg KH wrote:
> > > On Thu, Dec 07, 2017 at 04:00:36PM +0100, Greg KH wrote:
> > > > On Thu, Dec 07, 2017 at 10:26:21AM +, Michael Drake wrote:
> > > > > This adds a new way of dumping descriptors, which splits the knowledge
> > > > > of how to interpret descriptor data from the actual dumping. This has
> > > > > two advantages:
> > > > > 
> > > > > 1. It is easy to add support for new descriptors, since they are now
> > > > > simple definitions that resemble the tables in the USB 
> > > > > specifications.
> > > > > 
> > > > > 2. The code for dumping descriptors is common, so the output is easy 
> > > > > to
> > > > > keep consistent. It is also consistent and thorough in its 
> > > > > handling
> > > > > of insufficient descriptor data buffer, and junk data at the end 
> > > > > of
> > > > > a descriptor.
> > > > > 
> > > > > UAC1 and UAC2 are converted to use the new mechanism, initial support
> > > > > for UAC3 is added.  Finally, support for the USB3 BOS Configuration
> > > > > Summary Descriptor is added.
> > > > > 
> > > > > This was previously opened as a github pull request here:
> > > > > 
> > > > >  https://github.com/gregkh/usbutils/pull/61
> > > > 
> > > > Thanks for this, all of the patches are now applied.
> > > > 
> > > > There were some intermediate build warnings, but future patches in the
> > > > series fixed that up, next time be more careful, each patch should be
> > > > "clean".
> > > > 
> > > > However the build now gets the following warnings:
> > > > 
> > > >CC   lsusb-lsusb.o
> > > > lsusb.c:220:12: warning: ‘get_audioterminal_string’ defined but not 
> > > > used [-Wunused-function]
> > > >   static int get_audioterminal_string(char *buf, size_t size, u_int16_t 
> > > > termt)
> > > >  ^~~~
> > > >CC   lsusb-lsusb-t.o
> > > >CC   lsusb-desc-defs.o
> > > >CC   lsusb-desc-dump.o
> > > > desc-dump.c: In function ‘desc_bmcontrol_dump’:
> > > > desc-dump.c:67:18: warning: comparison between pointer and zero 
> > > > character constant [-Wpointer-compare]
> > > > if (strings[0] != '\0') {
> > > >^~
> > > > desc-dump.c:67:7: note: did you mean to dereference the pointer?
> > > > if (strings[0] != '\0') {
> > > > ^
> > > >CC   lsusb-names.o
> > > > 
> > > > 
> > > > Can you fix this up and send a patch for them?
> > > 
> > > Oops, I should have tested the code, it now crashes for me with the
> > > following error:
> > >   Floating point exception (core dumped)
> > > 
> > > Do you see this as well?
> 
> No, I don't see that.
> 
> > And it's crashing on my USB audio device.  Here's the output of it from
> > the "old" lsusb output.
> 
> [snip]
> 
> Does it still crash with the warning fixes I posted?  If so I'll
> look in detail tomorrow.

I will check when I get home tonight, I don't have the USB device on me
at the moment.

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 v2 0/8] lsusb: Add initial support for USB Audio Class 3

[Greg KH]

On Thu, Dec 07, 2017 at 05:11:58PM +, Michael Drake wrote:
> 
> 
> On 07/12/17 15:00, Greg KH wrote:
> > On Thu, Dec 07, 2017 at 10:26:21AM +, Michael Drake wrote:
> > > This adds a new way of dumping descriptors, which splits the knowledge
> > > of how to interpret descriptor data from the actual dumping. This has
> > > two advantages:
> > > 
> > > 1. It is easy to add support for new descriptors, since they are now
> > > simple definitions that resemble the tables in the USB specifications.
> > > 
> > > 2. The code for dumping descriptors is common, so the output is easy to
> > > keep consistent. It is also consistent and thorough in its handling
> > > of insufficient descriptor data buffer, and junk data at the end of
> > > a descriptor.
> > > 
> > > UAC1 and UAC2 are converted to use the new mechanism, initial support
> > > for UAC3 is added.  Finally, support for the USB3 BOS Configuration
> > > Summary Descriptor is added.
> > > 
> > > This was previously opened as a github pull request here:
> > > 
> > >  https://github.com/gregkh/usbutils/pull/61
> > 
> > Thanks for this, all of the patches are now applied.
> > 
> > There were some intermediate build warnings, but future patches in the
> > series fixed that up, next time be more careful, each patch should be
> > "clean".
> > 
> > However the build now gets the following warnings:
> > 
> >CC   lsusb-lsusb.o
> > lsusb.c:220:12: warning: ‘get_audioterminal_string’ defined but not used 
> > [-Wunused-function]
> >   static int get_audioterminal_string(char *buf, size_t size, u_int16_t 
> > termt)
> >  ^~~~
> >CC   lsusb-lsusb-t.o
> >CC   lsusb-desc-defs.o
> >CC   lsusb-desc-dump.o
> > desc-dump.c: In function ‘desc_bmcontrol_dump’:
> > desc-dump.c:67:18: warning: comparison between pointer and zero character 
> > constant [-Wpointer-compare]
> > if (strings[0] != '\0') {
> >^~
> > desc-dump.c:67:7: note: did you mean to dereference the pointer?
> > if (strings[0] != '\0') {
> > ^
> >CC   lsusb-names.o
> > 
> > 
> > Can you fix this up and send a patch for them?
> 
> Done.
> 
> Oddly I didn't see the warnings with the default `make`.  I hacked
> "Makefile.am" locally to add "-Wall -Wextra -pedantic -O2" to the
> CCFLAGS, and I saw the one about the unused get_audioterminal_string()
> function.  However I still didn't see the other.
> 
> (Using gcc (Debian 6.3.0-18) 6.3.0 20170516)

It's your version of gcc, you need a more modern one:
$ gcc --version
gcc (GCC) 7.2.0

thanks for the fixups.

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] tools/usbip: fixes potential (minor) "buffer overflow" (detected on recent gcc with -Werror)

[Shuah Khan]

On 12/05/2017 08:09 AM, julien.boibes...@free.fr wrote:
> From: Julien BOIBESSOT 
> 
> Fixes following build error:
> vhci_driver.c: In function 'refresh_imported_device_list':
> vhci_driver.c:118:37: error: 'snprintf' output may be truncated before
>   the last format character [-Werror=format-truncation=]
> snprintf(status, sizeof(status), "status.%d", i);
>  ^~~
> vhci_driver.c:118:4: note: 'snprintf' output between 9 and 18 bytes into
>   a destination of size 17
> snprintf(status, sizeof(status), "status.%d", i);
> ^~~~
> cc1: all warnings being treated as errors
> 
> Signed-off-by: Julien BOIBESSOT 
> ---
>  tools/usb/usbip/libsrc/vhci_driver.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/tools/usb/usbip/libsrc/vhci_driver.c 
> b/tools/usb/usbip/libsrc/vhci_driver.c
> index 5727dfb..a9ce431 100644
> --- a/tools/usb/usbip/libsrc/vhci_driver.c
> +++ b/tools/usb/usbip/libsrc/vhci_driver.c
> @@ -106,7 +106,7 @@ static int parse_status(const char *value)
>   return 0;
>  }
>  
> -#define MAX_STATUS_NAME 16
> +#define MAX_STATUS_NAME 18
>  
>  static int refresh_imported_device_list(void)
>  {
> 

I have been thinking about this some and if it indeed a large
ncontrollers value that makes the buffer overflow, we might have
a bigger problem. That said, this patch looks good to fix the
warming.

Greg,

Could you please pick this patch up.

Acked-by: Shuah Khan 

thanks,
-- Shuah

--
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 v1 0/2] lsusb: Squash warnings from UAC3 merge.

[Greg KH]

On Thu, Dec 07, 2017 at 05:07:17PM +, Michael Drake wrote:
> This series is to fix some warnings reported by Greg.

Thanks, all applied.

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] usb: dwc2: hcd: Fix host channel halt flow

[Stefan Wahren]

Hi Minas,

Am 07.12.2017 um 18:08 schrieb Stefan Wahren:
> According databook in Buffer and External DMA mode
> non-split periodic channels can't be halted.

do you know of any consequences not having this patch applied?

>
> Signed-off-by: Minas Harutyunyan 

Please add a fixes tag.

Thanks
Stefan

> ---
>  drivers/usb/dwc2/hcd.c | 19 +++
>  1 file changed, 19 insertions(+)
>
> diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
> index 614bb9603def..987122497408 100644
> --- a/drivers/usb/dwc2/hcd.c
> +++ b/drivers/usb/dwc2/hcd.c
> @@ -985,6 +985,25 @@ void dwc2_hc_halt(struct dwc2_hsotg *hsotg, struct 
> dwc2_host_chan *chan,
>  
>   if (dbg_hc(chan))
>   dev_vdbg(hsotg->dev, "%s()\n", __func__);
> +
> + /*
> +  * In buffer DMA or external DMA mode channel can't be halted
> +  * for non-split periodic channels. At the end of the next
> +  * uframe/frame (in the worst case), the core generates a channel
> +  * halted and disables the channel automatically.
> +  */
> + if ((hsotg->core_params->dma_enable > 0 &&
> +  hsotg->core_params->dma_desc_enable <= 0) ||
> +  hsotg->hw_params.arch == GHWCFG2_EXT_DMA_ARCH) {
> + if (!chan->do_split &&
> + (chan->ep_type == USB_ENDPOINT_XFER_ISOC ||
> +  chan->ep_type == USB_ENDPOINT_XFER_INT)) {
> + dev_err(hsotg->dev, "%s() Channel can't be halted\n",
> + __func__);
> + return;
> + }
> + }
> +
>   if (halt_status == DWC2_HC_XFER_NO_HALT_STATUS)
>   dev_err(hsotg->dev, "!!! halt_status = %d !!!\n", halt_status);
>  


--
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 0/8] lsusb: Add initial support for USB Audio Class 3

[Michael Drake]

On 07/12/17 15:16, Greg KH wrote:

On Thu, Dec 07, 2017 at 04:01:23PM +0100, Greg KH wrote:

On Thu, Dec 07, 2017 at 04:00:36PM +0100, Greg KH wrote:

On Thu, Dec 07, 2017 at 10:26:21AM +, Michael Drake wrote:

This adds a new way of dumping descriptors, which splits the knowledge
of how to interpret descriptor data from the actual dumping. This has
two advantages:

1. It is easy to add support for new descriptors, since they are now
simple definitions that resemble the tables in the USB specifications.

2. The code for dumping descriptors is common, so the output is easy to
keep consistent. It is also consistent and thorough in its handling
of insufficient descriptor data buffer, and junk data at the end of
a descriptor.

UAC1 and UAC2 are converted to use the new mechanism, initial support
for UAC3 is added.  Finally, support for the USB3 BOS Configuration
Summary Descriptor is added.

This was previously opened as a github pull request here:

 https://github.com/gregkh/usbutils/pull/61


Thanks for this, all of the patches are now applied.

There were some intermediate build warnings, but future patches in the
series fixed that up, next time be more careful, each patch should be
"clean".

However the build now gets the following warnings:

   CC   lsusb-lsusb.o
lsusb.c:220:12: warning: ‘get_audioterminal_string’ defined but not used 
[-Wunused-function]
  static int get_audioterminal_string(char *buf, size_t size, u_int16_t termt)
 ^~~~
   CC   lsusb-lsusb-t.o
   CC   lsusb-desc-defs.o
   CC   lsusb-desc-dump.o
desc-dump.c: In function ‘desc_bmcontrol_dump’:
desc-dump.c:67:18: warning: comparison between pointer and zero character 
constant [-Wpointer-compare]
if (strings[0] != '\0') {
   ^~
desc-dump.c:67:7: note: did you mean to dereference the pointer?
if (strings[0] != '\0') {
^
   CC   lsusb-names.o


Can you fix this up and send a patch for them?


Oops, I should have tested the code, it now crashes for me with the
following error:
Floating point exception (core dumped)

Do you see this as well?


No, I don't see that.


And it's crashing on my USB audio device.  Here's the output of it from
the "old" lsusb output.


[snip]

Does it still crash with the warning fixes I posted?  If so I'll
look in detail tomorrow.

Cheers,

--
Michael Drake  http://www.codethink.co.uk/
--
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 0/8] lsusb: Add initial support for USB Audio Class 3

[Michael Drake]

On 07/12/17 15:00, Greg KH wrote:

On Thu, Dec 07, 2017 at 10:26:21AM +, Michael Drake wrote:

This adds a new way of dumping descriptors, which splits the knowledge
of how to interpret descriptor data from the actual dumping. This has
two advantages:

1. It is easy to add support for new descriptors, since they are now
simple definitions that resemble the tables in the USB specifications.

2. The code for dumping descriptors is common, so the output is easy to
keep consistent. It is also consistent and thorough in its handling
of insufficient descriptor data buffer, and junk data at the end of
a descriptor.

UAC1 and UAC2 are converted to use the new mechanism, initial support
for UAC3 is added.  Finally, support for the USB3 BOS Configuration
Summary Descriptor is added.

This was previously opened as a github pull request here:

 https://github.com/gregkh/usbutils/pull/61


Thanks for this, all of the patches are now applied.

There were some intermediate build warnings, but future patches in the
series fixed that up, next time be more careful, each patch should be
"clean".

However the build now gets the following warnings:

   CC   lsusb-lsusb.o
lsusb.c:220:12: warning: ‘get_audioterminal_string’ defined but not used 
[-Wunused-function]
  static int get_audioterminal_string(char *buf, size_t size, u_int16_t termt)
 ^~~~
   CC   lsusb-lsusb-t.o
   CC   lsusb-desc-defs.o
   CC   lsusb-desc-dump.o
desc-dump.c: In function ‘desc_bmcontrol_dump’:
desc-dump.c:67:18: warning: comparison between pointer and zero character 
constant [-Wpointer-compare]
if (strings[0] != '\0') {
   ^~
desc-dump.c:67:7: note: did you mean to dereference the pointer?
if (strings[0] != '\0') {
^
   CC   lsusb-names.o


Can you fix this up and send a patch for them?


Done.

Oddly I didn't see the warnings with the default `make`.  I hacked
"Makefile.am" locally to add "-Wall -Wextra -pedantic -O2" to the
CCFLAGS, and I saw the one about the unused get_audioterminal_string()
function.  However I still didn't see the other.

(Using gcc (Debian 6.3.0-18) 6.3.0 20170516)

Cheers,

--
Michael Drake  http://www.codethink.co.uk/
--
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 v1 1/2] lsusb: Squash Wpointer-compare warning.

[Michael Drake]

This squashes "warning: comparison between pointer and zero character"

This was an empty string check that was checking the pointer rather
than the first character.  The check was done correctly before the
string was used, so here we yank the correct check up, to the upper
level, replacing the ineffectual/broken one.

Signed-off-by: Michael Drake 
---
 desc-dump.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/desc-dump.c b/desc-dump.c
index 5c8e8ae..0df0e00 100644
--- a/desc-dump.c
+++ b/desc-dump.c
@@ -64,17 +64,16 @@ static void desc_bmcontrol_dump(
   (type == DESC_BMCONTROL_2));
 
while (strings[count] != NULL) {
-   if (strings[0] != '\0') {
+   if (strings[count][0] != '\0') {
if (type == DESC_BMCONTROL_1) {
-   if ((strings[count][0] != '\0') &&
-   (bmcontrols >> count) & 0x1) {
+   if ((bmcontrols >> count) & 0x1) {
printf("%*s%s Control\n",
indent * 2, "",
strings[count]);
}
} else {
control = (bmcontrols >> (count * 2)) & 0x3;
-   if ((strings[count][0] != '\0') && control) {
+   if (control) {
printf("%*s%s Control (%s)\n",
indent * 2, "",
strings[count],
-- 
2.11.0

--
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 v1 2/2] lsusb: Remove unused function.

[Michael Drake]

The get_audioterminal_string() function is now unused.

Signed-off-by: Michael Drake 
---
 lsusb.c | 12 
 1 file changed, 12 deletions(-)

diff --git a/lsusb.c b/lsusb.c
index a1b7f8d..1650016 100644
--- a/lsusb.c
+++ b/lsusb.c
@@ -217,18 +217,6 @@ static int get_protocol_string(char *buf, size_t size, 
u_int8_t cls, u_int8_t su
return snprintf(buf, size, "%s", cp);
 }
 
-static int get_audioterminal_string(char *buf, size_t size, u_int16_t termt)
-{
-   const char *cp;
-
-   if (size < 1)
-   return 0;
-   *buf = 0;
-   if (!(cp = names_audioterminal(termt)))
-   return 0;
-   return snprintf(buf, size, "%s", cp);
-}
-
 static int get_videoterminal_string(char *buf, size_t size, u_int16_t termt)
 {
const char *cp;
-- 
2.11.0

--
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 v1 0/2] lsusb: Squash warnings from UAC3 merge.

[Michael Drake]

This series is to fix some warnings reported by Greg.

Michael Drake (2):
  lsusb: Squash Wpointer-compare warning.
  lsusb: Remove unused function.

 desc-dump.c |  7 +++
 lsusb.c | 12 
 2 files changed, 3 insertions(+), 16 deletions(-)

-- 
2.11.0

--
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] usb: dwc2: host: Setting TOUTCAL and USBTRDTIM fields in host mode

[Stefan Wahren]

Hi Minas,

Am 07.12.2017 um 17:56 schrieb Stefan Wahren:
> Added missing GUSBCFG programming in host mode.
>
> These fields even if was programmed in device mode (in function
> dwc2_hsotg_core_init_disconnected()) will be resetting to POR values
> after core soft reset applied.
> So, each time when switching to host mode required to set these fields
> to correct values. It's allow fix issues with lot of transaction errors
> due to timeouts and turnarrounds on USB bus.
>
> Signed-off-by: Minas Harutyunyan 

please add a fixes tag.

> ---
>  drivers/usb/dwc2/hcd.c | 9 -
>  1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
> index 614bb9603def..05e4e8c07bf1 100644
> --- a/drivers/usb/dwc2/hcd.c
> +++ b/drivers/usb/dwc2/hcd.c
> @@ -2317,10 +2317,17 @@ static int dwc2_core_init(struct dwc2_hsotg *hsotg, 
> bool initial_setup)
>   */
>  static void dwc2_core_host_init(struct dwc2_hsotg *hsotg)
>  {
> - u32 hcfg, hfir, otgctl;
> + u32 hcfg, hfir, otgctl, usbcfg, val;
>  
>   dev_dbg(hsotg->dev, "%s(%p)\n", __func__, hsotg);
>  
> + /* Set HS/FS Timeout Calibration and USBTrdTim */
> + usbcfg = dwc2_readl(hsotg->regs + GUSBCFG);
> + usbcfg &= ~(GUSBCFG_TOUTCAL_MASK | GUSBCFG_USBTRDTIM_MASK);
> + val = (hsotg->phyif == GUSBCFG_PHYIF8) ? 9 : 5;
> + usbcfg |= (GUSBCFG_TOUTCAL(7) | (val << GUSBCFG_USBTRDTIM_SHIFT));

These are too much magic numbers (9,5,7). Could you please add a comment
or even better defines for them?

Thanks

> + dwc2_writel(usbcfg, hsotg->regs + GUSBCFG);
> +
>   /* Restart the Phy Clock */
>   dwc2_writel(0, hsotg->regs + PCGCTL);
>  
--
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] usb: dwc2: Change TxFIFO and RxFIFO flushing flow

[Stefan Wahren]

Hi Minas,

Am 07.12.2017 um 09:40 schrieb Stefan Wahren:
> Before flushing fifos required to check AHB master state and
> flush when AHB master is in IDLE state.
>
> Signed-off-by: Minas Harutyunyan 
> ---
>  drivers/usb/dwc2/core.c | 27 +++
>  1 file changed, 27 insertions(+)
>
> diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c
> index dbca3b8890da..cbc7c562477f 100644
> --- a/drivers/usb/dwc2/core.c
> +++ b/drivers/usb/dwc2/core.c
> @@ -670,10 +670,23 @@ void dwc2_flush_tx_fifo(struct dwc2_hsotg *hsotg, const 
> int num)
>  
>   dev_vdbg(hsotg->dev, "Flush Tx FIFO %d\n", num);
>  
> + /* Wait for AHB master IDLE state */
> + do {
> + udelay(1);

is this delay always necessary before reading GRSTCTL?

If yes please add a comment why.
If no please rework the loop in order to avoid this delay in case the
AHB master is already idle.

> + greset = dwc2_readl(hsotg->regs + GRSTCTL);
> + if (++count > 1) {
> + dev_warn(hsotg->dev,
> +  "%s() HANG! AHB Idle GRSTCTL=%0x\n",
> +  __func__, greset);
> + return;
> + }
> + } while (!(greset & GRSTCTL_AHBIDLE));
> +
>   greset = GRSTCTL_TXFFLSH;
>   greset |= num << GRSTCTL_TXFNUM_SHIFT & GRSTCTL_TXFNUM_MASK;
>   dwc2_writel(greset, hsotg->regs + GRSTCTL);
>  
> + count = 0;
>   do {
>   greset = dwc2_readl(hsotg->regs + GRSTCTL);
>   if (++count > 1) {
> @@ -702,9 +715,23 @@ void dwc2_flush_rx_fifo(struct dwc2_hsotg *hsotg)
>  
>   dev_vdbg(hsotg->dev, "%s()\n", __func__);
>  
> + /* Wait for AHB master IDLE state */
> + do {
> + udelay(1);
> + greset = dwc2_readl(hsotg->regs + GRSTCTL);
> + if (++count > 1) {
> + dev_warn(hsotg->dev,
> +  "%s() HANG! AHB Idle GRSTCTL=%0x\n",
> +  __func__, greset);
> + return;
> + }
> + } while (!(greset & GRSTCTL_AHBIDLE));
> +
>   greset = GRSTCTL_RXFFLSH;
>   dwc2_writel(greset, hsotg->regs + GRSTCTL);
>  
> + /* Wait for RxFIFO flush done */
> + count = 0;
>   do {
>   greset = dwc2_readl(hsotg->regs + GRSTCTL);
>   if (++count > 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: [RFC PATCH 0/2] usb: typec: alternate mode bus

[Hans de Goede]

Hi,

On 07-12-17 16:00, Heikki Krogerus wrote:

Hi Hans,

On Tue, Dec 05, 2017 at 03:56:05PM +0100, Hans de Goede wrote:

Hi,

On 01-12-17 09:38, Heikki Krogerus wrote:

Hi,

Thanks for taking a look at this..

On Sun, Nov 26, 2017 at 12:23:31PM +0100, Hans de Goede wrote:

Hi Heiko,

On 28-09-17 13:35, Heikki Krogerus wrote:

Hi guys,

The bus allows SVID specific communication with the partners to be
handled in separate drivers for each alternate mode.

Alternate mode handling happens with two separate logical devices:
1. Partner alternate mode devices which represent the alternate modes
  on the partner. The driver for them will handle the alternate mode
  specific communication with the partner using VDMs.
2. Port alternate mode devices which represent connections from the
  USB Type-C port to devices on the platform.

The drivers will be bind to the partner alternate modes. The alternate
mode drivers will need to deliver the result of the negotiated pin
configurations to the rest of the platform (towards the port alternate
mode devices). This series includes API for that, however, not the
final implementation yet.

The connections to the other devices on the platform the ports have
can be described by using the remote endpoint concept [1][2] on ACPI
and DT platforms, but I have no solution for the "platform data" case
where we have neither DT nor ACPI to describe the connections for us.


Sorry about the slow reply, I've been a bit swamped with other stuff,
but now I would like to get back to this.

I've been trying to wrap my head around what you're proposing here and
I see how this can help with implementing display-port alternate mode
support, but I don't see how it is going to help with regular superspeed
USB support / the mux problem.

The problems I see / questions I have are:

1) This seems to be driven by having a bus using svid-s as match functions,
but the standard USB function does not have any svid, or at least currently
does not show as such under e.g. /sys/class/typec/port0/port0-partner


USB is the "normal" mode, not alt-mode. We don't need any specific
driver for the USB mode. In alternate modes, we have to communicate
with the partner using SVID specific messages, and that is what we
need the drivers for.


Ack, but we do still need to control the mux in USB-mode I was under
the impression that the alt-mode drivers would be responsible for
switching the mux to the right component in the graph, if (which
may not be true) the alt-mode drivers indeed will be the ones controlling
the mux, then we need a dummy alt-mode for USB mode and a dummy
alt-mode driver for that.


The Type-C/PD PHY/controller drivers (the port drivers) will be in
control of the dual-role (USB) mux, not an alternate mode driver. The
port driver will know if we need to be UFP or DFP in any case, so it
just needs to pass that detail to the mux driver. There is no need for
an extra driver in the middle just for that.


Right, but that only deals with the "USB MUX" i your ascii-art
diagram not with the one you labelled "MUX" and the one you labelled
"MUX" also needs to switch between "tristate(floating) / normal SuperSpeed USB /
upside-down SuperSpeed USB.


But logically we will have two muxes to deal with - one for the USB
handled by the port drivers, and one for the type-c handled by the
alt-mode drivers - even in case the same physical mux component
handles both cases on the platform.


Right, but as mentioned above even for just the non alt-mode Superspeed
USB stuff to work we also need to control the Type-C mux/switch.


2) The alt-mode drivers you are suggesting seem to be about 2 things:
a) Alt-mode specific PD communication
b) Telling other components about pin-configs, e.g. telling the i915 driver how
much display port lanes are configured

What this seems to miss a mechanism to control the mux between the "superspeed"
data-pairs on the port and the dp-port pins on the SoC / the superspeed USB
pins on the SoC. Even leaving display-port out of the picture for now we still
need to control the port -> SoC superspeed pins routing which need to be
one of: tristated (default) / normal / upside-down routing.


We will need to deliver the orientation to the GPU/DP drivers and I'm
not supporting that yet in this draft.


That depends, at least with the PI3USB30532 USB switch, the switch/mux
should take care of upside-downness, but I believe I remember some other
hw where the displayport lanes get swapped when upside down, so I guess
that we need to add info like if the upside-downness is handled inside
the mux to the graph info.


Good point. That needs to be considered.


I'm preparing a more complete
version of these, and I'll propose something for the orientation as
well, though it is a little bit out side the scope of this series.
That information comes from the device drivers or tcpm, not the
alternate mode drivers.

The USB MUX question is a separate topic, however, the idea of
describing the 

Re: USB: hub: Delete an error message for a failed memory allocation in usb_hub_clear_tt_buffer()

[Joe Perches]

On Thu, 2017-12-07 at 10:12 -0500, Alan Stern wrote:
> The real problem is that the kernel development community doesn't have
> a fixed policy on how to handle memory allocation errors.
[]
> If there was one agreed-upon policy, then we could definitively point 
> to old code and say "That's wrong, and here is how it should be fixed."  
> But currently this is not possible, and we end up with repetitive 
> discussions like this one that aren't of general use.

Well stated.

My preferred policy would be to remove all the individual
allocation failure messages and only use the generic
warn_alloc()/dump_stack() mechanism.

--
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 72/73] xfs: Convert mru cache to XArray

[Theodore Ts'o]

On Wed, Dec 06, 2017 at 06:06:48AM -0800, Matthew Wilcox wrote:
> > Unfortunately for you, I don't find arguments along the lines of
> > "lockdep will save us" at all convincing.  lockdep already throws
> > too many false positives to be useful as a tool that reliably and
> > accurately points out rare, exciting, complex, intricate locking
> > problems.
> 
> But it does reliably and accurately point out "dude, you forgot to take
> the lock".  It's caught a number of real problems in my own testing that
> you never got to see.

The problem is that if it has too many false positives --- and it's
gotten *way* worse with the completion callback "feature", people will
just stop using Lockdep as being too annyoing and a waste of developer
time when trying to figure what is a legitimate locking bug versus
lockdep getting confused.

I can't even disable the new Lockdep feature which is throwing
lots of new false positives --- it's just all or nothing.

Dave has just said he's already stopped using Lockdep, as a result.

  - Ted
--
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 0/8] lsusb: Add initial support for USB Audio Class 3

[Greg KH]

On Thu, Dec 07, 2017 at 04:01:23PM +0100, Greg KH wrote:
> On Thu, Dec 07, 2017 at 04:00:36PM +0100, Greg KH wrote:
> > On Thu, Dec 07, 2017 at 10:26:21AM +, Michael Drake wrote:
> > > This adds a new way of dumping descriptors, which splits the knowledge
> > > of how to interpret descriptor data from the actual dumping. This has
> > > two advantages:
> > > 
> > > 1. It is easy to add support for new descriptors, since they are now
> > >simple definitions that resemble the tables in the USB specifications.
> > > 
> > > 2. The code for dumping descriptors is common, so the output is easy to
> > >keep consistent. It is also consistent and thorough in its handling
> > >of insufficient descriptor data buffer, and junk data at the end of
> > >a descriptor.
> > > 
> > > UAC1 and UAC2 are converted to use the new mechanism, initial support
> > > for UAC3 is added.  Finally, support for the USB3 BOS Configuration
> > > Summary Descriptor is added.
> > > 
> > > This was previously opened as a github pull request here:
> > > 
> > > https://github.com/gregkh/usbutils/pull/61
> > 
> > Thanks for this, all of the patches are now applied.
> > 
> > There were some intermediate build warnings, but future patches in the
> > series fixed that up, next time be more careful, each patch should be
> > "clean".
> > 
> > However the build now gets the following warnings:
> > 
> >   CC   lsusb-lsusb.o
> > lsusb.c:220:12: warning: ‘get_audioterminal_string’ defined but not used 
> > [-Wunused-function]
> >  static int get_audioterminal_string(char *buf, size_t size, u_int16_t 
> > termt)
> > ^~~~
> >   CC   lsusb-lsusb-t.o
> >   CC   lsusb-desc-defs.o
> >   CC   lsusb-desc-dump.o
> > desc-dump.c: In function ‘desc_bmcontrol_dump’:
> > desc-dump.c:67:18: warning: comparison between pointer and zero character 
> > constant [-Wpointer-compare]
> >if (strings[0] != '\0') {
> >   ^~
> > desc-dump.c:67:7: note: did you mean to dereference the pointer?
> >if (strings[0] != '\0') {
> >^
> >   CC   lsusb-names.o
> > 
> > 
> > Can you fix this up and send a patch for them?
> 
> Oops, I should have tested the code, it now crashes for me with the
> following error:
>   Floating point exception (core dumped)
> 
> Do you see this as well?

And it's crashing on my USB audio device.  Here's the output of it from
the "old" lsusb output.


Bus 001 Device 018: ID 0d8c:1066 C-Media Electronics, Inc. 
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   2.00
  bDeviceClass0 
  bDeviceSubClass 0 
  bDeviceProtocol 0 
  bMaxPacketSize064
  idVendor   0x0d8c C-Media Electronics, Inc.
  idProduct  0x1066 
  bcdDevice1.03
  iManufacturer   1 
  iProduct2 
  iSerial 0 
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength  214
bNumInterfaces  3
bConfigurationValue 1
iConfiguration  0 
bmAttributes 0xc0
  Self Powered
MaxPower0mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   0
  bInterfaceClass 1 Audio
  bInterfaceSubClass  1 Control Device
  bInterfaceProtocol  0 
  iInterface  2 
  AudioControl Interface Descriptor:
bLength 9
bDescriptorType36
bDescriptorSubtype  1 (HEADER)
bcdADC   1.00
wTotalLength   40
bInCollection   1
baInterfaceNr( 0)   1
  AudioControl Interface Descriptor:
bLength12
bDescriptorType36
bDescriptorSubtype  2 (INPUT_TERMINAL)
bTerminalID 1
wTerminalType  0x0101 USB Streaming
bAssocTerminal  0
bNrChannels 2
wChannelConfig 0x0003
  Left Front (L)
  Right Front (R)
iChannelNames   0 
iTerminal   0 
  AudioControl Interface Descriptor:
bLength 9
bDescriptorType36
bDescriptorSubtype  3 (OUTPUT_TERMINAL)
bTerminalID 7
wTerminalType  0x0301 Speaker
bAssocTerminal  0
bSourceID  13
iTerminal   0 
  AudioControl Interface Descriptor:
bLength10
bDescriptorType36
bDescriptorSubtype  6 (FEATURE_UNIT)
bUnitID13
bSourceID   1
bControlSize1
bmaControls( 0)  0x01
  Mute Control

Re: USB: hub: Delete an error message for a failed memory allocation in usb_hub_clear_tt_buffer()

[Alan Stern]

On Thu, 7 Dec 2017, Geert Uytterhoeven wrote:

> Hi Alan,
> 
> On Wed, Dec 6, 2017 at 11:02 PM, Alan Stern  wrote:
> > On Wed, 6 Dec 2017, SF Markus Elfring wrote:
> >> >>> Does the existing memory allocation error message include the
> >> >>> >dev device name and driver name?  If it doesn't, there will be
> >> >>> no way for the user to tell that the error message is related to the
> >> >>> device failure.
> >> >>
> >> >> No, but the effect is similar.
> >> >>
> >> >> OOM does a dump_stack() so this function's call tree is shown.
> >> >
> >> > A call stack doesn't tell you which device was being handled.
> >>
> >> Do you find a default Linux allocation failure report insufficient then?
> >>
> >> Would you like to to achieve that the requested information can be 
> >> determined
> >> from a backtrace?
> >
> > It is not practical to do this.  The memory allocation routines do not
> > for what purpose the memory is being allocated; hence when a failure
> > occurs they cannot tell what device (or other part of the system) will
> > be affected.
> 
> If even allocation of 24 bytes fails, lots of other devices and other parts of
> the system will start failing really soon...

In fact, one wonders if the allocation routine's own error message and
stack trace would actually appear anywhere...

> > That's why we have a secondary error message.
> 
> ... and the secondary error message would still be useless.

Well, there is still a difference between GFP_ATOMIC and GFP_KERNEL 
allocations.  Failure of the first doesn't necessarily imply failure of 
the second, so perhaps the system could recover.

The real problem is that the kernel development community doesn't have
a fixed policy on how to handle memory allocation errors.  There are
several possibilities:

Ignore them on the grounds that they will never happen.
(Really?  And what is the size limit above which they
might happen?)

Ignore them on the grounds that the machine will hang or
crash in the near future.  (Is this guaranteed?)

Treat them like other errors: try to press forward (perhaps
in a degraded mode).

Treat them like other errors: log an error message and try
to press forward.

And probably a few more that haven't occurred to me.  No doubt there 
are examples of each at various places in the kernel.  Nobody seems
able to agree on a single course of action.  Maybe not even Linus.

If there was one agreed-upon policy, then we could definitively point 
to old code and say "That's wrong, and here is how it should be fixed."  
But currently this is not possible, and we end up with repetitive 
discussions like this one that aren't of general use.

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 0/8] lsusb: Add initial support for USB Audio Class 3

[Greg KH]

On Thu, Dec 07, 2017 at 04:00:36PM +0100, Greg KH wrote:
> On Thu, Dec 07, 2017 at 10:26:21AM +, Michael Drake wrote:
> > This adds a new way of dumping descriptors, which splits the knowledge
> > of how to interpret descriptor data from the actual dumping. This has
> > two advantages:
> > 
> > 1. It is easy to add support for new descriptors, since they are now
> >simple definitions that resemble the tables in the USB specifications.
> > 
> > 2. The code for dumping descriptors is common, so the output is easy to
> >keep consistent. It is also consistent and thorough in its handling
> >of insufficient descriptor data buffer, and junk data at the end of
> >a descriptor.
> > 
> > UAC1 and UAC2 are converted to use the new mechanism, initial support
> > for UAC3 is added.  Finally, support for the USB3 BOS Configuration
> > Summary Descriptor is added.
> > 
> > This was previously opened as a github pull request here:
> > 
> > https://github.com/gregkh/usbutils/pull/61
> 
> Thanks for this, all of the patches are now applied.
> 
> There were some intermediate build warnings, but future patches in the
> series fixed that up, next time be more careful, each patch should be
> "clean".
> 
> However the build now gets the following warnings:
> 
>   CC   lsusb-lsusb.o
> lsusb.c:220:12: warning: ‘get_audioterminal_string’ defined but not used 
> [-Wunused-function]
>  static int get_audioterminal_string(char *buf, size_t size, u_int16_t termt)
> ^~~~
>   CC   lsusb-lsusb-t.o
>   CC   lsusb-desc-defs.o
>   CC   lsusb-desc-dump.o
> desc-dump.c: In function ‘desc_bmcontrol_dump’:
> desc-dump.c:67:18: warning: comparison between pointer and zero character 
> constant [-Wpointer-compare]
>if (strings[0] != '\0') {
>   ^~
> desc-dump.c:67:7: note: did you mean to dereference the pointer?
>if (strings[0] != '\0') {
>^
>   CC   lsusb-names.o
> 
> 
> Can you fix this up and send a patch for them?

Oops, I should have tested the code, it now crashes for me with the
following error:
Floating point exception (core dumped)

Do you see this as well?

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 v2 0/8] lsusb: Add initial support for USB Audio Class 3

[Greg KH]

On Thu, Dec 07, 2017 at 10:26:21AM +, Michael Drake wrote:
> This adds a new way of dumping descriptors, which splits the knowledge
> of how to interpret descriptor data from the actual dumping. This has
> two advantages:
> 
> 1. It is easy to add support for new descriptors, since they are now
>simple definitions that resemble the tables in the USB specifications.
> 
> 2. The code for dumping descriptors is common, so the output is easy to
>keep consistent. It is also consistent and thorough in its handling
>of insufficient descriptor data buffer, and junk data at the end of
>a descriptor.
> 
> UAC1 and UAC2 are converted to use the new mechanism, initial support
> for UAC3 is added.  Finally, support for the USB3 BOS Configuration
> Summary Descriptor is added.
> 
> This was previously opened as a github pull request here:
> 
> https://github.com/gregkh/usbutils/pull/61

Thanks for this, all of the patches are now applied.

There were some intermediate build warnings, but future patches in the
series fixed that up, next time be more careful, each patch should be
"clean".

However the build now gets the following warnings:

  CC   lsusb-lsusb.o
lsusb.c:220:12: warning: ‘get_audioterminal_string’ defined but not used 
[-Wunused-function]
 static int get_audioterminal_string(char *buf, size_t size, u_int16_t termt)
^~~~
  CC   lsusb-lsusb-t.o
  CC   lsusb-desc-defs.o
  CC   lsusb-desc-dump.o
desc-dump.c: In function ‘desc_bmcontrol_dump’:
desc-dump.c:67:18: warning: comparison between pointer and zero character 
constant [-Wpointer-compare]
   if (strings[0] != '\0') {
  ^~
desc-dump.c:67:7: note: did you mean to dereference the pointer?
   if (strings[0] != '\0') {
   ^
  CC   lsusb-names.o


Can you fix this up and send a patch for them?

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: [RFC PATCH 0/2] usb: typec: alternate mode bus

[Heikki Krogerus]

Hi Hans,

On Tue, Dec 05, 2017 at 03:56:05PM +0100, Hans de Goede wrote:
> Hi,
> 
> On 01-12-17 09:38, Heikki Krogerus wrote:
> > Hi,
> > 
> > Thanks for taking a look at this..
> > 
> > On Sun, Nov 26, 2017 at 12:23:31PM +0100, Hans de Goede wrote:
> > > Hi Heiko,
> > > 
> > > On 28-09-17 13:35, Heikki Krogerus wrote:
> > > > Hi guys,
> > > > 
> > > > The bus allows SVID specific communication with the partners to be
> > > > handled in separate drivers for each alternate mode.
> > > > 
> > > > Alternate mode handling happens with two separate logical devices:
> > > > 1. Partner alternate mode devices which represent the alternate modes
> > > >  on the partner. The driver for them will handle the alternate mode
> > > >  specific communication with the partner using VDMs.
> > > > 2. Port alternate mode devices which represent connections from the
> > > >  USB Type-C port to devices on the platform.
> > > > 
> > > > The drivers will be bind to the partner alternate modes. The alternate
> > > > mode drivers will need to deliver the result of the negotiated pin
> > > > configurations to the rest of the platform (towards the port alternate
> > > > mode devices). This series includes API for that, however, not the
> > > > final implementation yet.
> > > > 
> > > > The connections to the other devices on the platform the ports have
> > > > can be described by using the remote endpoint concept [1][2] on ACPI
> > > > and DT platforms, but I have no solution for the "platform data" case
> > > > where we have neither DT nor ACPI to describe the connections for us.
> > > 
> > > Sorry about the slow reply, I've been a bit swamped with other stuff,
> > > but now I would like to get back to this.
> > > 
> > > I've been trying to wrap my head around what you're proposing here and
> > > I see how this can help with implementing display-port alternate mode
> > > support, but I don't see how it is going to help with regular superspeed
> > > USB support / the mux problem.
> > > 
> > > The problems I see / questions I have are:
> > > 
> > > 1) This seems to be driven by having a bus using svid-s as match 
> > > functions,
> > > but the standard USB function does not have any svid, or at least 
> > > currently
> > > does not show as such under e.g. /sys/class/typec/port0/port0-partner
> > 
> > USB is the "normal" mode, not alt-mode. We don't need any specific
> > driver for the USB mode. In alternate modes, we have to communicate
> > with the partner using SVID specific messages, and that is what we
> > need the drivers for.
> 
> Ack, but we do still need to control the mux in USB-mode I was under
> the impression that the alt-mode drivers would be responsible for
> switching the mux to the right component in the graph, if (which
> may not be true) the alt-mode drivers indeed will be the ones controlling
> the mux, then we need a dummy alt-mode for USB mode and a dummy
> alt-mode driver for that.

The Type-C/PD PHY/controller drivers (the port drivers) will be in
control of the dual-role (USB) mux, not an alternate mode driver. The
port driver will know if we need to be UFP or DFP in any case, so it
just needs to pass that detail to the mux driver. There is no need for
an extra driver in the middle just for that.

But logically we will have two muxes to deal with - one for the USB
handled by the port drivers, and one for the type-c handled by the
alt-mode drivers - even in case the same physical mux component
handles both cases on the platform.

> > > 2) The alt-mode drivers you are suggesting seem to be about 2 things:
> > > a) Alt-mode specific PD communication
> > > b) Telling other components about pin-configs, e.g. telling the i915 
> > > driver how
> > > much display port lanes are configured
> > > 
> > > What this seems to miss a mechanism to control the mux between the 
> > > "superspeed"
> > > data-pairs on the port and the dp-port pins on the SoC / the superspeed 
> > > USB
> > > pins on the SoC. Even leaving display-port out of the picture for now we 
> > > still
> > > need to control the port -> SoC superspeed pins routing which need to be
> > > one of: tristated (default) / normal / upside-down routing.
> > 
> > We will need to deliver the orientation to the GPU/DP drivers and I'm
> > not supporting that yet in this draft.
> 
> That depends, at least with the PI3USB30532 USB switch, the switch/mux
> should take care of upside-downness, but I believe I remember some other
> hw where the displayport lanes get swapped when upside down, so I guess
> that we need to add info like if the upside-downness is handled inside
> the mux to the graph info.

Good point. That needs to be considered.

> > I'm preparing a more complete
> > version of these, and I'll propose something for the orientation as
> > well, though it is a little bit out side the scope of this series.
> > That information comes from the device drivers or tcpm, not the
> > alternate mode drivers.
> > 
> > The USB MUX question is a separate 

Re: [PATCH] Do not create and install usbutils.pc

[Greg Kroah-Hartman]

On Thu, Dec 07, 2017 at 03:44:15PM +0100, Greg Kroah-Hartman wrote:
> On Sat, Nov 25, 2017 at 08:59:12PM +0100, Aurelien Jarno wrote:
> > The usbutils pkgconfig file defines where the usb.ids database is
> > installed. Given usbutils does not ship with usb.ids and does not
> > install it anymore, it makes no sense to install such a pkgconfig
> > anymore. Remove it.
> > 
> > Signed-off-by: Aurelien Jarno 
> > ---
> >  Makefile.am| 10 +-
> >  usbutils.pc.in |  5 -
> >  2 files changed, 1 insertion(+), 14 deletions(-)
> >  delete mode 100644 usbutils.pc.in
> 
> This doesn't apply to the 009 version of usbutils, what did you make it
> against?  Can you rebase against the latest tree and resend?

Oops, my fault, I had an old tree here, this worked just fine, sorry for
the noise.

Now applied, 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] usbreset.c: add missing include

[Greg Kroah-Hartman]

On Sat, Nov 25, 2017 at 10:48:13PM +0100, Aurelien Jarno wrote:
> Without it one gets:
> 
>   $ gcc -o usbreset usbreset.c
>   usbreset.c: In function 'parse_devlist':
>   usbreset.c:68:17: warning: implicit declaration of function 'strtoul'; did 
> you mean 'strtok'? [-Wimplicit-function-declaration]
>  dev.bus_num = strtoul(attr, NULL, 10);
>^~~
>strtok
> 
> Signed-off-by: Aurelien Jarno 
> ---
>  usbreset.c | 1 +
>  1 file changed, 1 insertion(+)

Applied, 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] Do not create and install usbutils.pc

[Greg Kroah-Hartman]

On Sat, Nov 25, 2017 at 08:59:12PM +0100, Aurelien Jarno wrote:
> The usbutils pkgconfig file defines where the usb.ids database is
> installed. Given usbutils does not ship with usb.ids and does not
> install it anymore, it makes no sense to install such a pkgconfig
> anymore. Remove it.
> 
> Signed-off-by: Aurelien Jarno 
> ---
>  Makefile.am| 10 +-
>  usbutils.pc.in |  5 -
>  2 files changed, 1 insertion(+), 14 deletions(-)
>  delete mode 100644 usbutils.pc.in

This doesn't apply to the 009 version of usbutils, what did you make it
against?  Can you rebase against the latest tree and resend?

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

I NEED YOUR HELP URGENT

[Emily Alba]

I NEED YOUR HELP URGENT

It's my pleasure to have contact with you,based on the critical
condition I find mine self,though, it's not financial problem, but my
health,you might have know that cancer is not what to talk home
about,though I don't know you,and my contact with you was not by
mistake, but by devine favour of ALLAH.

I am married to Mr.ALBA KABORE NDAYI who worked with Tunisia embassy
in Burkina Faso for nine years before he died in the year 2008.We were
married for eleven years without a child. He died after a brief
illness that lasted for five days.

Since his death I decided not to remarry, When my late husband was
alive he deposited the sum of US$ 8.2m(Eight million two hundred
thousand dollars)in a bank in Ouagadougou the capital city of Burkina
Faso in west Africa Presently this money is still in bank. He made
this money available for exportation of Gold from Burkina Faso mining.
Recently, My Doctor told me that I don't have much time to live
because of the cancer problem,

Having known my condition I decided to hand you over this money to
take care of the less-privileged people, you will utilize this money
the way I am going to instruct herein. I want you to take 30 Percent
of the total money for your personal use While 70% of the money will
go to charity" people and helping the orphanage.


I don't want my husband's efforts to be used by the Gorvernment. I
grew up as an Orphan and I don't have anybody as my family member,
just to endeavour that the name of ALLAH is maintained. Am doing this
so that ALLAH will forgive my sins and accept my soul because this
sickness has suffered me so much.

As soon as I receive your reply I shall give you the contact of the
bank in Burkina Faso and I will send authority letter that will prove
you the present beneficiary of the money in the bank that is if you
assure me that you will act accordingly as I Stated herein. Hoping to
receive your reply

Regards,
Mrs. Emily Alba
written from Hospita
--
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

RFC: FT232H based FPGA configuration adapter drivers

[Anatolij Gustschin]

Hi,

I have to rework drivers for custom FT232H based FPGA configuration
adapters to make them suitable for including in mainline kernel. These
adapters should be usable via low-level drivers for FPGA Manager
framework. Two required low-level FPGA Manager drivers (for PS-SPI and
CvP configurations) are already in mainline. The missing parts are the
MPSSE SPI master driver (for attaching altera-ps-spi SPI devices) and
the FTDI FIFO FPP interface driver for FPGA Manager. I'm CCing the
relevant subsystem mailing lists and would like to get feedback to the
draft below before rewriting the missing driver parts.

A few words about our FPGA and FPGA configuration adapter hardware. We
have FPGA PCIe boards with two different FT232H based configuration
adapters. The first adapter type utilizes FT232H chip in MPSSE mode to
connect ADBUS SPI/GPIO pins to Stratix-V PS-SPI interface. Another
adapter type connects FT232H ADBUS (in FT245 FIFO mode) and two ACBUS
GPIOs to a CPLD, the CPLD is connected to the Arria-10 FPP interface.
Both FPGA boards are connected to the host via PCIe and USB (FT232H).

Below simplified diagram shows the drivers relationship used in the
first patch series [1] submitted to the FPGA and USB lists before
(this series didn't yet include the MPSSE SPI master driver).

   +-+
   | |
   |  STRATIX V  |PS-SPI FT245 FIFO & GPIO
   | +-++---+
   |  on Board 1 | ||   |
   | | ++---+
   |  PCIe   |   ADBUS   |  CPLD  |
   +---+-+ Connection Options  ++---+
   ^  (MPSSE or FIFO)  |
   |  |  +--+---+
  altera-cvp  +---+--+   | FPP  |
  |  |   |  |
  | FT232H 0x0403:0x6014 |   |   ARRIA 10   |
  |  |   |  |
  +--+---+   |  on Board 2  |
 |   |  |
  MFD drv +--+---+   |PCIe  |
  creates | ftdi-ft232h MFD drv  |   +--+---+
 platform |  USB bulk/ctrl xfer  |  ^
  devices +---+--+---+---+  |
   below  |  |   |  |
+-+  |   +-+++
|| | |
 +--+---+ +--+---+ +---+-+   |
 |ftdi-mpsse-spi| |ftdi-cbus-gpio| |ftdi-fifo-fpp-mgr|   |
 | platform dev | | platform dev | |  platform dev   |   |
 +---+--+ +--+---+ +-+---+   |
  platform   ^   ^   ^   |
   drivers:  +   +   |   |
 MPSSE SPI master  ACBUS GPIO Ctrl +-++--+
 ^   ^ |  |
 |   | +  +
   altera-ps-spi \uses   ftdi-fifo-fpp altera-cvp
FPGA Manager  --+ FPGA ManagerFPGA Manager
 ^^   ^
 ||   |
 +-+  +  ++
   fpga-mgr

The first FTDI FPP adapter driver patch series has some fundamental
issues as discussed on the lists and I plan to rework the FT232H
specific parts to prepare a new patch series. We have already
reserved custom PIDs for both adapter types and can use them in
adapter EEPROMs to ensure binding to the vendor specific drivers
for SPI and FIFO FPP types.

Instead of MFD part as in previous version I intend to add an USB misc
driver for our FPGA configuration adapters under drivers/usb/misc.
When probing for VID/PID assigned to FIFO-FPP adapter type, this
driver will register CBUS GPIO controller, GPIO lookup tables for
FIFO FPP device and will create a platform device for attaching the
low-level FPGA manager driver for FIFO FPP interface. The attached
FPGA manager driver will be similar to the ftdi-fifo-fpp driver and
will reside in drivers/fpga. When probing for VID/PID assigned to
MPSSE SPI adapter type, the USB misc driver will register MPSSE GPIO
controller, GPIO lookup tables for altera-ps-spi control/status GPIOs
and will create platform device for attaching MPSSE SPI master
controller driver. The SPI master controller platform driver will
register MPSSE SPI bus with SPI slave device from spi_board_info
struct in its platform data (in our case altera-ps-spi SPI slave
device for attaching altera-ps-spi driver). The intended location
of this custom SPI master controller driver is drivers/spi.

Below simplified diagram shows the intended device and drivers
relationship for reworking the adapter drivers.

   +-+
   | |
   |  

[PATCH 4.9 023/109] usb: dwc2: Error out of dwc2_hsotg_ep_disable() if were in host mode

[Greg Kroah-Hartman]

4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: John Stultz 


[ Upstream commit 9b481092c2a31a6b630aff9c28f0145bf6683787 ]

We've found that while in host mode, using Android, if one runs
the command:
  stop adbd

The existing usb devices being utilized in host mode are disconnected.
This is most visible with usb networking devices.

This seems to be due to adbd closing the file:
  /dev/usb-ffs/adb/ep0
Which calls ffs_ep0_release() and the following backtrace:

[] dwc2_hsotg_ep_disable+0x148/0x150
[] dwc2_hsotg_udc_stop+0x60/0x110
[] usb_gadget_remove_driver+0x58/0x78
[] usb_gadget_unregister_driver+0x74/0xe8
[] unregister_gadget+0x28/0x58
[] unregister_gadget_item+0x2c/0x40
[] ffs_data_clear+0xe8/0xf8
[] ffs_data_reset+0x20/0x58
[] ffs_data_closed+0x98/0xe8
[] ffs_ep0_release+0x20/0x30

Then when dwc2_hsotg_ep_disable() is called, we call
kill_all_requests() which causes a bunch of the following
messages:

dwc2 f72c.usb: Mode Mismatch Interrupt: currently in Host mode
dwc2 f72c.usb: Mode Mismatch Interrupt: currently in Host mode
dwc2 f72c.usb: Mode Mismatch Interrupt: currently in Host mode
dwc2 f72c.usb: Mode Mismatch Interrupt: currently in Host mode
dwc2 f72c.usb: Mode Mismatch Interrupt: currently in Host mode
dwc2 f72c.usb: Mode Mismatch Interrupt: currently in Host mode
dwc2 f72c.usb: Mode Mismatch Interrupt: currently in Host mode
dwc2 f72c.usb: Mode Mismatch Interrupt: currently in Host mode
init: Service 'adbd' (pid 1915) killed by signal 9
init: Sending signal 9 to service 'adbd' (pid 1915) process group...
init: Successfully killed process cgroup uid 0 pid 1915 in 0ms
init: processing action (init.svc.adbd=stopped) from (/init.usb.configfs.rc:15)
dwc2 f72c.usb: dwc2_hc_chhltd_intr_dma: Channel 8 - ChHltd set, but reason 
is unknown
dwc2 f72c.usb: hcint 0x0002, intsts 0x04200029
dwc2 f72c.usb: dwc2_hc_chhltd_intr_dma: Channel 12 - ChHltd set, but reason 
is unknown
dwc2 f72c.usb: hcint 0x0002, intsts 0x04200029
dwc2 f72c.usb: dwc2_hc_chhltd_intr_dma: Channel 15 - ChHltd set, but reason 
is unknown
dwc2 f72c.usb: hcint 0x0002, intsts 0x04200029
dwc2 f72c.usb: dwc2_hc_chhltd_intr_dma: Channel 3 - ChHltd set, but reason 
is unknown
dwc2 f72c.usb: hcint 0x0002, intsts 0x04200029
dwc2 f72c.usb: dwc2_hc_chhltd_intr_dma: Channel 4 - ChHltd set, but reason 
is unknown
dwc2 f72c.usb: hcint 0x0002, intsts 0x04200029
dwc2 f72c.usb: dwc2_update_urb_state_abn(): trimming xfer length

And the usb devices connected are basically hung at this point.

It seems like if we're in host mode, we probably shouldn't run
the dwc2_hostg_ep_disable logic, so this patch returns an error
in that case.

With this patch (along with the previous patch in this set), we avoid
the mismatched interrupts and connected usb devices continue to function.

I'm not sure if some other solution would be better here, but this seems
to work, so I wanted to send it out for input on what the right approach
should be.

Cc: Wei Xu 
Cc: Guodong Xu 
Cc: Amit Pundir 
Cc: YongQin Liu 
Cc: John Youn 
Cc: Minas Harutyunyan 
Cc: Douglas Anderson 
Cc: Chen Yu 
Cc: Felipe Balbi 
Cc: Greg Kroah-Hartman 
Cc: linux-usb@vger.kernel.org
Acked-by: Minas Harutyunyan 
Tested-by: Minas Harutyunyan 
Reported-by: YongQin Liu 
Signed-off-by: John Stultz 
Signed-off-by: Felipe Balbi 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/usb/dwc2/gadget.c |5 +
 1 file changed, 5 insertions(+)

--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -3117,6 +3117,11 @@ static int dwc2_hsotg_ep_disable(struct
return -EINVAL;
}
 
+   if (hsotg->op_state != OTG_STATE_B_PERIPHERAL) {
+   dev_err(hsotg->dev, "%s: called in host mode?\n", __func__);
+   return -EINVAL;
+   }
+
epctrl_reg = dir_in ? DIEPCTL(index) : DOEPCTL(index);
 
spin_lock_irqsave(>lock, flags);


--
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 4.9 022/109] usb: dwc2: Fix UDC state tracking

[Greg Kroah-Hartman]

4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: John Stultz 


[ Upstream commit ce2b21a4e5ce042c0a42c9db8fa9e0f849427d5e ]

It has been noticed that the dwc2 udc state reporting doesn't
seem to work (at least on HiKey boards). Where after the initial
setup, the sysfs /sys/class/udc/f72c.usb/state file would
report "configured" no matter the state of the OTG port.

This patch adds a call so that we report to the UDC layer when
the gadget device is disconnected.

This patch does depend on the previous patch ("usb: dwc2:
Improve gadget state disconnection handling") in this patch set
in order to properly work.

Cc: Wei Xu 
Cc: Guodong Xu 
Cc: Amit Pundir 
Cc: YongQin Liu 
Cc: John Youn 
Cc: Minas Harutyunyan 
Cc: Douglas Anderson 
Cc: Chen Yu 
Cc: Felipe Balbi 
Cc: Greg Kroah-Hartman 
Cc: linux-usb@vger.kernel.org
Acked-by: Minas Harutyunyan 
Tested-by: Minas Harutyunyan 
Reported-by: Amit Pundir 
Signed-off-by: John Stultz 
Signed-off-by: Felipe Balbi 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/usb/dwc2/gadget.c |2 ++
 1 file changed, 2 insertions(+)

--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -2467,6 +2467,8 @@ void dwc2_hsotg_disconnect(struct dwc2_h
 
call_gadget(hsotg, disconnect);
hsotg->lx_state = DWC2_L3;
+
+   usb_gadget_set_state(>gadget, USB_STATE_NOTATTACHED);
 }
 
 /**


--
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 4.4 13/49] usb: dwc2: Fix UDC state tracking

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: John Stultz 


[ Upstream commit ce2b21a4e5ce042c0a42c9db8fa9e0f849427d5e ]

It has been noticed that the dwc2 udc state reporting doesn't
seem to work (at least on HiKey boards). Where after the initial
setup, the sysfs /sys/class/udc/f72c.usb/state file would
report "configured" no matter the state of the OTG port.

This patch adds a call so that we report to the UDC layer when
the gadget device is disconnected.

This patch does depend on the previous patch ("usb: dwc2:
Improve gadget state disconnection handling") in this patch set
in order to properly work.

Cc: Wei Xu 
Cc: Guodong Xu 
Cc: Amit Pundir 
Cc: YongQin Liu 
Cc: John Youn 
Cc: Minas Harutyunyan 
Cc: Douglas Anderson 
Cc: Chen Yu 
Cc: Felipe Balbi 
Cc: Greg Kroah-Hartman 
Cc: linux-usb@vger.kernel.org
Acked-by: Minas Harutyunyan 
Tested-by: Minas Harutyunyan 
Reported-by: Amit Pundir 
Signed-off-by: John Stultz 
Signed-off-by: Felipe Balbi 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/usb/dwc2/gadget.c |2 ++
 1 file changed, 2 insertions(+)

--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -2206,6 +2206,8 @@ void dwc2_hsotg_disconnect(struct dwc2_h
 
call_gadget(hsotg, disconnect);
hsotg->lx_state = DWC2_L3;
+
+   usb_gadget_set_state(>gadget, USB_STATE_NOTATTACHED);
 }
 
 /**


--
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 4.4 14/49] usb: dwc2: Error out of dwc2_hsotg_ep_disable() if were in host mode

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: John Stultz 


[ Upstream commit 9b481092c2a31a6b630aff9c28f0145bf6683787 ]

We've found that while in host mode, using Android, if one runs
the command:
  stop adbd

The existing usb devices being utilized in host mode are disconnected.
This is most visible with usb networking devices.

This seems to be due to adbd closing the file:
  /dev/usb-ffs/adb/ep0
Which calls ffs_ep0_release() and the following backtrace:

[] dwc2_hsotg_ep_disable+0x148/0x150
[] dwc2_hsotg_udc_stop+0x60/0x110
[] usb_gadget_remove_driver+0x58/0x78
[] usb_gadget_unregister_driver+0x74/0xe8
[] unregister_gadget+0x28/0x58
[] unregister_gadget_item+0x2c/0x40
[] ffs_data_clear+0xe8/0xf8
[] ffs_data_reset+0x20/0x58
[] ffs_data_closed+0x98/0xe8
[] ffs_ep0_release+0x20/0x30

Then when dwc2_hsotg_ep_disable() is called, we call
kill_all_requests() which causes a bunch of the following
messages:

dwc2 f72c.usb: Mode Mismatch Interrupt: currently in Host mode
dwc2 f72c.usb: Mode Mismatch Interrupt: currently in Host mode
dwc2 f72c.usb: Mode Mismatch Interrupt: currently in Host mode
dwc2 f72c.usb: Mode Mismatch Interrupt: currently in Host mode
dwc2 f72c.usb: Mode Mismatch Interrupt: currently in Host mode
dwc2 f72c.usb: Mode Mismatch Interrupt: currently in Host mode
dwc2 f72c.usb: Mode Mismatch Interrupt: currently in Host mode
dwc2 f72c.usb: Mode Mismatch Interrupt: currently in Host mode
init: Service 'adbd' (pid 1915) killed by signal 9
init: Sending signal 9 to service 'adbd' (pid 1915) process group...
init: Successfully killed process cgroup uid 0 pid 1915 in 0ms
init: processing action (init.svc.adbd=stopped) from (/init.usb.configfs.rc:15)
dwc2 f72c.usb: dwc2_hc_chhltd_intr_dma: Channel 8 - ChHltd set, but reason 
is unknown
dwc2 f72c.usb: hcint 0x0002, intsts 0x04200029
dwc2 f72c.usb: dwc2_hc_chhltd_intr_dma: Channel 12 - ChHltd set, but reason 
is unknown
dwc2 f72c.usb: hcint 0x0002, intsts 0x04200029
dwc2 f72c.usb: dwc2_hc_chhltd_intr_dma: Channel 15 - ChHltd set, but reason 
is unknown
dwc2 f72c.usb: hcint 0x0002, intsts 0x04200029
dwc2 f72c.usb: dwc2_hc_chhltd_intr_dma: Channel 3 - ChHltd set, but reason 
is unknown
dwc2 f72c.usb: hcint 0x0002, intsts 0x04200029
dwc2 f72c.usb: dwc2_hc_chhltd_intr_dma: Channel 4 - ChHltd set, but reason 
is unknown
dwc2 f72c.usb: hcint 0x0002, intsts 0x04200029
dwc2 f72c.usb: dwc2_update_urb_state_abn(): trimming xfer length

And the usb devices connected are basically hung at this point.

It seems like if we're in host mode, we probably shouldn't run
the dwc2_hostg_ep_disable logic, so this patch returns an error
in that case.

With this patch (along with the previous patch in this set), we avoid
the mismatched interrupts and connected usb devices continue to function.

I'm not sure if some other solution would be better here, but this seems
to work, so I wanted to send it out for input on what the right approach
should be.

Cc: Wei Xu 
Cc: Guodong Xu 
Cc: Amit Pundir 
Cc: YongQin Liu 
Cc: John Youn 
Cc: Minas Harutyunyan 
Cc: Douglas Anderson 
Cc: Chen Yu 
Cc: Felipe Balbi 
Cc: Greg Kroah-Hartman 
Cc: linux-usb@vger.kernel.org
Acked-by: Minas Harutyunyan 
Tested-by: Minas Harutyunyan 
Reported-by: YongQin Liu 
Signed-off-by: John Stultz 
Signed-off-by: Felipe Balbi 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/usb/dwc2/gadget.c |5 +
 1 file changed, 5 insertions(+)

--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -2834,6 +2834,11 @@ static int dwc2_hsotg_ep_disable(struct
return -EINVAL;
}
 
+   if (hsotg->op_state != OTG_STATE_B_PERIPHERAL) {
+   dev_err(hsotg->dev, "%s: called in host mode?\n", __func__);
+   return -EINVAL;
+   }
+
epctrl_reg = dir_in ? DIEPCTL(index) : DOEPCTL(index);
 
spin_lock_irqsave(>lock, flags);


--
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: hub: Delete an error message for a failed memory allocation in usb_hub_clear_tt_buffer()

[SF Markus Elfring]

 OOM does a dump_stack() so this function's call tree is shown.
>>>
>>> A call stack doesn't tell you which device was being handled.
>>
>> Do you find a default Linux allocation failure report insufficient then?
>>
>> Would you like to to achieve that the requested information can be determined
>> from a backtrace?
> 
> It is not practical to do this.

I imagine that this depends on details if a backtrace could eventually
be configured for your specific needs.


> The memory allocation routines do not for what purpose
> the memory is being allocated;

Do you want an improved accounting for these purposes?


> hence when a failure occurs they cannot tell what device
> (or other part of the system) will be affected.

I know that other programs can provide dumps for function call
stacks where the parameters which were passed in previous calls
could be decoded to some degree.


> That's why we have a secondary error message.

I am curious on how the relevance of such messages will be interpreted
by other developers in this software area.

Regards,
Markus
--
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 4.14 32/75] usb: dwc2: Fix UDC state tracking

[Greg Kroah-Hartman]

4.14-stable review patch.  If anyone has any objections, please let me know.

--

From: John Stultz 


[ Upstream commit ce2b21a4e5ce042c0a42c9db8fa9e0f849427d5e ]

It has been noticed that the dwc2 udc state reporting doesn't
seem to work (at least on HiKey boards). Where after the initial
setup, the sysfs /sys/class/udc/f72c.usb/state file would
report "configured" no matter the state of the OTG port.

This patch adds a call so that we report to the UDC layer when
the gadget device is disconnected.

This patch does depend on the previous patch ("usb: dwc2:
Improve gadget state disconnection handling") in this patch set
in order to properly work.

Cc: Wei Xu 
Cc: Guodong Xu 
Cc: Amit Pundir 
Cc: YongQin Liu 
Cc: John Youn 
Cc: Minas Harutyunyan 
Cc: Douglas Anderson 
Cc: Chen Yu 
Cc: Felipe Balbi 
Cc: Greg Kroah-Hartman 
Cc: linux-usb@vger.kernel.org
Acked-by: Minas Harutyunyan 
Tested-by: Minas Harutyunyan 
Reported-by: Amit Pundir 
Signed-off-by: John Stultz 
Signed-off-by: Felipe Balbi 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/usb/dwc2/gadget.c |2 ++
 1 file changed, 2 insertions(+)

--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -3202,6 +3202,8 @@ void dwc2_hsotg_disconnect(struct dwc2_h
 
call_gadget(hsotg, disconnect);
hsotg->lx_state = DWC2_L3;
+
+   usb_gadget_set_state(>gadget, USB_STATE_NOTATTACHED);
 }
 
 /**


--
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 4.14 33/75] usb: dwc2: Error out of dwc2_hsotg_ep_disable() if were in host mode

[Greg Kroah-Hartman]

4.14-stable review patch.  If anyone has any objections, please let me know.

--

From: John Stultz 


[ Upstream commit 9b481092c2a31a6b630aff9c28f0145bf6683787 ]

We've found that while in host mode, using Android, if one runs
the command:
  stop adbd

The existing usb devices being utilized in host mode are disconnected.
This is most visible with usb networking devices.

This seems to be due to adbd closing the file:
  /dev/usb-ffs/adb/ep0
Which calls ffs_ep0_release() and the following backtrace:

[] dwc2_hsotg_ep_disable+0x148/0x150
[] dwc2_hsotg_udc_stop+0x60/0x110
[] usb_gadget_remove_driver+0x58/0x78
[] usb_gadget_unregister_driver+0x74/0xe8
[] unregister_gadget+0x28/0x58
[] unregister_gadget_item+0x2c/0x40
[] ffs_data_clear+0xe8/0xf8
[] ffs_data_reset+0x20/0x58
[] ffs_data_closed+0x98/0xe8
[] ffs_ep0_release+0x20/0x30

Then when dwc2_hsotg_ep_disable() is called, we call
kill_all_requests() which causes a bunch of the following
messages:

dwc2 f72c.usb: Mode Mismatch Interrupt: currently in Host mode
dwc2 f72c.usb: Mode Mismatch Interrupt: currently in Host mode
dwc2 f72c.usb: Mode Mismatch Interrupt: currently in Host mode
dwc2 f72c.usb: Mode Mismatch Interrupt: currently in Host mode
dwc2 f72c.usb: Mode Mismatch Interrupt: currently in Host mode
dwc2 f72c.usb: Mode Mismatch Interrupt: currently in Host mode
dwc2 f72c.usb: Mode Mismatch Interrupt: currently in Host mode
dwc2 f72c.usb: Mode Mismatch Interrupt: currently in Host mode
init: Service 'adbd' (pid 1915) killed by signal 9
init: Sending signal 9 to service 'adbd' (pid 1915) process group...
init: Successfully killed process cgroup uid 0 pid 1915 in 0ms
init: processing action (init.svc.adbd=stopped) from (/init.usb.configfs.rc:15)
dwc2 f72c.usb: dwc2_hc_chhltd_intr_dma: Channel 8 - ChHltd set, but reason 
is unknown
dwc2 f72c.usb: hcint 0x0002, intsts 0x04200029
dwc2 f72c.usb: dwc2_hc_chhltd_intr_dma: Channel 12 - ChHltd set, but reason 
is unknown
dwc2 f72c.usb: hcint 0x0002, intsts 0x04200029
dwc2 f72c.usb: dwc2_hc_chhltd_intr_dma: Channel 15 - ChHltd set, but reason 
is unknown
dwc2 f72c.usb: hcint 0x0002, intsts 0x04200029
dwc2 f72c.usb: dwc2_hc_chhltd_intr_dma: Channel 3 - ChHltd set, but reason 
is unknown
dwc2 f72c.usb: hcint 0x0002, intsts 0x04200029
dwc2 f72c.usb: dwc2_hc_chhltd_intr_dma: Channel 4 - ChHltd set, but reason 
is unknown
dwc2 f72c.usb: hcint 0x0002, intsts 0x04200029
dwc2 f72c.usb: dwc2_update_urb_state_abn(): trimming xfer length

And the usb devices connected are basically hung at this point.

It seems like if we're in host mode, we probably shouldn't run
the dwc2_hostg_ep_disable logic, so this patch returns an error
in that case.

With this patch (along with the previous patch in this set), we avoid
the mismatched interrupts and connected usb devices continue to function.

I'm not sure if some other solution would be better here, but this seems
to work, so I wanted to send it out for input on what the right approach
should be.

Cc: Wei Xu 
Cc: Guodong Xu 
Cc: Amit Pundir 
Cc: YongQin Liu 
Cc: John Youn 
Cc: Minas Harutyunyan 
Cc: Douglas Anderson 
Cc: Chen Yu 
Cc: Felipe Balbi 
Cc: Greg Kroah-Hartman 
Cc: linux-usb@vger.kernel.org
Acked-by: Minas Harutyunyan 
Tested-by: Minas Harutyunyan 
Reported-by: YongQin Liu 
Signed-off-by: John Stultz 
Signed-off-by: Felipe Balbi 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/usb/dwc2/gadget.c |5 +
 1 file changed, 5 insertions(+)

--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -4006,6 +4006,11 @@ static int dwc2_hsotg_ep_disable(struct
return -EINVAL;
}
 
+   if (hsotg->op_state != OTG_STATE_B_PERIPHERAL) {
+   dev_err(hsotg->dev, "%s: called in host mode?\n", __func__);
+   return -EINVAL;
+   }
+
epctrl_reg = dir_in ? DIEPCTL(index) : DOEPCTL(index);
 
spin_lock_irqsave(>lock, flags);


--
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] usb-core: Fix potential null pointer dereference in xhci-debugfs.c

[Mathias Nyman]

On 07.12.2017 11:26, Alexander Kappner wrote:

Date: Wed, 6 Dec 2017 15:28:37 -0800
Subject: [PATCH] usb-core: Fix potential null pointer dereference in 
xhci-debugfs.c


(Added this as reply subject, please remember to send mail with proper subject)



My kernel crashed just after resuming from hibernate and starting usbmuxd
(a user-space daemon for iOS device pairing) with several USB devices
connected (dmesg attached).

Backtrace leads to:

0x8170465d is in xhci_debugfs_create_endpoint
(drivers/usb/host/xhci-debugfs.c:381).
376   int ep_index)
377 {
378 struct xhci_ep_priv *epriv;
379 struct xhci_slot_priv   *spriv = dev->debugfs_private;
380
381 if (spriv->eps[ep_index])
382 return;
383
384 epriv = kzalloc(sizeof(*epriv), GFP_KERNEL);
385 if (!epriv)

The read violation happens at address 0x40 and sizeof(struct
xhci_ep_priv)=0x40, so it seems ep_index is 1 and spriv is NULL here.



Thanks for reporting and debugging this, much appreciated.
 

spriv gets allocated in xhci_debugfs_create_slot:

...
priv = kzalloc(sizeof(*priv), GFP_KERNEL);
if (!priv)
 return;
...

There's no separate error path if this allocation fails, so we might be
left with NULL in priv. Subsequent users of priv thus need to check for
this NULL - so this is what the patch does.



I think we need to dig a bit deeper. It's good to check if spriv is valid
but there are probably other reasons than kzalloc failing.

Resume from hibernation will reset the xhci controller, reinitializing a lot.
It could be related.

-Mathias

(keeping rest of message as reference)


There might be other ways of triggering this null pointer dereference,
including when xhci_resume frees the device structures (e.g. after
returning from a hibernate), but I wasn't able to find or reproduce it.

[63953.758083] BUG: unable to handle kernel NULL pointer dereference at
0040
[63953.758090] IP: xhci_debugfs_create_endpoint+0x1d/0xa0
[63953.758091] PGD bb911d067 P4D bb911d067 PUD 10500ff067 PMD 0
[63953.758093] Oops:  [#1] PREEMPT SMP
[63953.758094] Modules linked in: ipheth tun nvidia_modeset(PO) iwlmvm
mac80211 iwlwifi nvidia(PO) btusb btrtl btbcm btintel bluetooth cfg80211
qmi_wwan ecdh_generic thinkpad_acpi rfkill
[63953.758103] CPU: 4 PID: 27091 Comm: usbmuxd Tainted: P   O
4.14.0.1-12769-g1deab8c #1
[63953.758104] Hardware name: LENOVO 20ENCTO1WW/20ENCTO1WW, BIOS N1EET62W
(1.35 ) 11/10/2016
[63953.758105] task: 8810527ba0c0 task.stack: c9000a8ec000
[63953.758107] RIP: 0010:xhci_debugfs_create_endpoint+0x1d/0xa0
[63953.758108] RSP: 0018:c9000a8efc80 EFLAGS: 00010206
[63953.758109] RAX:  RBX: 88105a71c000 RCX:
0003
[63953.758110] RDX: 0003 RSI: 880c0b57e000 RDI:
88105a71c238
[63953.758110] RBP: 0003 R08: 881063800600 R09:
0003
[63953.758111] R10: 88105a71c238 R11: 0001 R12:
0011
[63953.758112] R13: 0018 R14:  R15:

[63953.758113] FS:  7f0a77715700() GS:8810a3d0()
knlGS:
[63953.758114] CS:  0010 DS:  ES:  CR0: 80050033
[63953.758115] CR2: 0040 CR3: 0003f91a8006 CR4:
003606e0
[63953.758115] DR0:  DR1:  DR2:

[63953.758116] DR3:  DR6: fffe0ff0 DR7:
0400
[63953.758117] Call Trace:
[63953.758120]  xhci_add_endpoint+0x127/0x2b0
[63953.758123]  usb_hcd_alloc_bandwidth+0x1ad/0x300
[63953.758125]  usb_set_configuration+0x1c8/0x880
[63953.758128]  usbdev_do_ioctl+0xc41/0x1120
[63953.758130]  usbdev_ioctl+0xa/0x10
[63953.758151]  do_vfs_ioctl+0x8b/0x5c0
[63953.758153]  ? __fget+0x6c/0xb0
[63953.758155]  SyS_ioctl+0x76/0x90
[63953.758157]  do_syscall_64+0x6b/0x290
[63953.758173]  entry_SYSCALL64_slow_path+0x25/0x25
[63953.758175] RIP: 0033:0x7f0a76a151c7
[63953.758175] RSP: 002b:7ffd1431b0c8 EFLAGS: 0202 ORIG_RAX:
0010
[63953.758177] RAX: ffda RBX: 023239a0 RCX:
7f0a76a151c7
[63953.758178] RDX: 7ffd1431b0dc RSI: 80045505 RDI:
000e
[63953.758178] RBP: 023240c0 R08: 7ffd1431b008 R09:
0004
[63953.758179] R10: 7ffd1431aec0 R11: 0202 R12:
023240c0
[63953.758180] R13: 0001 R14: 0056 R15:
0038
[63953.758182] Code: e9 39 ff ff ff 66 0f 1f 84 00 00 00 00 00 0f 1f 44 00
00 41 57 41 56 41 55 41 54 55 48 63 ea 53 4c 8b b6 88 15 00 00 4d 8d 2c ee
<49> 83 7d 28 00 74 0b 5b 5d 41 5c 41 5d 41 5e 41 5f c3 48 8b 3d
[63953.758202] RIP: xhci_debugfs_create_endpoint+0x1d/0xa0 RSP:
c9000a8efc80
[63953.758203] CR2: 0040
[63953.758204] ---[ end trace 1f7ea9a959f02054 ]---

Signed-off-by: Alexander Kappner 
---
  

[PATCH 2/3] phy: phy-mtk-tphy: make shared banks optional for V1 TPHY

[Chunfeng Yun]

V1 TPHY for SATA doesn't have shared banks if it isn't shared
with PCIe or USB, so make it optional.

Signed-off-by: Chunfeng Yun 
---
 drivers/phy/mediatek/phy-mtk-tphy.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/phy/mediatek/phy-mtk-tphy.c 
b/drivers/phy/mediatek/phy-mtk-tphy.c
index 5d9d7f3..d99f79b1 100644
--- a/drivers/phy/mediatek/phy-mtk-tphy.c
+++ b/drivers/phy/mediatek/phy-mtk-tphy.c
@@ -1023,9 +1023,10 @@ static int mtk_tphy_probe(struct platform_device *pdev)
tphy->dev = dev;
platform_set_drvdata(pdev, tphy);
 
-   if (tphy->pdata->version == MTK_PHY_V1) {
+   sif_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+   /* SATA phy of V1 needn't it if not shared with PCIe or USB */
+   if (sif_res && tphy->pdata->version == MTK_PHY_V1) {
/* get banks shared by multiple phys */
-   sif_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
tphy->sif_base = devm_ioremap_resource(dev, sif_res);
if (IS_ERR(tphy->sif_base)) {
dev_err(dev, "failed to remap sif regs\n");
-- 
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 3/3] phy: phy-mtk-tphy: use of_device_get_match_data()

[Chunfeng Yun]

reduce the boilerplate code to get the specific data

Signed-off-by: Chunfeng Yun 
---
 drivers/phy/mediatek/phy-mtk-tphy.c | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/phy/mediatek/phy-mtk-tphy.c 
b/drivers/phy/mediatek/phy-mtk-tphy.c
index d99f79b1..bd26de3 100644
--- a/drivers/phy/mediatek/phy-mtk-tphy.c
+++ b/drivers/phy/mediatek/phy-mtk-tphy.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -995,7 +996,6 @@ static struct phy *mtk_phy_xlate(struct device *dev,
 
 static int mtk_tphy_probe(struct platform_device *pdev)
 {
-   const struct of_device_id *match;
struct device *dev = >dev;
struct device_node *np = dev->of_node;
struct device_node *child_np;
@@ -1005,15 +1005,14 @@ static int mtk_tphy_probe(struct platform_device *pdev)
struct resource res;
int port, retval;
 
-   match = of_match_node(mtk_tphy_id_table, pdev->dev.of_node);
-   if (!match)
-   return -EINVAL;
-
tphy = devm_kzalloc(dev, sizeof(*tphy), GFP_KERNEL);
if (!tphy)
return -ENOMEM;
 
-   tphy->pdata = match->data;
+   tphy->pdata = of_device_get_match_data(dev);
+   if (!tphy->pdata)
+   return -EINVAL;
+
tphy->nphys = of_get_child_count(np);
tphy->phys = devm_kcalloc(dev, tphy->nphys,
  sizeof(*tphy->phys), GFP_KERNEL);
-- 
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/3] phy: phy-mtk-tphy: use auto instead of force to bypass utmi signals

[Chunfeng Yun]

When system is running, if usb2 phy is forced to bypass utmi signals,
all PLL will be turned off, and it can't detect device connection
anymore, so replace force mode with auto mode which can bypass utmi
signals automatically if no device attached for normal flow.
But keep the force mode to fix RX sensitivity degradation issue.

Signed-off-by: Chunfeng Yun 
---
 drivers/phy/mediatek/phy-mtk-tphy.c | 19 +++
 1 file changed, 7 insertions(+), 12 deletions(-)

diff --git a/drivers/phy/mediatek/phy-mtk-tphy.c 
b/drivers/phy/mediatek/phy-mtk-tphy.c
index fb8aba4..5d9d7f3 100644
--- a/drivers/phy/mediatek/phy-mtk-tphy.c
+++ b/drivers/phy/mediatek/phy-mtk-tphy.c
@@ -440,9 +440,9 @@ static void u2_phy_instance_init(struct mtk_tphy *tphy,
u32 index = instance->index;
u32 tmp;
 
-   /* switch to USB function. (system register, force ip into usb mode) */
+   /* switch to USB function, and enable usb pll */
tmp = readl(com + U3P_U2PHYDTM0);
-   tmp &= ~P2C_FORCE_UART_EN;
+   tmp &= ~(P2C_FORCE_UART_EN | P2C_FORCE_SUSPENDM);
tmp |= P2C_RG_XCVRSEL_VAL(1) | P2C_RG_DATAIN_VAL(0);
writel(tmp, com + U3P_U2PHYDTM0);
 
@@ -502,10 +502,8 @@ static void u2_phy_instance_power_on(struct mtk_tphy *tphy,
u32 index = instance->index;
u32 tmp;
 
-   /* (force_suspendm=0) (let suspendm=1, enable usb 480MHz pll) */
tmp = readl(com + U3P_U2PHYDTM0);
-   tmp &= ~(P2C_FORCE_SUSPENDM | P2C_RG_XCVRSEL);
-   tmp &= ~(P2C_RG_DATAIN | P2C_DTM0_PART_MASK);
+   tmp &= ~(P2C_RG_XCVRSEL | P2C_RG_DATAIN | P2C_DTM0_PART_MASK);
writel(tmp, com + U3P_U2PHYDTM0);
 
/* OTG Enable */
@@ -540,7 +538,6 @@ static void u2_phy_instance_power_off(struct mtk_tphy *tphy,
 
tmp = readl(com + U3P_U2PHYDTM0);
tmp &= ~(P2C_RG_XCVRSEL | P2C_RG_DATAIN);
-   tmp |= P2C_FORCE_SUSPENDM;
writel(tmp, com + U3P_U2PHYDTM0);
 
/* OTG Disable */
@@ -548,18 +545,16 @@ static void u2_phy_instance_power_off(struct mtk_tphy 
*tphy,
tmp &= ~PA6_RG_U2_OTG_VBUSCMP_EN;
writel(tmp, com + U3P_USBPHYACR6);
 
-   /* let suspendm=0, set utmi into analog power down */
-   tmp = readl(com + U3P_U2PHYDTM0);
-   tmp &= ~P2C_RG_SUSPENDM;
-   writel(tmp, com + U3P_U2PHYDTM0);
-   udelay(1);
-
tmp = readl(com + U3P_U2PHYDTM1);
tmp &= ~(P2C_RG_VBUSVALID | P2C_RG_AVALID);
tmp |= P2C_RG_SESSEND;
writel(tmp, com + U3P_U2PHYDTM1);
 
if (tphy->pdata->avoid_rx_sen_degradation && index) {
+   tmp = readl(com + U3P_U2PHYDTM0);
+   tmp &= ~(P2C_RG_SUSPENDM | P2C_FORCE_SUSPENDM);
+   writel(tmp, com + U3P_U2PHYDTM0);
+
tmp = readl(com + U3D_U2PHYDCR0);
tmp &= ~P2C_RG_SIF_U2PLL_FORCE_ON;
writel(tmp, com + U3D_U2PHYDCR0);
-- 
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: [PATCH 0/1] USB Audio Device Class 3.0 Gadget support

[Ruslan Bilovol]

Hi Felipe,

On Mon, Dec 4, 2017 at 1:36 PM, Felipe Balbi  wrote:
>
> Hi,
>
> Ruslan Bilovol  writes:
>> On Tue, Nov 7, 2017 at 3:52 AM, Ruslan Bilovol  
>> wrote:
>>> Hi,
>>>
>>> This patch adds USB Audio Device Class 3.0 [1] function
>>> support to gadget subsystem.
>>> I didn't add UAC3 support to legacy gadget as it will
>>> make preprocessor configuration too complex (UAC3 device
>>> must have two configurations for backward compatibility,
>>> first is UAC1/2 and second is UAC3), yet also I'm too lazy
>>> to do that and verify all possible configurations.
>>>
>>> For modern ConfigFS interface I'll provide my configuration
>>> for testing below; testing was done on a BeagleBone Black
>>> board.
>>>
>>> This patch depends on uac3 header files from include dir
>>> which I'll post as part of ALSA host UAC3 patch and will
>>> provide the link to it here.
>>
>> http://www.spinics.net/lists/alsa-devel/msg69071.html
>
> Once that patch hits upstream, then we can queue this for merge window
> otherwise we will just have issues and create unbisectable points in the
> tree.

Takashi promised to create an immutable branch for that purpose.

However, I'm currently reworking configfs part of UAC3 for channels
configuration handling, which is now more clear after sharing missing
parts of UAC3 spec by Pierre-Louis Bossart during host side patches
review; so I will send v2 soon.

Thanks,
Ruslan
--
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: dwc3: of-simple: fix missing clk_disable_unprepare

[Andreas Platschek]

If of_clk_get() fails, the clean-up of already initialized clocks should be
the same as when clk_prepare_enable() fails. Thus a clk_disable_unprepare()
for each clock should be called before the clk_put().

Found by Linux Driver Verification project (linuxtesting.org).

Fixes: 16adc674d0d6 ("usb: dwc3: ep0: fix setup_packet_pending initialization")

Signed-off-by: Andreas Platschek 
---
NOTE: This was only compile-tested

 drivers/usb/dwc3/dwc3-of-simple.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/dwc3/dwc3-of-simple.c 
b/drivers/usb/dwc3/dwc3-of-simple.c
index c4a4d7bd2766..762370dd7c75 100644
--- a/drivers/usb/dwc3/dwc3-of-simple.c
+++ b/drivers/usb/dwc3/dwc3-of-simple.c
@@ -51,8 +51,10 @@ static int dwc3_of_simple_clk_init(struct dwc3_of_simple 
*simple, int count)
 
clk = of_clk_get(np, i);
if (IS_ERR(clk)) {
-   while (--i >= 0)
+   while (--i >= 0) {
+   clk_disable_unprepare(simple->clks[i]);
clk_put(simple->clks[i]);
+   }
return PTR_ERR(clk);
}
 
-- 
2.11.0

--
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: your mail

[Greg Kroah-Hartman]

On Thu, Dec 07, 2017 at 01:26:14AM -0800, Alexander Kappner wrote:
> Date: Wed, 6 Dec 2017 15:28:37 -0800
> Subject: [PATCH] usb-core: Fix potential null pointer dereference in 
> xhci-debugfs.c

Something went wrong here, resulting in an email with no subject.

Can you fix this up and resend?

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

[PATCH v2 8/8] lsusb: Dump USB3 BOS Configuration Summary Descriptor.

[Michael Drake]

Add support for dumping the configuration summary device capability
descriptor to the verbose output of lsusb.

Signed-off-by: Michael Drake 
---
 lsusb.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/lsusb.c b/lsusb.c
index e3eb423..c7a237e 100644
--- a/lsusb.c
+++ b/lsusb.c
@@ -75,6 +75,7 @@
 #define USB_DC_PLATFORM0x05
 #define USB_DC_SUPERSPEEDPLUS  0x0a
 #define USB_DC_BILLBOARD   0x0d
+#define USB_DC_CONFIGURATION_SUMMARY   0x10
 
 /* Conventional codes for class-specific descriptors.  The convention is
  * defined in the USB "Common Class" Spec (3.11).  Individual class specs
@@ -3517,6 +3518,11 @@ static void dump_bos_descriptor(libusb_device_handle *fd)
case USB_DC_BILLBOARD:
dump_billboard_device_capability_desc(fd, buf);
break;
+   case USB_DC_CONFIGURATION_SUMMARY:
+   printf("  Configuration Summary Device Capability:\n");
+   desc_dump(fd, desc_usb3_dc_configuration_summary,
+   buf, DESC_BUF_LEN_FROM_BUF, 2);
+   break;
default:
printf("  ** UNRECOGNIZED: ");
dump_bytes(buf, buf[0]);
-- 
2.11.0

--
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 v2 7/8] lsusb: Add descriptor definition for USB3 BOS Configuration Summary.

[Michael Drake]

Add definition of the BOS configuration summary descriptor, as
specified by the USB 3 standard, to the descriptor definitions
for lsusb.

Signed-off-by: Michael Drake 
---
 desc-defs.c | 15 +++
 desc-defs.h |  3 +++
 2 files changed, 18 insertions(+)

diff --git a/desc-defs.c b/desc-defs.c
index 590f34a..9d3e312 100644
--- a/desc-defs.c
+++ b/desc-defs.c
@@ -978,3 +978,18 @@ const struct desc * const 
desc_audio_as_isochronous_audio_data_endpoint[3] = {
desc_audio_2_as_isochronous_audio_data_endpoint,
desc_audio_3_as_isochronous_audio_data_endpoint,
 };
+
+/** USB3: 9.6.2.7 Configuration Summary Descriptor; Table 9-21. */
+const struct desc desc_usb3_dc_configuration_summary[] = {
+   { .field = "bLength", .size = 1, .type = DESC_NUMBER },
+   { .field = "bDescriptorType", .size = 1, .type = DESC_CONSTANT },
+   { .field = "bDevCapabilityType",  .size = 1, .type = DESC_NUMBER },
+   { .field = "bcdVersion",  .size = 2, .type = DESC_BCD },
+   { .field = "bClass",  .size = 1, .type = DESC_NUMBER },
+   { .field = "bSubClass",   .size = 1, .type = DESC_NUMBER },
+   { .field = "bProtocol",   .size = 1, .type = DESC_NUMBER },
+   { .field = "bConfigurationCount", .size = 1, .type = DESC_NUMBER },
+   { .field = "bConfigurationIndex", .size = 1, .type = DESC_NUMBER,
+   .array = { .array = true, .length_field1 = 
"bConfigurationCount" } },
+   { .field = NULL }
+};
diff --git a/desc-defs.h b/desc-defs.h
index d88ebd8..2c8f1b3 100644
--- a/desc-defs.h
+++ b/desc-defs.h
@@ -151,6 +151,9 @@ extern const struct desc * const 
desc_audio_ac_sample_rate_converter[3];
 extern const struct desc * const desc_audio_as_interface[3];
 extern const struct desc * const 
desc_audio_as_isochronous_audio_data_endpoint[3];
 
+/* Device Capability (DC) descriptor definitions */
+extern const struct desc desc_usb3_dc_configuration_summary[];
+
 /* -- */
 
 #endif /* _DESC_DEFS_H */
-- 
2.11.0

--
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 v2 5/8] lsusb: Add descriptor definitions for UAC3.

[Michael Drake]

These descriptor definitions descibe how raw descriptor data
should be interpreted.

Signed-off-by: Michael Drake 
---
 desc-defs.c | 338 
 desc-defs.h |   3 +
 desc-dump.c |   5 +
 3 files changed, 303 insertions(+), 43 deletions(-)

diff --git a/desc-defs.c b/desc-defs.c
index a01aae2..590f34a 100644
--- a/desc-defs.c
+++ b/desc-defs.c
@@ -79,11 +79,20 @@ static const struct desc desc_audio_2_ac_header[] = {
{ .field = NULL }
 };
 
+/** UAC3: 4.5.2 Class-Specific AC Interface Descriptor; Table 4-15. */
+static const struct desc desc_audio_3_ac_header[] = {
+   { .field = "bCategory",.size = 1, .type = DESC_CONSTANT },
+   { .field = "wTotalLength", .size = 2, .type = DESC_NUMBER },
+   { .field = "bmControls",   .size = 4, .type = DESC_BMCONTROL_2,
+   .bmcontrol = uac2_interface_header_bmcontrols },
+   { .field = NULL }
+};
+
 /** AudioControl Header descriptor definitions for the three Audio Device 
Class protocols */
 const struct desc * const desc_audio_ac_header[3] = {
desc_audio_1_ac_header,
desc_audio_2_ac_header,
-   NULL, /* UAC3 not implemented yet */
+   desc_audio_3_ac_header,
 };
 
 /** UAC2: 4.7.2.10 Effect Unit Descriptor; Table 4-15. */
@@ -97,11 +106,22 @@ static const struct desc desc_audio_2_ac_effect_unit[] = {
{ .field = NULL }
 };
 
+/** UAC3: 4.5.2.9 Effect Unit Descriptor; Table 4-33. */
+static const struct desc desc_audio_3_ac_effect_unit[] = {
+   { .field = "bUnitID",  .size = 1, .type = DESC_NUMBER },
+   { .field = "wEffectType",  .size = 2, .type = DESC_CONSTANT },
+   { .field = "bSourceID",.size = 1, .type = DESC_CONSTANT },
+   { .field = "bmaControls",  .size = 4, .type = DESC_BITMAP,
+   .array = { .array = true } },
+   { .field = "wEffectsDescrStr", .size = 2, .type = DESC_CS_STR_DESC_ID },
+   { .field = NULL }
+};
+
 /** Effect Unit descriptor definitions for the three Audio Device Class 
protocols */
 const struct desc * const desc_audio_ac_effect_unit[3] = {
NULL, /* UAC1 not supported */
desc_audio_2_ac_effect_unit,
-   NULL, /* UAC3 not implemented yet */
+   desc_audio_3_ac_effect_unit,
 };
 
 /** UAC2 Input Terminal bmControls; Human readable bit meanings. */
@@ -115,6 +135,16 @@ static const char * const uac2_input_term_bmcontrols[] = {
[6] = NULL
 };
 
+/** UAC3 Input Terminal bmControls; Human readable bit meanings. */
+static const char * const uac3_input_term_bmcontrols[] = {
+   [0] = "Insertion",
+   [1] = "Overload",
+   [2] = "Underflow",
+   [3] = "Overflow",
+   [4] = "Underflow",
+   [5] = NULL
+};
+
 /** UAC1: 4.3.2.1 Input Terminal Descriptor; Table 4-3. */
 static const struct desc desc_audio_1_ac_input_terminal[] = {
{ .field = "bTerminalID",.size = 1, .type = DESC_NUMBER },
@@ -144,11 +174,26 @@ static const struct desc desc_audio_2_ac_input_terminal[] 
= {
{ .field = NULL }
 };
 
+/** UAC3: 4.5.2.1 Input Terminal Descriptor; Table 4-16. */
+static const struct desc desc_audio_3_ac_input_terminal[] = {
+   { .field = "bTerminalID",.size = 1, .type = DESC_NUMBER },
+   { .field = "wTerminalType",  .size = 2, .type = DESC_TERMINAL_STR },
+   { .field = "bAssocTerminal", .size = 1, .type = DESC_NUMBER },
+   { .field = "bCSourceID", .size = 1, .type = DESC_NUMBER },
+   { .field = "bmControls", .size = 4, .type = DESC_BMCONTROL_2,
+   .bmcontrol = uac3_input_term_bmcontrols },
+   { .field = "wClusterDescrID",.size = 2, .type = DESC_NUMBER },
+   { .field = "wExTerminalDescrID", .size = 2, .type = DESC_NUMBER },
+   { .field = "wConnectorsDescrID", .size = 2, .type = DESC_NUMBER },
+   { .field = "wTerminalDescrStr",  .size = 2, .type = DESC_CS_STR_DESC_ID 
},
+   { .field = NULL }
+};
+
 /** Input Terminal descriptor definitions for the three Audio Device Class 
protocols */
 const struct desc * const desc_audio_ac_input_terminal[3] = {
desc_audio_1_ac_input_terminal,
desc_audio_2_ac_input_terminal,
-   NULL, /* UAC3 not implemented yet */
+   desc_audio_3_ac_input_terminal,
 };
 
 /** UAC2 Output Terminal bmControls; Human readable bit meanings. */
@@ -161,6 +206,15 @@ static const char * const uac2_output_term_bmcontrols[] = {
[5] = NULL
 };
 
+/** UAC3 Output Terminal bmControls; Human readable bit meanings. */
+static const char * const uac3_output_term_bmcontrols[] = {
+   [0] = "Insertion",
+   [1] = "Overload",
+   [2] = "Underflow",
+   [3] = "Overflow",
+   [4] = NULL
+};
+
 /** UAC1: 4.3.2.2 Output Terminal Descriptor; Table 4-4. */
 static const struct desc desc_audio_1_ac_output_terminal[] = {
{ .field = "bTerminalID",.size = 1, .type = DESC_NUMBER },
@@ -184,11 

[PATCH v2 3/8] lsusb: Add code to dump descriptor data using descriptor definition.

[Michael Drake]

This adds a new way of dumping descriptors.  It takes the descriptor
data to be dumped, and a descriptor definition as input.

The descriptor definition takes the form of a NULL terminated array
of descriptor field definitions.

These definitions describe how the raw descriptor data buffer should
be interpreted.

Thus the knowledge of how to interpret a descriptor buffer is separate
from the shared code that renders the descriptor dump.  This has two
advantages:

1. The code for dumping descriptors is common, so the output is easy
   to keep consistent.  It is also consistent and thorough in its
   handling of insufficient descriptor data buffer, and junk data
   at the end of a descriptor.

2. It is easy to add support for new descriptors, since they are now
   simple definitions that resemble the tables in the USB specifications.

Signed-off-by: Michael Drake 
---
 desc-dump.c | 541 
 desc-dump.h |  64 +++
 2 files changed, 605 insertions(+)
 create mode 100644 desc-dump.c
 create mode 100644 desc-dump.h

diff --git a/desc-dump.c b/desc-dump.c
new file mode 100644
index 000..711889b
--- /dev/null
+++ b/desc-dump.c
@@ -0,0 +1,541 @@
+/*/
+
+/*
+ *  desc-dump.c  --  USB descriptor dumping
+ *
+ *  Copyright (C) 2017 Michael Drake 
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation; either version 2 of the License, or
+ *  (at your option) any later version.
+ *
+ *  This program is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ */
+
+/*/
+
+#include "config.h"
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include "desc-defs.h"
+#include "desc-dump.h"
+#include "usbmisc.h"
+#include "names.h"
+
+/**
+ * Print a description of a bmControls field value, using a given string array.
+ *
+ * Handles the DESC_BMCONTROL_1 and DESC_BMCONTROL_2 field types.  The former
+ * is one bit per string, and the latter is 2 bits per string, with the
+ * additional bit specifying whether the control is read-only.
+ *
+ * \param[in] bmcontrols  The value to dump a human-readable representation of.
+ * \param[in] strings Array of human-readable strings, must be NULL 
terminated.
+ * \param[in] typeThe type of the value in bmcontrols.
+ * \param[in] indent  The current indent level.
+ */
+static void desc_bmcontrol_dump(
+   unsigned long long bmcontrols,
+   const char * const * strings,
+   enum desc_type type,
+   unsigned int indent)
+{
+   static const char * const setting[] = {
+   "read-only",
+   "ILLEGAL VALUE (0b10)",
+   "read/write"
+   };
+   unsigned int count = 0;
+   unsigned int control;
+
+   assert((type == DESC_BMCONTROL_1) ||
+  (type == DESC_BMCONTROL_2));
+
+   while (strings[count] != NULL) {
+   if (strings[0] != '\0') {
+   if (type == DESC_BMCONTROL_1) {
+   if ((strings[count][0] != '\0') &&
+   (bmcontrols >> count) & 0x1) {
+   printf("%*s%s Control\n",
+   indent * 2, "",
+   strings[count]);
+   }
+   } else {
+   control = (bmcontrols >> (count * 2)) & 0x3;
+   if ((strings[count][0] != '\0') && control) {
+   printf("%*s%s Control (%s)\n",
+   indent * 2, "",
+   strings[count],
+   setting[control-1]);
+   }
+   }
+   }
+   count++;
+   }
+}
+
+/**
+ * Read N bytes from descriptor data buffer into a value.
+ *
+ * Only supports values of up to 8 bytes.
+ *
+ * \param[in] buf Buffer containing the bytes to read.
+ * \param[in] offset  Offset in buffer to start reading bytes from.
+ * \param[in] bytes   Number of bytes to read.
+ * \return Value contained within the given bytes.
+ */
+static unsigned long long get_n_bytes_as_ull(
+   const unsigned char *buf,
+   unsigned int 

[PATCH v2 4/8] lsusb: Switch to descriptor-definition based dump for UAC1 and UAC2.

[Michael Drake]

This gives us more consistency in handling of incorrect descriptor
buffer lengths, and improves whitespace/alignment consistency.

Signed-off-by: Michael Drake 
---
 Makefile.am |   2 +
 lsusb.c | 751 
 2 files changed, 50 insertions(+), 703 deletions(-)

diff --git a/Makefile.am b/Makefile.am
index 117e94b..46fd7b5 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -19,6 +19,8 @@ lsusb_SOURCES = \
lsusb.c lsusb.h \
lsusb-t.c \
list.h \
+   desc-defs.c desc-defs.h \
+   desc-dump.c desc-dump.h \
names.c names.h \
usb-spec.h \
usbmisc.c usbmisc.h
diff --git a/lsusb.c b/lsusb.c
index 26df98e..fb5e6ee 100644
--- a/lsusb.c
+++ b/lsusb.c
@@ -31,6 +31,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #ifdef HAVE_BYTESWAP_H
 #include 
@@ -42,6 +43,8 @@
 #include "lsusb.h"
 #include "names.h"
 #include "usbmisc.h"
+#include "desc-defs.h"
+#include "desc-dump.h"
 
 #include 
 
@@ -159,7 +162,7 @@ static void dump_videostreaming_interface(const unsigned 
char *buf);
 static void dump_dfu_interface(const unsigned char *buf);
 static char *dump_comm_descriptor(libusb_device_handle *dev, const unsigned 
char *buf, char *indent);
 static void dump_hid_device(libusb_device_handle *dev, const struct 
libusb_interface_descriptor *interface, const unsigned char *buf);
-static void dump_audiostreaming_endpoint(const unsigned char *buf, int 
protocol);
+static void dump_audiostreaming_endpoint(libusb_device_handle *dev, const 
unsigned char *buf, int protocol);
 static void dump_midistreaming_endpoint(const unsigned char *buf);
 static void dump_hub(const char *prefix, const unsigned char *p, int tt_type);
 static void dump_ccid_device(const unsigned char *buf);
@@ -626,7 +629,7 @@ static void dump_altsetting(libusb_device_handle *dev, 
const struct libusb_inter
case USB_DT_CS_ENDPOINT:
switch 
(interface->bInterfaceSubClass) {
case 2:
-   
dump_audiostreaming_endpoint(buf, interface->bInterfaceProtocol);
+   
dump_audiostreaming_endpoint(dev, buf, interface->bInterfaceProtocol);
break;
default:
goto dump;
@@ -756,7 +759,7 @@ static void dump_endpoint(libusb_device_handle *dev, const 
struct libusb_interfa
switch (buf[1]) {
case USB_DT_CS_ENDPOINT:
if (interface->bInterfaceClass == 1 && 
interface->bInterfaceSubClass == 2)
-   dump_audiostreaming_endpoint(buf, 
interface->bInterfaceProtocol);
+   dump_audiostreaming_endpoint(dev, buf, 
interface->bInterfaceProtocol);
else if (interface->bInterfaceClass == 1 && 
interface->bInterfaceSubClass == 3)
dump_midistreaming_endpoint(buf);
break;
@@ -880,125 +883,32 @@ static void dump_unit(unsigned int data, unsigned int 
len)
  * Audio Class descriptor dump
  */
 
-struct bmcontrol {
-   const char *name;
-   unsigned int bit;
-};
-
-static const struct bmcontrol uac2_interface_header_bmcontrols[] = {
-   { "Latency control",0 },
-   { NULL }
-};
-
-static const struct bmcontrol uac_fu_bmcontrols[] = {
-   { "Mute",   0 },
-   { "Volume", 1 },
-   { "Bass",   2 },
-   { "Mid",3 },
-   { "Treble", 4 },
-   { "Graphic Equalizer",  5 },
-   { "Automatic Gain", 6 },
-   { "Delay",  7 },
-   { "Bass Boost", 8 },
-   { "Loudness",   9 },
-   { "Input gain", 10 },
-   { "Input gain pad", 11 },
-   { "Phase inverter", 12 },
-   { NULL }
-};
-
-static const struct bmcontrol uac2_input_term_bmcontrols[] = {
-   { "Copy Protect",   0 },
-   { "Connector",  1 },
-   { "Overload",   2 },
-   { "Cluster",3 },
-   { "Underflow",  4 },
-   { "Overflow",   5 },
-   { NULL }
-};
-
-static const struct bmcontrol uac2_output_term_bmcontrols[] = {
-   { "Copy Protect",   0 },
-   { "Connector",  1 },
-   { "Overload",   2 },
-   { "Underflow",  3 },
-   { "Overflow",   4 },
-   { NULL }
-};
-
-static const struct bmcontrol uac2_mixer_unit_bmcontrols[] = {
-   { "Cluster",0 },
-   { "Underflow",  1 },
-   { "Overflow",   2 },
-   { NULL }
-};
-
-static 

[PATCH v2 2/8] lsusb: Add declarative definitions for UAC1 and UAC2 descriptors.

[Michael Drake]

These descriptor definitions descibe how raw descriptor data
should be interpreted.

Signed-off-by: Michael Drake 
---
 desc-defs.c | 728 
 desc-defs.h | 153 +
 2 files changed, 881 insertions(+)
 create mode 100644 desc-defs.c
 create mode 100644 desc-defs.h

diff --git a/desc-defs.c b/desc-defs.c
new file mode 100644
index 000..a01aae2
--- /dev/null
+++ b/desc-defs.c
@@ -0,0 +1,728 @@
+/*/
+
+/*
+ *  desc-defs.c  --  USB descriptor definitions
+ *
+ *  Copyright (C) 2017 Michael Drake 
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation; either version 2 of the License, or
+ *  (at your option) any later version.
+ *
+ *  This program is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ */
+
+/*/
+
+#include "config.h"
+
+#include 
+#include 
+#include 
+
+#include "desc-defs.h"
+
+/** Macro for computing number of elements in array. */
+#define ARRAY_LEN(a) ((sizeof(a)) / (sizeof(a[0])))
+
+/** USB Audio Device Class 1 Channel Names.  (Note: Order matters.) */
+static const char * const uac1_channel_names[] = {
+   "Left Front (L)", "Right Front (R)", "Center Front (C)",
+   "Low Frequency Enhancement (LFE)", "Left Surround (LS)",
+   "Right Surround (RS)", "Left of Center (LC)", "Right of Center (RC)",
+   "Surround (S)", "Side Left (SL)", "Side Right (SR)", "Top (T)"
+};
+
+/** USB Audio Device Class 2 Channel Names.  (Note: Order matters.) */
+static const char * const uac2_channel_names[] = {
+   "Front Left (FL)", "Front Right (FR)", "Front Center (FC)",
+   "Low Frequency Effects (LFE)", "Back Left (BL)", "Back Right (BR)",
+   "Front Left of Center (FLC)", "Front Right of Center (FRC)",
+   "Back Center (BC)", "Side Left (SL)", "Side Right (SR)",
+   "Top Center (TC)", "Top Front Left (TFL)", "Top Front Center (TFC)",
+   "Top Front Right (TFR)", "Top Back Left (TBL)", "Top Back Center (TBC)",
+   "Top Back Right (TBR)", "Top Front Left of Center (TFLC)",
+   "Top Front Right of Center (TFRC)", "Left Low Frequency Effects (LLFE)",
+   "Right Low Frequency Effects (RLFE)", "Top Side Left (TSL)",
+   "Top Side Right (TSR)", "Bottom Center (BC)",
+   "Back Left of Center (BLC)", "Back Right of Center (BRC)"
+};
+
+/** Audio Control Interface Header bmControls; Human readable bit meanings. */
+static const char * const uac2_interface_header_bmcontrols[] = {
+   [0] = "Latency control",
+   [1] = NULL
+};
+
+/** UAC1: 4.3.2 Class-Specific AC Interface Descriptor; Table 4-2. */
+static const struct desc desc_audio_1_ac_header[] = {
+   { .field = "bcdADC",.size = 2, .type = DESC_BCD },
+   { .field = "wTotalLength",  .size = 2, .type = DESC_CONSTANT },
+   { .field = "bInCollection", .size = 1, .type = DESC_CONSTANT },
+   { .field = "baInterfaceNr", .size = 1, .type = DESC_NUMBER,
+   .array = { .array = true } },
+   { .field = NULL }
+};
+
+/** UAC2: 4.7.2 Class-Specific AC Interface Descriptor; Table 4-5. */
+static const struct desc desc_audio_2_ac_header[] = {
+   { .field = "bcdADC",   .size = 2, .type = DESC_BCD },
+   { .field = "bCategory",.size = 1, .type = DESC_CONSTANT },
+   { .field = "wTotalLength", .size = 2, .type = DESC_NUMBER },
+   { .field = "bmControls",   .size = 1, .type = DESC_BMCONTROL_2,
+   .bmcontrol = uac2_interface_header_bmcontrols },
+   { .field = NULL }
+};
+
+/** AudioControl Header descriptor definitions for the three Audio Device 
Class protocols */
+const struct desc * const desc_audio_ac_header[3] = {
+   desc_audio_1_ac_header,
+   desc_audio_2_ac_header,
+   NULL, /* UAC3 not implemented yet */
+};
+
+/** UAC2: 4.7.2.10 Effect Unit Descriptor; Table 4-15. */
+static const struct desc desc_audio_2_ac_effect_unit[] = {
+   { .field = "bUnitID", .size = 1, .type = DESC_NUMBER },
+   { .field = "wEffectType", .size = 2, .type = DESC_CONSTANT },
+   { .field = "bSourceID",   .size = 1, .type = DESC_CONSTANT },
+   { .field = "bmaControls", .size = 4, .type = DESC_BITMAP,
+   .array = { .array = true } },
+   { .field = "iEffects",.size = 1, .type = DESC_STR_DESC_INDEX },
+   { .field = NULL }
+};
+
+/** Effect Unit descriptor definitions for the three Audio Device Class 
protocols */
+const struct 

[PATCH v2 0/8] lsusb: Add initial support for USB Audio Class 3

[Michael Drake]

This adds a new way of dumping descriptors, which splits the knowledge
of how to interpret descriptor data from the actual dumping. This has
two advantages:

1. It is easy to add support for new descriptors, since they are now
   simple definitions that resemble the tables in the USB specifications.

2. The code for dumping descriptors is common, so the output is easy to
   keep consistent. It is also consistent and thorough in its handling
   of insufficient descriptor data buffer, and junk data at the end of
   a descriptor.

UAC1 and UAC2 are converted to use the new mechanism, initial support
for UAC3 is added.  Finally, support for the USB3 BOS Configuration
Summary Descriptor is added.

This was previously opened as a github pull request here:

https://github.com/gregkh/usbutils/pull/61

Changes since v2:

 - Signed off commits.
 - Added detail sections to all commit messages.
 - Single blank lines between things.
 - Improved comments.
 - Designated initilisers for arrays of bmControls bit names.
 - Added default to subtype mapping switch.
 - Fixed subtype mapping commit to make use of the enum in the
   switch that switches on subtype.
 - Removed redundant #ifdef around #include "config.h"
 - Fixed use of magic numbers in wFormatTag snowflake renderer.

Michael Drake (8):
  lsusb: Split subtype mapping out of AudioControl interface handling.
  lsusb: Add declarative definitions for UAC1 and UAC2 descriptors.
  lsusb: Add code to dump descriptor data using descriptor definition.
  lsusb: Switch to descriptor-definition based dump for UAC1 and UAC2.
  lsusb: Add descriptor definitions for UAC3.
  lsusb: Add initial support for USB Audio Device Class 3.
  lsusb: Add descriptor definition for USB3 BOS Configuration Summary.
  lsusb: Dump USB3 BOS Configuration Summary Descriptor.

 Makefile.am |   2 +
 desc-defs.c | 995 
 desc-defs.h | 159 ++
 desc-dump.c | 546 +
 desc-dump.h |  64 
 lsusb.c | 887 ++---
 6 files changed, 1923 insertions(+), 730 deletions(-)
 create mode 100644 desc-defs.c
 create mode 100644 desc-defs.h
 create mode 100644 desc-dump.c
 create mode 100644 desc-dump.h

-- 
2.11.0

--
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 v2 1/8] lsusb: Split subtype mapping out of AudioControl interface handling.

[Michael Drake]

UAC1 and UAC2 have different different meanings for the same subtype
value.  This splits the subtype mapping out.

Signed-off-by: Michael Drake 
---
 lsusb.c | 128 +++-
 1 file changed, 94 insertions(+), 34 deletions(-)

diff --git a/lsusb.c b/lsusb.c
index f611f2e..26df98e 100644
--- a/lsusb.c
+++ b/lsusb.c
@@ -1000,8 +1000,87 @@ static const char * const chconfig_uac2[] = {
"Back Left of Center (BLC)", "Back Right of Center (BRC)"
 };
 
+/* USB Audio Class subtypes */
+enum uac_interface_subtype {
+   UAC_INTERFACE_SUBTYPE_AC_DESCRIPTOR_UNDEFINED = 0x00,
+   UAC_INTERFACE_SUBTYPE_HEADER  = 0x01,
+   UAC_INTERFACE_SUBTYPE_INPUT_TERMINAL  = 0x02,
+   UAC_INTERFACE_SUBTYPE_OUTPUT_TERMINAL = 0x03,
+   UAC_INTERFACE_SUBTYPE_EXTENDED_TERMINAL   = 0x04,
+   UAC_INTERFACE_SUBTYPE_MIXER_UNIT  = 0x05,
+   UAC_INTERFACE_SUBTYPE_SELECTOR_UNIT   = 0x06,
+   UAC_INTERFACE_SUBTYPE_FEATURE_UNIT= 0x07,
+   UAC_INTERFACE_SUBTYPE_EFFECT_UNIT = 0x08,
+   UAC_INTERFACE_SUBTYPE_PROCESSING_UNIT = 0x09,
+   UAC_INTERFACE_SUBTYPE_EXTENSION_UNIT  = 0x0a,
+   UAC_INTERFACE_SUBTYPE_CLOCK_SOURCE= 0x0b,
+   UAC_INTERFACE_SUBTYPE_CLOCK_SELECTOR  = 0x0c,
+   UAC_INTERFACE_SUBTYPE_CLOCK_MULTIPLIER= 0x0d,
+   UAC_INTERFACE_SUBTYPE_SAMPLE_RATE_CONVERTER   = 0x0e,
+   UAC_INTERFACE_SUBTYPE_CONNECTORS  = 0x0f,
+   UAC_INTERFACE_SUBTYPE_POWER_DOMAIN= 0x10,
+};
+
+/*
+ * UAC1, and UAC2 define bDescriptorSubtype differently for the
+ * AudioControl interface, so we need to do some ugly remapping:
+ *
+ * val  | UAC1| UAC2
+ * -|-|--
+ * 0x00 | AC UNDEFINED| AC UNDEFINED
+ * 0x01 | HEADER  | HEADER
+ * 0x02 | INPUT_TERMINAL  | INPUT_TERMINAL
+ * 0x03 | OUTPUT_TERMINAL | OUTPUT_TERMINAL
+ * 0x04 | MIXER_UNIT  | MIXER_UNIT
+ * 0x05 | SELECTOR_UNIT   | SELECTOR_UNIT
+ * 0x06 | FEATURE_UNIT| FEATURE_UNIT
+ * 0x07 | PROCESSING_UNIT | EFFECT_UNIT
+ * 0x08 | EXTENSION_UNIT  | PROCESSING_UNIT
+ * 0x09 | -   | EXTENSION_UNIT
+ * 0x0a | -   | CLOCK_SOURCE
+ * 0x0b | -   | CLOCK_SELECTOR
+ * 0x0c | -   | CLOCK_MULTIPLIER
+ * 0x0d | -   | SAMPLE_RATE_CONVERTER
+ */
+static enum uac_interface_subtype get_uac_interface_subtype(unsigned char c, 
int protocol)
+{
+   switch (protocol) {
+   case USB_AUDIO_CLASS_1:
+   switch(c) {
+   case 0x04: return UAC_INTERFACE_SUBTYPE_MIXER_UNIT;
+   case 0x05: return UAC_INTERFACE_SUBTYPE_SELECTOR_UNIT;
+   case 0x06: return UAC_INTERFACE_SUBTYPE_FEATURE_UNIT;
+   case 0x07: return UAC_INTERFACE_SUBTYPE_PROCESSING_UNIT;
+   case 0x08: return UAC_INTERFACE_SUBTYPE_EXTENSION_UNIT;
+   }
+   break;
+   case USB_AUDIO_CLASS_2:
+   switch(c) {
+   case 0x04: return UAC_INTERFACE_SUBTYPE_MIXER_UNIT;
+   case 0x05: return UAC_INTERFACE_SUBTYPE_SELECTOR_UNIT;
+   case 0x06: return UAC_INTERFACE_SUBTYPE_FEATURE_UNIT;
+   case 0x07: return UAC_INTERFACE_SUBTYPE_EFFECT_UNIT;
+   case 0x08: return UAC_INTERFACE_SUBTYPE_PROCESSING_UNIT;
+   case 0x09: return UAC_INTERFACE_SUBTYPE_EXTENSION_UNIT;
+   case 0x0a: return UAC_INTERFACE_SUBTYPE_CLOCK_SOURCE;
+   case 0x0b: return UAC_INTERFACE_SUBTYPE_CLOCK_SELECTOR;
+   case 0x0c: return UAC_INTERFACE_SUBTYPE_CLOCK_MULTIPLIER;
+   case 0x0d: return UAC_INTERFACE_SUBTYPE_SAMPLE_RATE_CONVERTER;
+   }
+   break;
+   default:
+   /* Unknown protocol */
+   break;
+   }
+
+   /* If the protocol was unknown, or the value was not known to require
+* mapping, just return it unchanged. */
+   return c;
+}
+
 static void dump_audiocontrol_interface(libusb_device_handle *dev, const 
unsigned char *buf, int protocol)
 {
+   enum uac_interface_subtype subtype;
static const char * const chconfig[] = {
"Left Front (L)", "Right Front (R)", "Center Front (C)", "Low 
Frequency Enhancement (LFE)",
"Left Surround (LS)", "Right Surround (RS)", "Left of Center 
(LC)", "Right of Center (RC)",
@@ -1010,7 +1089,7 @@ static void 
dump_audiocontrol_interface(libusb_device_handle *dev, const unsigne
static const char * const clock_source_attrs[] = {
"External", "Internal fixed", "Internal variable", "Internal 
programmable"
};
-   unsigned int i, chcfg, j, k, N, termt, subtype;
+   unsigned int i, chcfg, j, k, N, termt;
char *chnames = NULL, *term = NULL, termts[128];
 
if 

[PATCH v2 6/8] lsusb: Add initial support for USB Audio Device Class 3.

[Michael Drake]

Make lsusb display verbose descriptor output for USB Audio
Devide Class 3 devices.  The descriptors have changed for
version 3 of the protocol.

Signed-off-by: Michael Drake 
---
 lsusb.c | 52 ++--
 1 file changed, 34 insertions(+), 18 deletions(-)

diff --git a/lsusb.c b/lsusb.c
index fb5e6ee..e3eb423 100644
--- a/lsusb.c
+++ b/lsusb.c
@@ -106,6 +106,11 @@
 #define USB_AUDIO_CLASS_2  0x20
 #endif
 
+/* USB DCD for Audio Devices Release 3.0: Section A.6, pp139 */
+#ifndef USB_AUDIO_CLASS_3
+#define USB_AUDIO_CLASS_3  0x30
+#endif
+
 #ifndef USB_VIDEO_PROTOCOL_15
 #define USB_VIDEO_PROTOCOL_15  0x01
 #endif
@@ -890,11 +895,12 @@ static void dump_audio_subtype(libusb_device_handle *dev,
int protocol,
unsigned int indent)
 {
-   static const char * const strings[] = { "UAC1", "UAC2" };
+   static const char * const strings[] = { "UAC1", "UAC2", "UAC3" };
unsigned int idx = 0;
 
switch (protocol) {
case USB_AUDIO_CLASS_2: idx = 1; break;
+   case USB_AUDIO_CLASS_3: idx = 2; break;
}
 
printf("(%s)\n", name);
@@ -932,25 +938,28 @@ enum uac_interface_subtype {
 };
 
 /*
- * UAC1, and UAC2 define bDescriptorSubtype differently for the
+ * UAC1, UAC2, and UAC3 define bDescriptorSubtype differently for the
  * AudioControl interface, so we need to do some ugly remapping:
  *
- * val  | UAC1| UAC2
- * -|-|--
- * 0x00 | AC UNDEFINED| AC UNDEFINED
- * 0x01 | HEADER  | HEADER
- * 0x02 | INPUT_TERMINAL  | INPUT_TERMINAL
- * 0x03 | OUTPUT_TERMINAL | OUTPUT_TERMINAL
- * 0x04 | MIXER_UNIT  | MIXER_UNIT
- * 0x05 | SELECTOR_UNIT   | SELECTOR_UNIT
- * 0x06 | FEATURE_UNIT| FEATURE_UNIT
- * 0x07 | PROCESSING_UNIT | EFFECT_UNIT
- * 0x08 | EXTENSION_UNIT  | PROCESSING_UNIT
- * 0x09 | -   | EXTENSION_UNIT
- * 0x0a | -   | CLOCK_SOURCE
- * 0x0b | -   | CLOCK_SELECTOR
- * 0x0c | -   | CLOCK_MULTIPLIER
- * 0x0d | -   | SAMPLE_RATE_CONVERTER
+ * val  | UAC1| UAC2  | UAC3
+ * -|-|---|-
+ * 0x00 | AC UNDEFINED| AC UNDEFINED  | AC UNDEFINED
+ * 0x01 | HEADER  | HEADER| HEADER
+ * 0x02 | INPUT_TERMINAL  | INPUT_TERMINAL| INPUT_TERMINAL
+ * 0x03 | OUTPUT_TERMINAL | OUTPUT_TERMINAL   | OUTPUT_TERMINAL
+ * 0x04 | MIXER_UNIT  | MIXER_UNIT| EXTENDED_TERMINAL
+ * 0x05 | SELECTOR_UNIT   | SELECTOR_UNIT | MIXER_UNIT
+ * 0x06 | FEATURE_UNIT| FEATURE_UNIT  | SELECTOR_UNIT
+ * 0x07 | PROCESSING_UNIT | EFFECT_UNIT   | FEATURE_UNIT
+ * 0x08 | EXTENSION_UNIT  | PROCESSING_UNIT   | EFFECT_UNIT
+ * 0x09 | -   | EXTENSION_UNIT| PROCESSING_UNIT
+ * 0x0a | -   | CLOCK_SOURCE  | EXTENSION_UNIT
+ * 0x0b | -   | CLOCK_SELECTOR| CLOCK_SOURCE
+ * 0x0c | -   | CLOCK_MULTIPLIER  | CLOCK_SELECTOR
+ * 0x0d | -   | SAMPLE_RATE_CONVERTER | CLOCK_MULTIPLIER
+ * 0x0e | -   | - | SAMPLE_RATE_CONVERTER
+ * 0x0f | -   | - | CONNECTORS
+ * 0x10 | -   | - | POWER_DOMAIN
  */
 static enum uac_interface_subtype get_uac_interface_subtype(unsigned char c, 
int protocol)
 {
@@ -978,6 +987,9 @@ static enum uac_interface_subtype 
get_uac_interface_subtype(unsigned char c, int
case 0x0d: return UAC_INTERFACE_SUBTYPE_SAMPLE_RATE_CONVERTER;
}
break;
+   case USB_AUDIO_CLASS_3:
+   /* No mapping required. */
+   break;
default:
/* Unknown protocol */
break;
@@ -1057,6 +1069,10 @@ static void 
dump_audiocontrol_interface(libusb_device_handle *dev, const unsigne
dump_audio_subtype(dev, "EFFECT_UNIT", 
desc_audio_ac_effect_unit, buf, protocol, 4);
break;
 
+   case UAC_INTERFACE_SUBTYPE_POWER_DOMAIN:
+   dump_audio_subtype(dev, "POWER_DOMAIN", 
desc_audio_ac_power_domain, buf, protocol, 4);
+   break;
+
default:
printf("(unknown)\n"
   "Invalid desc subtype:");
-- 
2.11.0

--
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] HID: add quirk for another PIXART OEM mouse used by HP

[Jiri Kosina]

On Fri, 1 Dec 2017, Dave Young wrote:

> This mouse keep disconnecting in runleve 3 like below, add it needs the
> quirk to mute the anoying messages.
> 
> [  111.230555] usb 2-2: USB disconnect, device number 6
> [  112.718156] usb 2-2: new low-speed USB device number 7 using xhci_hcd
> [  112.941594] usb 2-2: New USB device found, idVendor=03f0, idProduct=094a
> [  112.984866] usb 2-2: New USB device strings: Mfr=1, Product=2, 
> SerialNumber=0
> [  113.027731] usb 2-2: Product: HP USB Optical Mouse
> [  113.069977] usb 2-2: Manufacturer: PixArt
> [  113.113500] input: PixArt HP USB Optical Mouse as 
> /devices/pci:00/:00:14.0/usb2/2-2/2-2:1.0/0003:03F0:094A.0002/input/input14
> [  113.156787] hid-generic 0003:03F0:094A.0002: input: USB HID v1.11 Mouse 
> [PixArt HP USB Optical Mouse] on usb-:00:14.0-2/input0
> [  173.262642] usb 2-2: USB disconnect, device number 7
> [  174.750244] usb 2-2: new low-speed USB device number 8 using xhci_hcd
> [  174.935740] usb 2-2: New USB device found, idVendor=03f0, idProduct=094a
> [  174.990435] usb 2-2: New USB device strings: Mfr=1, Product=2, 
> SerialNumber=0
> [  175.014984] usb 2-2: Product: HP USB Optical Mouse
> [  175.037886] usb 2-2: Manufacturer: PixArt
> [  175.061794] input: PixArt HP USB Optical Mouse as 
> /devices/pci:00/:00:14.0/usb2/2-2/2-2:1.0/0003:03F0:094A.0003/input/input15
> [  175.084946] hid-generic 0003:03F0:094A.0003: input: USB HID v1.11 Mouse 
> [PixArt HP USB Optical Mouse] on usb-:00:14.0-2/input0

Applied, thanks.

-- 
Jiri Kosina
SUSE Labs

--
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: hub: Delete an error message for a failed memory allocation in usb_hub_clear_tt_buffer()

[Dan Carpenter]

On Thu, Dec 07, 2017 at 09:45:38AM +0100, Geert Uytterhoeven wrote:
> >
> > Small allocations never fail in the current kernel.
> 
> A few comments (this is in response to a patch from Markus, so there have
> to be lots of questions and uncertainties ;-)
> 1. In the current kernel. What about the future?

Right.  No one can predict.  And the small allocations don't fail rule
causes some problems.

> 2. If a small allocation cannot fail, what happens if the small memory slab
>is exhausted? A new page must be allocated, which will trigger an OOM,
>and some other part of the system will be killed and fail.

Right.


> 3. This driver uses GFP_ATOMIC, is that guaranteed to succeed? I think not.
> 

Right again.  I was missing the first email in the thread because of my
email filters so I didn't see this was atomic.

regards,
dan carpenter

--
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

[no subject]

[Alexander Kappner]

Date: Wed, 6 Dec 2017 15:28:37 -0800
Subject: [PATCH] usb-core: Fix potential null pointer dereference in 
xhci-debugfs.c

My kernel crashed just after resuming from hibernate and starting usbmuxd
(a user-space daemon for iOS device pairing) with several USB devices
connected (dmesg attached).

Backtrace leads to:

0x8170465d is in xhci_debugfs_create_endpoint
(drivers/usb/host/xhci-debugfs.c:381).
376   int ep_index)
377 {
378 struct xhci_ep_priv *epriv;
379 struct xhci_slot_priv   *spriv = dev->debugfs_private;
380
381 if (spriv->eps[ep_index])
382 return;
383
384 epriv = kzalloc(sizeof(*epriv), GFP_KERNEL);
385 if (!epriv)

The read violation happens at address 0x40 and sizeof(struct
xhci_ep_priv)=0x40, so it seems ep_index is 1 and spriv is NULL here.

spriv gets allocated in xhci_debugfs_create_slot:

...
priv = kzalloc(sizeof(*priv), GFP_KERNEL);
if (!priv)
return;
...

There's no separate error path if this allocation fails, so we might be
left with NULL in priv. Subsequent users of priv thus need to check for
this NULL - so this is what the patch does.

There might be other ways of triggering this null pointer dereference,
including when xhci_resume frees the device structures (e.g. after
returning from a hibernate), but I wasn't able to find or reproduce it. 

[63953.758083] BUG: unable to handle kernel NULL pointer dereference at
0040
[63953.758090] IP: xhci_debugfs_create_endpoint+0x1d/0xa0
[63953.758091] PGD bb911d067 P4D bb911d067 PUD 10500ff067 PMD 0
[63953.758093] Oops:  [#1] PREEMPT SMP
[63953.758094] Modules linked in: ipheth tun nvidia_modeset(PO) iwlmvm
mac80211 iwlwifi nvidia(PO) btusb btrtl btbcm btintel bluetooth cfg80211
qmi_wwan ecdh_generic thinkpad_acpi rfkill
[63953.758103] CPU: 4 PID: 27091 Comm: usbmuxd Tainted: P   O
4.14.0.1-12769-g1deab8c #1
[63953.758104] Hardware name: LENOVO 20ENCTO1WW/20ENCTO1WW, BIOS N1EET62W
(1.35 ) 11/10/2016
[63953.758105] task: 8810527ba0c0 task.stack: c9000a8ec000
[63953.758107] RIP: 0010:xhci_debugfs_create_endpoint+0x1d/0xa0
[63953.758108] RSP: 0018:c9000a8efc80 EFLAGS: 00010206
[63953.758109] RAX:  RBX: 88105a71c000 RCX:
0003
[63953.758110] RDX: 0003 RSI: 880c0b57e000 RDI:
88105a71c238
[63953.758110] RBP: 0003 R08: 881063800600 R09:
0003
[63953.758111] R10: 88105a71c238 R11: 0001 R12:
0011
[63953.758112] R13: 0018 R14:  R15:

[63953.758113] FS:  7f0a77715700() GS:8810a3d0()
knlGS:
[63953.758114] CS:  0010 DS:  ES:  CR0: 80050033
[63953.758115] CR2: 0040 CR3: 0003f91a8006 CR4:
003606e0
[63953.758115] DR0:  DR1:  DR2:

[63953.758116] DR3:  DR6: fffe0ff0 DR7:
0400
[63953.758117] Call Trace:
[63953.758120]  xhci_add_endpoint+0x127/0x2b0
[63953.758123]  usb_hcd_alloc_bandwidth+0x1ad/0x300
[63953.758125]  usb_set_configuration+0x1c8/0x880
[63953.758128]  usbdev_do_ioctl+0xc41/0x1120
[63953.758130]  usbdev_ioctl+0xa/0x10
[63953.758151]  do_vfs_ioctl+0x8b/0x5c0
[63953.758153]  ? __fget+0x6c/0xb0
[63953.758155]  SyS_ioctl+0x76/0x90
[63953.758157]  do_syscall_64+0x6b/0x290
[63953.758173]  entry_SYSCALL64_slow_path+0x25/0x25
[63953.758175] RIP: 0033:0x7f0a76a151c7
[63953.758175] RSP: 002b:7ffd1431b0c8 EFLAGS: 0202 ORIG_RAX:
0010
[63953.758177] RAX: ffda RBX: 023239a0 RCX:
7f0a76a151c7
[63953.758178] RDX: 7ffd1431b0dc RSI: 80045505 RDI:
000e
[63953.758178] RBP: 023240c0 R08: 7ffd1431b008 R09:
0004
[63953.758179] R10: 7ffd1431aec0 R11: 0202 R12:
023240c0
[63953.758180] R13: 0001 R14: 0056 R15:
0038
[63953.758182] Code: e9 39 ff ff ff 66 0f 1f 84 00 00 00 00 00 0f 1f 44 00
00 41 57 41 56 41 55 41 54 55 48 63 ea 53 4c 8b b6 88 15 00 00 4d 8d 2c ee
<49> 83 7d 28 00 74 0b 5b 5d 41 5c 41 5d 41 5e 41 5f c3 48 8b 3d
[63953.758202] RIP: xhci_debugfs_create_endpoint+0x1d/0xa0 RSP:
c9000a8efc80
[63953.758203] CR2: 0040
[63953.758204] ---[ end trace 1f7ea9a959f02054 ]---

Signed-off-by: Alexander Kappner 
---
 drivers/usb/host/xhci-debugfs.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/usb/host/xhci-debugfs.c b/drivers/usb/host/xhci-debugfs.c
index 4f7895d..1cea59c 100644
--- a/drivers/usb/host/xhci-debugfs.c
+++ b/drivers/usb/host/xhci-debugfs.c
@@ -378,6 +378,9 @@ void xhci_debugfs_create_endpoint(struct xhci_hcd *xhci,
struct xhci_ep_priv *epriv;
struct xhci_slot_priv   *spriv = dev->debugfs_private;
 
+   if (!spriv)
+   return;
+
if 

musb-hdrc: can't add more than 2 functions to composite gadget

[Nuno Gonçalves]

Linux: 4.14.0 and 4.15-rc2
SOC: H3
Driver: sun8i-h3-musb

I am trying to add 3 functions to a composite gadget and it fails.

[4.664742] configfs-gadget gadget: acm/23b5a59a: can't bind, err -19
[4.671227] configfs-gadget musb-hdrc.1.auto: failed to start g1: -19

The same configuration works on a am335x, and it also works in this
SOC when using just 1 or 3 functions, it just fails from 3.

Eg:
2x ACM - OK.
1x ACM + 1x Mass Storage works - OK.
3x ACM - ERROR
2x ACM + 1x Mass Storage - ERROR

Might this be a SOC limitation in some way? Hints were to start debugging?

Thanks,
Nuno Gonçalves
--
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: hub: Delete an error message for a failed memory allocation in usb_hub_clear_tt_buffer()

[Oliver Neukum]

Am Donnerstag, den 07.12.2017, 09:56 +0100 schrieb Greg Kroah-Hartman:
> On Thu, Dec 07, 2017 at 09:45:38AM +0100, Geert Uytterhoeven wrote:
> > 
> > A few comments (this is in response to a patch from Markus, so there have
> > to be lots of questions and uncertainties ;-)
> 
> Note, because of the patch author, I'm not applying it no matter what,
> so this discussion is really going nowhere.

We really need to come to a consensus on that question.
If those additional messages really are redundant, we could save
memory deleting them. Or alternatively, if they are not and we need to
know which device is hit, we should centralize that reporting
and tell the VM subsystem not the dump a stack trace.

Regards
Oliver

--
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: hub: Delete an error message for a failed memory allocation in usb_hub_clear_tt_buffer()

[Greg Kroah-Hartman]

On Thu, Dec 07, 2017 at 09:45:38AM +0100, Geert Uytterhoeven wrote:
> A few comments (this is in response to a patch from Markus, so there have
> to be lots of questions and uncertainties ;-)

Note, because of the patch author, I'm not applying it no matter what,
so this discussion is really going nowhere.

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: USB: hub: Delete an error message for a failed memory allocation in usb_hub_clear_tt_buffer()

[Geert Uytterhoeven]

Hi Dan,

On Thu, Dec 7, 2017 at 9:35 AM, Dan Carpenter  wrote:
> On Thu, Dec 07, 2017 at 08:40:07AM +0100, Geert Uytterhoeven wrote:
>> On Wed, Dec 6, 2017 at 11:02 PM, Alan Stern  
>> wrote:
>> > On Wed, 6 Dec 2017, SF Markus Elfring wrote:
>> >> >>> Does the existing memory allocation error message include the
>> >> >>> >dev device name and driver name?  If it doesn't, there will be
>> >> >>> no way for the user to tell that the error message is related to the
>> >> >>> device failure.
>> >> >>
>> >> >> No, but the effect is similar.
>> >> >>
>> >> >> OOM does a dump_stack() so this function's call tree is shown.
>> >> >
>> >> > A call stack doesn't tell you which device was being handled.
>> >>
>> >> Do you find a default Linux allocation failure report insufficient then?
>> >>
>> >> Would you like to to achieve that the requested information can be 
>> >> determined
>> >> from a backtrace?
>> >
>> > It is not practical to do this.  The memory allocation routines do not
>> > for what purpose the memory is being allocated; hence when a failure
>> > occurs they cannot tell what device (or other part of the system) will
>> > be affected.
>>
>> If even allocation of 24 bytes fails, lots of other devices and other parts 
>> of
>> the system will start failing really soon...
>
> Small allocations never fail in the current kernel.

A few comments (this is in response to a patch from Markus, so there have
to be lots of questions and uncertainties ;-)
1. In the current kernel. What about the future?
2. If a small allocation cannot fail, what happens if the small memory slab
   is exhausted? A new page must be allocated, which will trigger an OOM,
   and some other part of the system will be killed and fail.
3. This driver uses GFP_ATOMIC, is that guaranteed to succeed? I think not.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
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: hub: Delete an error message for a failed memory allocation in usb_hub_clear_tt_buffer()

[Dan Carpenter]

On Thu, Dec 07, 2017 at 08:40:07AM +0100, Geert Uytterhoeven wrote:
> Hi Alan,
> 
> On Wed, Dec 6, 2017 at 11:02 PM, Alan Stern  wrote:
> > On Wed, 6 Dec 2017, SF Markus Elfring wrote:
> >> >>> Does the existing memory allocation error message include the
> >> >>> >dev device name and driver name?  If it doesn't, there will be
> >> >>> no way for the user to tell that the error message is related to the
> >> >>> device failure.
> >> >>
> >> >> No, but the effect is similar.
> >> >>
> >> >> OOM does a dump_stack() so this function's call tree is shown.
> >> >
> >> > A call stack doesn't tell you which device was being handled.
> >>
> >> Do you find a default Linux allocation failure report insufficient then?
> >>
> >> Would you like to to achieve that the requested information can be 
> >> determined
> >> from a backtrace?
> >
> > It is not practical to do this.  The memory allocation routines do not
> > for what purpose the memory is being allocated; hence when a failure
> > occurs they cannot tell what device (or other part of the system) will
> > be affected.
> 
> If even allocation of 24 bytes fails, lots of other devices and other parts of
> the system will start failing really soon...
> 

Small allocations never fail in the current kernel.

regards,
dan carpenter

--
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