Re: [PATCH v3 3/3] usb: phy: hold wakeupsource when USB is enumerated in peripheral mode

[Sumit Semwal]

On 13 July 2015 at 12:30, Peter Chen  wrote:
> On Mon, Jul 13, 2015 at 01:26:23PM +0530, Sumit Semwal wrote:
>> Hi Peter,
>>
>> On 8 June 2015 at 14:02, Peter Chen  wrote:
>> > On Mon, Jun 08, 2015 at 12:37:00PM +0530, Sumit Semwal wrote:
>> >> H Peter, Felipe,
>> >>
>> >> On 14 January 2015 at 06:56, Peter Chen  wrote:
>> >> > On Tue, Jan 13, 2015 at 10:18:02AM -0600, Felipe Balbi wrote:
>> >> >> On Tue, Jan 13, 2015 at 04:02:20PM +0530, Kiran Raparthy wrote:
>> >> >> > Hi Felipe,
>> >> >> >
>> >> >> > On 1 December 2014 at 11:09, Kiran Raparthy  
>> >> >> > wrote:
>> >> >> > > Hi Felipe,
>> >> >> > >
>> >> >> > > On 25 November 2014 at 20:15, Felipe Balbi  wrote:
>> >> >> > >> On Tue, Nov 25, 2014 at 07:06:18AM +, Peter Chen wrote:
>> >> >> > >>>
>> >> >> > >>> >
>> >> >> > >>> > usb: phy: hold wakeupsource when USB is enumerated in 
>> >> >> > >>> > peripheral mode
>> >> >> > >>> >
>> >> >> > >>> > Some systems require a mechanism to prevent system to enter 
>> >> >> > >>> > into suspend
>> >> >> > >>> > state when USB is connected and enumerated in peripheral mode.
>> >> >> > >>> >
>> >> >> > >>> > This patch provides an interface to hold a wakeupsource to 
>> >> >> > >>> > prevent suspend.
>> >> >> > >>> > PHY drivers can use this interface when USB is connected and 
>> >> >> > >>> > enumerated in
>> >> >> > >>> > peripheral mode.
>> >> >> > >>> >
>> >> >> > >>> > A timed wakeupsource is temporarily held on USB disconnect 
>> >> >> > >>> > events, to allow
>> >> >> > >>> > the rest of the system to react to the USB disconnection 
>> >> >> > >>> > (dropping host
>> >> >> > >>> > sessions, updating charger status, etc.) prior to re-allowing 
>> >> >> > >>> > suspend.
>> >> >> > >>> >
>> >> >> > >>>
>> 
>> >>
>> >> Kiran is unable to continue on this patch anymore, so despite my very
>> >> limited usb experience, I would like to take this over and with your
>> >> help, take it to closure.
>> >>
>> >> From what I understand, it might be possible to do this either at the
>> >> usb controller driver (where it detects if it has enumerated in host
>> >> mode or device mode) or in the extcon driver (where it detects VBUS
>> >> etc..) -  which would be a cleaner / more logical way to do it?
>> >>
>> >> Thanks for all your help!
>> >
>> > I added my suggestions below:
>> >
>> > My opinion is: if we need this feature, we should depend on gadget's
>> > state, eg 'configured', not vbus level. The system suspend should be
>> > allowed if the gadget state is 'suspended' even vbus is still there.
>> >
>> > And when the gadget goes to suspend or reset or disconnect state, we can
>> > go to disable this wakeup source.
>> >
>> > At drivers/usb/gadget/composite.c, we can know the gadget's state.
>> >
>> Thanks very much for your suggestion, and apologies in the delay in response.
>>
>> I tried to study your suggestion and the code a little bit more, and
>> while I liked your idea quite a bit, I also realised that for the case
>> of letting the USB charger use cases, in gadget framework, there
>> doesn't seem to be a way to get the USB_EVENT_CHARGER, since charger
>> would likely not be a gadget.
>>
>> In this case, how'd we be able to enable / disable wakeup_source for
>> charger events?
>
> We may not prevent the system entering system if it is a charger, isn't
> it, so don't need to consider USB charger.
>
Thanks for your comments, Peter!
>From the Android code that I see, it seems that for a charger
connect/disconnect, some systems might require some time to react to
the change in power, and hence there's a timed-out wakeup event for
USB charger cases. That;s where the consideration for USB chargers
came from.
>>
>> If indeed we can't handle charger events in the way suggested by you,
>> may I propose the following:
>>
>> - implement this in USB-phy as proposed in Kiran's original patch,
>> - keep it disabled by default, and add a module param to enable/disable it
>> - for no vbus case, use another event (USB_EVENT_ENUMERATED /
>> USB_EVENT_NONE? ) to identify connect / disconnect?
>>  (OR, maybe don't do anything for such cases, since most likely
>> the chipidea kind of implementations would handle it themselves?)
>>
>
> In my opinion, we can do noop for wakeup source if it is a USB charger.
>
I think I misunderstood your comment here - do you mean for 'no vbus
case (like chipidea)' do a noop for wakeup source? In the gadget
framework, there doesn't seem to be a way to get to know if a USB
charger is connected.

>> Of course these are based on my limited reading of the USB code, so
>> I'd be grateful if you'd let me know of any obvious gaps in my
>> understanding!
>>
>> > --
>> >
>> > Best Regards,
>> > Peter Chen
>>
>>
>> Best regards,
>> Sumit.
>
> --
>
> Best Regards,
> Peter Chen

Best regards,
Sumit.
--
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 3/3] usb: phy: hold wakeupsource when USB is enumerated in peripheral mode

[Peter Chen]

On Mon, Jul 20, 2015 at 01:18:35PM +0530, Sumit Semwal wrote:
> On 13 July 2015 at 12:30, Peter Chen  wrote:
> > On Mon, Jul 13, 2015 at 01:26:23PM +0530, Sumit Semwal wrote:
> >> Hi Peter,
> >>
> >> On 8 June 2015 at 14:02, Peter Chen  wrote:
> >> > On Mon, Jun 08, 2015 at 12:37:00PM +0530, Sumit Semwal wrote:
> >> >> H Peter, Felipe,
> >> >>
> >> >> On 14 January 2015 at 06:56, Peter Chen  
> >> >> wrote:
> >> >> > On Tue, Jan 13, 2015 at 10:18:02AM -0600, Felipe Balbi wrote:
> >> >> >> On Tue, Jan 13, 2015 at 04:02:20PM +0530, Kiran Raparthy wrote:
> >> >> >> > Hi Felipe,
> >> >> >> >
> >> >> >> > On 1 December 2014 at 11:09, Kiran Raparthy 
> >> >> >> >  wrote:
> >> >> >> > > Hi Felipe,
> >> >> >> > >
> >> >> >> > > On 25 November 2014 at 20:15, Felipe Balbi  wrote:
> >> >> >> > >> On Tue, Nov 25, 2014 at 07:06:18AM +, Peter Chen wrote:
> >> >> >> > >>>
> >> >> >> > >>> >
> >> >> >> > >>> > usb: phy: hold wakeupsource when USB is enumerated in 
> >> >> >> > >>> > peripheral mode
> >> >> >> > >>> >
> >> >> >> > >>> > Some systems require a mechanism to prevent system to enter 
> >> >> >> > >>> > into suspend
> >> >> >> > >>> > state when USB is connected and enumerated in peripheral 
> >> >> >> > >>> > mode.
> >> >> >> > >>> >
> >> >> >> > >>> > This patch provides an interface to hold a wakeupsource to 
> >> >> >> > >>> > prevent suspend.
> >> >> >> > >>> > PHY drivers can use this interface when USB is connected and 
> >> >> >> > >>> > enumerated in
> >> >> >> > >>> > peripheral mode.
> >> >> >> > >>> >
> >> >> >> > >>> > A timed wakeupsource is temporarily held on USB disconnect 
> >> >> >> > >>> > events, to allow
> >> >> >> > >>> > the rest of the system to react to the USB disconnection 
> >> >> >> > >>> > (dropping host
> >> >> >> > >>> > sessions, updating charger status, etc.) prior to 
> >> >> >> > >>> > re-allowing suspend.
> >> >> >> > >>> >
> >> >> >> > >>>
> >> 
> >> >>
> >> >> Kiran is unable to continue on this patch anymore, so despite my very
> >> >> limited usb experience, I would like to take this over and with your
> >> >> help, take it to closure.
> >> >>
> >> >> From what I understand, it might be possible to do this either at the
> >> >> usb controller driver (where it detects if it has enumerated in host
> >> >> mode or device mode) or in the extcon driver (where it detects VBUS
> >> >> etc..) -  which would be a cleaner / more logical way to do it?
> >> >>
> >> >> Thanks for all your help!
> >> >
> >> > I added my suggestions below:
> >> >
> >> > My opinion is: if we need this feature, we should depend on gadget's
> >> > state, eg 'configured', not vbus level. The system suspend should be
> >> > allowed if the gadget state is 'suspended' even vbus is still there.
> >> >
> >> > And when the gadget goes to suspend or reset or disconnect state, we can
> >> > go to disable this wakeup source.
> >> >
> >> > At drivers/usb/gadget/composite.c, we can know the gadget's state.
> >> >
> >> Thanks very much for your suggestion, and apologies in the delay in 
> >> response.
> >>
> >> I tried to study your suggestion and the code a little bit more, and
> >> while I liked your idea quite a bit, I also realised that for the case
> >> of letting the USB charger use cases, in gadget framework, there
> >> doesn't seem to be a way to get the USB_EVENT_CHARGER, since charger
> >> would likely not be a gadget.
> >>
> >> In this case, how'd we be able to enable / disable wakeup_source for
> >> charger events?
> >
> > We may not prevent the system entering system if it is a charger, isn't
> > it, so don't need to consider USB charger.
> >
> Thanks for your comments, Peter!
> From the Android code that I see, it seems that for a charger
> connect/disconnect, some systems might require some time to react to
> the change in power, and hence there's a timed-out wakeup event for
> USB charger cases. That;s where the consideration for USB chargers
> came from.

Current udc core has an API usb_gadget_set_state set its state
according to usb ch9. For this wakeup source case, if the peripheral
has been configured, it can hold wakeup source. Otherise, just have
a timeout wake lock.
Below are some reference code:

diff --git a/drivers/usb/gadget/udc/udc-core.c
b/drivers/usb/gadget/udc/udc-core.c
index d69c355..018f534 100644
--- a/drivers/usb/gadget/udc/udc-core.c
+++ b/drivers/usb/gadget/udc/udc-core.c

@@ -136,6 +138,16 @@ static void usb_gadget_state_work(struct
work_struct *work)
 
if (udc) {
sysfs_notify(&udc->dev.kobj, NULL, "state");
   switch (gadget->state) {
caseUSB_STATE_CONFIGURED:
__pm_stay_awake(&x->wsource);
break;
default:
__pm_wakeup_event(&x->wsource,
USB_DEFAULT_WAKEUP_SRC_TIMEOUT);
break;
  }
}


-- 

Best Regard

Re: is xHCI support for AMD APU chipsets known to be broken?

[Mathias Nyman]

Hi,

I'm temporary back from vacation, for a week or two.

On 08.07.2015 05:38, James Ralston wrote:
> Before I submit a full-blown bug report, could anyone tell me whether
> there are already known issues with the xHCI driver on AMD and/or
> ASUSTek systems, specifically involving AMD APU chipsets?
> 

I'm not aware of any AMD APU /ASUSTek xHCI issues, so a full-blown
bug report would be appreciated.

> I have two different AMD systems, both using ASUSTek AMD motherboards:
> an A88XM-E (AMD A88X / Bolton D4 chipset), and an older F2A85-M PRO
> (AMD A85X FCH / Hudson D4 chipset).
> 
> On both of these systems, under all Linux kernels up through 4.0.4,
> the USB 3.0 ports are broken to the point of being unusable.

Does 4.1 work any better?

> 
> For starters, almost all high-speed USB 3.0 devices simply fail to
> work.  On the A88X system (running Fedora 20 with kernel 4.0.4),
> here's what happens when I connect my LG G4 (not sure if first line is
> related, so I'm including it):
> 
> [  253.825901] pci_pm_runtime_suspend():
> hcd_pci_runtime_suspend+0x0/0x50 returns -16
> [  254.028227] usb 3-2: new high-speed USB device number 2 using xhci_hcd
> [  254.144879] usb 3-2: device descriptor read/all, error -71
> [  254.297946] usb 3-2: new high-speed USB device number 3 using xhci_hcd
> [  254.413979] usb 3-2: device descriptor read/all, error -71
> [  254.57] usb 3-2: new high-speed USB device number 4 using xhci_hcd
> [  254.581420] usb 3-2: device descriptor read/all, error -71
> [  254.734489] usb 3-2: new high-speed USB device number 5 using xhci_hcd
> [  254.748747] usb 3-2: device descriptor read/all, error -71
> [  254.748782] usb usb3-port2: unable to enumerate USB device
> 

does disabling runtime suspend for xhci make a difference?, something like:
"echo on > /sys/bus/pci/devices/:00:14.0/power/control"

Looks like runtime pm tries to suspend xhci, but fails as xhci is busy, and
after this we fail to read the device descriptors with -EPROTO)

> In contrast, when I plug the LG G4 into my Intel-based laptop (running
> Fedora 22, also with the 4.0.4 kernel), it works perfectly:
> 
> [165797.389963] usb 1-6: new high-speed USB device number 22 using xhci_hcd
> [165797.555755] usb 1-6: New USB device found, idVendor=1004, idProduct=633e
> [165797.555778] usb 1-6: New USB device strings: Mfr=1, Product=2,
> SerialNumber=3
> [165797.555783] usb 1-6: Product: LGE Android Phone
> [165797.555786] usb 1-6: Manufacturer: LG Electronics Inc.
> [165797.555789] usb 1-6: SerialNumber: LGH811df5dac44
> 
> Same kernel (or reasonably so), same device, yet the AMD system craps
> the bed, and the Intel system works perfectly.
> 
> Even worse, when I unplug *ANY* USB device on the AMD systems, the
> xhci_hcd driver dies about 90% of the time:
> 
> [  259.747143] xhci_hcd :00:10.1: Stopped the command ring failed,
> maybe the host is dead
> [  259.747188] xhci_hcd :00:10.1: Host not halted after 16000 
> microseconds.
> [  259.747195] xhci_hcd :00:10.1: Abort command ring failed
> [  259.747205] xhci_hcd :00:10.1: HC died; cleaning up
> 

So when unplugging a device xhci fails to finish a command on the command ring.
The command timer times out, we try to stop the command ring to skip/remove the 
"faulty" command, but stopping the command ring fails so we assume xhci is 
completely
messed  up.

Now we just need to figure out why this happends.

> Again, in contrast, the Intel system works perfectly:
> 
> [165873.817070] usb 1-6: USB disconnect, device number 22
> 
> I've seen various mutterings that on AMD systems, I need to enable the
> IOMMU in the BIOS / UEFI in order for USB devices to work correctly,
> and pass various iommu= flags on the kernel command line.  But for all
> combinations of IOMMU settings I tried, the USB3 ports are still
> essentially broken.  (Plus, if enable the IOMMU in the UEFI, the r8169
> driver won't pass any traffic... but that's a different problem,
> sigh.)
> 
> Both systems are/were dual-boot Windows 7 systems, and I had no issues
> with the USB3 ports working under Windows.  So I doubt that faulty
> hardware is involved, unless the ASUSTek driver for Windows works
> around it.
> 
> So, in summary, is this actually a known issue?  E.g., "Yes, sorry,
> we're still working on xHCI support for the newer AMD APU chipsets and
> you're going to have a crappy time until support is further along;
> sorry."  That would be disappointing if that's actually the case,
> because it would feel like 1995 again instead of 2015, but I can deal.
> 
> But if the consensus is that xHCI should work without issues on AMD
> APU chipsets, then I'll go gather up the information to make a full
> bug report.  I just don't want to waste everyone's time if there's
> already a known issue that I just wasn't able to find via web
> searches.
> 

consensus is that xhci should work without issues on AMD APU chipsets

Thanks

-Mathias
--
To unsubscribe from this list: send the line "unsubscribe lin

Re: [PATCH] USB: serial: ftdi_sio: Fix broken URL in comment

[Johan Hovold]

On Mon, Jul 06, 2015 at 10:40:32AM -0400, Nik Nyby wrote:
> This fixes a typo in the URL: http://zeitcontrol.de/
> 
> Signed-off-by: Nik Nyby 

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

[PATCH] qcserial: Add support for Dell Wireless 5809e 4G Modem

[Pieter Hollants]

Added the USB IDs 0x413c:0x81b1 for the "Dell Wireless 5809e Gobi(TM) 4G
LTE Mobile Broadband Card", a Dell-branded Sierra Wireless EM7305 LTE
card in M.2 form factor, used eg. in Dell's Latitude E7540 Notebook
series.

Signed-off-by: Pieter Hollants 
---
 drivers/usb/serial/qcserial.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/usb/serial/qcserial.c b/drivers/usb/serial/qcserial.c
index 9c63897..22f87f3 100644
--- a/drivers/usb/serial/qcserial.c
+++ b/drivers/usb/serial/qcserial.c
@@ -158,6 +158,7 @@ static const struct usb_device_id id_table[] = {
{DEVICE_SWI(0x413c, 0x81a4)},   /* Dell Wireless 5570e HSPA+ (42Mbps) 
Mobile Broadband Card */
{DEVICE_SWI(0x413c, 0x81a8)},   /* Dell Wireless 5808 Gobi(TM) 4G LTE 
Mobile Broadband Card */
{DEVICE_SWI(0x413c, 0x81a9)},   /* Dell Wireless 5808e Gobi(TM) 4G LTE 
Mobile Broadband Card */
+   {DEVICE_SWI(0x413c, 0x81b1)},   /* Dell Wireless 5809e Gobi(TM) 4G LTE 
Mobile Broadband Card */
 
/* Huawei devices */
{DEVICE_HWI(0x03f0, 0x581d)},   /* HP lt4112 LTE/HSPA+ Gobi 4G Modem 
(Huawei me906e) */
-- 
2.4.5

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

Re: [PATCH v2] USB: sierra: add 1199:68AB device ID

[Johan Hovold]

[ +CC: Bjørn and Dan ]

On Mon, Jul 20, 2015 at 08:14:19AM +0200, Dirk Behme wrote:
> Add support for the Sierra Wireless AR8550 device with
> USB descriptor 0x1199, 0x68AB. For this, lsusb reports:

Thanks for the patch. This modem business is a bit of a mess and it's
not always apparent what driver a device id belongs to.

> Bus 001 Device 004: ID 1199:68ab Sierra Wireless, Inc.
> Device Descriptor:
>   bLength18
>   bDescriptorType 1
>   bcdUSB   2.00
>   bDeviceClass0 (Defined at Interface level)
>   bDeviceSubClass 0
>   bDeviceProtocol 0
>   bMaxPacketSize064
>   idVendor   0x1199 Sierra Wireless, Inc.
>   idProduct  0x68ab
>   bcdDevice0.06
>   iManufacturer   3 Sierra Wireless, Incorporated
>   iProduct2 AR8550
>   iSerial 0
>   bNumConfigurations  1
>   Configuration Descriptor:
> bLength 9
> bDescriptorType 2
> wTotalLength  198
> bNumInterfaces  7

[...]

> Signed-off-by: Dirk Behme 
> ---
> Changes in v2: Improve the commit message.
> 
>  drivers/usb/serial/sierra.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/usb/serial/sierra.c b/drivers/usb/serial/sierra.c
> index 46179a0..4122e4f 100644
> --- a/drivers/usb/serial/sierra.c
> +++ b/drivers/usb/serial/sierra.c
> @@ -289,6 +289,9 @@ static const struct usb_device_id id_table[] = {
>   { USB_DEVICE_AND_INTERFACE_INFO(0x1199, 0x68AA, 0xFF, 0xFF, 0xFF),
> .driver_info = (kernel_ulong_t)&direct_ip_interface_blacklist
>   },
> + { USB_DEVICE(0x1199, 0x68AB),   /* Sierra Wireless Direct IP modems */
> +   .driver_info = (kernel_ulong_t)&direct_ip_interface_blacklist
> + },

This device has seven interfaces (0..6) so why do you use the direct-ip
interface blacklisting, which only blacklists interfaces >= 7?

Also do you notice any delays when connecting the device (which could
indicate that sierra is not the right driver)? A log snipped from when
plugging the device in should reveal this.

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] USB: qcserial/option: make AT URCs work for Sierra Wireless MC7305/MC7355

[Johan Hovold]

On Tue, Jul 14, 2015 at 10:55:06PM +0200, Reinhard Speyerer wrote:
> Tests with a Sierra Wireless MC7355 have shown that 1199:9041 devices
> also require the option_send_setup() code to be used on the USB
> interface for the AT port to make unsolicited response codes work
> correctly. Move these devices from the qcserial driver to the option
> driver like it has been done for the 1199:68c0 devices in commit
> d80c0d14183516f184a5ac88e11008ee4c7d2a2e ("USB: qcserial/option: make
> AT URCs work for Sierra Wireless MC73xx").
> 
> Signed-off-by: Reinhard Speyerer 

Applied, 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] qcserial: Add support for Dell Wireless 5809e 4G Modem

[Johan Hovold]

On Mon, Jul 20, 2015 at 10:33:21AM +0200, Pieter Hollants wrote:
> Added the USB IDs 0x413c:0x81b1 for the "Dell Wireless 5809e Gobi(TM) 4G
> LTE Mobile Broadband Card", a Dell-branded Sierra Wireless EM7305 LTE
> card in M.2 form factor, used eg. in Dell's Latitude E7540 Notebook
> series.
> 
> Signed-off-by: Pieter Hollants 

Looks good, but could you resend and include the "lsusb -v" output in
the commit message for completeness?

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

[PATCH v2] qcserial: Add support for Dell Wireless 5809e 4G Modem

[Pieter Hollants]

Added the USB IDs 0x413c:0x81b1 for the "Dell Wireless 5809e Gobi(TM) 4G
LTE Mobile Broadband Card", a Dell-branded Sierra Wireless EM7305 LTE
card in M.2 form factor, used eg. in Dell's Latitude E7540 Notebook
series.

"lsusb -v" output for this device:

Bus 002 Device 003: ID 413c:81b1 Dell Computer Corp.
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   2.00
  bDeviceClass0
  bDeviceSubClass 0
  bDeviceProtocol 0
  bMaxPacketSize064
  idVendor   0x413c Dell Computer Corp.
  idProduct  0x81b1
  bcdDevice0.06
  iManufacturer   1 Sierra Wireless, Incorporated
  iProduct2 Dell Wireless 5809e Gobi™ 4G LTE Mobile Broadband 
Card
  iSerial 3
  bNumConfigurations  2
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength  204
bNumInterfaces  4
bConfigurationValue 1
iConfiguration  0
bmAttributes 0xe0
  Self Powered
  Remote Wakeup
MaxPower  500mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   2
  bInterfaceClass   255 Vendor Specific Class
  bInterfaceSubClass255 Vendor Specific Subclass
  bInterfaceProtocol255 Vendor Specific Protocol
  iInterface  0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81  EP 1 IN
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval   0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01  EP 1 OUT
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval   0
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber2
  bAlternateSetting   0
  bNumEndpoints   3
  bInterfaceClass   255 Vendor Specific Class
  bInterfaceSubClass  0
  bInterfaceProtocol  0
  iInterface  0
  ** UNRECOGNIZED:  05 24 00 10 01
  ** UNRECOGNIZED:  05 24 01 00 00
  ** UNRECOGNIZED:  04 24 02 02
  ** UNRECOGNIZED:  05 24 06 00 00
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83  EP 3 IN
bmAttributes3
  Transfer TypeInterrupt
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x000c  1x 12 bytes
bInterval   9
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82  EP 2 IN
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval   0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02  EP 2 OUT
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval   0
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber3
  bAlternateSetting   0
  bNumEndpoints   3
  bInterfaceClass   255 Vendor Specific Class
  bInterfaceSubClass  0
  bInterfaceProtocol  0
  iInterface  0
  ** UNRECOGNIZED:  05 24 00 10 01
  ** UNRECOGNIZED:  05 24 01 00 00
  ** UNRECOGNIZED:  04 24 02 02
  ** UNRECOGNIZED:  05 24 06 00 00
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x85  EP 5 IN
bmAttributes3
  Transfer TypeInterrupt
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x000c  1x 12 bytes
bInterval   9
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x84  EP 4 IN
bmAttributes2
  Transfer TypeBulk
  Synch Type  

Re: [PATCH v2] qcserial: Add support for Dell Wireless 5809e 4G Modem

[Johan Hovold]

On Mon, Jul 20, 2015 at 11:56:17AM +0200, Pieter Hollants wrote:
> Added the USB IDs 0x413c:0x81b1 for the "Dell Wireless 5809e Gobi(TM) 4G
> LTE Mobile Broadband Card", a Dell-branded Sierra Wireless EM7305 LTE
> card in M.2 form factor, used eg. in Dell's Latitude E7540 Notebook
> series.
> 
> "lsusb -v" output for this device:

> Signed-off-by: Pieter Hollants 

Applied, 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 v3 4/5] usb: gadget: mass_storage: Use static array for luns

