Re: [RFC PATCH 10/13] mm: Introduce first class virtual address spaces

[Till Smejkal]

Hi Vineet,

On Mon, 13 Mar 2017, Vineet Gupta wrote:
> I've not looked at the patches closely (or read the references paper fully 
> yet),
> but at first glance it seems on ARC architecture, we can can potentially
> use/leverage this mechanism to implement the shared TLB entries. Before anyone
> shouts these are not same as the IA64/x86 protection keys which allow TLB 
> entries
> with different protection bits across processes etc. These TLB entries are
> actually *shared* by processes.
> 
> Conceptually there's shared address spaces, independent of processes. e.g. 
> ldso
> code is shared address space #1, libc (code) #2  System can support a 
> limited
> number of shared addr spaces (say 64, enough for typical embedded sys).
> 
> While Normal TLB entries are tagged with ASID (Addr space ID) to keep them 
> unique
> across processes, Shared TLB entries are tagged with Shared address space ID.
> 
> A process MMU context consists of ASID (a single number) and a SASID bitmap 
> (to
> allow "subscription" to multiple Shared spaces. The subscriptions are set up 
> bu
> userspace ld.so which knows about the libs process wants to map.
> 
> The restriction ofcourse is that the spaces are mapped at *same* vaddr is all
> participating processes. I know this goes against whole security, address 
> space
> randomization - but it gives much better real time performance. Why does each
> process need to take a MMU exception for libc code...
> 
> So long story short - it seems there can be multiple uses of this 
> infrastructure !

During the development of this code, we also looked at shared TLB entries, but
the other way around. We wanted to use them to prevent flushing of TLB entries 
of
shared memory regions when switching between multiple ASes. Unfortunately, we 
never
finished this part of the code.

However, we also investigated into a different use-case for first class virtual
address spaces that is related to what you propose if I didn't understand 
something
wrong. The idea is to move shared libraries into their own first class virtual
address space and only load some small trampoline code in the application AS. 
This
trampoline code performs the VAS switch in the libraries AS and execute the 
requested
function there. If we combine this architecture with tagged TLB entries to 
prevent
TLB flushes during the switch operation, it can also reach an acceptable 
performance.
A side effect of moving the shared library into its own AS is that it can not 
be used
by ROP-attacks because it is not accessible in the application's AS.

Till
--
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: Add MS_INTR_BINTERVAL USB quirk

[Dave Mielke]

Thank you for your very helpful answer. I really do appreciate it.

It's possible that this device is using high speed because it offers a feature 
to transfer its internal clipboard to the host, and it allows that clipboard to 
contain lots of data. Interestingly, though, hidden within a usage note, they 
do observe that, so far, they've been unable to achieve a transfer speed faster 
than 5,000 characters in seven minutes. It looks to me like this is exactly due 
to their incorrect setting of bInterval. :-) I've sent them a note about it.

-- 
Dave Mielke   | 2213 Fox Crescent | The Bible is the very Word of God.
Phone: 1-613-726-0014 | Ottawa, Ontario   | http://Mielke.cc/bible/
EMail: d...@mielke.cc | Canada  K2A 1H7   | http://FamilyRadio.org/
--
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: smsc95xx: Reduce logging noise

[Guenter Roeck]

On 03/13/2017 03:32 PM, David Miller wrote:

From: Guenter Roeck 
Date: Fri, 10 Mar 2017 17:45:21 -0800


An insert/remove stress test generated the following log message sequence.

...

Use netdev_dbg() instead of netdev_warn() for the repeating messages
to reduce logging noise.

Signed-off-by: Guenter Roeck 


The problem I have with changes like this is that outside of your
stress test situation these messages are extremely useful but will
now be hidden making diagnosis of problems more difficult.



In general I agree, but in this case the calling code also generates
another set of error messages, which I considered a bit excessive.

No problem, though, we can live with the noise.

Guenter

--
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 v19 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

[Baolin Wang]

On 14 March 2017 at 09:10, Jun Li  wrote:
> Hi,
>
>> -Original Message-
>> From: Baolin Wang [mailto:baolin.w...@linaro.org]
>> Sent: Monday, March 13, 2017 4:44 PM
>> To: Jun Li 
>> Cc: NeilBrown ; Felipe Balbi ; Greg KH
>> ; Sebastian Reichel ; Dmitry
>> Eremin-Solenikov ; David Woodhouse
>> ; r...@kernel.org; Marek Szyprowski
>> ; Ruslan Bilovol ;
>> Peter Chen ; Alan Stern
>> ; grygorii.stras...@ti.com; Yoshihiro Shimoda
>> ; Lee Jones ;
>> Mark Brown ; John Stultz ;
>> Charles Keepax ;
>> patc...@opensource.wolfsonmicro.com; Linux PM list > p...@vger.kernel.org>; USB ; device-
>> mainlin...@lists.linuxfoundation.org; LKML 
>> Subject: Re: [PATCH v19 0/4] Introduce usb charger framework to deal with
>> the usb gadget power negotation
>>
> ... ...
>> >> That is same what USB charger did, from this point, we need USB
>> >> charger to send out vbus draw information according to speed and usb
>> >> state. But I should listen to other guys suggestion. Peter and Felipe, 
>> >> what
>> do you think?
>
> Instead of waiting for maintainer's comments on this long discussion, I'd 
> suggest
> you directly post the patches for the required change, so they can easily know
> what's the conclusion/solution looks like.

That's right, I am creating patches for adding extcon_dev in
phy/usb_phy. Thanks.

-- 
Baolin.wang
Best Regards
--
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/2] usb: host: [eo]hci-plat: set hcd->phy to avoid phy_get_() in usb_add_hcd()

[Alan Stern]

On Mon, 13 Mar 2017, Yoshihiro Shimoda wrote:

> The usb_add_hcd() will call phy_{get,init,power_on}() if hcd->phy is not set.
> After the usb_add_hcd() call phy_power_on(), it keeps until usb_remove_hcd().
> And then, even if the system turns suspend, the usb core keeps the phy power.
> I think that each host driver should handle the phy power. So, this patch
> sets hcd->phy before usb_add_hcd() to avoid phy_get() in usb_add_hcd().
> 
> Changes from v1 (as RFC):
>  - Fix the usage condition about priv->phys[].
>  - Remove RFC.
> 
> Yoshihiro Shimoda (2):
>   usb: host: ehci-platform: set hcd->phy to avoid phy_get() in
> usb_add_hcd()
>   usb: host: ohci-platform: set hcd->phy to avoid phy_get() in
> usb_add_hcd()
> 
>  drivers/usb/host/ehci-platform.c | 3 +++
>  drivers/usb/host/ohci-platform.c | 3 +++
>  2 files changed, 6 insertions(+)

For both patches:

Acked-by: 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] usb-core: Add MS_INTR_BINTERVAL USB quirk

[Alan Stern]

On Mon, 13 Mar 2017, Samuel Thibault wrote:

> Alan Stern, on dim. 12 mars 2017 21:40:33 -0400, wrote:
> > On Sun, 12 Mar 2017, Dave Mielke wrote:
> > > [quoted lines by Alan Stern on 2017/03/12 at 21:31 -0400]
> > > 
> > > >A device's speed is only partially related to its USB version.  A
> > > >USB-1.1 device can run at low speed or full speed.  A USB-2 device can
> > > >run at low, full, or high speed.  And a USB-3 device can run at low,
> > > >full, high, or Super speed.
> > > 
> > > Yes, I did know this, so maybe I misunderstood what you were wondering 
> > > about. 
> > > Were you wondering why 64ms was too long?
> > 
> > No, I was wondering why an HID device would run at high speed.  Both
> > you and Samuel implied that this was because it was a USB-2 device.  
> > But that is not an adequate answer, because it is perfectly valid for a 
> > USB-2 device to run at full speed.
> 
> to_usb_device(ddev)->speed really is USB_SPEED_HIGH, otherwise the quirk
> wouldn't work :)

Indeed; I believe you.  It's just odd and a little noteworthy, that's
all.

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] usb-core: Add MS_INTR_BINTERVAL USB quirk

[Alan Stern]

On Sun, 12 Mar 2017, Dave Mielke wrote:

> [quoted lines by Alan Stern on 2017/03/12 at 21:40 -0400]
> 
> >No, I was wondering why an HID device would run at high speed.  Both
> >you and Samuel implied that this was because it was a USB-2 device.  
> >But that is not an adequate answer, because it is perfectly valid for a 
> >USB-2 device to run at full speed.
> 
> What should we look at to find out what speed it wants to operate at? We 
> didn't 

The speed is reported in the kernel log and in 
/sys/kernel/debug/usb/devices.

> look into it becuaase the real problem, from our perspective, was that the 
> 64ms 
> interval was being honoured by the host when it should be the 10ms as is 
> literally in the endpoint descriptor. Our assumption was that since it says 
> it's USB 2.0 then bInterval must be intterpreted in light of that regardless 
> of 
> the actual speed used for communication.

You should read the USB specification.  Specifically, table 9-13 in 
section 9.6.6 describes bInterval like this (in part):

Interval for polling endpoint for data transfers.
Expressed in frames or microframes depending on the
device operating speed (i.e., either 1 millisecond or
125 μs units).

For full-/high-speed isochronous endpoints, this value
must be in the range from 1 to 16. The bInterval value
is used as the exponent for a 2^(bInterval-1) value; e.g., a
bInterval of 4 means a period of 8 (2^(4-1)).

For full-/low-speed interrupt endpoints, the value of
this field may be from 1 to 255.

For high-speed interrupt endpoints, the bInterval value
is used as the exponent for a 2^(bInterval-1) value; e.g., a
bInterval of 4 means a period of 8 (2^(4-1)). This value
must be from 1 to 16.

> Yes, I did know this, so maybe I misunderstood what you were wondering about.
> Were you wondering why 64ms was too long?

No.  I was wondering why an HID device would run at high speed.

> I think I've misunderstood something about how to interpret bInterval. I'm 
> now 
> suspecting that bInterval must be interpreted the new (mocro frame) way only 
> if 
> the device is operating at least at high speed, and that, even if the device 
> advertizes itself as USB 2.0, bInterval must still be interpreted the old way 
> if the device is operating at full or low speed. Is that correct?

Like I said, read the spec.

> If the above is correct, how can we tell from usbfs which way to 
> interpret bInterval?

There is an ioctl you can use to find the device speed: 
USBDEVFS_CONNECTINFO.  Unfortunately, this ioctl is badly out of date 
and only distinguishes between low speed and non-low speed.  A patch to 
remedy this situation would be welcome.

However, in general, users of usbfs don't need to know the device
speed.  In particular, you don't need to interpret bInterval.  Just
submit URBs quickly enough that the pipeline never empties out.

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: [RFC PATCH 10/13] mm: Introduce first class virtual address spaces

[Vineet Gupta]

+CC Ingo, tglx

Hi Till,

On 03/13/2017 03:14 PM, Till Smejkal wrote:
> Introduce a different type of address spaces which are first class citizens
> in the OS. That means that the kernel now handles two types of AS, those
> which are closely coupled with a process and those which aren't. While the
> former ones are created and destroyed together with the process by the
> kernel and are the default type of AS in the Linux kernel, the latter ones
> have to be managed explicitly by the user and are the newly introduced
> type.
> 
> Accordingly, a first class AS (also called VAS == virtual address space)
> can exist in the OS independently from any process. A user has to
> explicitly create and destroy them in the system. Processes and VAS can be
> combined by attaching a previously created VAS to a process which basically
> adds an additional AS to the process that the process' threads are able to
> execute in. Hence, VAS allow a process to have different views onto the
> main memory of the system (its original AS and the attached VAS) between
> which its threads can switch arbitrarily during their lifetime.
> 
> The functionality made available through first class virtual address spaces
> can be used in various different ways. One possible way to utilize VAS is
> to compartmentalize a process for security reasons. Another possible usage
> is to improve the performance of data-centric applications by being able to
> manage different sets of data in memory without the need to map or unmap
> them.
> 
> Furthermore, first class virtual address spaces can be attached to
> different processes at the same time if the underlying memory is only
> readable. This mechanism allows sharing of whole address spaces between
> multiple processes that can both execute in them using the contained
> memory.

