Re: cdc_acm / cdc_wdm issue. Connection to device lost (Sony Ericsson w660)
On Thu, 2015-06-18 at 21:30 +0200, Fab Stz wrote: > Hello, > > I'm facing some issues to connect to my mobile phone (Sony Ericsson W660i) > > I use Gammu/Wammu to connect to my mobile phone > With kernel 3.2 (debian wheezy) it works fine. But with kernel 3.16 (debian > jessie) or even 4.0.2 it doesn't work. > > Moreover, the connection of the phone to the PC makes some configuration > changes on my phone. It changes my netwok connection type from "2G only" to > "2G/3G" for obscure reasons In which kernel? > BTW, it seems the connection gets lost when the phone backlight turns off That suggest a power management issue. Does the backlight turn off with the older kernel? > Here is the dmesg when I connect the phone > [ 1536.912061] usb 3-2: new full-speed USB device number 2 using uhci_hcd > [ 1537.168027] usb 3-2: New USB device found, idVendor=0fce, idProduct=d0a3 > [ 1537.168035] usb 3-2: New USB device strings: Mfr=1, Product=2, > SerialNumber=3 > [ 1537.168040] usb 3-2: Product: Sony Ericsson W660 > [ 1537.168044] usb 3-2: Manufacturer: Sony Ericsson > [ 1537.168048] usb 3-2: SerialNumber: 3571550133112050 > [ 1537.371402] cdc_ether 3-2:3.8 usb0: register 'cdc_ether' at > usb-:00:1d.1-2, CDC Ethernet Device, 02:80:37:fa:02:00 > [ 1537.371459] usbcore: registered new interface driver cdc_ether > [ 1537.380242] cdc_wdm 3-2:3.7: cdc-wdm0: USB WDM device > [ 1537.380282] usbcore: registered new interface driver cdc_wdm > [ 1537.382752] cdc_acm 3-2:3.1: ttyACM0: USB ACM device > [ 1537.387047] cdc_acm 3-2:3.3: ttyACM1: USB ACM device > [ 1537.389890] usbcore: registered new interface driver cdc_acm > [ 1537.389894] cdc_acm: USB Abstract Control Model driver for USB modems and > ISDN adapters > [ 1537.424010] cdc_wdm 3-2:3.7: wdm_int_callback - 0 bytes > [ 1537.446697] cdc_ether 3-2:3.8 usb0: kevent 12 may have been dropped There is no disconnection in the log on the USB level. What exactly do you mean by disconnection? > I already reported the following bug > https://bugzilla.kernel.org/show_bug.cgi?id=100091 > > Is there anything to do ? Fix ? Please try with usb.autosuspend=-1 on the kernel command line. Regards Oliver -- 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: class: Use USB_CLASS_PRINTER instead of number 7
Kernel provides very nice defines for USB device class
so it's a good idea to use them in suitable places.
It is much easier to grep for such define instead of 7.
Signed-off-by: Krzysztof Opasiak
---
drivers/usb/class/usblp.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/class/usblp.c b/drivers/usb/class/usblp.c
index 0924ee4..24dcd53 100644
--- a/drivers/usb/class/usblp.c
+++ b/drivers/usb/class/usblp.c
@@ -57,6 +57,7 @@
#include
#undef DEBUG
#include
+#include
#include
/*
@@ -1401,12 +1402,12 @@ static int usblp_resume(struct usb_interface *intf)
}
static const struct usb_device_id usblp_ids[] = {
- { USB_DEVICE_INFO(7, 1, 1) },
- { USB_DEVICE_INFO(7, 1, 2) },
- { USB_DEVICE_INFO(7, 1, 3) },
- { USB_INTERFACE_INFO(7, 1, 1) },
- { USB_INTERFACE_INFO(7, 1, 2) },
- { USB_INTERFACE_INFO(7, 1, 3) },
+ { USB_DEVICE_INFO(USB_CLASS_PRINTER, 1, 1) },
+ { USB_DEVICE_INFO(USB_CLASS_PRINTER, 1, 2) },
+ { USB_DEVICE_INFO(USB_CLASS_PRINTER, 1, 3) },
+ { USB_INTERFACE_INFO(USB_CLASS_PRINTER, 1, 1) },
+ { USB_INTERFACE_INFO(USB_CLASS_PRINTER, 1, 2) },
+ { USB_INTERFACE_INFO(USB_CLASS_PRINTER, 1, 3) },
{ USB_DEVICE(0x04b8, 0x0202) }, /* Seiko Epson Receipt Printer M129C */
{ } /* Terminating entry */
};
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb: gadget: loopback: Remove out-of-date comment
As loopback function has been reworked for ConfigFS
composite gadget this comment is no longer valid.
Signed-off-by: Krzysztof Opasiak
---
drivers/usb/gadget/function/f_loopback.c |5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/usb/gadget/function/f_loopback.c
b/drivers/usb/gadget/function/f_loopback.c
index 39f49f1..6e2fe63 100644
--- a/drivers/usb/gadget/function/f_loopback.c
+++ b/drivers/usb/gadget/function/f_loopback.c
@@ -28,11 +28,6 @@
* This takes messages of various sizes written OUT to a device, and loops
* them back so they can be read IN from it. It has been used by certain
* test applications. It supports limited testing of data queueing logic.
- *
- *
- * This is currently packaged as a configuration driver, which can't be
- * combined with other functions to make composite devices. However, it
- * can be combined with other independent configurations.
*/
struct f_loopback {
struct usb_function function;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb: gadget: SourceSink: Remove out-of-date comment
As SourceSink function has been reworked for ConfigFS
composite gadget this comment is no longer valid.
Signed-off-by: Krzysztof Opasiak
---
drivers/usb/gadget/function/f_sourcesink.c |5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/usb/gadget/function/f_sourcesink.c
b/drivers/usb/gadget/function/f_sourcesink.c
index 3a5ae99..e6af171 100644
--- a/drivers/usb/gadget/function/f_sourcesink.c
+++ b/drivers/usb/gadget/function/f_sourcesink.c
@@ -42,11 +42,6 @@
* queues are relatively independent, will receive a range of packet sizes,
* and can often be made to run out completely. Those issues are important
* when stress testing peripheral controller drivers.
- *
- *
- * This is currently packaged as a configuration driver, which can't be
- * combined with other functions to make composite devices. However, it
- * can be combined with other independent configurations.
*/
struct f_sourcesink {
struct usb_function function;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Configfs usb mass_storage device always reports 8 LUNs ?
Hi all, I'm running 4.1-rc4 (Linaro 5.15) and trying to create a mass storage gadget via configfs, with default 1 LUN (lun.0). As the configfs progresses, I see "Number of LUNs=8". And when plugged in, the USB class specific getMaxLun request returns 7. In some Windows drivers (but not some others ?!), this MAX_LUN is taken into account and Windows tries to load class drivers for the additional 7 duff LUNs - resulting in "Device driver software was not correctly installed". With debug added to f_mass_storage.c, I get the following : [ 469.402527] Number of LUNs=8 (fsg_common_set_nluns), with stack : [ 469.402611] CPU: 2 PID: 1590 Comm: mkdir Not tainted 4.1.0-1-linaro-vexpress64 #15 [ 469.402680] Hardware name: FVP Base (DT) [ 469.402730] Call trace: [ 469.402808] [] dump_backtrace+0x0/0x164 [ 469.402897] [] show_stack+0x1c/0x28 [ 469.402975] [] dump_stack+0x84/0xc8 [ 469.403061] [] fsg_common_set_nluns+0x74/0xa4 [ 469.403152] [] fsg_alloc_inst+0xe4/0x218 [ 469.403245] [] try_get_usb_function_instance+0xb4/0xf0 [ 469.403342] [] usb_get_function_instance+0x1c/0x68 [ 469.403425] [] function_make+0x78/0x138 [ 469.403510] [] configfs_mkdir+0x110/0x38c [ 469.403591] [] vfs_mkdir+0xf4/0x190 [ 469.403673] [] SyS_mkdirat+0xe4/0xf0 [ 469.403755] Mass Storage Function, version: 2009/09/11 [ 469.403823] LUN: removable file: (no medium) [ 469.448719] Number of LUNs=8 (fsg_bind), with stack : [ 469.448799] CPU: 1 PID: 1576 Comm: start_dwusb_dev Not tainted 4.1.0-1-linaro-vexpress64 #15 [ 469.448872] Hardware name: FVP Base (DT) [ 469.448921] Call trace: [ 469.448999] [] dump_backtrace+0x0/0x164 [ 469.449088] [] show_stack+0x1c/0x28 [ 469.449167] [] dump_stack+0x84/0xc8 [ 469.449253] [] fsg_bind+0x1a4/0x1b0 [ 469.449340] [] usb_add_function+0x74/0x188 [ 469.449437] [] configfs_composite_bind+0x22c/0x33c [ 469.449524] [] udc_bind_to_driver+0x54/0x11c [ 469.449609] [] usb_udc_attach_driver+0x8c/0xc8 [ 469.449693] [] gadget_dev_desc_UDC_store+0xc0/0x104 [ 469.449789] [] gadget_info_attr_store+0x40/0x5c [ 469.449875] [] configfs_write_file+0xc4/0x128 [ 469.449958] [] __vfs_write+0x44/0x130 [ 469.450039] [] vfs_write+0x98/0x178 [ 469.450119] [] SyS_write+0x50/0xb0 Configfs tree is : drwxr-xr-x3 root root 0 Jun 19 11:40 /sys/kernel/config/usb_gadget/ drwxr-xr-x6 root root 0 Jun 19 11:41 /sys/kernel/config/usb_gadget/g1 drwxr-xr-x2 root root 0 Jun 19 11:41 /sys/kernel/config/usb_gadget/g1/os_desc -rw-r--r--1 root root 4096 Jun 19 11:42 /sys/kernel/config/usb_gadget/g1/os_desc/qw_sign -rw-r--r--1 root root 4096 Jun 19 11:42 /sys/kernel/config/usb_gadget/g1/os_desc/b_vendor_code -rw-r--r--1 root root 4096 Jun 19 11:42 /sys/kernel/config/usb_gadget/g1/os_desc/use drwxr-xr-x3 root root 0 Jun 19 11:40 /sys/kernel/config/usb_gadget/g1/strings drwxr-xr-x2 root root 0 Jun 19 11:41 /sys/kernel/config/usb_gadget/g1/strings/0x409 -rw-r--r--1 root root 4096 Jun 19 11:40 /sys/kernel/config/usb_gadget/g1/strings/0x409/serialnumber -rw-r--r--1 root root 4096 Jun 19 11:40 /sys/kernel/config/usb_gadget/g1/strings/0x409/product -rw-r--r--1 root root 4096 Jun 19 11:40 /sys/kernel/config/usb_gadget/g1/strings/0x409/manufacturer drwxr-xr-x3 root root 0 Jun 19 11:40 /sys/kernel/config/usb_gadget/g1/configs drwxr-xr-x3 root root 0 Jun 19 11:41 /sys/kernel/config/usb_gadget/g1/configs/c.1 lrwxrwxrwx1 root root 0 Jun 19 11:40 /sys/kernel/config/usb_gadget/g1/configs/c.1/mass_storage.0 -> ../../../../usb_gadget/g1/functions/mass_storage.0 drwxr-xr-x3 root root 0 Jun 19 11:40 /sys/kernel/config/usb_gadget/g1/configs/c.1/strings drwxr-xr-x2 root root 0 Jun 19 11:41 /sys/kernel/config/usb_gadget/g1/configs/c.1/strings/0x409 -rw-r--r--1 root root 4096 Jun 19 11:40 /sys/kernel/config/usb_gadget/g1/configs/c.1/strings/0x409/configuration -rw-r--r--1 root root 4096 Jun 19 11:42 /sys/kernel/config/usb_gadget/g1/configs/c.1/bmAttributes -rw-r--r--1 root root 4096 Jun 19 11:40 /sys/kernel/config/usb_gadget/g1/configs/c.1/MaxPower drwxr-xr-x3 root root 0 Jun 19 11:40 /sys/kernel/config/usb_gadget/g1/functions drwxr-xr-x3 root root 0 Jun 19 11:41 /sys/kernel/config/usb_gadget/g1/functions/mass_storage.0 drwxr-xr-x2 root root 0 Jun 19 11:41 /sys/kernel/config/usb_gadget/g1/functions/mass_storage.0/lun.0 -rw-r--r--1 root root 4096 Jun 19 11:42 /sys/kernel/config/usb_gadget/g1/functions/mass_storage.0/lun.0/nofua -rw-r--r--1 root root 4096 Jun 19 11:42 /sys/kernel/config/usb_gadget/g1/functions/mass_storage.0/lun.0/cdrom -rw-r--r--1 root root
Configfs usb mass_storage device always reports 8 LUNs ?
diff --git a/drivers/usb/gadget/function/f_mass_storage.c
b/drivers/usb/gadget/function/f_mass_storage.c
index 3cc109f..f502f00 100644
--- a/drivers/usb/gadget/function/f_mass_storage.c
+++ b/drivers/usb/gadget/function/f_mass_storage.c
@@ -2796,8 +2796,6 @@ int fsg_common_set_nluns(struct fsg_common *common, int
nluns)
common->luns = curlun;
common->nluns = nluns;
- pr_info("Number of LUNs=%d\n", common->nluns);
-
return 0;
}
EXPORT_SYMBOL_GPL(fsg_common_set_nluns);
@@ -2941,6 +2939,9 @@ int fsg_common_create_lun(struct fsg_common *common,
struct fsg_lun_config *cfg,
p = "(error)";
}
}
+
+ common->nluns = id + 1;
+
pr_info("LUN: %s%s%sfile: %s\n",
lun->removable ? "removable " : "",
lun->ro ? "read only " : "",
@@ -2973,8 +2974,6 @@ int fsg_common_create_luns(struct fsg_common *common,
struct fsg_config *cfg)
goto fail;
}
- pr_info("Number of LUNs=%d\n", common->nluns);
-
return 0;
fail:
@@ -3121,6 +3120,8 @@ static int fsg_bind(struct usb_configuration *c, struct
usb_function *f)
if (ret)
goto autoconf_fail;
+ pr_info("Number of LUNs=%d\n", fsg->common->nluns);
+
return 0;
autoconf_fail:
Is this something that needs fixing or am I misunderstanding how configfs usb
mass storage is supposed to work or be configured ?
Thanks in advance for any help,
David
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
Re: Configfs usb mass_storage device always reports 8 LUNs ?
Hi, On Fri, Jun 19, 2015 at 01:59:40PM +, David Fisher wrote: > Hi all, > > I'm running 4.1-rc4 (Linaro 5.15) and trying to create a mass storage > gadget via configfs, with default 1 LUN (lun.0). As the configfs > progresses, I see "Number of LUNs=8". And when plugged in, the USB > class specific getMaxLun request returns 7. In some Windows drivers > (but not some others ?!), this MAX_LUN is taken into account and > Windows tries to load class drivers for the additional 7 duff LUNs - > resulting in "Device driver software was not correctly installed". > > With debug added to f_mass_storage.c, I get the following : > > [ 469.402527] Number of LUNs=8 (fsg_common_set_nluns), with stack : > [ 469.402611] CPU: 2 PID: 1590 Comm: mkdir Not tainted > 4.1.0-1-linaro-vexpress64 #15 > [ 469.402680] Hardware name: FVP Base (DT) > [ 469.402730] Call trace: > [ 469.402808] [] dump_backtrace+0x0/0x164 > [ 469.402897] [] show_stack+0x1c/0x28 > [ 469.402975] [] dump_stack+0x84/0xc8 > [ 469.403061] [] fsg_common_set_nluns+0x74/0xa4 > [ 469.403152] [] fsg_alloc_inst+0xe4/0x218 > [ 469.403245] [] try_get_usb_function_instance+0xb4/0xf0 > [ 469.403342] [] usb_get_function_instance+0x1c/0x68 > [ 469.403425] [] function_make+0x78/0x138 > [ 469.403510] [] configfs_mkdir+0x110/0x38c > [ 469.403591] [] vfs_mkdir+0xf4/0x190 > [ 469.403673] [] SyS_mkdirat+0xe4/0xf0 > [ 469.403755] Mass Storage Function, version: 2009/09/11 > [ 469.403823] LUN: removable file: (no medium) > [ 469.448719] Number of LUNs=8 (fsg_bind), with stack : > [ 469.448799] CPU: 1 PID: 1576 Comm: start_dwusb_dev Not tainted > 4.1.0-1-linaro-vexpress64 #15 > [ 469.448872] Hardware name: FVP Base (DT) > [ 469.448921] Call trace: > [ 469.448999] [] dump_backtrace+0x0/0x164 > [ 469.449088] [] show_stack+0x1c/0x28 > [ 469.449167] [] dump_stack+0x84/0xc8 > [ 469.449253] [] fsg_bind+0x1a4/0x1b0 > [ 469.449340] [] usb_add_function+0x74/0x188 > [ 469.449437] [] configfs_composite_bind+0x22c/0x33c > [ 469.449524] [] udc_bind_to_driver+0x54/0x11c > [ 469.449609] [] usb_udc_attach_driver+0x8c/0xc8 > [ 469.449693] [] gadget_dev_desc_UDC_store+0xc0/0x104 > [ 469.449789] [] gadget_info_attr_store+0x40/0x5c > [ 469.449875] [] configfs_write_file+0xc4/0x128 > [ 469.449958] [] __vfs_write+0x44/0x130 > [ 469.450039] [] vfs_write+0x98/0x178 > [ 469.450119] [] SyS_write+0x50/0xb0 > > Configfs tree is : > > drwxr-xr-x3 root root 0 Jun 19 11:40 > /sys/kernel/config/usb_gadget/ > drwxr-xr-x6 root root 0 Jun 19 11:41 > /sys/kernel/config/usb_gadget/g1 > drwxr-xr-x2 root root 0 Jun 19 11:41 > /sys/kernel/config/usb_gadget/g1/os_desc > -rw-r--r--1 root root 4096 Jun 19 11:42 > /sys/kernel/config/usb_gadget/g1/os_desc/qw_sign > -rw-r--r--1 root root 4096 Jun 19 11:42 > /sys/kernel/config/usb_gadget/g1/os_desc/b_vendor_code > -rw-r--r--1 root root 4096 Jun 19 11:42 > /sys/kernel/config/usb_gadget/g1/os_desc/use > drwxr-xr-x3 root root 0 Jun 19 11:40 > /sys/kernel/config/usb_gadget/g1/strings > drwxr-xr-x2 root root 0 Jun 19 11:41 > /sys/kernel/config/usb_gadget/g1/strings/0x409 > -rw-r--r--1 root root 4096 Jun 19 11:40 > /sys/kernel/config/usb_gadget/g1/strings/0x409/serialnumber > -rw-r--r--1 root root 4096 Jun 19 11:40 > /sys/kernel/config/usb_gadget/g1/strings/0x409/product > -rw-r--r--1 root root 4096 Jun 19 11:40 > /sys/kernel/config/usb_gadget/g1/strings/0x409/manufacturer > drwxr-xr-x3 root root 0 Jun 19 11:40 > /sys/kernel/config/usb_gadget/g1/configs > drwxr-xr-x3 root root 0 Jun 19 11:41 > /sys/kernel/config/usb_gadget/g1/configs/c.1 > lrwxrwxrwx1 root root 0 Jun 19 11:40 > /sys/kernel/config/usb_gadget/g1/configs/c.1/mass_storage.0 -> > ../../../../usb_gadget/g1/functions/mass_storage.0 > drwxr-xr-x3 root root 0 Jun 19 11:40 > /sys/kernel/config/usb_gadget/g1/configs/c.1/strings > drwxr-xr-x2 root root 0 Jun 19 11:41 > /sys/kernel/config/usb_gadget/g1/configs/c.1/strings/0x409 > -rw-r--r--1 root root 4096 Jun 19 11:40 > /sys/kernel/config/usb_gadget/g1/configs/c.1/strings/0x409/configuration > -rw-r--r--1 root root 4096 Jun 19 11:42 > /sys/kernel/config/usb_gadget/g1/configs/c.1/bmAttributes > -rw-r--r--1 root root 4096 Jun 19 11:40 > /sys/kernel/config/usb_gadget/g1/configs/c.1/MaxPower > drwxr-xr-x3 root root 0 Jun 19 11:40 > /sys/kernel/config/usb_gadget/g1/functions > drwxr-xr-x3 root root 0 Jun 19 11:41 > /sys/kernel/config/usb_gadget/g1/functions/mass_storage.0 > drwxr-xr-x2 root root 0 Jun 19 11:41 > /sys/kernel/config/usb_gadget/g1/functions/mass_storage.0/lun.0 > -rw-r--r--1 root root
Re: cdc_acm / cdc_wdm issue. Connection to device lost (Sony Ericsson w660)
Oh ! I just realized my mistake. Actually it is not the kernel that is faulty but my configuration (since I migrated from debian wheezy to jessie). I had connection/disconnection issues because of conflicts between gammu and ModemManager. It is also ModemManager which took the control of my phone and switched to 3G network. Now that I disabled NetworkManager for my phone, I don't have such issues any more with kernel 3.16 or 4.0 (backlight still extincts, but that's by design for my phone) Sorry for that. Kind regards Fab -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in
Re: Configfs usb mass_storage device always reports 8 LUNs ?
> On Fri, Jun 19, 2015 at 01:59:40PM +, David Fisher wrote:
>> My interpretation of this is that common->nluns is only ever set in
>> fsg_alloc_inst() "rc = fsg_common_set_nluns(opts->common,
>> FSG_MAX_LUNS);"
>> It doesn't take account of how many luns have been setup in the
>> configfs tree.
On Fri, Jun 19 2015, Felipe Balbi wrote:
> your interpretation is correct.
>
>> I have applied a hack/fix which works for me, though it needs tweaks
>> and further testing given recent f_mass_storage.c patches I've seen
>> floating about. This patch updates common->nluns on each
>> fsg_common_create_lun(), and only prints Number of LUNs on fsg_bind
>> when the configfs tree should be all there. Also assumes contiguous
>> incrementing lun ids.
>
> this makes sense to me although we need this in a proper patch format
> (have a look at Documentation/SubmittingPatches and
> Documentation/SubmitChecklist)
>
> Michal, any comments to this diff ?
>
>> diff --git a/drivers/usb/gadget/function/f_mass_storage.c
>> b/drivers/usb/gadget/function/f_mass_storage.c
>> index 3cc109f..f502f00 100644
>> --- a/drivers/usb/gadget/function/f_mass_storage.c
>> +++ b/drivers/usb/gadget/function/f_mass_storage.c
>> @@ -2796,8 +2796,6 @@ int fsg_common_set_nluns(struct fsg_common *common,
>> int nluns)
>> common->luns = curlun;
>> common->nluns = nluns;
>>
>> -pr_info("Number of LUNs=%d\n", common->nluns);
>> -
>> return 0;
>> }
>> EXPORT_SYMBOL_GPL(fsg_common_set_nluns);
>> @@ -2941,6 +2939,9 @@ int fsg_common_create_lun(struct fsg_common *common,
>> struct fsg_lun_config *cfg,
>> p = "(error)";
>> }
>> }
>> +
>> +common->nluns = id + 1;
>> +
This breaks fsg_common_create_luns. If configfs interface allows for
a single LUN only (which I think is the case), just change
rc = fsg_common_set_nluns(opts->common, FSG_MAX_LUNS);
to
/* Only one LUN is supported via configfs */
rc = fsg_common_set_nluns(opts->common, 1);
in fsg_alloc_inst.
>> pr_info("LUN: %s%s%sfile: %s\n",
>>lun->removable ? "removable " : "",
>>lun->ro ? "read only " : "",
>> @@ -2973,8 +2974,6 @@ int fsg_common_create_luns(struct fsg_common *common,
>> struct fsg_config *cfg)
>> goto fail;
>> }
>>
>> -pr_info("Number of LUNs=%d\n", common->nluns);
>> -
>> return 0;
>>
>> fail:
>> @@ -3121,6 +3120,8 @@ static int fsg_bind(struct usb_configuration *c,
>> struct usb_function *f)
>> if (ret)
>> goto autoconf_fail;
>>
>> +pr_info("Number of LUNs=%d\n", fsg->common->nluns);
>> +
>> return 0;
>>
>> autoconf_fail:
>>
>>
>>
>> Is this something that needs fixing or am I misunderstanding how
>> configfs usb mass storage is supposed to work or be configured ?
>
> it certainly needs to be fixed.
>
> --
> balbi
--
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o
..o | Computer Science, Michał “mina86” Nazarewicz(o o)
ooo +--ooO--(_)--Ooo--
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
Re: [PATCH] usb: class: Use USB_CLASS_PRINTER instead of number 7
On Fri, 19 Jun 2015 11:37:08 +0200
Krzysztof Opasiak wrote:
> Kernel provides very nice defines for USB device class
> so it's a good idea to use them in suitable places.
> It is much easier to grep for such define instead of 7.
> static const struct usb_device_id usblp_ids[] = {
> - { USB_INTERFACE_INFO(7, 1, 3) },
> + { USB_INTERFACE_INFO(USB_CLASS_PRINTER, 1, 3) },
> { USB_DEVICE(0x04b8, 0x0202) }, /* Seiko Epson Receipt Printer M129C */
If you're concerned about grepping, then fix all other places like
usblp_select_alts(), too.
-- Pete
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
Xenta Mouse Wireless sometimes not working in Linux Kernel 4.0.5
Sometimes generic mice usb wireless not work with usb_modeswitch enabled. dmesg | grep usb output when kernel not find device descriptors for mouse: [ 154.988937] usb 2-3: new full-speed USB device number 9 using xhci_hcd [ 160.159445] usb 2-3: unable to read config index 0 descriptor/start: -110 [ 160.159450] usb 2-3: can't read configurations, error -110 [ 160.319415] usb 2-3: new full-speed USB device number 10 using xhci_hcd [ 165.489805] usb 2-3: unable to read config index 0 descriptor/start: -110 [ 165.489815] usb 2-3: can't read configurations, error -110 after I disable usb_modeswitch or unplug and plug mouse several times... [ 165.649708] usb 2-3: new full-speed USB device number 11 using xhci_hcd [ 165.705290] usbcore: registered new interface driver usbhid [ 165.705293] usbhid: USB HID core driver [ 165.739693] input: HID Wireless Mouse HID Wireless Mouse as /devices/pci:00/:00:14.0/usb2/2-3/2-3:1.0/0003:1D57:0016.0001/input/input17 [ 165.739838] hid-generic 0003:1D57:0016.0001: input,hidraw0: USB HID v1.10 Mouse [HID Wireless Mouse HID Wireless Mouse] on usb-:00:14.0-3/input0 I know it use Xenta drivers for lsusb: Bus 002 Device 011: ID 1d57:0016 Xenta. Thanks. Sorry for my English, I'm from Colombia. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in
Re: Configfs usb mass_storage device always reports 8 LUNs ?
Hi,
On Fri, Jun 19, 2015 at 09:00:26PM +0200, Michal Nazarewicz wrote:
> > On Fri, Jun 19, 2015 at 01:59:40PM +, David Fisher wrote:
> >> My interpretation of this is that common->nluns is only ever set in
> >> fsg_alloc_inst() "rc = fsg_common_set_nluns(opts->common,
> >> FSG_MAX_LUNS);"
> >> It doesn't take account of how many luns have been setup in the
> >> configfs tree.
>
> On Fri, Jun 19 2015, Felipe Balbi wrote:
> > your interpretation is correct.
> >
> >> I have applied a hack/fix which works for me, though it needs tweaks
> >> and further testing given recent f_mass_storage.c patches I've seen
> >> floating about. This patch updates common->nluns on each
> >> fsg_common_create_lun(), and only prints Number of LUNs on fsg_bind
> >> when the configfs tree should be all there. Also assumes contiguous
> >> incrementing lun ids.
> >
> > this makes sense to me although we need this in a proper patch format
> > (have a look at Documentation/SubmittingPatches and
> > Documentation/SubmitChecklist)
> >
> > Michal, any comments to this diff ?
> >
> >> diff --git a/drivers/usb/gadget/function/f_mass_storage.c
> >> b/drivers/usb/gadget/function/f_mass_storage.c
> >> index 3cc109f..f502f00 100644
> >> --- a/drivers/usb/gadget/function/f_mass_storage.c
> >> +++ b/drivers/usb/gadget/function/f_mass_storage.c
> >> @@ -2796,8 +2796,6 @@ int fsg_common_set_nluns(struct fsg_common *common,
> >> int nluns)
> >>common->luns = curlun;
> >>common->nluns = nluns;
> >>
> >> - pr_info("Number of LUNs=%d\n", common->nluns);
> >> -
> >>return 0;
> >> }
> >> EXPORT_SYMBOL_GPL(fsg_common_set_nluns);
> >> @@ -2941,6 +2939,9 @@ int fsg_common_create_lun(struct fsg_common *common,
> >> struct fsg_lun_config *cfg,
> >>p = "(error)";
> >>}
> >>}
> >> +
> >> + common->nluns = id + 1;
> >> +
>
> This breaks fsg_common_create_luns. If configfs interface allows for
> a single LUN only (which I think is the case), just change
>
> rc = fsg_common_set_nluns(opts->common, FSG_MAX_LUNS);
>
> to
>
> /* Only one LUN is supported via configfs */
> rc = fsg_common_set_nluns(opts->common, 1);
>
> in fsg_alloc_inst.
the fact is that this needs to be configurable from configfs. If user
sets up a single lun, then this should be as you said, however, if 2
luns are configured, I still want to have those 2 working.
From a user perspective, configfs should support N luns just fine as
long as we have enough memory available.
--
balbi
signature.asc
Description: Digital signature
Re: Configfs usb mass_storage device always reports 8 LUNs ?
On Fri, Jun 19 2015, Felipe Balbi wrote:
> the fact is that this needs to be configurable from configfs. If user
> sets up a single lun, then this should be as you said, however, if 2
> luns are configured, I still want to have those 2 working.
>
> From a user perspective, configfs should support N luns just fine as
> long as we have enough memory available.
Yes, sorry, you’re right. I didn’t fallow closely migration to configfs
based configuration and didn’t have the full picture.
After taking another look, I think the best solution is to have a loop
in fsg_alloc, something like the following (beware that this has not
been tested in any way):
>From 19ec2796009f8650c7db4358f7e16931ba96e4ee Mon Sep 17 00:00:00 2001
From: Michal Nazarewicz
Date: Fri, 19 Jun 2015 23:56:34 +0200
Subject: [PATCH] usb: f_mass_storage: limit number of reported LUNs
Mass storage function created via configfs always reports eight LUNs
to the hosts even if only one LUN has been configured. Adjust the
number when the USB function is allocated based on LUNs that user
has created.
Signed-off-by: Michal Nazarewicz
---
drivers/usb/gadget/function/f_mass_storage.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/usb/gadget/function/f_mass_storage.c
b/drivers/usb/gadget/function/f_mass_storage.c
index 3cc109f..8e26a12 100644
--- a/drivers/usb/gadget/function/f_mass_storage.c
+++ b/drivers/usb/gadget/function/f_mass_storage.c
@@ -3563,14 +3563,28 @@ static struct usb_function *fsg_alloc(struct
usb_function_instance *fi)
struct fsg_opts *opts = fsg_opts_from_func_inst(fi);
struct fsg_common *common = opts->common;
struct fsg_dev *fsg;
+ unsigned nluns, i;
fsg = kzalloc(sizeof(*fsg), GFP_KERNEL);
if (unlikely(!fsg))
return ERR_PTR(-ENOMEM);
mutex_lock(&opts->lock);
+ if (!opts->refcnt) {
+ for (nluns = i = 0; i < FSG_MAX_LUNS; ++i)
+ if (common->luns[i])
+ nluns = i + 1;
+ if (!nluns) {
+ pr_warn("No LUNS defined, continuing anyway\n");
+ } else if (nluns != common->nluns) {
+ pr_info("Adjusting number of LUNs=%u (was %u)\n",
+ nluns, common->nluns);
+ common->nluns = nluns;
+ }
+ }
opts->refcnt++;
mutex_unlock(&opts->lock);
+
fsg->function.name = FSG_DRIVER_DESC;
fsg->function.bind = fsg_bind;
fsg->function.unbind= fsg_unbind;
--
2.4.3.573.g4eafbef
--
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o
..o | Computer Science, Michał “mina86” Nazarewicz(o o)
ooo +--ooO--(_)--Ooo--
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
