Re: [PATCH 08/10] usb: add usb port auto power off mechanism
On 2012年12月06日 23:43, Alan Stern wrote: > On Thu, 6 Dec 2012, Lan Tianyu wrote: > >> Hi Alan: >> Doing port_dev->power_on = true in usb_hub_set_port_power() just after >> set PORT_POWER feature will cause device to be disconnected. If user set >> PM Qos NO_POWER_OFF flag after the device was power off, the port would >> be power on and do port_dev->power_on = true. But the port connect >> change event couldn't be ignored and the device would be disconnected. > > The problem is that you chose a bad name for this flag. Does > "power_on" mean that the power _is_ on, that the power _was_ on, that > the power _will be_ on, or that the power _should be_ on? > > Maybe you really need two flags. Do whatever is best; I'm sure you can > figure out a good scheme. Yeah. Two flags maybe good. In this situation, it should be call "power_is_on", right? power_is_on can be used to avoid to sending redundant PORT_POWER request. The other flag is dedicated to prevent device from being disconnected. Something like hub->busy_bits. We can can "child_busy", I am not very good at giving a name. So I'd like to see your opinion. :) > > Alan Stern > -- Best regards Tianyu Lan -- 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 v5 1/3] usb: composite: add make_group and add_function operations
Using configfs to create/configure a usb gadget requires
providing a method to create config group for a usb function
and a wrapper for usb_add_function.
Signed-off-by: Andrzej Pietrasiewicz
Signed-off-by: Kyungmin Park
---
include/linux/usb/composite.h |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/include/linux/usb/composite.h b/include/linux/usb/composite.h
index e84c754..cfd9209 100644
--- a/include/linux/usb/composite.h
+++ b/include/linux/usb/composite.h
@@ -39,6 +39,7 @@
#include
#include
#include
+#include
/*
* USB function drivers should return USB_GADGET_DELAYED_STATUS if they
@@ -147,6 +148,11 @@ struct usb_function {
* Related: unbind() may kfree() but bind() won't...
*/
+ struct config_group *(*make_group)(struct config_group *parent,
+ const char *name);
+ int (*add_function)(struct usb_configuration *c, struct usb_function *f,
+ struct config_item *item, void *data);
+
/* configuration management: bind/unbind */
int (*bind)(struct usb_configuration *,
struct usb_function *);
--
1.7.0.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
[RFC v5 0/3] configfs integration
Dear All, This is the fifth version of what used to be called "USB Functions Gadget". It includes changes after Michal's and Sebastian's reviews - thanks, guys. This is what I have been working on since June'12 and starts looking usable. As an example I ported the mass storage function, which is a nontrivial one. I am also working on adapter modules to provide the legacy interface. The general idea is like here: http://www.spinics.net/lists/linux-usb/msg74871.html but after the change of programmatic configfs folder creation the adapter needs to be changed. Naming is to be adjusted, not a big deal. This series requires 126c4896cd5ca94f5e1d77d7526870f99019ea48 fs/configfs: allow to create groups on demand and f7e4ec2ed0eddd63b93d0ca1beb45ffec6bb12b2 usb/gadget: add some infracture to register/unregister functions Example use with mass storage: $ mount -t configfs none /cfg $ cd /cfg/usb-function-gadget/ $ ls gadgets udcs $ ls udcs s3c-hsotg $ cd gadgets $ mkdir g1 $ ls g1 $ cd g1 $ ls bcdDevice functions iProductidProduct configs iManufacturer iSerialNumber idVendor $ echo Samsung > iManufacturer $ echo 12345 > iSerialNumber $ echo 0x0109 > idProduct $ echo 0x04e8 > idVendor $ cd functions $ mkdir MassStorage.0 [ 110.485345] Mass Storage Function, version: 2009/09/11 [ 110.489669] Number of LUNs=0 [ 110.491871] I/O thread pid: 2491 $ ls MassStorage.0 $ lsmod f_mass_storage $ echo 1 > MassStorage.0/luns [ 139.969099] LUN: file: (no medium) $ echo /root/file.img > MassStorage.0/lun0/file $ cd ../configs $ mkdir 0 $ ls 0 $ cd 0 $ ls configuration_numberfunctions maximum_power number_of_interfaces $ cd functions $ ln -s ../../../functions/MassStorage.0 # points to /cfg/usb_function_gadget/ # gadgets/g1/functions/MassStorage.0 $ ls MassStorage.0 $ cd ../../../ $ ln -s ../../udcs/s3c-hsotg# points to /cfg/usb_function_gadget/ # udcs/s3c-hsotg # the gadget is probed, host sees a new disk $ ls /cfg/usb-function-gadget/gadgets/g1/functions/MassStorage.0 interface00 lun0lunsstall $ ls /cfg/usb-function-gadget/gadgets/g1/functions/MassStorage.0\ /interface00 altsetting endpoint81 interface_numberinterface_subclass endpoint02 interface_class interface_protocol n_endpoints $ ls /cfg/usb-function-gadget/gadgets/g1/functions/MassStorage.0\ /interface00/endpoint02 attributes endpoint_addressintervalmax_packet_size $ rm s3c-hsotg # the gadget is removed Rebased on 3.7-rc8. v5: Changes since v4: - fixes according to Michal's and Sebastian's reviews - adapted to new directory layout as proposed by Michal and Sebastian - binding the gadget using symlink to udc - binding the functions using symlinks v4: Changes since v3: - use Sebastian's function registration framework - code cleanup and small improvements - differently squashed commits in order to show the steps v3: Changes since v2: - improved ufg_gadget_bind - some attributes have real values instead of dummy values - added interfaces and endpoints directories in configfs - added a local header file in drivers/usb/gadget Andrzej Pietrasiewicz (3): usb: composite: add make_group and add_function operations usb: gadget: Add USB Functions Gadget usb: gadget: example port of mass storage to UFG: create storage_common.h and factor out code from storage_common.c Documentation/usb/ufg.txt |2 + drivers/usb/gadget/Kconfig | 17 + drivers/usb/gadget/Makefile |8 +- drivers/usb/gadget/f_mass_storage.c | 825 - drivers/usb/gadget/f_mass_storage.h | 99 +++ drivers/usb/gadget/storage_common.c | 175 --- drivers/usb/gadget/storage_common.h | 43 ++ drivers/usb/gadget/udc-core.c | 27 +- drivers/usb/gadget/usb_functions.c | 1142 +++ drivers/usb/gadget/usb_functions.h | 188 ++ include/linux/usb/composite.h |6 + include/linux/usb/gadget.h |5 + 12 files changed, 2033 insertions(+), 504 deletions(-) create mode 100644 Documentation/usb/ufg.txt create mode 100644 drivers/usb/gadget/f_mass_storage.h create mode 100644 drivers/usb/gadget/storage_common.h create mode 100644 drivers/usb/gadget/usb_functions.c create mode 100644 drivers/usb/gadget/usb_functions.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
[RFC v5 2/3] usb: gadget: Add USB Functions Gadget
Demonstrate a USB gadget configured entirely through configfs.
Signed-off-by: Andrzej Pietrasiewicz
Signed-off-by: Kyungmin Park
---
Documentation/usb/ufg.txt |2 +
drivers/usb/gadget/Kconfig | 13 +
drivers/usb/gadget/Makefile|5 +-
drivers/usb/gadget/udc-core.c | 27 +-
drivers/usb/gadget/usb_functions.c | 1142
drivers/usb/gadget/usb_functions.h | 188 ++
include/linux/usb/gadget.h |5 +
7 files changed, 1379 insertions(+), 3 deletions(-)
create mode 100644 Documentation/usb/ufg.txt
create mode 100644 drivers/usb/gadget/usb_functions.c
create mode 100644 drivers/usb/gadget/usb_functions.h
diff --git a/Documentation/usb/ufg.txt b/Documentation/usb/ufg.txt
new file mode 100644
index 000..c4691e0
--- /dev/null
+++ b/Documentation/usb/ufg.txt
@@ -0,0 +1,2 @@
+USB Functions Gadget
+
diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig
index 14625fd..80ab9a5 100644
--- a/drivers/usb/gadget/Kconfig
+++ b/drivers/usb/gadget/Kconfig
@@ -15,6 +15,7 @@
menuconfig USB_GADGET
tristate "USB Gadget Support"
+ select USB_LIBCOMPOSITE
select NLS
help
USB is a master/slave protocol, organized with one master
@@ -521,6 +522,18 @@ choice
# this first set of drivers all depend on bulk-capable hardware.
+config USB_FG
+ tristate "USB Functions Gadget"
+ depends on CONFIGFS_FS
+ help
+ USB Functions Gadget is a device which aggregates a number of
+ USB functions. The gadget is composed by userspace through a
+ configfs interface, which enables specifying what USB
+ configurations the gadget is composed of, what USB functions
+ a USB configuration is composed of and enabling/disabling
+ the gadget.
+ For more information, see Documentation/usb/ufg.txt
+
config USB_ZERO
tristate "Gadget Zero (DEVELOPMENT)"
select USB_LIBCOMPOSITE
diff --git a/drivers/usb/gadget/Makefile b/drivers/usb/gadget/Makefile
index fef41f5..378296b 100644
--- a/drivers/usb/gadget/Makefile
+++ b/drivers/usb/gadget/Makefile
@@ -3,10 +3,11 @@
#
ccflags-$(CONFIG_USB_GADGET_DEBUG) := -DDEBUG
-obj-$(CONFIG_USB_GADGET) += udc-core.o
+obj-$(CONFIG_USB_GADGET) += udc.o
obj-$(CONFIG_USB_LIBCOMPOSITE) += libcomposite.o
libcomposite-y := usbstring.o config.o epautoconf.o
-libcomposite-y += composite.o functions.o
+libcomposite-y += composite.o
+udc-y += udc-core.o functions.o usb_functions.o
obj-$(CONFIG_USB_DUMMY_HCD)+= dummy_hcd.o
obj-$(CONFIG_USB_NET2272) += net2272.o
obj-$(CONFIG_USB_NET2280) += net2280.o
diff --git a/drivers/usb/gadget/udc-core.c b/drivers/usb/gadget/udc-core.c
index 4d90a80..5d5bf37 100644
--- a/drivers/usb/gadget/udc-core.c
+++ b/drivers/usb/gadget/udc-core.c
@@ -40,6 +40,7 @@
struct usb_udc {
struct usb_gadget_driver*driver;
struct usb_gadget *gadget;
+ struct config_group *group;
struct device dev;
struct list_headlist;
};
@@ -196,6 +197,7 @@ static void usb_udc_release(struct device *dev)
}
static const struct attribute_group *usb_udc_attr_groups[];
+
/**
* usb_add_gadget_udc - adds a new gadget to the udc class driver list
* @parent: the parent device to this udc. Usually the controller
@@ -231,6 +233,7 @@ int usb_add_gadget_udc(struct device *parent, struct
usb_gadget *gadget)
if (ret)
goto err3;
+ udc->group = udc_configfs_register(&udc->dev);
mutex_unlock(&udc_lock);
return 0;
@@ -305,6 +308,7 @@ found:
usb_gadget_remove_driver(udc);
kobject_uevent(&udc->dev.kobj, KOBJ_REMOVE);
+ udc_configfs_unregister(udc->group);
device_unregister(&udc->dev);
}
EXPORT_SYMBOL_GPL(usb_del_gadget_udc);
@@ -504,6 +508,8 @@ static int usb_udc_uevent(struct device *dev, struct
kobj_uevent_env *env)
static int __init usb_udc_init(void)
{
+ int rc = 0;
+
udc_class = class_create(THIS_MODULE, "udc");
if (IS_ERR(udc_class)) {
pr_err("failed to create udc class --> %ld\n",
@@ -512,12 +518,31 @@ static int __init usb_udc_init(void)
}
udc_class->dev_uevent = usb_udc_uevent;
- return 0;
+
+#ifdef MODULE
+ rc = ufg_init();
+ if (rc)
+ class_destroy(udc_class);
+#endif
+
+ return rc;
}
subsys_initcall(usb_udc_init);
+#ifndef MODULE
+static int __init usb_udc_init_module(void)
+{
+ if (IS_ERR(udc_class))
+ return PTR_ERR(udc_class);
+
+ return ufg_init();
+}
+module_init(usb_udc_init_module);
+#endif
+
static void __exit usb_udc_exit(void)
{
+ ufg_cleanup();
class_destroy(udc_class);
}
module_exit(usb_udc_exit);
diff --git a/drivers/usb/gadget/usb_fu
[RFC v5 3/3] usb: gadget: example port of mass storage to UFG: create storage_common.h and factor out code from storage_common.c
Signed-off-by: Andrzej Pietrasiewicz
Signed-off-by: Kyungmin Park
---
drivers/usb/gadget/Kconfig |4 +
drivers/usb/gadget/Makefile |3 +
drivers/usb/gadget/f_mass_storage.c | 825 +--
drivers/usb/gadget/f_mass_storage.h | 99 +
drivers/usb/gadget/storage_common.c | 175 +---
drivers/usb/gadget/storage_common.h | 43 ++
6 files changed, 648 insertions(+), 501 deletions(-)
create mode 100644 drivers/usb/gadget/f_mass_storage.h
create mode 100644 drivers/usb/gadget/storage_common.h
diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig
index 80ab9a5..f142db3 100644
--- a/drivers/usb/gadget/Kconfig
+++ b/drivers/usb/gadget/Kconfig
@@ -501,6 +501,9 @@ config USB_LIBCOMPOSITE
tristate
depends on USB_GADGET
+config USB_F_MASS_STORAGE
+ tristate
+
choice
tristate "USB Gadget Drivers"
default USB_ETH
@@ -524,6 +527,7 @@ choice
config USB_FG
tristate "USB Functions Gadget"
+select USB_F_MASS_STORAGE
depends on CONFIGFS_FS
help
USB Functions Gadget is a device which aggregates a number of
diff --git a/drivers/usb/gadget/Makefile b/drivers/usb/gadget/Makefile
index 378296b..536f4d6 100644
--- a/drivers/usb/gadget/Makefile
+++ b/drivers/usb/gadget/Makefile
@@ -75,3 +75,6 @@ obj-$(CONFIG_USB_G_WEBCAM)+= g_webcam.o
obj-$(CONFIG_USB_G_NCM)+= g_ncm.o
obj-$(CONFIG_USB_G_ACM_MS) += g_acm_ms.o
obj-$(CONFIG_USB_GADGET_TARGET)+= tcm_usb_gadget.o
+
+# USB Functions
+obj-$(CONFIG_USB_F_MASS_STORAGE) += f_mass_storage.o
\ No newline at end of file
diff --git a/drivers/usb/gadget/f_mass_storage.c
b/drivers/usb/gadget/f_mass_storage.c
index 5d027b3..a558f32 100644
--- a/drivers/usb/gadget/f_mass_storage.c
+++ b/drivers/usb/gadget/f_mass_storage.c
@@ -213,12 +213,14 @@
#include
#include
#include
+#include
#include
#include
#include
#include "gadget_chips.h"
+#include "usb_functions.h"
/**/
@@ -229,124 +231,11 @@
static const char fsg_string_interface[] = "Mass Storage";
#include "storage_common.c"
-
+#include "f_mass_storage.h"
/*-*/
-struct fsg_dev;
-struct fsg_common;
-
-/* FSF callback functions */
-struct fsg_operations {
- /*
-* Callback function to call when thread exits. If no
-* callback is set or it returns value lower then zero MSF
-* will force eject all LUNs it operates on (including those
-* marked as non-removable or with prevent_medium_removal flag
-* set).
-*/
- int (*thread_exits)(struct fsg_common *common);
-
- /*
-* Called prior to ejection. Negative return means error,
-* zero means to continue with ejection, positive means not to
-* eject.
-*/
- int (*pre_eject)(struct fsg_common *common,
-struct fsg_lun *lun, int num);
- /*
-* Called after ejection. Negative return means error, zero
-* or positive is just a success.
-*/
- int (*post_eject)(struct fsg_common *common,
- struct fsg_lun *lun, int num);
-};
-
-/* Data shared by all the FSG instances. */
-struct fsg_common {
- struct usb_gadget *gadget;
- struct usb_composite_dev *cdev;
- struct fsg_dev *fsg, *new_fsg;
- wait_queue_head_t fsg_wait;
-
- /* filesem protects: backing files in use */
- struct rw_semaphore filesem;
-
- /* lock protects: state, all the req_busy's */
- spinlock_t lock;
-
- struct usb_ep *ep0; /* Copy of gadget->ep0 */
- struct usb_request *ep0req;/* Copy of cdev->req */
- unsigned intep0_req_tag;
-
- struct fsg_buffhd *next_buffhd_to_fill;
- struct fsg_buffhd *next_buffhd_to_drain;
- struct fsg_buffhd *buffhds;
-
- int cmnd_size;
- u8 cmnd[MAX_COMMAND_SIZE];
-
- unsigned intnluns;
- unsigned intlun;
- struct fsg_lun *luns;
- struct fsg_lun *curlun;
-
- unsigned intbulk_out_maxpacket;
- enum fsg_state state; /* For exception handling */
- unsigned intexception_req_tag;
-
- enum data_direction data_dir;
- u32 data_size;
- u32 data_size_from_cmnd;
- u32 tag;
- u32 residue;
- u32 usb_amount_left;
-
- unsigned intcan_stall:1;
- unsigned intfree_storage_on_release:1;
- unsigned intphase_error:1;
- unsigned intsho
Re: [RFC v5 0/3] configfs integration
On 12/07/2012 10:12 AM, Andrzej Pietrasiewicz wrote: Dear All, This is the fifth version of what used to be called "USB Functions Gadget". It includes changes after Michal's and Sebastian's reviews - thanks, guys. I started slowly based coding based on feedback. Why do start over? Sebastian -- 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 v5 0/3] configfs integration
On Friday, December 07, 2012 10:15 AM Sebastian Andrzej Siewior wrote: > Subject: Re: [RFC v5 0/3] configfs integration > > On 12/07/2012 10:12 AM, Andrzej Pietrasiewicz wrote: > > Dear All, > > > > This is the fifth version of what used to be called "USB Functions > Gadget". > > It includes changes after Michal's and Sebastian's reviews - thanks, > guys. > > I started slowly based coding based on feedback. Why do start over? > > Sebastian I started in June 2012. Why do you start over? I posted it as a natural consequence of what has been done over the last 6 months and now looks usable. AP -- 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 v5 0/3] configfs integration
On 12/07/2012 11:17 AM, Andrzej Pietrasiewicz wrote: On Friday, December 07, 2012 10:15 AM Sebastian Andrzej Siewior wrote: Subject: Re: [RFC v5 0/3] configfs integration On 12/07/2012 10:12 AM, Andrzej Pietrasiewicz wrote: Dear All, This is the fifth version of what used to be called "USB Functions Gadget". It includes changes after Michal's and Sebastian's reviews - thanks, guys. I started slowly based coding based on feedback. Why do start over? Sebastian I started in June 2012. Why do you start over? I posted it as a natural consequence of what has been done over the last 6 months and now looks usable. I reviewed it a few times. It was huge, had old chunks somtimes,… You asked once what of groud work had to be done, nothing happend. We started discussing how we want the hierarchy after your last post and I didn't see much happen. *Then* I started slowly coding with a confgifs patch followed by small pieces of more code where we changed the hierarchy again. Didn't hear anything from your side. Based on what I see in your description: - the hierarchy is not as we discussed it the last time - the strings are not suggested by Alan also do make sense in my opinion. AP Sebastian -- 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
Linux USB mass storage gadget insmod error
Hi, I can build linux USB mass storage gadget. When I want to insmod it, the following errors are reported. I have the file g_mass_storage.ko, why can't I insmod the file? # ls /lib/modules/3.4.4\+/kernel/drivers/usb/gadget/ g_mass_storage.ko # insmod /lib/modules/3.4.4\+/kernel/drivers/usb/gadget/g_mass_storage.ko file=/dev/mmcblk0 insmod: can't insert '/lib/modules/3.4.4+/kernel/drivers/usb/gadget/g_mass_storage.ko': No such device thanks, victor CONFIDENTIALITY NOTE: This e-mail and any attachments may contain confidential information and may be protected by legal privilege. If you are not the intended addressee (or authorized to receive for the addressee). be aware that any disclosure, copying, distribution or use of this e-mail or any attachment is prohibited. If you have received this e-mail in error, please notify us immediately by returning it to the sender and delete this copy from your system. Thank you for your cooperation. KeyASIC Inc. -- 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 v5 0/3] configfs integration
O Friday, December 07, 2012 11:48 AM Sebastian Andrzej Siewior wrote: > On 12/07/2012 11:17 AM, Andrzej Pietrasiewicz wrote: > > On Friday, December 07, 2012 10:15 AM Sebastian Andrzej Siewior wrote: > > > >> Subject: Re: [RFC v5 0/3] configfs integration > >> > >> On 12/07/2012 10:12 AM, Andrzej Pietrasiewicz wrote: > >>> Dear All, > >>> > >>> This is the fifth version of what used to be called "USB Functions > >> Gadget". > >>> It includes changes after Michal's and Sebastian's reviews - thanks, > >> guys. > >> > >> I started slowly based coding based on feedback. Why do start over? > >> > >> Sebastian > > > > I started in June 2012. Why do you start over? > > I posted it as a natural consequence of what has been done over the > > last 6 months and now looks usable. > > I reviewed it a few times. It was huge, I am not sure if it is possible to be less than ~1KLOC, which is what it is now. > had old chunks somtimes,. So what? They were removed as you suggested. Is it the reason to start over? > You > asked once what of groud work had to be done, nothing happend. We started > discussing how we want the hierarchy after your last post and I didn't see > much happen. > *Then* I started slowly coding with a confgifs patch followed by small > pieces of more code where we changed the hierarchy again. Didn't hear > anything from your side. I've changed the hierarchy a number of times. It is not a big deal. Just the need to change the hierarchy is not a reason good enough to start over. > Based on what I see in your description: > - the hierarchy is not as we discussed it the last time I wanted it to be what Michal suggested and you agreed to. Can you be more specific? Anyway, as I said, changing the hierarchy so that functions are in this folder or that, configurations in this folder or that is a fairly easy task. Not such a great revolution so that starting from scratch were easier. > - the strings are not suggested by Alan also do make sense in my >opinion. What do you mean exactly? The need to add one more thing (language variants for strings) is not a valid reason to start over. AP -- 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 mass storage gadget insmod error
On Fri, Dec 07 2012, victor wrote: > I can build linux USB mass storage gadget. When I want to insmod it, the > following errors are reported. I have the file g_mass_storage.ko, why can't > I insmod the file? > > # ls /lib/modules/3.4.4\+/kernel/drivers/usb/gadget/ > g_mass_storage.ko > # insmod /lib/modules/3.4.4\+/kernel/drivers/usb/gadget/g_mass_storage.ko > file=/dev/mmcblk0 > insmod: can't insert > '/lib/modules/3.4.4+/kernel/drivers/usb/gadget/g_mass_storage.ko': No such > device I'm guessing that you don't have any UDCs compiled in. -- Best regards, _ _ .o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o ..o | Computer Science, Michał “mina86” Nazarewicz(o o) ooo +--ooO--(_)--Ooo-- pgpnAIiD4R06F.pgp Description: PGP signature
[Suggestion] drivers/usb/renesas_usbhs: pkt is still in use, after it was already free.
Hello Greg Kroah-Hartman:
in drivers/usb/renesas_usbhs/mod_host.c, in function usbhsh_queue_done:
get ureq from pkt, by using the macro usbhsh_pkt_to_ureq (at line 637)
pkt is the sub-object of ureq (line 73..76, line 157..158)
free ureq, by calling function usbhsh_ureq_free (at line 655)
use kfree to free ureq in function usbhsh_ureq_free (line 184..191)
originally ureq is call kzalloc in function usbhsh_ureq_alloc (line
171..179)
so pkt also free, too.
still use pkt, by calling function usbhsh_endpoint_sequence_save (at line
657)
use pkt->zero in funcion usbhsh_endpoint_sequence_save (at line 243)
I find it through code review, please help to check this suggestion whether
valid.
if it was valid:
I prefer the relative member to provide relative patch.
if can not find relative member, I should try (although it seems not a good
idea)
Regards
gchen.
73 struct usbhsh_request {
74 struct urb *urb;
75 struct usbhs_pktpkt;
76 };
77
...
157 #define usbhsh_pkt_to_ureq(p) \
158 container_of((void *)p, struct usbhsh_request, pkt)
...
163 static struct usbhsh_request *usbhsh_ureq_alloc(struct usbhsh_hpriv *hpriv,
164struct urb *urb,
165gfp_t mem_flags)
166 {
167 struct usbhsh_request *ureq;
168 struct usbhs_priv *priv = usbhsh_hpriv_to_priv(hpriv);
169 struct device *dev = usbhs_priv_to_dev(priv);
170
171 ureq = kzalloc(sizeof(struct usbhsh_request), mem_flags);
172 if (!ureq) {
173 dev_err(dev, "ureq alloc fail\n");
174 return NULL;
175 }
176
177 usbhs_pkt_init(&ureq->pkt);
178 ureq->urb = urb;
179 usbhsh_urb_to_ureq(urb) = ureq;
180
181 return ureq;
182 }
183
184 static void usbhsh_ureq_free(struct usbhsh_hpriv *hpriv,
185 struct usbhsh_request *ureq)
186 {
187 usbhsh_urb_to_ureq(ureq->urb) = NULL;
188 ureq->urb = NULL;
189
190 kfree(ureq);
191 }
...
211 static void usbhsh_endpoint_sequence_save(struct usbhsh_hpriv *hpriv,
212 struct urb *urb,
213 struct usbhs_pkt *pkt)
214 {
215 int len = urb->actual_length;
216 int maxp = usb_endpoint_maxp(&urb->ep->desc);
217 int t = 0;
218
219 /* DCP is out of sequence control */
220 if (usb_pipecontrol(urb->pipe))
221 return;
222
223 /*
224 * renesas_usbhs pipe has a limitation in a number.
225 * So, driver should re-use the limited pipe for each
device/endpoint.
226 * DATA0/1 sequence should be saved for it.
227 * see [image of mod_host]
228 * [HARDWARE LIMITATION]
229 */
230
231 /*
232 * next sequence depends on actual_length
233 *
234 * ex) actual_length = 1147, maxp = 512
235 * data0 : 512
236 * data1 : 512
237 * data0 : 123
238 * data1 is the next sequence
239 */
240 t = len / maxp;
241 if (len % maxp)
242 t++;
243 if (pkt->zero)
244 t++;
245 t %= 2;
246
247 if (t)
248 usb_dotoggle(urb->dev,
249 usb_pipeendpoint(urb->pipe),
250 usb_pipeout(urb->pipe));
251 }
...
635 static void usbhsh_queue_done(struct usbhs_priv *priv, struct usbhs_pkt
*pkt)
636 {
637 struct usbhsh_request *ureq = usbhsh_pkt_to_ureq(pkt);
638 struct usbhsh_hpriv *hpriv = usbhsh_priv_to_hpriv(priv);
639 struct usb_hcd *hcd = usbhsh_hpriv_to_hcd(hpriv);
640 struct urb *urb = ureq->urb;
641 struct device *dev = usbhs_priv_to_dev(priv);
642 int status = 0;
643
644 dev_dbg(dev, "%s\n", __func__);
645
646 if (!urb) {
647 dev_warn(dev, "pkt doesn't have urb\n");
648 return;
649 }
650
651 if (!usbhsh_is_running(hpriv))
652 status = -ESHUTDOWN;
653
654 urb->actual_length = pkt->actual;
655 usbhsh_ureq_free(hpriv, ureq);
656
657 usbhsh_endpoint_sequence_save(hpriv, urb, pkt);
658 usbhsh_pipe_detach(hpriv, usbhsh_ep_to_uep(urb->ep));
659
660 usb_hcd_unlink_urb_from_ep(hcd, urb);
661 usb_hcd_giveback_urb(hcd, urb, status);
662 }
--
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: Random MAC address from smsc75xx: How to permanently set?
> -Original Message- > From: Jassi Brar [mailto:jassisinghb...@gmail.com] > Sent: Thursday, December 06, 2012 10:21 PM > Subject: Re: Random MAC address from smsc75xx: How to permanently set? > > On Fri, Dec 7, 2012 at 12:21 AM, Dan Williams wrote: > > On Thu, 2012-12-06 at 12:44 -0600, Dan Williams wrote: > >> On Thu, 2012-12-06 at 18:35 +, Cunningham, Robert wrote: > >> > I'm trying to bring up an OMAP4 system based on Variscite's OM44 > module running Linaro's Ubuntu Precise in a headless configuration. The > system contains two SMSC LAN7500 USB-GigE chips (not dongles), both of > which are fully functional. > >> > > >> > The GigE chips don't have EEPROMS, so no permanent MAC addresses > >> > can be assigned in hardware. As expected, the smsc75xx driver > >> > assigns a random MAC address when the interface is discovered and > >> > initialized. However, we need to provide consistent MAC addresses > >> > on these interfaces. (Yes, we could respin the board to add > >> > EEPROMS, but that's a last, and expensive, resort.) > >> > > >> > After the system boots, I'd like to change the MAC addresses to specific > values. While there are multiple ways to do this (using commands such as > ifconfig, ip, macchanger, and others), it seems the updated MAC address is > always overridden when I do "ifconfig ethX up", which causes yet another > different random MAC address to be created and assigned. Simply repeating > ifconfig up/down causes an endless list of random MAC addresses to be > generated. > >> > > >> > I created a udev rule that I hoped would handle the situation, but it is > also overridden: > >> > /etc/udev/rules.d/99-mac-address.rules: > >> > SUBSYSTEM=="net", KERNEL=="eth0", RUN+="/sbin/ip link set dev > %k address XX:XX:XX:XX:XX:00" > >> > SUBSYSTEM=="net", KERNEL=="eth1", RUN+="/sbin/ip link set dev > %k address XX:XX:XX:XX:XX:01" > >> > > >> > For a single interface, I can use u-boot variables or kernel boot > arguments, but they seem to work only for the first interface, and I have > two. > >> > >> Just matching on interface name won't guarantee that you get the same > >> MAC assigned to the same physical interface each time you boot. You > >> can't rely on bus probing order. What you really want to do is > >> enhance the udev rule to match the network interfaces based on stuff > >> like PCI bus address, SDIO details, or whatever bus type the > >> interfaces are hanging off. If the device is a virtual one because > >> it's on-chip or something like that, then you're at the mercy of the > >> driver's probing code because it probably doesn't expose any unique > >> details of the device. This all doesn't have anything to do with the > >> MAC potentially being overwritten by something later, but just beware > >> that device probing order is *not* generally reliable, which means > >> that interface names can and do get reordered. > > > > Just noticed this was sent only to linux-usb, so I'll assume we're > > talking about USB here. Unfortunately, USB probing order is even > > *less* reliable than PCI and other types. So the only thing you can > > do here is hope that the manufacturer set a unique serial number on > > the network device (use lsusb -v to find it) and then you can use that > > to lock the udev rules to that specific device. If not, you're hosed > > and you'll never get completely reliable mapping between the network > > interface and the MAC address you're trying to set. > > > Or the usb device path of lan7500 chips onboard, which would remain same > across reboots ? In my specific case, the 7500s are hard-wired to separate hard-wired hubs, so I would expect consistent enumeration. The first 7500 on the first hub should always enumerate before the one on the second hub. I haven't seen any variation in the enumeration across many boots. If this turns out to be true, how can I use it to get control over my MAC addresses? I'm guessing a udev rule, but I'm no expert in that area (actually, I'm closer to a clueless newbie). There's still the general problem of uncontrolled re-randomization of the MAC address by the smsc75xx driver. To me, this looks like a real in-your-face bug. And since code is often shared between device drivers, I can't help but believe this behavior is not unique to the smsc75xx driver. Where would I check to see if this bug has already been reported for this and other drivers? Where would I check to see if a fix has already been created, but hasn't yet hit my kernel? (ARM kernels lag 2-3 releases behind x86 kernels, so this may already be old news to x86 folks.)
Re: [Suggestion] drivers/usb/renesas_usbhs: pkt is still in use, after it was already free.
On Fri, Dec 07, 2012 at 08:42:25PM +0800, Chen Gang wrote: > Hello Greg Kroah-Hartman: > > in drivers/usb/renesas_usbhs/mod_host.c, in function usbhsh_queue_done: > > get ureq from pkt, by using the macro usbhsh_pkt_to_ureq (at line 637) > pkt is the sub-object of ureq (line 73..76, line 157..158) > > free ureq, by calling function usbhsh_ureq_free (at line 655) > use kfree to free ureq in function usbhsh_ureq_free (line 184..191) > originally ureq is call kzalloc in function usbhsh_ureq_alloc (line > 171..179) > so pkt also free, too. > > still use pkt, by calling function usbhsh_endpoint_sequence_save (at line > 657) > use pkt->zero in funcion usbhsh_endpoint_sequence_save (at line 243) > > > I find it through code review, please help to check this suggestion whether > valid. I don't know, run the code to see if this is correct or not. 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: Random MAC address from smsc75xx: How to permanently set?
On Fri, 2012-12-07 at 14:13 +, Cunningham, Robert wrote: > > -Original Message- > > From: Jassi Brar [mailto:jassisinghb...@gmail.com] > > Sent: Thursday, December 06, 2012 10:21 PM > > Subject: Re: Random MAC address from smsc75xx: How to permanently set? > > > > On Fri, Dec 7, 2012 at 12:21 AM, Dan Williams wrote: > > > On Thu, 2012-12-06 at 12:44 -0600, Dan Williams wrote: > > >> On Thu, 2012-12-06 at 18:35 +, Cunningham, Robert wrote: > > >> > I'm trying to bring up an OMAP4 system based on Variscite's OM44 > > module running Linaro's Ubuntu Precise in a headless configuration. The > > system contains two SMSC LAN7500 USB-GigE chips (not dongles), both of > > which are fully functional. > > >> > > > >> > The GigE chips don't have EEPROMS, so no permanent MAC addresses > > >> > can be assigned in hardware. As expected, the smsc75xx driver > > >> > assigns a random MAC address when the interface is discovered and > > >> > initialized. However, we need to provide consistent MAC addresses > > >> > on these interfaces. (Yes, we could respin the board to add > > >> > EEPROMS, but that's a last, and expensive, resort.) > > >> > > > >> > After the system boots, I'd like to change the MAC addresses to > > >> > specific > > values. While there are multiple ways to do this (using commands such as > > ifconfig, ip, macchanger, and others), it seems the updated MAC address is > > always overridden when I do "ifconfig ethX up", which causes yet another > > different random MAC address to be created and assigned. Simply repeating > > ifconfig up/down causes an endless list of random MAC addresses to be > > generated. > > >> > > > >> > I created a udev rule that I hoped would handle the situation, but it > > >> > is > > also overridden: > > >> > /etc/udev/rules.d/99-mac-address.rules: > > >> > SUBSYSTEM=="net", KERNEL=="eth0", RUN+="/sbin/ip link set dev > > %k address XX:XX:XX:XX:XX:00" > > >> > SUBSYSTEM=="net", KERNEL=="eth1", RUN+="/sbin/ip link set dev > > %k address XX:XX:XX:XX:XX:01" > > >> > > > >> > For a single interface, I can use u-boot variables or kernel boot > > arguments, but they seem to work only for the first interface, and I have > > two. > > >> > > >> Just matching on interface name won't guarantee that you get the same > > >> MAC assigned to the same physical interface each time you boot. You > > >> can't rely on bus probing order. What you really want to do is > > >> enhance the udev rule to match the network interfaces based on stuff > > >> like PCI bus address, SDIO details, or whatever bus type the > > >> interfaces are hanging off. If the device is a virtual one because > > >> it's on-chip or something like that, then you're at the mercy of the > > >> driver's probing code because it probably doesn't expose any unique > > >> details of the device. This all doesn't have anything to do with the > > >> MAC potentially being overwritten by something later, but just beware > > >> that device probing order is *not* generally reliable, which means > > >> that interface names can and do get reordered. > > > > > > Just noticed this was sent only to linux-usb, so I'll assume we're > > > talking about USB here. Unfortunately, USB probing order is even > > > *less* reliable than PCI and other types. So the only thing you can > > > do here is hope that the manufacturer set a unique serial number on > > > the network device (use lsusb -v to find it) and then you can use that > > > to lock the udev rules to that specific device. If not, you're hosed > > > and you'll never get completely reliable mapping between the network > > > interface and the MAC address you're trying to set. > > > > > Or the usb device path of lan7500 chips onboard, which would remain same > > across reboots ? > > In my specific case, the 7500s are hard-wired to separate hard-wired hubs, so > I would expect consistent enumeration. The first 7500 on the first hub > should always enumerate before the one on the second hub. I haven't seen any > variation in the enumeration across many boots. > > If this turns out to be true, how can I use it to get control over my MAC > addresses? I'm guessing a udev rule, but I'm no expert in that area > (actually, I'm closer to a clueless newbie). > > There's still the general problem of uncontrolled re-randomization of the MAC > address by the smsc75xx driver. To me, this looks like a real in-your-face > bug. And since code is often shared between device drivers, I can't help but > believe this behavior is not unique to the smsc75xx driver. Where would I > check to see if this bug has already been reported for this and other > drivers? Where would I check to see if a fix has already been created, but > hasn't yet hit my kernel? (ARM kernels lag 2-3 releases behind x86 kernels, > so this may already be old news to x86 folks.) KERNELS=="x" where x is something like 1-2:1 or whereever your devices are. Grab that from the /sys/cla
Re: [Suggestion] drivers/usb/core: dev-config and dev->rawdescriptors, when processing failure.
On Fri, 7 Dec 2012, Chen Gang wrote: > but I still not quite be sure, please help checking (total 3 steps, below). > > thanks. > > -- > Step 1: > > in drivers/usb/core/sysfs.c: > > for the same device, can usb_dev_authorized_store be called multi-times ? > according to the function comments, it seems can be called multi-times. Yes, it can. > Step 2: > > in drivers/usb/core/hub.c: > >usb_authorize_device may call usb_enumerate_device at line 2355 Yes. > Step 3: > > also in drivers/usb/core/hub.c: > > if udev->config != NULL: > we will assume that it has already configured, > and will not call usb_get_configuration again. > > if first call for usb_get_confiuration failed, may udev->config will not be > NULL. > and next call usb_enumerate_device, > we will misunderstand that it has already configured (all things are 0). If the first call to usb_get_configuration fails, there won't be any more calls to usb_enumerate_device. The device will be rejected by usb_new_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 08/10] usb: add usb port auto power off mechanism
On Fri, 7 Dec 2012, Lan Tianyu wrote: > > Maybe you really need two flags. Do whatever is best; I'm sure you can > > figure out a good scheme. > Yeah. Two flags maybe good. In this situation, it should be call > "power_is_on", right? power_is_on can be used to avoid to sending > redundant PORT_POWER request. The other flag is dedicated to prevent > device from being disconnected. Something like hub->busy_bits. We can > can "child_busy", I am not very good at giving a name. So I'd like to > see your opinion. :) How about "needs_debounce"? 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: Random MAC address from smsc75xx: How to permanently set?
> From: Dan Williams [mailto:d...@redhat.com] > Sent: Friday, December 07, 2012 7:17 AM > Subject: Re: Random MAC address from smsc75xx: How to permanently set? > > On Fri, 2012-12-07 at 14:13 +, Cunningham, Robert wrote: > > > -Original Message- > > > From: Jassi Brar [mailto:jassisinghb...@gmail.com] > > > Sent: Thursday, December 06, 2012 10:21 PM > > > Subject: Re: Random MAC address from smsc75xx: How to permanently > set? > > > > > > On Fri, Dec 7, 2012 at 12:21 AM, Dan Williams > wrote: > > > > On Thu, 2012-12-06 at 12:44 -0600, Dan Williams wrote: > > > >> On Thu, 2012-12-06 at 18:35 +, Cunningham, Robert wrote: > > > >> > I'm trying to bring up an OMAP4 system based on Variscite's > > > >> > OM44 > > > module running Linaro's Ubuntu Precise in a headless configuration. > > > The system contains two SMSC LAN7500 USB-GigE chips (not dongles), > > > both of which are fully functional. > > > >> > > > > >> > The GigE chips don't have EEPROMS, so no permanent MAC > > > >> > addresses can be assigned in hardware. As expected, the > > > >> > smsc75xx driver assigns a random MAC address when the interface > > > >> > is discovered and initialized. However, we need to provide > > > >> > consistent MAC addresses on these interfaces. (Yes, we could > > > >> > respin the board to add EEPROMS, but that's a last, and > > > >> > expensive, resort.) > > > >> > > > > >> > After the system boots, I'd like to change the MAC addresses to > > > >> > specific > > > values. While there are multiple ways to do this (using commands > > > such as ifconfig, ip, macchanger, and others), it seems the updated > > > MAC address is always overridden when I do "ifconfig ethX up", which > > > causes yet another different random MAC address to be created and > > > assigned. Simply repeating ifconfig up/down causes an endless list > > > of random MAC addresses to be generated. > > > >> > > > > >> > I created a udev rule that I hoped would handle the situation, > > > >> > but it is > > > also overridden: > > > >> > /etc/udev/rules.d/99-mac-address.rules: > > > >> > SUBSYSTEM=="net", KERNEL=="eth0", RUN+="/sbin/ip link set > > > >> > dev > > > %k address XX:XX:XX:XX:XX:00" > > > >> > SUBSYSTEM=="net", KERNEL=="eth1", RUN+="/sbin/ip link set > > > >> > dev > > > %k address XX:XX:XX:XX:XX:01" > > > >> > > > > >> > For a single interface, I can use u-boot variables or kernel > > > >> > boot > > > arguments, but they seem to work only for the first interface, and I > > > have two. > > > >> > > > >> Just matching on interface name won't guarantee that you get the > > > >> same MAC assigned to the same physical interface each time you > > > >> boot. You can't rely on bus probing order. What you really want > > > >> to do is enhance the udev rule to match the network interfaces > > > >> based on stuff like PCI bus address, SDIO details, or whatever > > > >> bus type the interfaces are hanging off. If the device is a > > > >> virtual one because it's on-chip or something like that, then > > > >> you're at the mercy of the driver's probing code because it > > > >> probably doesn't expose any unique details of the device. This > > > >> all doesn't have anything to do with the MAC potentially being > > > >> overwritten by something later, but just beware that device > > > >> probing order is *not* generally reliable, which means that interface > names can and do get reordered. > > > > > > > > Just noticed this was sent only to linux-usb, so I'll assume we're > > > > talking about USB here. Unfortunately, USB probing order is even > > > > *less* reliable than PCI and other types. So the only thing you > > > > can do here is hope that the manufacturer set a unique serial > > > > number on the network device (use lsusb -v to find it) and then > > > > you can use that to lock the udev rules to that specific device. > > > > If not, you're hosed and you'll never get completely reliable > > > > mapping between the network interface and the MAC address you're > trying to set. > > > > > > > Or the usb device path of lan7500 chips onboard, which would remain > > > same across reboots ? > > > > In my specific case, the 7500s are hard-wired to separate hard-wired hubs, > so I would expect consistent enumeration. The first 7500 on the first hub > should always enumerate before the one on the second hub. I haven't seen > any variation in the enumeration across many boots. > > > > If this turns out to be true, how can I use it to get control over my MAC > addresses? I'm guessing a udev rule, but I'm no expert in that area > (actually, > I'm closer to a clueless newbie). > > > > There's still the general problem of uncontrolled re-randomization of > > the MAC address by the smsc75xx driver. To me, this looks like a real > > in-your-face bug. And since code is often shared between device > > drivers, I can't help but believe this behavior is not unique to the > > smsc75xx driver. Where would I check to see if this bug h
Re: Random MAC address from smsc75xx: How to permanently set?
On Fri, 2012-12-07 at 15:27 +, Cunningham, Robert wrote: > > From: Dan Williams [mailto:d...@redhat.com] > > Sent: Friday, December 07, 2012 7:17 AM > > Subject: Re: Random MAC address from smsc75xx: How to permanently set? > > > > On Fri, 2012-12-07 at 14:13 +, Cunningham, Robert wrote: > > > > -Original Message- > > > > From: Jassi Brar [mailto:jassisinghb...@gmail.com] > > > > Sent: Thursday, December 06, 2012 10:21 PM > > > > Subject: Re: Random MAC address from smsc75xx: How to permanently > > set? > > > > > > > > On Fri, Dec 7, 2012 at 12:21 AM, Dan Williams > > wrote: > > > > > On Thu, 2012-12-06 at 12:44 -0600, Dan Williams wrote: > > > > >> On Thu, 2012-12-06 at 18:35 +, Cunningham, Robert wrote: > > > > >> > I'm trying to bring up an OMAP4 system based on Variscite's > > > > >> > OM44 > > > > module running Linaro's Ubuntu Precise in a headless configuration. > > > > The system contains two SMSC LAN7500 USB-GigE chips (not dongles), > > > > both of which are fully functional. > > > > >> > > > > > >> > The GigE chips don't have EEPROMS, so no permanent MAC > > > > >> > addresses can be assigned in hardware. As expected, the > > > > >> > smsc75xx driver assigns a random MAC address when the interface > > > > >> > is discovered and initialized. However, we need to provide > > > > >> > consistent MAC addresses on these interfaces. (Yes, we could > > > > >> > respin the board to add EEPROMS, but that's a last, and > > > > >> > expensive, resort.) > > > > >> > > > > > >> > After the system boots, I'd like to change the MAC addresses to > > > > >> > specific > > > > values. While there are multiple ways to do this (using commands > > > > such as ifconfig, ip, macchanger, and others), it seems the updated > > > > MAC address is always overridden when I do "ifconfig ethX up", which > > > > causes yet another different random MAC address to be created and > > > > assigned. Simply repeating ifconfig up/down causes an endless list > > > > of random MAC addresses to be generated. > > > > >> > > > > > >> > I created a udev rule that I hoped would handle the situation, > > > > >> > but it is > > > > also overridden: > > > > >> > /etc/udev/rules.d/99-mac-address.rules: > > > > >> > SUBSYSTEM=="net", KERNEL=="eth0", RUN+="/sbin/ip link set > > > > >> > dev > > > > %k address XX:XX:XX:XX:XX:00" > > > > >> > SUBSYSTEM=="net", KERNEL=="eth1", RUN+="/sbin/ip link set > > > > >> > dev > > > > %k address XX:XX:XX:XX:XX:01" > > > > >> > > > > > >> > For a single interface, I can use u-boot variables or kernel > > > > >> > boot > > > > arguments, but they seem to work only for the first interface, and I > > > > have two. > > > > >> > > > > >> Just matching on interface name won't guarantee that you get the > > > > >> same MAC assigned to the same physical interface each time you > > > > >> boot. You can't rely on bus probing order. What you really want > > > > >> to do is enhance the udev rule to match the network interfaces > > > > >> based on stuff like PCI bus address, SDIO details, or whatever > > > > >> bus type the interfaces are hanging off. If the device is a > > > > >> virtual one because it's on-chip or something like that, then > > > > >> you're at the mercy of the driver's probing code because it > > > > >> probably doesn't expose any unique details of the device. This > > > > >> all doesn't have anything to do with the MAC potentially being > > > > >> overwritten by something later, but just beware that device > > > > >> probing order is *not* generally reliable, which means that interface > > names can and do get reordered. > > > > > > > > > > Just noticed this was sent only to linux-usb, so I'll assume we're > > > > > talking about USB here. Unfortunately, USB probing order is even > > > > > *less* reliable than PCI and other types. So the only thing you > > > > > can do here is hope that the manufacturer set a unique serial > > > > > number on the network device (use lsusb -v to find it) and then > > > > > you can use that to lock the udev rules to that specific device. > > > > > If not, you're hosed and you'll never get completely reliable > > > > > mapping between the network interface and the MAC address you're > > trying to set. > > > > > > > > > Or the usb device path of lan7500 chips onboard, which would remain > > > > same across reboots ? > > > > > > In my specific case, the 7500s are hard-wired to separate hard-wired hubs, > > so I would expect consistent enumeration. The first 7500 on the first hub > > should always enumerate before the one on the second hub. I haven't seen > > any variation in the enumeration across many boots. > > > > > > If this turns out to be true, how can I use it to get control over my MAC > > addresses? I'm guessing a udev rule, but I'm no expert in that area > > (actually, > > I'm closer to a clueless newbie). > > > > > > There's still the general problem of uncontrolled re-randomization of > > > the MAC address by the smsc7
[PATCH] usb: dwc3: decrease event buffer size
Currently we're allocating an entire page to serve as our event buffer. Provided our events are 4 bytes long, it's very unlikely we will even trigger 1k events at once. Even in the worst case scenario where every endpoint triggers one event and we still have a couple of error events, that would still be less than 40 events. In order to cope with future versions of the IP which could (or could not) increase the amount of possible events to trigger simultaneously, we're using an arbitrary size of 64 events for our event buffer. We're saving 3840 bytes by doing so. Signed-off-by: Felipe Balbi --- I will send this patch for v3.9 merge window. Please give it a round of test, though there won't be any issues at all. In fact, in normal usage, I have never seen more than 20 or so events trigger simultaneously. drivers/usb/dwc3/core.h | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h index 4999563..5f79d9f 100644 --- a/drivers/usb/dwc3/core.h +++ b/drivers/usb/dwc3/core.h @@ -55,7 +55,9 @@ #define DWC3_ENDPOINTS_NUM 32 #define DWC3_XHCI_RESOURCES_NUM2 -#define DWC3_EVENT_BUFFERS_SIZEPAGE_SIZE +#define DWC3_EVENT_SIZE4 /* bytes */ +#define DWC3_EVENT_MAX_NUM 64 /* 2 events/endpoint */ +#define DWC3_EVENT_BUFFERS_SIZE(DWC3_EVENT_SIZE * DWC3_EVENT_MAX_NUM) #define DWC3_EVENT_TYPE_MASK 0xfe #define DWC3_EVENT_TYPE_DEV0 -- 1.8.0.1 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] USB: misc: Add USB3503 High-Speed Hub Controller
From: Dongjin Kim
This patch adds new driver of SMSC USB3503 USB 2.0 hub controller with HSIC
upstream connectivity and three USB 2.0 downstream ports. The specification
can be found from 'http://www.smsc.com/index.php?tid=295&pid=325'.
The current version have been tested very basic features switching the modes,
HUB-MODE and STANDBY-MODE.
Signed-off-by: Dongjin Kim
---
drivers/usb/misc/Kconfig |6 +
drivers/usb/misc/Makefile |1 +
drivers/usb/misc/usb3503.c| 303 +
include/linux/platform_data/usb3503.h | 19 +++
4 files changed, 329 insertions(+)
create mode 100644 drivers/usb/misc/usb3503.c
create mode 100644 include/linux/platform_data/usb3503.h
diff --git a/drivers/usb/misc/Kconfig b/drivers/usb/misc/Kconfig
index a8f0523..98081bc 100644
--- a/drivers/usb/misc/Kconfig
+++ b/drivers/usb/misc/Kconfig
@@ -249,3 +249,9 @@ config USB_EZUSB_FX2
help
Say Y here if you need EZUSB device support.
(Cypress FX/FX2/FX2LP microcontrollers)
+
+config USB_HSIC_USB3503
+ tristate "USB3503 HSIC to USB20 Driver"
+ depends on I2C
+ help
+ This option enables support for SMSC USB3503 HSIC to USB 2.0 Driver.
diff --git a/drivers/usb/misc/Makefile b/drivers/usb/misc/Makefile
index 3e99a64..3e1bd70 100644
--- a/drivers/usb/misc/Makefile
+++ b/drivers/usb/misc/Makefile
@@ -26,5 +26,6 @@ obj-$(CONFIG_USB_TRANCEVIBRATOR) += trancevibrator.o
obj-$(CONFIG_USB_USS720) += uss720.o
obj-$(CONFIG_USB_SEVSEG) += usbsevseg.o
obj-$(CONFIG_USB_YUREX)+= yurex.o
+obj-$(CONFIG_USB_HSIC_USB3503) += usb3503.o
obj-$(CONFIG_USB_SISUSBVGA)+= sisusbvga/
diff --git a/drivers/usb/misc/usb3503.c b/drivers/usb/misc/usb3503.c
new file mode 100644
index 000..796d58c
--- /dev/null
+++ b/drivers/usb/misc/usb3503.c
@@ -0,0 +1,303 @@
+/*
+ * Driver for SMSC USB3503 USB 2.0 hub controller driver
+ *
+ * Copyright (c) 2012-2013 Dongjin Kim (tobet...@gmail.com)
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define USB3503_VIDL 0x00
+#define USB3503_VIDM 0x01
+#define USB3503_PIDL 0x02
+#define USB3503_PIDM 0x03
+#define USB3503_DIDL 0x04
+#define USB3503_DIDM 0x05
+
+#define USB3503_CFG1 0x06
+#define USB3503_SELF_BUS_PWR (1 << 7)
+
+#define USB3503_CFG2 0x07
+#define USB3503_CFG3 0x08
+#define USB3503_NRD0x09
+
+#define USB3503_PDS0x0a
+#define USB3503_PORT1 (1 << 1)
+#define USB3503_PORT2 (1 << 2)
+#define USB3503_PORT3 (1 << 3)
+
+#define USB3503_SP_ILOCK 0xe7
+#define USB3503_SPILOCK_CONNECT(1 << 1)
+#define USB3503_SPILOCK_CONFIG (1 << 0)
+
+#define USB3503_CFGP 0xee
+#define USB3503_CLKSUSP(1 << 7)
+
+struct usb3503 {
+ enum usb3503_mode mode;
+ struct i2c_client *client;
+ int gpio_intn;
+ int gpio_reset;
+ int gpio_connect;
+};
+
+static int usb3503_write_register(struct i2c_client *client,
+ char reg, char data)
+{
+ return i2c_smbus_write_byte_data(client, reg, data);
+}
+
+static int usb3503_read_register(struct i2c_client *client, char reg)
+{
+ return i2c_smbus_read_byte_data(client, reg);
+}
+
+static int usb3503_set_bits(struct i2c_client *client, char reg, char req)
+{
+ int err;
+
+ err = usb3503_read_register(client, reg);
+ if (err < 0)
+ return err;
+
+ err = usb3503_write_register(client, reg, err | req);
+ if (err < 0)
+ return err;
+
+ return 0;
+}
+
+static int usb3503_clear_bits(struct i2c_client *client, char reg, char req)
+{
+ int err;
+
+ err = usb3503_read_register(client, reg);
+ if (err < 0)
+ return err;
+
+ err = usb3503_write_register(client, reg, err & ~req);
+ if (err < 0)
+ return err;
+
+ return 0;
+}
+
+static int usb3503_reset(int gpio_reset, int state)
+{
+ if (gpio_is_valid(gpio_reset))
+ gpio_set_value(gpio_reset, state);
+
+
[no subject]
-- 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: Unreliable USB3 with NEC uPD720200 and Delock Cardreader
On Thursday, December 06, 2012 04:28:08 PM Sarah Sharp wrote: > On Thu, Dec 06, 2012 at 01:43:32AM +0100, Rafael J. Wysocki wrote: > > On Wednesday, December 05, 2012 04:33:44 PM Sarah Sharp wrote: > > > Wakeup from D3 works fine on the 3.5.0 kernel, but fails on 3.6.2. I > > > haven't fully bisected yet. > > > > > > In debugging, I found that if you only enable runtime suspend for the > > > NEC host controller, the host successfully comes out of D3 when you plug > > > in a USB device. However, if you enable runtime PM for the parent PCIe > > > root > > > port, it stops working. Disabling D3cold for both devices did not help. > > > > > > It looks like a PCI issue, so what sort of debugging info do you need > > > from me? > > > > It looks like this is related to one of the following commits: > > > Generally, please try to bisect changes in drivers/pci between v3.5 and > > v3.6. > > Ok, I ran git bisect with only the drivers/pci directory as a target. > > > ee85f54 ACPI/PM: specify lowest allowed state for device sleep state > > git bisect ended up identifying this as the bad patch, although > reverting just that patch after the bisect finished didn't seem to help. > However, it does make sense that this would be the culprit patch, if > Huang Ying's theory about the PME polling is correct. Well, we surely don't handle this particular case correctly, and it shouldn't be very difficult to fix, so let's hope that this is the culprit. :-) Thanks, Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- 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 v2 03/11] USB: Allow USB 3.0 ports to be disabled.
On Wed, Dec 05, 2012 at 11:55:59AM -0500, Alan Stern wrote:
> On Tue, 4 Dec 2012, Sarah Sharp wrote:
> > +static int hub_set_port_link_state(struct usb_hub *hub, int port1,
> > + unsigned int link_status)
> > +{
> > + return set_port_feature(hub->hdev,
> > + port1 | (link_status << 3),
>
> Shouldn't this be << 8?
The port link state values defined in ch11.h are already right shifted
by 5. Basically, they're designed so you can mask off bits 5-8
returned by the Get Port Status hub request and directly compare those
macros to the result. For example, the USB 3.0 spec says that a 0x1 in
bits 5-8 means the link state is U1, but USB_SS_PORT_LS_U1 is defined as
0x0020.
I was basically copying code like this in hub.c:
/* see 7.1.7.6 */
if (hub_is_superspeed(hub->hdev))
status = set_port_feature(hub->hdev,
port1 | (USB_SS_PORT_LS_U3 << 3),
USB_PORT_FEAT_LINK_STATE);
I was going to convert that code to use hub_set_port_link_state, but didn't get
around to it in this patchset.
Sarah Sharp
--
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 v2 06/11] USB: Handle warm reset failure on empty port.
On Wed, Dec 05, 2012 at 12:14:07PM -0500, Alan Stern wrote:
> On Tue, 4 Dec 2012, Sarah Sharp wrote:
>
> > An empty port can transition to either Inactive or Compliance Mode if a
> > newly connected USB 3.0 device fails to link train. In that case, we
> > issue a warm reset. Some devices, such as John's Roseweil eusb3
> > enclosure, slip back into Compliance Mode after the warm reset.
> >
> > The current warm reset code does not check for device connect status on
> > warm reset completion, and it incorrectly reports the warm reset
> > succeeded. This causes the USB core to attempt to send a Set Address
> > control transfer to a port in Compliance Mode, which will always fail.
> >
> > Make hub_port_wait_reset check the current connect status and link state
> > after the warm reset completes. Return a failure status if the device
> > is disconnected or the link state is Compliance Mode or SS.Inactive.
> >
> > Make hub_events disable the port if warm reset fails. This will disable
> > the port, and then bring it back into the RxDetect state. Make the USB
> > core ignore the connect change until the device reconnects.
>
> Is this really the right thing to do? It means that drivers will
> continue to submit URBs.
This is just a bandaid patch until the patch that handles connected
device reset failures. That patch will do the right thing by calling
usb_reset_device and properly disconnecting drivers on failure.
Basically the only reason this patch is broken out is to break the
patchset into readable chucks.
Or do you mean we'll have issues with drivers continuing to submit URBs
once the last patch is applied?
> > Note that this patch does NOT handle connected devices slipping into the
> > Inactive state very well. This is a concern, because devices can go
> > into the Inactive state on U1/U2 exit failure. However, the fix for
> > that case is too large for stable, so it will be submitted in a separate
> > patch.
> >
> > This patch should be backported to kernels as old as 3.2, contain the
> > commit ID 75d7cf72ab9fa01dc70877aa5c68e8ef477229dc "usbcore: refine warm
> > reset logic"
> >
> > Signed-off-by: Sarah Sharp
> > Reported-by: John Covici
> > Cc: sta...@vger.kernel.org
> > ---
> > drivers/usb/core/hub.c | 18 +++---
> > 1 files changed, 15 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
> > index b7b055f..85977de 100644
> > --- a/drivers/usb/core/hub.c
> > +++ b/drivers/usb/core/hub.c
> > @@ -2601,8 +2601,15 @@ static int hub_port_wait_reset(struct usb_hub *hub,
> > int port1,
> > return 0;
> > }
> > } else {
> > - if (portchange & USB_PORT_STAT_C_BH_RESET)
> > - return 0;
> > + if (!(portchange & USB_PORT_STAT_C_BH_RESET))
> > + goto delay;
>
> Does this bit get set as soon as the reset is finished, or not until
> later? (The spec isn't clear about this, or I'm not looking in the
> right place.)
>
> If it gets set as soon as the reset is finished then this test isn't
> needed, because you already added a test for USB_PORT_STAT_RESET.
The USB_PORT_STAT_C_BH_RESET bit gets set along with the reset change
bit if the reset was a warm reset. So yes, you're correct this code
could just go away, and that change probably should go into the patch to
ignore port status until the reset finishes.
Sarah Sharp
--
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 v2 07/11] xhci: Avoid "dead ports", add roothub port polling.
On Wed, Dec 05, 2012 at 01:50:46PM -0500, Alan Stern wrote: > On Tue, 4 Dec 2012, Sarah Sharp wrote: > > > The USB core hub thread (khubd) is designed with external USB hubs in > > mind. It expects that if a port status change bit is set, the hub will > > continue to send a notification through the hub status data transfer. > > Basically, it expects hub notifications to be level-triggered. > > > > The xHCI host controller is designed to be edge-triggered. When all > > port status change bits are clear, and a new change bit is set, the xHC > > will generate a Port Status Change Event. If another change bit is set > > in the same port status register before the first bit is cleared, it > > will not send another event. > > This explanation is okay, but in general I often find the terms > "edge-triggered" and "level-triggered" to be rather confusing in this > sort of context. > > The real issue here is what input will turn on the IRQ signal (or cause > an event to be raised). With xHCI, that input is the "or" of all the > status-change bits in a port register -- a new IRQ won't be generated > until the "or" changes from 0 to 1. With EHCI, on the other hand, a 0 > -> 1 change in any of the bits will cause a new IRQ. > > Both controllers use edge-triggered IRQs. The difference lies in what > edges they are monitoring. Yes, that's a better expression of the idea. In fact, the xHCI spec's diagram of the port status change triggers includes all change bits feeding to an OR gate. :) > > + /* > > +* xHCI portsc bits are level-triggered. An event is sent on the first > > +* change bit, but won't be sent if another change bit is still set. > > +* Poll to avoid losing change bits. > > +*/ > > The first two lines of this comment don't express the idea very well. > I suggest something more like: > > /* >* xHCI port-status-change events occur when the "or" of all the >* status-change bits in the portsc register changes from 0 to 1. >* New status changes won't cause an event if any other change >* bits are still set. When an event occurs, switch over to >* polling to avoid losing status changes. >*/ Sure, that sounds fine. Sarah Sharp -- 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
various fixes to usbip userspace
The following patch series contains a few random fixes that I did along the way, while bringing up usbip on my machines. Please review and consider for inclusion upstream. The patches are based on staging-next branch in Greg KH's repository. If you would prefer me to rebase to something else, I'll be glad to. regards, Ilija -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/5] staging: usbip: userspace: add option to turn fortify on or off
This comes handy when hacking with different cross compilers, some of which may or may not have _FORTIFY_SOURCE turned on by default. This patch allows us to turn _FORTIFY_SOURCE on by specifying --with-fortify option at configuration time (or to turn it off by specifying --without-fortify). If nothing is specified, default compiler behavior is assumed. Signed-off-by: Ilija Hadzic --- drivers/staging/usbip/userspace/configure.ac | 17 + 1 file changed, 17 insertions(+) diff --git a/drivers/staging/usbip/userspace/configure.ac b/drivers/staging/usbip/userspace/configure.ac index 6d52841..2be4060 100644 --- a/drivers/staging/usbip/userspace/configure.ac +++ b/drivers/staging/usbip/userspace/configure.ac @@ -91,5 +91,22 @@ AC_ARG_WITH([usbids-dir], [USBIDS_DIR=$withval], [USBIDS_DIR="/usr/share/hwdata/"]) AC_SUBST([USBIDS_DIR]) +# use _FORTIFY_SOURCE +AC_MSG_CHECKING([whether to use fortify]) +AC_ARG_WITH([fortify], + [AS_HELP_STRING([--with-fortify], + [use _FORTIFY_SROUCE option when compiling)])], + dnl [ACTION-IF-GIVEN] + [if test "$withval" = "yes"; then + AC_MSG_RESULT([yes]) + CFLAGS="$CFLAGS -D_FORTIFY_SOURCE -O" +else + AC_MSG_RESULT([no]) + CFLAGS="$CFLAGS -U_FORTIFY_SOURCE" +fi + ], + dnl [ACTION-IF-NOT-GIVEN] + [AC_MSG_RESULT([default])]) + AC_CONFIG_FILES([Makefile libsrc/Makefile src/Makefile]) AC_OUTPUT -- 1.7.12 -- 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/5] staging: usbip: userspace: fix build breakage in doc directory
File doc/usbip_bind_driver.8 does not exist any more but it is listed in dist_man_MANS. This breaks the build of the userspace. Remove the file from the list. Signed-off-by: Ilija Hadzic --- drivers/staging/usbip/userspace/Makefile.am | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/usbip/userspace/Makefile.am b/drivers/staging/usbip/userspace/Makefile.am index 9ab1949..66f8bf0 100644 --- a/drivers/staging/usbip/userspace/Makefile.am +++ b/drivers/staging/usbip/userspace/Makefile.am @@ -3,4 +3,4 @@ includedir = @includedir@/usbip include_HEADERS := $(addprefix libsrc/, \ usbip_common.h vhci_driver.h usbip_host_driver.h) -dist_man_MANS := $(addprefix doc/, usbip.8 usbipd.8 usbip_bind_driver.8) +dist_man_MANS := $(addprefix doc/, usbip.8 usbipd.8) -- 1.7.12 -- 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 v2 10/11] USB: Rip out recursive call on warm port reset.
On Wed, Dec 05, 2012 at 02:41:11PM -0500, Alan Stern wrote:
> On Tue, 4 Dec 2012, Sarah Sharp wrote:
>
> > When a hot reset fails on a USB 3.0 port, the current port reset code
> > recursively calls hub_port_reset inside hub_port_wait_reset. This isn't
> > ideal, since we should avoid recursive calls in the kernel, and it also
> > doesn't allow us to issue multiple warm resets on reset failures.
> >
> > Rip out the recursive call. Instead, add code to hub_port_reset to
> > issue a warm reset if the hot reset fails, and try multiple warm resets
> > before giving up on the port.
>
> This is better than before. There is still a little bit I don't quite
> follow...
>
> > In hub_port_wait_reset, remove the recursive call and re-indent. The
> > code is basically the same, except:
> >
> > 1. It bails out early if the port has transitioned to Inactive or
> > Compliance Mode after the reset completed.
> >
> > 2. It doesn't consider a connect status change to be a failed reset. If
> > multiple warm resets needed to be issued, the connect status may have
> > changed, so we need to ignore that and look at the port link state
> > instead. hub_port_reset will now do that.
>
> In fact, we might as well do the same thing for non-SuperSpeed
> connections too. The kernel probably is smart enough not to get
> confused if the user manages to replace one device with another while a
> reset is in progress.
Ok, I'll look into that, although I'm really not fond of the idea of
testing that much legacy code.
> > 3. It unconditionally sets udev->speed on all types of successful
> > resets. The old recursive code would set the port speed when the second
> > hub_port_reset returned.
> >
> > With the new code in hub_port_reset, the 'warm' variable may change on a
> > transition from a hot reset to a warm reset. So hub_port_finish_reset
> > could be called with 'warm' set to true when a connected USB device has
> > been reset. Fix the code by unconditionally updating the device number,
> > informing the host that the device has been reset, and setting the
> > device state to default.
>
> Why was it necessary to skip these things before, when "warm" was set?
> Was it merely an optimization? If not, do the same reasons still
> apply?
First, you need to understand that the old code did not handle connected
devices needing a warm reset well. There were only two situations that
the old code handled correctly: an empty port needing a warm reset, and a
hot reset that migrated to a warm reset.
When an empty port needed a warm reset, hub_port_reset was called with
the warm variable set. The code in hub_port_finish_reset would skip
telling the USB core and the xHC host that the device was reset, because
otherwise that would result in a NULL pointer dereference.
When a USB 3.0 device reset migrated to a warm reset, the recursive call
made the call stack look like this:
hub_port_reset(warm = false)
hub_wait_port_reset(warm = false)
hub_port_reset(warm = true)
hub_wait_port_reset(warm = true)
hub_port_finish_reset(warm = true)
(return up the call stack to the first wait)
hub_port_finish_reset(warm = false)
The old code didn't want to notify the USB core or the xHC host of device reset
twice, so it only did it in the second call to hub_port_finish_reset,
when warm was set to false. This was necessary because
before patch two ("USB: Ignore xHCI Reset Device status."), the USB core
would pay attention to the xHC Reset Device command error status, and
the second call would always fail.
Now that we no longer have the recursive call, and warm can change from
false to true in hub_port_reset, we need to have hub_port_finish_reset
unconditionally notify the USB core and the xHC of the device reset.
Does that make sense?
> > In hub_port_finish_reset, unconditionally clear the connect status
> > change (CSC) bit for USB 3.0 hubs when the port reset is done. If we
> > had to issue multiple warm resets for a device, that bit may have been
> > set if the device went into SS.Inactive and then was successfully warm
> > reset.
> >
> > Signed-off-by: Sarah Sharp
> > ---
> > drivers/usb/core/hub.c | 159
> > +--
> > 1 files changed, 71 insertions(+), 88 deletions(-)
> >
> > diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
> > index d8de712..a502857 100644
> > --- a/drivers/usb/core/hub.c
> > +++ b/drivers/usb/core/hub.c
> > @@ -2538,80 +2538,39 @@ static int hub_port_wait_reset(struct usb_hub *hub,
> > int port1,
>
> > - if (!(portstatus & USB_PORT_STAT_CONNECTION) ||
> > - hub_port_warm_reset_required(hub,
> > - portstatus))
> > - return -ENOTCONN;
> > + /* if we've finished resetting, then break out of
> > +* the loop
> > +
[PATCH 2/5] staging: usbip: userspace: add gitignore file
There are a bunch of automatically generated files that git should not care about. Signed-off-by: Ilija Hadzic --- drivers/staging/usbip/userspace/.gitignore | 28 1 file changed, 28 insertions(+) create mode 100644 drivers/staging/usbip/userspace/.gitignore diff --git a/drivers/staging/usbip/userspace/.gitignore b/drivers/staging/usbip/userspace/.gitignore new file mode 100644 index 000..9aad9e3 --- /dev/null +++ b/drivers/staging/usbip/userspace/.gitignore @@ -0,0 +1,28 @@ +Makefile +Makefile.in +aclocal.m4 +autom4te.cache/ +config.guess +config.h +config.h.in +config.log +config.status +config.sub +configure +depcomp +install-sh +libsrc/Makefile +libsrc/Makefile.in +libtool +ltmain.sh +missing +src/Makefile +src/Makefile.in +stamp-h1 +libsrc/libusbip.la +libsrc/libusbip_la-names.lo +libsrc/libusbip_la-usbip_common.lo +libsrc/libusbip_la-usbip_host_driver.lo +libsrc/libusbip_la-vhci_driver.lo +src/usbip +src/usbipd -- 1.7.12 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/5] staging: usbip: userspace: suppress a bogus error
If mkdir() of VHCI_STATE_PATH fails because the directory
already exists, that's not an error. This patch fixes
annoying "record connection" errors that would typically
come up on attach.
Signed-off-by: Ilija Hadzic
---
drivers/staging/usbip/userspace/src/usbip_attach.c | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/usbip/userspace/src/usbip_attach.c
b/drivers/staging/usbip/userspace/src/usbip_attach.c
index bdf61c0..2da4e44 100644
--- a/drivers/staging/usbip/userspace/src/usbip_attach.c
+++ b/drivers/staging/usbip/userspace/src/usbip_attach.c
@@ -27,6 +27,7 @@
#include
#include
#include
+#include
#include "vhci_driver.h"
#include "usbip_common.h"
@@ -52,8 +53,18 @@ static int record_connection(char *host, char *port, char
*busid, int rhport)
int ret;
ret = mkdir(VHCI_STATE_PATH, 0700);
- if (ret < 0)
- return -1;
+ if (ret < 0) {
+ /* if VHCI_STATE_PATH exists, then it better be a directory */
+ if (errno == EEXIST) {
+ struct stat s;
+ ret = stat(VHCI_STATE_PATH, &s);
+ if (ret < 0)
+ return -1;
+ if (!(s.st_mode & S_IFDIR))
+ return -1;
+ } else
+ return -1;
+ }
snprintf(path, PATH_MAX, VHCI_STATE_PATH"/port%d", rhport);
--
1.7.12
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/5] staging: usbip: userspace: eliminate glib dependency
USBIP daemon relies on functions available in glib2 library
to spawn handler code for incoming connection. This makes the
whole program dependent on glib2 library, which is a GNOME library
that on systems that don't have GNOME results in pulling more
dependency, only to be able to run a relatively trivial
socket-based program.
While this may not seem to be a problem on full-blown desktops
that already have the necessary libraries, it is a big issue
on small embedded systems (think USB hub with an Ethernet port)
that only have bare essentials in their file systems.
This patch eliminates glib2 dependency by reworking the
code to use lower level system calls to dispatch connection
handler. Instead of using glib2-style event loop and dispatching
mechanism, just do a ppoll(2) system call in our own loop and call
accept(2) followed by fork(2) on the socket that has incoming
connection. Stevens' books taught us that more than twenty
years ago. No need for anything smarter in a simple server, such
as usbipd.
Signed-off-by: Ilija Hadzic
---
drivers/staging/usbip/userspace/README | 2 -
drivers/staging/usbip/userspace/configure.ac| 5 --
drivers/staging/usbip/userspace/src/Makefile.am | 4 +-
drivers/staging/usbip/userspace/src/usbipd.c| 96 ++---
4 files changed, 57 insertions(+), 50 deletions(-)
diff --git a/drivers/staging/usbip/userspace/README
b/drivers/staging/usbip/userspace/README
index 63cd107..233d1d7 100644
--- a/drivers/staging/usbip/userspace/README
+++ b/drivers/staging/usbip/userspace/README
@@ -17,8 +17,6 @@
- gcc >= 4.0
-- libglib2.0-dev >= 2.6.0
-
- libtool, automake >= 1.9, autoconf >= 2.5.0, pkg-config
diff --git a/drivers/staging/usbip/userspace/configure.ac
b/drivers/staging/usbip/userspace/configure.ac
index 43e641e..6d52841 100644
--- a/drivers/staging/usbip/userspace/configure.ac
+++ b/drivers/staging/usbip/userspace/configure.ac
@@ -91,10 +91,5 @@ AC_ARG_WITH([usbids-dir],
[USBIDS_DIR=$withval], [USBIDS_DIR="/usr/share/hwdata/"])
AC_SUBST([USBIDS_DIR])
-GLIB2_REQUIRED=2.6.0
-PKG_CHECK_MODULES([PACKAGE], [glib-2.0 >= $GLIB2_REQUIRED])
-AC_SUBST([PACKAGE_CFLAGS])
-AC_SUBST([PACKAGE_LIBS])
-
AC_CONFIG_FILES([Makefile libsrc/Makefile src/Makefile])
AC_OUTPUT
diff --git a/drivers/staging/usbip/userspace/src/Makefile.am
b/drivers/staging/usbip/userspace/src/Makefile.am
index c365a3f..a113003 100644
--- a/drivers/staging/usbip/userspace/src/Makefile.am
+++ b/drivers/staging/usbip/userspace/src/Makefile.am
@@ -1,6 +1,6 @@
AM_CPPFLAGS = -I$(top_srcdir)/libsrc -DUSBIDS_FILE='"@USBIDS_DIR@/usb.ids"'
-AM_CFLAGS = @EXTRA_CFLAGS@ @PACKAGE_CFLAGS@
-LDADD = $(top_builddir)/libsrc/libusbip.la @PACKAGE_LIBS@
+AM_CFLAGS = @EXTRA_CFLAGS@
+LDADD = $(top_builddir)/libsrc/libusbip.la
sbin_PROGRAMS := usbip usbipd
diff --git a/drivers/staging/usbip/userspace/src/usbipd.c
b/drivers/staging/usbip/userspace/src/usbipd.c
index 8668a80..34760cc 100644
--- a/drivers/staging/usbip/userspace/src/usbipd.c
+++ b/drivers/staging/usbip/userspace/src/usbipd.c
@@ -20,6 +20,7 @@
#include "../config.h"
#endif
+#define _GNU_SOURCE
#include
#include
#include
@@ -35,10 +36,9 @@
#include
#endif
-#define _GNU_SOURCE
#include
-#include
#include
+#include
#include "usbip_host_driver.h"
#include "usbip_common.h"
@@ -48,7 +48,7 @@
#define PROGNAME "usbipd"
#define MAXSOCKFD 20
-GMainLoop *main_loop;
+#define MAIN_LOOP_TIMEOUT 10
static const char usbip_version_string[] = PACKAGE_STRING;
@@ -310,30 +310,22 @@ static int do_accept(int listenfd)
return connfd;
}
-gboolean process_request(GIOChannel *gio, GIOCondition condition,
-gpointer unused_data)
+int process_request(int listenfd)
{
- int listenfd;
+ pid_t childpid;
int connfd;
- (void) unused_data;
-
- if (condition & (G_IO_ERR | G_IO_HUP | G_IO_NVAL)) {
- err("unknown condition");
- BUG();
- }
-
- if (condition & G_IO_IN) {
- listenfd = g_io_channel_unix_get_fd(gio);
- connfd = do_accept(listenfd);
- if (connfd < 0)
- return TRUE;
-
+ connfd = do_accept(listenfd);
+ if (connfd < 0)
+ return -1;
+ childpid = fork();
+ if (childpid == 0) {
+ close(listenfd);
recv_pdu(connfd);
- close(connfd);
+ exit(0);
}
-
- return TRUE;
+ close(connfd);
+ return 0;
}
static void log_addrinfo(struct addrinfo *ai)
@@ -418,10 +410,7 @@ static struct addrinfo *do_getaddrinfo(char *host, int
ai_family)
static void signal_handler(int i)
{
- dbg("received signal: code %d", i);
-
- if (main_loop)
- g_main_loop_quit(main_loop);
+ dbg("received '%s' signal", strsignal(i));
}
static void set_signal(void)
@@ -433,14 +422,19 @@ static voi
Re: [RFC v2 06/11] USB: Handle warm reset failure on empty port.
On Fri, 7 Dec 2012, Sarah Sharp wrote: > On Wed, Dec 05, 2012 at 12:14:07PM -0500, Alan Stern wrote: > > On Tue, 4 Dec 2012, Sarah Sharp wrote: > > > > > An empty port can transition to either Inactive or Compliance Mode if a > > > newly connected USB 3.0 device fails to link train. In that case, we > > > issue a warm reset. Some devices, such as John's Roseweil eusb3 > > > enclosure, slip back into Compliance Mode after the warm reset. > > > > > > The current warm reset code does not check for device connect status on > > > warm reset completion, and it incorrectly reports the warm reset > > > succeeded. This causes the USB core to attempt to send a Set Address > > > control transfer to a port in Compliance Mode, which will always fail. > > > > > > Make hub_port_wait_reset check the current connect status and link state > > > after the warm reset completes. Return a failure status if the device > > > is disconnected or the link state is Compliance Mode or SS.Inactive. > > > > > > Make hub_events disable the port if warm reset fails. This will disable > > > the port, and then bring it back into the RxDetect state. Make the USB > > > core ignore the connect change until the device reconnects. > > > > Is this really the right thing to do? It means that drivers will > > continue to submit URBs. > > This is just a bandaid patch until the patch that handles connected > device reset failures. That patch will do the right thing by calling > usb_reset_device and properly disconnecting drivers on failure. > Basically the only reason this patch is broken out is to break the > patchset into readable chucks. Oh, okay. When reading a bunch of patches in a series, it's not so easy to tell when a later patch overwrites code added in an earlier patch. > Or do you mean we'll have issues with drivers continuing to submit URBs > once the last patch is applied? No, that wasn't what I meant -- but I didn't check specifically whether it could happen. Assuming it can't, and as long as the end result works okay, I don't mind a little awkwardness in the middle. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v2 10/11] USB: Rip out recursive call on warm port reset.
On Fri, 7 Dec 2012, Sarah Sharp wrote:
> > > 2. It doesn't consider a connect status change to be a failed reset. If
> > > multiple warm resets needed to be issued, the connect status may have
> > > changed, so we need to ignore that and look at the port link state
> > > instead. hub_port_reset will now do that.
> >
> > In fact, we might as well do the same thing for non-SuperSpeed
> > connections too. The kernel probably is smart enough not to get
> > confused if the user manages to replace one device with another while a
> > reset is in progress.
>
> Ok, I'll look into that, although I'm really not fond of the idea of
> testing that much legacy code.
That change can be separate from the rest of your -stable cleanup
stuff.
> > > 3. It unconditionally sets udev->speed on all types of successful
> > > resets. The old recursive code would set the port speed when the second
> > > hub_port_reset returned.
> > >
> > > With the new code in hub_port_reset, the 'warm' variable may change on a
> > > transition from a hot reset to a warm reset. So hub_port_finish_reset
> > > could be called with 'warm' set to true when a connected USB device has
> > > been reset. Fix the code by unconditionally updating the device number,
> > > informing the host that the device has been reset, and setting the
> > > device state to default.
> >
> > Why was it necessary to skip these things before, when "warm" was set?
> > Was it merely an optimization? If not, do the same reasons still
> > apply?
>
> First, you need to understand that the old code did not handle connected
> devices needing a warm reset well. There were only two situations that
> the old code handled correctly: an empty port needing a warm reset, and a
> hot reset that migrated to a warm reset.
>
> When an empty port needed a warm reset, hub_port_reset was called with
> the warm variable set. The code in hub_port_finish_reset would skip
> telling the USB core and the xHC host that the device was reset, because
> otherwise that would result in a NULL pointer dereference.
>
> When a USB 3.0 device reset migrated to a warm reset, the recursive call
> made the call stack look like this:
>
> hub_port_reset(warm = false)
> hub_wait_port_reset(warm = false)
> hub_port_reset(warm = true)
> hub_wait_port_reset(warm = true)
> hub_port_finish_reset(warm = true)
> (return up the call stack to the first wait)
>
> hub_port_finish_reset(warm = false)
>
> The old code didn't want to notify the USB core or the xHC host of device
> reset
> twice, so it only did it in the second call to hub_port_finish_reset,
> when warm was set to false. This was necessary because
> before patch two ("USB: Ignore xHCI Reset Device status."), the USB core
> would pay attention to the xHC Reset Device command error status, and
> the second call would always fail.
>
> Now that we no longer have the recursive call, and warm can change from
> false to true in hub_port_reset, we need to have hub_port_finish_reset
> unconditionally notify the USB core and the xHC of the device reset.
>
> Does that make sense?
Yes, thank you. Can you stick a copy of this explanation into the
patch description?
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
Need help for hardware bug in Intel's EHCI implementation
Sarah: I just tracked down a tricky problem, which appears to be caused by a genuine hardware bug. It's hard to believe this has escaped everyone's notice for so many years -- maybe my results are wrong. But as far as I can tell, they aren't. Anyway, I don't know what to do about it. Can you forward this message to an appropriate person at Intel? Thanks. My system has a fairly old 82801EB/ER motherboard with the ICH5/ICH5R chipset, as shown by lspci: $ lspci -v -s 1d.7 00:1d.7 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB2 EHCI Controller (rev 02) (prog-if 20 [EHCI]) Subsystem: GVC/BCM Advanced Research Device 2181 Flags: bus master, medium devsel, latency 0, IRQ 23 Memory at fe77bc00 (32-bit, non-prefetchable) [size=1K] Capabilities: Kernel driver in use: ehci_hcd $ lspci -vn -s 1d.7 00:1d.7 0c03: 8086:24dd (rev 02) (prog-if 20 [EHCI]) Subsystem: 14a4:2181 Flags: bus master, medium devsel, latency 0, IRQ 23 Memory at fe77bc00 (32-bit, non-prefetchable) [size=1K] Capabilities: Kernel driver in use: ehci_hcd My test results show that the EHCI hardware generates Interrupt on Async Advance (IAA) interrupts too early. The test is fairly simple. The async schedule contains nothing but an empty QH (with the Head bit set) and a QH for a bulk-OUT endpoint. A bunch of 512-byte qTD's are added to the bulk QH, and at various times some of them are cancelled. This cancellation involves removing the QH from the async schedule. The driver uses the scheme outlined in section 4.8.2 of the EHCI spec. The Horizontal Pointer in the empty QH is set to point back to itself, then the Interrupt on Async Advance Doorbell (IAAD) bit is set in the USBCMD register, and then the driver waits for an interrupt with the IAA bit set in the USBSTS register. When the interrupt arrives, the driver stores the values of the qTD Token words from both the bulk QH's overlay region and the first qTD whose Active bit is still set. After the cancelled qTD's have been removed from the list, the driver inserts the bulk QH back into the async schedule. Just before doing this, the driver compares the Token words currently in the overlay region and the first qTD with the stored values from earlier, and it logs a message if they are different. This should never happen, because the controller should not be able to access the bulk QH after the IAA interrupt. Nevertheless, I do see occasional changes in the Token words. It is obvious that the controller sometimes writes back values for a completed transaction to the overlay or to the qTD _after_ the IAA interrupt has been received. In the tests, the earlier Token values are 0x02008c80 and the later values are 0x80008c00. (Oddly enough, this seems to happen only when the Data Toggle bit changes from 0 to 1.) Assuming the test results are correct, this is clearly a hardware bug, and a nasty one. Is it a known problem? Is there a recommended workaround? Thank you, Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH] fs: configfs: programmatically create config groups
Hey Guys,
Sorry I missed this for a while. I'll make a couple of inline
comments, and then I'll summarize my (incomplete) thoughts at the
bottom.
On Wed, Nov 28, 2012 at 02:50:13PM +0100, Sebastian Andrzej Siewior wrote:
> On 11/28/2012 02:05 PM, Michal Nazarewicz wrote:
> >>On 11/27/2012 05:23 PM, Michal Nazarewicz wrote:
> >>>How should a generic tool know what kind of actions are needed for given
> >>>function to be removed? If you ask me, there should be a way to unbind
> >>>gadget and unload all modules without any specific knowledge of the
> >>>functions. If there is no such mechanism, then it's a bad user
> >>>interface.
Please remember that configfs is not a "user" interface, it's a
userspace<->kernelspace interface. Like sysfs, it's not required to be
convenient for someone at a bash prompt. My goal is that it is *usable*
from a bash prompt. So it must be that you can
create/destroy/configure objects via mkdir/rmkdir/cat/echo, but you
might have a lot of those mkdir/echo combos to configure something.
When it comes to the "user" interface, a wrapper script or library
should be converting a user intention into all that boilerplate.
> >
> >On Wed, Nov 28 2012, Sebastian Andrzej Siewior wrote:
> >>Well. You need only to remove the directories you created.
> >
> >My point is that there should be a way to write a script that is unaware
> >of the way function is configured, ie. which directories were created
> >and which were not.
As I stated above, I expect that tools will know which is which.
But having said that, a major goal of configfs is that it is discoverable and
transparent. So you have to be able to distinguish between default
groups and created directories. When you rmdir a configfs directory,
EACCESS means you don't have permission, ENOTEMPTY means there are children,
EBUSY means there is a depend or a link, and EPERM means it is a default
group.
> I get this. If you recursively rmdir each directory then you clean it
> up.
>
> >Besides, if you rmdir lun0, is the function still supposed to work with
> >all LUNs present? In my opinion, while gadget is bound, it should not
> >be possible to modify such things.
>
> That is correct. The configuration should remain frozen as long as the
> gadget is active because in most cases you can't propagate the change.
>
> >>An unbind would be simply an unlink of the gadget which is linked to
> >>the udc. All configurations remain so you can link it at a later
> >>point without touching the configuration because it is as it was.
> >
> >Yes, but that's not my concern. My concern is that I should be able to
> >put a relatively simple code in my shutdown script (or whatever) which
> >unbinds all gadgets, without knowing what kind of functions are used.
> >
> >And I'm proposing that this could be done by allowing user to just do:
> >
> > cd /cfs/...
> > rmdir gadgets/* # unbind and remove all gadgets
> > rmdir functions/*/* # unbind and remove all function instances
> > rmdir functions/* # unload all functions
>
> Yes, you push for simple rmdir API. That would avoid the need for an
> user land tool at some point and you end up in shell scripts.
> I'm not against it but others do have user tools to handle such things.
Yeah, user tools are expected (and should be).
> Anyway, for this to work we have to go through Joel.
>
> > rmdir udcs/*# unload all UDCs
>
> No, for this you still have to rmmod :)
>
>
> >>>I think the question is of information flow direction. If user gives
> >>>some information to the kernel, she should be the one creating any
> >>>necessary directories. But if the information comes from kernel to the
> >>>user, the kernel should create the structure.
This last paragraph actually describes the distinction between
configfs and sysfs. More specifically, if userspace wants to create an
object in the kernel, it should use configfs. If the kernel has created
an object on its own, it exposes it via sysfs. It is a deliberate
non-goal for configfs to replicate sysfs behavior.
[General Thoughts]
First let me restate your problem to see if I understand it.
You want to expose e.g. five LUNs. They should eventually appear
in configfs as five items to configure (.../{lun0,lun1,...lun4}/. The
current configfs way to do this is to have your setup script do:
cd /cfg/.../mass_storage
mkdir lun0
echo blah >lun0/attr1
echo blahh >lun0/attr2
mkdir lun1
echo blag >lun1/attr1
echo blagg >lun1/attr1
...
I think the primary concern expressed by Andrzej is that a random user
could come along and say "mkdir lun8", even though the gadget cannot
support it. A secondary concern from Michal is that userspace has to
run all of those mkdirs. The thread has described varying solutions.
If these original directories were default_groups, you could
disallow any
Re: [PATCH] fs/configfs: allow to create groups on demand
On Thu, Nov 29, 2012 at 05:41:23PM +0100, Sebastian Andrzej Siewior wrote:
> This patch adds a function add a group to an existing one and its
> counterart. The newly created group behaves as it would be created via
> default_groups[] which means the user can't rmdir it.
> This should be used by the upcomming USB gadget interface in order to
> add the currently available UDCs as a child of the UDC node. The UDC
> itself will appear once the hardware driver is loaded and can appear
> later.
I've now responded to the original thread. Sorry I didn't notice last
week. Please see my thoughts there and comment.
Joel
>
> Signed-off-by: Sebastian Andrzej Siewior
> ---
> fs/configfs/dir.c| 63
> ++
> include/linux/configfs.h |4 +++
> 2 files changed, 51 insertions(+), 16 deletions(-)
>
> diff --git a/fs/configfs/dir.c b/fs/configfs/dir.c
> index 7414ae2..50ee2bd 100644
> --- a/fs/configfs/dir.c
> +++ b/fs/configfs/dir.c
> @@ -1663,19 +1663,13 @@ const struct file_operations configfs_dir_operations
> = {
> .readdir= configfs_readdir,
> };
>
> -int configfs_register_subsystem(struct configfs_subsystem *subsys)
> +static int __create_group(struct config_group *group, struct dentry *root)
> {
> int err;
> - struct config_group *group = &subsys->su_group;
> struct qstr name;
> struct dentry *dentry;
> - struct dentry *root;
> struct configfs_dirent *sd;
>
> - root = configfs_pin_fs();
> - if (IS_ERR(root))
> - return PTR_ERR(root);
> -
> if (!group->cg_item.ci_name)
> group->cg_item.ci_name = group->cg_item.ci_namebuf;
>
> @@ -1708,25 +1702,48 @@ int configfs_register_subsystem(struct
> configfs_subsystem *subsys)
>
> mutex_unlock(&root->d_inode->i_mutex);
>
> - if (err) {
> + if (err)
> unlink_group(group);
> - configfs_release_fs();
> +
> + return err;
> +}
> +
> +int configfs_create_group(struct config_group *parent, struct config_group
> *new)
> +{
> + int ret;
> +
> + ret = __create_group(new, parent->cg_item.ci_dentry);
> + if (!ret) {
> + struct configfs_dirent *sd = new->cg_item.ci_dentry->d_fsdata;
> +
> + sd->s_type |= CONFIGFS_USET_DEFAULT;
> }
>
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(configfs_create_group);
> +
> +int configfs_register_subsystem(struct configfs_subsystem *subsys)
> +{
> + int err;
> + struct dentry *root;
> +
> + root = configfs_pin_fs();
> + if (IS_ERR(root))
> + return PTR_ERR(root);
> +
> + err = __create_group(&subsys->su_group, root);
> + if (err)
> + configfs_release_fs();
> +
> return err;
> }
>
> -void configfs_unregister_subsystem(struct configfs_subsystem *subsys)
> +void configfs_remove_group(struct config_group *group)
> {
> - struct config_group *group = &subsys->su_group;
> struct dentry *dentry = group->cg_item.ci_dentry;
> struct dentry *root = dentry->d_sb->s_root;
>
> - if (dentry->d_parent != root) {
> - printk(KERN_ERR "configfs: Tried to unregister
> non-subsystem!\n");
> - return;
> - }
> -
> mutex_lock_nested(&root->d_inode->i_mutex,
> I_MUTEX_PARENT);
> mutex_lock_nested(&dentry->d_inode->i_mutex, I_MUTEX_CHILD);
> @@ -1749,6 +1766,20 @@ void configfs_unregister_subsystem(struct
> configfs_subsystem *subsys)
> dput(dentry);
>
> unlink_group(group);
> +}
> +EXPORT_SYMBOL_GPL(configfs_remove_group);
> +
> +void configfs_unregister_subsystem(struct configfs_subsystem *subsys)
> +{
> + struct config_group *group = &subsys->su_group;
> + struct dentry *dentry = group->cg_item.ci_dentry;
> + struct dentry *root = dentry->d_sb->s_root;
> +
> + if (dentry->d_parent != root) {
> + pr_err("configfs: Tried to unregister non-subsystem!\n");
> + return;
> + }
> + configfs_remove_group(group);
> configfs_release_fs();
> }
>
> diff --git a/include/linux/configfs.h b/include/linux/configfs.h
> index 34025df..660c25d 100644
> --- a/include/linux/configfs.h
> +++ b/include/linux/configfs.h
> @@ -249,6 +249,10 @@ static inline struct configfs_subsystem
> *to_configfs_subsystem(struct config_gro
> NULL;
> }
>
> +int configfs_create_group(struct config_group *parent,
> + struct config_group *new);
> +void configfs_remove_group(struct config_group *group);
> +
> int configfs_register_subsystem(struct configfs_subsystem *subsys);
> void configfs_unregister_subsystem(struct configfs_subsystem *subsys);
>
> --
> 1.7.10.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
"Frie
Re: Need help for hardware bug in Intel's EHCI implementation
On Fri, Dec 07, 2012 at 05:51:55PM -0500, Alan Stern wrote: > Sarah: > > I just tracked down a tricky problem, which appears to be caused by a > genuine hardware bug. It's hard to believe this has escaped everyone's > notice for so many years -- maybe my results are wrong. But as far as > I can tell, they aren't. > > Anyway, I don't know what to do about it. Can you forward this message > to an appropriate person at Intel? Sure, I'll try to track the right hardware person down. I'm afraid they might not be able to help, because they may not remember hardware that is that old. :-/ Sarah Sharp -- 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
