[PATCH] USB: cp210x: add new IDs for GE Bx50v3 boards

[Ken Lin]

Add new USB IDs for cp2104/5 devices on Bx50v3 boards due to the design change

Signed-off-by: Ken Lin 
---
 drivers/usb/serial/cp210x.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/usb/serial/cp210x.c b/drivers/usb/serial/cp210x.c
index fff718352e0c..691e3e5f0e61 100644
--- a/drivers/usb/serial/cp210x.c
+++ b/drivers/usb/serial/cp210x.c
@@ -178,6 +178,8 @@ static const struct usb_device_id id_table[] = {
{ USB_DEVICE(0x1901, 0x0190) }, /* GE B850 CP2105 Recorder interface */
{ USB_DEVICE(0x1901, 0x0193) }, /* GE B650 CP2104 PMC interface */
{ USB_DEVICE(0x1901, 0x0194) }, /* GE Healthcare Remote Alarm Box */
+   { USB_DEVICE(0x1901, 0x0195) }, /* GE B850/B650/B450 CP2104 DP UART 
intefrace */
+   { USB_DEVICE(0x1901, 0x0196) }, /* GE B850 CP2105 DP UART interface */
{ USB_DEVICE(0x19CF, 0x3000) }, /* Parrot NMEA GPS Flight Recorder */
{ USB_DEVICE(0x1ADB, 0x0001) }, /* Schweitzer Engineering C662 Cable */
{ USB_DEVICE(0x1B1C, 0x1C00) }, /* Corsair USB Dongle */
-- 
2.11.0

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

Re: [PATCH V2 1/2] dt-bindings: leds: document new led-triggers property

[Rafał Miłecki]

On 02/02/2017 09:44 PM, Jacek Anaszewski wrote:

On 02/01/2017 10:55 PM, Rafał Miłecki wrote:

On 02/01/2017 10:26 PM, Jacek Anaszewski wrote:

On 02/01/2017 04:56 PM, Rafał Miłecki wrote:

On 01/31/2017 10:34 PM, Jacek Anaszewski wrote:

On 01/31/2017 05:11 PM, Rafał Miłecki wrote:

Thanks a lot Jacek for this explanation (and sorry but I needed a
bit of
time to
think about this). I can finally see your point, I think we're on the
same page
now.

I think that for all this time I was thinking from the pure DT
perspective. If
you ignore fact that Linux has multiple LED trigger drivers, then
"led-triggers"
may not sound that bad.

After reading your description however I can see this property can be
misleading
as Linux people may think "drivers" when seeing "triggers".

I still think this is a useful property and I hope we can still find a
way to
name it in a sane way: to be nice from DT PoV and march Linux LEDs
subsystem.


I also see the need for this property.


I think we should still work on some generic property (without linux,
prefix) as
this seems to be something generic, not really specific to Linux
implementation.
Specifying relation between LED and devices is something than AFAICS
can be
reused by other systems as well.

So my suggestion is to try some new name & leave linux,default-trigger
to allow
specifying one single trigger driver as required by current Linux
implementation.

What do you think about this?

There are few suggestions to came to my mind:
"trigger-sources"
"trigger-devices"
"led-trigger-devices"
"led-related-devices"
"led-event-devices"


trigger-devices would work in this specific use case,
where we can give phandles to usb ports. Nonetheless, we
have also other kernel based events serving as trigger
sources - e.g. timer.

In this case I'd go for trigger-sources, but we'd need
to have some generic way of defining the source like timer.


I'd leave timer for later discussion but I'm glad you brought this
problem.
Maybe we could discuss this on another example that is more supported
like
GPIOs?

We know this property allows specifying USB ports and we want it to
support
mixing various sources. So a very simple sample case seems to be using
it for
specifying GPIO as trigger source.

Is this possible to mix various entries in a list assigned to single
property?
Let's say:
trigger-sources =
<_port1>,
<_port1>,
< 1 GPIO_ACTIVE_HIGH>;


According to my knowledge all elements in the list are elements
of one array, no matter if they are comma separated or space separated
in "<>" brackets. DT maintainer would have to confirm that though.


This matches my knowledge as well.


Having that, we would be limited to a list of fixed size
tuples IMHO.


That sounds OK. Now I spent some time thinking about this I think it can work.
First of all we may need something like #sources-cells to extend our property
in the future.
Secondly it should be possible to detect type of phandle node by trying things
one by one. We should be e.g. able to check is phandle is for GPIO by trying
of_find_gpiochip_by_xlate.



Is this possible to support this? If so, which function I can use to
detect
what is pointed by a phandle?
I'm not that familiar with DT and I'm not sure how to handle this.


I wonder if this is correct way to go. Maybe we should think of
creating entirely new trigger mechanism that would allow for having
multiple active triggers at a time.


I'm OK with reworking Linux's triggers if it need be. I think we should
agree
on binding(s) first though.


I was thinking of creating entirely new mechanism (new sysfs file),
as we can't break existing users.


Agree.



Of course trigger-sources would be still useful for defining
a list of devices of the same type like in case of usbport trigger.
Nonetheless, I have a problem with this property being a part of
LED class device DT bindings. Triggers are not tightly coupled with
LED class devices, but trigger-sources being a list of usb ports
would be applicable only to usbport trigger. What if there was
another combo trigger e.g. for reporting activity on mulitple GPIOs?


That was exactly my point with above trigger-sources example including 2
USB
ports & GPIO.


How usbport trigger would make use use of information about GPIO?
Does it mean that in this approach triggers would arbitrarily choose
trigger-sources applicable for them?


It wouldn't. It would simply ignore it.

We could modify ledtrig-gpio.c however to support this new property
(ex-"led-triggers") and make use of specified GPIO(s). Of course ledtrig-gpio
would ignore specified USB ports. One type per LED trigger driver.



Should we have separate list of trigger sources per any possible
existing trigger type? Aren't we going to far from pure hardware
description the Device Tree was initially predestined to?


That would simplify things, but it gets us back to *multiple* properties
like
led-usb-triggers (or led-usb-trigger-sources)
led-pci-triggers (or led-pci-trigger-sources)

Re: [PATCH V2 1/2] dt-bindings: leds: document new led-triggers property

[Jacek Anaszewski]

On 02/01/2017 10:55 PM, Rafał Miłecki wrote:
> On 02/01/2017 10:26 PM, Jacek Anaszewski wrote:
>> On 02/01/2017 04:56 PM, Rafał Miłecki wrote:
>>> On 01/31/2017 10:34 PM, Jacek Anaszewski wrote:
 On 01/31/2017 05:11 PM, Rafał Miłecki wrote:
> Thanks a lot Jacek for this explanation (and sorry but I needed a
> bit of
> time to
> think about this). I can finally see your point, I think we're on the
> same page
> now.
>
> I think that for all this time I was thinking from the pure DT
> perspective. If
> you ignore fact that Linux has multiple LED trigger drivers, then
> "led-triggers"
> may not sound that bad.
>
> After reading your description however I can see this property can be
> misleading
> as Linux people may think "drivers" when seeing "triggers".
>
> I still think this is a useful property and I hope we can still find a
> way to
> name it in a sane way: to be nice from DT PoV and march Linux LEDs
> subsystem.

 I also see the need for this property.

> I think we should still work on some generic property (without linux,
> prefix) as
> this seems to be something generic, not really specific to Linux
> implementation.
> Specifying relation between LED and devices is something than AFAICS
> can be
> reused by other systems as well.
>
> So my suggestion is to try some new name & leave linux,default-trigger
> to allow
> specifying one single trigger driver as required by current Linux
> implementation.
>
> What do you think about this?
>
> There are few suggestions to came to my mind:
> "trigger-sources"
> "trigger-devices"
> "led-trigger-devices"
> "led-related-devices"
> "led-event-devices"

 trigger-devices would work in this specific use case,
 where we can give phandles to usb ports. Nonetheless, we
 have also other kernel based events serving as trigger
 sources - e.g. timer.

 In this case I'd go for trigger-sources, but we'd need
 to have some generic way of defining the source like timer.
>>>
>>> I'd leave timer for later discussion but I'm glad you brought this
>>> problem.
>>> Maybe we could discuss this on another example that is more supported
>>> like
>>> GPIOs?
>>>
>>> We know this property allows specifying USB ports and we want it to
>>> support
>>> mixing various sources. So a very simple sample case seems to be using
>>> it for
>>> specifying GPIO as trigger source.
>>>
>>> Is this possible to mix various entries in a list assigned to single
>>> property?
>>> Let's say:
>>> trigger-sources =
>>> <_port1>,
>>> <_port1>,
>>> < 1 GPIO_ACTIVE_HIGH>;
>>
>> According to my knowledge all elements in the list are elements
>> of one array, no matter if they are comma separated or space separated
>> in "<>" brackets. DT maintainer would have to confirm that though.
> 
> This matches my knowledge as well.

Having that, we would be limited to a list of fixed size
tuples IMHO.

> 
>>> Is this possible to support this? If so, which function I can use to
>>> detect
>>> what is pointed by a phandle?
>>> I'm not that familiar with DT and I'm not sure how to handle this.
>>
>> I wonder if this is correct way to go. Maybe we should think of
>> creating entirely new trigger mechanism that would allow for having
>> multiple active triggers at a time.
> 
> I'm OK with reworking Linux's triggers if it need be. I think we should
> agree
> on binding(s) first though.

I was thinking of creating entirely new mechanism (new sysfs file),
as we can't break existing users.


> 
>> Of course trigger-sources would be still useful for defining
>> a list of devices of the same type like in case of usbport trigger.
>> Nonetheless, I have a problem with this property being a part of
>> LED class device DT bindings. Triggers are not tightly coupled with
>> LED class devices, but trigger-sources being a list of usb ports
>> would be applicable only to usbport trigger. What if there was
>> another combo trigger e.g. for reporting activity on mulitple GPIOs?
> 
> That was exactly my point with above trigger-sources example including 2
> USB
> ports & GPIO.

How usbport trigger would make use use of information about GPIO?
Does it mean that in this approach triggers would arbitrarily choose
trigger-sources applicable for them?

> 
>> Should we have separate list of trigger sources per any possible
>> existing trigger type? Aren't we going to far from pure hardware
>> description the Device Tree was initially predestined to?
> 
> That would simplify things, but it gets us back to *multiple* properties
> like
> led-usb-triggers (or led-usb-trigger-sources)
> led-pci-triggers (or led-pci-trigger-sources)
> led-gpio-triggers (or led-gpio-trigger-sources)
> etc.

Right, I was rather skeptical in my question - I don't like this
solution too.

> Last time Rob said he's not going to accept something like 

Re: ftdi_sio: overrun errors

[Johan Hovold]

On Wed, Jun 29, 2016 at 11:59:06PM +0200, Michael Walle wrote:
> Am 2016-05-27 20:02, schrieb Johan Hovold:
> > On Fri, May 13, 2016 at 12:17:24PM +0200, mich...@walle.cc wrote:
> >> Hi,
> >> 
> >> if the internal buffer is full, a read() returns a steady stream of
> >> zeros until one valid character is received. According to my 
> >> experiments
> >> this happens if the FT232 receives characters while the device is not
> >> opened. After the 257th byte the device returns overrun errors, which
> >> are translated to zero bytes (with TTY_OVERRUN flag set). The 257 
> >> bytes
> >> makes sense because the internal RX FIFO is 256 bytes and there is 
> >> room
> >> for one more byte in the receive register, before the overrun occurs.
> >> Unfortunately, this happens until one (valid?) character is received.
> >> 
> >> The FT232RL seems to set the overrun flag and only clears it on the 
> >> next
> >> received character. This flag is polled every $poll_interval
> >> microseconds and for each single poll there is one zero character 
> >> placed
> >> in the tty buffer (and the overrun error is incremented).
> > 
> >> Before commit cc01f17d5 (USB: ftdi_sio: re-implement read processing)
> >> there was a similar note in the driver:
> >> 
> >> /* if a parity error is detected you get status packets forever
> >> until a character is sent without a parity error.
> >> This doesn't work well since the application receives a
> >> never ending stream of bad data - even though new data
> >> hasn't been sent. Therefore I (bill) have taken this out.
> >> However - this might make sense for framing errors and so on
> >> so I am leaving the code in for now.
> >> */
> >> 
> >> So I guess this is still true for the parity error, but in this case
> >> there will be no character inserted into the tty buffer. Only the
> >> counter will be incremented indefinitely. I guess this is not the
> >> correct behaviour, either?

Yeah, that's not right either.

> >> The first byte of the status packet is compared to a saved
> >> "prev_status", maybe we should do the same for the second byte, too?
> >> 
> >> Btw. this does not happen if, the adapter is plugged in for the first
> >> time. I see that the open causes issues a reset, I guess this doesn't
> >> reset this error condition.
> > 
> > Thanks for reporting this. It sounds like we need to ignore the errors
> > on status-only packets, possibly after checking for changes.

I had a change to take a closer look at this today, and just submitted a
patch that should fix this. Only processing break and error status for
packets with status payload avoids over-reporting break and error
conditions.

> What comes directly to my mind is the handling of the break condition. 
> Can't look into that at the moment. But if break conditions are 
> translated into status-only packets, how are two consecutive breaks 
> recognized. Ie. if the break condition flag is sticky (until a new 
> character is received) you can't determine if its one or more. But maybe 
> we are lucky and the chip will send some different pattern. If only 
> there were some specs ;)

