[PATCH 3/3] usb: gadget: storage-common: Fix old comment about qualifier descriptor
From: Krzysztof Opasiak
Device qualifier descriptor is now generated by composite.c
code. So let's fix this old comment by removing parts which
are no longer valid.
Signed-off-by: Krzysztof Opasiak
Signed-off-by: Krzysztof Opasiak
---
drivers/usb/gadget/function/storage_common.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/usb/gadget/function/storage_common.c
b/drivers/usb/gadget/function/storage_common.c
index d626830..990df22 100644
--- a/drivers/usb/gadget/function/storage_common.c
+++ b/drivers/usb/gadget/function/storage_common.c
@@ -83,9 +83,7 @@ EXPORT_SYMBOL_GPL(fsg_fs_function);
* USB 2.0 devices need to expose both high speed and full speed
* descriptors, unless they only run at full speed.
*
- * That means alternate endpoint descriptors (bigger packets)
- * and a "device qualifier" ... plus more construction options
- * for the configuration descriptor.
+ * That means alternate endpoint descriptors (bigger packets).
*/
struct usb_endpoint_descriptor fsg_hs_bulk_in_desc = {
.bLength = USB_DT_ENDPOINT_SIZE,
--
1.9.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 2/3] usb: gadget: uac2: Drop unused device qualifier descriptor
From: Krzysztof Opasiak
This descriptor is never used. Currently device qualifier
descriptor is generated by compossite code so no need to
keep it in function file.
Signed-off-by: Krzysztof Opasiak
Signed-off-by: Krzysztof Opasiak
---
drivers/usb/gadget/function/f_uac2.c | 12
1 file changed, 12 deletions(-)
diff --git a/drivers/usb/gadget/function/f_uac2.c
b/drivers/usb/gadget/function/f_uac2.c
index 186d4b1..1c81dd3 100644
--- a/drivers/usb/gadget/function/f_uac2.c
+++ b/drivers/usb/gadget/function/f_uac2.c
@@ -598,18 +598,6 @@ static struct usb_gadget_strings *fn_strings[] = {
NULL,
};
-static struct usb_qualifier_descriptor devqual_desc = {
- .bLength = sizeof devqual_desc,
- .bDescriptorType = USB_DT_DEVICE_QUALIFIER,
-
- .bcdUSB = cpu_to_le16(0x200),
- .bDeviceClass = USB_CLASS_MISC,
- .bDeviceSubClass = 0x02,
- .bDeviceProtocol = 0x01,
- .bNumConfigurations = 1,
- .bRESERVED = 0,
-};
-
static struct usb_interface_assoc_descriptor iad_desc = {
.bLength = sizeof iad_desc,
.bDescriptorType = USB_DT_INTERFACE_ASSOCIATION,
--
1.9.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 1/3] usb: gadget: printer: Drop unused device qualifier descriptor
From: Krzysztof Opasiak
This descriptor is never used. Currently device qualifier
descriptor is generated by compossite code, so no need to
keep it in function file.
Signed-off-by: Krzysztof Opasiak
Signed-off-by: Krzysztof Opasiak
---
drivers/usb/gadget/function/f_printer.c | 8
1 file changed, 8 deletions(-)
diff --git a/drivers/usb/gadget/function/f_printer.c
b/drivers/usb/gadget/function/f_printer.c
index c45104e..64706a7 100644
--- a/drivers/usb/gadget/function/f_printer.c
+++ b/drivers/usb/gadget/function/f_printer.c
@@ -161,14 +161,6 @@ static struct usb_endpoint_descriptor hs_ep_out_desc = {
.wMaxPacketSize = cpu_to_le16(512)
};
-static struct usb_qualifier_descriptor dev_qualifier = {
- .bLength = sizeof(dev_qualifier),
- .bDescriptorType = USB_DT_DEVICE_QUALIFIER,
- .bcdUSB = cpu_to_le16(0x0200),
- .bDeviceClass = USB_CLASS_PRINTER,
- .bNumConfigurations = 1
-};
-
static struct usb_descriptor_header *hs_printer_function[] = {
(struct usb_descriptor_header *) &intf_desc,
(struct usb_descriptor_header *) &hs_ep_in_desc,
--
1.9.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 49/54] MAINTAINERS: Add file patterns for usb device tree bindings
Submitters of device tree binding documentation may forget to CC the subsystem maintainer if this is missing. Signed-off-by: Geert Uytterhoeven Cc: Greg Kroah-Hartman Cc: linux-usb@vger.kernel.org --- Please apply this patch directly if you want to be involved in device tree binding documentation for your subsystem. --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index 4f8c1a45fead33af..d79cedf604642ee4 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -11994,6 +11994,7 @@ L: linux-usb@vger.kernel.org W: http://www.linux-usb.org T: git git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git S: Supported +F: Documentation/devicetree/bindings/usb/ F: Documentation/usb/ F: drivers/usb/ F: include/linux/usb.h -- 1.9.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
[regression] uas no longer queues commands since v4.5.2
With commit 198de51dbc3454d95b015ca0a055b673f85f01bb, uas no longer set `queue_depth` with scsi_change_queue_depth(), so now `queue_depth` of UAS drives are 1. Even though `can_queue` is set to `devinfo->qdepth - 2`, but apparently that does not help, since I can see performance impact. Suppose limiting `can_queue` is the right way to fix this bug (https://bugzilla.redhat.com/show_bug.cgi?id=1315013), do we really need to eliminate scsi_change_queue_depth() at the same time though? If so, how should we deal with the regression? -- 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: [regression] uas no longer queues commands since v4.5.2
Btw, I suppose `.can_queue = MAX_CMNDS` in the host template is unnecessary (unless we are going to revert `shost->can_queue = devinfo->qdepth - 2`)? On 22 May 2016 at 18:39, Tom Yan wrote: > With commit 198de51dbc3454d95b015ca0a055b673f85f01bb, uas no longer > set `queue_depth` with scsi_change_queue_depth(), so now `queue_depth` > of UAS drives are 1. Even though `can_queue` is set to > `devinfo->qdepth - 2`, but apparently that does not help, since I can > see performance impact. > > Suppose limiting `can_queue` is the right way to fix this bug > (https://bugzilla.redhat.com/show_bug.cgi?id=1315013), do we really > need to eliminate scsi_change_queue_depth() at the same time though? > If so, how should we deal with the regression? -- 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 resend] Documentation: configfs-usb-gadget-uvc: fix kernel version
v3.20 doesn't exist, it is actually v4.0. Signed-off-by: Alexandre Belloni --- Resend using correct address for Felipe Documentation/ABI/testing/configfs-usb-gadget-uvc | 58 +++ 1 file changed, 29 insertions(+), 29 deletions(-) diff --git a/Documentation/ABI/testing/configfs-usb-gadget-uvc b/Documentation/ABI/testing/configfs-usb-gadget-uvc index 2f4a0051b32d..1ba0d0fda9c0 100644 --- a/Documentation/ABI/testing/configfs-usb-gadget-uvc +++ b/Documentation/ABI/testing/configfs-usb-gadget-uvc @@ -1,6 +1,6 @@ What: /config/usb-gadget/gadget/functions/uvc.name Date: Dec 2014 -KernelVersion: 3.20 +KernelVersion: 4.0 Description: UVC function directory streaming_maxburst - 0..15 (ss only) @@ -9,37 +9,37 @@ Description: UVC function directory What: /config/usb-gadget/gadget/functions/uvc.name/control Date: Dec 2014 -KernelVersion: 3.20 +KernelVersion: 4.0 Description: Control descriptors What: /config/usb-gadget/gadget/functions/uvc.name/control/class Date: Dec 2014 -KernelVersion: 3.20 +KernelVersion: 4.0 Description: Class descriptors What: /config/usb-gadget/gadget/functions/uvc.name/control/class/ss Date: Dec 2014 -KernelVersion: 3.20 +KernelVersion: 4.0 Description: Super speed control class descriptors What: /config/usb-gadget/gadget/functions/uvc.name/control/class/fs Date: Dec 2014 -KernelVersion: 3.20 +KernelVersion: 4.0 Description: Full speed control class descriptors What: /config/usb-gadget/gadget/functions/uvc.name/control/terminal Date: Dec 2014 -KernelVersion: 3.20 +KernelVersion: 4.0 Description: Terminal descriptors What: /config/usb-gadget/gadget/functions/uvc.name/control/terminal/output Date: Dec 2014 -KernelVersion: 3.20 +KernelVersion: 4.0 Description: Output terminal descriptors What: /config/usb-gadget/gadget/functions/uvc.name/control/terminal/output/default Date: Dec 2014 -KernelVersion: 3.20 +KernelVersion: 4.0 Description: Default output terminal descriptors All attributes read only: @@ -53,12 +53,12 @@ Description:Default output terminal descriptors What: /config/usb-gadget/gadget/functions/uvc.name/control/terminal/camera Date: Dec 2014 -KernelVersion: 3.20 +KernelVersion: 4.0 Description: Camera terminal descriptors What: /config/usb-gadget/gadget/functions/uvc.name/control/terminal/camera/default Date: Dec 2014 -KernelVersion: 3.20 +KernelVersion: 4.0 Description: Default camera terminal descriptors All attributes read only: @@ -75,12 +75,12 @@ Description:Default camera terminal descriptors What: /config/usb-gadget/gadget/functions/uvc.name/control/processing Date: Dec 2014 -KernelVersion: 3.20 +KernelVersion: 4.0 Description: Processing unit descriptors What: /config/usb-gadget/gadget/functions/uvc.name/control/processing/default Date: Dec 2014 -KernelVersion: 3.20 +KernelVersion: 4.0 Description: Default processing unit descriptors All attributes read only: @@ -94,49 +94,49 @@ Description:Default processing unit descriptors What: /config/usb-gadget/gadget/functions/uvc.name/control/header Date: Dec 2014 -KernelVersion: 3.20 +KernelVersion: 4.0 Description: Control header descriptors What: /config/usb-gadget/gadget/functions/uvc.name/control/header/name Date: Dec 2014 -KernelVersion: 3.20 +KernelVersion: 4.0 Description: Specific control header descriptors dwClockFrequency bcdUVC What: /config/usb-gadget/gadget/functions/uvc.name/streaming Date: Dec 2014 -KernelVersion: 3.20 +KernelVersion: 4.0 Description: Streaming descriptors What: /config/usb-gadget/gadget/functions/uvc.name/streaming/class Date: Dec 2014 -KernelVersion: 3.20 +KernelVersion: 4.0 Description: Streaming class descriptors What: /config/usb-gadget/gadget/functions/uvc.name/streaming/class/ss Date: Dec 2014 -KernelVersion: 3.20 +KernelVersion: 4.0 Description: Super speed streaming class descriptors What: /config/usb-gadget/gadget/functions/uvc.name/streaming/class/hs Date: Dec 2014 -KernelVersion: 3.20 +KernelVersion: 4.0 Description: High speed streaming class descriptors What: /config/usb-gadget/gadget/functions/uvc.name/streaming/class/fs Date: Dec 2014 -KernelVersion: 3.20 +KernelVersion: 4.0 Description: Full speed streaming class descriptors What: /config/usb-gadget/gadget/functions/uvc.name/streaming/color_matching Date: Dec 2014 -KernelVersion: 3.20 +KernelVersion: 4.0 Description: Color matching descriptors What: /config/usb-gadget/gadget/functions/uvc.name/streaming/c
Re: [RFC PATCHv2] usb: USB Type-C Connector Class
Hi Oliver, On 05/20/2016 11:43 PM, Oliver Neukum wrote: On Fri, 2016-05-20 at 22:51 -0700, Guenter Roeck wrote: On 05/20/2016 06:37 AM, Oliver Neukum wrote: On Fri, 2016-05-20 at 14:24 +0300, Heikki Krogerus wrote: On Thu, May 19, 2016 at 04:47:17PM +0200, Oliver Neukum wrote: Please explain. How does that express DRP but prefered master? Sorry but I'm not sure what you mean here. If the port is capable of being used as dual role port (DRP in the supported_data_roles file), that is the only case where you can select the role with this file. So I would imagine that in your case you want to make the port act as DFP only, right? But if the port is capable of acting only as UFP, you are stuck with that role. How do I trigger that Try.SRC is to be used on a port? This would be part of the USB PD protocol, ie probably outside the scope of the class code. In my implementation, I enable Try.SRC or Try.SNK based on the platform's preferred role. Hi, from a purely formal point of view that makes sense. From a usability viewpoint I'd ideally want all controls for role at one place. And possibly the controls for modes at the same place. I think part of the problem here is that we lack a statement of mission. What are these controls for? Merely for controlling modes and providing information about modes? And to use neutral terms only for the "master" side or both sides? Good question. I originally added a sysfs attribute 'preferred-mode' to my code, but then concluded that this is supposed to be provided by the platform and added it as platform data instead, with (currently) no means to report it to user space. Heikki's current code doesn't really match the semantics of a 'preferred' mode, at least not as I read it. In my understanding, 'preferred mode' means "this is a DRP port which prefers to be a source/sink". In Heikki's code, one can fix the mode to source or sink, but that doesn't support situations such as "this port prefers to be a source, but is currently a sink because the link partner happens to be a charger or refuses to act as sink for some other reason". Given that, my working assumption is that preferred mode handling is supposed to be outside the scope of the infrastructure. I am happy to be corrected, though. On a side note, are you working on a USB-PD implementation as well ? Thanks, Guenter -- 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: (4.3.0) r8152: deadlock related to runtime suspend?
http://lkml.iu.edu/hypermail/linux/kernel/1512.0/04117.html http://lkml.iu.edu/hypermail/linux/kernel/1512.0/04831.html Same issue here with kernel 4.4.10 and 4.5.4 and r8153. Mine is an USB 3.0 Hub with Gigabit Ethernet, so the common point seems to be USB 3.0. For me it only happens when playing openmw. [12480.821609] INFO: task kworker/3:1:3221 blocked for more than 120 seconds. [12480.821630] Not tainted 4.4.10-1-ARCH #1 [12480.821633] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [12480.821637] kworker/3:1 D 880172963c38 0 3221 2 0x [12480.821677] Workqueue: events rtl_work_func_t [r8152] [12480.821683] 880172963c38 0066 880214b5b700 8801e85c9b80 [12480.821690] 880172964000 88003781a140 88003781a200 [12480.821695] 880172963c50 815b430c 88003781a090 [12480.821701] Call Trace: [12480.821727] [] schedule+0x3c/0x90 [12480.821739] [] rpm_resume+0x118/0x6e0 [12480.821753] [] ? wake_atomic_t_function+0x60/0x60 [12480.821758] [] rpm_resume+0x36e/0x6e0 [12480.821762] [] ? dequeue_entity+0x265/0xa70 [12480.821770] [] ? find_next_bit+0x18/0x20 [12480.821777] [] ? next_online_pgdat+0x26/0x50 [12480.821787] [] __pm_runtime_resume+0x3f/0x60 [12480.821796] [] usb_autopm_get_interface+0x22/0x60 [12480.821808] [] rtl_work_func_t+0x70/0x420 [r8152] [12480.821821] [] ? finish_task_switch+0x78/0x1f0 [12480.821834] [] process_one_work+0x1e4/0x470 [12480.821840] [] worker_thread+0x48/0x4a0 [12480.821847] [] ? process_one_work+0x470/0x470 [12480.821852] [] ? process_one_work+0x470/0x470 [12480.821862] [] kthread+0xd8/0xf0 [12480.821867] [] ? kthread_worker_fn+0x170/0x170 [12480.821875] [] ret_from_fork+0x3f/0x70 [12480.821879] [] ? kthread_worker_fn+0x170/0x170 [12600.826910] INFO: task kworker/3:1:3221 blocked for more than 120 seconds. [12600.826934] Not tainted 4.4.10-1-ARCH #1 [12600.826938] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [12600.826943] kworker/3:1 D 880172963c38 0 3221 2 0x [12600.826985] Workqueue: events rtl_work_func_t [r8152] [12600.826992] 880172963c38 0066 880214b5b700 8801e85c9b80 [12600.826999] 880172964000 88003781a140 88003781a200 [12600.827004] 880172963c50 815b430c 88003781a090 [12600.827009] Call Trace: [12600.827030] [] schedule+0x3c/0x90 [12600.827039] [] rpm_resume+0x118/0x6e0 [12600.827053] [] ? wake_atomic_t_function+0x60/0x60 [12600.827059] [] rpm_resume+0x36e/0x6e0 [12600.827063] [] ? dequeue_entity+0x265/0xa70 [12600.827069] [] ? find_next_bit+0x18/0x20 [12600.827075] [] ? next_online_pgdat+0x26/0x50 [12600.827082] [] __pm_runtime_resume+0x3f/0x60 [12600.827089] [] usb_autopm_get_interface+0x22/0x60 [12600.827098] [] rtl_work_func_t+0x70/0x420 [r8152] [12600.827104] [] ? finish_task_switch+0x78/0x1f0 [12600.827112] [] process_one_work+0x1e4/0x470 [12600.827122] [] worker_thread+0x48/0x4a0 [12600.827127] [] ? process_one_work+0x470/0x470 [12600.827132] [] ? process_one_work+0x470/0x470 [12600.827137] [] kthread+0xd8/0xf0 [12600.827143] [] ? kthread_worker_fn+0x170/0x170 [12600.827152] [] ret_from_fork+0x3f/0x70 [12600.827156] [] ? kthread_worker_fn+0x170/0x170 [12720.832405] INFO: task kworker/3:1:3221 blocked for more than 120 seconds. [12720.832426] Not tainted 4.4.10-1-ARCH #1 [12720.832429] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [12720.832432] kworker/3:1 D 880172963c38 0 3221 2 0x [12720.832481] Workqueue: events rtl_work_func_t [r8152] [12720.832490] 880172963c38 0066 880214b5b700 8801e85c9b80 [12720.832497] 880172964000 88003781a140 88003781a200 [12720.832502] 880172963c50 815b430c 88003781a090 [12720.832507] Call Trace: [12720.832541] [] schedule+0x3c/0x90 [12720.832559] [] rpm_resume+0x118/0x6e0 [12720.832579] [] ? wake_atomic_t_function+0x60/0x60 [12720.832585] [] rpm_resume+0x36e/0x6e0 [12720.832592] [] ? dequeue_entity+0x265/0xa70 [12720.832599] [] ? find_next_bit+0x18/0x20 [12720.832611] [] ? next_online_pgdat+0x26/0x50 [12720.832621] [] __pm_runtime_resume+0x3f/0x60 [12720.832635] [] usb_autopm_get_interface+0x22/0x60 [12720.832651] [] rtl_work_func_t+0x70/0x420 [r8152] [12720.832659] [] ? finish_task_switch+0x78/0x1f0 [12720.832680] [] process_one_work+0x1e4/0x470 [12720.832690] [] worker_thread+0x48/0x4a0 [12720.832697] [] ? process_one_work+0x470/0x470 [12720.832705] [] ? process_one_work+0x470/0x470 [12720.832712] [] kthread+0xd8/0xf0 [12720.832717] [] ? kthread_worker_fn+0x170/0x170 [12720.832723] [] ret_from_fork+0x3f/0x70 [12720.832727] [] ? kthread_worker_fn+0x170/0x170 [12840.837567] INFO: task avahi-daemon:732 blocked for more
Re: [PATCH v8 13/14] usb: gadget: udc: adapt to OTG core
On Sat, May 21, 2016 at 10:29:40AM +0800, Peter Chen wrote:
> On Thu, May 19, 2016 at 10:32:44AM +0300, Roger Quadros wrote:
> > On 18/05/16 17:46, Jun Li wrote:
> > >
> > >
> >
> > I didn't want to have complex Kconfig so decided to have otg as
> > built-in only.
> > What do you want me to change in existing code? and why?
> > >>>
> > >>> Remove those stuff which only for pass diff driver config Like every
> > >>> controller driver need a duplicated
> > >>>
> > >>> static struct otg_hcd_ops ci_hcd_ops = {
> > >>> ...
> > >>> }
> > >>
> > >> This is an exception only. Every controller driver doesn't need to
> > >> implement hcd_ops. It is implemented in the hcd core.
> > >>
> > >>>
> > >>> And here is another example, for gadget connect, otg driver can
> > >>> directly call to usb_udc_vbus_handler() in drd state machine, but you
> > >>> create another interface:
> > >>>
> > >>> .connect_control = usb_gadget_connect_control,
> > >>>
> > >>> If the symbol is defined in one driver which is 'm', another driver
> > >>> reference it should be 'm' as well, then there is no this kind of
> > >>> problem as my understanding.
> > >>
> > >> That is fine as long as all are 'm'. but how do you solve the case when
> > >> Gadget is built in and host is 'm'? OTG has to be built-in and you will
> > >> need an hcd to gadget interface.
> > >
> > > Hcd to gadget interface? Or you want to say otg to host interface?
> >
> > Sorry, I meant to say host to otg interface.
> >
> > >
> > > I think hcd and gadget are independent each other, now
> > >
> > > Hcd --> otg; and gadget --> otg, (hcd and gadget use otg's symbol)
> >
> > It is actually a circular dependency for both.
> > hcd <--> otg and gadget <--> otg
> >
> > hcd -> otg for usb_otg_register/unregister_hcd
> > otg -> hcd for usb_add/remove_hcd, usb_bus_start_enum, usb_control_msg,
> > usb_hub_find_child
> >
> > gadget -> otg for usb_otg_register/unregister_gadget
> > otg -> gadget for usb_gadget_start/stop, usb_udc_vbus_handler
> >
> > Now consider what will happen if I get rid of the otg_hcd and otg_gadget
> > interfaces.
> > 'y' means built-in, 'm' means module.
> >
> > 1) hcd 'y', gadget 'y'
> > otg has to be 'y' for proper build.
> >
> > 2) hcd 'm', gadget 'm'
> > otg has to be 'm' for proper build.
> >
> > 3) hcd 'y', gadget 'm'
> > Build will fail always.
> > If otg is 'y', otg build will fail due to dependency on gadget.
> > If otg is 'm', hcd build will fail due to dependency on otg.
> >
> > 4) hcd 'm', gadget 'y'
> > Build will fail always.
> > If otg is 'y', otg build will fail due to dependency on hcd.
> > If otg is 'm', gadget build will fails due to dependency on otg.
> >
> > So I solve this problem by adding the otg_hcd_ops and otg_gadget_ops
> > to remove otg->hcd and otg->gadget dependency.
> >
> > Now we can address 3) and 4) like so
> >
> > 3) hcd 'y', gadget 'm'
> > otg has to be 'y' for proper build.
> >
> > 4) hcd 'm', gadget 'y'
> > otg has to be 'y' for proper build.
> >
>
> How about this:
> Moving usb_otg_register/unregister_hcd to host driver to remove
> dependency hcd->otg. And moving usb_otg_get_data to common.c.
>
> Delete the wait queue at usb-otg.c, and if calling usb_otg_get_data
> returns NULL, the host/device driver's probe return -EPROBE_DEFER.
> When the otg driver is probed successfully, the host/device will be
> re-probed again, and usb_otg_register_hcd will be called again.
>
> And let OTG depends on HCD && GADGET, and delete otg_hcd_ops and
> otg_gadget_ops. Below build dependency issues can be fixed.
> What do you think?
>
> > 1) hcd 'y', gadget 'y'
> > otg has to be 'y' for proper build.
> >
> > 2) hcd 'm', gadget 'm'
> > otg has to be 'm' for proper build.
> >
> > 3) hcd 'y', gadget 'm'
> > Build will fail always.
> > If otg is 'y', otg build will fail due to dependency on gadget.
> > If otg is 'm', hcd build will fail due to dependency on otg.
> >
> > 4) hcd 'm', gadget 'y'
> > Build will fail always.
> > If otg is 'y', otg build will fail due to dependency on hcd.
> > If otg is 'm', gadget build will fails due to dependency on otg.
> --
>
After thinking more, my suggestion can't work. How about moving
CONFIG_USB_OTG out of CONFIG_USB, in that case, CONFIG_USB_OTG
can only be built in.
--
Best Regards,
Peter Chen
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCHv2] usb: USB Type-C Connector Class
On Sun, 2016-05-22 at 08:54 -0700, Guenter Roeck wrote: > Hi Oliver, > > On 05/20/2016 11:43 PM, Oliver Neukum wrote: > > On Fri, 2016-05-20 at 22:51 -0700, Guenter Roeck wrote: > >> On 05/20/2016 06:37 AM, Oliver Neukum wrote: > >>> On Fri, 2016-05-20 at 14:24 +0300, Heikki Krogerus wrote: > On Thu, May 19, 2016 at 04:47:17PM +0200, Oliver Neukum wrote: > > > > Please explain. How does that express DRP but prefered master? > > Sorry but I'm not sure what you mean here. If the port is capable of > being used as dual role port (DRP in the supported_data_roles file), > that is the only case where you can select the role with this file. So > I would imagine that in your case you want to make the port act as > DFP only, right? But if the port is capable of acting only as UFP, you > are stuck with that role. > >>> > >>> How do I trigger that Try.SRC is to be used on a port? > >>> > >> > >> This would be part of the USB PD protocol, ie probably outside the scope > >> of the class code. In my implementation, I enable Try.SRC or Try.SNK based > >> on the platform's preferred role. > > > > Hi, > > > > from a purely formal point of view that makes sense. > > > >>From a usability viewpoint I'd ideally want all controls > > for role at one place. And possibly the controls for modes > > at the same place. > > > > I think part of the problem here is that we lack a statement > > of mission. What are these controls for? > > Merely for controlling modes and providing information > > about modes? And to use neutral terms only for the "master" > > side or both sides? > > > > Good question. I originally added a sysfs attribute 'preferred-mode' to > my code, but then concluded that this is supposed to be provided > by the platform and added it as platform data instead, with (currently) > no means to report it to user space. Mode or role? I would say that the choice of alternate modes belongs to user space. THere's no point in giving a preference to the kernel. Role is different. Try.SRC is part of the standard (and Try.SNK has been added). It needs to be in kernel space. Now, if you say that this API is for selecting modes only, then I say it lacks support for cable resets and notifications thereof. Yes, that is a PD feature, but that doesn't help us. It changes the mode. > Heikki's current code doesn't really match the semantics of a 'preferred' > mode, at least not as I read it. In my understanding, 'preferred mode' > means "this is a DRP port which prefers to be a source/sink". In Heikki's > code, one can fix the mode to source or sink, but that doesn't support > situations such as "this port prefers to be a source, but is currently > a sink because the link partner happens to be a charger or refuses to act > as sink for some other reason". Yes. That is why we need a mission statement. We may be talking a rice cooker not preparing tea here. > Given that, my working assumption is that preferred mode handling is supposed > to be outside the scope of the infrastructure. I am happy to be corrected, > though. > > On a side note, are you working on a USB-PD implementation as well ? No, one of my task is to to make use of USB PD (and alternate modes) in a distribution. 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 1/2] usb: xhci: switch to running avg trb length
It's unlikely that we will ever know the avg so
instead of assuming it'll be something really large,
we will calculate the avg as we go as mentioned in
XHCI specification section 4.14.1.1.
Signed-off-by: Felipe Balbi
---
drivers/usb/host/xhci-mem.c | 34 --
drivers/usb/host/xhci-ring.c | 20
drivers/usb/host/xhci.h | 3 ++-
3 files changed, 46 insertions(+), 11 deletions(-)
diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index bad0d1f9a41d..0f2ca6e85bc0 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -1451,18 +1451,34 @@ int xhci_endpoint_init(struct xhci_hcd *xhci,
virt_dev->eps[ep_index].skip = false;
ep_ring = virt_dev->eps[ep_index].new_ring;
- /*
-* Get values to fill the endpoint context, mostly from ep descriptor.
-* The average TRB buffer lengt for bulk endpoints is unclear as we
-* have no clue on scatter gather list entry size. For Isoc and Int,
-* set it to max available. See xHCI 1.1 spec 4.14.1.1 for details.
-*/
+ /* Get values to fill the endpoint context, mostly from ep descriptor.
*/
max_esit_payload = xhci_get_max_esit_payload(udev, ep);
interval = xhci_get_endpoint_interval(udev, ep);
mult = xhci_get_endpoint_mult(udev, ep);
max_packet = GET_MAX_PACKET(usb_endpoint_maxp(&ep->desc));
max_burst = xhci_get_endpoint_max_burst(udev, ep);
- avg_trb_len = max_esit_payload;
+
+ /*
+* We are using a running avg for our endpoint's avg_trb_len. The reason
+* is that we have no clue about average transfer sizes for any
+* endpoints because the HCD does not know which USB Class is running on
+* the other end.
+*
+* See xHCI 1.1 spec 4.14.1.1 for details about initial avg_trb_len
+* setting.
+*/
+ switch (usb_endpoint_type(&ep->desc)) {
+ case USB_ENDPOINT_XFER_CONTROL:
+ avg_trb_len = 8;
+ break;
+ case USB_ENDPOINT_XFER_INT:
+ avg_trb_len = 1024;
+ break;
+ case USB_ENDPOINT_XFER_ISOC:
+ case USB_ENDPOINT_XFER_BULK:
+ avg_trb_len = 3072;
+ break;
+ }
/* FIXME dig Mult and streams info out of ep companion desc */
@@ -1472,9 +1488,7 @@ int xhci_endpoint_init(struct xhci_hcd *xhci,
/* Some devices get this wrong */
if (usb_endpoint_xfer_bulk(&ep->desc) && udev->speed == USB_SPEED_HIGH)
max_packet = 512;
- /* xHCI 1.0 and 1.1 indicates that ctrl ep avg TRB Length should be 8 */
- if (usb_endpoint_xfer_control(&ep->desc) && xhci->hci_version >= 0x100)
- avg_trb_len = 8;
+
/* xhci 1.1 with LEC support doesn't use mult field, use RsvdZ */
if ((xhci->hci_version > 0x100) && HCC2_LEC(xhci->hcc_params2))
mult = 0;
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 99b4ff42f7a0..6c41dbbf9f2f 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -2901,6 +2901,8 @@ static int prepare_transfer(struct xhci_hcd *xhci,
struct xhci_td *td;
struct xhci_ring *ep_ring;
struct xhci_ep_ctx *ep_ctx = xhci_get_ep_ctx(xhci, xdev->out_ctx,
ep_index);
+ unsigned int avg_trb_len;
+ unsigned int tx_info;
ep_ring = xhci_stream_id_to_ring(xdev, ep_index, stream_id);
if (!ep_ring) {
@@ -2909,6 +2911,24 @@ static int prepare_transfer(struct xhci_hcd *xhci,
return -EINVAL;
}
+ /*
+* Here we update avg_trb_len so that, over time, we get a better
+* representation of what the actual average length for this endpoint's
+* TRBs are going to be.
+*/
+ if (urb->transfer_buffer_length > 0) {
+ tx_info = le32_to_cpu(ep_ctx->tx_info);
+
+ avg_trb_len = EP_AVG_TRB_LENGTH(tx_info);
+ avg_trb_len += urb->transfer_buffer_length;
+ avg_trb_len /= 2;
+
+ tx_info &= ~EP_AVG_TRB_LENGTH_MASK;
+ tx_info |= EP_AVG_TRB_LENGTH(avg_trb_len);
+
+ ep_ctx->tx_info = cpu_to_le32(tx_info);
+ }
+
ret = prepare_ring(xhci, ep_ring,
le32_to_cpu(ep_ctx->ep_info) & EP_STATE_MASK,
num_trbs, mem_flags);
diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index 6c629c97f8ad..9f1e9be0afcc 100644
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -751,7 +751,8 @@ struct xhci_ep_ctx {
#define GET_MAX_PACKET(p) ((p) & 0x7ff)
/* tx_info bitmasks */
-#define EP_AVG_TRB_LENGTH(p) ((p) & 0x)
+#define EP_AVG_TRB_LENGTH_MASK 0x
+#define EP_AVG_TRB_LENGTH(p) ((p) & EP_AVG_TRB_LENGTH_MASK)
#define EP_MAX_ESIT_PAYLOAD_LO(p) (((p) & 0x) << 16)
#define
[PATCH 2/2] usb: xhci: mem: convert to a switch statement
when getting endpoint type a switch statement looks
better than a series of if () branches. There are no
functional changes with this patch, cleanup only.
Signed-off-by: Felipe Balbi
---
drivers/usb/host/xhci-mem.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index 0f2ca6e85bc0..5949c7962aec 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -1364,14 +1364,16 @@ static u32 xhci_get_endpoint_type(struct
usb_host_endpoint *ep)
in = usb_endpoint_dir_in(&ep->desc);
- if (usb_endpoint_xfer_control(&ep->desc))
+ switch (usb_endpoint_type(&ep->desc)) {
+ case USB_ENDPOINT_XFER_CONTROL:
return CTRL_EP;
- if (usb_endpoint_xfer_bulk(&ep->desc))
+ case USB_ENDPOINT_XFER_BULK:
return in ? BULK_IN_EP : BULK_OUT_EP;
- if (usb_endpoint_xfer_isoc(&ep->desc))
+ case USB_ENDPOINT_XFER_ISOC:
return in ? ISOC_IN_EP : ISOC_OUT_EP;
- if (usb_endpoint_xfer_int(&ep->desc))
+ case USB_ENDPOINT_XFER_INT:
return in ? INT_IN_EP : INT_OUT_EP;
+ }
return 0;
}
--
2.8.3
-
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki
Business Identity Code: 0357606 - 4
Domiciled in Helsinki
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
--
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