I've not looked at the patches closely (or read the references paper fully yet),
but at first glance it seems on ARC architecture, we can can potentially
use/leverage this mechanism to implement the shared TLB entries. Before anyone
shouts these are not same as the IA64/x86 protection keys which allow TLB 
entries
with different protection bits across processes etc. These TLB entries are
actually *shared* by processes.

Conceptually there's shared address spaces, independent of processes. e.g. ldso
code is shared address space #1, libc (code) #2  System can support a 
limited
number of shared addr spaces (say 64, enough for typical embedded sys).

While Normal TLB entries are tagged with ASID (Addr space ID) to keep them 
unique
across processes, Shared TLB entries are tagged with Shared address space ID.

A process MMU context consists of ASID (a single number) and a SASID bitmap (to
allow "subscription" to multiple Shared spaces. The subscriptions are set up bu
userspace ld.so which knows about the libs process wants to map.

The restriction ofcourse is that the spaces are mapped at *same* vaddr is all
participating processes. I know this goes against whole security, address space
randomization - but it gives much better real time performance. Why does each
process need to take a MMU exception for libc code...

So long story short - it seems there can be multiple uses of this 
infrastructure !

-Vineet
--
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: Killing process causing USB bulk transfer transaction loss?

[Alan Stern]

On Mon, 13 Mar 2017, Charles Manning wrote:

> On Mon, Mar 13, 2017 at 2:38 PM, Alan Stern 
> wrote:
> 
> > On Mon, 13 Mar 2017, Charles Manning wrote:
> >
> > > Hello
> > >
> > > I have an issue where the first 512-byte high speed bulk transfer
> > > between a custom peripheral and a Linux host is sometimes lost.
> > >
> > > I have the bus attached to a Beagle 480 and I can see the transaction
> > > happening over the bus (IN, DATA, ACK) at the right time but the data
> > > does not show up into userspace buffers. ie. it would seem the data is
> > > getting lost somewhere between the host hardware and user space.
> > >
> > > I've seen on both Ubuntu with 4.4.0 x64 as well as on various Android
> > > ARM platforms (ie commercial Android phones/tablets).
> > >
> > > There are two independently written user space programs that both
> > > exhibit this behaviour:
> > > * Linux PC based application written using libusb.
> > > * Android application written in NDK using ioctls.
> > >
> > > In both cases everything works fine (eg. long term streaming for
> > > hours, orderly start/stopping) except when the process is killed
> > > (swipe app right in Android) or Control C in Ubuntu.
> > >
> > > If the application is killed then the first 512-byte transfer in the
> > > next invocation of the application **might** be lost.
> > >
> > > In our application we're stuffing approx 8 or 9 MBytes of data a
> > > second through the high speed USB link (ie. around 1/7) of the full
> > > bandwidth. The problem occurs approximately 1/7th of the time.
> > >
> > > This leads me to suspect that around 1/7th of the time the process is
> > > being killed during the middle of a transfer and this results in the
> > > host controller being left in a weird state causing the first packet
> > > to be lost.
> > >
> > > Any hints on where to look for this or how to debug further would be
> > > much appreciated.
> >
> > No doubt what happens is that the packet is received by the system, but
> > the process is killed before it can get the packet's contents from the
> > operating system.  (Or after it has gotten the packet's contents but
> > before it can do anything with them.)
> >
> >
> Thanks for the response, but that does not stack up.
> 
> The order is this:
> 
> Start a process all transfering nicely.

Okay.  The process submits URBs 1 - N, and processes the replies for
URBs 1 - (N-1).  The data for URB N has just arrived at the computer
and (let's say) has been sent to the process.  But before the process
can do anything with this data...

> Kill process with Ctl C.

The process is now dead.  The data for URB N has been lost.  The data 
for URBs 1 - (N-1), on the other hand, have been fully processed.

> Start another process
> The new process does set halt, clear halts etc. (as well as some config).

Why on earth would you want to do a Set-Halt?  That request hardly ever 
gets used -- and when it does, it's usually in error.

> The new process submits URBs.

It submits URBs (N+1) - M.

> The device sends out new packets.

Starting with the data for URB N+1.

> The first 512 byte transfer goes AWOL.

No, it doesn't.  What you _think_ is the first 512 bytes is actually 
the 512 bytes for URB N, which (as mentioned above) have been 
permanently lost.  The data for URB N+1 gets sent to the new process as 
it should be.

> ie. it isn't the control C that is causing the data to not get to the
> process. The Control C was on an entirely different process.

The missing data doesn't get to the new process because it was already
sent to the original process.  The ^C prevents the original process
from processing (or receiving, as the case may be) this data.

> > I can assure you that the host controller is not left in any sort of
> > weird state.
> >
> 
> Where is that state managed?

In the host controller driver.  You can probably find out what driver
that is by reading the information in /sys/kernel/debug/usb/devices, or 
if necessary, by examining the kernel log.

> > If you want to prevent this sort of thing from happening, don't just
> > kill the process willy-nilly.  Have it catch the signal and set a flag,
> > and have it check this flag at an appropriate place so that it can
> > fetch the contents of any remaining packets before exiting in an
> > orderly manner.
> >
> 
> That's not really the point. I was doing this as a stress test, not as
> inything intended in production code.

Ah, okay.

If you want to find out what the kernel thinks is happening to your
URBs during the stress test, follow the instructions in
Documentation/usb/usbmon.txt.

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 v19 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

[Jun Li]

Hi,

> -Original Message-
> From: Baolin Wang [mailto:baolin.w...@linaro.org]
> Sent: Monday, March 13, 2017 4:44 PM
> To: Jun Li 
> Cc: NeilBrown ; Felipe Balbi ; Greg KH
> ; Sebastian Reichel ; Dmitry
> Eremin-Solenikov ; David Woodhouse
> ; r...@kernel.org; Marek Szyprowski
> ; Ruslan Bilovol ;
> Peter Chen ; Alan Stern
> ; grygorii.stras...@ti.com; Yoshihiro Shimoda
> ; Lee Jones ;
> Mark Brown ; John Stultz ;
> Charles Keepax ;
> patc...@opensource.wolfsonmicro.com; Linux PM list  p...@vger.kernel.org>; USB ; device-
> mainlin...@lists.linuxfoundation.org; LKML 
> Subject: Re: [PATCH v19 0/4] Introduce usb charger framework to deal with
> the usb gadget power negotation
> 
... ...
> >> That is same what USB charger did, from this point, we need USB
> >> charger to send out vbus draw information according to speed and usb
> >> state. But I should listen to other guys suggestion. Peter and Felipe, what
> do you think?

Instead of waiting for maintainer's comments on this long discussion, I'd 
suggest
you directly post the patches for the required change, so they can easily know
what's the conclusion/solution looks like.

Li Jun

> >
> > So now the only to do work is to find a common place to send the
> > notification out (based on gadget speed and sate).
> 
> Yes.
> 
> --
> Baolin.wang
> Best Regards
N�r��yb�X��ǧv�^�)޺{.n�+{��^n�r���z���h�&���G���h�(�階�ݢj"���m��z�ޖ���f���h���~�m�

Re: Neophyte questions about PCIe

[Bjorn Helgaas]

On Mon, Mar 13, 2017 at 10:57:48PM +0100, Mason wrote:
> On 13/03/2017 22:40, Bjorn Helgaas wrote:
> 
> > On Sat, Mar 11, 2017 at 11:57:56AM +0100, Mason wrote:
> >
> >> On 10/03/2017 18:49, Mason wrote:
> >> 
> >>> static void tango_pcie_bar_quirk(struct pci_dev *dev)
> >>> {
> >>>   struct pci_bus *bus = dev->bus;
> >>>
> >>>   printk("%s: bus=%d devfn=%d\n", __func__, bus->number, dev->devfn);
> >>>
> >>> pci_write_config_dword(dev, PCI_BASE_ADDRESS_0, 0x8004);
> >>> }
> >>> DECLARE_PCI_FIXUP_FINAL(0x1105, PCI_ANY_ID, tango_pcie_bar_quirk);
> >>
> >> And this is where the elusive "black magic" happens.
> >>
> >> Is it "safe" to configure a BAR behind Linux's back?
> > 
> > No.  Linux maintains a struct resource for every BAR.  This quirk
> > makes the BAR out of sync with the resource, so Linux no longer has an
> > accurate idea of what bus address space is consumed and what is
> > available.
> 
> Even when Linux is not able to map the BAR, since it's too
> large to fit in the mem window?

I don't think there's much point in advertising a BAR that isn't
really a BAR and making assumptions about how Linux will handle it.
So my answer remains "No, I don't think it's a good idea to change a
BAR behind the back of the PCI core.  It might work now, but there's
no guarantee it will keep working."

> > Normally a BAR is for mapping device registers into PCI bus address
> > space.  If this BAR controls how the RC forwards PCI DMA transactions
> > to RAM, then it's not really a BAR and you should prevent Linux from
> > seeing it as a BAR.  You could do this by special-casing it in the
> > config accessor so reads return 0 and writes are dropped.  Then you
> > could write the register in your host bridge driver safely because the
> > PCI core would think the BAR is not implemented.
> 
> In fact, that's what I used to do in a previous version :-)
> 
> I'd like to push support for this PCIe controller upstream.
> 
> Is the code I posted on the right track?
> Maybe I can post a RFC patch tomorrow?

No need to ask before posting a patch :)
--
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: smsc95xx: Reduce logging noise

[David Miller]

From: Guenter Roeck 
Date: Fri, 10 Mar 2017 17:45:21 -0800

> An insert/remove stress test generated the following log message sequence.
...
> Use netdev_dbg() instead of netdev_warn() for the repeating messages
> to reduce logging noise.
> 
> Signed-off-by: Guenter Roeck 

The problem I have with changes like this is that outside of your
stress test situation these messages are extremely useful but will
now be hidden making diagnosis of problems more difficult.

Perhaps you can check the error code or some piece of USB device
state to see if there was a disconnect, and elide the log message
in that case specifically.

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

Re: [PATCH] net: usb: asix88179_178a: use new api ethtool_{get|set}_link_ksettings

[David Miller]

From: Philippe Reynes 
Date: Sun, 12 Mar 2017 18:02:36 +0100

> The ethtool api {get|set}_settings is deprecated.
> We move this driver to new api {get|set}_link_ksettings.
> 
> As I don't have the hardware, I'd be very pleased if
> someone may test this patch.
> 
> Signed-off-by: Philippe Reynes 

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

Re: [PATCH] net: usb: catc: use new api ethtool_{get|set}_link_ksettings

[David Miller]

From: Philippe Reynes 
Date: Sun, 12 Mar 2017 22:08:26 +0100

> The ethtool api {get|set}_settings is deprecated.
> We move this driver to new api {get|set}_link_ksettings.
> 
> As I don't have the hardware, I'd be very pleased if
> someone may test this patch.
> 
> Signed-off-by: Philippe Reynes 

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

Re: [PATCH] net: usb: r8152: use new api ethtool_{get|set}_link_ksettings

[David Miller]

From: Philippe Reynes 
Date: Sun, 12 Mar 2017 22:41:58 +0100

> The ethtool api {get|set}_settings is deprecated.
> We move this driver to new api {get|set}_link_ksettings.
> 
> As I don't have the hardware, I'd be very pleased if
> someone may test this patch.
> 
> Signed-off-by: Philippe Reynes 

Applied.
--
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] [for 4.11]xhci: plat: Register shutdown for xhci_plat

[Adam Wallis]

Shutdown should be called for xhci_plat devices especially for
situations where kexec might be used by stopping DMA
transactions.

Signed-off-by: Adam Wallis 
---
 drivers/usb/host/xhci-plat.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index bd02a6c..6ed468f 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -344,6 +344,7 @@ static int xhci_plat_resume(struct device *dev)
 static struct platform_driver usb_xhci_driver = {
.probe  = xhci_plat_probe,
.remove = xhci_plat_remove,
+   .shutdown   = usb_hcd_platform_shutdown,
.driver = {
.name = "xhci-hcd",
.pm = DEV_PM_OPS,
-- 
Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.

--
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: Neophyte questions about PCIe

[Mason]

On 13/03/2017 22:40, Bjorn Helgaas wrote:

> On Sat, Mar 11, 2017 at 11:57:56AM +0100, Mason wrote:
>
>> On 10/03/2017 18:49, Mason wrote:
>> 
>>> static void tango_pcie_bar_quirk(struct pci_dev *dev)
>>> {
>>> struct pci_bus *bus = dev->bus;
>>>
>>> printk("%s: bus=%d devfn=%d\n", __func__, bus->number, dev->devfn);
>>>
>>> pci_write_config_dword(dev, PCI_BASE_ADDRESS_0, 0x8004);
>>> }
>>> DECLARE_PCI_FIXUP_FINAL(0x1105, PCI_ANY_ID, tango_pcie_bar_quirk);
>>
>> And this is where the elusive "black magic" happens.
>>
>> Is it "safe" to configure a BAR behind Linux's back?
> 
> No.  Linux maintains a struct resource for every BAR.  This quirk
> makes the BAR out of sync with the resource, so Linux no longer has an
> accurate idea of what bus address space is consumed and what is
> available.

Even when Linux is not able to map the BAR, since it's too
large to fit in the mem window?

> Normally a BAR is for mapping device registers into PCI bus address
> space.  If this BAR controls how the RC forwards PCI DMA transactions
> to RAM, then it's not really a BAR and you should prevent Linux from
> seeing it as a BAR.  You could do this by special-casing it in the
> config accessor so reads return 0 and writes are dropped.  Then you
> could write the register in your host bridge driver safely because the
> PCI core would think the BAR is not implemented.

In fact, that's what I used to do in a previous version :-)

I'd like to push support for this PCIe controller upstream.

Is the code I posted on the right track?
Maybe I can post a RFC patch tomorrow?

Regards.
--
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] [for 4.11]xhci: plat: Register shutdown for xhci_plat

[Greg KH]

On Mon, Mar 13, 2017 at 05:21:14PM -0400, Adam Wallis wrote:
> Shutdown should be called for xhci_plat devices especially for
> situations where kexec might be used by stopping DMA
> transactions.
> 
> Signed-off-by: Adam Wallis 
> ---
>  drivers/usb/host/xhci-plat.c | 1 +
>  1 file changed, 1 insertion(+)

$ ./scripts/get_maintainer.pl --file drivers/usb/host/xhci-plat.c
Mathias Nyman  (supporter:USB XHCI DRIVER)

:(
--
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: Neophyte questions about PCIe

[Bjorn Helgaas]

On Sat, Mar 11, 2017 at 11:57:56AM +0100, Mason wrote:
> On 10/03/2017 18:49, Mason wrote:

> > static void tango_pcie_bar_quirk(struct pci_dev *dev)
> > {
> > struct pci_bus *bus = dev->bus;
> > 
> > printk("%s: bus=%d devfn=%d\n", __func__, bus->number, dev->devfn);
> > 
> > pci_write_config_dword(dev, PCI_BASE_ADDRESS_0, 0x8004);
> > }
> > DECLARE_PCI_FIXUP_FINAL(0x1105, PCI_ANY_ID, tango_pcie_bar_quirk);
> 
> And this is where the elusive "black magic" happens.
> 
> Is it "safe" to configure a BAR behind Linux's back?

No.  Linux maintains a struct resource for every BAR.  This quirk
makes the BAR out of sync with the resource, so Linux no longer has an
accurate idea of what bus address space is consumed and what is
available.

Normally a BAR is for mapping device registers into PCI bus address
space.  If this BAR controls how the RC forwards PCI DMA transactions
to RAM, then it's not really a BAR and you should prevent Linux from
seeing it as a BAR.  You could do this by special-casing it in the
config accessor so reads return 0 and writes are dropped.  Then you
could write the register in your host bridge driver safely because the
PCI core would think the BAR is not implemented.

Bjorn
--
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] [for 4.11]xhci: plat: Register shutdown for xhci_plat

[Adam Wallis]

Shutdown should be called for xhci_plat devices especially for
situations where kexec might be used by stopping DMA
transactions.

Signed-off-by: Adam Wallis 
---
 drivers/usb/host/xhci-plat.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index bd02a6c..6ed468f 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -344,6 +344,7 @@ static int xhci_plat_resume(struct device *dev)
 static struct platform_driver usb_xhci_driver = {
.probe  = xhci_plat_probe,
.remove = xhci_plat_remove,
+   .shutdown   = usb_hcd_platform_shutdown,
.driver = {
.name = "xhci-hcd",
.pm = DEV_PM_OPS,
-- 
Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.

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

[PATCHv3] usb-core: Add LINEAR_FRAME_INTR_BINTERVAL USB quirk

[Samuel Thibault]

Some USB 2.0 devices erroneously report millisecond values in
bInterval. The generic config code manages to catch most of them,
but in some cases it's not completely enough.

The case at stake here is a USB 2.0 braille device, which wants to
announce 10ms and thus sets bInterval to 10, but with the USB 2.0
computation that yields to 64ms.  It happens that one can type fast
enough to reach this interval and get the device buffers overflown,
leading to problematic latencies.  The generic config code does not
catch this case because the 64ms is considered a sane enough value.

This change thus adds a USB_QUIRK_LINEAR_FRAME_INTR_BINTERVAL quirk
to mark devices which actually report milliseconds in bInterval,
and marks Vario Ultra devices as needing it.

Signed-off-by: Samuel Thibault 
Acked-by: Alan Stern 

--- a/include/linux/usb/quirks.h
+++ b/include/linux/usb/quirks.h
@@ -50,4 +50,10 @@
 /* device can't handle Link Power Management */
 #define USB_QUIRK_NO_LPM   BIT(10)
 
+/*
+ * Device reports its bInterval as linear frames instead of the
+ * USB 2.0 calculation.
+ */
+#define USB_QUIRK_LINEAR_FRAME_INTR_BINTERVAL  BIT(11)
+
 #endif /* __LINUX_USB_QUIRKS_H */
--- a/drivers/usb/core/config.c
+++ b/drivers/usb/core/config.c
@@ -280,6 +280,16 @@ static int usb_parse_endpoint(struct dev
 
/*
 * Adjust bInterval for quirked devices.
+*/
+   /*
+* This quirk fixes bIntervals reported in ms.
+*/
+   if (to_usb_device(ddev)->quirks &
+   USB_QUIRK_LINEAR_FRAME_INTR_BINTERVAL) {
+   n = clamp(fls(d->bInterval) + 3, i, j);
+   i = j = n;
+   }
+   /*
 * This quirk fixes bIntervals reported in
 * linear microframes.
 */
--- a/drivers/usb/core/quirks.c
+++ b/drivers/usb/core/quirks.c
@@ -170,6 +170,14 @@ static const struct usb_device_id usb_qu
/* M-Systems Flash Disk Pioneers */
{ USB_DEVICE(0x08ec, 0x1000), .driver_info = USB_QUIRK_RESET_RESUME },
 
+   /* Baum Vario Ultra */
+   { USB_DEVICE(0x0904, 0x6101), .driver_info =
+   USB_QUIRK_LINEAR_FRAME_INTR_BINTERVAL },
+   { USB_DEVICE(0x0904, 0x6102), .driver_info =
+   USB_QUIRK_LINEAR_FRAME_INTR_BINTERVAL },
+   { USB_DEVICE(0x0904, 0x6103), .driver_info =
+   USB_QUIRK_LINEAR_FRAME_INTR_BINTERVAL },
+
/* Keytouch QWERTY Panel keyboard */
{ USB_DEVICE(0x0926, 0x), .driver_info =
USB_QUIRK_CONFIG_INTF_STRINGS },
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] net: wimax/i2400m: fix NULL-deref at probe

[David Miller]

From: Johan Hovold 
Date: Mon, 13 Mar 2017 13:42:03 +0100

> Make sure to check the number of endpoints to avoid dereferencing a
> NULL-pointer or accessing memory beyond the endpoint array should a
> malicious device lack the expected endpoints.
> 
> The endpoints are specifically dereferenced in the i2400m_bootrom_init
> path during probe (e.g. in i2400mu_tx_bulk_out).
> 
> Fixes: f398e4240fce ("i2400m/USB: probe/disconnect, dev init/shutdown
> and reset backends")
> Cc: Inaky Perez-Gonzalez 
> 
> Signed-off-by: Johan Hovold 

Applied.
--
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] isdn/gigaset: fix NULL-deref at probe

[David Miller]

From: Johan Hovold 
Date: Mon, 13 Mar 2017 13:39:01 +0100

> Make sure to check the number of endpoints to avoid dereferencing a
> NULL-pointer should a malicious device lack endpoints.
> 
> Fixes: cf7776dc05b8 ("[PATCH] isdn4linux: Siemens Gigaset drivers -
> direct USB connection")
> Cc: stable    # 2.6.17
> Cc: Hansjoerg Lipp 
> 
> Signed-off-by: Johan Hovold 

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

Re: [PATCH] net: usb: asix88179_178a: use new api ethtool_{get|set}_link_ksettings

[Chris Roth]

I have tested this patch on the Cypress GX3 SuperSpeed to Gigabit Ethernet
Bridge Controller (Vendor=04b4 ProdID=3610) and the device still
functions properly with the patch applied.

Feel free to add my name / email to the tested-by portion of the patch.

Chris


On 2017-03-12 11:02 AM, Philippe Reynes wrote:
> The ethtool api {get|set}_settings is deprecated.
> We move this driver to new api {get|set}_link_ksettings.
>
> As I don't have the hardware, I'd be very pleased if
> someone may test this patch.
>
> Signed-off-by: Philippe Reynes 
> ---
>  drivers/net/usb/ax88179_178a.c |   14 --
>  1 files changed, 8 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/net/usb/ax88179_178a.c b/drivers/net/usb/ax88179_178a.c
> index a3a7db0..4a0ae7c 100644
> --- a/drivers/net/usb/ax88179_178a.c
> +++ b/drivers/net/usb/ax88179_178a.c
> @@ -620,16 +620,18 @@ static int ax88179_get_eeprom_len(struct net_device 
> *net)
>   return 0;
>  }
>  
> -static int ax88179_get_settings(struct net_device *net, struct ethtool_cmd 
> *cmd)
> +static int ax88179_get_link_ksettings(struct net_device *net,
> +   struct ethtool_link_ksettings *cmd)
>  {
>   struct usbnet *dev = netdev_priv(net);
> - return mii_ethtool_gset(>mii, cmd);
> + return mii_ethtool_get_link_ksettings(>mii, cmd);
>  }
>  
> -static int ax88179_set_settings(struct net_device *net, struct ethtool_cmd 
> *cmd)
> +static int ax88179_set_link_ksettings(struct net_device *net,
> +   const struct ethtool_link_ksettings *cmd)
>  {
>   struct usbnet *dev = netdev_priv(net);
> - return mii_ethtool_sset(>mii, cmd);
> + return mii_ethtool_set_link_ksettings(>mii, cmd);
>  }
>  
>  static int
> @@ -826,11 +828,11 @@ static int ax88179_ioctl(struct net_device *net, struct 
> ifreq *rq, int cmd)
>   .set_wol= ax88179_set_wol,
>   .get_eeprom_len = ax88179_get_eeprom_len,
>   .get_eeprom = ax88179_get_eeprom,
> - .get_settings   = ax88179_get_settings,
> - .set_settings   = ax88179_set_settings,
>   .get_eee= ax88179_get_eee,
>   .set_eee= ax88179_set_eee,
>   .nway_reset = usbnet_nway_reset,
> + .get_link_ksettings = ax88179_get_link_ksettings,
> + .set_link_ksettings = ax88179_set_link_ksettings,
>  };
>  
>  static void ax88179_set_multicast(struct net_device *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] watchdog: pcwd_usb: fix NULL-deref at probe

[Guenter Roeck]

On Mon, Mar 13, 2017 at 03:17:39PM +0100, Johan Hovold wrote:
> [ Adding linux-usb which I forgot to CC for this one ]
> 
> On Mon, Mar 13, 2017 at 06:42:45AM -0700, Guenter Roeck wrote:
> > On 03/13/2017 05:49 AM, Johan Hovold wrote:
> > > Make sure to check the number of endpoints to avoid dereferencing a
> > > NULL-pointer should a malicious device lack endpoints.
> > >
> > 
> > Is this theory or was it actually observed ?
> 
> This was found through inspection, but creating a USB device to crash a
> host with this driver enabled is easily done.
> 
Ok, makes sense. I see other drivers doing a similar check.

Guenter

> > > Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> > > Cc: stable 
> > > Signed-off-by: Johan Hovold 
> > > ---
> > >  drivers/watchdog/pcwd_usb.c | 3 +++
> > >  1 file changed, 3 insertions(+)
> > >
> > > diff --git a/drivers/watchdog/pcwd_usb.c b/drivers/watchdog/pcwd_usb.c
> > > index 99ebf6ea3de6..5615f4013924 100644
> > > --- a/drivers/watchdog/pcwd_usb.c
> > > +++ b/drivers/watchdog/pcwd_usb.c
> > > @@ -630,6 +630,9 @@ static int usb_pcwd_probe(struct usb_interface 
> > > *interface,
> > >   return -ENODEV;
> > >   }
> > >
> > > + if (iface_desc->desc.bNumEndpoints < 1)
> > > + return -ENODEV;
> > > +
> > >   /* check out the endpoint: it has to be Interrupt & IN */
> > >   endpoint = _desc->endpoint[0].desc;
> > >
> > >
> 
> Johan
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 0/5] USB: serial: ftdi_sio: latency timer and other stuff

[Johan Hovold]

On Wed, Mar 08, 2017 at 04:02:56PM +, Ian Abbott wrote:
> Some patches to skip accessing the FTDI latency timer on chips that
> don't support it, detect "BM" chips with iSerialNumber bug, validate
> written device attribute values, and allow hex and octal "event_char"
> values.
> 
> This is v2 of the patch series, incorporating changes suggested by
> Johan.  The original patch 5 has been folded into v2 patches 3 and 4
> with minor changes.
> 
> 1) USB: serial: ftdi_sio: don't access latency timer on old chips
> 2) USB: serial: ftdi_sio: detect BM chip with iSerialNumber bug
> 3) USB: serial: ftdi_sio: only allow valid latency timer values
> 4) USB: serial: ftdi_sio: only allow valid event_char values
> 5) USB: serial: ftdi_sio: allow other bases for "event_char"
>
> 
>  drivers/usb/serial/ftdi_sio.c | 52 
> ---
>  1 file changed, 44 insertions(+), 8 deletions(-)