[Krzysztof Opasiak]

On 07/08/2015 04:00 PM, Michal Nazarewicz wrote:

On Tue, Jul 07 2015, Krzysztof Opasiak wrote:

This patch replace dynamicly allocated luns array with static one.
This simplifies the code of mass storage function and modules.

It also fix issue with reporting wrong number of LUNs in GET_MAX_LUN
request. According to MS spec we should return the max index of valid
LUN, not the number of luns - 1.


This is no longer true, is it?  Why my fix this bug has been solved, no?
As such, this should not go to stable.  Or am I missing something?


First of all please excuse me my late response but I were out of office.

Unfortunately it's still true. Your fix solved this bug partially. Now 
we report nluns - 1 instead of FSG_LUN_MAX but in case of not contiguous 
luns it is not enough.


Let's consider mass storage function with luns 0 1 3 5. nluns == 4 so in 
GET_MAX_LUN we will return 3 (nluns - 1). Some hosts (in particular 
Windows) iterate over all luns up to value returned from this request. 
This means that host will ask about LUNs 0 1 2 3. LUN 2 is invalid and 
will be skipped but he will never ask about luns 4 and 5 what makes LUN 
5 unavailable.


Standard says that GET_MAX_LUNS should return index of last valid LUN 
which in this case is 5 not 3 and this is what this patch does.





Reported-by: David Fisher 
Signed-off-by: Krzysztof Opasiak 


Acked-by: Michal Nazarewicz 


CC: sta...@vger.kernel.org # 3.13+




@@ -490,6 +489,16 @@ static void bulk_out_complete(struct usb_ep *ep, struct 
usb_request *req)
spin_unlock(&common->lock);
  }

+static int _fsg_common_get_max_lun(struct fsg_common *common)


Perhaps even ‘unsigned’.


As 0 is a valid LUN index this function returns -1 if there is no LUNs 
at all.





