some question about unbind and rebind usb interfaces
hi all: below patch introduce unbind and rebind interfaces during usb reset https://lists.ubuntu.com/archives/kernel-team/2014-April/042177.html If a driver claims additional interfaces, the claim may fail because the old binding instance may still own the additional interface when the new instance tries to claim it. After usb_reset_device, the whole enumeration will run again, why this patch say the previous solution will be fail to claim additional interface? thanks for your help in advance, -- 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: What is the command line commands to use UAC2 at USB client side?
Hi Jassi, On 08/19/2014 11:52 AM, Jassi Brar wrote: Its been quite some time now, but I think we designed the uac2 to rely on USB's ISO packets' rate control to send and receive audio data at announced sampling rate. I'm still thinking how that setup should have ever been possible with snd-usb-audio on the host side. snd-usb-audio prepares its capture USB ISO frames with a pre-calculated value of how many bytes per packet to expect on the capture endpoint. That value is derived from the currently configured sample rate, and if the sound card fills each of its buffers with that number of bytes or less, everything's fine. Also, each urb is resubmitted immediately after reception, and there is no delay or timing or anything. f_uac2, however, currently always completes its buffers with 512 bytes packets, which causes two problems: a) it leads to -EOVERFLOW errors on the host side, as the host doesn't expect such big packets, and b) audio is transported as fast as possible, and nothing ties the actual rate to any clock on either side. In my tests, audio was transported roughly at 3x the actual sample rate. While this works fine if only files are in the game on both sides, but once any part of the system expects the actual rate to be at least approximately in the configured range, things go wrong of course. Also, the maximum number of bytes that the host expects to receive for a packet is not part of the request communication on the USB wire. Even if we wanted, we wouldn't be able to adopt to it in order to prevent overflows on the host side. My current fix is comprised of two parts: a) set UAC_EP_CS_ATTR_FILL_MAX in the capture UAC2 endpoint, which allows the gadget to actually send packet with wMaxPacketSize bytes, and b) implement a simple timing mechanism to tie the gadget's capture stream to the configured sample rate, and send 0 bytes packets if the timing doesn't allow a full-sized packet to be sent again. These two changes fixed the functionality on a BBB/musb gadget setup, but I'd still like to understand how this could have ever worked the way it's implemented at the moment. Which OS did you test with on the host side, and what type of gadget hardware was in use? I'll send out the patches once I have confidence that I'm not missing anything essential :) Thanks, Daniel -- 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 v5 1/3] usb: gadget: f_fs: fix the redundant ep files problem
On Thu, Aug 21 2014, Robert Baldyga r.bald...@samsung.com wrote:
Up to now, when endpoint addresses in descriptors were non-consecutive,
there were created redundant files, which could cause problems in kernel,
when user tryed to read/write to them. It was result of fact that maximum
^ -- tried
endpoint address was taken as total number of endpoints in funciton.
This patch adds endpoint descriptors counting and storing their addresses
in eps_addrmap to verify their cohesion in each speed.
Endpoint address map would be also useful for further features, just like
vitual endpoint address mapping.
Signed-off-by: Robert Baldyga r.bald...@samsung.com
Acked-by: Michal Nazarewicz min...@mina86.com
@@ -1853,14 +1860,23 @@ static int __ffs_data_do_entity(enum ffs_entity_type
type,
* Strings are indexed from 1 (0 is magic ;) reserved
* for languages list or some such)
*/
- if (*valuep ffs-strings_count)
- ffs-strings_count = *valuep;
+ if (*valuep helper-ffs-strings_count)
+ helper-ffs-strings_count = *valuep;
break;
case FFS_ENDPOINT:
- /* Endpoints are indexed from 1 as well. */
- if ((*valuep USB_ENDPOINT_NUMBER_MASK) ffs-eps_count)
- ffs-eps_count = (*valuep USB_ENDPOINT_NUMBER_MASK);
+ d = (void *)desc;
+ helper-eps_count++;
+ if (helper-eps_count = 15)
+ return -EINVAL;
+ if (!helper-ffs-eps_count !helper-ffs-interfaces_count)
I'd check helper-ffs-eps_count only. helper-ffs-interfaces_count is
zero only because endpoints and interfaces are interpret at the same
time, but otherwise the interfaces_count is unrelated to what we're
doing here.
Also, perhaps adding a comment describing what !helper-ffs-eps_count
means makes sense here.
+ helper-ffs-eps_addrmap[helper-eps_count] =
+ d-bEndpointAddress;
+ else if (helper-ffs-eps_count helper-eps_count)
+ return -EINVAL;
Doesn't this duplicate check in __ffs_data_got_descs?
+ else if (helper-ffs-eps_addrmap[helper-eps_count] !=
+ d-bEndpointAddress)
+ return -EINVAL;
break;
}
@@ -2101,13 +2118,29 @@ static int __ffs_data_got_descs(struct ffs_data *ffs,
/* Read descriptors */
raw_descs = data;
+ helper.ffs = ffs;
for (i = 0; i 3; ++i) {
if (!counts[i])
continue;
+ helper.interfaces_count = 0;
+ helper.eps_count = 0;
ret = ffs_do_descs(counts[i], data, len,
-__ffs_data_do_entity, ffs);
+__ffs_data_do_entity, helper);
if (ret 0)
goto error;
+ if (!ffs-eps_count !ffs-interfaces_count) {
+ ffs-eps_count = helper.eps_count;
+ ffs-interfaces_count = helper.interfaces_count;
+ } else {
+ if (ffs-eps_count != helper.eps_count) {
+ ret = -EINVAL;
+ goto error;
+ }
+ if (ffs-interfaces_count != helper.interfaces_count) {
+ ret = -EINVAL;
+ goto error;
+ }
+ }
data += ret;
len -= ret;
}
@@ -2342,9 +2375,18 @@ static void ffs_event_add(struct ffs_data *ffs,
spin_unlock_irqrestore(ffs-ev.waitq.lock, flags);
}
-
/* Bind/unbind USB function hooks
***/
+static int ffs_ep_addr2idx(struct ffs_data *ffs, u8 endpoint_address)
+{
+ int i;
+
+ for (i = 1; i 15; ++i)
+ for (i = 1; i ARRAY_SIZE(ffs-eps_addrmap); ++i)
+ if (ffs-eps_addrmap[i] == endpoint_address)
+ return i;
+ return -ENOENT;
+}
+
static int __ffs_func_bind_do_descs(enum ffs_entity_type type, u8 *valuep,
struct usb_descriptor_header *desc,
void *priv)
--
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o
..o | Computer Science, Michał “mina86” Nazarewicz(o o)
ooo +--m...@google.com--xmpp:min...@jabber.org--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 v5 2/3] usb: gadget: f_fs: add ioctl returning ep descriptor
On Thu, Aug 21 2014, Robert Baldyga r.bald...@samsung.com wrote:
This patch introduces ioctl named FUNCTIONFS_ENDPOINT_DESC, which
returns endpoint descriptor to userspace. It works only if function
is active.
Signed-off-by: Robert Baldyga r.bald...@samsung.com
With the change described below:
Acked-by: Michal Nazarewicz min...@mina86.com
---
drivers/usb/gadget/function/f_fs.c | 21 +
include/uapi/linux/usb/functionfs.h | 6 ++
2 files changed, 27 insertions(+)
diff --git a/drivers/usb/gadget/function/f_fs.c
b/drivers/usb/gadget/function/f_fs.c
index 8096f22..ac7b16d 100644
--- a/drivers/usb/gadget/function/f_fs.c
+++ b/drivers/usb/gadget/function/f_fs.c
@@ -1032,6 +1032,27 @@ static long ffs_epfile_ioctl(struct file *file,
unsigned code,
case FUNCTIONFS_ENDPOINT_REVMAP:
ret = epfile-ep-num;
break;
+ case FUNCTIONFS_ENDPOINT_DESC:
+ {
+ int desc_idx;
+ struct usb_endpoint_descriptor *desc;
+
+ switch (epfile-ffs-gadget-speed) {
+ case USB_SPEED_SUPER:
+ desc_idx = 2;
+ break;
+ case USB_SPEED_HIGH:
+ desc_idx = 1;
+ break;
+ default:
+ desc_idx = 0;
+ }
+ desc = epfile-ep-descs[desc_idx];
+ ret = copy_to_user((void *)value, desc, sizeof(*desc));
This is called under a spin lock, so nope… The simplest will be to just
unlock prior to copying and then return instead of breaking from the switch:
+ struct usb_endpoint_descriptor desc;
…
+ desc = *epfile-ep-descs[desc_idx];
+ spin_unlock_irq(epfile-ffs-eps_lock);
+ ret = copy_to_user((void *)value, desc, sizeof(desc));
+ return ret ? -EFAULT : 0;
+ if (ret)
+ ret = -EFAULT;
+ break;
+ }
default:
ret = -ENOTTY;
}
--
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o
..o | Computer Science, Michał “mina86” Nazarewicz(o o)
ooo +--m...@google.com--xmpp:min...@jabber.org--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 v5 3/3] usb: gadget: f_fs: virtual endpoint address mapping
On Thu, Aug 21 2014, Robert Baldyga r.bald...@samsung.com wrote: This patch introduces virtual endpoint address mapping. It separates function logic form physical endpoint addresses making it more hardware independent. Following modifications changes user space API, so to enable them user have to switch on the FUNCTIONFS_VIRTUAL_ADDR flag in descriptors. Endpoints are now refered using virtual endpoint addresses chosen by user in endpoint descpriptors. This applies to each context when endpoint address can be used: - when accessing endpoint files in FunctionFS filesystemi (in file name), - in setup requests directed to specific endpoint (in wIndex field), - in descriptors returned by FUNCTIONFS_ENDPOINT_DESC ioctl. In endpoint file names the endpoint address number is formatted as double-digit hexadecimal value (ep%02x) which has few advantages - it is easy to parse, allows to easly recognize endpoint direction basing on its name (IN endpoint number starts with digit 8, and OUT with 0) which can be useful for debugging purpose, and it makes easier to introduce further features allowing to use each endpoint number in both directions to have more endpoints available for function if hardware supports this (for example we could have ep01 which is endpoint 1 with OUT direction, and ep81 which is endpoint 1 with IN direction). Physical endpoint address can be still obtained using ioctl named FUNCTIONFS_ENDPOINT_REVMAP, but now it's not neccesary to handle USB transactions properly. Signed-off-by: Robert Baldyga r.bald...@samsung.com Acked-by: Michal Nazarewicz min...@mina86.com -- Best regards, _ _ .o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o ..o | Computer Science, Michał “mina86” Nazarewicz(o o) ooo +--m...@google.com--xmpp:min...@jabber.org--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] HID: usbhid: add usb_clear_halt determination for next hid_start_in
hi Alan:
I originally tried using usb_reset_device, and it caused a deadlock:
Unplug the HID device.
I/O error occurs. hid_io_error schedules reset_work.
The reset_work callback routine is hid_reset. It calls
usb_reset_device.
The reset fails because the device is gone. At the end of the
reset, hid_post_reset is called.
hid_post_reset returns 1 because hid_get_class_descriptor
fails.
Because the post_reset routine failed, usb_reset_device calls
usb_unbind_and_rebind_marked_interfaces.
usb_unbind_and_rebind_marked_interfaces is called if config
parameter is not null,
it seems no matter post_reset routine fail or not.
That routine indirectly calls usbhid_disconnect.
Why that routine, usb_reset_device, will call usbhid_disconnect?
No matter port reset success or fail, usbhid_disconnect should not be
called except that did happen disconnection.
usbhid_disconnect calls usbhid_close by way of
hid_destroy_device.
below is the content of hid_destroy and hid_remove_device, but I
cannot find where usbhid_close be called by way of hid_destroy_device.
static void hid_remove_device(struct hid_device *hdev)
{
if (hdev-status HID_STAT_ADDED) {
device_del(hdev-dev);
hid_debug_unregister(hdev);
hdev-status = ~HID_STAT_ADDED;
}
kfree(hdev-dev_rdesc);
hdev-dev_rdesc = NULL;
hdev-dev_rsize = 0;
}
void hid_destroy_device(struct hid_device *hdev)
{
hid_remove_device(hdev);
put_device(hdev-dev);
}
usbhid_close calls hid_cancel_delayed_stuff.
hid_cancel_delayed_stuff calls cancel_work_sync for reset_work.
So the reset_work routine tries to cancel itself synchronously while it
is running. usb_queue_reset_device was carefully written to avoid such
deadlocks.
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: [Bug 80711] [PATCH]SG_FLAG_LUN_INHIBIT is no longer implemented and there's not way to prevent the kernel from using the 2nd cdb byte for the LUN
On Fri, Aug 22, 2014 at 01:29:32PM -0400, Alan Stern wrote: Other than this, I'm fine with the code ... you can add the acked by from me when we resolve the above question. Okay. It's true that this issue is only tangentially related to the main point of the patch. It could be removed and addressed later. Just make it a separate patch and send it along.. -- 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: [linux-usb] USB Gadget drivers Windows 7/8 support and .bAlternateSetting in interface descriptor
On 08/22/2014 04:43 AM, Xuebing Wang wrote:
static inline bool gadget_supports_altsettings(struct usb_gadget *gadget)
{
/* PXA 21x/25x/26x has no altsettings at all */
if (gadget_is_pxa(gadget))
return false;
/* PXA 27x and 3xx have *broken* altsetting support */
if (gadget_is_pxa27x(gadget))
return false;
/* Everything else is *presumably* fine ... */
return true;
}
Hmm. On hardware without altsetting support, isochronous endpoints
cannot be used. I wonder whether the gadget core should loudly complain
if it detects such a situation.
This is what the USB spec says in 5.6.3:
All device default interface settings must not include any isochronous
endpoints with non-zero data payload sizes (specified via
wMaxPacketSize in the endpoint descriptor). Alternate interface
settings may specify non-zero data payload sizes for isochronous
endpoints.
Daniel
--
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: some question about unbind and rebind usb interfaces
On Sun, 24 Aug 2014, vichy wrote: hi all: below patch introduce unbind and rebind interfaces during usb reset https://lists.ubuntu.com/archives/kernel-team/2014-April/042177.html If a driver claims additional interfaces, the claim may fail because the old binding instance may still own the additional interface when the new instance tries to claim it. After usb_reset_device, the whole enumeration will run again, No, only part of the enumeration. The kernel does read the device and config descriptors again. But if the reset succeeded, the kernel doesn't carry out any of the other parts of enumeration. why this patch say the previous solution will be fail to claim additional interface? Suppose a driver claims interfaces 0 and 1, and then they have to be unbound and rebound. The old code would unbind interface 0, then rebind it, then unbind interface 1, and then rebind it. Suppose the driver's probe routine for interface 0 tries to claim interface 1? The probe routine runs when interface 0 is rebound. At that time interface 1 hasn't been unbound yet. Since interface 1 is still owned, the driver will not be able to claim it. On the other hand, the new code will unbind interface 0, then unbind interface 1, then rebind interface 0, and then rebind interface 1. Now if the driver's probe routine for interface 0 tries to claim interface 1, the claim will succeed because interface has already been unbound. 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 1/1] HID: usbhid: add usb_clear_halt determination for next hid_start_in
On Sun, 24 Aug 2014, vichy wrote:
hi Alan:
I originally tried using usb_reset_device, and it caused a deadlock:
Unplug the HID device.
I/O error occurs. hid_io_error schedules reset_work.
The reset_work callback routine is hid_reset. It calls
usb_reset_device.
The reset fails because the device is gone. At the end of the
reset, hid_post_reset is called.
hid_post_reset returns 1 because hid_get_class_descriptor
fails.
Because the post_reset routine failed, usb_reset_device calls
usb_unbind_and_rebind_marked_interfaces.
usb_unbind_and_rebind_marked_interfaces is called if config
parameter is not null,
it seems no matter post_reset routine fail or not.
Yes, that's right. I should have said: Because the post_reset routine
failed, usb_unbind_and_rebind_marked_interfaces indirectly calls
usbhid_disconnect.
That routine indirectly calls usbhid_disconnect.
Why that routine, usb_reset_device, will call usbhid_disconnect?
No matter port reset success or fail, usbhid_disconnect should not be
called except that did happen disconnection.
usbhid_disconnect gets called when the driver is unbound, regardless of
whether the device was unplugged. The kernel unbinds a driver when a
device is reset but the driver isn't able to handle the reset.
usbhid_disconnect calls usbhid_close by way of
hid_destroy_device.
below is the content of hid_destroy and hid_remove_device, but I
cannot find where usbhid_close be called by way of hid_destroy_device.
static void hid_remove_device(struct hid_device *hdev)
{
if (hdev-status HID_STAT_ADDED) {
device_del(hdev-dev);
hid_debug_unregister(hdev);
hdev-status = ~HID_STAT_ADDED;
}
kfree(hdev-dev_rdesc);
hdev-dev_rdesc = NULL;
hdev-dev_rsize = 0;
}
void hid_destroy_device(struct hid_device *hdev)
{
hid_remove_device(hdev);
put_device(hdev-dev);
}
I don't remember the entire call chain. It was pretty long.
hid_destroy_device calls hid_remove_device, which calls device_del,
which calls lots of other things. If you really want to see all the
details, put a dump_stack() call in usbhid_close and examine what it
prints in the kernel log when you unplug an HID device.
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 1/4] usbip: move usbip userspace code out of staging
On Tue, Aug 19, 2014 at 9:30 PM, Valentina Manea valentina.mane...@gmail.com wrote: At this point, USB/IP userspace code is fully functional and can be moved out of staging. Signed-off-by: Valentina Manea valentina.mane...@gmail.com Bumping this in case Greg missed the patch series. Valentina -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 4/7] usb: gadget: gadgetfs: add reset API at usb_gadget_driver
Add reset API at usb_gadget_driver
Signed-off-by: Peter Chen peter.c...@freescale.com
---
drivers/usb/gadget/legacy/inode.c | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/legacy/inode.c
b/drivers/usb/gadget/legacy/inode.c
index 2e4ce77..337340d 100644
--- a/drivers/usb/gadget/legacy/inode.c
+++ b/drivers/usb/gadget/legacy/inode.c
@@ -1733,7 +1733,7 @@ enomem:
}
static void
-gadgetfs_disconnect (struct usb_gadget *gadget)
+__gadgetfs_disconnect(struct usb_gadget *gadget)
{
struct dev_data *dev = get_gadget_data (gadget);
unsigned long flags;
@@ -1751,6 +1751,19 @@ exit:
}
static void
+gadgetfs_disconnect(struct usb_gadget *gadget)
+{
+ __gadgetfs_disconnect(gadget);
+ usb_gadget_disconnect(gadget);
+}
+
+static void
+gadgetfs_reset(struct usb_gadget *gadget)
+{
+ __gadgetfs_disconnect(gadget);
+}
+
+static void
gadgetfs_suspend (struct usb_gadget *gadget)
{
struct dev_data *dev = get_gadget_data (gadget);
@@ -1776,6 +1789,7 @@ static struct usb_gadget_driver gadgetfs_driver = {
.unbind = gadgetfs_unbind,
.setup = gadgetfs_setup,
.disconnect = gadgetfs_disconnect,
+ .reset = gadgetfs_reset,
.suspend= gadgetfs_suspend,
.driver = {
--
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
[RFC PATCH 2/7] usb: gadget: composite: add reset API at usb_gadget_driver
Add reset API at usb_gadget_driver, and export it for other driver
use (eg, configfs).
Signed-off-by: Peter Chen peter.c...@freescale.com
---
drivers/usb/gadget/composite.c | 13 -
include/linux/usb/composite.h |1 +
2 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/composite.c b/drivers/usb/gadget/composite.c
index 6935a82..30ad3d5 100644
--- a/drivers/usb/gadget/composite.c
+++ b/drivers/usb/gadget/composite.c
@@ -1775,7 +1775,7 @@ done:
return value;
}
-void composite_disconnect(struct usb_gadget *gadget)
+static void __composite_disconnect(struct usb_gadget *gadget)
{
struct usb_composite_dev*cdev = get_gadget_data(gadget);
unsigned long flags;
@@ -1791,6 +1791,16 @@ void composite_disconnect(struct usb_gadget *gadget)
spin_unlock_irqrestore(cdev-lock, flags);
}
+void composite_disconnect(struct usb_gadget *gadget)
+{
+ __composite_disconnect(gadget);
+ usb_gadget_disconnect(gadget);
+}
+
+void composite_reset(struct usb_gadget *gadget)
+{
+ __composite_disconnect(gadget);
+}
/*-*/
static ssize_t suspended_show(struct device *dev, struct device_attribute
*attr,
@@ -2073,6 +2083,7 @@ static const struct usb_gadget_driver
composite_driver_template = {
.unbind = composite_unbind,
.setup = composite_setup,
+ .reset = composite_reset,
.disconnect = composite_disconnect,
.suspend= composite_suspend,
diff --git a/include/linux/usb/composite.h b/include/linux/usb/composite.h
index c330f5e..5e927d1 100644
--- a/include/linux/usb/composite.h
+++ b/include/linux/usb/composite.h
@@ -501,6 +501,7 @@ extern int usb_string_ids_n(struct usb_composite_dev *c,
unsigned n);
extern void composite_disconnect(struct usb_gadget *gadget);
extern int composite_setup(struct usb_gadget *gadget,
const struct usb_ctrlrequest *ctrl);
+extern void composite_reset(struct usb_gadget *gadget);
/*
* Some systems will need runtime overrides for the product identifiers
--
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
[RFC PATCH 5/7] usb: gadget: dbgp: add reset API at usb_gadget_driver
Add reset API at usb_gadget_driver
Signed-off-by: Peter Chen peter.c...@freescale.com
---
drivers/usb/gadget/legacy/dbgp.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/legacy/dbgp.c b/drivers/usb/gadget/legacy/dbgp.c
index 986fc51..b34140d 100644
--- a/drivers/usb/gadget/legacy/dbgp.c
+++ b/drivers/usb/gadget/legacy/dbgp.c
@@ -209,7 +209,7 @@ fail_1:
}
#endif
-static void dbgp_disconnect(struct usb_gadget *gadget)
+static void __dbgp_disconnect(struct usb_gadget *gadget)
{
#ifdef CONFIG_USB_G_DBGP_PRINTK
dbgp_disable_ep();
@@ -218,6 +218,17 @@ static void dbgp_disconnect(struct usb_gadget *gadget)
#endif
}
+static void dbgp_disconnect(struct usb_gadget *gadget)
+{
+ __dbgp_disconnect(gadget);
+ usb_gadget_disconnect(gadget);
+}
+
+static void dbgp_reset(struct usb_gadget *gadget)
+{
+ __dbgp_disconnect(gadget);
+}
+
static void dbgp_unbind(struct usb_gadget *gadget)
{
#ifdef CONFIG_USB_G_DBGP_SERIAL
@@ -408,6 +419,7 @@ static __refdata struct usb_gadget_driver dbgp_driver = {
.bind = dbgp_bind,
.unbind = dbgp_unbind,
.setup = dbgp_setup,
+ .reset = dbgp_reset,
.disconnect = dbgp_disconnect,
.driver = {
.owner = THIS_MODULE,
--
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
[RFC PATCH 0/7] usb: gadget: add reset API at usb_gadget_driver
Hi Felipe Alan, It is the follow-up for: http://www.spinics.net/lists/linux-usb/msg112193.html This patchset adds reset API at usb_gadget_driver, the UDC driver can call it at bus_reset handler instead of calling disconnect. The benefits of this patchset are: - We can let the gadget driver do different things for bus reset. and host is disconnected, eg, whether pull down dp or not. - Match kernel doc for disconnect API, it says it is invoked when the host is disconnected. - Will be more match for the real things the gadget driver does for connect and disconnect, when we introduce connect API later. The reason for I mark RFC is I don't add the modification for mass UDC driver changes, if you consider this patchset is ok, I will add them without RFC later. Peter Chen (7): usb: gadget: add reset API at usb_gadget_driver usb: gadget: composite: add reset API at usb_gadget_driver usb: gadget: configfs: add reset API at usb_gadget_driver usb: gadget: gadgetfs: add reset API at usb_gadget_driver usb: gadget: dbgp: add reset API at usb_gadget_driver usb: gadget: udc-core: delete usb_gadget_disconnect at usb_gadget_remove_driver usb: gadget: udc-core: call gadget driver's disconnect at soft disconnect drivers/usb/gadget/composite.c| 13 - drivers/usb/gadget/configfs.c |1 + drivers/usb/gadget/legacy/dbgp.c | 14 +- drivers/usb/gadget/legacy/inode.c | 16 +++- drivers/usb/gadget/udc/udc-core.c |3 +-- include/linux/usb/composite.h |1 + include/linux/usb/gadget.h|2 ++ 7 files changed, 45 insertions(+), 5 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
[RFC PATCH 1/7] usb: gadget: add reset API at usb_gadget_driver
Adding reset API for UDC bus reset handler is useful for below
two issues.
Current disconnect API at usb_gadget_driver is also invoked at
udc's bus reset handler, but the document says it is invoked when
the host is disconnected.
Besides, we may expect the gadget_driver to do different things
for host sends bus reset and host disconnects gadget, eg, we don't
want to pull down dp after bus reset, but we may want it after
disconnection.
Signed-off-by: Peter Chen peter.c...@freescale.com
---
include/linux/usb/gadget.h |2 ++
1 file changed, 2 insertions(+)
diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
index c3a6185..0516ac5 100644
--- a/include/linux/usb/gadget.h
+++ b/include/linux/usb/gadget.h
@@ -816,6 +816,7 @@ static inline int usb_gadget_disconnect(struct usb_gadget
*gadget)
* Called in a context that permits sleeping.
* @suspend: Invoked on USB suspend. May be called in_interrupt.
* @resume: Invoked on USB resume. May be called in_interrupt.
+ * @reset: Invoked on USB bus reset. Should be called in_interrupt.
* @driver: Driver model state for this driver.
*
* Devices are disabled till a gadget driver successfully bind()s, which
@@ -873,6 +874,7 @@ struct usb_gadget_driver {
void(*disconnect)(struct usb_gadget *);
void(*suspend)(struct usb_gadget *);
void(*resume)(struct usb_gadget *);
+ void(*reset)(struct usb_gadget *);
/* FIXME support safe rmmod */
struct device_driverdriver;
--
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
[RFC PATCH 3/7] usb: gadget: configfs: add reset API at usb_gadget_driver
Add reset API at usb_gadget_driver
Signed-off-by: Peter Chen peter.c...@freescale.com
---
drivers/usb/gadget/configfs.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/gadget/configfs.c b/drivers/usb/gadget/configfs.c
index 811c2c7..8fe33b4 100644
--- a/drivers/usb/gadget/configfs.c
+++ b/drivers/usb/gadget/configfs.c
@@ -1450,6 +1450,7 @@ static const struct usb_gadget_driver
configfs_driver_template = {
.unbind = configfs_composite_unbind,
.setup = composite_setup,
+ .reset = composite_reset,
.disconnect = composite_disconnect,
.max_speed = USB_SPEED_SUPER,
--
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
[RFC PATCH 7/7] usb: gadget: udc-core: call gadget driver's disconnect at soft disconnect
We have moved usb_gadget_disconnect to individual gadget driver's
disconnect, besides, it is suitable to call gadget driver's disconnect
before stopping udc, so using udc-driver-disconnect instead of
usb_gadget_disconnect at soft disconnect.
Signed-off-by: Peter Chen peter.c...@freescale.com
---
drivers/usb/gadget/udc/udc-core.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/udc/udc-core.c
b/drivers/usb/gadget/udc/udc-core.c
index ddc996da..ff94e94 100644
--- a/drivers/usb/gadget/udc/udc-core.c
+++ b/drivers/usb/gadget/udc/udc-core.c
@@ -461,7 +461,7 @@ static ssize_t usb_udc_softconn_store(struct device *dev,
usb_gadget_udc_start(udc-gadget, udc-driver);
usb_gadget_connect(udc-gadget);
} else if (sysfs_streq(buf, disconnect)) {
- usb_gadget_disconnect(udc-gadget);
+ udc-driver-disconnect(udc-gadget);
usb_gadget_udc_stop(udc-gadget, udc-driver);
} else {
dev_err(dev, unsupported command '%s'\n, buf);
--
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
[RFC PATCH 6/7] usb: gadget: udc-core: delete usb_gadget_disconnect at usb_gadget_remove_driver
The usb_gadget_disconnect will be called at individual gadget driver's disconnect, so delete it at udc core. Signed-off-by: Peter Chen peter.c...@freescale.com --- drivers/usb/gadget/udc/udc-core.c |1 - 1 file changed, 1 deletion(-) diff --git a/drivers/usb/gadget/udc/udc-core.c b/drivers/usb/gadget/udc/udc-core.c index b0d9817..ddc996da 100644 --- a/drivers/usb/gadget/udc/udc-core.c +++ b/drivers/usb/gadget/udc/udc-core.c @@ -283,7 +283,6 @@ static void usb_gadget_remove_driver(struct usb_udc *udc) kobject_uevent(udc-dev.kobj, KOBJ_CHANGE); - usb_gadget_disconnect(udc-gadget); udc-driver-disconnect(udc-gadget); udc-driver-unbind(udc-gadget); usb_gadget_udc_stop(udc-gadget, NULL); -- 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
Good News
Dear Sir/Madam, I saw your email address during the course of my research today. My name is Bill William Groner my wife and I won a Jackpot Lottery of $50 Million Dollars in December 2013, we are donating the sum of $1 million Dollars to 6 lucky individual all over the world as part of our charity project and if you received this email then you are one of the luck recipients and all you have to do is get back to us with your details so we can forward it directly to the payout bank. Please note that you have to contact us via our private email for more information (b.a.groo...@foxmail.com) You can verify this by visiting the web pages below. https://ca.news.yahoo.com/keep-secret-edmonton-couple-reveals-50m-lotto-win- 200041218.html http://cnews.canoe.ca/CNEWS/Canada/2014/07/21/21823476.html Good luck, Bill William And Andrean Groner Email: b.a.groo...@foxmail.com -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH net-next 4/4] r8152: support firmware files
Francois Romieu [mailto:rom...@fr.zoreil.com]
[...]
+static void rtl_request_firmware(struct r8152 *tp)
+{
+ char *fw_name = NULL;
+
+ if (tp-rtl_fw.fw)
+ goto out_request;
+
+ switch (tp-version) {
+ case RTL_VER_01:
+ fw_name = rtl_nic/rtl8152-1.fw;
+ break;
+ case RTL_VER_02:
+ fw_name = rtl_nic/rtl8152-2.fw;
+ break;
+ case RTL_VER_03:
+ fw_name = rtl_nic/rtl8153-1.fw;
+ break;
+ case RTL_VER_04:
+ fw_name = rtl_nic/rtl8153-2.fw;
+ break;
+ case RTL_VER_05:
+ fw_name = rtl_nic/rtl8153-3.fw;
+ break;
The driver should use MODULE_FIRMWARE() for these files.
Oops. I would fix this. Thanks.
Best Regards,
Hayes
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH net-next 0/4] r8152: firmware support
From: David Miller [mailto:da...@davemloft.net] [...] You haven't told us why you need to do this. These are just programming registers in the chip, and I see no reason to not keep these in the driver with real code. I'm not applying this series, you haven't explained what is happening here and the reason for doing so. Ironically, that's exactly what you are supposed to provide in this 0/4 header email. The nic has the MCU inside which is used to fix the PHY, MAC, and some behavior of the USB device. Each parts have different methods of updating the firmware by accessing the registers. The firmware files are used to deal with the processes, so I need some functions to parse the firmware files to update the fimrware code. I would resend these. Sorry. Best Regards, Hayes -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-next 0/4] r8152: firmware support
From: Hayes Wang hayesw...@realtek.com Date: Mon, 25 Aug 2014 03:43:04 + From: David Miller [mailto:da...@davemloft.net] [...] You haven't told us why you need to do this. These are just programming registers in the chip, and I see no reason to not keep these in the driver with real code. I'm not applying this series, you haven't explained what is happening here and the reason for doing so. Ironically, that's exactly what you are supposed to provide in this 0/4 header email. The nic has the MCU inside which is used to fix the PHY, MAC, and some behavior of the USB device. Each parts have different methods of updating the firmware by accessing the registers. The firmware files are used to deal with the processes, so I need some functions to parse the firmware files to update the fimrware code. That still doesn't convince me. The functions I see you removing are just programming a set of registers in some way. And the firmware that is replacing those functions is just going to be causing the same register writes, just even more obfuscated than it is now. You should keep the C functions which document and show clearly what is being programmed in each chip. Don't hide register programming behind firmware files, please. -- 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: ehci: using wIndex + 1 for hub port
On Tue, Aug 5, 2014 at 8:28 AM, Peter Chen peter.c...@freescale.com wrote:
The roothub's index per controller is from 0, but the hub port index per hub
is from 1, this patch fixes can't find device at roohub problem for
connecting
test fixture at roohub when do USB-IF Embedded Host High-Speed Electrical
Test.
This patch is for v3.12+.
Cc: sta...@vger.kernel.org
Signed-off-by: Peter Chen peter.c...@freescale.com
Acked-by: Alan Stern st...@rowland.harvard.edu
---
Changes for v2:
- Fix more than 80-column per line problem
- Add information that this patch is available for stable tree from v3.12
drivers/usb/host/ehci-hub.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/host/ehci-hub.c b/drivers/usb/host/ehci-hub.c
index cc305c7..6130b75 100644
--- a/drivers/usb/host/ehci-hub.c
+++ b/drivers/usb/host/ehci-hub.c
@@ -1230,7 +1230,7 @@ int ehci_hub_control(
if (selector == EHSET_TEST_SINGLE_STEP_SET_FEATURE) {
spin_unlock_irqrestore(ehci-lock, flags);
retval = ehset_single_step_set_feature(hcd,
-
wIndex);
+ wIndex + 1);
spin_lock_irqsave(ehci-lock, flags);
break;
}
--
Hi Greg, Does this patch will be in your usb-linus branch? I haven't found it.
--
BR,
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