Thanks for the v2. Series now applied for next.

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

Re: [PATCH 0/7] Input: fix NULL-derefs at probe

[Johan Hovold]

On Mon, Mar 13, 2017 at 04:15:18PM +0100, Oliver Neukum wrote:
> Am Montag, den 13.03.2017, 13:35 +0100 schrieb Johan Hovold:
> > This series fixes a number of NULL-pointer dereferences due to
> > missing
> > endpoint sanity checks that can be triggered by a malicious USB
> > device.
>
> At the risk of repeating myself, doesn't the sheer number of fixes
> demonstrate the need for a more centralized check?

No, I don't think that follows. These are plain bugs that needs to be
fixed (cf. not checking for allocation failures or whatever) and
backported to the stable trees.

I think I may have surveyed just about every USB driver this last week,
and there is no single pattern for how endpoints are verified and
retrieved that could easily be refactored into USB core.

Now there are certain patterns that could benefit from a few helpers,
and some obvious bugs could then be caught by declaring those helpers as
__must_check. But specifically, you'd still be checking the return
value from the helpers.

Then verifying the endpoint counts before calling driver probe,
typically only saves a bit of time while probing *malicious* devices
(and the occasional odd interface which cannot be matched on other
attributes).

That being said, we could still add a centralised sanity check for a
large class of drivers (e.g. that do not use altsettings and only need
minimum constraints) but it's not going to obviate the need for careful
driver implementations.