+{
+   int i = ARRAY_SIZE(common->luns) - 1;


Ditto.  This applies in other places of the patch so I won’t keep
repeating it.


+
+   while (i >= 0 && !common->luns[i])
+   --i;
+
+   return i;
+}
+
  static int fsg_setup(struct usb_function *f,
 const struct usb_ctrlrequest *ctrl)
  {



@@ -2552,12 +2562,11 @@ static int fsg_main_thread(void *common_)

if (!common->ops || !common->ops->thread_exits
 || common->ops->thread_exits(common) < 0) {
-   struct fsg_lun **curlun_it = common->luns;
-   unsigned i = common->nluns;
+   int i;

down_write(&common->filesem);
-   for (; i--; ++curlun_it) {
-   struct fsg_lun *curlun = *curlun_it;
+   for (i = 0; i < ARRAY_SIZE(common->luns); --i) {


++i


+   struct fsg_lun *curlun = common->luns[i];
if (!curlun || !fsg_lun_is_open(curlun))
continue;





--
Krzysztof Opasiak
Samsung R&D Institute Poland
Samsung Electronics
--
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: Renesas upd7202 (xhci): can't setup

[Mathias Nyman]

On 15.07.2015 14:54, Jean-Francois SIMON wrote:
> Hi,
> 
> We have designed a h/w system with the Renesas USB 3.0 upd7202 controller.
> We are seeing that sometimes xhci initialization fails with a "can't
> setup" error message.
> As a result lsusb doesn't report the USB3.0 ports.
> 
> Adding traces to the kernel we could see that this is happening in
> xhci_reset() --> xhci_handshake() sequence, where xhci_handshake exits
> in time out. (I tried to increase the time out value by 10 times..it
> didn't help)

Does changing the delay time in the busyloop make a difference?
Just thinking that as you have some complicated pci setup and try to
read a pci register in a busyloop every microsecond it could cause issues.

something like:

@@ -71,8 +71,8 @@ int xhci_handshake(void __iomem *ptr, u32 mask, u32 done, int 
usec)
result &= mask;
if (result == done)
return 0;
-   udelay(1);
-   usec--;
+   udelay(10);
+   usec -= 10;


I also see that there are some bus auto-suspend messages, do you have the patch 
that
prevents suspend while xhci is in between loading usb2 and usb3 buses:

commit bcffae7708eb8352f44dc510b326541fe43a02a4
xhci: Prevent runtime pm from autosuspending during initialization


-Mathias


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

Re: [PATCH v2] USB: pl2303: Rewrite pl2303_encode_baud_rate_divisor

[Johan Hovold]

On Wed, Jul 15, 2015 at 01:35:58PM +0200, Michał Pecio wrote:
> 
> This commit fixes the following issues:
> 
> 1. The 9th bit of buf was believed to be the LSB of divisor's
> exponent, but the hardware interprets it as MSB (9th bit) of the
> mantissa. The exponent is actually one bit shorter and applies
> to base 4, not 2 as previously believed.
> 
> 2. Loop iterations doubled the exponent instead of incrementing.
> 
> 3. The exponent wasn't checked for overflow.
> 
> 4. The function returned requested rate instead of actual rate.
> 
> Due to issue #2, the old code deviated from the wrong formula
> described in #1 and actually yielded correct rates when divisor
> was lower than 4096 by using exponents of 0, 2 or 4 base-2,
> interpreted as 0, 1, 2 base-4 with the 9th mantissa bit clear.
> However, at 93.75 kbaud or less the rate turned out too slow
> due to #2 or too fast due to #2 and #3.
> 
> I tested this patch by sending and validating 0x00,0x01,..,0xff
> to an FTDI dongle at 234, 987, 2401, 9601, 31415, 115199, 250k,
> 500k, 750k, 1M, 1.5M, 3M+1 baud. All rates passed.
> 
> I also used pv to check speed at some rates unsupported by FTDI:
> 45 (the lowest possible), 2M, 4M, 5M and 6M-1. Looked sane.
> 
> Signed-off-by: Michal Pecio 

Now applied with stable tag.

Thanks for fixing this.

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

External USB3 hard drive is sometimes not recognized (race condition?) - Event TRB for slot 14 ep 2 with no TDs queued

[Kamil Paral]

Hello folks,

I have troubles with my external USB3 hard drive (a standard laptop drive put 
into an USB3 enclosure) and I have reported a bug about it here:
https://bugzilla.kernel.org/show_bug.cgi?id=101661

I was asked to re-send it to this mailing list, so here it is. I quote the 
initial bug description in full, but there are other attachments in the 
bugzilla,
please have a look.

I'll be happy to provide further information to resolve this issue.

~~~

I have a desktop machine with USB3 ports and an external hard drive
with USB3 enclosure. When I plug the disk into the USB3 port, it is in
roughly 50% recognized and mounted, and in the other cases no disk device
is created and the disk is not accessible. System journal reports this:

Jul 17 14:41:07 titan kernel: usb 2-6.2: new SuperSpeed USB device number 8 
using xhci_hcd
Jul 17 14:41:07 titan kernel: usb 2-6.2: New USB device found, idVendor=1f75, 
idProduct=0888
Jul 17 14:41:07 titan kernel: usb 2-6.2: New USB device strings: Mfr=4, 
Product=5, SerialNumber=6
Jul 17 14:41:07 titan kernel: usb 2-6.2: Product: IS888 USB bridge
Jul 17 14:41:07 titan kernel: usb 2-6.2: Manufacturer: Innostor
Jul 17 14:41:07 titan kernel: usb 2-6.2: SerialNumber: 08881567890556
Jul 17 14:41:07 titan kernel: usb-storage 2-6.2:1.0: USB Mass Storage device 
detected
Jul 17 14:41:07 titan kernel: scsi host12: usb-storage 2-6.2:1.0
Jul 17 14:41:07 titan mtp-probe[2903]: checking bus 2, device 8: 
"/sys/devices/pci:00/:00:14.0/usb2/2-6/2-6.2"
Jul 17 14:41:07 titan mtp-probe[2903]: bus: 2, device: 8 was not an MTP device
Jul 17 14:41:10 titan kernel: scsi 12:0:0:0: Direct-Access ST950042 0AS 
  PQ: 0 ANSI: 0
Jul 17 14:41:10 titan kernel: sd 12:0:0:0: Attached scsi generic sg2 type 0
Jul 17 14:41:10 titan kernel: sd 12:0:0:0: [sdc] 976773168 512-byte logical 
blocks: (500 GB/465 GiB)
Jul 17 14:41:10 titan kernel: sd 12:0:0:0: [sdc] Write Protect is off
Jul 17 14:41:10 titan kernel: sd 12:0:0:0: [sdc] Mode Sense: 03 00 00 00
Jul 17 14:41:10 titan kernel: sd 12:0:0:0: [sdc] No Caching mode page found
Jul 17 14:41:10 titan kernel: sd 12:0:0:0: [sdc] Assuming drive cache: write 
through
Jul 17 14:41:10 titan kernel: xhci_hcd :00:14.0: WARN Event TRB for slot 14 
ep 2 with no TDs queued?
Jul 17 14:41:40 titan kernel: usb 2-6.2: reset SuperSpeed USB device number 8 
using xhci_hcd
Jul 17 14:42:11 titan kernel: usb 2-6.2: reset SuperSpeed USB device number 8 
using xhci_hcd
Jul 17 14:42:42 titan kernel: usb 2-6.2: reset SuperSpeed USB device number 8 
using xhci_hcd
Jul 17 14:42:53 titan kernel: usb 2-6.2: reset SuperSpeed USB device number 8 
using xhci_hcd
Jul 17 14:43:09 titan kernel: usb 2-6.2: reset SuperSpeed USB device number 8 
using xhci_hcd
Jul 17 14:43:09 titan kernel: usb 2-6.2: reset SuperSpeed USB device number 8 
using xhci_hcd
Jul 17 14:43:19 titan kernel: usb 2-6.2: reset SuperSpeed USB device number 8 
using xhci_hcd
Jul 17 14:43:19 titan kernel: sd 12:0:0:0: Device offlined - not ready after 
error recovery
Jul 17 14:43:19 titan kernel: sd 12:0:0:0: [sdc] FAILED Result: 
hostbyte=DID_ABORT driverbyte=DRIVER_OK
Jul 17 14:43:19 titan kernel: sd 12:0:0:0: [sdc] CDB: Read(10) 28 00 00 00 00 
00 00 00 08 00
Jul 17 14:43:19 titan kernel: blk_update_request: I/O error, dev sdc, sector 0
Jul 17 14:43:19 titan kernel: Buffer I/O error on dev sdc, logical block 0, 
async page read
Jul 17 14:43:19 titan kernel: sd 12:0:0:0: rejecting I/O to offline device
Jul 17 14:43:19 titan kernel: sd 12:0:0:0: rejecting I/O to offline device
Jul 17 14:43:19 titan kernel: ldm_validate_partition_table(): Disk read failed.
Jul 17 14:43:19 titan kernel: sd 12:0:0:0: rejecting I/O to offline device
Jul 17 14:43:19 titan kernel: sd 12:0:0:0: rejecting I/O to offline device
Jul 17 14:43:19 titan kernel: sd 12:0:0:0: rejecting I/O to offline device
Jul 17 14:43:19 titan kernel: sd 12:0:0:0: rejecting I/O to offline device
Jul 17 14:43:19 titan kernel: Dev sdc: unable to read RDB block 0
Jul 17 14:43:19 titan kernel: sd 12:0:0:0: rejecting I/O to offline device
Jul 17 14:43:19 titan kernel: sd 12:0:0:0: rejecting I/O to offline device
Jul 17 14:43:19 titan kernel:  sdc: unable to read partition table
Jul 17 14:43:19 titan kernel: sd 12:0:0:0: [sdc] Attached SCSI disk
Jul 17 14:43:19 titan systemd-udevd[496]: error: /dev/sdc: No such device or 
address


When kernel successfully recognizes the drive, it looks like this:

Jul 17 14:35:21 titan kernel: usb 2-6.2: new SuperSpeed USB device number 4 
using xhci_hcd
Jul 17 14:35:21 titan kernel: usb 2-6.2: New USB device found, idVendor=1f75, 
idProduct=0888
Jul 17 14:35:21 titan kernel: usb 2-6.2: New USB device strings: Mfr=4, 
Product=5, SerialNumber=6
Jul 17 14:35:21 titan kernel: usb 2-6.2: Product: IS888 USB bridge
Jul 17 14:35:21 titan kernel: usb 2-6.2: Manufacturer: Innostor
Jul 17 14:35:21 titan kernel: usb 2-6.2: SerialNumber: 08881567

Re: [PATCH v3 3/3] usb: phy: hold wakeupsource when USB is enumerated in peripheral mode

[Sumit Semwal]

Hi Peter,

On 20 July 2015 at 12:45, Peter Chen  wrote:
> On Mon, Jul 20, 2015 at 01:18:35PM +0530, Sumit Semwal wrote:
>> On 13 July 2015 at 12:30, Peter Chen  wrote:
>> > On Mon, Jul 13, 2015 at 01:26:23PM +0530, Sumit Semwal wrote:
>> >> Hi Peter,
>> >>
>> >> On 8 June 2015 at 14:02, Peter Chen  wrote:
>> >> > On Mon, Jun 08, 2015 at 12:37:00PM +0530, Sumit Semwal wrote:
>> >> >> H Peter, Felipe,
>> >> >>
>> >> >> On 14 January 2015 at 06:56, Peter Chen  
>> >> >> wrote:
>> >> >> > On Tue, Jan 13, 2015 at 10:18:02AM -0600, Felipe Balbi wrote:
>> >> >> >> On Tue, Jan 13, 2015 at 04:02:20PM +0530, Kiran Raparthy wrote:
>> >> >> >> > Hi Felipe,
>> >> >> >> >
>> >> >> >> > On 1 December 2014 at 11:09, Kiran Raparthy 
>> >> >> >> >  wrote:
>> >> >> >> > > Hi Felipe,
>> >> >> >> > >
>> >> >> >> > > On 25 November 2014 at 20:15, Felipe Balbi  wrote:
>> >> >> >> > >> On Tue, Nov 25, 2014 at 07:06:18AM +, Peter Chen wrote:
>> >> >> >> > >>>
>> >> >> >> > >>> >
>> >> >> >> > >>> > usb: phy: hold wakeupsource when USB is enumerated in 
>> >> >> >> > >>> > peripheral mode
>> >> >> >> > >>> >
>> >> >> >> > >>> > Some systems require a mechanism to prevent system to enter 
>> >> >> >> > >>> > into suspend
>> >> >> >> > >>> > state when USB is connected and enumerated in peripheral 
>> >> >> >> > >>> > mode.
>> >> >> >> > >>> >
>> >> >> >> > >>> > This patch provides an interface to hold a wakeupsource to 
>> >> >> >> > >>> > prevent suspend.
>> >> >> >> > >>> > PHY drivers can use this interface when USB is connected 
>> >> >> >> > >>> > and enumerated in
>> >> >> >> > >>> > peripheral mode.
>> >> >> >> > >>> >
>> >> >> >> > >>> > A timed wakeupsource is temporarily held on USB disconnect 
>> >> >> >> > >>> > events, to allow
>> >> >> >> > >>> > the rest of the system to react to the USB disconnection 
>> >> >> >> > >>> > (dropping host
>> >> >> >> > >>> > sessions, updating charger status, etc.) prior to 
>> >> >> >> > >>> > re-allowing suspend.
>> >> >> >> > >>> >
>> >> >> >> > >>>
>> >> 
>> >> >>
>> >> >> Kiran is unable to continue on this patch anymore, so despite my very
>> >> >> limited usb experience, I would like to take this over and with your
>> >> >> help, take it to closure.
>> >> >>
>> >> >> From what I understand, it might be possible to do this either at the
>> >> >> usb controller driver (where it detects if it has enumerated in host
>> >> >> mode or device mode) or in the extcon driver (where it detects VBUS
>> >> >> etc..) -  which would be a cleaner / more logical way to do it?
>> >> >>
>> >> >> Thanks for all your help!
>> >> >
>> >> > I added my suggestions below:
>> >> >
>> >> > My opinion is: if we need this feature, we should depend on gadget's
>> >> > state, eg 'configured', not vbus level. The system suspend should be
>> >> > allowed if the gadget state is 'suspended' even vbus is still there.
>> >> >
>> >> > And when the gadget goes to suspend or reset or disconnect state, we can
>> >> > go to disable this wakeup source.
>> >> >
>> >> > At drivers/usb/gadget/composite.c, we can know the gadget's state.
>> >> >
>> >> Thanks very much for your suggestion, and apologies in the delay in 
>> >> response.
>> >>
>> >> I tried to study your suggestion and the code a little bit more, and
>> >> while I liked your idea quite a bit, I also realised that for the case
>> >> of letting the USB charger use cases, in gadget framework, there
>> >> doesn't seem to be a way to get the USB_EVENT_CHARGER, since charger
>> >> would likely not be a gadget.
>> >>
>> >> In this case, how'd we be able to enable / disable wakeup_source for
>> >> charger events?
>> >
>> > We may not prevent the system entering system if it is a charger, isn't
>> > it, so don't need to consider USB charger.
>> >
>> Thanks for your comments, Peter!
>> From the Android code that I see, it seems that for a charger
>> connect/disconnect, some systems might require some time to react to
>> the change in power, and hence there's a timed-out wakeup event for
>> USB charger cases. That;s where the consideration for USB chargers
>> came from.
>
> Current udc core has an API usb_gadget_set_state set its state
> according to usb ch9. For this wakeup source case, if the peripheral
> has been configured, it can hold wakeup source. Otherise, just have
> a timeout wake lock.
Thank you for your kind hint. Let me toy with this change and update.

> Below are some reference code:
>
> diff --git a/drivers/usb/gadget/udc/udc-core.c
> b/drivers/usb/gadget/udc/udc-core.c
> index d69c355..018f534 100644
> --- a/drivers/usb/gadget/udc/udc-core.c
> +++ b/drivers/usb/gadget/udc/udc-core.c
>
> @@ -136,6 +138,16 @@ static void usb_gadget_state_work(struct
> work_struct *work)
>
> if (udc) {
> sysfs_notify(&udc->dev.kobj, NULL, "state");
>switch (gadget->state) {
> caseUSB_STATE_CONFIGURED:
> __pm_stay_awake(&x->wsource);
>   

Re: [PATCH v3 4/5] usb: gadget: mass_storage: Use static array for luns

[Michal Nazarewicz]

> On 07/08/2015 04:00 PM, Michal Nazarewicz wrote:
>> On Tue, Jul 07 2015, Krzysztof Opasiak wrote:
>>> This patch replace dynamicly allocated luns array with static one.
>>> This simplifies the code of mass storage function and modules.
>>>
>>> It also fix issue with reporting wrong number of LUNs in GET_MAX_LUN
>>> request. According to MS spec we should return the max index of valid
>>> LUN, not the number of luns - 1.
>>
>> This is no longer true, is it?  Why my fix this bug has been solved, no?
>> As such, this should not go to stable.  Or am I missing something?

On Mon, Jul 20 2015, Krzysztof Opasiak wrote:
> Unfortunately it's still true. Your fix solved this bug partially. Now 
> we report nluns - 1 instead of FSG_LUN_MAX but in case of not contiguous 
> luns it is not enough.
>
> Let's consider mass storage function with luns 0 1 3 5. nluns == 4 so in 
> GET_MAX_LUN we will return 3 (nluns - 1).

I don’t believe that’s accurate.  See loop in my patch:

+   if (!opts->refcnt) {
+   for (nluns = i = 0; i < FSG_MAX_LUNS; ++i)
+   if (common->luns[i])
+   nluns = i + 1;
+   if (!nluns)
+   pr_warn("No LUNS defined, continuing anyway\n");
+   else
+   common->nluns = nluns;
+   pr_info("Number of LUNs=%u\n", common->nluns);
+   }

It iterates over all luns and if lun is non-NULL it sets nluns to index
of that lun plus one.  So if luns[0], lun[1], lun[2], lun[3] and lun[5]
are set, common->nluns = 6.

-- 
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of  o' \,=./ `o
..o | Computer Science,  Michał “mina86” Nazarewicz(o o)
ooo +--ooO--(_)--Ooo--
--
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] xhci: Calculate old endpoints correctly on device reset

[Mathias Nyman]

On 19.07.2015 18:25, Brian Campbell wrote:
> 
> When resetting a device the number of active TTs may need to be
> corrected by xhci_update_tt_active_eps, but the number of old active
> endpoints supplied to it was always zero, so the number of TTs and the
> bandwidth reserved for them was not updated, and could rise
> unnecessarily.
> 
> This affected systems using Intel's Patherpoint chipset, which rely on
> software bandwidth checking.  For example, a Lenovo X230 would lose the
> ability to use ports on the docking station after enough suspend/resume
> cycles because the bandwidth calculated would rise with every cycle when
> a suitable device is attached.
> 
> The correct number of active endpoints is calculated in the same way as
> in xhci_reserve_bandwidth.
> 

Thanks, 

I remember there was an issue about something eating bandwidth as suspend/resume
that never got fixed?

here it is:
http://marc.info/?l=linux-usb&m=141561758015676&w=2

Not sure if Kenneth has triggered it lately?

Anyways, patch looks good, I'll send it forward

-Mathias


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

Re: [PATCH v3 4/5] usb: gadget: mass_storage: Use static array for luns

[Krzysztof Opasiak]

On 07/20/2015 03:17 PM, Michal Nazarewicz wrote:

On 07/08/2015 04:00 PM, Michal Nazarewicz wrote:

On Tue, Jul 07 2015, Krzysztof Opasiak wrote:

This patch replace dynamicly allocated luns array with static one.
This simplifies the code of mass storage function and modules.

It also fix issue with reporting wrong number of LUNs in GET_MAX_LUN
request. According to MS spec we should return the max index of valid
LUN, not the number of luns - 1.


This is no longer true, is it?  Why my fix this bug has been solved, no?
As such, this should not go to stable.  Or am I missing something?


On Mon, Jul 20 2015, Krzysztof Opasiak wrote:

Unfortunately it's still true. Your fix solved this bug partially. Now
we report nluns - 1 instead of FSG_LUN_MAX but in case of not contiguous
luns it is not enough.

Let's consider mass storage function with luns 0 1 3 5. nluns == 4 so in
GET_MAX_LUN we will return 3 (nluns - 1).


I don’t believe that’s accurate.  See loop in my patch:

+   if (!opts->refcnt) {
+   for (nluns = i = 0; i < FSG_MAX_LUNS; ++i)
+   if (common->luns[i])
+   nluns = i + 1;
+   if (!nluns)
+   pr_warn("No LUNS defined, continuing anyway\n");
+   else
+   common->nluns = nluns;
+   pr_info("Number of LUNs=%u\n", common->nluns);
+   }

It iterates over all luns and if lun is non-NULL it sets nluns to index
of that lun plus one.  So if luns[0], lun[1], lun[2], lun[3] and lun[5]
are set, common->nluns = 6.



Yeah I see it now. What I wrote was a problem before your patch but now 
it seams to be ok, just nluns name is very misleading. Summing up, just 
like you wrote this patch should not go to stable.


--
Krzysztof Opasiak
Samsung R&D Institute Poland
Samsung Electronics
--
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 2/5] dt-bindings: Add a binding for Mediatek xHCI host controller

[chunfeng yun]

On Fri, 2015-07-10 at 11:31 +0300, Roger Quadros wrote:
> Hi,
> 
> On 08/07/15 12:41, Chunfeng Yun wrote:
> > add a DT binding documentation of xHCI host controller for the
> > MT8173 SoC from Mediatek.
> > 
> > Signed-off-by: Chunfeng Yun 
> > ---
> >  .../devicetree/bindings/usb/mt8173-xhci.txt| 27 
> > ++
> >  1 file changed, 27 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/usb/mt8173-xhci.txt
> > 
> > diff --git a/Documentation/devicetree/bindings/usb/mt8173-xhci.txt 
> > b/Documentation/devicetree/bindings/usb/mt8173-xhci.txt
> > new file mode 100644
> > index 000..94cec94
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/usb/mt8173-xhci.txt
> > @@ -0,0 +1,27 @@
> > +MT65XX xhci
> > +
> > +The device node for Mediatek SOC usb3.0 host controller
> > +
> > +Required properties:
> > + - compatible : supports "mediatek,mt8173-xhci"
> > + - reg: Offset and length of registers
> > + - interrupts : Interrupt mode, number and trigger mode
> > + - reg-vusb33-supply:  regulator of usb avdd3.3v
> > + - reg-vbus-supply : regulator of vbus;
> 
> General trend is to use -supply.
> We already know it is a regulator so no need to add "reg-"
> 
> So those two can be
> 
> vusb33-supply:
> vbus-supply:
> 
Ok, thanks

> 
> > + - usb-phy : the phy that xhci will bind
> > + - usb3-lpm-capable: supports USB3 LPM
> > + - clocks : must support all clocks that xhci needs
> > + - clock-names: should be "sys_mac" for sys and mac clocks
> > +
> > +Example:
> > +usb: usb30@1127 {
> > +   compatible = "mediatek,mt8173-xhci";
> > +   reg = <0 0x1127 0 0x1000>;
> > +   interrupts = ;
> > +   reg-vusb33-supply = <&mt6397_vusb_reg>;
> > +   reg-vbus-supply = <&usb_p1_vbus>;
> > +   usb-phy = <&u3phy>;
> > +   usb3-lpm-capable;
> > +   clocks = <&topckgen CLK_TOP_USB30_SEL>;
> > +   clock-names = "sys_mac";
> > +};
> > 
> 
> 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

Re: [PATCH v2 5/5] arm64: dts: mediatek: add xHCI & usb phy for mt8173

[chunfeng yun]

Hi,

On Tue, 2015-07-14 at 18:12 +0800, Daniel Kurtz wrote:
> Hi Chunfeng,
> 
> On Wed, Jul 8, 2015 at 5:41 PM, Chunfeng Yun  
> wrote:
> > Signed-off-by: Chunfeng Yun 
> > ---
> >  arch/arm64/boot/dts/mediatek/mt8173-evb.dts | 15 +++
> >  arch/arm64/boot/dts/mediatek/mt8173.dtsi| 27 
> > +++
> >  2 files changed, 42 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts 
> > b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
> > index f433c21..cb63dc3 100644
> > --- a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
> > +++ b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
> > @@ -13,6 +13,7 @@
> >   */
> >
> >  /dts-v1/;
> > +#include 
> >  #include "mt8173.dtsi"
> >
> >  / {
> > @@ -32,6 +33,15 @@
> > };
> >
> > chosen { };
> > +
> > +   usb_p1_vbus: fixedregulator@0 {
> 
> Why @0 ?
It is the first fixed regulator, so set it to 0 as a index.
I will remove it later
> 
> > +   compatible = "regulator-fixed";
> > +   regulator-name = "usb_vbus";
> > +   regulator-min-microvolt = <500>;
> > +   regulator-max-microvolt = <500>;
> > +   gpio = <&pio 130 GPIO_ACTIVE_HIGH>;
> > +   enable-active-high;
> > +   };
> >  };
> >
> >  &pwrap {
> > @@ -211,3 +221,8 @@
> >  &uart0 {
> > status = "okay";
> >  };
> > +
> > +&usb {
> > +   reg-vusb33-supply = <&mt6397_vusb_reg>;
> > +   reg-vbus-supply = <&usb_p1_vbus>;
> > +};
> > diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi 
> > b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> > index 0696f8f..452bd0a 100644
> > --- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> > +++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> > @@ -15,6 +15,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> 
> Sort alphabetically, so:
> power before reset
> 
Ok
> >  #include "mt8173-pinfunc.h"
> >
> >  / {
> > @@ -393,6 +394,32 @@
> > #size-cells = <0>;
> > status = "disabled";
> > };
> > +
> > +   usb: usb30@1127 {
> > +   compatible = "mediatek,mt8173-xhci";
> > +   reg = <0 0x1127 0 0x1000>;
> > +   interrupts = ;
> > +   usb-phy = <&u3phy>;
> > +   usb3-lpm-capable;
> > +   clocks = <&topckgen CLK_TOP_USB30_SEL>;
> > +   clock-names = "sys_mac";
> > +   };
> > +
> > +   u3phy: usb-phy@11271000 {
> > +   compatible = "mediatek,mt8173-u3phy";
> > +   reg = <0 0x11271000 0 0x3000>,
> > + <0 0x1128 0 0x2>;
> > +   power-domains = <&scpsys MT8173_POWER_DOMAIN_USB>;
> > +   usb-wakeup-ctrl = <&pericfg>;
> > +   wakeup-src = <1>;
> > +   u2port-num = <2>;
> 
> Mediatek specific properties should be prefixed with "mediatek,".
> I also find it nicer if you put the standard properties first:
>   (compatible, reg, clocks, clock-names, power-domains)
> then device specific properties:
>   (usb-wakeup-ctrl, wakeup-src, u2port-num)
> and then the final:
>   status="disabled";
> 
> This last is currently missing, so please add it, too.
> 
I will revise it. Thanks a lot.

> Also, is there some pinctrl settings that must be set for USB?
> 
There is no special pinctrl setting for USB on EVB board on which driver
is tested.

> Lastly, I could not quite figure out which patch this set was based on.
> Patch [0] mentions v4.2-rc1, however, the .dts changes in this patch
> did not apply cleanly.
> Perhaps it was based on a particular patch of Matthias tree?
> 
Yes, it is.
> Thanks!
> -Dan
> 
> > +   clocks = <&pericfg CLK_PERI_USB0>,
> > +<&pericfg CLK_PERI_USB1>,
> > +<&apmixedsys CLK_APMIXED_REF2USB_TX>;
> > +   clock-names = "wakeup_deb_p0",
> > + "wakeup_deb_p1",
> > + "u3phya_ref";
> > +   };
> > };
> >  };
> >
> > --
> > 1.8.1.1.dirty
> >
> >
> > ___
> > Linux-mediatek mailing list
> > linux-media...@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-mediatek


--
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 01/46] usb: gadget: encapsulate endpoint claiming mechanism

[Krzysztof Opasiak]

On 07/15/2015 08:31 AM, Robert Baldyga wrote:

So far it was necessary for usb functions to set ep->driver_data in
endpoint obtained from autoconfig to non-null value, to indicate that
endpoint is claimed by function (in autoconfig it was checked if endpoint
has set this field to non-null value, and if it has, it was assumed that
it is claimed). It could cause bugs becouse if some function doesn't


s/becouse/because

Best regards,
--
Krzysztof Opasiak
Samsung R&D Institute Poland
Samsung Electronics
--
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 5/5] arm64: dts: mediatek: add xHCI & usb phy for mt8173

[Yingjoe Chen]

Hi Daniel, Chunfeng,


On Mon, 2015-07-20 at 22:39 +0800, chunfeng yun wrote:
> Hi,
> 
> On Tue, 2015-07-14 at 18:12 +0800, Daniel Kurtz wrote:
<...>
> > > +
> > > +   usb_p1_vbus: fixedregulator@0 {
> > 
> > Why @0 ?
> It is the first fixed regulator, so set it to 0 as a index.
> I will remove it later

Since this name should be unique, I think we should use gpio number as
address for fixedregulator in case we need other fixedregulators. So
this could be:

usb_p1_vbus: fixedregulator@130 {

Also, we should sort according to the address(gpio number) for these
nodes. Does this make sense?

Joe.C

> > 
> > > +   compatible = "regulator-fixed";
> > > +   regulator-name = "usb_vbus";
> > > +   regulator-min-microvolt = <500>;
> > > +   regulator-max-microvolt = <500>;
> > > +   gpio = <&pio 130 GPIO_ACTIVE_HIGH>;
> > > +   enable-active-high;
> > > +   };


--
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 4/5] xhci: mediatek: support MTK xHCI host controller

[chunfeng yun]

On Mon, 2015-07-13 at 16:52 +0200, John Crispin wrote:
> Hi
> 
> there is a cross dependency between the modules. xhci-mtk.ko requires
> xhci.ko to be loaded. however this will look for xhci_mtk_add_ep_quirk()
> which is part of xhci-mtk. the modules will build but are not run time
> loadable.
> 
>   John
> 
I seperate the quirk functions called by xhci_hcd.ko from xhci-mtk.c
into another C file to fix up the issue.
Thanks

> On 08/07/2015 11:41, Chunfeng Yun wrote:
> > MTK xhci host controller defines some extra SW scheduling
> > parameters for HW to minimize the scheduling effort for
> > synchronous and interrupt endpoints. The parameters are
> > put into reseved DWs of slot context and endpoint context
> > 
> > Signed-off-by: Chunfeng Yun 
> > ---
> >  drivers/usb/host/Kconfig |   9 +
> >  drivers/usb/host/Makefile|   1 +
> >  drivers/usb/host/xhci-mtk.c  | 814 
> > +++
> >  drivers/usb/host/xhci-mtk.h  | 108 ++
> >  drivers/usb/host/xhci-ring.c |  35 +-
> >  drivers/usb/host/xhci.c  |  19 +-
> >  drivers/usb/host/xhci.h  |   1 +
> >  7 files changed, 980 insertions(+), 7 deletions(-)
> >  create mode 100644 drivers/usb/host/xhci-mtk.c
> >  create mode 100644 drivers/usb/host/xhci-mtk.h
> > 
> > diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
> > index 8afc3c1..2202c68 100644
> > --- a/drivers/usb/host/Kconfig
> > +++ b/drivers/usb/host/Kconfig
> > @@ -34,6 +34,15 @@ config USB_XHCI_PCI
> >  config USB_XHCI_PLATFORM
> > tristate
> >  
> > +config USB_XHCI_MTK
> > +   tristate "xHCI support for Mediatek MT65xx"
> > +   select USB_XHCI_PLATFORM
> > +   depends on ARCH_MEDIATEK || COMPILE_TEST
> > +   ---help---
> > + Say 'Y' to enable the support for the xHCI host controller
> > + found in Mediatek MT65xx SoCs.
> > + If unsure, say N.
> > +
> >  config USB_XHCI_MVEBU
> > tristate "xHCI support for Marvell Armada 375/38x"
> > select USB_XHCI_PLATFORM
> > diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
> > index 754efaa..90c6eb2 100644
> > --- a/drivers/usb/host/Makefile
> > +++ b/drivers/usb/host/Makefile
> > @@ -30,6 +30,7 @@ endif
> >  
> >  obj-$(CONFIG_USB_XHCI_PCI) += xhci-pci.o
> >  obj-$(CONFIG_USB_XHCI_PLATFORM) += xhci-plat-hcd.o
> > +obj-$(CONFIG_USB_XHCI_MTK) += xhci-mtk.o
> >  
> >  obj-$(CONFIG_USB_EHCI_HCD) += ehci-hcd.o
> >  obj-$(CONFIG_USB_EHCI_PCI) += ehci-pci.o
> > diff --git a/drivers/usb/host/xhci-mtk.c b/drivers/usb/host/xhci-mtk.c
> > new file mode 100644
> > index 000..45f0606
> > --- /dev/null
> > +++ b/drivers/usb/host/xhci-mtk.c
> > @@ -0,0 +1,814 @@
> > +/*
> > + * Copyright (c) 2015 MediaTek Inc.
> > + * Author:
> > + *  Zhigang.Wei 
> > + *  Chunfeng.Yun 
> > + *
> > + * This software is licensed under the terms of the GNU General Public
> > + * License version 2, as published by the Free Software Foundation, and
> > + * may be copied, distributed, and modified under those terms.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > + * GNU General Public License for more details.
> > + *
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include "xhci.h"
> > +#include "xhci-mtk.h"
> > +
> > +
> > +#define SS_BW_BOUNDARY 51000
> > +/* table 5-5. High-speed Isoc Transaction Limits in usb_20 spec */
> > +#define HS_BW_BOUNDARY 6144
> > +/* usb2 spec section11.18.1: at most 188 FS bytes per microframe */
> > +#define FS_PAYLOAD_MAX 188
> > +
> > +/* mtk scheduler bitmasks */
> > +#define EP_BPKTS(p)((p) & 0x3f)
> > +#define EP_BCSCOUNT(p) (((p) & 0x7) << 8)
> > +#define EP_BBM(p)  ((p) << 11)
> > +#define EP_BOFFSET(p)  ((p) & 0x3fff)
> > +#define EP_BREPEAT(p)  (((p) & 0x7fff) << 16)
> > +
> > +
> > +struct xhci_hcd_mtk {
> > +   struct device *dev;
> > +   struct usb_hcd *hcd;
> > +   struct mu3h_sch_bw_info *sch_array;
> > +   struct regulator *vusb33;
> > +   struct regulator *vbus;
> > +   struct clk *sys_mac;/* sys and mac clock */
> > +};
> > +
> > +
> > +static int is_fs_or_ls(enum usb_device_speed speed)
> > +{
> > +   return speed == USB_SPEED_FULL || speed == USB_SPEED_LOW;
> > +}
> > +
> > +static int get_bw_index(struct xhci_hcd *xhci, struct usb_device *udev,
> > +   struct usb_host_endpoint *ep)
> > +{
> > +   int bw_index;
> > +   int port_id;
> > +   struct xhci_virt_device *virt_dev;
> > +
> > +   virt_dev = xhci->devs[udev->slot_id];
> > +   port_id = virt_dev->real_port;
> > +
> > +   if (udev->speed == USB_SPEED_SUPER) {
> > +   if (usb_endpoint_dir_out(&ep->desc))
> > +   bw_index = (port_id - 1) * 2;
> > +   else
> > +   bw_index = (port_id - 1) *

Re: [PATCH v2 5/5] arm64: dts: mediatek: add xHCI & usb phy for mt8173

[Daniel Kurtz]

On Mon, Jul 20, 2015 at 10:51 PM, Yingjoe Chen
 wrote:
>
> Hi Daniel, Chunfeng,
>
>
> On Mon, 2015-07-20 at 22:39 +0800, chunfeng yun wrote:
>> Hi,
>>
>> On Tue, 2015-07-14 at 18:12 +0800, Daniel Kurtz wrote:
> <...>
>> > > +
>> > > +   usb_p1_vbus: fixedregulator@0 {
>> >
>> > Why @0 ?
>> It is the first fixed regulator, so set it to 0 as a index.
>> I will remove it later
>
> Since this name should be unique, I think we should use gpio number as
> address for fixedregulator in case we need other fixedregulators. So
> this could be:
>
> usb_p1_vbus: fixedregulator@130 {
>
> Also, we should sort according to the address(gpio number) for these
> nodes. Does this make sense?

Yes - that makes some sense.
But, a quick check of other "fixedregulator@" nodes in
arch/arm/boot/dts/ shows that mostly they use @0 , @1.
So, I think the original patch is probably fine.

Sorry for the noise,
-Dan

>
> Joe.C
>
>> >
>> > > +   compatible = "regulator-fixed";
>> > > +   regulator-name = "usb_vbus";
>> > > +   regulator-min-microvolt = <500>;
>> > > +   regulator-max-microvolt = <500>;
>> > > +   gpio = <&pio 130 GPIO_ACTIVE_HIGH>;
>> > > +   enable-active-high;
>> > > +   };
>
>
--
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] xhci: Calculate old endpoints correctly on device reset

[Brian Campbell]

On Mon, Jul 20, 2015 at 04:38:16PM +0300, Mathias Nyman wrote:
> 
> I remember there was an issue about something eating bandwidth as 
> suspend/resume
> that never got fixed?
> 
> here it is:
> http://marc.info/?l=linux-usb&m=141561758015676&w=2

That sounds like the same problem (s/w bandwidth check failing on a new TT,
even though the only change in the system is suspend and resume).  I'm not sure
why the problem would disappear later on, though, but I suppose it would be
sensitive to what kind of devices are attached.

> Not sure if Kenneth has triggered it lately?
> 
> Anyways, patch looks good, I'll send it forward

Thanks,

  Brian
--
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 26/46] usb: gadget: pch_ud: add ep capabilities support

[Krzysztof Opasiak]

On 07/15/2015 08:32 AM, Robert Baldyga wrote:

Convert endpoint configuration to new capabilities model.

Signed-off-by: Robert Baldyga 
---
  drivers/usb/gadget/udc/pch_udc.c | 14 --
  1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/gadget/udc/pch_udc.c b/drivers/usb/gadget/udc/pch_udc.c
index 613547f..cc8fb3c 100644
--- a/drivers/usb/gadget/udc/pch_udc.c
+++ b/drivers/usb/gadget/udc/pch_udc.c
@@ -2895,11 +2895,21 @@ static void pch_udc_pcd_reinit(struct pch_udc_dev *dev)
ep->in = ~i & 1;
ep->ep.name = ep_string[i];
ep->ep.ops = &pch_udc_ep_ops;
-   if (ep->in)
+   if (ep->in) {
ep->offset_addr = ep->num * UDC_EP_REG_SHIFT;
-   else
+   ep->ep.caps.dir_in = true;
+   } else {
ep->offset_addr = (UDC_EPINT_OUT_SHIFT + ep->num) *
  UDC_EP_REG_SHIFT;
+   ep->ep.caps.dir_out = true;
+   }
+   if (i == UDC_EP0IN_IDX || i == UDC_EP0OUT_IDX) {
+   ep->ep.caps.type_control = true;


In all previous patches you set both dir_in and dir_out to true for ep0 
but in this patch you don't do this. Is there some reason for this or 
it's just a mistake?



+   } else {
+   ep->ep.caps.type_iso = true;
+   ep->ep.caps.type_bulk = true;
+   ep->ep.caps.type_int = true;
+   }
/* need to set ep->ep.maxpacket and set Default Configuration?*/
usb_ep_set_maxpacket_limit(&ep->ep, UDC_BULK_MAX_PKT_SIZE);
list_add_tail(&ep->ep.ep_list, &dev->gadget.ep_list);



Best Regards,

--
Krzysztof Opasiak
Samsung R&D Institute Poland
Samsung Electronics
--
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 4/5] usb: gadget: mass_storage: Use static array for luns

[Michal Nazarewicz]

On Mon, Jul 20 2015, Krzysztof Opasiak wrote:
> Yeah I see it now. What I wrote was a problem before your patch but now 
> it seams to be ok, just nluns name is very misleading. Summing up, just 
> like you wrote this patch should not go to stable.

For me nluns has always been *size* of the luns array.  And with changes
from my patch, it’s size in the std::vector sense, i.e. it’s not the
same as capacity.

Your patchset gets away from nluns so this confusion will be cleared
anyway.

-- 
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of  o' \,=./ `o
..o | Computer Science,  Michał “mina86” Nazarewicz(o o)
ooo +--ooO--(_)--Ooo--
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/1] usb: chipidea: host: add own hc_driver for each hcd

