Re: [git pull] gadgetfs fixes

[Al Viro]

On Sun, Mar 15, 2015 at 07:35:20AM +0100, Alexander Holler wrote:

> > Umm...  If I'm not misparsing what you said, you are talking about the
> 
> Glücklicherweise nicht. Vielleicht sollten wir es zur Abwechslung mal
> mit meiner bevorzugten Sprache versuchen.

Good.  I'll probably abstain from trying to mangle it, though.

Another question, if you don't mind - does that series (i.e. what's currently
in Linus' tree) fix the module refcount issues you'd been seeing?  I agree
with your analysis of likely cause (->f_op reassignments with different
->owner before and after) and these patches should have eliminated that, but
confirmation would be nice...

Incidentally, none of those file_operations need ->owner in the first place;
it doesn't hurt (as long as ->f_op doesn't change that way), but such files
(living on a filesystem provided by the module their methods are in)
don't need the module refcount bumped while the file is opened - having it
opened pins file_system_type of containing filesystem (by keeping a reference
to struct vfsmount, which keeps a reference to struct super_block, which keeps
a reference to file_system_type), so the module will be kept busy just fine.
Again, having ->owner on file_operations doesn't hurt, so it's not a bug
per se - just pointless in such cases.  So we might want to remove it
from ep_io_operations someday.  Anyway, that's a completely separate story...
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [git pull] gadgetfs fixes

[Alexander Holler]

Am 15.03.2015 um 09:17 schrieb Al Viro:

On Sun, Mar 15, 2015 at 07:35:20AM +0100, Alexander Holler wrote:


Umm...  If I'm not misparsing what you said, you are talking about the


Glücklicherweise nicht. Vielleicht sollten wir es zur Abwechslung mal
mit meiner bevorzugten Sprache versuchen.


Good.  I'll probably abstain from trying to mangle it, though.

Another question, if you don't mind - does that series (i.e. what's currently
in Linus' tree) fix the module refcount issues you'd been seeing?  I agree
with your analysis of likely cause (->f_op reassignments with different
->owner before and after) and these patches should have eliminated that, but
confirmation would be nice...


I haven't tried to apply the whole series to the 3.19.1 which I'm 
currently using. As mentioned before, something (a single patch I've 
tried before) didn't apply cleanly which means I need to have a deeper 
look at the stuff. E.g. I've just learned (through another problem), 
that (my version of) glibc still doesn't use the aio-syscalls the kernel 
provides (and instead uses pread/pwrite).


I will look if I find the time today.


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

Re: [git pull] gadgetfs fixes

[Alexander Holler]

Am 15.03.2015 um 09:17 schrieb Al Viro:


Another question, if you don't mind - does that series (i.e. what's currently
in Linus' tree) fix the module refcount issues you'd been seeing?  I agree
with your analysis of likely cause (->f_op reassignments with different
->owner before and after) and these patches should have eliminated that, but
confirmation would be nice...

Incidentally, none of those file_operations need ->owner in the first place;
it doesn't hurt (as long as ->f_op doesn't change that way), but such files
(living on a filesystem provided by the module their methods are in)
don't need the module refcount bumped while the file is opened - having it
opened pins file_system_type of containing filesystem (by keeping a reference
to struct vfsmount, which keeps a reference to struct super_block, which keeps
a reference to file_system_type), so the module will be kept busy just fine.
Again, having ->owner on file_operations doesn't hurt, so it's not a bug
per se - just pointless in such cases.  So we might want to remove it
from ep_io_operations someday.  Anyway, that's a completely separate story...


Hmm, a year ago or so I've stumbled over the fact that the owner might 
be necessary for correct entries in sysfs (that was mtd). I've no idea 
if that's true here too but it might be worse to mention it.


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

Re: [git pull] gadgetfs fixes

[Al Viro]

On Sun, Mar 15, 2015 at 09:50:01AM +0100, Alexander Holler wrote:

> Hmm, a year ago or so I've stumbled over the fact that the owner
> might be necessary for correct entries in sysfs (that was mtd). I've
> no idea if that's true here too but it might be worse to mention it.

There are two mechanisms.  One keeps the filesystem your file is on pinned
while the file is opened.  That works for all filesystems, and it's enough
when the methods of that file are in the module defining that filesystem.
In cases when that is not enough (e.g. character device living on ext3 -
it's nice to have ext3 pinned down, but you want the driver that defined
that device to be pinned as well) you can ask to pin a given module for
as long as the file is opened.  That's what file_operations ->owner gives.
Your example (mtd creating a file on sysfs) also needs that - you want
mtd pinned, not just sysfs.

gadgetfs, however, has filesystem defined by the same module.  So pinning
filesystem_type down is enough - nothing extra is needed, same as for e.g.
a regular file on ext3.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/2] serial: 8250_pci: Fintek products patches

[Greg KH]