I'll be posting some more patches related to this shortly.

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

Re: [PATCH 0/7] Input: fix NULL-derefs at probe

[Oliver Neukum]

Am Montag, den 13.03.2017, 13:35 +0100 schrieb Johan Hovold:
> This series fixes a number of NULL-pointer dereferences due to
> missing
> endpoint sanity checks that can be triggered by a malicious USB
> device.
> 
At the risk of repeating myself, doesn't the sheer number of fixes
demonstrate the need for a more centralized check?

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: [PATCH] net: usb: rtl8150: use new api ethtool_{get|set}_link_ksettings

[Petko Manolov]

On 17-03-12 23:16:25, Philippe Reynes wrote:
> The ethtool api {get|set}_settings is deprecated.
> We move this driver to new api {get|set}_link_ksettings.
> 
> As I don't have the hardware, I'd be very pleased if someone may test this 
> patch.

I've got some old adapters around and will drop you a line when i test the 
patch.


Petko


> Signed-off-by: Philippe Reynes 
> ---
>  drivers/net/usb/rtl8150.c |   35 ---
>  1 files changed, 20 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/net/usb/rtl8150.c b/drivers/net/usb/rtl8150.c
> index c81c791..daaa88a 100644
> --- a/drivers/net/usb/rtl8150.c
> +++ b/drivers/net/usb/rtl8150.c
> @@ -791,47 +791,52 @@ static void rtl8150_get_drvinfo(struct net_device 
> *netdev, struct ethtool_drvinf
>   usb_make_path(dev->udev, info->bus_info, sizeof(info->bus_info));
>  }
>  
> -static int rtl8150_get_settings(struct net_device *netdev, struct 
> ethtool_cmd *ecmd)
> +static int rtl8150_get_link_ksettings(struct net_device *netdev,
> +   struct ethtool_link_ksettings *ecmd)
>  {
>   rtl8150_t *dev = netdev_priv(netdev);
>   short lpa, bmcr;
> + u32 supported;
>  
> - ecmd->supported = (SUPPORTED_10baseT_Half |
> + supported = (SUPPORTED_10baseT_Half |
> SUPPORTED_10baseT_Full |
> SUPPORTED_100baseT_Half |
> SUPPORTED_100baseT_Full |
> SUPPORTED_Autoneg |
> SUPPORTED_TP | SUPPORTED_MII);
> - ecmd->port = PORT_TP;
> - ecmd->transceiver = XCVR_INTERNAL;
> - ecmd->phy_address = dev->phy;
> + ecmd->base.port = PORT_TP;
> + ecmd->base.phy_address = dev->phy;
>   get_registers(dev, BMCR, 2, );
>   get_registers(dev, ANLP, 2, );
>   if (bmcr & BMCR_ANENABLE) {
>   u32 speed = ((lpa & (LPA_100HALF | LPA_100FULL)) ?
>SPEED_100 : SPEED_10);
> - ethtool_cmd_speed_set(ecmd, speed);
> - ecmd->autoneg = AUTONEG_ENABLE;
> + ecmd->base.speed = speed;
> + ecmd->base.autoneg = AUTONEG_ENABLE;
>   if (speed == SPEED_100)
> - ecmd->duplex = (lpa & LPA_100FULL) ?
> + ecmd->base.duplex = (lpa & LPA_100FULL) ?
>   DUPLEX_FULL : DUPLEX_HALF;
>   else
> - ecmd->duplex = (lpa & LPA_10FULL) ?
> + ecmd->base.duplex = (lpa & LPA_10FULL) ?
>   DUPLEX_FULL : DUPLEX_HALF;
>   } else {
> - ecmd->autoneg = AUTONEG_DISABLE;
> - ethtool_cmd_speed_set(ecmd, ((bmcr & BMCR_SPEED100) ?
> -  SPEED_100 : SPEED_10));
> - ecmd->duplex = (bmcr & BMCR_FULLDPLX) ?
> + ecmd->base.autoneg = AUTONEG_DISABLE;
> + ecmd->base.speed = ((bmcr & BMCR_SPEED100) ?
> +  SPEED_100 : SPEED_10);
> + ecmd->base.duplex = (bmcr & BMCR_FULLDPLX) ?
>   DUPLEX_FULL : DUPLEX_HALF;
>   }
> +
> + ethtool_convert_legacy_u32_to_link_mode(ecmd->link_modes.supported,
> + supported);
> +
>   return 0;
>  }
>  
>  static const struct ethtool_ops ops = {
>   .get_drvinfo = rtl8150_get_drvinfo,
> - .get_settings = rtl8150_get_settings,
> - .get_link = ethtool_op_get_link
> + .get_link = ethtool_op_get_link,
> + .get_link_ksettings = rtl8150_get_link_ksettings,
>  };
>  
>  static int rtl8150_ioctl(struct net_device *netdev, struct ifreq *rq, int 
> cmd)
> -- 
> 1.7.4.4
> 
> 
--
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 v3 1/2] usb: dwc3: refactor gadget endpoint count calculation

[Bryan O'Donoghue]

On 13/03/17 11:56, Felipe Balbi wrote:

Bryan O'Donoghue  writes:

On 10/03/17 12:14, Felipe Balbi wrote:



return 0;

I can change your patch locally, if you want. I can also drop your
patches and wait for replacements. No strong feelings.



I'll resend Felipe.


thank you, please test multiple connect/disconnect cycles :-)

I had some issues related to those.



Ah that would explain the disparity - cheers :)
--
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: gadget: delay unmap of bounced requests

[Felipe Balbi]

From: Janusz Dziedzic 

In the case of bounced ep0 requests, we must delay DMA operation until
after ->complete() otherwise we might overwrite contents of req->buf.

This caused problems with RNDIS gadget.