[Alan Stern]

On Mon, 20 Jul 2015, Peter Chen wrote:

> > I don't think a new use case is needed.  All you have to do is add
> > something like this to host.c:
> > 
> > static void ci_hdrc_host_driver_init(void)
> > {
> > ehci_init_driver(&ci_ehci_hc_driver, &ehci_ci_overrides);

By the way, right here I forgot to include:

orig_bus_suspend = ci_ehci_hc_driver.bus_suspend;
ci_ehci_hc_driver.bus_suspend = ci_ehci_bus_suspend;

> > }
> > module_init(ci_hdrc_host_driver_init);
> > 
> > Can you think of any reason this won't work?
> > 
> 
> No, it will not work. The core driver's probe will run which will
> call host_start to call ehci APIs before ci_hdrc_host_driver_init
> is called.

Ah, I see the difficulty.  core.c does 
pci_register_driver(&ehci_pci_driver).  That will have to be different.
Let's change that line to this:

static int __init ci_hdrc_driver_init(void)
{
ci_hdrc_host_driver_init();
return platform_register_driver(&ci_hdrc_driver);
}
module_init(ci_hdrc_driver_init);

static void __exit ci_hdrc_driver_cleanup(void)
{
platform_unregister_driver(&ci_hdrc_driver);
}
module_exit(ci_hdrc_driver_cleanup);

Then in host.c, make ci_hdrc_host_driver_init non-static.

This should work, because the core's probe routine can't be called 
before it is registered as a platform driver, and that doesn't happen 
until after ehci_init_driver is called.

Alan Stern

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

Re: [PATCH v2 3/5] usb: phy: add usb3.0 phy driver for mt65xx SoCs

[chunfeng yun]

On Fri, 2015-07-10 at 08:42 +0200, Sascha Hauer wrote:
> On Wed, Jul 08, 2015 at 05:41:05PM +0800, Chunfeng Yun wrote:
> > Signed-off-by: Chunfeng Yun 
> > ---
> >  drivers/usb/phy/Kconfig   |  10 +
> >  drivers/usb/phy/Makefile  |   1 +
> >  drivers/usb/phy/phy-mt65xx-usb3.c | 856 
> > ++
> >  3 files changed, 867 insertions(+)
> >  create mode 100644 drivers/usb/phy/phy-mt65xx-usb3.c
> > 
> > diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
> > index 869c0cfcad..66ded00 100644
> > --- a/drivers/usb/phy/Kconfig
> > +++ b/drivers/usb/phy/Kconfig
> > @@ -152,6 +152,16 @@ config USB_MSM_OTG
> >   This driver is not supported on boards like trout which
> >   has an external PHY.
> >  
> > +config USB_MT65XX_USB3_PHY
> > +   tristate "Mediatek USB3.0 PHY controller Driver"
> > +   depends on ARCH_MEDIATEK || COMPILE_TEST
> > +   select USB_PHY
> > +   help
> > + Say 'Y' here to add support for Mediatek USB3.0 PHY driver
> > + for mt65xx SoCs. it supports two usb2.0 ports and
> > + one usb3.0 port.
> > + To compile this driver as a module, choose M here
> > +
> >  config USB_MV_OTG
> > tristate "Marvell USB OTG support"
> > depends on USB_EHCI_MV && USB_MV_UDC && PM
> > diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile
> > index e36ab1d..414ef57 100644
> > --- a/drivers/usb/phy/Makefile
> > +++ b/drivers/usb/phy/Makefile
> > @@ -20,6 +20,7 @@ obj-$(CONFIG_USB_EHCI_TEGRA)  += 
> > phy-tegra-usb.o
> >  obj-$(CONFIG_USB_GPIO_VBUS)+= phy-gpio-vbus-usb.o
> >  obj-$(CONFIG_USB_ISP1301)  += phy-isp1301.o
> >  obj-$(CONFIG_USB_MSM_OTG)  += phy-msm-usb.o
> > +obj-$(CONFIG_USB_MT65XX_USB3_PHY)  += phy-mt65xx-usb3.o
> >  obj-$(CONFIG_USB_MV_OTG)   += phy-mv-usb.o
> >  obj-$(CONFIG_USB_MXS_PHY)  += phy-mxs-usb.o
> >  obj-$(CONFIG_USB_RCAR_PHY) += phy-rcar-usb.o
> > diff --git a/drivers/usb/phy/phy-mt65xx-usb3.c 
> > b/drivers/usb/phy/phy-mt65xx-usb3.c
> > new file mode 100644
> > index 000..38ee6f3
> > --- /dev/null
> > +++ b/drivers/usb/phy/phy-mt65xx-usb3.c
> > @@ -0,0 +1,856 @@
> > +/*
> > + * Copyright (c) 2015 MediaTek Inc.
> > + * Author: Chunfeng.Yun 
> > + *
> > + * This software is licensed under the terms of the GNU General Public
> > + * License version 2, as published by the Free Software Foundation, and
> > + * may be copied, distributed, and modified under those terms.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > + * GNU General Public License for more details.
> > + *
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +/*
> > + * relative to MAC base address
> > + */
> > +#define SSUSB_USB3_MAC_CSR_BASE(0x1400)
> > +#define SSUSB_USB3_SYS_CSR_BASE(0x1400)
> > +#define SSUSB_USB2_CSR_BASE(0x2400)
> 
> Please drop the unnecessary braces.
> 
ok
> > +
> > +/*
> > + * for sifslv1 register
> > + * relative to USB3_SIF_BASE base address
> > + */
> > +#define SSUSB_SIFSLV_IPPC_BASE (0x700)
> > +
> > +/*
> > + * for sifslv2 register
> > + * relative to USB3_SIF_BASE base address
> > + */
> > +#define SSUSB_SIFSLV_U2PHY_COM_BASE(0x10800)
> > +#define SSUSB_SIFSLV_U3PHYD_BASE   (0x10900)
> > +#define SSUSB_SIFSLV_U2FREQ_BASE   (0x10f00)
> > +#define SSUSB_USB30_PHYA_SIV_B_BASE(0x10b00)
> > +#define SSUSB_SIFSLV_U3PHYA_DA_BASE(0x10c00)
> > +#define SSUSB_SIFSLV_SPLLC (0x1)
> > +
> > +/*port1 refs. +0x800(refer to port0)*/
> > +#define U3P_PORT_OFFSET (0x800)/*based on port0 */
> > +#define U3P_PHY_BASE(index) ((U3P_PORT_OFFSET) * (index))
> 
> According to my datasheet port(idx) base is at:
> 
> sif_base + 0x800 + 0x100 * idx
> 
> Am I missing something here?
Maybe, ssusb_sifslv_u2_phy_com_T28_Xp etc(X = 1,2,3,4)
and their interval is 0x800
 
> > +
> > +#define U3P_IP_PW_CTRL0(SSUSB_SIFSLV_IPPC_BASE + 0x)
> > +#define CTRL0_IP_SW_RST(0x1 << 0)
> > +
> > +#define U3P_IP_PW_CTRL1(SSUSB_SIFSLV_IPPC_BASE + 0x0004)
> > +#define CTRL1_IP_HOST_PDN  (0x1 << 0)
> > +
> > +#define U3P_IP_PW_CTRL2(SSUSB_SIFSLV_IPPC_BASE + 0x0008)
> > +#define CTRL2_IP_DEV_PDN   (0x1 << 0)
> > +
> > +#define U3P_IP_PW_STS1 (SSUSB_SIFSLV_IPPC_BASE + 0x0010)
> > +#define STS1_IP_SLEEP_STS  (0x1 << 30)
> > +#define STS1_U3_MAC_RST(0x1 << 16)
> > +#define STS1_SYS125_RST(0x1 << 10)
> > +#define STS1_REF_RST   (0x1 << 8)
> > +#define STS1_SYSPLL_STABLE (0x1 << 0)
> > +
> > +#define U3P_I

Re: [PATCH 1/4] usb: gadget: udc: bdc: Fix a driver crash on disconnect

[Felipe Balbi]

On Thu, Jul 16, 2015 at 05:47:35PM -0400, Al Cooper wrote:
> ep_dequeue() in bdc_ep.c was capturing the hw dequeue pointer
> incorrectly by reading the wrong register for the upper 32 bits.
> The header file defining the registers was incorrect.
> 
> Signed-off-by: Al Cooper 

so you fix a driver crash by introducing a build error ? Test your
patches before sending them out.

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH] Fix data loss in cdc-acm

[Johan Hovold]

[ +CC: Alan, Oliver, Peter, Toby, linux-serial, linux-usb ]

On Sun, Jul 19, 2015 at 11:37:07PM +0200, Sven Brauch wrote:
> Since acm_process_read_urb does not check the return value
> of tty_insert_flip_string, it can happen that not all data
> is copied from the urb to the tty if the tty buffer
> is full and throttling does not set in quickly enough. This
> problem is very evident for devices with high data throughput;
> for a device with ~12 MB/s of data transfer, I get a few
> missing kB of data every few MB transferred randomly.

What kernel version are you using?

> To solve this problem, a check is introduced which verifies
> that indeed all data was copied from the urb to the tty buffer.
> If that is not the case, the urb is held in a queue instead
> of resubmitting it to the USB subsystem right away. When new
> data arrives or the tty is unthrottled, the queue is emptied
> again (as far as possible).
> 
> Effectively, this change will force the transmitting USB device
> to wait until the tty buffer can accept new data again, instead
> of discarding the data in this case.

The idea of adding another layer of buffering in the cdc-acm driver has
been suggested in the past but was rejected (or at least questioned).
See for example this thread:

https://lkml.kernel.org/r/20110608164626.22bc8...@lxorguk.ukuu.org.uk

The tty buffers are quite large these days, but could possibly be bumped
further if needed to give the ldisc some more time to throttle the
device at very high speeds.

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 3/3] usb: dwc3: gadget: return error if command sent to DEPCMD register fails

[Felipe Balbi]

Hi,

On Wed, Jul 15, 2015 at 09:49:05AM +, Subbaraya Sundeep Bhatta wrote:
> Hi John,
> 
> > -Original Message-
> > From: Felipe Balbi [mailto:ba...@ti.com]
> > Sent: Tuesday, July 14, 2015 12:29 AM
> > To: John Youn
> > Cc: ba...@ti.com; Subbaraya Sundeep Bhatta; gre...@linuxfoundation.org;
> > linux-usb@vger.kernel.org; linux-ker...@vger.kernel.org;
> > sta...@vger.kernel.org
> > Subject: Re: [PATCH v2 3/3] usb: dwc3: gadget: return error if command
> > sent to DEPCMD register fails
> > 
> > Hi,
> > 
> > On Mon, Jul 13, 2015 at 05:50:49PM +, John Youn wrote:
> > > On 7/11/2015 12:29 PM, Felipe Balbi wrote:
> > > > Hi,
> > > >
> > > > On Sat, Jul 11, 2015 at 05:17:32PM +, Subbaraya Sundeep Bhatta
> > wrote:
> > > >> Hi Felipe,
> > > >>
> > > >> Just an update on this.
> > > >>
> > > >> I'm trying to get this working with our latest IP with dwc3
> > > >> from your testing/next branch. It fails the usbtest with a
> > > >> problem unrelated to this patch.
> > > >> .
> > > >> It passes on 4.1.1.
> > > >>
> > > >> I'll have to look into the failure but I won't get to it until
> > > >> next week as I'm off the rest of this week.
> > > >
> > > > interesting... If you could post failure signature, I can help
> > > > looking at it, but I guess it's too late to ask :-)
> > > >
> > > > thanks for helping though
> > > >
> > > 
> > > 
> > >  Hi Felipe,
> > > 
> > >  Nevermind about my issue, it ended up being a setup-related
> > problem.
> > > 
> > >  I actually do see the same error as you due to this series of 
> > >  patches.
> > >  Except I see it happening before even the first iteration. I get
> > >  a completion status of 1 for the Set Endpoint Transfer Resources
> > >  command. I'm not sure why this is.
> > > 
> > >  I don't see any conflict with any previous Transfer Complete.
> > > >>
> > > >> Same behavior at my end too. Fails before first iteration and I get
> > > >> completion status of 1 for Set Endpoint Resource command. Attached
> > > >> the logs of testing done with this patch and without this patch.
> > > >> Without this patch I often see completion status of 1 for Set
> > > >> Endpoint Transfer Resources command for Bulk and Isoc endpoints but
> > > >> test proceeds because driver just logs command completion status
> > > >> and moves on. We can revert this patch for time being. IP version is
> > 2.90a.
> > > >
> > > > yeah, that's what I mean, it really seems like it's the IP misbehaving.
> > > >
> > > > John, let's try to figure out what's the root cause of this, we
> > > > really want to use command completion status at some point, but for
> > > > now we need to revert the patch :-(
> > > >
> > > > Let me know if you want me to log STARS ticket on your solvnet system.
> > > >
> > > > cheers
> > > >
> > >
> > > Hi Felipe,
> > >
> > > We found the issue last week.
> > >
> > > The start config command isn't getting called during SET_INTERFACE.
> > > Thus the transfer resource index isn't getting reset, and with
> > > multiple SET_INTERFACE commands it will eventually exhaust the
> > > resources.
> > >
> > > I tried out a fix and it works for me. I'll send it out separately for
> > > review.
> 
> Thanks John for debugging :). Yes we are not handling SET_INTERFACE similar to
> SET_CONFIGURATION in driver. I guess we follow 
> "Alternate Initialization on SetInterface Request" sequence as per data book.
> Felipe can confirm this.
> 
> > 
> > Thanks a lot John. Not sure how come we missed that for such a long time
> > :-) Let's Cc stable and get it plugged ASAP :-)
> > 
> > > Also, I noticed that the trace message that shows control transfers
> > > doesn't show the SET_INTERFACE properly. Any idea why this is?
> > >
> > > For example, here is the line in the trace that corresponds to the
> > > SET_INTERFACE:
> > > irq/33-dwc3-10808 [003] d...  2443.494368: dwc3_ctrl_req:
> > bRequestType
> > > 01 bRequest 0b wValue 0001 wIndex  wLength 0
> 
> Can you please elaborate? What is expected here? Did you mean it shows wrong 
> info
> (other than the request actually sent by Host) ?

I have been looking more at this and the reason why we're failing is a
patch from Paul, which I quote below:

commit b23c843992b659d537514e6493d673284f5d6724
Author: Paul Zimmerman 
Date:   Fri Sep 30 10:58:42 2011 +0300

usb: dwc3: gadget: fix DEPSTARTCFG for non-EP0 EPs

DEPSTARTCFG for non-EP0 EPs must only be sent once per config

[ ba...@ti.com : changed config_start to start_config_issued ]

Signed-off-by: Paul Zimmerman 
Signed-off-by: Felipe Balbi 
Signed-off-by: Greg Kroah-Hartman 

diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 0231eba1f53d..502582ce1fc6 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -529,6 +529,7 @@ static inline void dwc3_trb_to_nat(struct dwc3_trb_hw *hw, 
struct dwc3_trb *nat

Re: [PATCH] Fix data loss in cdc-acm

[Sven Brauch]

On 20/07/15 19:25, Johan Hovold wrote:
> What kernel version are you using?
I'm using linux 4.1.2.

> The idea of adding another layer of buffering in the cdc-acm driver has
> been suggested in the past but was rejected (or at least questioned).
> See for example this thread:
> 
>   https://lkml.kernel.org/r/20110608164626.22bc8...@lxorguk.ukuu.org.uk
Yes, that is indeed pretty much the same problem and the same solution.
Answering to the questions brought up in that thread:

> a) Why is your setup filling 64K in the time it takes the throttle
> response to occur
As far as I understand, the throttle happens only when there's less than
128 bytes of free space in the tty buffer. Data can already be lost
before the tty even decides it should start throttling, simply because
the throttle threshold is smaller than the amount of data potentially in
each urb. Also (excuse my cluelessness) it seems that when exactly the
throttling happens depends on some scheduling "jitter" as well.
Additionally, the response of the cdc_acm driver to a throttle request
is not very prompt; it might have a queue of up to 16kB (16 urbs) pending.

> b) Do we care (is the right thing to do to lose bits anyway at
> that point)
This I cannot answer, I don't know enough about the architecture or
standards. I can just say that for my case, there's a lot of losses;
this it not an issue which happens after hours when the system is under
heavy load, it happens after just a few seconds reproducably.

> The tty buffers are quite large these days, but could possibly be bumped
> further if needed to give the ldisc some more time to throttle the
> device at very high speeds.
I do not like this solution. It will again be based on luck, and you
will still be unable to rely on the delivery guarantee made by the USB
stack (at least when using bulk).
My suggestion instead stops the host system from accepting any more data
from the device when its buffers are full, forcing the device to wait
before sending out more data (which many kinds of devices might very
well be able to do).

Also note that this patch does not introduce an extra layer of
buffering. The buffers are already there; this change just alters the
process which decides when to submit the buffers to the tty, and when to
free them for more input data from the device.

Sven




signature.asc
Description: OpenPGP digital signature

[PATCH v4 0/5] Mass storage fixes and improvements

[Krzysztof Opasiak]

Hello,

This series fix a few bugs in mass storage function, adds a warning
message when binding function with not contiguous LUN ids and replace
dynamically allocated luns array with static one what simplifies the
code.

Best regards,

-- 
Krzysztof Opasiak
Samsung R&D Institute Poland
Samsung Electronics 

---
Changes since v3:
- fix commit messages

Changes since v2:
- drop nluns from fsg_common as discussed with Michal
- rebased onto balbi/fixes


Krzysztof Opasiak (5):
  usb: gadget: mass_storage: Free buffers if create lun fails
  usb: gadget: mass_storage: Place EXPORT_SYMBOL_GPL() after func
definition
  usb: gadget: storage-common: Set FSG_MAX_LUNS to 16
  usb: gadget: mass_storage: Use static array for luns
  usb: gadget: mass_storage: Warn if LUNs ids are not contiguous

 drivers/usb/gadget/function/f_mass_storage.c |  143 +++---
 drivers/usb/gadget/function/f_mass_storage.h |4 -
 drivers/usb/gadget/function/storage_common.h |2 +-
 drivers/usb/gadget/legacy/acm_ms.c   |6 --
 drivers/usb/gadget/legacy/mass_storage.c |6 --
 drivers/usb/gadget/legacy/multi.c|6 --
 6 files changed, 60 insertions(+), 107 deletions(-)