Specs would be nice...

Through experimentation I found that these flags are always first
reported for packets with data payload (NULL in case of break)
which seems to make sense.

> > Might be a second issue since you say you can set the device in an
> > error state which is not cleared when later opening the port.
>
> Well, I've already tried a soft reset with no success. So I doubt there 
> is any solution. Seems like a soft reset doesn't reset the internal 
> state entirely.

I can confirm that. Specifically, it does not seem to clear the LSR and
holding registers, so an overrun along with the final character received
is still reported if an overrun occurs while the port is closed.

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] USB: serial: ftdi_sio: fix line-status over-reporting

[Johan Hovold]

FTDI devices use a receive latency timer to periodically empty the
receive buffer and report modem and line status (also when the buffer is
empty).

When a break or error condition is detected the corresponding status
flags will be set on a packet with nonzero data payload and the flags
are not updated until the break is over or further characters are
received.

In order to avoid over-reporting break and error conditions, these flags
must therefore only be processed for packets with payload.

This specifically fixes the case where after an overrun, the error
condition is continuously reported and NULL-characters inserted until
further data is received.

Reported-by: Michael Walle 
Fixes: 72fda3ca6fc1 ("USB: serial: ftd_sio: implement sysrq handling on
break")
Fixes: 166ceb690750 ("USB: ftdi_sio: clean up line-status handling")
Cc: stable  # v2.6.35
Signed-off-by: Johan Hovold 
---
 drivers/usb/serial/ftdi_sio.c | 23 ++-
 1 file changed, 14 insertions(+), 9 deletions(-)

diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
index e82dbb3d0883..c540de15aad2 100644
--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -2068,6 +2068,20 @@ static int ftdi_process_packet(struct usb_serial_port 
*port,
priv->prev_status = status;
}
 
+   /* save if the transmitter is empty or not */
+   if (packet[1] & FTDI_RS_TEMT)
+   priv->transmit_empty = 1;
+   else
+   priv->transmit_empty = 0;
+
+   len -= 2;
+   if (!len)
+   return 0;   /* status only */
+
+   /*
+* Break and error status must only be processed for packets with
+* data payload to avoid over-reporting.
+*/
flag = TTY_NORMAL;
if (packet[1] & FTDI_RS_ERR_MASK) {
/* Break takes precedence over parity, which takes precedence
@@ -2090,15 +2104,6 @@ static int ftdi_process_packet(struct usb_serial_port 
*port,
}
}
 
-   /* save if the transmitter is empty or not */
-   if (packet[1] & FTDI_RS_TEMT)
-   priv->transmit_empty = 1;
-   else
-   priv->transmit_empty = 0;
-
-   len -= 2;
-   if (!len)
-   return 0;   /* status only */
port->icount.rx += len;
ch = packet + 2;
 
-- 
2.10.2

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

[RFC PATCH] usb: misc: add USB251xB/xBi Hi-Speed Hub Controller Driver

[Richard Leitner]

This patch adds a driver for configuration of the Microchip USB251xB/xBi
USB 2.0 hub controller series with USB 2.0 upstream connectivity, SMBus
configuration interface and two to four USB 2.0 downstream ports.

Furthermore add myself as a maintainer for this driver.

The datasheet can be found at the manufacturers website, see [1]. All
device-tree exposed configuration features have been tested on a i.MX6
platform with a USB2512B hub.

[1] http://ww1.microchip.com/downloads/en/DeviceDoc/1692C.pdf

Signed-off-by: Richard Leitner 
---
 Documentation/devicetree/bindings/usb/usb251xb.txt |  83 +++
 MAINTAINERS|   8 +
 drivers/usb/misc/Kconfig   |   9 +
 drivers/usb/misc/Makefile  |   1 +
 drivers/usb/misc/usb251xb.c| 757 +
 include/linux/platform_data/usb251xb.h |  33 +
 6 files changed, 891 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/usb/usb251xb.txt
 create mode 100644 drivers/usb/misc/usb251xb.c
 create mode 100644 include/linux/platform_data/usb251xb.h

diff --git a/Documentation/devicetree/bindings/usb/usb251xb.txt 
b/Documentation/devicetree/bindings/usb/usb251xb.txt
new file mode 100644
index 000..9496b06
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/usb251xb.txt
@@ -0,0 +1,83 @@
+Microchip USB 2.0 Hi-Speed Hub Controller
+
+The device node for the configuration of a Microchip USB251xB/xBi USB 2.0
+Hi-Speed Controller.
+
+Required properties :
+ - compatible : Should be "microchip,usb251xb" or one of the specific types:
+   "microchip,usb2512b", "microchip,usb2512bi", "microchip,usb2513b",
+   "microchip,usb2513bi", "microchip,usb2514b", "microchip,usb2514bi"
+ - hub-reset-gpios : Should specify the gpio for hub reset
+
+Optional properties :
+ - reg : I2C address on the selected bus (default is <0x2C>)
+ - skip-config : Skip Hub configuration, but only send the USB-Attach command
+ - vendor-id : USB Vendor ID of the hub (16 bit, default is 0x0424)
+ - product-id : USB Product ID of the hub (16 bit, default depends on type)
+ - device-id : USB Device ID of the hub (16 bit, default is 0x0bb3)
+ - language-id : USB Language ID (16 bit, default is 0x)
+ - manufacturer : USB Manufacturer string (max 31 characters long)
+ - product : USB Product string (max 31 characters long)
+ - serial : USB Serial string (max 31 characters long)
+ - {bus,self}-powered : selects between self- and bus-powered operation 
(default
+   is self-powered)
+ - disable-hi-speed : disable USB Hi-Speed support
+ - {multi,single}-tt : selects between multi- and single-transaction-translator
+   (default is multi-tt)
+ - disable-eop : disable End of Packet generation in full-speed mode
+ - {ganged,individual}-sensing : select over-current sense type in self-powered
+   mode (default is individual)
+ - {ganged,individual}-port-switching : select port power switching mode
+   (default is individual)
+ - dynamic-power-switching : enable auto-switching from self- to bus-powered
+   operation if the local power source is removed or unavailable
+ - oc-delay-{100us,4ms,8ms,16ms} : set over current timer delay (default is 
8ms)
+ - compound-device : indicated the hub is part of a compound device
+ - port-mapping-mode : enable port mapping mode
+ - string-support : enable string descriptor support (required for 
manufacturer,
+   product and serial string configuration)
+ - non-removable-ports : Should specify the ports which have a non-removable
+   device connected.
+ - sp-disabled-ports : Specifies the ports which will be self-power disabled
+ - bp-disabled-ports : Specifies the ports which will be bus-power disabled
+ - max-sp-power : Specifies the maximum current the hub consumes from an
+   upstream port when operating as self-powered hub including the power
+   consumption of a permanently attached peripheral if the hub is
+   configured as a compound device. The value is given in mA in a 0 - 500
+   range (default is 2).
+ - max-bp-power : Specifies the maximum current the hub consumes from an
+   upstream port when operating as bus-powered hub including the power
+   consumption of a permanently attached peripheral if the hub is
+   configured as a compound device. The value is given in mA in a 0 - 500
+   range (default is 100).
+ - max-sp-power : Specifies the maximum current the hub consumes from an
+   upstream port when operating as self-powered hub EXCLUDING the power
+   consumption of a permanently attached peripheral if the hub is
+   configured as a compound device. The value is given in mA in a 0 - 500
+   range (default is 2).
+ - max-bp-power : Specifies the maximum current the hub consumes from an
+   upstream port when operating as bus-powered hub EXCLUDING the power
+   consumption of a permanently attached 

Re: net2280 Driver Bug

[Greg Kroah-Hartman]

On Thu, Feb 02, 2017 at 12:50:02PM +, Raz Manor wrote:
> I opened a pull request for this patch
> https://github.com/torvalds/linux/pull/388

Linux development does not work with github pull requests, sorry.

Please see Documentation/development_process/ for how we all work
together.  Please send a patch through email.

thanks,

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

Re: [PATCH] usb: storage: fix infinite wait loop by incrementing loop counter

[walter harms]

Am 02.02.2017 14:19, schrieb Colin King:
> From: Colin Ian King 
> 
> If jumpshot_get_status continues to return a failed result then the
> wait loop will spin forever because the waitcount counter is never
> being incremented and we don't ever timeout.  Fix this by incrementing
> waitcount.
> 
> Cc: 
> Signed-off-by: Colin Ian King 
> ---
>  drivers/usb/storage/jumpshot.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/usb/storage/jumpshot.c b/drivers/usb/storage/jumpshot.c
> index 011e527..81d82ce 100644
> --- a/drivers/usb/storage/jumpshot.c
> +++ b/drivers/usb/storage/jumpshot.c
> @@ -311,6 +311,7 @@ static int jumpshot_write_data(struct us_data *us,
>   if (result != USB_STOR_TRANSPORT_GOOD) {
>   // I have not experimented to find the smallest 
> value.
>   //
> + waitcount++;
>   msleep(50); 
>   }
>   } while ((result != USB_STOR_TRANSPORT_GOOD) && (waitcount < 
> 10));


the function looks a bit complicated ..
what i about this ?

for(waitcount=0;waitcount<10;waitcount++)
{
   result = jumpshot_get_status(us);
   if ( result == USB_STOR_TRANSPORT_GOOD)
break;

   msleep(50);

}

just my 2 cents,

re,
 wg




--
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: storage: fix infinite wait loop by incrementing loop counter

[Colin King]

From: Colin Ian King 

If jumpshot_get_status continues to return a failed result then the
wait loop will spin forever because the waitcount counter is never
being incremented and we don't ever timeout.  Fix this by incrementing
waitcount.

Cc: 
Signed-off-by: Colin Ian King 
---
 drivers/usb/storage/jumpshot.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/usb/storage/jumpshot.c b/drivers/usb/storage/jumpshot.c
index 011e527..81d82ce 100644
--- a/drivers/usb/storage/jumpshot.c
+++ b/drivers/usb/storage/jumpshot.c
@@ -311,6 +311,7 @@ static int jumpshot_write_data(struct us_data *us,
if (result != USB_STOR_TRANSPORT_GOOD) {
// I have not experimented to find the smallest 
value.
//
+   waitcount++;
msleep(50); 
}
} while ((result != USB_STOR_TRANSPORT_GOOD) && (waitcount < 
10));
-- 
2.10.2

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

RE: net2280 Driver Bug

[Raz Manor]

I opened a pull request for this patch
https://github.com/torvalds/linux/pull/388

Hope it could restart the discussion

Peace and love,
Raz

-Original Message-
From: Alan Stern [mailto:st...@rowland.harvard.edu] 
Sent: Thursday, January 5, 2017 9:08 PM
To: Greg Kroah-Hartman 
Cc: Raz Manor ; Linus Torvalds 
; USB list ; Felipe 
Balbi ; Tim Harvey ; Heikki Krogerus 
; Jussi Kivilinna 
; Colin Ian King 
Subject: Re: net2280 Driver Bug

On Thu, 5 Jan 2017, Greg Kroah-Hartman wrote:

> On Tue, Dec 27, 2016 at 03:56:11PM +, Raz Manor wrote:
> > I'm not entirely sure either, that is why I wanted the specs.
> > Alan sent me the PLX NET2280 specs, but I'm using the USB3380/USB3381 - the 
> > USB3 version of the device.
> > As it seems from the code, the HW interface is mostly the same, with some 
> > minor changes, so it is the same driver (net2280.c) but with some branches 
> > for USB3380 when needed.
> > Maybe the problem has something to do with a minor difference between the 
> > NET2280 and USB3380, that was over looked when adding the support for the 
> > USB3380.
> > So, if any of you have the specs for that one, I would love to get them and 
> > see if there is such a difference in that area.
> > 
> > Anyway, as for the proposed path, this was my logic:
> > 1. The req->td->dmadesc equals to 0 iff:
> >  -- There was a transaction ending with a short packet, and
> >  -- The read() to read it was shorter than the transaction length, and
> >  -- The read() to complete it is longer than the residue.
> >  I believe this is true from the printouts of various cases, but I 
> > can't be positive it is correct.
> > 
> > 2. Entering this if, there should be no more data in the endpoint (a short 
> > packet terminated the transaction). If there is, the transaction wasn't 
> > really done and we should exit and wait for it to finish entirely. That is 
> > the inner if.
> > That inner if should never happen, but it is there to be on the safe 
> > side. That is why it is marked with the comment /* paranoia */. 
> > The size of the data available in the endpoint is ep->dma->dmacount and 
> > it is read to tmp.
> >  This entire clause is based on my own educated guesses.
> > 
> > 3. If we passed that inner if without breaking in the original code, than 
> > tmp & DMA_BYTE_MASK_COUNT== 0.
> > That means we will always pass dma bytes count of 0 to dma_done(), 
> > meaning all the requested bytes were read.
> > 
> > 4. dma_done() reports back to the upper layer that the request (read()) was 
> > done and how many bytes were read. In the original code that would always 
> > be the request size, regardless of the actual size of the data.
> > That did not make sense to me at all.
> > 
> > 5. However, the original value of tmp is req->td->dmacount, which is the 
> > dmacount value when the request's dma transaction was finished. And that is 
> > a much more reasonable value to report back to the caller.
> > 
> > As you can see, this is based a lot on educated guesses and debug printouts 
> > of various cases. That is why I would like to get your input on this, to 
> > make sure I'm on the right track.
> > 
> > To recreate the problem., try reading from a bulk out endpoint in a 
> > loop, 1024 * n bytes in each iteration. Connect the PLX to a host you can 
> > control, and send to that endpoint 1024 * n +x bytes such that  0 < x < 
> > 1024 * n and (x % 1024) != 0 You would expect the first read() to return 
> > 1024 * n and the second read to return x, but you will get the first read 
> > to return 1024 *n and the second one to return 1024 * n.
> > That is true for every positive integer n.
> > 
> > My patch, solves the problem, and does not break any of the other cases 
> > I've tried.
> > 
> > To conclude:
> > I would love to get your input on this patch, as it is based on personal 
> > debugging and guesses, without knowing the HW specs.
> > I would also love to get the USB3380 specs, so I could verify some aspects 
> > of this problem myself, and for future references.
> 
> What ever happened to this?
> 
> Alan, any thoughts about this change?

Sorry, I haven't had time to look at this, and I probably won't have time in 
the near future.  The existing code looks obviously wrong, but the exact change 
required to fix it isn't entirely clear.

Besides, I'm not acquainted with the USB3380 card, only the older
NET2280 (which supports USB-2 but not USB-3).  I suggested to Raz that he 
should CC: the people who added USB3380 support to the driver.  
They are more likely to have the specs than anyone else.

I can test a patch with my card, if Raz wants to post one.

Alan Stern

> thanks,
> 
> greg k-h

--
To unsubscribe from this list: send the line 

[PATCH] usb: misc: adutux: remove redundant error check on copy_to_user return code

[Colin King]

From: Colin Ian King 

The 2nd check for a non-zero return from copy_to_user is redundant as
it is has already been made a few lines earlier.  This check was made
redundant because of previous fix to the copy_to_user error return
check.

Detected by CoverityScan, CID#114347 ("Logically Dead Code")

Fixes: 1865a9c382ede ("USB: adutux: fix misuse of return value of 
copy_to_user()")

Signed-off-by: Colin Ian King 
---
 drivers/usb/misc/adutux.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/usb/misc/adutux.c b/drivers/usb/misc/adutux.c
index 43a677f..c5fa584 100644
--- a/drivers/usb/misc/adutux.c
+++ b/drivers/usb/misc/adutux.c
@@ -389,10 +389,6 @@ static ssize_t adu_read(struct file *file, __user char 
*buffer, size_t count,
dev->secondary_head += (amount - i);
bytes_read += (amount - i);
bytes_to_read -= (amount - i);
-   if (i) {
-   retval = bytes_read ? bytes_read : -EFAULT;
-   goto exit;
-   }
} else {
/* we check the primary buffer */
spin_lock_irqsave (>buflock, flags);
-- 
2.10.2

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

Re: [PATCH 5/6] DT bindings documentation for Broadcom IPROC USB Device controller.

[Raviteja Garimella]

Hi Rob,

On Wed, Feb 1, 2017 at 9:43 PM, Rob Herring  wrote:
> On Mon, Jan 30, 2017 at 01:26:12PM +0530, Raviteja Garimella wrote:
>> The device node is used for UDCs integrated into Broadcom's
>> iProc family of SoCs'. The UDC is based on Synopsys Designware
>> Cores AHB Subsystem USB Device Controller IP.
>>
>> Signed-off-by: Raviteja Garimella 
>> ---
>>  .../bindings/usb/brcm,iproc-snps-udc.txt   | 24 
>> ++
>>  1 file changed, 24 insertions(+)
>>  create mode 100644 
>> Documentation/devicetree/bindings/usb/brcm,iproc-snps-udc.txt
>>
>> diff --git a/Documentation/devicetree/bindings/usb/brcm,iproc-snps-udc.txt 
>> b/Documentation/devicetree/bindings/usb/brcm,iproc-snps-udc.txt
>> new file mode 100644
>> index 000..537dd4d
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/usb/brcm,iproc-snps-udc.txt
>> @@ -0,0 +1,24 @@
>> +Broadcom IPROC USB Device controller.
>> +
>> +The device node is used for UDCs integrated into Broadcom's
>> +iProc family of SoCs'. The UDC is based on Synopsys Designware
>> +Cores AHB Subsystem Device Controller.
>> +
>> +Required properties:
>> + - compatible: should be "brcm,iproc-snps-udc"
>
> Adding "snps" in here adds nothing really. Again, please use per SoC
> compatible strings.

Will do.

>
>> + - reg: Offset and length of UDC register set
>> + - interrupts: description of interrupt line
>> + - phys: phandle to phy node.
>> + - extcon: phandle to the extcon device. This is optional and
>> +   not required for those that don't require extcon support.
>> +   Extcon support will be required if the UDC is connected to
>> +   a Dual Role Device Phy that supports both Host and Device
>> +   mode based on the external cable.
>
> Drop this property.

Ok.

Thanks,
Ravi
>
>> +
>> +Example:
>> + udc_dwc: usb@664e {
>> + compatible = "brcm,iproc-snps-udc";
>> + reg = <0x664e 0x2000>;
>> + interrupts = ;
>> + phys = <_phy>;
>> + extcon = <_phy>";
>> --
>> 2.1.0
>>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Fwd: snd_usb_toneport stops working on Linux >=4.9 (Line6 POD Studio UX1)

[Greg KH]

On Thu, Feb 02, 2017 at 12:26:41PM +0200, Vitaly Tonkacheyev wrote:
> I don't know how to do it.
> ~/github $ git clone https://github.com/torvalds/linux.git
> ~/github $ cd linux
> ~/github/linux $ git bisect start
> ~/github/linux $ git bisect bad v4.9
> ~/github/linux $ git bisect good v4.8
> fatal: BUG: attempt to snprintf into too-small buffer

Huh?  Where did that bug line come from?  git?

That's really odd.

Have you built a kernel before on this machine?

thanks,

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

Fwd: snd_usb_toneport stops working on Linux >=4.9 (Line6 POD Studio UX1)

[Vitaly Tonkacheyev]

I don't know how to do it.
~/github $ git clone https://github.com/torvalds/linux.git
~/github $ cd linux
~/github/linux $ git bisect start
~/github/linux $ git bisect bad v4.9
~/github/linux $ git bisect good v4.8
fatal: BUG: attempt to snprintf into too-small buffer

2017-01-30 8:58 GMT+02:00 Greg KH :
> On Sun, Jan 29, 2017 at 05:12:29PM +0200, Vitaly Tonkacheyev wrote:
>> Driver stops working after update kernel to 4.9 (tried 4.9.4-4.9.6).
>> On 4.8 it works fine.
>
> Any chance you can run 'git bisect' and track down the offending commit?
>
> thanks,
>
> greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html