Signed-off-by: Janusz Dziedzic 
Signed-off-by: Felipe Balbi 
---
 drivers/usb/dwc3/gadget.c | 21 +
 1 file changed, 17 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 0d75158e43fe..79e7a3480d51 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -171,6 +171,7 @@ void dwc3_gadget_giveback(struct dwc3_ep *dep, struct 
dwc3_request *req,
int status)
 {
struct dwc3 *dwc = dep->dwc;
+   unsigned intunmap_after_complete = false;
 
req->started = false;
list_del(>list);
@@ -180,11 +181,19 @@ void dwc3_gadget_giveback(struct dwc3_ep *dep, struct 
dwc3_request *req,
if (req->request.status == -EINPROGRESS)
req->request.status = status;
 
-   if (dwc->ep0_bounced && dep->number <= 1)
+   /*
+* NOTICE we don't want to unmap before calling ->complete() if we're
+* dealing with a bounced ep0 request. If we unmap it here, we would end
+* up overwritting the contents of req->buf and this could confuse the
+* gadget driver.
+*/
+   if (dwc->ep0_bounced && dep->number <= 1) {
dwc->ep0_bounced = false;
-
-   usb_gadget_unmap_request_by_dev(dwc->sysdev,
-   >request, req->direction);
+   unmap_after_complete = true;
+   } else {
+   usb_gadget_unmap_request_by_dev(dwc->sysdev,
+   >request, req->direction);
+   }
 
trace_dwc3_gadget_giveback(req);
 
@@ -192,6 +201,10 @@ void dwc3_gadget_giveback(struct dwc3_ep *dep, struct 
dwc3_request *req,
usb_gadget_giveback_request(>endpoint, >request);
spin_lock(>lock);
 
+   if (unmap_after_complete)
+   usb_gadget_unmap_request_by_dev(dwc->sysdev,
+   >request, req->direction);
+
if (dep->number > 1)
pm_runtime_put(dwc->dev);
 }
-- 
2.11.0.295.gd7dffce1ce

--
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] watchdog: pcwd_usb: fix NULL-deref at probe

[Johan Hovold]

[ Adding linux-usb which I forgot to CC for this one ]

On Mon, Mar 13, 2017 at 06:42:45AM -0700, Guenter Roeck wrote:
> On 03/13/2017 05:49 AM, Johan Hovold wrote:
> > Make sure to check the number of endpoints to avoid dereferencing a
> > NULL-pointer should a malicious device lack endpoints.
> >
> 
> Is this theory or was it actually observed ?

This was found through inspection, but creating a USB device to crash a
host with this driver enabled is easily done.

> > Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> > Cc: stable 
> > Signed-off-by: Johan Hovold 
> > ---
> >  drivers/watchdog/pcwd_usb.c | 3 +++
> >  1 file changed, 3 insertions(+)
> >
> > diff --git a/drivers/watchdog/pcwd_usb.c b/drivers/watchdog/pcwd_usb.c
> > index 99ebf6ea3de6..5615f4013924 100644
> > --- a/drivers/watchdog/pcwd_usb.c
> > +++ b/drivers/watchdog/pcwd_usb.c
> > @@ -630,6 +630,9 @@ static int usb_pcwd_probe(struct usb_interface 
> > *interface,
> > return -ENODEV;
> > }
> >
> > +   if (iface_desc->desc.bNumEndpoints < 1)
> > +   return -ENODEV;
> > +
> > /* check out the endpoint: it has to be Interrupt & IN */
> > endpoint = _desc->endpoint[0].desc;
> >
> >

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

[PATCH 5/6] uwb: hwa-rc: fix NULL-deref at probe

[Johan Hovold]

Make sure to check the number of endpoints to avoid dereferencing a
NULL-pointer should a malicious device lack endpoints.

Note that the dereference happens in the start callback which is called
during probe.

Fixes: de520b8bd552 ("uwb: add HWA radio controller driver")
Cc: stable  # 2.6.28
Cc: Inaky Perez-Gonzalez 
Cc: David Vrabel 
Signed-off-by: Johan Hovold 
---
 drivers/uwb/hwa-rc.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/uwb/hwa-rc.c b/drivers/uwb/hwa-rc.c
index 0aa6c3c29d17..35a1e777b449 100644
--- a/drivers/uwb/hwa-rc.c
+++ b/drivers/uwb/hwa-rc.c
@@ -823,6 +823,9 @@ static int hwarc_probe(struct usb_interface *iface,
struct hwarc *hwarc;
struct device *dev = >dev;
 
+   if (iface->cur_altsetting->desc.bNumEndpoints < 1)
+   return -ENODEV;
+
result = -ENOMEM;
uwb_rc = uwb_rc_alloc();
if (uwb_rc == NULL) {
-- 
2.12.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 1/6] USB: idmouse: fix NULL-deref at probe

[Johan Hovold]

Make sure to check the number of endpoints to avoid dereferencing a
NULL-pointer should a malicious device lack endpoints.

Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: stable 
Signed-off-by: Johan Hovold 
---
 drivers/usb/misc/idmouse.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/usb/misc/idmouse.c b/drivers/usb/misc/idmouse.c
index 8b9fd7534f69..502bfe30a077 100644
--- a/drivers/usb/misc/idmouse.c
+++ b/drivers/usb/misc/idmouse.c
@@ -347,6 +347,9 @@ static int idmouse_probe(struct usb_interface *interface,
if (iface_desc->desc.bInterfaceClass != 0x0A)
return -ENODEV;
 
+   if (iface_desc->desc.bNumEndpoints < 1)
+   return -ENODEV;
+
/* allocate memory for our device state and initialize it */
dev = kzalloc(sizeof(*dev), GFP_KERNEL);
if (dev == NULL)
-- 
2.12.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 6/6] uwb: i1480-dfu: fix NULL-deref at probe

[Johan Hovold]

Make sure to check the number of endpoints to avoid dereferencing a
NULL-pointer should a malicious device lack endpoints.

Note that the dereference happens in the cmd and wait_init_done
callbacks which are called during probe.

Fixes: 1ba47da52712 ("uwb: add the i1480 DFU driver")
Cc: stable  # 2.6.28
Cc: Inaky Perez-Gonzalez 
Cc: David Vrabel 
Signed-off-by: Johan Hovold 
---
 drivers/uwb/i1480/dfu/usb.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/uwb/i1480/dfu/usb.c b/drivers/uwb/i1480/dfu/usb.c
index 2bfc846ac071..6345e85822a4 100644
--- a/drivers/uwb/i1480/dfu/usb.c
+++ b/drivers/uwb/i1480/dfu/usb.c
@@ -362,6 +362,9 @@ int i1480_usb_probe(struct usb_interface *iface, const 
struct usb_device_id *id)
 result);
}
 
+   if (iface->cur_altsetting->desc.bNumEndpoints < 1)
+   return -ENODEV;
+
result = -ENOMEM;
i1480_usb = kzalloc(sizeof(*i1480_usb), GFP_KERNEL);
if (i1480_usb == NULL) {
-- 
2.12.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 3/6] USB: uss720: fix NULL-deref at probe

[Johan Hovold]

Make sure to check the number of endpoints to avoid dereferencing a
NULL-pointer or accessing memory beyond the endpoint array should a
malicious device lack the expected endpoints.

Note that the endpoint access that causes the NULL-deref is currently
only used for debugging purposes during probe so the oops only happens
when dynamic debugging is enabled. This means the driver could be
rewritten to continue to accept device with only two endpoints, should
such devices exist.

Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: stable 
Signed-off-by: Johan Hovold 
---
 drivers/usb/misc/uss720.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/usb/misc/uss720.c b/drivers/usb/misc/uss720.c
index e45a3a680db8..07014cad6dbe 100644
--- a/drivers/usb/misc/uss720.c
+++ b/drivers/usb/misc/uss720.c
@@ -709,6 +709,11 @@ static int uss720_probe(struct usb_interface *intf,
 
interface = intf->cur_altsetting;
 
+   if (interface->desc.bNumEndpoints < 3) {
+   usb_put_dev(usbdev);
+   return -ENODEV;
+   }
+
/*
 * Allocate parport interface 
 */
-- 
2.12.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 2/6] USB: lvtest: fix NULL-deref at probe

[Johan Hovold]

Make sure to check the number of endpoints to avoid dereferencing a
NULL-pointer should the probed device lack endpoints.

Note that this driver does not bind to any devices by default.

Fixes: ce21bfe603b3 ("USB: Add LVS Test device driver")
Cc: stable  # 3.17
Cc: Pratyush Anand 
Signed-off-by: Johan Hovold 
---
 drivers/usb/misc/lvstest.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/usb/misc/lvstest.c b/drivers/usb/misc/lvstest.c
index 77176511658f..d3d124753266 100644
--- a/drivers/usb/misc/lvstest.c
+++ b/drivers/usb/misc/lvstest.c
@@ -366,6 +366,10 @@ static int lvs_rh_probe(struct usb_interface *intf,
 
hdev = interface_to_usbdev(intf);
desc = intf->cur_altsetting;
+
+   if (desc->desc.bNumEndpoints < 1)
+   return -ENODEV;
+
endpoint = >endpoint[0].desc;
 
/* valid only for SS root hub */
-- 
2.12.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 4/6] USB: wusbcore: fix NULL-deref at probe

[Johan Hovold]

Make sure to check the number of endpoints to avoid dereferencing a
NULL-pointer or accessing memory beyond the endpoint array should a
malicious device lack the expected endpoints.

This specifically fixes the NULL-pointer dereference when probing HWA HC
devices.

Fixes: df3654236e31 ("wusb: add the Wire Adapter (WA) core")
Cc: stable  # 2.6.28
Cc: Inaky Perez-Gonzalez 
Cc: David Vrabel 
Signed-off-by: Johan Hovold 
---
 drivers/usb/wusbcore/wa-hc.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/usb/wusbcore/wa-hc.c b/drivers/usb/wusbcore/wa-hc.c
index 252c7bd9218a..d01496fd27fe 100644
--- a/drivers/usb/wusbcore/wa-hc.c
+++ b/drivers/usb/wusbcore/wa-hc.c
@@ -39,6 +39,9 @@ int wa_create(struct wahc *wa, struct usb_interface *iface,
int result;
struct device *dev = >dev;
 
+   if (iface->cur_altsetting->desc.bNumEndpoints < 3)
+   return -ENODEV;
+
result = wa_rpipes_create(wa);
if (result < 0)
goto error_rpipes_create;
-- 
2.12.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 0/6] USB: fix missing endpoint sanity checks

[Johan Hovold]

This series fixes a number of NULL-pointer dereferences due to missing
endpoint sanity checks that can be triggered by a malicious device.

Johan


Johan Hovold (6):
  USB: idmouse: fix NULL-deref at probe
  USB: lvtest: fix NULL-deref at probe
  USB: uss720: fix NULL-deref at probe
  USB: wusbcore: fix NULL-deref at probe
  uwb: hwa-rc: fix NULL-deref at probe
  uwb: i1480-dfu: fix NULL-deref at probe

 drivers/usb/misc/idmouse.c   | 3 +++
 drivers/usb/misc/lvstest.c   | 4 
 drivers/usb/misc/uss720.c| 5 +
 drivers/usb/wusbcore/wa-hc.c | 3 +++
 drivers/uwb/hwa-rc.c | 3 +++
 drivers/uwb/i1480/dfu/usb.c  | 3 +++
 6 files changed, 21 insertions(+)

-- 
2.12.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 2/2] wireless: zd1211rw: fix NULL-deref at probe

[Johan Hovold]

Make sure to check the number of endpoints to avoid dereferencing a
NULL-pointer or accessing memory beyond the endpoint array should a
malicious device lack the expected endpoints.