-- 
1.7.9.5

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

[PATCH v4 1/5] usb: gadget: mass_storage: Free buffers if create lun fails

[Krzysztof Opasiak]

Creation of LUN 0 may fail (for example due to ENOMEM).
As fsg_common_set_num_buffers() does some memory allocation
we should free it before it becomes unavailable.

Signed-off-by: Krzysztof Opasiak 
Acked-by: Michal Nazarewicz 
---
 drivers/usb/gadget/function/f_mass_storage.c |5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/usb/gadget/function/f_mass_storage.c 
b/drivers/usb/gadget/function/f_mass_storage.c
index f936268..f72102a 100644
--- a/drivers/usb/gadget/function/f_mass_storage.c
+++ b/drivers/usb/gadget/function/f_mass_storage.c
@@ -3524,6 +3524,9 @@ static struct usb_function_instance *fsg_alloc_inst(void)
config.removable = true;
rc = fsg_common_create_lun(opts->common, &config, 0, "lun.0",
(const char **)&opts->func_inst.group.cg_item.ci_name);
+   if (rc)
+   goto release_buffers;
+
opts->lun0.lun = opts->common->luns[0];
opts->lun0.lun_id = 0;
config_group_init_type_name(&opts->lun0.group, "lun.0", &fsg_lun_type);
@@ -3534,6 +3537,8 @@ static struct usb_function_instance *fsg_alloc_inst(void)
 
return &opts->func_inst;
 
+release_buffers:
+   fsg_common_free_buffers(opts->common);
 release_luns:
kfree(opts->common->luns);
 release_opts:
-- 
1.7.9.5

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

[PATCH v4 2/5] usb: gadget: mass_storage: Place EXPORT_SYMBOL_GPL() after func definition

[Krzysztof Opasiak]

EXPORT_SYMBOL_GPL() is usually placed after function definition
not before.

Signed-off-by: Krzysztof Opasiak 
Acked-by: Michal Nazarewicz 
---
 drivers/usb/gadget/function/f_mass_storage.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/gadget/function/f_mass_storage.c 
b/drivers/usb/gadget/function/f_mass_storage.c
index f72102a..c3b62c7 100644
--- a/drivers/usb/gadget/function/f_mass_storage.c
+++ b/drivers/usb/gadget/function/f_mass_storage.c
@@ -2761,12 +2761,12 @@ static void _fsg_common_remove_luns(struct fsg_common 
*common, int n)
common->luns[i] = NULL;
}
 }
-EXPORT_SYMBOL_GPL(fsg_common_remove_luns);
 
 void fsg_common_remove_luns(struct fsg_common *common)
 {
_fsg_common_remove_luns(common, common->nluns);
 }