On Fri, Mar 13, 2015 at 10:00:11AM +0800, Peter Hung wrote:
> These series patches works for Fintek F81504/F81508/F81512 PCI to Serial Port.
> and patch 0002 is following with patch 0001.
> 
> patch 0001 is just cleanup non-used source code.
> patch 0002 is major patch.
> 
> The serial port of our product will failed after wakeup from S3(STR).
> 
> It's due to when the system wakeup from S3(STR), this PCI device's
> configuration space from 0x40 to 0x40 + max_port * 0x08 should be
> re-configured. If had no re-configure, It's will all zero.
> 
> We move all initialization from pci_fintek_setup() to pci_fintek_init() and
> set it to pci_serial_quirks struct .init section. It's will re-init this 
> device when system wakeup from pciserial_resume_ports().
> 
> Peter Hung (2):
>   serial: 8250_pci: remove non-used var for F81504
>   serial: 8250_pci: port failed after wakeup from S3
> 
>  drivers/tty/serial/8250/8250_pci.c | 121 
> +++--
>  1 file changed, 50 insertions(+), 71 deletions(-)

Why did you cc: the linux-usb@vger mailing list on these?  Don't you
mean linux-serial@vger?
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 1/1] usb: xhci: apply XHCI_AVOID_BEI quirk to all Intel xHCI controllers

[Alistair Grant]

On Fri, Mar 13, 2015 at 1:54 AM, Lu Baolu  wrote:
> ...
> This patch is to apply XHCI_AVOID_BEI quirk to Intel xHC devices. And
> it should be backported to kernels as old as 3.0, that contains the
> commit 69e848c2090a ("Intel xhci: Support EHCI/xHCI port switching.").
>
> Signed-off-by: Lu Baolu 
> Tested-by: Alistair Grant 
> Tested-by: Devin Heitmueller 
> Cc: sta...@vger.kernel.org
> ...

As a workaround until this makes it to the various distributions,
would it be possible to create a config file that enables the quirk,
something like:

> cat /etc/modprobe.d/xhci.conf
# Enable XHCI_AVOID_BEI (= 1<<15)
options xhci-plat-hcd quirks=32768

I tried this using "xhci-plat-hcd" and "xhci-hcd", but neither appeared to work.

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

Re: [PATCH v2 1/1] usb: xhci: apply XHCI_AVOID_BEI quirk to all Intel xHCI controllers

[Alistair Grant]