Fixes: a1030e92c150 ("[PATCH] zd1211rw: Convert installer CDROM device
into WLAN device")
Cc: Daniel Drake 

Signed-off-by: Johan Hovold 
---
 drivers/net/wireless/zydas/zd1211rw/zd_usb.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/net/wireless/zydas/zd1211rw/zd_usb.c 
b/drivers/net/wireless/zydas/zd1211rw/zd_usb.c
index c5effd6c6be9..01ca1d57b3d9 100644
--- a/drivers/net/wireless/zydas/zd1211rw/zd_usb.c
+++ b/drivers/net/wireless/zydas/zd1211rw/zd_usb.c
@@ -1278,6 +1278,9 @@ static int eject_installer(struct usb_interface *intf)
u8 bulk_out_ep;
int r;
 
+   if (iface_desc->desc.bNumEndpoints < 2)
+   return -ENODEV;
+
/* Find bulk out endpoint */
for (r = 1; r >= 0; r--) {
endpoint = _desc->endpoint[r].desc;
-- 
2.12.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 1/2] wireless: ath9k_htc: fix NULL-deref at probe

[Johan Hovold]

Make sure to check the number of endpoints to avoid dereferencing a
NULL-pointer or accessing memory beyond the endpoint array should a
malicious device lack the expected endpoints.

Fixes: 36bcce430657 ("ath9k_htc: Handle storage devices")
Cc: Sujith Manoharan 
Signed-off-by: Johan Hovold 
---
 drivers/net/wireless/ath/ath9k/hif_usb.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/net/wireless/ath/ath9k/hif_usb.c 
b/drivers/net/wireless/ath/ath9k/hif_usb.c
index de2d212f39ec..9206955e865a 100644
--- a/drivers/net/wireless/ath/ath9k/hif_usb.c
+++ b/drivers/net/wireless/ath/ath9k/hif_usb.c
@@ -1219,6 +1219,9 @@ static int send_eject_command(struct usb_interface 
*interface)
u8 bulk_out_ep;
int r;
 
+   if (iface_desc->desc.bNumEndpoints < 2)
+   return -ENODEV;
+
/* Find bulk out endpoint */
for (r = 1; r >= 0; r--) {
endpoint = _desc->endpoint[r].desc;
-- 
2.12.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] net: wimax/i2400m: fix NULL-deref at probe

[Johan Hovold]

Make sure to check the number of endpoints to avoid dereferencing a
NULL-pointer or accessing memory beyond the endpoint array should a
malicious device lack the expected endpoints.

The endpoints are specifically dereferenced in the i2400m_bootrom_init
path during probe (e.g. in i2400mu_tx_bulk_out).

Fixes: f398e4240fce ("i2400m/USB: probe/disconnect, dev init/shutdown
and reset backends")
Cc: Inaky Perez-Gonzalez 

Signed-off-by: Johan Hovold 
---
 drivers/net/wimax/i2400m/usb.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/net/wimax/i2400m/usb.c b/drivers/net/wimax/i2400m/usb.c
index e7f5910a6519..f8eb66ef2944 100644
--- a/drivers/net/wimax/i2400m/usb.c
+++ b/drivers/net/wimax/i2400m/usb.c
@@ -467,6 +467,9 @@ int i2400mu_probe(struct usb_interface *iface,
struct i2400mu *i2400mu;
struct usb_device *usb_dev = interface_to_usbdev(iface);
 
+   if (iface->cur_altsetting->desc.bNumEndpoints < 4)
+   return -ENODEV;
+
if (usb_dev->speed != USB_SPEED_HIGH)
dev_err(dev, "device not connected as high speed\n");
 
-- 
2.12.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] mmc: ushc: fix NULL-deref at probe

[Johan Hovold]

Make sure to check the number of endpoints to avoid dereferencing a
NULL-pointer should a malicious device lack endpoints.

Fixes: 53f3a9e26ed5 ("mmc: USB SD Host Controller (USHC) driver")
Cc: stable  # 2.6.37
Cc: David Vrabel 
Signed-off-by: Johan Hovold 
---
 drivers/mmc/host/ushc.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/mmc/host/ushc.c b/drivers/mmc/host/ushc.c
index d2c386f09d69..1d843357422e 100644
--- a/drivers/mmc/host/ushc.c
+++ b/drivers/mmc/host/ushc.c
@@ -426,6 +426,9 @@ static int ushc_probe(struct usb_interface *intf, const 
struct usb_device_id *id
struct ushc_data *ushc;
int ret;
 
+   if (intf->cur_altsetting->desc.bNumEndpoints < 1)
+   return -ENODEV;
+
mmc = mmc_alloc_host(sizeof(struct ushc_data), >dev);
if (mmc == NULL)
return -ENOMEM;
-- 
2.12.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] isdn/gigaset: fix NULL-deref at probe

[Johan Hovold]

Make sure to check the number of endpoints to avoid dereferencing a
NULL-pointer should a malicious device lack endpoints.

Fixes: cf7776dc05b8 ("[PATCH] isdn4linux: Siemens Gigaset drivers -
direct USB connection")
Cc: stable  # 2.6.17
Cc: Hansjoerg Lipp 

Signed-off-by: Johan Hovold 
---
 drivers/isdn/gigaset/bas-gigaset.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/isdn/gigaset/bas-gigaset.c 
b/drivers/isdn/gigaset/bas-gigaset.c
index 11e13c56126f..2da3ff650e1d 100644
--- a/drivers/isdn/gigaset/bas-gigaset.c
+++ b/drivers/isdn/gigaset/bas-gigaset.c
@@ -2317,6 +2317,9 @@ static int gigaset_probe(struct usb_interface *interface,
return -ENODEV;
}
 
+   if (hostif->desc.bNumEndpoints < 1)
+   return -ENODEV;
+
dev_info(>dev,
 "%s: Device matched (Vendor: 0x%x, Product: 0x%x)\n",
 __func__, le16_to_cpu(udev->descriptor.idVendor),
-- 
2.12.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 1/7] Input: iforce - fix NULL-deref at probe

[Johan Hovold]

Make sure to check the number of endpoints to avoid dereferencing a
NULL-pointer or accessing memory that lie beyond the end of the endpoint
array should a malicious device lack the expected endpoints.

Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: stable 
Signed-off-by: Johan Hovold 
---
 drivers/input/joystick/iforce/iforce-usb.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/input/joystick/iforce/iforce-usb.c 
b/drivers/input/joystick/iforce/iforce-usb.c
index d96aa27dfcdc..db64adfbe1af 100644
--- a/drivers/input/joystick/iforce/iforce-usb.c
+++ b/drivers/input/joystick/iforce/iforce-usb.c
@@ -141,6 +141,9 @@ static int iforce_usb_probe(struct usb_interface *intf,
 
interface = intf->cur_altsetting;
 
+   if (interface->desc.bNumEndpoints < 2)
+   return -ENODEV;
+
epirq = >endpoint[0].desc;
epout = >endpoint[1].desc;
 
-- 
2.12.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 7/7] Input: sur40 - fix NULL-deref at probe

[Johan Hovold]

Make sure to check the number of endpoints to avoid dereferencing a
NULL-pointer or accessing memory that lie beyond the end of the endpoint
array should a malicious device lack the expected endpoints.

Fixes: bdb5c57f209c ("Input: add sur40 driver for Samsung SUR40 (aka MS
Surface 2.0/Pixelsense)")
Cc: stable  # 3.13
Cc: Florian Echtler 
Cc: David Herrmann 
Cc: Henrik Rydberg 

Signed-off-by: Johan Hovold 
---
 drivers/input/touchscreen/sur40.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/input/touchscreen/sur40.c 
b/drivers/input/touchscreen/sur40.c
index aefb6e11f88a..4c0eecae065c 100644
--- a/drivers/input/touchscreen/sur40.c
+++ b/drivers/input/touchscreen/sur40.c
@@ -527,6 +527,9 @@ static int sur40_probe(struct usb_interface *interface,
if (iface_desc->desc.bInterfaceClass != 0xFF)
return -ENODEV;
 
+   if (iface_desc->desc.bNumEndpoints < 5)
+   return -ENODEV;
+
/* Use endpoint #4 (0x86). */
endpoint = _desc->endpoint[4].desc;
if (endpoint->bEndpointAddress != TOUCH_ENDPOINT)
-- 
2.12.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 3/7] Input: ims-pcu - fix NULL-deref at probe

[Johan Hovold]

Make sure to check the number of endpoints to avoid dereferencing a
NULL-pointer should a malicious device lack control-interface endpoints.

Fixes: 628329d52474 ("Input: add IMS Passenger Control Unit driver")
Cc: stable  # 3.10
Cc: Dmitry Torokhov 
Signed-off-by: Johan Hovold 
---
 drivers/input/misc/ims-pcu.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/input/misc/ims-pcu.c b/drivers/input/misc/ims-pcu.c
index 9c0ea36913b4..f4e8fbec6a94 100644
--- a/drivers/input/misc/ims-pcu.c
+++ b/drivers/input/misc/ims-pcu.c
@@ -1667,6 +1667,10 @@ static int ims_pcu_parse_cdc_data(struct usb_interface 
*intf, struct ims_pcu *pc
return -EINVAL;
 
alt = pcu->ctrl_intf->cur_altsetting;
+
+   if (alt->desc.bNumEndpoints < 1)
+   return -ENODEV;
+
pcu->ep_ctrl = >endpoint[0].desc;
pcu->max_ctrl_size = usb_endpoint_maxp(pcu->ep_ctrl);
 
-- 
2.12.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 6/7] Input: kbtab - fix NULL-deref at probe

[Johan Hovold]

Make sure to check the number of endpoints to avoid dereferencing a
NULL-pointer should a malicious device lack endpoints.

Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: stable 
Signed-off-by: Johan Hovold 
---
 drivers/input/tablet/kbtab.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/input/tablet/kbtab.c b/drivers/input/tablet/kbtab.c
index e850d7e8afbc..4d9d64908b59 100644
--- a/drivers/input/tablet/kbtab.c
+++ b/drivers/input/tablet/kbtab.c
@@ -122,6 +122,9 @@ static int kbtab_probe(struct usb_interface *intf, const 
struct usb_device_id *i
struct input_dev *input_dev;
int error = -ENOMEM;
 
+   if (intf->cur_altsetting->desc.bNumEndpoints < 1)
+   return -ENODEV;
+
kbtab = kzalloc(sizeof(struct kbtab), GFP_KERNEL);
input_dev = input_allocate_device();
if (!kbtab || !input_dev)
-- 
2.12.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 4/7] Input: yealink - fix NULL-deref at probe

[Johan Hovold]

Make sure to check the number of endpoints to avoid dereferencing a
NULL-pointer should a malicious device lack endpoints.

Fixes: aca951a22a1d ("[PATCH] input-driver-yealink-P1K-usb-phone")
Cc: stable  # 2.6.14
Cc: Henk 
Signed-off-by: Johan Hovold 
---
 drivers/input/misc/yealink.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/input/misc/yealink.c b/drivers/input/misc/yealink.c
index 79c964c075f1..6e7ff9561d92 100644
--- a/drivers/input/misc/yealink.c
+++ b/drivers/input/misc/yealink.c
@@ -875,6 +875,10 @@ static int usb_probe(struct usb_interface *intf, const 
struct usb_device_id *id)
int ret, pipe, i;
 
interface = intf->cur_altsetting;
+
+   if (interface->desc.bNumEndpoints < 1)
+   return -ENODEV;
+
endpoint = >endpoint[0].desc;
if (!usb_endpoint_is_int_in(endpoint))
return -ENODEV;
-- 
2.12.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 5/7] Input: hanwang - fix NULL-deref at probe

[Johan Hovold]

Make sure to check the number of endpoints to avoid dereferencing a
NULL-pointer should a malicious device lack endpoints.

Fixes: bba5394ad3bd ("Input: add support for Hanwang tablets")
Cc: stable  # 2.6.37
Cc: Xing Wei 
Cc: Jiri Kosina 
Signed-off-by: Johan Hovold 
---
 drivers/input/tablet/hanwang.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/input/tablet/hanwang.c b/drivers/input/tablet/hanwang.c
index cd852059b99e..df4bea96d7ed 100644
--- a/drivers/input/tablet/hanwang.c
+++ b/drivers/input/tablet/hanwang.c
@@ -340,6 +340,9 @@ static int hanwang_probe(struct usb_interface *intf, const 
struct usb_device_id
int error;
int i;
 
+   if (intf->cur_altsetting->desc.bNumEndpoints < 1)
+   return -ENODEV;
+
hanwang = kzalloc(sizeof(struct hanwang), GFP_KERNEL);
input_dev = input_allocate_device();
if (!hanwang || !input_dev) {
-- 
2.12.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 2/7] Input: cm109 - fix NULL-deref at probe

[Johan Hovold]

Make sure to check the number of endpoints to avoid dereferencing a
NULL-pointer should a malicious device lack endpoints.

Fixes: c04148f915e5 ("Input: add driver for USB VoIP phones with CM109
chipset")
Cc: stable  # 2.6.28
Cc: Alfred E. Heggestad 

Signed-off-by: Johan Hovold 
---
 drivers/input/misc/cm109.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/input/misc/cm109.c b/drivers/input/misc/cm109.c
index 9cc6d057c302..23c191a2a071 100644
--- a/drivers/input/misc/cm109.c
+++ b/drivers/input/misc/cm109.c
@@ -700,6 +700,10 @@ static int cm109_usb_probe(struct usb_interface *intf,
int error = -ENOMEM;
 
interface = intf->cur_altsetting;
+
+   if (interface->desc.bNumEndpoints < 1)
+   return -ENODEV;
+
endpoint = >endpoint[0].desc;
 
if (!usb_endpoint_is_int_in(endpoint))
-- 
2.12.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 0/7] Input: fix NULL-derefs at probe

[Johan Hovold]

This series fixes a number of NULL-pointer dereferences due to missing
endpoint sanity checks that can be triggered by a malicious USB device.

Johan


Johan Hovold (7):
  Input: iforce - fix NULL-deref at probe
  Input: cm109 - fix NULL-deref at probe
  Input: ims-pcu - fix NULL-deref at probe
  Input: yealink - fix NULL-deref at probe
  Input: hanwang - fix NULL-deref at probe
  Input: kbtab - fix NULL-deref at probe
  Input: sur40 - fix NULL-deref at probe

 drivers/input/joystick/iforce/iforce-usb.c | 3 +++
 drivers/input/misc/cm109.c | 4 
 drivers/input/misc/ims-pcu.c   | 4 
 drivers/input/misc/yealink.c   | 4 
 drivers/input/tablet/hanwang.c | 3 +++
 drivers/input/tablet/kbtab.c   | 3 +++
 drivers/input/touchscreen/sur40.c  | 3 +++
 7 files changed, 24 insertions(+)

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

Problem with expresscard renesas 720202 resuming from s3

[Alessio Corbucci]

hi guys, I'm not a developer, but need help to understand a problem...
I've an expresscard usb 3.0 controller with renesas/nec 720202 chip
and when I connect an external drive it works fine but gives me some
problem on suspend to ram (s3): on resume from s3 the drive is not
mounted anymore and sometimes it's device node change (e.g. from
/dev/sdb to /dev/sdc)...

I've read that this chip seems to have a problem with resume on linux
and there seems to be a quirk (XHCI_RESET_ON_RESUME) for this reason,
but despite search I have not understood what this quirk does and what
are the consequences...

and if, given the circumstances, the behaviour of my renesas
controller should be expected or not...  (the controller gives none of
this problems on windows)...

any hint?
thanks
alessio
--
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 v3 1/2] usb: dwc3: refactor gadget endpoint count calculation

[Felipe Balbi]

Bryan O'Donoghue  writes:
> On 10/03/17 12:14, Felipe Balbi wrote:
>
>>
>> return 0;
>>
>> I can change your patch locally, if you want. I can also drop your
>> patches and wait for replacements. No strong feelings.
>>
>
> I'll resend Felipe.

thank you, please test multiple connect/disconnect cycles :-)

I had some issues related to those.

-- 
balbi


signature.asc
Description: PGP signature

[PATCH] usb: xhci: fix HCSPARAMS 3 debug message

[Yoichi Yuasa]

Signed-off-by: Yoichi Yuasa 
---
 drivers/usb/host/xhci-dbg.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/host/xhci-dbg.c b/drivers/usb/host/xhci-dbg.c
index 2b4a00f..20ee337 100644
--- a/drivers/usb/host/xhci-dbg.c
+++ b/drivers/usb/host/xhci-dbg.c
@@ -87,7 +87,7 @@ static void xhci_print_cap_regs(struct xhci_hcd *xhci)
(unsigned int) HCS_ERST_MAX(temp));
 