+EXPORT_SYMBOL_GPL(fsg_common_remove_luns);
 
 void fsg_common_free_luns(struct fsg_common *common)
 {
-- 
1.7.9.5

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

[PATCH v4 3/5] usb: gadget: storage-common: Set FSG_MAX_LUNS to 16

[Krzysztof Opasiak]

Mass storage spec allows up to 16 LUNs, so let's not
add some more restrictive limits.

Signed-off-by: Krzysztof Opasiak 
Acked-by: Michal Nazarewicz 
---
 drivers/usb/gadget/function/f_mass_storage.c |2 +-
 drivers/usb/gadget/function/storage_common.h |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/gadget/function/f_mass_storage.c 
b/drivers/usb/gadget/function/f_mass_storage.c
index c3b62c7..9e88e2b 100644
--- a/drivers/usb/gadget/function/f_mass_storage.c
+++ b/drivers/usb/gadget/function/f_mass_storage.c
@@ -54,7 +54,7 @@
  * following fields:
  *
  * nluns   Number of LUNs function have (anywhere from 1
- * to FSG_MAX_LUNS which is 8).
+ * to FSG_MAX_LUNS).
  * lunsAn array of LUN configuration values.  This
  * should be filled for each LUN that
  * function will include (ie. for "nluns"
diff --git a/drivers/usb/gadget/function/storage_common.h 
b/drivers/usb/gadget/function/storage_common.h
index 70c8914..c3544e6 100644
--- a/drivers/usb/gadget/function/storage_common.h
+++ b/drivers/usb/gadget/function/storage_common.h
@@ -123,7 +123,7 @@ static inline bool fsg_lun_is_open(struct fsg_lun *curlun)
 #define FSG_BUFLEN ((u32)16384)
 
 /* Maximal number of LUNs supported in mass storage function */
-#define FSG_MAX_LUNS   8
+#define FSG_MAX_LUNS   16
 
 enum fsg_buffer_state {
BUF_STATE_EMPTY = 0,
-- 
1.7.9.5

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

[PATCH v4 5/5] usb: gadget: mass_storage: Warn if LUNs ids are not contiguous

[Krzysztof Opasiak]

According to mass storage specification:

"Logical Unit Numbers on the device shall be numbered contiguously
 starting from LUN 0 to a maximum LUN of 15 (Fh)"

So let's at least print a warning message that LUNs ids should be
contiguous.

Signed-off-by: Krzysztof Opasiak 
Acked-by: Michal Nazarewicz 
---
 drivers/usb/gadget/function/f_mass_storage.c |7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/usb/gadget/function/f_mass_storage.c 
b/drivers/usb/gadget/function/f_mass_storage.c
index 5fcd9a0..69167ad 100644
--- a/drivers/usb/gadget/function/f_mass_storage.c
+++ b/drivers/usb/gadget/function/f_mass_storage.c
@@ -3042,6 +3042,13 @@ static int fsg_bind(struct usb_configuration *c, struct 
usb_function *f)
return -EINVAL;
}
 
+   for (i = 0; i < ARRAY_SIZE(common->luns); ++i)
+   if (!common->luns[i])
+   break;
+
+   if (ret != i - 1)
+   pr_err("LUN ids should be contiguous.\n");
+
opts = fsg_opts_from_func_inst(f->fi);
if (!opts->no_configfs) {
ret = fsg_common_set_cdev(fsg->common, c->cdev,
-- 
1.7.9.5

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

[PATCH v4 4/5] usb: gadget: mass_storage: Use static array for luns

[Krzysztof Opasiak]

This patch replace dynamicly allocated luns array with static one.
This simplifies the code of mass storage function and modules.

Signed-off-by: Krzysztof Opasiak 
Acked-by: Michal Nazarewicz 
---
 drivers/usb/gadget/function/f_mass_storage.c |  127 +-
 drivers/usb/gadget/function/f_mass_storage.h |4 -
 drivers/usb/gadget/legacy/acm_ms.c   |6 --
 drivers/usb/gadget/legacy/mass_storage.c |6 --
 drivers/usb/gadget/legacy/multi.c|6 --
 5 files changed, 45 insertions(+), 104 deletions(-)

diff --git a/drivers/usb/gadget/function/f_mass_storage.c 
b/drivers/usb/gadget/function/f_mass_storage.c
index 9e88e2b..5fcd9a0 100644
--- a/drivers/usb/gadget/function/f_mass_storage.c
+++ b/drivers/usb/gadget/function/f_mass_storage.c
@@ -279,9 +279,8 @@ struct fsg_common {
int cmnd_size;
u8  cmnd[MAX_COMMAND_SIZE];
 
-   unsigned intnluns;
unsigned intlun;
-   struct fsg_lun  **luns;
+   struct fsg_lun  *luns[FSG_MAX_LUNS];
struct fsg_lun  *curlun;
 
unsigned intbulk_out_maxpacket;
@@ -490,6 +489,16 @@ static void bulk_out_complete(struct usb_ep *ep, struct 
usb_request *req)
spin_unlock(&common->lock);
 }
 
+static int _fsg_common_get_max_lun(struct fsg_common *common)
+{
+   int i = ARRAY_SIZE(common->luns) - 1;
+
+   while (i >= 0 && !common->luns[i])
+   --i;
+
+   return i;
+}
+
 static int fsg_setup(struct usb_function *f,
 const struct usb_ctrlrequest *ctrl)
 {
@@ -533,7 +542,7 @@ static int fsg_setup(struct usb_function *f,
w_length != 1)
return -EDOM;
VDBG(fsg, "get max LUN\n");
-   *(u8 *)req->buf = fsg->common->nluns - 1;
+   *(u8 *)req->buf = _fsg_common_get_max_lun(fsg->common);
 
/* Respond with data/status */
req->length = min((u16)1, w_length);
@@ -2131,8 +2140,9 @@ static int received_cbw(struct fsg_dev *fsg, struct 
fsg_buffhd *bh)
}
 
/* Is the CBW meaningful? */
-   if (cbw->Lun >= FSG_MAX_LUNS || cbw->Flags & ~US_BULK_FLAG_IN ||
-   cbw->Length <= 0 || cbw->Length > MAX_COMMAND_SIZE) {
+   if (cbw->Lun >= ARRAY_SIZE(common->luns) ||
+   cbw->Flags & ~US_BULK_FLAG_IN || cbw->Length <= 0 ||
+   cbw->Length > MAX_COMMAND_SIZE) {
DBG(fsg, "non-meaningful CBW: lun = %u, flags = 0x%x, "
"cmdlen %u\n",
cbw->Lun, cbw->Flags, cbw->Length);
@@ -2159,7 +2169,7 @@ static int received_cbw(struct fsg_dev *fsg, struct 
fsg_buffhd *bh)
if (common->data_size == 0)
common->data_dir = DATA_DIR_NONE;
common->lun = cbw->Lun;
-   if (common->lun < common->nluns)
+   if (common->lun < ARRAY_SIZE(common->luns))
common->curlun = common->luns[common->lun];
else
common->curlun = NULL;
@@ -2307,7 +2317,7 @@ reset:
}
 
common->running = 1;
-   for (i = 0; i < common->nluns; ++i)
+   for (i = 0; i < ARRAY_SIZE(common->luns); ++i)
if (common->luns[i])
common->luns[i]->unit_attention_data =
SS_RESET_OCCURRED;
@@ -2409,7 +2419,7 @@ static void handle_exception(struct fsg_common *common)
if (old_state == FSG_STATE_ABORT_BULK_OUT)
common->state = FSG_STATE_STATUS_PHASE;
else {
-   for (i = 0; i < common->nluns; ++i) {
+   for (i = 0; i < ARRAY_SIZE(common->luns); ++i) {
curlun = common->luns[i];
if (!curlun)
continue;
@@ -2453,7 +2463,7 @@ static void handle_exception(struct fsg_common *common)
 * a waste of time.  Ditto for the INTERFACE_CHANGE and
 * CONFIG_CHANGE cases.
 */
-   /* for (i = 0; i < common->nluns; ++i) */
+   /* for (i = 0; i < common->ARRAY_SIZE(common->luns); ++i) */
/*  if (common->luns[i]) */
/*  common->luns[i]->unit_attention_data = */
/*  SS_RESET_OCCURRED;  */
@@ -2552,12 +2562,11 @@ static int fsg_main_thread(void *common_)
 
if (!common->ops || !common->ops->thread_exits
 || common->ops->thread_exits(common) < 0) {
-   struct fsg_lun **curlun_it = common->luns;
-   unsigned i = common->nluns;
+   int i;
 
down_write(&common->filesem);
-   for (; i--; ++curlun_it) {
-   struct fsg_lun *curlun = *curlun_it;
+   for (i = 0; i < ARRAY_SIZE(common->luns); --i) {
+   struct fsg_lun *curlun = common->

Re: [PATCH v2 3/3] usb: dwc3: gadget: return error if command sent to DEPCMD register fails

[John Youn]

On 7/20/2015 10:51 AM, Felipe Balbi wrote:
> Hi,
> 
> On Wed, Jul 15, 2015 at 09:49:05AM +, Subbaraya Sundeep Bhatta wrote:
>> Hi John,
>>
>>> -Original Message-
>>> From: Felipe Balbi [mailto:ba...@ti.com]
>>> Sent: Tuesday, July 14, 2015 12:29 AM
>>> To: John Youn
>>> Cc: ba...@ti.com; Subbaraya Sundeep Bhatta; gre...@linuxfoundation.org;
>>> linux-usb@vger.kernel.org; linux-ker...@vger.kernel.org;
>>> sta...@vger.kernel.org
>>> Subject: Re: [PATCH v2 3/3] usb: dwc3: gadget: return error if command
>>> sent to DEPCMD register fails
>>>
>>> Hi,
>>>
>>> On Mon, Jul 13, 2015 at 05:50:49PM +, John Youn wrote:
 On 7/11/2015 12:29 PM, Felipe Balbi wrote:
> Hi,
>
> On Sat, Jul 11, 2015 at 05:17:32PM +, Subbaraya Sundeep Bhatta
>>> wrote:
>> Hi Felipe,
>>
>> Just an update on this.
>>
>> I'm trying to get this working with our latest IP with dwc3
>> from your testing/next branch. It fails the usbtest with a
>> problem unrelated to this patch.
>> .
>> It passes on 4.1.1.
>>
>> I'll have to look into the failure but I won't get to it until
>> next week as I'm off the rest of this week.
>
> interesting... If you could post failure signature, I can help
> looking at it, but I guess it's too late to ask :-)
>
> thanks for helping though
>


 Hi Felipe,

 Nevermind about my issue, it ended up being a setup-related
>>> problem.

 I actually do see the same error as you due to this series of patches.
 Except I see it happening before even the first iteration. I get
 a completion status of 1 for the Set Endpoint Transfer Resources
 command. I'm not sure why this is.

 I don't see any conflict with any previous Transfer Complete.
>>
>> Same behavior at my end too. Fails before first iteration and I get
>> completion status of 1 for Set Endpoint Resource command. Attached
>> the logs of testing done with this patch and without this patch.
>> Without this patch I often see completion status of 1 for Set
>> Endpoint Transfer Resources command for Bulk and Isoc endpoints but
>> test proceeds because driver just logs command completion status
>> and moves on. We can revert this patch for time being. IP version is
>>> 2.90a.
>
> yeah, that's what I mean, it really seems like it's the IP misbehaving.
>
> John, let's try to figure out what's the root cause of this, we
> really want to use command completion status at some point, but for
> now we need to revert the patch :-(
>
> Let me know if you want me to log STARS ticket on your solvnet system.
>
> cheers
>

 Hi Felipe,

 We found the issue last week.

 The start config command isn't getting called during SET_INTERFACE.
 Thus the transfer resource index isn't getting reset, and with
 multiple SET_INTERFACE commands it will eventually exhaust the
 resources.

 I tried out a fix and it works for me. I'll send it out separately for
 review.
>>
>> Thanks John for debugging :). Yes we are not handling SET_INTERFACE similar 
>> to
>> SET_CONFIGURATION in driver. I guess we follow 
>> "Alternate Initialization on SetInterface Request" sequence as per data book.
>> Felipe can confirm this.
>>
>>>
>>> Thanks a lot John. Not sure how come we missed that for such a long time
>>> :-) Let's Cc stable and get it plugged ASAP :-)
>>>
 Also, I noticed that the trace message that shows control transfers
 doesn't show the SET_INTERFACE properly. Any idea why this is?

 For example, here is the line in the trace that corresponds to the
 SET_INTERFACE:
 irq/33-dwc3-10808 [003] d...  2443.494368: dwc3_ctrl_req:
>>> bRequestType
 01 bRequest 0b wValue 0001 wIndex  wLength 0
>>
>> Can you please elaborate? What is expected here? Did you mean it shows wrong 
>> info
>> (other than the request actually sent by Host) ?
> 
> I have been looking more at this and the reason why we're failing is a
> patch from Paul, which I quote below:
> 
> commit b23c843992b659d537514e6493d673284f5d6724
> Author: Paul Zimmerman 
> Date:   Fri Sep 30 10:58:42 2011 +0300
> 
> usb: dwc3: gadget: fix DEPSTARTCFG for non-EP0 EPs
> 
> DEPSTARTCFG for non-EP0 EPs must only be sent once per config
> 
> [ ba...@ti.com : changed config_start to start_config_issued ]
> 
> Signed-off-by: Paul Zimmerman 
> Signed-off-by: Felipe Balbi 
> Signed-off-by: Greg Kroah-Hartman 
> 
> diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
> index 0231eba1f53d..502582ce1fc6 100644
> --- a/drivers/usb/dwc3/core.h
> +++ b/drivers/usb/dwc3/core.h
> @@ -529,6 +529,7 @@ static inline void dwc3_trb_to_nat(struct dwc3_trb_hw 
> *hw, struct dwc3_trb *nat)
>   * @ep0_status_pending: ep

Several races in "usbnet" module (kernel 4.1.x)

[Eugene Shatokhin]

Hi,

I have recently found several data races in "usbnet" module, checked on 
vanilla kernel 4.1.0 on x86_64. The races do actually happen, I have 
confirmed it by adding delays and using hardware breakpoints to detect 
the conflicting memory accesses (with RaceHound tool, 
https://github.com/winnukem/racehound).


I have not analyzed yet how harmful these races are (if they are), but 
it is better to report them anyway, I think.


Everything was checked using YOTA 4G LTE Modem that works via "usbnet" 
and "cdc_ether" kernel modules.

--

[Race #1]

Race on skb_queue ('next' pointer) between usbnet_stop() and rx_complete().

Reproduced that by unplugging the device while the system was 
downloading a large file from the Net.


Here is part of the call stack with the code where the changes to the 
queue happen:


#0 __skb_unlink (skbuff.h:1517) 
prev->next = next;
#1 defer_bh (usbnet.c:430)
spin_lock_irqsave(&list->lock, flags);
old_state = entry->state;
entry->state = state;
__skb_unlink(skb, list);
spin_unlock(&list->lock);
spin_lock(&dev->done.lock);
__skb_queue_tail(&dev->done, skb);
if (dev->done.qlen == 1)
tasklet_schedule(&dev->bh);
spin_unlock_irqrestore(&dev->done.lock, flags);
#2 rx_complete (usbnet.c:640)
state = defer_bh(dev, skb, &dev->rxq, state);

At the same time, the following code repeatedly checks if the queue is 
empty and reads the same values concurrently with the above changes:


#0  usbnet_terminate_urbs (usbnet.c:765)
/* maybe wait for deletions to finish. */
while (!skb_queue_empty(&dev->rxq)
&& !skb_queue_empty(&dev->txq)
&& !skb_queue_empty(&dev->done)) {
schedule_timeout(msecs_to_jiffies(UNLINK_TIMEOUT_MS));
set_current_state(TASK_UNINTERRUPTIBLE);
netif_dbg(dev, ifdown, dev->net,
  "waited for %d urb completions\n", temp);
}
#1  usbnet_stop (usbnet.c:806)
if (!(info->flags & FLAG_AVOID_UNLINK_URBS))
usbnet_terminate_urbs(dev);

For example, it is possible that the skb is removed from dev->rxq by 
__skb_unlink() before the check "!skb_queue_empty(&dev->rxq)" in 
usbnet_terminate_urbs() is made. It is also possible in this case that 
the skb is added to dev->done queue after "!skb_queue_empty(&dev->done)" 
is checked. So usbnet_terminate_urbs() may stop waiting and return while 
dev->done queue still has an item.

--

Unrelated the that race, if the goal of that while loop in 
usbnet_terminate_urbs() is to wait till all three queues (dev->rxq, 
dev->txq, dev->done) become empty, perhaps the code should be changed as 
follows:


while (!skb_queue_empty(&dev->rxq)
-   && !skb_queue_empty(&dev->txq)
-   && !skb_queue_empty(&dev->done)) {
+   || !skb_queue_empty(&dev->txq)
+   || !skb_queue_empty(&dev->done)) {
schedule_timeout(...));
--

[Race #2]

Races on dev->rx_qlen. Reproduced these by repeatedly changing MTU (1500 
<-> 1400) while downloading large files.


dev->rx_qlen is written to here:
#0  usbnet_update_max_qlen (usbnet.c:351)
case USB_SPEED_HIGH:
dev->rx_qlen = MAX_QUEUE_MEMORY / dev->rx_urb_size;
#1  __handle_link_change (usbnet.c:1049)
/* hard_mtu or rx_urb_size may change during link change */
usbnet_update_max_qlen(dev);
#2  usbnet_deferred_kevent (usbnet.c:1172)
if (test_bit (EVENT_LINK_CHANGE, &dev->flags))
__handle_link_change(dev);

Here are the conflicting reads from dev->rx_qlen (via RX_QLEN(dev)), 3 
code locations:


* usbnet_bh (usbnet.c:1492)
if (temp < RX_QLEN(dev)) { ...
* usbnet_bh (usbnet.c:1499)
if (dev->rxq.qlen < RX_QLEN(dev)) ...
* rx_alloc_submit (usbnet.c:1431)
for (i = 0; i < 10 && dev->rxq.qlen < RX_QLEN(dev); i++) { ...
--

[Race #3]

Similar to race #2 but on dev->tx_qlen. I reproduced it the same way.

dev->tx_qlen is written to here:
#0  usbnet_update_max_qlen (usbnet.c:352)
case USB_SPEED_HIGH:
dev->rx_qlen = MAX_QUEUE_MEMORY / dev->rx_urb_size;
dev->tx_qlen = MAX_QUEUE_MEMORY / dev->hard_mtu;
#1  __handle_link_change (usbnet.c:1049)
/* hard_mtu or rx_urb_size may change during link change */
usbnet_update_max_qlen(dev);
#2  usbnet_deferred_kevent (usbnet.c:1172)
if (test_bit (EVENT_LINK_CHANGE, &dev->flags))
__handle_link_change(dev);

Here are the conflicting reads from dev->tx_qlen (via TX_QLEN(dev)), 2 
code locations:


* usbnet_bh (usbnet.c:1502)
if (dev->txq.qlen < TX_QLEN (dev))
netif_wake_queue (dev->net);
* usbnet_start_xmit (usbnet.c:1398)
if (dev->txq.ql

[PATCH] usb: dwc3: Reset the transfer resource index on SET_INTERFACE

[John Youn]

This fixes an issue introduced in a previous patch that added checking of the
return status of device endpoint commands. It caught the Set Endpoint Transfer
Resource command failing occasionally. This is because the Transfer Resource
Index was not getting reset during a SET_INTERFACE request.

Signed-off-by: John Youn 
---
 drivers/usb/dwc3/ep0.c | 4 
 1 file changed, 4 insertions(+)


diff --git a/drivers/usb/dwc3/ep0.c b/drivers/usb/dwc3/ep0.c
index 2ef3c8d..69e769c 100644
--- a/drivers/usb/dwc3/ep0.c
+++ b/drivers/usb/dwc3/ep0.c
@@ -727,6 +727,10 @@ static int dwc3_ep0_std_request(struct dwc3 *dwc, struct 
usb_ctrlrequest *ctrl)
dwc3_trace(trace_dwc3_ep0, "USB_REQ_SET_ISOCH_DELAY");
ret = dwc3_ep0_set_isoch_delay(dwc, ctrl);
break;
+   case USB_REQ_SET_INTERFACE:
+   dwc3_trace(trace_dwc3_ep0, "USB_REQ_SET_INTERFACE");
+   dwc->start_config_issued = false;
+   /* Fall through */
default:
dwc3_trace(trace_dwc3_ep0, "Forwarding to gadget driver");
ret = dwc3_ep0_delegate_req(dwc, ctrl);
-- 
2.3.2

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

Re: [PATCH v2 3/3] usb: dwc3: gadget: return error if command sent to DEPCMD register fails

[Felipe Balbi]

On Mon, Jul 20, 2015 at 06:16:46PM +, John Youn wrote:
> On 7/20/2015 10:51 AM, Felipe Balbi wrote:
> > Hi,
> > 
> > On Wed, Jul 15, 2015 at 09:49:05AM +, Subbaraya Sundeep Bhatta wrote:
> >> Hi John,
> >>
> >>> -Original Message-
> >>> From: Felipe Balbi [mailto:ba...@ti.com]
> >>> Sent: Tuesday, July 14, 2015 12:29 AM
> >>> To: John Youn
> >>> Cc: ba...@ti.com; Subbaraya Sundeep Bhatta; gre...@linuxfoundation.org;
> >>> linux-usb@vger.kernel.org; linux-ker...@vger.kernel.org;
> >>> sta...@vger.kernel.org
> >>> Subject: Re: [PATCH v2 3/3] usb: dwc3: gadget: return error if command
> >>> sent to DEPCMD register fails
> >>>
> >>> Hi,
> >>>
> >>> On Mon, Jul 13, 2015 at 05:50:49PM +, John Youn wrote:
>  On 7/11/2015 12:29 PM, Felipe Balbi wrote:
> > Hi,
> >
> > On Sat, Jul 11, 2015 at 05:17:32PM +, Subbaraya Sundeep Bhatta
> >>> wrote:
> >> Hi Felipe,
> >>
> >> Just an update on this.
> >>
> >> I'm trying to get this working with our latest IP with dwc3
> >> from your testing/next branch. It fails the usbtest with a
> >> problem unrelated to this patch.
> >> .
> >> It passes on 4.1.1.
> >>
> >> I'll have to look into the failure but I won't get to it until
> >> next week as I'm off the rest of this week.
> >
> > interesting... If you could post failure signature, I can help
> > looking at it, but I guess it's too late to ask :-)
> >
> > thanks for helping though
> >
> 
> 
>  Hi Felipe,
> 
>  Nevermind about my issue, it ended up being a setup-related
> >>> problem.
> 
>  I actually do see the same error as you due to this series of 
>  patches.
>  Except I see it happening before even the first iteration. I get
>  a completion status of 1 for the Set Endpoint Transfer Resources
>  command. I'm not sure why this is.
> 
>  I don't see any conflict with any previous Transfer Complete.
> >>
> >> Same behavior at my end too. Fails before first iteration and I get
> >> completion status of 1 for Set Endpoint Resource command. Attached
> >> the logs of testing done with this patch and without this patch.
> >> Without this patch I often see completion status of 1 for Set
> >> Endpoint Transfer Resources command for Bulk and Isoc endpoints but
> >> test proceeds because driver just logs command completion status
> >> and moves on. We can revert this patch for time being. IP version is
> >>> 2.90a.
> >
> > yeah, that's what I mean, it really seems like it's the IP misbehaving.
> >
> > John, let's try to figure out what's the root cause of this, we
> > really want to use command completion status at some point, but for
> > now we need to revert the patch :-(
> >
> > Let me know if you want me to log STARS ticket on your solvnet system.
> >
> > cheers
> >
> 
>  Hi Felipe,
> 
>  We found the issue last week.
> 
>  The start config command isn't getting called during SET_INTERFACE.
>  Thus the transfer resource index isn't getting reset, and with
>  multiple SET_INTERFACE commands it will eventually exhaust the
>  resources.
> 
>  I tried out a fix and it works for me. I'll send it out separately for
>  review.
> >>
> >> Thanks John for debugging :). Yes we are not handling SET_INTERFACE 
> >> similar to
> >> SET_CONFIGURATION in driver. I guess we follow 
> >> "Alternate Initialization on SetInterface Request" sequence as per data 
> >> book.
> >> Felipe can confirm this.
> >>
> >>>
> >>> Thanks a lot John. Not sure how come we missed that for such a long time
> >>> :-) Let's Cc stable and get it plugged ASAP :-)
> >>>
>  Also, I noticed that the trace message that shows control transfers
>  doesn't show the SET_INTERFACE properly. Any idea why this is?
> 
>  For example, here is the line in the trace that corresponds to the
>  SET_INTERFACE:
>  irq/33-dwc3-10808 [003] d...  2443.494368: dwc3_ctrl_req:
> >>> bRequestType
>  01 bRequest 0b wValue 0001 wIndex  wLength 0
> >>
> >> Can you please elaborate? What is expected here? Did you mean it shows 
> >> wrong info
> >> (other than the request actually sent by Host) ?
> > 
> > I have been looking more at this and the reason why we're failing is a
> > patch from Paul, which I quote below:
> > 
> > commit b23c843992b659d537514e6493d673284f5d6724
> > Author: Paul Zimmerman 
> > Date:   Fri Sep 30 10:58:42 2011 +0300
> > 
> > usb: dwc3: gadget: fix DEPSTARTCFG for non-EP0 EPs
> > 
> > DEPSTARTCFG for non-EP0 EPs must only be sent once per config
> > 
> > [ ba...@ti.com : changed config_start to start_config_issued ]
> > 
> > Signed-off-by: Paul Zimmerman 
> > Signed-off-by: Felipe Balbi 
> > Signed-off-by

Re: [PATCH v4 5/5] usb: gadget: mass_storage: Warn if LUNs ids are not contiguous

[Sergei Shtylyov]

Hello.

On 07/20/2015 09:15 PM, Krzysztof Opasiak wrote:


According to mass storage specification:



"Logical Unit Numbers on the device shall be numbered contiguously
  starting from LUN 0 to a maximum LUN of 15 (Fh)"



So let's at least print a warning message that LUNs ids should be
contiguous.



Signed-off-by: Krzysztof Opasiak 
Acked-by: Michal Nazarewicz 
---
  drivers/usb/gadget/function/f_mass_storage.c |7 +++
  1 file changed, 7 insertions(+)



diff --git a/drivers/usb/gadget/function/f_mass_storage.c 
b/drivers/usb/gadget/function/f_mass_storage.c
index 5fcd9a0..69167ad 100644
--- a/drivers/usb/gadget/function/f_mass_storage.c
+++ b/drivers/usb/gadget/function/f_mass_storage.c
@@ -3042,6 +3042,13 @@ static int fsg_bind(struct usb_configuration *c, struct 
usb_function *f)
return -EINVAL;
}

+   for (i = 0; i < ARRAY_SIZE(common->luns); ++i)
+   if (!common->luns[i])
+   break;
+
+   if (ret != i - 1)
+   pr_err("LUN ids should be contiguous.\n");


   I suggest just "LUNs" instead of "LUN ids" which sounds somewhat strange 
(logical unit number ids, hm?).


WBR, Sergei

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

Remote wakeup in USB gadget drivers

[Bin Liu]

Hi,

I was trying to understand how remote wakeup works in the gadget framework.

It seems most UDC drivers define .wakeup() call, which is invoked by
usb_gadget_wakeup() wrapper. But none of the gadget drivers (except
g_zero) calls it. Does it mean the gadget framework does not support
remote wakeup or there is something I missed?

By the way, I also found [1] which mentions remote wakeup is not
support in gadget, except g_zero.

Thanks,
-Bin.

[1] http://comments.gmane.org/gmane.linux.usb.general/69113
--
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: Remote wakeup in USB gadget drivers

[Felipe Balbi]

On Mon, Jul 20, 2015 at 02:02:30PM -0500, Bin Liu wrote:
> Hi,
> 
> I was trying to understand how remote wakeup works in the gadget framework.
> 
> It seems most UDC drivers define .wakeup() call, which is invoked by
> usb_gadget_wakeup() wrapper. But none of the gadget drivers (except
> g_zero) calls it. Does it mean the gadget framework does not support
> remote wakeup or there is something I missed?
> 
> By the way, I also found [1] which mentions remote wakeup is not
> support in gadget, except g_zero.

yeah, it needs to be added on a per-gadget basis.

-- 
balbi


signature.asc
Description: Digital signature

Re: Remote wakeup in USB gadget drivers

[Bin Liu]

On Mon, Jul 20, 2015 at 2:10 PM, Felipe Balbi  wrote:
> On Mon, Jul 20, 2015 at 02:02:30PM -0500, Bin Liu wrote:
>> Hi,
>>
>> I was trying to understand how remote wakeup works in the gadget framework.
>>
>> It seems most UDC drivers define .wakeup() call, which is invoked by
>> usb_gadget_wakeup() wrapper. But none of the gadget drivers (except
>> g_zero) calls it. Does it mean the gadget framework does not support
>> remote wakeup or there is something I missed?
>>
>> By the way, I also found [1] which mentions remote wakeup is not
>> support in gadget, except g_zero.
>
> yeah, it needs to be added on a per-gadget basis.

So there is nothing preventing to add the feature, it was not in there
(yet) only because no one really wanted it, right?

Thanks,
-Bin.

>
> --
> balbi
--
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: Remote wakeup in USB gadget drivers

[Felipe Balbi]

On Mon, Jul 20, 2015 at 02:39:58PM -0500, Bin Liu wrote:
> On Mon, Jul 20, 2015 at 2:10 PM, Felipe Balbi  wrote:
> > On Mon, Jul 20, 2015 at 02:02:30PM -0500, Bin Liu wrote:
> >> Hi,
> >>
> >> I was trying to understand how remote wakeup works in the gadget framework.
> >>
> >> It seems most UDC drivers define .wakeup() call, which is invoked by
> >> usb_gadget_wakeup() wrapper. But none of the gadget drivers (except
> >> g_zero) calls it. Does it mean the gadget framework does not support
> >> remote wakeup or there is something I missed?
> >>
> >> By the way, I also found [1] which mentions remote wakeup is not
> >> support in gadget, except g_zero.
> >
> > yeah, it needs to be added on a per-gadget basis.
> 
> So there is nothing preventing to add the feature, it was not in there
> (yet) only because no one really wanted it, right?

s/wanted/implemented :-)

I'm sure many would want it, just nobody has sat down to write it.

-- 
balbi


signature.asc
Description: Digital signature

Re: Remote wakeup in USB gadget drivers

[Bin Liu]

On Mon, Jul 20, 2015 at 2:53 PM, Felipe Balbi  wrote:
> On Mon, Jul 20, 2015 at 02:39:58PM -0500, Bin Liu wrote:
>> On Mon, Jul 20, 2015 at 2:10 PM, Felipe Balbi  wrote:
>> > On Mon, Jul 20, 2015 at 02:02:30PM -0500, Bin Liu wrote:
>> >> Hi,
>> >>
>> >> I was trying to understand how remote wakeup works in the gadget 
>> >> framework.
>> >>
>> >> It seems most UDC drivers define .wakeup() call, which is invoked by
>> >> usb_gadget_wakeup() wrapper. But none of the gadget drivers (except
>> >> g_zero) calls it. Does it mean the gadget framework does not support
>> >> remote wakeup or there is something I missed?
>> >>
>> >> By the way, I also found [1] which mentions remote wakeup is not
>> >> support in gadget, except g_zero.
>> >
>> > yeah, it needs to be added on a per-gadget basis.
>>
>> So there is nothing preventing to add the feature, it was not in there
>> (yet) only because no one really wanted it, right?
>
> s/wanted/implemented :-)
>
> I'm sure many would want it, just nobody has sat down to write it.

Ok, understood the situation now. Thanks.

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

[PATCH 1/2] usb: dwc3: gadget: add a trace when disabling EPs

[Felipe Balbi]

We have a "Enabling %s" trace when enabling an endpoint
but that message felt lonely without a matching
"Disabling %s". Add it.

Signed-off-by: Felipe Balbi 
---
 drivers/usb/dwc3/gadget.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 333a7c0078fc..7f6498dc30f2 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -586,6 +586,8 @@ static int __dwc3_gadget_ep_disable(struct dwc3_ep *dep)
struct dwc3 *dwc = dep->dwc;
u32 reg;
 
+   dwc3_trace(trace_dwc3_gadget, "Enabling %s", dep->name);
+
dwc3_remove_requests(dwc, dep);
 
/* make sure HW endpoint isn't stalled */
-- 
2.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

[PATCH 2/2] usb: dwc3: gadget: defer endpoint name change

[Felipe Balbi]

We should only change endpoint names when we
actually manage to enable/disable it.

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

diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 7f6498dc30f2..7299cbec43c5 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -547,6 +547,23 @@ static int __dwc3_gadget_ep_enable(struct dwc3_ep *dep,
trb_link->ctrl |= DWC3_TRB_CTRL_HWO;
}
 
+   switch (usb_endpoint_type(desc)) {
+   case USB_ENDPOINT_XFER_CONTROL:
+   strlcat(dep->name, "-control", sizeof(dep->name));
+   break;
+   case USB_ENDPOINT_XFER_ISOC:
+   strlcat(dep->name, "-isoc", sizeof(dep->name));
+   break;
+   case USB_ENDPOINT_XFER_BULK:
+   strlcat(dep->name, "-bulk", sizeof(dep->name));
+   break;
+   case USB_ENDPOINT_XFER_INT:
+   strlcat(dep->name, "-int", sizeof(dep->name));
+   break;
+   default:
+   dev_err(dwc->dev, "invalid endpoint transfer type\n");
+   }
+
return 0;
 }
 
@@ -604,6 +621,10 @@ static int __dwc3_gadget_ep_disable(struct dwc3_ep *dep)
dep->type = 0;
dep->flags = 0;
 
+   snprintf(dep->name, sizeof(dep->name), "ep%d%s",
+   dep->number >> 1,
+   (dep->number & 1) ? "in" : "out");
+
return 0;
 }
 
@@ -649,23 +670,6 @@ static int dwc3_gadget_ep_enable(struct usb_ep *ep,
return 0;
}
 
-   switch (usb_endpoint_type(desc)) {
-   case USB_ENDPOINT_XFER_CONTROL:
-   strlcat(dep->name, "-control", sizeof(dep->name));
-   break;
-   case USB_ENDPOINT_XFER_ISOC:
-   strlcat(dep->name, "-isoc", sizeof(dep->name));
-   break;
-   case USB_ENDPOINT_XFER_BULK:
-   strlcat(dep->name, "-bulk", sizeof(dep->name));
-   break;
-   case USB_ENDPOINT_XFER_INT:
-   strlcat(dep->name, "-int", sizeof(dep->name));
-   break;
-   default:
-   dev_err(dwc->dev, "invalid endpoint transfer type\n");
-   }
-
spin_lock_irqsave(&dwc->lock, flags);
ret = __dwc3_gadget_ep_enable(dep, desc, ep->comp_desc, false, false);
spin_unlock_irqrestore(&dwc->lock, flags);
@@ -694,10 +698,6 @@ static int dwc3_gadget_ep_disable(struct usb_ep *ep)
return 0;
}
 
-   snprintf(dep->name, sizeof(dep->name), "ep%d%s",
-   dep->number >> 1,
-   (dep->number & 1) ? "in" : "out");
-
spin_lock_irqsave(&dwc->lock, flags);
ret = __dwc3_gadget_ep_disable(dep);
spin_unlock_irqrestore(&dwc->lock, flags);
-- 
2.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: xhci_hcd 0000:00:14.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 1

[Arkadiusz Miskiewicz]

On Saturday 18 of July 2015, Arkadiusz Miskiewicz wrote:
> Hi.
> 
> I'm on 4.2.0-rc2-00077-gf760b87 kernel and while trying to copy some file
> from usb storage (sata disk behind sata-usb bridge or pendrive; hapens in
> both cases) copying process hangs just early after start with:

Looks like suspend & resume is enough. Reloading bluetooth firmware done by 
kernel
triggers problem:

[  106.302783] rtc_cmos 00:02: System wakeup disabled by ACPI
[  106.313280] PM: resume of devices complete after 3003.032 msecs
[  106.314079] Restarting tasks ... done.
[  106.326434] Bluetooth: hci0: read Intel version: 370710018002030d00
[  106.330422] Bluetooth: hci0: Intel Bluetooth firmware file: 
intel/ibt-hw-37.7.10-fw-1.80.2.3.d.bseq
[  106.398223] xhci_hcd :00:14.0: ERROR Transfer event TRB DMA ptr not part 
of current TD ep_index 0 comp_code 1
[  106.398230] xhci_hcd :00:14.0: Looking for event-dma fffd3000 
trb-start fffd4fd0 trb-end fffd5000 seg-start fffd4000 
seg-end fffd4ff0
[  106.400396] xhci_hcd :00:14.0: ERROR Transfer event TRB DMA ptr not part 
of current TD ep_index 0 comp_code 1
[  106.400402] xhci_hcd :00:14.0: Looking for event-dma fffd3030 
trb-start fffd4fd0 trb-end fffd5000 seg-start fffd4000 
seg-end fffd4ff0
[  106.402225] xhci_hcd :00:14.0: ERROR Transfer event TRB DMA ptr not part 
of current TD ep_index 0 comp_code 1
[  106.402228] xhci_hcd :00:14.0: Looking for event-dma fffd3060 
trb-start fffd4fd0 trb-end fffd5000 seg-start fffd4000 
seg-end fffd4ff0
[  106.404401] xhci_hcd :00:14.0: ERROR Transfer event TRB DMA ptr not part 
of current TD ep_index 0 comp_code 1
[  106.404408] xhci_hcd :00:14.0: Looking for event-dma fffd3090 
trb-start fffd4fd0 trb-end fffd5000 seg-start fffd4000 
seg-end fffd4ff0
[  106.406229] xhci_hcd :00:14.0: ERROR Transfer event TRB DMA ptr not part 
of current TD ep_index 0 comp_code 1
[  106.406232] xhci_hcd :00:14.0: Looking for event-dma fffd30c0 
trb-start fffd4fd0 trb-end fffd5000 seg-start fffd4000 
seg-end fffd4ff0
[  106.408389] xhci_hcd :00:14.0: ERROR Transfer event TRB DMA ptr not part 
of current TD ep_index 0 comp_code 1
[  106.408395] xhci_hcd :00:14.0: Looking for event-dma fffd30f0 
trb-start fffd4fd0 trb-end fffd5000 seg-start fffd4000 
seg-end fffd4ff0
[  106.410291] xhci_hcd :00:14.0: ERROR Transfer event TRB DMA ptr not part 
of current TD ep_index 0 comp_code 1
[  106.410294] xhci_hcd :00:14.0: Looking for event-dma fffd3120 
trb-start fffd4fd0 trb-end fffd5000 seg-start fffd4000 
seg-end fffd4ff0
[  106.412427] xhci_hcd :00:14.0: ERROR Transfer event TRB DMA ptr not part 
of current TD ep_index 0 comp_code 1
[  106.412433] xhci_hcd :00:14.0: Looking for event-dma fffd3150 
trb-start fffd4fd0 trb-end fffd5000 seg-start fffd4000 
seg-end fffd4ff0
[  106.414315] xhci_hcd :00:14.0: ERROR Transfer event TRB DMA ptr not part 
of current TD ep_index 0 comp_code 1
[  106.414318] xhci_hcd :00:14.0: Looking for event-dma fffd3180 
trb-start fffd4fd0 trb-end fffd5000 seg-start fffd4000 
seg-end fffd4ff0

[...]



http://sprunge.us/IDUh


-- 
Arkadiusz Miśkiewicz, arekm / ( maven.pl | pld-linux.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 1/2] usb: dwc3: gadget: add a trace when disabling EPs

[Fabio Estevam]

On Mon, Jul 20, 2015 at 5:09 PM, Felipe Balbi  wrote:
> We have a "Enabling %s" trace when enabling an endpoint
> but that message felt lonely without a matching
> "Disabling %s". Add it.
>
> Signed-off-by: Felipe Balbi 
> ---
>  drivers/usb/dwc3/gadget.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
> index 333a7c0078fc..7f6498dc30f2 100644
> --- a/drivers/usb/dwc3/gadget.c
> +++ b/drivers/usb/dwc3/gadget.c
> @@ -586,6 +586,8 @@ static int __dwc3_gadget_ep_disable(struct dwc3_ep *dep)
> struct dwc3 *dwc = dep->dwc;
> u32 reg;
>
> +   dwc3_trace(trace_dwc3_gadget, "Enabling %s", dep->name);
> +

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

Re: [PATCH 1/2] usb: dwc3: gadget: add a trace when disabling EPs

[Felipe Balbi]

On Mon, Jul 20, 2015 at 05:36:34PM -0300, Fabio Estevam wrote:
> On Mon, Jul 20, 2015 at 5:09 PM, Felipe Balbi  wrote:
> > We have a "Enabling %s" trace when enabling an endpoint
> > but that message felt lonely without a matching
> > "Disabling %s". Add it.
> >
> > Signed-off-by: Felipe Balbi 
> > ---
> >  drivers/usb/dwc3/gadget.c | 2 ++
> >  1 file changed, 2 insertions(+)
> >
> > diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
> > index 333a7c0078fc..7f6498dc30f2 100644
> > --- a/drivers/usb/dwc3/gadget.c
> > +++ b/drivers/usb/dwc3/gadget.c
> > @@ -586,6 +586,8 @@ static int __dwc3_gadget_ep_disable(struct dwc3_ep *dep)
> > struct dwc3 *dwc = dep->dwc;
> > u32 reg;
> >
> > +   dwc3_trace(trace_dwc3_gadget, "Enabling %s", dep->name);
> > +
> 
> I think you meant "Disabling" :-)

yeah, I did :-) Thanks

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH 1/2] usb: dwc3: gadget: add a trace when disabling EPs

[Felipe Balbi]

On Mon, Jul 20, 2015 at 03:38:17PM -0500, Felipe Balbi wrote:
> On Mon, Jul 20, 2015 at 05:36:34PM -0300, Fabio Estevam wrote:
> > On Mon, Jul 20, 2015 at 5:09 PM, Felipe Balbi  wrote:
> > > We have a "Enabling %s" trace when enabling an endpoint
> > > but that message felt lonely without a matching
> > > "Disabling %s". Add it.
> > >
> > > Signed-off-by: Felipe Balbi 
> > > ---
> > >  drivers/usb/dwc3/gadget.c | 2 ++
> > >  1 file changed, 2 insertions(+)
> > >
> > > diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
> > > index 333a7c0078fc..7f6498dc30f2 100644
> > > --- a/drivers/usb/dwc3/gadget.c
> > > +++ b/drivers/usb/dwc3/gadget.c
> > > @@ -586,6 +586,8 @@ static int __dwc3_gadget_ep_disable(struct dwc3_ep 
> > > *dep)
> > > struct dwc3 *dwc = dep->dwc;
> > > u32 reg;
> > >
> > > +   dwc3_trace(trace_dwc3_gadget, "Enabling %s", dep->name);
> > > +
> > 
> > I think you meant "Disabling" :-)
> 
> yeah, I did :-) Thanks

here's updated version:

8<--

From 2a87b731fedbb018b7330b79fb4d8bff5349d4b4 Mon Sep 17 00:00:00 2001
From: Felipe Balbi 
Date: Mon, 20 Jul 2015 14:46:15 -0500
Subject: [PATCH 1/2] usb: dwc3: gadget: add a trace when disabling EPs

We have a "Enabling %s" trace when enabling an endpoint
but that message felt lonely without a matching
"Disabling %s". Add it.

Signed-off-by: Felipe Balbi 
---
 drivers/usb/dwc3/gadget.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 333a7c0078fc..1f8f730c7cc5 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -586,6 +586,8 @@ static int __dwc3_gadget_ep_disable(struct dwc3_ep *dep)
struct dwc3 *dwc = dep->dwc;
u32 reg;
 
+   dwc3_trace(trace_dwc3_gadget, "Disabling %s", dep->name);
+
dwc3_remove_requests(dwc, dep);
 
/* make sure HW endpoint isn't stalled */
-- 
2.4.4


-- 
balbi


signature.asc
Description: Digital signature

[RFC ebeam PATCH 1/2] hid: Blacklist eBeam devices

[Yann Cantin]

Signed-off-by: Yann Cantin 
---
 drivers/hid/hid-core.c | 6 ++
 drivers/hid/hid-ids.h  | 6 ++
 2 files changed, 12 insertions(+)

diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index 157c627..db4c7ee 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -2267,6 +2267,12 @@ static const struct hid_device_id hid_ignore_list[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_DELORME, USB_DEVICE_ID_DELORME_EM_LT20) 
},
{ HID_USB_DEVICE(USB_VENDOR_ID_DREAM_CHEEKY, 0x0004) },
{ HID_USB_DEVICE(USB_VENDOR_ID_DREAM_CHEEKY, 0x000a) },
+#if defined(CONFIG_INPUT_EBEAM_USB)
+   { HID_USB_DEVICE(USB_VENDOR_ID_EFI, USB_DEVICE_ID_EFI_EBEAM_USB1) },
+   { HID_USB_DEVICE(USB_VENDOR_ID_EFI, USB_DEVICE_ID_EFI_EBEAM_USB2) },
+   { HID_USB_DEVICE(USB_VENDOR_ID_EFI, USB_DEVICE_ID_EFI_EBEAM_BT_USB1) },
+   { HID_USB_DEVICE(USB_VENDOR_ID_EFI, USB_DEVICE_ID_EFI_EBEAM_BT_USB2) },
+#endif
{ HID_USB_DEVICE(USB_VENDOR_ID_ESSENTIAL_REALITY, 
USB_DEVICE_ID_ESSENTIAL_REALITY_P5) },
{ HID_USB_DEVICE(USB_VENDOR_ID_ETT, USB_DEVICE_ID_TC5UH) },
{ HID_USB_DEVICE(USB_VENDOR_ID_ETT, USB_DEVICE_ID_TC4UM) },
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index b04b082..ca013c2 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -303,6 +303,12 @@
 #define USB_DEVICE_ID_DWAV_EGALAX_MULTITOUCH_73F7  0x73f7
 #define USB_DEVICE_ID_DWAV_EGALAX_MULTITOUCH_A001  0xa001
 
+#define USB_VENDOR_ID_EFI  0x2650
+#define USB_DEVICE_ID_EFI_EBEAM_USB1   0x1311
+#define USB_DEVICE_ID_EFI_EBEAM_USB2   0x1315
+#define USB_DEVICE_ID_EFI_EBEAM_BT_USB10x1313
+#define USB_DEVICE_ID_EFI_EBEAM_BT_USB20x1320
+
 #define USB_VENDOR_ID_ELAN 0x04f3
 #define USB_DEVICE_ID_ELAN_TOUCHSCREEN 0x0089
 #define USB_DEVICE_ID_ELAN_TOUCHSCREEN_009B0x009b
-- 
2.3.8

--
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 ebeam PATCH 2/2] input: misc: New USB eBeam input driver

[Yann Cantin]

Signed-off-by: Yann Cantin 
---
 Documentation/ABI/testing/sysfs-driver-ebeam |  53 ++
 drivers/input/misc/Kconfig   |  22 +
 drivers/input/misc/Makefile  |   1 +
 drivers/input/misc/ebeam.c   | 777 +++
 4 files changed, 853 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-driver-ebeam
 create mode 100644 drivers/input/misc/ebeam.c

diff --git a/Documentation/ABI/testing/sysfs-driver-ebeam 
b/Documentation/ABI/testing/sysfs-driver-ebeam
new file mode 100644
index 000..6873db5
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-driver-ebeam
@@ -0,0 +1,53 @@
+What:  /sys/class/input/inputXX/device/min_x
+   /sys/class/input/inputXX/device/min_y
+   /sys/class/input/inputXX/device/max_x
+   /sys/class/input/inputXX/device/max_y
+Date:  Jul 2015
+Kernel Version:4.1
+Contact:   yann.can...@laposte.net
+   linux-usb@vger.kernel.org
+Description:
+   Reading from these files return the actually used range values 
of
+   the reported coordinates.
+   Writing to these files preset these range values.
+   See below for the calibration procedure.
+
+What:  /sys/class/input/inputXX/device/h[1..9]
+Date:  Jul 2015
+Kernel Version:4.1
+Contact:   yann.can...@laposte.net
+   linux-usb@vger.kernel.org
+Description:
+   Reading from these files return the 3x3 transformation matrix 
elements
+   actually used, in row-major.
+   Writing to these files preset these elements values.
+   See below for the calibration procedure.
+
+What:  /sys/class/input/inputXX/device/calibrated
+Date:  Jul 2015
+Kernel Version:4.1
+Contact:   yann.can...@laposte.net
+   linux-usb@vger.kernel.org
+Description:
+   Reading from this file :
+   - Return 0 if the driver is in "un-calibrated" mode : it 
actually send
+ raw coordinates in the device's internal coordinates system.
+   - Return 1 if the driver is in "calibrated" mode : it send 
computed coordinates
+ that (hopefully) matches the screen's coordinates system.
+   Writing 1 to this file enable the "calibrated" mode, 0 reset 
the driver in
+   "un-calibrated" mode.
+
+Calibration procedure :
+
+When loaded, the driver is in "un-calibrated" mode : it send device's raw 
coordinates
+in the [0..65535]x[0..65535] range, the transformation matrix is the identity.
+
+A calibration program have to compute a homography transformation matrix that 
convert
+the device's raw coordinates to the matching screen's ones.
+It then write to the appropriate sysfs files the computed values, pre-setting 
the
+driver's parameters : xy range, and the matrix's elements.
+When all values are passed, it write 1 to the calibrated sysfs file to enable 
the "calibrated" mode.
+
+Warning : The parameters aren't used until 1 is writen to the calibrated sysfs 
file.
+
+Writing 0 to the calibrated sysfs file reset the driver in "un-calibrated" 
mode.
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index d4f0a81..22c46a4 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -103,6 +103,28 @@ config INPUT_E3X0_BUTTON
  To compile this driver as a module, choose M here: the
  module will be called e3x0_button.
 
+config INPUT_EBEAM_USB
+   tristate "USB eBeam driver"
+   depends on USB_ARCH_HAS_HCD
+   select USB
+   help
+ Say Y here if you have a USB eBeam pointing device and want to
+ use it without any proprietary user space tools.
+
+ Have a look at  for
+ a usage description and the required user-space tools.
+
+ Supported devices :
+   - Luidia eBeam Classic Projection and eBeam Edge Projection
+   - Nec NP01Wi1 & NP01Wi2 interactive solution
+
+ Supposed working devices, need test, may lack functionality :
+   - Luidia eBeam Edge Whiteboard and eBeam Engage
+   - Hitachi Starboard FX-63, FX-77, FX-82, FX-77GII
+
+ To compile this driver as a module, choose M here: the
+ module will be called ebeam.
+
 config INPUT_PCSPKR
tristate "PC Speaker support"
depends on PCSPKR_PLATFORM
diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
index 53df07d..125f8a9 100644
--- a/drivers/input/misc/Makefile
+++ b/drivers/input/misc/Makefile
@@ -28,6 +28,7 @@ obj-$(CONFIG_INPUT_DA9055_ONKEY)  += da9055_onkey.o
 obj-$(CONFIG_INPUT_DA9063_ONKEY)   += da9063_onkey.o
 obj-$(CONFIG_INPUT_DM355EVM)   += dm355evm_keys.o
 obj-$(CONFIG_INPUT_E3X0_BUTTON)+= e3x0-button.o
+obj-$(CONFIG_INPUT_EBEAM_USB)  += ebeam.o
 obj-$(CONFIG_INPUT_DRV260X_HA

[RFC ebeam PATCH 0/3] new USB eBeam input driver

[Yann Cantin]

Hi,

New USB input driver for eBeam devices.

Currently supported (tested) :
- Luidia eBeam classic projection and edge projection models
- Nec "interactive solution" NP01Wi1 & NP01Wi2 accessories.

Patch 1 to blacklist the devices for hid generic-usb.

Patch 2 is the actual driver.

Notable stuff :
- use div64_s64 for portable 64/64-bits divisions.
- 13 sysfs custom files : 9 values for the transformation matrix,
  4 for xy ranges and a calibration trigger.
- need userspace gui tool for calibration (ebeam.tuxfamily.org)

Side notes :
- The module run fine since 3.3.6, both x86_32 and 64.
- Already reviewed in 2012 and 2013, but i have'nt pushed for inclusion.
- The only recent change is switching to non world-writable sysfs files.
- There is a proprietary application suite based on libusb, hope it won't
  break with this driver.

Thanks for your help.

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

Re: [RFC ebeam PATCH 2/2] input: misc: New USB eBeam input driver

[Greg KH]

On Mon, Jul 20, 2015 at 11:03:19PM +0200, Yann Cantin wrote:
> Signed-off-by: Yann Cantin 

You need some kind of text in the changelog here...

> ---
>  Documentation/ABI/testing/sysfs-driver-ebeam |  53 ++
>  drivers/input/misc/Kconfig   |  22 +
>  drivers/input/misc/Makefile  |   1 +
>  drivers/input/misc/ebeam.c   | 777 
> +++
>  4 files changed, 853 insertions(+)
>  create mode 100644 Documentation/ABI/testing/sysfs-driver-ebeam
>  create mode 100644 drivers/input/misc/ebeam.c
> 
> diff --git a/Documentation/ABI/testing/sysfs-driver-ebeam 
> b/Documentation/ABI/testing/sysfs-driver-ebeam
> new file mode 100644
> index 000..6873db5
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-driver-ebeam
> @@ -0,0 +1,53 @@
> +What:/sys/class/input/inputXX/device/min_x
> + /sys/class/input/inputXX/device/min_y
> + /sys/class/input/inputXX/device/max_x
> + /sys/class/input/inputXX/device/max_y
> +Date:Jul 2015
> +Kernel Version:  4.1
> +Contact: yann.can...@laposte.net
> + linux-usb@vger.kernel.org
> +Description:
> + Reading from these files return the actually used range values 
> of
> + the reported coordinates.
> + Writing to these files preset these range values.
> + See below for the calibration procedure.
> +
> +What:/sys/class/input/inputXX/device/h[1..9]
> +Date:Jul 2015
> +Kernel Version:  4.1
> +Contact: yann.can...@laposte.net
> + linux-usb@vger.kernel.org
> +Description:
> + Reading from these files return the 3x3 transformation matrix 
> elements
> + actually used, in row-major.
> + Writing to these files preset these elements values.
> + See below for the calibration procedure.
> +
> +What:/sys/class/input/inputXX/device/calibrated
> +Date:Jul 2015
> +Kernel Version:  4.1
> +Contact: yann.can...@laposte.net
> + linux-usb@vger.kernel.org
> +Description:
> + Reading from this file :
> + - Return 0 if the driver is in "un-calibrated" mode : it 
> actually send
> +   raw coordinates in the device's internal coordinates system.
> + - Return 1 if the driver is in "calibrated" mode : it send 
> computed coordinates
> +   that (hopefully) matches the screen's coordinates system.
> + Writing 1 to this file enable the "calibrated" mode, 0 reset 
> the driver in
> + "un-calibrated" mode.
> +
> +Calibration procedure :
> +
> +When loaded, the driver is in "un-calibrated" mode : it send device's raw 
> coordinates
> +in the [0..65535]x[0..65535] range, the transformation matrix is the 
> identity.
> +
> +A calibration program have to compute a homography transformation matrix 
> that convert
> +the device's raw coordinates to the matching screen's ones.
> +It then write to the appropriate sysfs files the computed values, 
> pre-setting the
> +driver's parameters : xy range, and the matrix's elements.
> +When all values are passed, it write 1 to the calibrated sysfs file to 
> enable the "calibrated" mode.
> +
> +Warning : The parameters aren't used until 1 is writen to the calibrated 
> sysfs file.
> +
> +Writing 0 to the calibrated sysfs file reset the driver in "un-calibrated" 
> mode.


What tool(s) use these sysfs files?  Don't we already have "normal"
events for these types of things such that we don't have to make up new
sysfs files for these?

> diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
> index d4f0a81..22c46a4 100644
> --- a/drivers/input/misc/Kconfig
> +++ b/drivers/input/misc/Kconfig
> @@ -103,6 +103,28 @@ config INPUT_E3X0_BUTTON
> To compile this driver as a module, choose M here: the
> module will be called e3x0_button.
>  
> +config INPUT_EBEAM_USB
> + tristate "USB eBeam driver"
> + depends on USB_ARCH_HAS_HCD
> + select USB
> + help
> +   Say Y here if you have a USB eBeam pointing device and want to
> +   use it without any proprietary user space tools.
> +
> +   Have a look at  for
> +   a usage description and the required user-space tools.
> +
> +   Supported devices :
> + - Luidia eBeam Classic Projection and eBeam Edge Projection
> + - Nec NP01Wi1 & NP01Wi2 interactive solution
> +
> +   Supposed working devices, need test, may lack functionality :
> + - Luidia eBeam Edge Whiteboard and eBeam Engage
> + - Hitachi Starboard FX-63, FX-77, FX-82, FX-77GII
> +
> +   To compile this driver as a module, choose M here: the
> +   module will be called ebeam.
> +
>  config INPUT_PCSPKR
>   tristate "PC Speaker support"
>   depends on PCSPKR_PLATFORM
> diff --git a/drivers/input/misc/Makefile b/driv

Re: [RFC ebeam PATCH 2/2] input: misc: New USB eBeam input driver

[Dmitry Torokhov]

On Mon, Jul 20, 2015 at 02:59:56PM -0700, Greg KH wrote:
> On Mon, Jul 20, 2015 at 11:03:19PM +0200, Yann Cantin wrote:
> > Signed-off-by: Yann Cantin 
> 
> > +
> > +   /* sysfs setup */
> > +   err = sysfs_create_group(&intf->dev.kobj, &ebeam_attr_group);
> 
> Ick, you just added the sysfs files to the USB device, not your input
> device, are you sure you tested this?
> 
> And there should be a race-free way to add an attribute group to an
> input device, as this is, you are adding them to the device _after_ it
> is created, so userspace will not see them at creation time, causing a
> race.

No, there are no driver-specific attributed on input devices themselves,
they belong to the actual hardware devices. The input devices only
export standard attributes applicable to every and all input devices
in the system.

Thanks.

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

Re: [PATCH 1/4] usb: gadget: udc: bdc: Fix a driver crash on disconnect

[Alan Cooper]

I did do a build for ARM dove and x86_64 and didn't see any build
errors. Can you send me the build error?

Thanks
Al

On Mon, Jul 20, 2015 at 1:15 PM, Felipe Balbi  wrote:
> On Thu, Jul 16, 2015 at 05:47:35PM -0400, Al Cooper wrote:
>> ep_dequeue() in bdc_ep.c was capturing the hw dequeue pointer
>> incorrectly by reading the wrong register for the upper 32 bits.
>> The header file defining the registers was incorrect.
>>
>> Signed-off-by: Al Cooper 
>
> so you fix a driver crash by introducing a build error ? Test your
> patches before sending them out.
>
> --
> balbi
--
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 ebeam PATCH 2/2] input: misc: New USB eBeam input driver

[Greg KH]

On Mon, Jul 20, 2015 at 03:26:40PM -0700, Dmitry Torokhov wrote:
> On Mon, Jul 20, 2015 at 02:59:56PM -0700, Greg KH wrote:
> > On Mon, Jul 20, 2015 at 11:03:19PM +0200, Yann Cantin wrote:
> > > Signed-off-by: Yann Cantin 
> > 
> > > +
> > > + /* sysfs setup */
> > > + err = sysfs_create_group(&intf->dev.kobj, &ebeam_attr_group);
> > 
> > Ick, you just added the sysfs files to the USB device, not your input
> > device, are you sure you tested this?
> > 
> > And there should be a race-free way to add an attribute group to an
> > input device, as this is, you are adding them to the device _after_ it
> > is created, so userspace will not see them at creation time, causing a
> > race.
> 
> No, there are no driver-specific attributed on input devices themselves,
> they belong to the actual hardware devices. The input devices only
> export standard attributes applicable to every and all input devices
> in the system.

Then the Documentation in this patch better be fixed up, as it points to
the input device as having these sysfs files :)

But as these are input device attributes, and not USB device interface
attributes, putting them on the USB interface doesn't make much sense,
and as I pointed out, is racy.  Why can't input devices have
driver-specific attributes?  Why does input devices add their own
attributes sometimes (like in psmouse, which does so in a racy way) yet
this driver shouldn't do that?

Hm, nevermind about psmouse, that happens on the parent device too it
seems (a serio device), not the input device, so it is "consistent", but
not something I really like...

thanks,

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

Re: [RFC ebeam PATCH 2/2] input: misc: New USB eBeam input driver

[Dmitry Torokhov]

On Mon, Jul 20, 2015 at 03:40:33PM -0700, Greg KH wrote:
> On Mon, Jul 20, 2015 at 03:26:40PM -0700, Dmitry Torokhov wrote:
> > On Mon, Jul 20, 2015 at 02:59:56PM -0700, Greg KH wrote:
> > > On Mon, Jul 20, 2015 at 11:03:19PM +0200, Yann Cantin wrote:
> > > > Signed-off-by: Yann Cantin 
> > > 
> > > > +
> > > > +   /* sysfs setup */
> > > > +   err = sysfs_create_group(&intf->dev.kobj, &ebeam_attr_group);
> > > 
> > > Ick, you just added the sysfs files to the USB device, not your input
> > > device, are you sure you tested this?
> > > 
> > > And there should be a race-free way to add an attribute group to an
> > > input device, as this is, you are adding them to the device _after_ it
> > > is created, so userspace will not see them at creation time, causing a
> > > race.
> > 
> > No, there are no driver-specific attributed on input devices themselves,
> > they belong to the actual hardware devices. The input devices only
> > export standard attributes applicable to every and all input devices
> > in the system.
> 
> Then the Documentation in this patch better be fixed up, as it points to
> the input device as having these sysfs files :)
> 
> But as these are input device attributes, and not USB device interface
> attributes, putting them on the USB interface doesn't make much sense,
> and as I pointed out, is racy.  Why can't input devices have
> driver-specific attributes?  Why does input devices add their own
> attributes sometimes (like in psmouse, which does so in a racy way) yet
> this driver shouldn't do that?
> 
> Hm, nevermind about psmouse, that happens on the parent device too it
> seems (a serio device), not the input device, so it is "consistent", but
> not something I really like...