On Thu, Mar 12, 2015 at 8:14 PM, Alistair Grant  wrote:
> On Thu, Mar 12, 2015 at 11:15 AM, Lu Baolu  wrote:
>> When a device with an isochronous endpoint is plugged into the Intel
>> xHCI host controller, and the driver submits multiple frames per URB,
>> the xHCI driver will set the Block Event Interrupt (BEI) flag on all
>> but the last TD for the URB. This causes the host controller to place
>> an event on the event ring, but not send an interrupt. When the last
>> TD for the URB completes, BEI is cleared, and we get an interrupt for
>> the whole URB.
>>
>> However, under Intel xHCI host controllers, if the event ring is full
>> of events from transfers with BEI set,  an "Event Ring is Full" event
>> will be posted to the last entry of the event ring,  but no interrupt
>> is generated. Host will cease all transfer and command executions and
>> wait until software completes handling the pending events in the event
>> ring.  That means xHC stops, but event of "event ring is full" is not
>> notified. As the result, the xHC looks like dead to user.
>>
>> This patch is to apply XHCI_AVOID_BEI quirk to Intel xHC devices. And
>> it should be backported to kernels as old as 3.0, that contains the
>> commit 69e848c2090a ("Intel xhci: Support EHCI/xHCI port switching.").
>>
>> Signed-off-by: Lu Baolu 
>> Cc: sta...@vger.kernel.org
>> ---
>>  drivers/usb/host/xhci-pci.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
>> index fd53c9e..2af32e2 100644
>> --- a/drivers/usb/host/xhci-pci.c
>> +++ b/drivers/usb/host/xhci-pci.c
>> @@ -115,6 +115,7 @@ static void xhci_pci_quirks(struct device *dev, struct 
>> xhci_hcd *xhci)
>> if (pdev->vendor == PCI_VENDOR_ID_INTEL) {
>> xhci->quirks |= XHCI_LPM_SUPPORT;
>> xhci->quirks |= XHCI_INTEL_HOST;
>> +   xhci->quirks |= XHCI_AVOID_BEI;
>> }
>> if (pdev->vendor == PCI_VENDOR_ID_INTEL &&
>> pdev->device == 
>> PCI_DEVICE_ID_INTEL_PANTHERPOINT_XHCI) {
>> @@ -130,7 +131,6 @@ static void xhci_pci_quirks(struct device *dev, struct 
>> xhci_hcd *xhci)
>>  * PPT chipsets.
>>  */
>> xhci->quirks |= XHCI_SPURIOUS_REBOOT;
>> -   xhci->quirks |= XHCI_AVOID_BEI;
>> }
>> if (pdev->vendor == PCI_VENDOR_ID_INTEL &&
>> pdev->device == PCI_DEVICE_ID_INTEL_LYNXPOINT_LP_XHCI) {
>> --
>> 2.1.0
>>
>> --
>
> This works for me...
>
> Computer: Dell XPS13 9333
> USB controller: Intel Corporation 8 Series USB xHCI HC (rev 04)
> (prog-if 30 [XHCI])
> Kernel: 3.19.1
> USB Device: Hauppauge USB-Live2
>
> Please let me know if I can help in any other way.
>
> Tested-by: Alistair Grant 

Just FYI...

I was able to test this on a slightly older laptop that had both USB2
and USB3 ports and can confirm that it also works there:

00:14.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset
Family USB xHCI Host Controller (rev 04)

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

[PATCH] xhci: match return type of wait_for_completion_timeout

[Nicholas Mc Guire]

Return type of wait_for_completion_timeout is unsigned long not int.
As time_left is exclusively used for wait_for_completion_timeout here its 
type is simply changed to unsigned long.

Signed-off-by: Nicholas Mc Guire 
---

Patch was only compile tested with x86_64_defconfig + CONFIG_USB_XHCI_HCD=m

Patch is against 4.0-rc3 (localversion-next is -next-20150313)

 drivers/usb/host/xhci-hub.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
index a7865c4..9e2bbfd 100644
--- a/drivers/usb/host/xhci-hub.c
+++ b/drivers/usb/host/xhci-hub.c
@@ -602,7 +602,7 @@ static u32 xhci_get_port_status(struct usb_hcd *hcd,
return 0x;
if (time_after_eq(jiffies,
bus_state->resume_done[wIndex])) {
-   int time_left;
+   unsigned long time_left;
 
xhci_dbg(xhci, "Resume USB2 port %d\n",
wIndex + 1);
-- 
1.7.10.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] uwb: Remove umc bus legacy suspend/resume support

[Lars-Peter Clausen]

There are currently no umc drivers implementing suspend/resume, so remove
the legacy suspend/resume support from the framework. If a umc driver ever
wants to implement suspend/resume they can use dev_pm_ops, which works out
of the box without any additional support necessary from the bus itself.

Signed-off-by: Lars-Peter Clausen 
---
 drivers/uwb/umc-bus.c   | 34 --
 include/linux/uwb/umc.h |  2 --
 2 files changed, 36 deletions(-)

diff --git a/drivers/uwb/umc-bus.c b/drivers/uwb/umc-bus.c
index 88a290f..c857140 100644
--- a/drivers/uwb/umc-bus.c
+++ b/drivers/uwb/umc-bus.c
@@ -163,38 +163,6 @@ static int umc_device_remove(struct device *dev)
return 0;
 }
 
-static int umc_device_suspend(struct device *dev, pm_message_t state)
-{
-   struct umc_dev *umc;
-   struct umc_driver *umc_driver;
-   int err = 0;
-
-   umc = to_umc_dev(dev);
-
-   if (dev->driver) {
-   umc_driver = to_umc_driver(dev->driver);
-   if (umc_driver->suspend)
-   err = umc_driver->suspend(umc, state);
-   }
-   return err;
-}
-
-static int umc_device_resume(struct device *dev)
-{
-   struct umc_dev *umc;
-   struct umc_driver *umc_driver;
-   int err = 0;
-
-   umc = to_umc_dev(dev);
-
-   if (dev->driver) {
-   umc_driver = to_umc_driver(dev->driver);
-   if (umc_driver->resume)
-   err = umc_driver->resume(umc);
-   }
-   return err;
-}
-
 static ssize_t capability_id_show(struct device *dev, struct device_attribute 
*attr, char *buf)
 {
struct umc_dev *umc = to_umc_dev(dev);
@@ -223,8 +191,6 @@ struct bus_type umc_bus_type = {
.match  = umc_bus_match,
.probe  = umc_device_probe,
.remove = umc_device_remove,
-   .suspend= umc_device_suspend,
-   .resume = umc_device_resume,
.dev_groups = umc_dev_groups,
 };
 EXPORT_SYMBOL_GPL(umc_bus_type);
diff --git a/include/linux/uwb/umc.h b/include/linux/uwb/umc.h
index ba82f03..0211229 100644
--- a/include/linux/uwb/umc.h
+++ b/include/linux/uwb/umc.h
@@ -87,8 +87,6 @@ struct umc_driver {
 
int  (*probe)(struct umc_dev *);
void (*remove)(struct umc_dev *);
-   int  (*suspend)(struct umc_dev *, pm_message_t state);
-   int  (*resume)(struct umc_dev *);
int  (*pre_reset)(struct umc_dev *);
int  (*post_reset)(struct umc_dev *);
 
-- 
1.8.0

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

Re: [PATCH v2 1/1] usb: xhci: apply XHCI_AVOID_BEI quirk to all Intel xHCI controllers

[Alistair Grant]

On Sun, Mar 15, 2015 at 3:54 PM, Alistair Grant  wrote:
> On Thu, Mar 12, 2015 at 8:14 PM, Alistair Grant  wrote:
>> On Thu, Mar 12, 2015 at 11:15 AM, Lu Baolu  wrote:
>>> When a device with an isochronous endpoint is plugged into the Intel
>>> xHCI host controller, and the driver submits multiple frames per URB,
>>> the xHCI driver will set the Block Event Interrupt (BEI) flag on all
>>> but the last TD for the URB. This causes the host controller to place
>>> an event on the event ring, but not send an interrupt. When the last
>>> TD for the URB completes, BEI is cleared, and we get an interrupt for
>>> the whole URB.
>>>
>>> However, under Intel xHCI host controllers, if the event ring is full
>>> of events from transfers with BEI set,  an "Event Ring is Full" event
>>> will be posted to the last entry of the event ring,  but no interrupt
>>> is generated. Host will cease all transfer and command executions and
>>> wait until software completes handling the pending events in the event
>>> ring.  That means xHC stops, but event of "event ring is full" is not
>>> notified. As the result, the xHC looks like dead to user.
>>>
>>> This patch is to apply XHCI_AVOID_BEI quirk to Intel xHC devices. And
>>> it should be backported to kernels as old as 3.0, that contains the
>>> commit 69e848c2090a ("Intel xhci: Support EHCI/xHCI port switching.").
>>>
>>> Signed-off-by: Lu Baolu 
>>> Cc: sta...@vger.kernel.org
>>> ---
>>>  drivers/usb/host/xhci-pci.c | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
>>> index fd53c9e..2af32e2 100644
>>> --- a/drivers/usb/host/xhci-pci.c
>>> +++ b/drivers/usb/host/xhci-pci.c
>>> @@ -115,6 +115,7 @@ static void xhci_pci_quirks(struct device *dev, struct 
>>> xhci_hcd *xhci)
>>> if (pdev->vendor == PCI_VENDOR_ID_INTEL) {
>>> xhci->quirks |= XHCI_LPM_SUPPORT;
>>> xhci->quirks |= XHCI_INTEL_HOST;
>>> +   xhci->quirks |= XHCI_AVOID_BEI;
>>> }
>>> if (pdev->vendor == PCI_VENDOR_ID_INTEL &&
>>> pdev->device == 
>>> PCI_DEVICE_ID_INTEL_PANTHERPOINT_XHCI) {
>>> @@ -130,7 +131,6 @@ static void xhci_pci_quirks(struct device *dev, struct 
>>> xhci_hcd *xhci)
>>>  * PPT chipsets.
>>>  */
>>> xhci->quirks |= XHCI_SPURIOUS_REBOOT;
>>> -   xhci->quirks |= XHCI_AVOID_BEI;
>>> }
>>> if (pdev->vendor == PCI_VENDOR_ID_INTEL &&
>>> pdev->device == PCI_DEVICE_ID_INTEL_LYNXPOINT_LP_XHCI) {
>>> --
>>> 2.1.0
>>>
>>> --
>>
>> This works for me...
>>
>> Computer: Dell XPS13 9333
>> USB controller: Intel Corporation 8 Series USB xHCI HC (rev 04)
>> (prog-if 30 [XHCI])
>> Kernel: 3.19.1
>> USB Device: Hauppauge USB-Live2
>>
>> Please let me know if I can help in any other way.
>>
>> Tested-by: Alistair Grant 
>
> Just FYI...
>
> I was able to test this on a slightly older laptop that had both USB2
> and USB3 ports and can confirm that it also works there:
>
> 00:14.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset
> Family USB xHCI Host Controller (rev 04)

It looks like I may have signed-off a little too soon.  While the patch is
working correctly if the Hauppauge Live2 is plugged in after the system has
booted and settled down (my normal use case), it fails if the Live2 is
plugged in while the system is booted up.

Unplugging the Live2 after recording (which appears to succeed from the
command line, but had no audio), executing lsusb just hangs.

I've included what I think is the relevant portions of /var/log/syslog
below.  If you'd like the entire log file posted somewhere please let me
know.

Thanks,
Alistair


Mar 15 19:50:42 alistair-XPS13 kernel: [   15.177240] Linux video
capture interface: v2.00
Mar 15 19:50:42 alistair-XPS13 kernel: [   15.221452] AVX2 version of
gcm_enc/dec engaged.
Mar 15 19:50:42 alistair-XPS13 kernel: [   15.221456] AES CTR mode by8
optimization enabled
Mar 15 19:50:42 alistair-XPS13 kernel: [   15.257091] cx231xx 1-2:1.1:
New device Hauppauge Hauppauge Device @ 480 Mbps (2040:c200) with 6
interfaces
Mar 15 19:50:42 alistair-XPS13 kernel: [   15.257790] cx231xx 1-2:1.1:
can't change interface 3 alt no. to 3: Max. Pkt size = 0
Mar 15 19:50:42 alistair-XPS13 kernel: [   15.259281] cx231xx 1-2:1.1:
can't change interface 4 alt no. to 1: Max. Pkt size = 0
Mar 15 19:50:42 alistair-XPS13 kernel: [   15.260533] cx231xx 1-2:1.1:
Identified as Hauppauge USB Live 2 (card=9)
Mar 15 19:50:42 alistair-XPS13 kernel: [   15.260724] i2c i2c-10:
Added multiplexed i2c bus 12
Mar 15 19:50:42 alistair-XPS13 kernel: [   15.260766] i2c i2c-10:
Added multiplexed i2c bus 13

...

Mar 15 19:50:42 alistair-XPS13 kernel: [   15.452042] cx25840 9-0044:
cx23102 A/V decoder found @ 0x88 (cx231xx #0-0)

...

Mar 15 19:50:44 alistair-XPS13 kernel: [   17.447893] cx25840 9-0044:
loaded v4l-cx231xx-avcore-01.fw firmware (16382 byt

Re: [PATCH v4 5/5] usb: gadget: udc-core: independent registration of gadgets and gadget drivers

[Ruslan Bilovol]

HI Alan,

On Fri, Mar 13, 2015 at 4:39 PM, Alan Stern  wrote:
> On Thu, 12 Mar 2015, Ruslan Bilovol wrote:
>
>> Change behavior during registration of gadgets and
>> gadget drivers in udc-core. Instead of previous
>> approach when for successful probe of usb gadget driver
>> at least one usb gadget should be already registered
>> use another one where gadget drivers and gadgets
>> can be registered in udc-core independently.
>>
>> Independent registration of gadgets and gadget drivers
>> is useful for built-in into kernel gadget and gadget
>> driver case - because it's possible that gadget is
>> really probed only on late_init stage (due to deferred
>> probe) whereas gadget driver's probe is silently failed
>> on module_init stage due to no any UDC added.
>>
>> Also it is useful for modules case - now there is no
>> difference what module to insert first: gadget module
>> or gadget driver one.
>
>
>> @@ -366,9 +383,16 @@ found:
>>   list_del(&udc->list);
>>   mutex_unlock(&udc_lock);
>>
>> - if (udc->driver)
>> + if (udc->driver) {
>> + struct usb_gadget_driver *driver = udc->driver;
>> +
>>   usb_gadget_remove_driver(udc);
>>
>> + mutex_lock(&udc_lock);
>> + list_add(&driver->pending, &gadget_driver_pending_list);
>> + mutex_unlock(&udc_lock);
>> + }
>
> I'm not sure this is a good idea.  Gadget drivers probably don't expect
> to be bound again after they are unbound.

This already has been discussed some time ago:
https://lkml.org/lkml/2015/2/9/497
The bottom line was - such gadget drivers are buggy and need to be fixed
since there is no known restrictions in binding gadget drivers to UDC multiple
times

>
> Besides, when would this gadget driver get bound to a UDC?  Not until
> the next UDC is added -- even if there already are some unbound UDCs.

Currently this gadget driver will get bound to a UDC only when next UDC
is added. It seems there is no users of this feature, so I didn't
add full implementation of this (that I had in version #1 if this patch:
https://lkml.org/lkml/2015/1/28/1079 )

>
>
>> @@ -468,6 +491,16 @@ int usb_gadget_unregister_driver(struct 
>> usb_gadget_driver *driver)
>>   break;
>>   }
>>
>> + if (ret) {
>> + struct usb_gadget_driver *tmp;
>> +
>> + list_for_each_entry(tmp, &gadget_driver_pending_list, pending)
>> + if (tmp == driver) {
>> + list_del(&driver->pending);
>> + ret = 0;
>> + break;
>> + }
>> + }
>
> You could avoid this loop and simply do list_del(&driver->pending), if
> you made sure driver->pending was initialized.

It would be good to avoid this loop but the question is how to make sure
that driver->pending is not only initialized (prev and next are not NULL),
but also contains valid data?

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

Re: [PATCH v2 2/5] usb: chipidea: udc: add OTG status request handling

[Peter Chen]

On Fri, Mar 13, 2015 at 09:41:13PM +0800, Li Jun wrote:
> On Fri, Mar 13, 2015 at 11:01:47AM +0800, Peter Chen wrote:
> > On Thu, Mar 12, 2015 at 10:30:21AM +0800, Li Jun wrote:
> > > From: Li Jun 
> > > 
> > > Peripheral answers OTG status selector request from host according to
> > > host_request_flag of gadget, length is 1.
> > > 
> > > Signed-off-by: Li Jun 
> > > ---
> > >  drivers/usb/chipidea/udc.c |   28 +++-
> > >  1 file changed, 23 insertions(+), 5 deletions(-)
> > > 
> > > diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
> > > index 4254792..eed66bc 100644
> > > --- a/drivers/usb/chipidea/udc.c
> > > +++ b/drivers/usb/chipidea/udc.c
> > > @@ -831,7 +831,17 @@ __acquires(hwep->lock)
> > >   return -ENOMEM;
> > >  
> > >   req->complete = isr_get_status_complete;
> > > - req->length   = 2;
> > > + if (setup->wIndex == OTG_STS_SELECTOR) {
> > 
> > It seems you define OTG_STS_SELECTOR at your 4/5, move it
> > to this one to avoid 'git bisect' problem.
> > 
> 
> I will resolve this.
> 
> Li Jun
> > > + if (ci_otg_is_fsm_mode(ci)) {
> > > + req->length = 1;
> > > + } else {
> > > + retval = -ENOTSUPP;
> > > + goto err_free_req;
> > > + }
> > 
> > If we don't support it, why not stall it?
> > 
> 
> This error handling will stall/halt it, isn't it?
> 

Oh, yes, it will.

-- 

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

Re: [PATCH 0/2] serial: 8250_pci: Fintek products patches

[Peter Hung]

Hello,

Greg KH 於 2015/3/15 下午 05:25 寫道:

Why did you cc: the linux-usb@vger mailing list on these?  Don't you
mean linux-serial@vger?



Sorry for my fault. Should I resend it with correct mail-list with V2 ??
or just send this series patches ?

Thanks
--
With Best Regards,
Peter Hung
--
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] usb: chipidea: udc: add OTG status request handling

[Peter Chen]

On Fri, Mar 13, 2015 at 10:34:59AM -0500, Felipe Balbi wrote:
> On Fri, Mar 13, 2015 at 11:13:11AM +0800, Peter Chen wrote:
> > On Thu, Mar 12, 2015 at 11:04:09AM -0500, Felipe Balbi wrote:
> > > Hi,
> > > 
> > > On Thu, Mar 12, 2015 at 10:30:21AM +0800, Li Jun wrote:
> > > > From: Li Jun 
> > > > 
> > > > Peripheral answers OTG status selector request from host according to
> > > > host_request_flag of gadget, length is 1.
> > > > 
> > > > Signed-off-by: Li Jun 
> > > > ---
> > > >  drivers/usb/chipidea/udc.c |   28 +++-
> > > >  1 file changed, 23 insertions(+), 5 deletions(-)
> > > > 
> > > > diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
> > > > index 4254792..eed66bc 100644
> > > > --- a/drivers/usb/chipidea/udc.c
> > > > +++ b/drivers/usb/chipidea/udc.c
> > > > @@ -831,7 +831,17 @@ __acquires(hwep->lock)
> > > > return -ENOMEM;
> > > >  
> > > > req->complete = isr_get_status_complete;
> > > > -   req->length   = 2;
> > > > +   if (setup->wIndex == OTG_STS_SELECTOR) {
> > > > +   if (ci_otg_is_fsm_mode(ci)) {
> > > > +   req->length = 1;
> > > > +   } else {
> > > > +   retval = -ENOTSUPP;
> > > > +   goto err_free_req;
> > > > +   }
> > > > +   } else {
> > > > +   req->length = 2;
> > > > +   }
> > > 
> > > this could still be done generically in composite.c
> > > 
> > 
> > I suggested it at v1, but after thinking more, we have handled
> > DEVICE request type at individual udc driver, like remote wakeup,
> > self-power support, so it is reasonable we handle get_status that
> > if we support hnp polling at udc driver, since it is controller
> > driver's capabilities.
> 
> right, right.. it is controller's capabilities, but all controller needs
> to do is a set a flag in struct usb_gadget, which it already does. Then,
> every single udc will get free implementation after setting that flag,
> right ?
> 

Great, then the udc driver which set b_hnp_enable can get the hnp
polling capabilities automatically, in fact, hnp polling support
is a software implement, I don't think it will affect old v1.3 otg
driver.

-- 

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

Re: [PATCH 00/19] usb: third series of updates for dwc2 driver

[zhangfei]

On 03/09/2015 11:04 PM, Mian Yousaf Kaukab wrote:

Hi,
This patchset consists of some bug fixes and feature enhancements for
the dwc2 driver. All the patches are verified on dwc2 v3.0a with
dedicated fifos. Main focus of testing was with dma enabled. Although
basic testing without dma was also done.

This is based on testing/next branch in Felipe's git.


Thanks Yousaf
Also verified on hikey board, dma mode, though it is also dwc2 v3.0a.

--
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 V8 02/10] USB: f81232: implement RX bulk-in EP

[Peter Hung]

Hello,

Johan Hovold 於 2015/3/14 下午 07:48 寫道:

On Thu, Feb 26, 2015 at 06:02:08PM +0800, Peter Hung wrote:

-   if (!urb->actual_length)
+   if ((urb->actual_length < 2) || (urb->actual_length % 2))
return;


Not parsing short data (e.g. not divisible by 2) is OK I guess. You
could also just discard the last odd byte, but that's up to you.

Either way, I think you should add a dev_warn here rather than just
silently drop it.


With F81232, when it first submit with interrupt URB, it will response 
once with 1 bytes data. The data is hw current LSR, but it useless on 
open. It's should necessary with receiving data. When the device is 
working good, it's should acked with even size data.


To avoid confusing to user, I'll keep it without warning message.

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

[PATCH] USB: ftdi_sio: Added custom PID for Synapse Wireless product

[Doug Goldstein]

Synapse Wireless uses the FTDI VID with a custom PID of 0x9090 for their
SNAP Stick 200 product.

Signed-off-by: Doug Goldstein 
---
 drivers/usb/serial/ftdi_sio.c | 1 +
 drivers/usb/serial/ftdi_sio_ids.h | 6 ++
 2 files changed, 7 insertions(+)

diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
index 3086dec..247130b 100644
--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -997,6 +997,7 @@ static const struct usb_device_id id_table_combined[] = {
{ USB_DEVICE(FTDI_VID, CHETCO_SEASMART_DISPLAY_PID) },
{ USB_DEVICE(FTDI_VID, CHETCO_SEASMART_LITE_PID) },
{ USB_DEVICE(FTDI_VID, CHETCO_SEASMART_ANALOG_PID) },
+   { USB_DEVICE(FTDI_VID, FTDI_SYNAPSE_SS200_PID) },
{ } /* Terminating entry */
 };
 
diff --git a/drivers/usb/serial/ftdi_sio_ids.h 
b/drivers/usb/serial/ftdi_sio_ids.h
index 56b1b55..4e4f46f 100644
--- a/drivers/usb/serial/ftdi_sio_ids.h
+++ b/drivers/usb/serial/ftdi_sio_ids.h
@@ -561,6 +561,12 @@
  */
 #define FTDI_NT_ORIONLXM_PID   0x7c90  /* OrionLXm Substation Automation 
Platform */
 
+/*
+ * Synapse Wireless product ids (FTDI_VID)
+ * http://www.synapse-wireless.com
+ */
+#define FTDI_SYNAPSE_SS200_PID 0x9090 /* SS200 - SNAP Stick 200 */
+
 
 //
 /** third-party VID/PID combos **/
-- 
2.0.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 V8 04/10] USB: f81232: implement read IIR/MSR with endpoint

[Peter Hung]

Hello,

Johan Hovold 於 2015/3/14 下午 08:02 寫道:

On Thu, Feb 26, 2015 at 06:02:10PM +0800, Peter Hung wrote:

+   if (status != sizeof(*val)) {
+   dev_err(&port->dev, "%s failed status: %d\n", __func__, status);
+
+   if (status == 0)
+   status = -EIO;
+   else
+   status = usb_translate_errors(status);


Could you rewrite this as

if (status < 0)
status = usb_translate_errors(status);
else
status = 0;


In my definition the return value of set/getregister(), 0 is success, 
negative values are errors. The function usb_control_msg() return value 
is success transmited/received byte. It's maybe return 0. I want to 
treat 0 with error(-EIO). But if pass 0 to usb_translate_errors(), It 
will return 0 back. So I need especially handle with status == 0.


I'll keep this sections.

Thanks for review
--
With Best Regards,
Peter Hung
--
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: Driver problem with USB chipset VIA VL812-B2

[wseverin]

Tested with 4.0-rc4. Problem persists exactly as earlier versions.

This is a potentially serious issue. Plugging common external USB 3.0 hubs
into the host USB 3.0 hub on a very popular HP laptop, using a very popular
AMD chipset, locks up a CPU.

So far, over 3 weeks, no acknowledgement. I'd be happy to gather whatever
data is necessary for someone to begin looking at it.

--
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: Regarding FSL OTG support patch set

[Ramneek Mehresh]

Hi Balbi,

I just sent you one mail...and that too for "advice...asking for 
suggestion/guidance", not to complain for "late review". I don't think there's 
any reason here to be perturbed.

Thanks and Regards,
Ramneek

> -Original Message-
> From: Felipe Balbi [mailto:ba...@ti.com]
> Sent: Saturday, March 14, 2015 12:36 AM
> To: Mehresh Ramneek-B31383
> Cc: ba...@ti.com; Linux USB Mailing List
> Subject: Re: Regarding FSL OTG support patch set
> 
> Hi,
> 
> On Wed, Mar 04, 2015 at 03:24:04PM +, Ramneek Mehresh wrote:
> > Hi Felipe,
> >
> > Several FSL OTG patches have been under review in open-source maillist
> > for some time. However, they have not been merged.
> > Now, one of the patches needs to be rebased. Not sure how to proceed.
> > Please suggest. Shall I resend the patches.
> >
> > Please find the list of these patches below:
> > [PATCH 1/7] fsl/otg: Add controller version based ULPI and UTMI
> > phy root.php?message_id=1402491778%2d19386%
> > 2d1%2dgit%2dsend%2demail%2dramneek.mehresh%40freescale.com>
> > [PATCH 2/7] fsl/otg: Add support to add/remove usb host
> > driver root.php?message_id=1402491778%2d193
> >
> 86%2d2%2dgit%2dsend%2demail%2dramneek.mehresh%40freescale.com>
> > [PATCH 3/7] fsl/otg: Modify otg_event to start host
> >
> drv > eek> [PATCH 4/7] fsl/otg: Combine host/gadget start/resume for ID
> >
> change > amneek> [PATCH 5/7] fsl/otg: Remove host drv upon otg
> > bring-up > =ramneek> [PATCH 6/7] fsl/otg: Add host-gadget drv sync
> > delay > mneek> [PATCH 7/7] fsl/otg: Resolve OTG crash issue with another
> >
> host > neek>
> 
> I'll be very frank, if you don't stop sending me private emails questioning
> about patches which have unresolved comments on them, I'll start ignoring
> your patches.
> 
> Sorry, but I just can't have people pinging me in private when communication
> must be done through the mailing list.
> 
> not to mention that the thread you link here, I wasn't even in Cc and I asked
> you to resend with proper maintainers in Cc, then you did and Alan had a
> comment on your patch which remains unresolved from what I can see.
> 
> regards
> 
> --
> 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: [PATCH 2/8][v2]usb:fsl:otg: Add support to add/remove usb host driver

[Ramneek Mehresh]

Understood...will do

Thanks.


> -Original Message-
> From: Felipe Balbi [mailto:ba...@ti.com]
> Sent: Saturday, March 14, 2015 12:28 AM
> To: Mehresh Ramneek-B31383
> Cc: linux-usb@vger.kernel.org; ba...@ti.com; gre...@linuxfoundation.org; Li
> Yang-Leo-R58472
> Subject: Re: [PATCH 2/8][v2]usb:fsl:otg: Add support to add/remove usb
> host driver
> 
> On Fri, Mar 13, 2015 at 11:41:09PM +0530, Ramneek Mehresh wrote:
> > Add workqueue to add/remove host driver (outside interrupt context)
> > upon each id change
> >
> > Signed-off-by: Li Yang 
> > Signed-off-by: Ramneek Mehresh 
> > Reviewed-by: Fleming Andrew-AFLEMING 
> > Tested-by: Fleming Andrew-AFLEMING 
> > ---
> > Changes for v2:
> > - moved change_hcd_work into struct ehci_fsl
> >
> >  drivers/usb/host/ehci-fsl.c   | 107
> ++
> >  drivers/usb/host/ehci.h   |   1 -
> >  drivers/usb/phy/phy-fsl-usb.c |   7 ++-
> 
> you really ought to find a way to split this patch so that phy-fsl-usb.c and 
> ehci
> changes don't depend on each other. That way I can take the phy part
> through my tree while Alan handles EHCI.
> 
> --
> 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: Regarding FSL OTG support patch set

[Ramneek Mehresh]

Hi Balbi,

You had responded to my mail that I sent for your advice. And I followed your 
advice to put Alan and Greg in cc. Also, promptly responded to Alan's comments.

As for sending another version, this is my first patch set in 
open-source...learning on the way from you guys by following your comments :)

Not sure what thing perturbed you!!

Thanks and Regards,
Ramneek

> -Original Message-
> From: Mehresh Ramneek-B31383
> Sent: Monday, March 16, 2015 11:48 AM
> To: 'ba...@ti.com'
> Cc: Linux USB Mailing List
> Subject: RE: Regarding FSL OTG support patch set
> 
> Hi Balbi,
> 
> I just sent you one mail...and that too for "advice...asking for
> suggestion/guidance", not to complain for "late review". I don't think there's
> any reason here to be perturbed.
> 
> Thanks and Regards,
> Ramneek
> 
> > -Original Message-
> > From: Felipe Balbi [mailto:ba...@ti.com]
> > Sent: Saturday, March 14, 2015 12:36 AM
> > To: Mehresh Ramneek-B31383
> > Cc: ba...@ti.com; Linux USB Mailing List
> > Subject: Re: Regarding FSL OTG support patch set
> >
> > Hi,
> >
> > On Wed, Mar 04, 2015 at 03:24:04PM +, Ramneek Mehresh wrote:
> > > Hi Felipe,
> > >
> > > Several FSL OTG patches have been under review in open-source
> > > maillist for some time. However, they have not been merged.
> > > Now, one of the patches needs to be rebased. Not sure how to proceed.
> > > Please suggest. Shall I resend the patches.
> > >
> > > Please find the list of these patches below:
> > > [PATCH 1/7] fsl/otg: Add controller version based ULPI and UTMI
> > > phy > root.php?message_id=1402491778%2d19386%
> > > 2d1%2dgit%2dsend%2demail%2dramneek.mehresh%40freescale.com>
> > > [PATCH 2/7] fsl/otg: Add support to add/remove usb host
> > > driver > root.php?message_id=1402491778%2d193
> > >
> >
> 86%2d2%2dgit%2dsend%2demail%2dramneek.mehresh%40freescale.com>
> > > [PATCH 3/7] fsl/otg: Modify otg_event to start host
> > >
> >
> drv > > eek> [PATCH 4/7] fsl/otg: Combine host/gadget start/resume for ID
> > >
> >
> change > > amneek> [PATCH 5/7] fsl/otg: Remove host drv upon otg
> > > bring-up > > ch =ramneek> [PATCH 6/7] fsl/otg: Add host-gadget drv sync
> > > delay > > ra
> > > mneek> [PATCH 7/7] fsl/otg: Resolve OTG crash issue with another
> > >
> >
> host > > neek>
> >
> > I'll be very frank, if you don't stop sending me private emails
> > questioning about patches which have unresolved comments on them, I'll
> > start ignoring your patches.
> >
> > Sorry, but I just can't have people pinging me in private when
> > communication must be done through the mailing list.
> >
> > not to mention that the thread you link here, I wasn't even in Cc and
> > I asked you to resend with proper maintainers in Cc, then you did and
> > Alan had a comment on your patch which remains unresolved from what I
> can see.
> >
> > regards
> >
> > --
> > balbi
--- Begin Message ---
On Wed, Jun 11, 2014 at 06:32:53PM +0530, Ramneek Mehresh wrote:
> Add controller version based ULPI and UTMI phy initialization for
> otg driver
> 
> Signed-off-by: Shengzhou Liu 
> Signed-off-by: Ramneek Mehresh 
> Reviewed-by: Fleming Andrew-AFLEMING 
> Tested-by: Fleming Andrew-AFLEMING 

please resend with proper Cc list. I had lost this patch set because I
was not in Cc. And Alan Stern probably didn't see your changes on
ehci-fsl either.

scripts/get_maintainer.pl helps a lot

-- 
balbi


signature.asc
Description: Digital signature
--- End Message ---