temp = readl(>cap_regs->hcs_params3);
-   xhci_dbg(xhci, "HCSPARAMS 3 0x%x:\n",
+   xhci_dbg(xhci, "HCSPARAMS 3: 0x%x\n",
(unsigned int) temp);
xhci_dbg(xhci, "  Worst case U1 device exit latency: %u\n",
(unsigned int) HCS_U1_LATENCY(temp));
-- 
2.7.4

--
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: Add MS_INTR_BINTERVAL USB quirk

[Dave Mielke]

[quoted lines by Alan Stern on 2017/03/12 at 21:40 -0400]

>No, I was wondering why an HID device would run at high speed.  Both
>you and Samuel implied that this was because it was a USB-2 device.  
>But that is not an adequate answer, because it is perfectly valid for a 
>USB-2 device to run at full speed.

I think I've misunderstood something about how to interpret bInterval. I'm now 
suspecting that bInterval must be interpreted the new (mocro frame) way only if 
the device is operating at least at high speed, and that, even if the device 
advertizes itself as USB 2.0, bInterval must still be interpreted the old way 
if the device is operating at full or low speed. Is that correct?

If the above is correct, how can we tell from usbfs which way to interpret 
bInterval?

-- 
Dave Mielke   | 2213 Fox Crescent | The Bible is the very Word of God.
Phone: 1-613-726-0014 | Ottawa, Ontario   | http://Mielke.cc/bible/
EMail: d...@mielke.cc | Canada  K2A 1H7   | http://FamilyRadio.org/
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH] net: usb: r8152: use new api ethtool_{get|set}_link_ksettings

[Hayes Wang]

Philippe Reynes [mailto:trem...@gmail.com]
> Sent: Monday, March 13, 2017 5:42 AM
> Subject: [PATCH] net: usb: r8152: use new api ethtool_{get|set}_link_ksettings
> 
> The ethtool api {get|set}_settings is deprecated.
> We move this driver to new api {get|set}_link_ksettings.
> 
> As I don't have the hardware, I'd be very pleased if
> someone may test this patch.
> 
> Signed-off-by: Philippe Reynes 
> ---
>  drivers/net/usb/r8152.c |   21 -
>  1 files changed, 12 insertions(+), 9 deletions(-)

Acked-by: Hayes Wang 

--
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 v19 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

[Baolin Wang]

On 13 March 2017 at 09:09, Jun Li  wrote:
> Hi,
>
>> -Original Message-
>> From: Baolin Wang [mailto:baolin.w...@linaro.org]
>> Sent: Friday, March 10, 2017 6:52 PM
>> To: Jun Li 
>> Cc: NeilBrown ; Felipe Balbi ; Greg KH
>> ; Sebastian Reichel ; Dmitry
>> Eremin-Solenikov ; David Woodhouse
>> ; r...@kernel.org; Marek Szyprowski
>> ; Ruslan Bilovol ;
>> Peter Chen ; Alan Stern
>> ; grygorii.stras...@ti.com; Yoshihiro Shimoda
>> ; Lee Jones ;
>> Mark Brown ; John Stultz ;
>> Charles Keepax ;
>> patc...@opensource.wolfsonmicro.com; Linux PM list > p...@vger.kernel.org>; USB ; device-
>> mainlin...@lists.linuxfoundation.org; LKML 
>> Subject: Re: [PATCH v19 0/4] Introduce usb charger framework to deal with
>> the usb gadget power negotation
>>
>> On 10 March 2017 at 16:27, Jun Li  wrote:
>> > Hi
>> >
>> >> -Original Message-
>> >> From: Baolin Wang [mailto:baolin.w...@linaro.org]
>> >> Sent: Friday, March 10, 2017 3:15 PM
>> >> To: Jun Li 
>> >> Cc: NeilBrown ; Felipe Balbi ; Greg
>> >> KH ; Sebastian Reichel ;
>> >> Dmitry Eremin-Solenikov ; David Woodhouse
>> >> ; r...@kernel.org; Marek Szyprowski
>> >> ; Ruslan Bilovol
>> >> ; Peter Chen ;
>> >> Alan Stern ; grygorii.stras...@ti.com;
>> >> Yoshihiro Shimoda ; Lee Jones
>> >> ; Mark Brown ; John Stultz
>> >> ; Charles Keepax
>> >> ;
>> >> patc...@opensource.wolfsonmicro.com; Linux PM list > >> p...@vger.kernel.org>; USB ; device-
>> >> mainlin...@lists.linuxfoundation.org; LKML
>> >> 
>> >> Subject: Re: [PATCH v19 0/4] Introduce usb charger framework to deal
>> >> with the usb gadget power negotation
>> >>
>> >> On 10 March 2017 at 14:30, Jun Li  wrote:
>> >> >> >> >
>> >> >> >> > Will generic phy need add extcon as well?
>> >> >> >>
>> >> >> >> Yes, will add a 'struct extcon_dev*' in 'struct usb_phy', which
>> >> >> >> will be common code.
>> >> >> >>
>> >> >> >
>> >> >> > I mean the common code need add 'struct extcon_dev' into both
>> >> >> > 'struct phy' and 'struct usb_phy', right? as some/new usb phy
>> >> >> > use that generic phy
>> >> >> driver.
>> >> >>
>> >> >> Ah, you remind me. Seems we need also add one 'struct extcon_dev'
>> >> >> into 'struct phy'.
>> >> >>
>> >> >> >> >
>> >> >> >> >> >
>> >> >> >> >> >> Secondly, I also agreed with Peter's comments: Not only
>> >> >> >> >> >> USB PHY to register an extcon, but also for the drivers
>> >> >> >> >> >> which can detect USB charger type, it may be USB
>> >> >> >> >> >> controller driver, USB type-c driver, pmic driver, and
>> >> >> >> >> >> these drivers may not have an extcon device since the
>> >> >> >> >> >> internal part can finish
>> >> the vbus detect.
>> >> >> >> >> >
>> >> >> >> >> > Whichever part can detect vbus, the driver for that part
>> >> >> >> >> > must be able to find the extcon and trigger a notification.
>> >> >> >> >> > Maybe one part can detect VBUS, another can measure the
>> >> >> >> >> > resistance on ID and a third can work through the state
>> >> >> >> >> > machine to determine if D+ and D- are shorted together.
>> >> >> >> >> > Somehow these three need to work together to determine
>> >> >> >> >> > what is
>> >> >> >> >> plugged
>> >> >> >> >> > in to the external connection port.  Somewhere there much
>> >> >> >> >> > an
>> >> >> 'extcon'
>> >> >> >> >> > device which represents that port and which the three
>> >> >> >> >> > devices can find and can interact with.
>> >> >> >> >> > I think it makes sense for the usb_phy to be the connection
>> point.
>> >> >> >> >> > Each of the devices can get to the phy, and the phy can
>> >> >> >> >> > get to the
>> >> >> >> extcon.
>> >> >> >> >> > It doesn't matter very much if the usb phy driver creates
>> >> >> >> >> > the extcon, or if something else creates the extcon and
>> >> >> >> >> > the phy driver performs a lookup to find it (e.g. based on
>> devicetree info).
>> >> >> >> >> >
>> >> >> >> >> > The point is that there is obviously an external physical
>> >> >> >> >> > connection, and so there should be an 'extcon' device that
>> >> >> represents it.
>> >> >> >> >>
>> >> >> >> >> Peter & Jun, is it 

Re: [PATCH v2] usb: xhci: bInterval quirk for TI TUSB73x0

[Sergei Shtylyov]

Hello!

On 3/13/2017 11:11 AM, Roger Quadros wrote:


As per [1] issue #4,
"The periodic EP scheduler always tries to schedule the EPs
that have large intervals (interval equal to or greater than
128 microframes) into different microframes. So it maintains
an internal counter and increments for each large interval
EP added. When the counter is greater than 128, the scheduler
rejects the new EP. So when the hub re-enumerated 128 times,
it triggers this condition."

This results in Bandwidth error when devices with periodic
endpoints (ISO/INT) having bInterval > 7 are plugged an


   s/an/and/.


unplugged several times on a TUSB73x0 xhci host.


   xHCI.


Workaround this issue by limiting the bInterval to 7
(i.e. interval to 6) for High-speed or faster periodic endpoints.

[1] - http://www.ti.com/lit/er/sllz076/sllz076.pdf

Signed-off-by: Roger Quadros 

[...]

MBR, Sergei

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

Re: [PATCH v3 1/2] usb: dwc3: refactor gadget endpoint count calculation