I think it is historical as quite often they (attributes) affect the
hardware itself, not behavior of input interface. And so they were
always placed on hardware level, not input device level.

Anyway, I do not think you are going to win your war on sysfs attributes
created post-device creation. We just need to recognize that there are
attributes that are created by the driver when it is bound to the
device. Maybe we need to revisit the idea about emitting special uevent
when driver is fully bound to a device and interested userspace can
start using it.

Thanks.

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

Re: [PATCH 1/4] usb: gadget: udc: bdc: Fix a driver crash on disconnect

[Felipe Balbi]

Hi,

(no top-posting, please)

On Mon, Jul 20, 2015 at 06:35:49PM -0400, Alan Cooper wrote:
> I did do a build for ARM dove and x86_64 and didn't see any build
> errors. Can you send me the build error?

do I really have to send the error ? Just look at the code:

-   temp = bdc_readl(bdc->regs, BDC_EPSTS7(0));
+   temp = bdc_readl(bdc->regs, BDC_EPSTS7));

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH 1/1] usb: chipidea: host: add own hc_driver for each hcd

[Peter Chen]

On Mon, Jul 20, 2015 at 11:37:11AM -0400, Alan Stern wrote:
> On Mon, 20 Jul 2015, Peter Chen wrote:
> 
> > > I don't think a new use case is needed.  All you have to do is add
> > > something like this to host.c:
> > > 
> > > static void ci_hdrc_host_driver_init(void)
> > > {
> > >   ehci_init_driver(&ci_ehci_hc_driver, &ehci_ci_overrides);
> 
> By the way, right here I forgot to include:
> 
>   orig_bus_suspend = ci_ehci_hc_driver.bus_suspend;
>   ci_ehci_hc_driver.bus_suspend = ci_ehci_bus_suspend;
> 
> > > }
> > > module_init(ci_hdrc_host_driver_init);
> > > 
> > > Can you think of any reason this won't work?
> > > 
> > 
> > No, it will not work. The core driver's probe will run which will
> > call host_start to call ehci APIs before ci_hdrc_host_driver_init
> > is called.
> 
> Ah, I see the difficulty.  core.c does 
> pci_register_driver(&ehci_pci_driver).  That will have to be different.
> Let's change that line to this:
> 
> static int __init ci_hdrc_driver_init(void)
> {
>   ci_hdrc_host_driver_init();
>   return platform_register_driver(&ci_hdrc_driver);
> }
> module_init(ci_hdrc_driver_init);
> 
> static void __exit ci_hdrc_driver_cleanup(void)
> {
>   platform_unregister_driver(&ci_hdrc_driver);
> }
> module_exit(ci_hdrc_driver_cleanup);
> 
> Then in host.c, make ci_hdrc_host_driver_init non-static.
> 
> This should work, because the core's probe routine can't be called 
> before it is registered as a platform driver, and that doesn't happen 
> until after ehci_init_driver is called.
> 