[Bryan O'Donoghue]

On 10/03/17 12:14, Felipe Balbi wrote:



return 0;

I can change your patch locally, if you want. I can also drop your
patches and wait for replacements. No strong feelings.



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

Re: [PATCH v2 0/4] usb: dwc3: dual-role support

[Roger Quadros]

Felipe,

On 16/02/17 15:06, Roger Quadros wrote:
> Hi,
> 
> We rely on the OTG controller block or Extcon to provide us with
> VBUS and ID line status via an interrupt.
> 
> This is then used to switch the controller between host, peripheral
> and idle roles based on the following table.
> 
> ID  VBUSdual-role state
> --  ---
> 0   x   A_HOST - Host controller active
> 1   0   B_IDLE - Both Host and Gadget controllers inactive
> 1   1   B_PERIPHERAL - Gadget controller active
> 
> Series depends on
> [1] dwc3 trivial fixes - https://lkml.org/lkml/2017/2/15/204

Would appreciate any feedback on this series. Thanks.

> 
> Changelog:
> v2:
> - Use extcon device for VBUS/ID events if extcon phandle is present.
> - Fix bugs during system suspend/resume.
> 
> cheers,
> -roger
> 
> Roger Quadros (4):
>   usb: dwc3: core.h: add some register definitions
>   usb: dwc3: omap: don't miss events during suspend/resume
>   usb: dwc3: add dual-role support
>   usb: dwc3: Workaround for super-speed host on dra7 in dual-role mode
> 
>  Documentation/devicetree/bindings/usb/dwc3.txt |   2 +
>  drivers/usb/dwc3/core.c| 752 
> -
>  drivers/usb/dwc3/core.h| 131 -
>  drivers/usb/dwc3/dwc3-omap.c   |  16 +
>  drivers/usb/dwc3/gadget.c  |  18 +-
>  5 files changed, 895 insertions(+), 24 deletions(-)
> 

-- 
cheers,
-roger
--
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] usb: xhci: bInterval quirk for TI TUSB73x0

[Roger Quadros]

As per [1] issue #4,
"The periodic EP scheduler always tries to schedule the EPs
that have large intervals (interval equal to or greater than
128 microframes) into different microframes. So it maintains
an internal counter and increments for each large interval
EP added. When the counter is greater than 128, the scheduler
rejects the new EP. So when the hub re-enumerated 128 times,
it triggers this condition."

This results in Bandwidth error when devices with periodic
endpoints (ISO/INT) having bInterval > 7 are plugged an
unplugged several times on a TUSB73x0 xhci host.

Workaround this issue by limiting the bInterval to 7
(i.e. interval to 6) for High-speed or faster periodic endpoints.

[1] - http://www.ti.com/lit/er/sllz076/sllz076.pdf

Signed-off-by: Roger Quadros 
---
v2:
-fixed typo in commit message

 drivers/usb/host/xhci-mem.c | 11 +++
 drivers/usb/host/xhci-pci.c |  3 +++
 drivers/usb/host/xhci.h |  1 +
 3 files changed, 15 insertions(+)

diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index ba1853f4..05fb3f6 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -1502,6 +1502,17 @@ int xhci_endpoint_init(struct xhci_hcd *xhci,
 */
max_esit_payload = xhci_get_max_esit_payload(udev, ep);
interval = xhci_get_endpoint_interval(udev, ep);
+
+   /* Periodic endpoint bInterval limit quirk */
+   if (usb_endpoint_xfer_int(>desc) ||
+   usb_endpoint_xfer_isoc(>desc)) {
+   if ((xhci->quirks & XHCI_LIMIT_ENDPOINT_INTERVAL_7) &&
+   udev->speed >= USB_SPEED_HIGH &&
+   interval >= 7) {
+   interval = 6;
+   }
+   }
+
mult = xhci_get_endpoint_mult(udev, ep);
max_packet = usb_endpoint_maxp(>desc);
max_burst = xhci_get_endpoint_max_burst(udev, ep);
diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
index fc99f51..7b86508 100644
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -199,6 +199,9 @@ static void xhci_pci_quirks(struct device *dev, struct 
xhci_hcd *xhci)
pdev->device == 0x1042)
xhci->quirks |= XHCI_BROKEN_STREAMS;
 
+   if (pdev->vendor == PCI_VENDOR_ID_TI && pdev->device == 0x8241)
+   xhci->quirks |= XHCI_LIMIT_ENDPOINT_INTERVAL_7;
+
if (xhci->quirks & XHCI_RESET_ON_RESUME)
xhci_dbg_trace(xhci, trace_xhci_dbg_quirks,
"QUIRK: Resetting on resume");
diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index da3eb69..2496bd6 100644
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -1818,6 +1818,7 @@ struct xhci_hcd {
 #define XHCI_MISSING_CAS   (1 << 24)
 /* For controller with a broken Port Disable implementation */
 #define XHCI_BROKEN_PORT_PED   (1 << 25)
+#define XHCI_LIMIT_ENDPOINT_INTERVAL_7 (1 << 26)
 
unsigned intnum_active_eps;
unsigned intlimit_active_eps;
-- 
2.7.4


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

Re: [PATCH] net: usb: asix88179_178a: use new api ethtool_{get|set}_link_ksettings

[Philippe Reynes]

Hi Chris,

On 3/13/17, Chris Roth  wrote:
> I can test it tomorrow. I'll pull a clean copy of 4.10.2, or do you
> suggest a different version than that?

I think that 4.10.2 is fine, there are no change on this driver
between 4.10 and git (net-next).

Thanks a lot for the test.


> Chris

Philippe


> On 2017-03-12 11:02 AM, Philippe Reynes wrote:
>> The ethtool api {get|set}_settings is deprecated.
>> We move this driver to new api {get|set}_link_ksettings.
>>
>> As I don't have the hardware, I'd be very pleased if
>> someone may test this patch.
>>
>> Signed-off-by: Philippe Reynes 
>> ---
>>  drivers/net/usb/ax88179_178a.c |   14 --
>>  1 files changed, 8 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/net/usb/ax88179_178a.c
>> b/drivers/net/usb/ax88179_178a.c
>> index a3a7db0..4a0ae7c 100644
>> --- a/drivers/net/usb/ax88179_178a.c
>> +++ b/drivers/net/usb/ax88179_178a.c
>> @@ -620,16 +620,18 @@ static int ax88179_get_eeprom_len(struct net_device
>> *net)
>>  return 0;
>>  }
>>
>> -static int ax88179_get_settings(struct net_device *net, struct
>> ethtool_cmd *cmd)
>> +static int ax88179_get_link_ksettings(struct net_device *net,
>> +  struct ethtool_link_ksettings *cmd)
>>  {
>>  struct usbnet *dev = netdev_priv(net);
>> -return mii_ethtool_gset(>mii, cmd);
>> +return mii_ethtool_get_link_ksettings(>mii, cmd);
>>  }
>>
>> -static int ax88179_set_settings(struct net_device *net, struct
>> ethtool_cmd *cmd)
>> +static int ax88179_set_link_ksettings(struct net_device *net,
>> +  const struct ethtool_link_ksettings *cmd)
>>  {
>>  struct usbnet *dev = netdev_priv(net);
>> -return mii_ethtool_sset(>mii, cmd);
>> +return mii_ethtool_set_link_ksettings(>mii, cmd);
>>  }
>>
>>  static int
>> @@ -826,11 +828,11 @@ static int ax88179_ioctl(struct net_device *net,
>> struct ifreq *rq, int cmd)
>>  .set_wol= ax88179_set_wol,
>>  .get_eeprom_len = ax88179_get_eeprom_len,
>>  .get_eeprom = ax88179_get_eeprom,
>> -.get_settings   = ax88179_get_settings,
>> -.set_settings   = ax88179_set_settings,
>>  .get_eee= ax88179_get_eee,
>>  .set_eee= ax88179_set_eee,
>>  .nway_reset = usbnet_nway_reset,
>> +.get_link_ksettings = ax88179_get_link_ksettings,
>> +.set_link_ksettings = ax88179_set_link_ksettings,
>>  };
>>
>>  static void ax88179_set_multicast(struct net_device *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] usb-core: Add MS_INTR_BINTERVAL USB quirk

[Samuel Thibault]

Alan Stern, on dim. 12 mars 2017 21:40:33 -0400, wrote:
> On Sun, 12 Mar 2017, Dave Mielke wrote:
> > [quoted lines by Alan Stern on 2017/03/12 at 21:31 -0400]
> > 
> > >A device's speed is only partially related to its USB version.  A
> > >USB-1.1 device can run at low speed or full speed.  A USB-2 device can
> > >run at low, full, or high speed.  And a USB-3 device can run at low,
> > >full, high, or Super speed.
> > 
> > Yes, I did know this, so maybe I misunderstood what you were wondering 
> > about. 
> > Were you wondering why 64ms was too long?
> 
> No, I was wondering why an HID device would run at high speed.  Both
> you and Samuel implied that this was because it was a USB-2 device.  
> But that is not an adequate answer, because it is perfectly valid for a 
> USB-2 device to run at full speed.

to_usb_device(ddev)->speed really is USB_SPEED_HIGH, otherwise the quirk
wouldn't work :)

Samuel
--
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/2] usb: host: ehci-platform: set hcd->phy to avoid phy_get() in usb_add_hcd()

[Yoshihiro Shimoda]

This patch sets hcd->phy from own phy context to avoid phy_get()
in usb_add_hcd(). Since core/hcd.c manages the phy only in
usb_add_hcd() and usb_remove_hcd(), there is difficult to manage
the phy in suspend/resume.

Signed-off-by: Yoshihiro Shimoda 
---
 drivers/usb/host/ehci-platform.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/usb/host/ehci-platform.c b/drivers/usb/host/ehci-platform.c
index a268d9e..2a7b6cb 100644
--- a/drivers/usb/host/ehci-platform.c
+++ b/drivers/usb/host/ehci-platform.c
@@ -220,6 +220,9 @@ static int ehci_platform_probe(struct platform_device *dev)
if (IS_ERR(priv->phys[phy_num])) {
err = PTR_ERR(priv->phys[phy_num]);
goto err_put_hcd;
+   } else if (!hcd->phy) {
+   /* Avoiding phy_get() in usb_add_hcd() */
+   hcd->phy = priv->phys[phy_num];
}
}
 
-- 
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 v2 0/2] usb: host: [eo]hci-plat: set hcd->phy to avoid phy_get_() in usb_add_hcd()

[Yoshihiro Shimoda]

The usb_add_hcd() will call phy_{get,init,power_on}() if hcd->phy is not set.
After the usb_add_hcd() call phy_power_on(), it keeps until usb_remove_hcd().
And then, even if the system turns suspend, the usb core keeps the phy power.
I think that each host driver should handle the phy power. So, this patch
sets hcd->phy before usb_add_hcd() to avoid phy_get() in usb_add_hcd().

Changes from v1 (as RFC):
 - Fix the usage condition about priv->phys[].
 - Remove RFC.

Yoshihiro Shimoda (2):
  usb: host: ehci-platform: set hcd->phy to avoid phy_get() in
usb_add_hcd()
  usb: host: ohci-platform: set hcd->phy to avoid phy_get() in
usb_add_hcd()

 drivers/usb/host/ehci-platform.c | 3 +++
 drivers/usb/host/ohci-platform.c | 3 +++
 2 files changed, 6 insertions(+)

-- 
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 v2 2/2] usb: host: ohci-platform: set hcd->phy to avoid phy_get() in usb_add_hcd()

[Yoshihiro Shimoda]

This patch sets hcd->phy from own phy context to avoid phy_get()
in usb_add_hcd(). Since core/hcd.c manages the phy only in
usb_add_hcd() and usb_remove_hcd(), there is difficult to manage
the phy in suspend/resume.

Signed-off-by: Yoshihiro Shimoda 
---
 drivers/usb/host/ohci-platform.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/usb/host/ohci-platform.c b/drivers/usb/host/ohci-platform.c
index 898b740..6368fce 100644
--- a/drivers/usb/host/ohci-platform.c
+++ b/drivers/usb/host/ohci-platform.c
@@ -183,6 +183,9 @@ static int ohci_platform_probe(struct platform_device *dev)
if (IS_ERR(priv->phys[phy_num])) {
err = PTR_ERR(priv->phys[phy_num]);
goto err_put_hcd;
+   } else if (!hcd->phy) {
+   /* Avoiding phy_get() in usb_add_hcd() */
+   hcd->phy = priv->phys[phy_num];
}
}
 
-- 
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