Yes, this should work, thanks.

-- 

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

[PATCH V5 1/1] usb:serial add Fintek F81532/534 driver

[Peter Hung]

This driver is for Fintek F81532/F81534 USB to Serial Ports IC.

Features:
1. F81534 is 1-to-4 & F81532 is 1-to-2 serial ports IC
2. Support Baudrate from B50 to B150 (excluding B100).
3. The RTS signal can be transformed their behavior with
   configuration by default ioctl TIOCGRS485/TIOCSRS485
   (for RS232/RS485/RS422 with transceiver)

   If the driver setting with SER_RS485_ENABLED, the RTS signal will
   high with not in TX and low with in TX.

   If the driver setting with SER_RS485_ENABLED | SER_RS485_RTS_ON_SEND,
   the RTS signal will low with not in TX and high with in TX.

4. There are 4x3 output-only ic pins to control transceiver mode.
   It's can be controlled via gpiolib. We could found the gpio
   number from /sys/class/tty/ttyUSB[x]/device/gpiochap[yyy] where
   x is F81532/534 serial port and yyy is gpiochip number.

   After we found chip number, we can export 3 gpios(M2/M1/M0) per
   serial port by
  echo yyy > /sys/class/gpio/export
  echo yyy+1 > /sys/class/gpio/export
  echo yyy+2 > /sys/class/gpio/export

   then we can control it with
  echo [M0 value] > /sys/class/gpio/gpio[yyy]/value
  echo [M1 value] > /sys/class/gpio/gpio[yyy+1]/value
  echo [M2 value] > /sys/class/gpio/gpio[yyy+2]/value
   which M0/M1/M2 as your desired value, value is only 0 or 1.

   When configure complete, It's a must to free all gpio by
  echo yyy > /sys/class/gpio/unexport
  echo yyy+1 > /sys/class/gpio/unexport
  echo yyy+2 > /sys/class/gpio/unexport

   The driver will "save" gpio configure after we release
   all gpio of a serial port.

   For examples to change mode & gpio with F81532/534
   Evalaution Board.

   F81532 EVB
  port0: F81437 (RS232 only)
  port1: F81439 (RS232/RS485/RS422 ... etc.)
   F81534 EVB
  port0/1: F81437 (RS232 only)
  port2/3: F81439 (RS232/RS485/RS422 ... etc.)

  1. RS232 Mode (Default IC Mode)
 1. Set struct serial_rs485 flags "without" SER_RS485_ENABLED
(control F81532/534 RTS control)
 2. Set M2/M1/M0 as 0/0/1
(control F81532/534 output pin to control transceiver mode)

  2. RS485 Mode (RTS Low when TX Mode)
 1. Set struct serial_rs485 flags with SER_RS485_ENABLED
 2. Set M2/M1/M0 as 0/1/0

  3. RS485 Mode (RTS High when TX Mode)
 1. Set struct serial_rs485 flags with SER_RS485_ENABLED and
SER_RS485_RTS_ON_SEND
 2. Set M2/M1/M0 as 0/1/1

  4. RS422 Mode
 1. The RTS mode is dont care.
 2. Set M2/M1/M0 as 0/0/0

   Please reference https://bitbucket.org/hpeter/fintek-general/src/
   with f81534/tools to get set_gpio.c & set_mode.c. Please use it
   carefully.

Changelog
v5
1. Change the configure data address F81534_CUSTOM_ADDRESS_START
   from 0x4000 to 0x2f00 (for MP F/W ver:AA66)
2. Change f81534_port_disable/enable() from H/W mode to S/W mode
   It'll skip all rx data when port is not opened.
3. Some function modifier add with static (Thanks for Paul Bolle)
4. It's will direct return when count=0 in f81534_write() to
   reduce spin_lock usage.

v4
1. clearify f81534_process_read_urb() with
   f81534_process_per_serial_block(). (referenced from mxuport.c)
2. We limited f81534_write() max tx kfifo with 124Bytes.
   Original subsystem is designed for auto tranmiting fifo data
   if available. But we must wait for tx_empty for next tx data
   (H/W design).

   With this kfifo size limit, we can use generic subsystem api with
   f81534_write(). When usb_serial_generic_write_start() called after
   first write URB complete, the fifo will no data. The generic
   subsystem of write will go to idle state. Until we received
   TX_EMPTY and release write spinlock, the fifo will fill max
   124Bytes by following f81534_write().

v3
1. Migrate read, write and some routine from custom code to usbserial
   subsystem callback function.
2. Use more defines to replece magic numbers to make it meaningful
3. Make more comments as document in source code.

v2
1. v1 version submit to staging tree, but Greg KH advised me to
   cleanup source code & re-submit it to correct subsystem
2. Remove all custom ioctl commands

Signed-off-by: Peter Hung 
---
 drivers/usb/serial/Kconfig  |   10 +
 drivers/usb/serial/Makefile |1 +
 drivers/usb/serial/f81534.c | 3279 +++
 3 files changed, 3290 insertions(+)
 create mode 100644 drivers/usb/serial/f81534.c

diff --git a/drivers/usb/serial/Kconfig b/drivers/usb/serial/Kconfig
index 56ecb8b..0642864 100644
--- a/drivers/usb/serial/Kconfig
+++ b/drivers/usb/serial/Kconfig
@@ -255,6 +255,16 @@ config USB_SERIAL_F81232
  To compile this driver as a module, choose M here: the
  module will be called f81232.
 
+config USB_SERIAL_F8153X
+   tristate "USB Fintek F81532/534 Multi-Ports Serial Driver"
+   help
+ Say

[PATCH 1/1] usb: chipidea: ehci_init_driver is intended to call one time

[Peter Chen]

The ehci_init_driver is used to initialize hcd APIs for each
ehci controller driver, it is designed to be called only one time
and before driver register is called. The current design will
cause ehci_init_driver is called multiple times at probe process,
it will cause hc_driver's initialization affect current running hcd.

We run out NULL pointer dereference problem when one hcd is started
by module_init, and the other is started by otg thread at SMP platform.
The reason for this problem is ehci_init_driver will do memory copy
for current uniform hc_driver, and this memory copy will do memset (as 0)
first, so when the first hcd is running usb_add_hcd, and the second
hcd may clear the uniform hc_driver's space (at ehci_init_driver),
then the first hcd will meet NULL pointer at the same time.

See below two logs:

LOG_1:
ci_hdrc ci_hdrc.0: EHCI Host Controller
ci_hdrc ci_hdrc.0: new USB bus registered, assigned bus number 1
ci_hdrc ci_hdrc.1: doesn't support gadget
Unable to handle kernel NULL pointer dereference at virtual address 0014
pgd = 80004000
[0014] *pgd=
Internal error: Oops: 805 [#1] PREEMPT SMP ARM
Modules linked in:
CPU: 0 PID: 108 Comm: kworker/u8:2 Not tainted 3.14.38-222193-g24b2734-dirty #25
Workqueue: ci_otg ci_otg_work
task: d839ec00 ti: d840 task.ti: d840
PC is at ehci_run+0x4c/0x284
LR is at _raw_spin_unlock_irqrestore+0x28/0x54
pc : [<8041f9a0>]lr : [<8070ea84>]psr: 6113
sp : d8401e30  ip :   fp : d8004400
r10: 0001  r9 : 0001  r8 : 
r7 :   r6 : d8419940  r5 : 80dd24c0  r4 : d8419800
r3 : 8001d060  r2 :   r1 : 0001  r0 : 
Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
Control: 10c53c7d  Table: 1000404a  DAC: 0015
Process kworker/u8:2 (pid: 108, stack limit = 0xd8400238)
Stack: (0xd8401e30 to 0xd8402000)
1e20: d87523c0 d8401e48 7562 d8419800
1e40:   d8419800    d84198b0 8040fcdc
1e60:  80dd320c d8477610 d8419c00 d803d010 d8419800  
1e80: d8004400  d848 80431494 80431374 d803d100 d803d010 d803d1ac
1ea0:  80432428 804323d4 d803d100 0001 80435eb8 80e0d0bc d803d100
1ec0: 0006 80436458  d803d100 80e92ec8 80436f44 d803d010 d803d100
1ee0: d83fde00 8043292c d8752710 d803d1f4 d803d010 8042ddfc 8042ddb8 d83f3b00
1f00: d803d1f4 80042b60  0003 0001 0001 80054598 d83f3b00
1f20: d8004400 d83f3b18 d8004414 d840 80e3957b 0089 d8004400 80043814
1f40: d839ec00  d83fcd80 d83f3b00 800436e4   
1f60:  80048f34    d83f3b00  
1f80: d8401f80 d8401f80   d8401f90 d8401f90 d8401fac d83fcd80
1fa0: 80048e68   8000e538    
1fc0:        
1fe0:     0013   
[<8041f9a0>] (ehci_run) from [<8040fcdc>] (usb_add_hcd+0x248/0x6e8)
[<8040fcdc>] (usb_add_hcd) from [<80431494>] (host_start+0x120/0x2e4)
[<80431494>] (host_start) from [<80432428>] (ci_otg_start_host+0x54/0xbc)
[<80432428>] (ci_otg_start_host) from [<80435eb8>] (otg_set_protocol+0xa4/0xd0)
[<80435eb8>] (otg_set_protocol) from [<80436458>] (otg_set_state+0x574/0xc58)
[<80436458>] (otg_set_state) from [<80436f44>] (otg_statemachine+0x408/0x46c)
[<80436f44>] (otg_statemachine) from [<8043292c>] (ci_otg_fsm_work+0x3c/0x190)
[<8043292c>] (ci_otg_fsm_work) from [<8042ddfc>] (ci_otg_work+0x44/0x1c4)
[<8042ddfc>] (ci_otg_work) from [<80042b60>] (process_one_work+0xf4/0x35c)
[<80042b60>] (process_one_work) from [<80043814>] (worker_thread+0x130/0x3bc)
[<80043814>] (worker_thread) from [<80048f34>] (kthread+0xcc/0xe4)
[<80048f34>] (kthread) from [<8000e538>] (ret_from_fork+0x14/0x3c)
Code: e5953018 e353 0a00 e12fff33 (e5878014)

LOG_2:
ci_hdrc ci_hdrc.0: EHCI Host Controller
ci_hdrc ci_hdrc.0: new USB bus registered, assigned bus number 1
ci_hdrc ci_hdrc.1: doesn't support gadget
Unable to handle kernel NULL pointer dereference at virtual address 
pgd = 80004000
[] *pgd=
In Online 00:00ternal e  Offline rror: Oops: 8005 [#1] PREEMPT SMP ARM
Modules linked in:
CPU: 0 PID: 108 Comm: kworker/u8:2 Not tainted 3.14.38-02007-g24b2734-dirty #127
Workque Online 00:00ue: ci_o  Offline tg ci_otg_work
Online 00:00task: d8  Offline 39ec00 ti: d83ea000 task.ti: d83ea000
PC is at 0x0
LR is at usb_add_hcd+0x248/0x6e8
pc : [<>]lr : [<8040f644>]psr: 6113
sp : d83ebe60  ip :   fp : d8004400
r10: 0001  r9 : 0001  r8 : d85fd4b0
r7 :   r6 :   r5 :   r4 : d85fd400
r3 :   r2 : d85fd4f4  r1 : 80410178  r0 : d85fd400
Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
Control: 10c53c7d  Table: 1000404a  DAC: 0015
Process kworker/

RE: [PATCH] usb: dwc3: Reset the transfer resource index on SET_INTERFACE

[Subbaraya Sundeep Bhatta]

Hi,

> -Original Message-
> From: John Youn [mailto:john.y...@synopsys.com]
> Sent: Monday, September 17, 2001 12:30 PM
> To: ba...@ti.com; Subbaraya Sundeep Bhatta
> Cc: linux-usb@vger.kernel.org
> Subject: [PATCH] usb: dwc3: Reset the transfer resource index on
> SET_INTERFACE
> 
> This fixes an issue introduced in a previous patch that added checking of the
> return status of device endpoint commands. It caught the Set Endpoint
> Transfer Resource command failing occasionally. This is because the
> Transfer Resource Index was not getting reset during a SET_INTERFACE
> request.
> 
> Signed-off-by: John Youn 
> ---
>  drivers/usb/dwc3/ep0.c | 4 
>  1 file changed, 4 insertions(+)
> 
> 
> diff --git a/drivers/usb/dwc3/ep0.c b/drivers/usb/dwc3/ep0.c index
> 2ef3c8d..69e769c 100644
> --- a/drivers/usb/dwc3/ep0.c
> +++ b/drivers/usb/dwc3/ep0.c
> @@ -727,6 +727,10 @@ static int dwc3_ep0_std_request(struct dwc3
> *dwc, struct usb_ctrlrequest *ctrl)
>   dwc3_trace(trace_dwc3_ep0,
> "USB_REQ_SET_ISOCH_DELAY");
>   ret = dwc3_ep0_set_isoch_delay(dwc, ctrl);
>   break;
> + case USB_REQ_SET_INTERFACE:
> + dwc3_trace(trace_dwc3_ep0, "USB_REQ_SET_INTERFACE");
> + dwc->start_config_issued = false;
> + /* Fall through */

This is the exact patch I had in my mind after reading databook for 
SetConfiguration/SetInterface. 
I will test and let you know the results.

Thanks,
Sundeep.

>   default:
>   dwc3_trace(trace_dwc3_ep0, "Forwarding to gadget
> driver");
>   ret = dwc3_ep0_delegate_req(dwc, ctrl);
> --
> 2.3.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] Bluetooth: btusb: match generic class code in interface descriptor

[Sjoerd Simons]

On Fri, 2015-07-17 at 11:12 -0600, Daniel Drake wrote:
> btusb currently has a generic match on USB device descriptors:
> { USB_DEVICE_INFO(0xe0, 0x01, 0x01) },
> 
> However, http://www.usb.org/developers/defined_class states:
> 
>   Base Class E0h (Wireless Controller)
>   This base class is defined for devices that are Wireless 
> controllers.
>   Values not shown in the table below are reserved. These class codes 
> are
>   to be used in Interface Descriptors, with the exception of the 
> Bluetooth
>   class code which can also be used in a Device Descriptor.
> 
> Add a match on the interface descriptors accordingly.

> This fixes compatibility with the RTL8723AU device shown below.
> This device conforms to the USB Interface Association Descriptor
> specification, which requires the device to have class ef/02/01.
> The extra IAD descriptor then specifies that interfaces 0 and 1
> belong to the same function/driver, which is true. Provided that
> the Bluetooth device class spec accepts use of the IAD, I imagine 
> that
> technically, all btusb devices should be configured like this.

Great, i didn't know whether was allowed hence using the more
conservative _VENDOR_AND_INTERFACE in my patch, but this solution is de
finately nicer.

Tested with a RTL8723AU device on a Radxa Rock Pro board

Reviewed-By: Sjoerd Simons 
Tested-By: Sjoerd Simons 

> T:  Bus=01 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#=  3 Spd=480  MxCh= 0
> D:  Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs=  1
> P:  Vendor=0bda ProdID=0724 Rev= 2.00
> S:  Manufacturer=Realtek
> S:  Product=802.11n WLAN Adapter
> S:  SerialNumber=00e04c01
> C:* #Ifs= 3 Cfg#= 1 Atr=e0 MxPwr=500mA
> A:  FirstIf#= 0 IfCount= 2 Cls=e0(wlcon) Sub=01 Prot=01
> I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> E:  Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=1ms
> E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
> E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
> I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
> E:  Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
> I:  If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> E:  Ad=03(O) Atr=01(Isoc) MxPS=   9 Ivl=1ms
> E:  Ad=83(I) Atr=01(Isoc) MxPS=   9 Ivl=1ms
> I:  If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> E:  Ad=03(O) Atr=01(Isoc) MxPS=  17 Ivl=1ms
> E:  Ad=83(I) Atr=01(Isoc) MxPS=  17 Ivl=1ms
> I:  If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> E:  Ad=03(O) Atr=01(Isoc) MxPS=  25 Ivl=1ms
> E:  Ad=83(I) Atr=01(Isoc) MxPS=  25 Ivl=1ms
> I:  If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> E:  Ad=03(O) Atr=01(Isoc) MxPS=  33 Ivl=1ms
> E:  Ad=83(I) Atr=01(Isoc) MxPS=  33 Ivl=1ms
> I:  If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> E:  Ad=03(O) Atr=01(Isoc) MxPS=  49 Ivl=1ms
> E:  Ad=83(I) Atr=01(Isoc) MxPS=  49 Ivl=1ms
> I:* If#= 2 Alt= 0 #EPs= 4 Cls=ff(vend.) Sub=ff Prot=ff 
> Driver=rtl8723au
> E:  Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
> E:  Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
> E:  Ad=06(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
> E:  Ad=87(I) Atr=03(Int.) MxPS=  64 Ivl=500us
> 
> Signed-off-by: Daniel Drake 
> ---
>  drivers/bluetooth/btusb.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> This replaces/obsoletes:
>   [PATCH] Bluetooth: btusb: Recognize Realtek shared wifi/bluetooth 
> devices
>   [PATCH] Bluetooth: btusb: Add Realtek devices into module device 
> table
> 
> diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
> index 93339a4..9874aac 100644
> --- a/drivers/bluetooth/btusb.c
> +++ b/drivers/bluetooth/btusb.c
> @@ -64,6 +64,7 @@ static struct usb_driver btusb_driver;
>  static const struct usb_device_id btusb_table[] = {
>   /* Generic Bluetooth USB device */
>   { USB_DEVICE_INFO(0xe0, 0x01, 0x01) },
> + { USB_INTERFACE_INFO(0xe0, 0x01, 0x01) },
>  
>   /* Generic Bluetooth AMP device */
>   { USB_DEVICE_INFO(0xe0, 0x01, 0x04), .driver_info = 
> BTUSB_AMP },

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