Re: [PATCH v6 07/12] usb: otg: add OTG/dual-role core
On 19/04/16 11:06, Peter Chen wrote:
> On Tue, Apr 05, 2016 at 05:05:12PM +0300, Roger Quadros wrote:
>> +/**
>> + * usb_otg_start_host - start/stop the host controller
>> + * @otg:usb_otg instance
>> + * @on: true to start, false to stop
>> + *
>> + * Start/stop the USB host controller. This function is meant
>> + * for use by the OTG controller driver.
>> + */
>> +int usb_otg_start_host(struct usb_otg *otg, int on)
>> +{
>> +struct otg_hcd_ops *hcd_ops = otg->hcd_ops;
>> +
>> +dev_dbg(otg->dev, "otg: %s %d\n", __func__, on);
>> +if (!otg->host) {
>> +WARN_ONCE(1, "otg: fsm running without host\n");
>> +return 0;
>> +}
>> +
>> +if (on) {
>> +if (otg->flags & OTG_FLAG_HOST_RUNNING)
>> +return 0;
>> +
>> +otg->flags |= OTG_FLAG_HOST_RUNNING;
>> +
>> +/* start host */
>> +hcd_ops->add(otg->primary_hcd.hcd, otg->primary_hcd.irqnum,
>> + otg->primary_hcd.irqflags);
>> +if (otg->shared_hcd.hcd) {
>> +hcd_ops->add(otg->shared_hcd.hcd,
>> + otg->shared_hcd.irqnum,
>> + otg->shared_hcd.irqflags);
>> +}
>
> Check the return value please.
And what should we do on failure?
Even if things fail, they could potentially start working on next
remove/add iteration so I didn't bother checking return values.
>
>> +} else {
>> +if (!(otg->flags & OTG_FLAG_HOST_RUNNING))
>> +return 0;
>> +
>> +otg->flags &= ~OTG_FLAG_HOST_RUNNING;
>> +
>> +/* stop host */
>> +if (otg->shared_hcd.hcd)
>> +hcd_ops->remove(otg->shared_hcd.hcd);
>> +
>> +hcd_ops->remove(otg->primary_hcd.hcd);
>> +}
>> +
>> +return 0;
>> +}
>> +EXPORT_SYMBOL_GPL(usb_otg_start_host);
>> +
>> +/**
>> + * usb_otg_start_gadget - start/stop the gadget controller
>> + * @otg:usb_otg instance
>> + * @on: true to start, false to stop
>> + *
>> + * Start/stop the USB gadget controller. This function is meant
>> + * for use by the OTG controller driver.
>> + */
>> +int usb_otg_start_gadget(struct usb_otg *otg, int on)
>> +{
>> +struct usb_gadget *gadget = otg->gadget;
>> +
>> +dev_dbg(otg->dev, "otg: %s %d\n", __func__, on);
>> +if (!gadget) {
>> +WARN_ONCE(1, "otg: fsm running without gadget\n");
>> +return 0;
>> +}
>> +
>> +if (on) {
>> +if (otg->flags & OTG_FLAG_GADGET_RUNNING)
>> +return 0;
>> +
>> +otg->flags |= OTG_FLAG_GADGET_RUNNING;
>> +otg->gadget_ops->start(otg->gadget);
>
> ditto
>
>> +} else {
>> +if (!(otg->flags & OTG_FLAG_GADGET_RUNNING))
>> +return 0;
>> +
>> +otg->flags &= ~OTG_FLAG_GADGET_RUNNING;
>> +otg->gadget_ops->stop(otg->gadget);
>> +}
>> +
>> +return 0;
>> +}
>> +EXPORT_SYMBOL_GPL(usb_otg_start_gadget);
>> +
>> +/**
>> + * Change USB protocol when there is a protocol change.
>> + * fsm->lock must be held.
>> + */
>> +static int drd_set_protocol(struct otg_fsm *fsm, int protocol)
>> +{
>> +struct usb_otg *otg = container_of(fsm, struct usb_otg, fsm);
>> +int ret = 0;
>> +
>> +if (fsm->protocol != protocol) {
>> +dev_dbg(otg->dev, "otg: changing role fsm->protocol= %d; new
>> protocol= %d\n",
>> +fsm->protocol, protocol);
>> +/* stop old protocol */
>> +if (fsm->protocol == PROTO_HOST)
>> +ret = otg_start_host(otg, 0);
>> +else if (fsm->protocol == PROTO_GADGET)
>> +ret = otg_start_gadget(otg, 0);
>> +if (ret)
>> +return ret;
>> +
>> +/* start new protocol */
>> +if (protocol == PROTO_HOST)
>> +ret = otg_start_host(otg, 1);
>> +else if (protocol == PROTO_GADGET)
>> +ret = otg_start_gadget(otg, 1);
>> +if (ret)
>> +return ret;
>> +
>> +fsm->protocol = protocol;
>> +return 0;
>> +}
>> +
>> +return 0;
>> +}
>> +
>> +/**
>> + * Called when entering a DRD state.
>> + * fsm->lock must be held.
>> + */
>> +static void drd_set_state(struct otg_fsm *fsm, enum usb_otg_state new_state)
>> +{
>> +struct usb_otg *otg = container_of(fsm, struct usb_otg, fsm);
>> +
>> +if (otg->state == new_state)
>> +return;
>> +
>> +fsm->state_changed = 1;
>> +dev_dbg(otg->dev, "otg: set state: %s\n",
>> +usb_otg_state_string(new_state));
>> +switch (new_state) {
>> +case OTG_STATE_B_IDLE:
>> +drd_set_protocol(fsm, PROTO_UNDEF);
>> +otg_drv_vbus(otg, 0);
>> +break;
>> +case OTG_STATE_B_PERIPHERAL:
>> +drd_set_protocol(fsm, PROTO_GADGET);
>> +
Re: [PATCH v6 07/12] usb: otg: add OTG/dual-role core
On 20/04/16 08:08, Yoshihiro Shimoda wrote:
> Hi,
>
>> From: Peter Chen
>> Sent: Tuesday, April 19, 2016 6:18 PM
>>
>> On Fri, Apr 15, 2016 at 10:03:16AM +, Yoshihiro Shimoda wrote:
>>> Hi,
>>>
From: Yoshihiro Shimoda
Sent: Friday, April 15, 2016 6:59 PM
Hi,
> From: Roger Quadros
> Sent: Thursday, April 14, 2016 8:32 PM
>
> On 14/04/16 14:15, Yoshihiro Shimoda wrote:
>> Hi,
>>
< snip >
@@ -865,7 +867,8 @@ int usb_otg_register_hcd(struct usb_hcd *hcd,
unsigned int irqnum,
* we're ready only if we have shared HCD
* or we don't need shared HCD.
*/
- if (otg->shared_hcd.hcd || !otg->primary_hcd.hcd->shared_hcd) {
+ if (otg->shared_hcd.hcd || (!otg->caps->needs_companion &&
+ !otg->primary_hcd.hcd->shared_hcd))
{
otg->host = hcd_to_bus(hcd);
/* FIXME: set bus->otg_port if this is true OTG port
with HNP */
>>>
>>> These changes look good to me. Thanks.
>>
>> Thank you for the comment.
>> If we change the "needs_companion" place to the otg_config,
>> do we need to add a flag into the otg, instead of otg->caps?
>
> Yes we can add a flag in struct usb_otg.
Thank you for the comment.
I made a fixed patch.
So, should I send this patch to ML after you sent v7 patches?
Or, would you apply this patch before you send v7 patches?
>>>
>>> Oops, I sent this email without my patch...
>>>
>>> ---
>>> Subject: [PATCH] usb: otg: add hcd companion support
>>>
>>> Since some host controller (e.g. EHCI) needs a companion host controller
>>> (e.g. OHCI), this patch adds such a configuration to use it in the OTG
>>> core.
>>>
>>> Signed-off-by: Yoshihiro Shimoda
>>> ---
>>> Documentation/devicetree/bindings/usb/generic.txt | 3 +++
>>> drivers/usb/common/usb-otg.c | 17 +
>>> include/linux/usb/otg.h | 7 ++-
>>> 3 files changed, 22 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/usb/generic.txt
>>> b/Documentation/devicetree/bindings/usb/generic.txt
>>> index f6866c1..1db1c33 100644
>>> --- a/Documentation/devicetree/bindings/usb/generic.txt
>>> +++ b/Documentation/devicetree/bindings/usb/generic.txt
>>> @@ -27,6 +27,9 @@ Optional properties:
>>> - otg-controller: phandle to otg controller. Host or gadget controllers
>>> can
>>> contain this property to link it to a particular OTG
>>> controller.
>>> + - hcd-needs-companion: must be present if otg controller is dealing with
>>> + EHCI host controller that needs a companion OHCI host
>>> + controller.
>>>
>>> This is an attribute to a USB controller such as:
>>>
>>> diff --git a/drivers/usb/common/usb-otg.c b/drivers/usb/common/usb-otg.c
>>> index 41e762a..83c8c96 100644
>>> --- a/drivers/usb/common/usb-otg.c
>>> +++ b/drivers/usb/common/usb-otg.c
>>> @@ -20,6 +20,7 @@
>>> #include
>>> #include
>>> #include
>>> +#include
>>> #include
>>> #include
>>> #include
>>> @@ -600,6 +601,10 @@ struct usb_otg *usb_otg_register(struct device *dev,
>>> else
>>> INIT_WORK(&otg->work, usb_otg_work);
>>>
>>> + if (of_find_property(dev->of_node, "hcd-needs-companion", NULL) ||
>>> + config->hcd_needs_companion)/* needs comanion ? */
>>
>> %s/comanion/companion
>
> Thank you for pointing it out!
>
> Roger, would you fix this in your v7 patch set?
Yes, I'll fix it locally. You don't need to post it again.
--
cheers,
-roger
>
>> I have a little puzzled with companion controller and shared hcd, let me
>> post a topic for it.
>
> I looked at the email thread.
> It is very useful information to me! :)
>
> Best regards,
> Yoshihiro Shimoda
>
>> Peter
>>
>>> + otg->flags |= OTG_FLAG_HCD_NEEDS_COMPANION;
>>> +
>>> otg->wq = create_singlethread_workqueue("usb_otg");
>>> if (!otg->wq) {
>>> dev_err(dev, "otg: %s: can't create workqueue\n",
>>> @@ -823,13 +828,15 @@ int usb_otg_register_hcd(struct usb_hcd *hcd,
>>> unsigned int irqnum,
>>> /* HCD will be started by OTG fsm when needed */
>>> mutex_lock(&otg->fsm.lock);
>>> if (otg->primary_hcd.hcd) {
>>> - /* probably a shared HCD ? */
>>> - if (usb_otg_hcd_is_primary_hcd(hcd)) {
>>> + /* probably a shared HCD or a companion OHCI HCD ? */
>>> + if (!(otg->flags & OTG_FLAG_HCD_NEEDS_COMPANION) &&
>>> + usb_otg_hcd_is_primary_hcd(hcd)) {
>>> dev_err(otg_dev, "otg: primary host already
>>> registered\n");
>>> goto err;
>>> }
>>>
>>> - if (hcd->shared_hcd == otg->primary_hcd.hcd) {
>>> + if (otg->flags & OTG_FLAG_HCD_NEEDS_COMPAN
Re: What are Shared HCD and Companion Controller(HCD?)
On Tue, Apr 19, 2016 at 10:20:33AM -0400, Alan Stern wrote: > On Tue, 19 Apr 2016, Felipe Balbi wrote: > > > Hi, > > > > Peter Chen writes: > > > Hi all, > > > > > > When I review the patch [1] for adding companion controller support for > > > OTG framework, I am puzzled several concepts, like shared hcd and > > > companion controller, companion hcd, companion port, would someone > > > please explain them? And why EHCI/OHCI do not use shared hcd, but > > > xHCI uses it? Thanks. > > > > xHCI is modeled as two separate buses (High-speed and Super-speed) which > > *share* the same IP block. In the case of EHCI/OHCI, there is a port > > being handed over to the a completely separate IP. OHCI is EHCI's > > companion for non-HS signalling. > > That's right. In more detail: > > Companion controller and companion hcd are the same thing. They exist > because EHCI can only handle high speed connections; it can't handle > full speed or low speed. When a USB-1.1 device is plugged into an EHCI > controller, the EHCI controller can't handle it and so the connection > is handed over to the companion controller, which is either OHCI or > UHCI. > > xHCI doesn't have that problem; it can handle all speeds. However the > hardware design (not just the software design!) uses two separate > buses: one for SuperSpeed and one for high/full/low speed. There > actually are two separate sets of wires in a USB-3 cable. > > If the USB core were designed better, we would have used a single > usb_hcd structure for xHCI, with two usb_bus structures inside it. But > the structures were designed long before USB-3 was announced, and it > would have taken a lot of changes to make that approach work. Instead, > xhci-hcd uses two usb_hcd structures, each containing a single usb_bus. > The structure for the high/full/low-speed bus is called the primary_hcd > and the structure for the SuperSpeed bus is called the shared_hcd. > > As a result of xHCI's design, the same physical port on the computer > will show up as two different ports in the kernel: one attached to the > SuperSpeed hcd and one attached to the high/full/low-speed hcd. The > peer pointer (not companion!) in struct usb_port connects these two > logical ports. > Thanks, Alan, Felipe, Oliver. After reading the beginning content of EHCI spec, I understand what is companion controller. At chipidea USB2 design, it handles FS/LS by internal, so I have no knowledge about it. Integrated Transaction Translator (Multi Port implementations) supports directly connected USB legacy (USB 1.1) Full and Low speed devices without a companion USB 1.1 host controller or host controller driver software. Embedded Transaction Translator - Allows direct attachment of FS and LS devices in host mode without the need for a companion controller. -- 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
[PATCH] usb: gadget: f_fs: Fix use-after-free
From: Lars-Peter Clausen
When using asynchronous read or write operations on the USB endpoints the
issuer of the IO request is notified by calling the ki_complete() callback
of the submitted kiocb when the URB has been completed.
Calling this ki_complete() callback will free kiocb. Make sure that the
structure is no longer accessed beyond that point, otherwise undefined
behaviour might occur.
Fixes: 2e4c7553cd6f ("usb: gadget: f_fs: add aio support")
Cc: # v3.15+
Signed-off-by: Lars-Peter Clausen
Signed-off-by: Felipe Balbi
---
this is just to Cc stable!!!
drivers/usb/gadget/function/f_fs.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/gadget/function/f_fs.c
b/drivers/usb/gadget/function/f_fs.c
index e21ca2bd6839..15b648cbc75c 100644
--- a/drivers/usb/gadget/function/f_fs.c
+++ b/drivers/usb/gadget/function/f_fs.c
@@ -646,6 +646,7 @@ static void ffs_user_copy_worker(struct work_struct *work)
work);
int ret = io_data->req->status ? io_data->req->status :
io_data->req->actual;
+ bool kiocb_has_eventfd = io_data->kiocb->ki_flags & IOCB_EVENTFD;
if (io_data->read && ret > 0) {
use_mm(io_data->mm);
@@ -657,13 +658,11 @@ static void ffs_user_copy_worker(struct work_struct *work)
io_data->kiocb->ki_complete(io_data->kiocb, ret, ret);
- if (io_data->ffs->ffs_eventfd &&
- !(io_data->kiocb->ki_flags & IOCB_EVENTFD))
+ if (io_data->ffs->ffs_eventfd && !kiocb_has_eventfd)
eventfd_signal(io_data->ffs->ffs_eventfd, 1);
usb_ep_free_request(io_data->ep, io_data->req);
- io_data->kiocb->private = NULL;
if (io_data->read)
kfree(io_data->to_free);
kfree(io_data->buf);
--
2.8.0.rc2
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What are Shared HCD and Companion Controller(HCD?)
Peter Chen writes: > On Tue, Apr 19, 2016 at 10:20:33AM -0400, Alan Stern wrote: >> On Tue, 19 Apr 2016, Felipe Balbi wrote: >> >> > Hi, >> > >> > Peter Chen writes: >> > > Hi all, >> > > >> > > When I review the patch [1] for adding companion controller support for >> > > OTG framework, I am puzzled several concepts, like shared hcd and >> > > companion controller, companion hcd, companion port, would someone >> > > please explain them? And why EHCI/OHCI do not use shared hcd, but >> > > xHCI uses it? Thanks. >> > >> > xHCI is modeled as two separate buses (High-speed and Super-speed) which >> > *share* the same IP block. In the case of EHCI/OHCI, there is a port >> > being handed over to the a completely separate IP. OHCI is EHCI's >> > companion for non-HS signalling. >> >> That's right. In more detail: >> >> Companion controller and companion hcd are the same thing. They exist >> because EHCI can only handle high speed connections; it can't handle >> full speed or low speed. When a USB-1.1 device is plugged into an EHCI >> controller, the EHCI controller can't handle it and so the connection >> is handed over to the companion controller, which is either OHCI or >> UHCI. >> >> xHCI doesn't have that problem; it can handle all speeds. However the >> hardware design (not just the software design!) uses two separate >> buses: one for SuperSpeed and one for high/full/low speed. There >> actually are two separate sets of wires in a USB-3 cable. >> >> If the USB core were designed better, we would have used a single >> usb_hcd structure for xHCI, with two usb_bus structures inside it. But >> the structures were designed long before USB-3 was announced, and it >> would have taken a lot of changes to make that approach work. Instead, >> xhci-hcd uses two usb_hcd structures, each containing a single usb_bus. >> The structure for the high/full/low-speed bus is called the primary_hcd >> and the structure for the SuperSpeed bus is called the shared_hcd. >> >> As a result of xHCI's design, the same physical port on the computer >> will show up as two different ports in the kernel: one attached to the >> SuperSpeed hcd and one attached to the high/full/low-speed hcd. The >> peer pointer (not companion!) in struct usb_port connects these two >> logical ports. >> > > Thanks, Alan, Felipe, Oliver. > > After reading the beginning content of EHCI spec, I understand what is > companion controller. At chipidea USB2 design, it handles FS/LS by > internal, so I have no knowledge about it. > > Integrated Transaction Translator (Multi Port implementations) supports > directly connected USB legacy (USB 1.1) Full and Low speed devices > without a companion USB 1.1 host controller or host controller driver > software. > > Embedded Transaction Translator - Allows direct attachment of FS and LS > devices in host mode without the need for a companion controller. TT is only required for hubs, not for roothubs. Some roothubs will implement it to save silicon area, but regular EHCIs don't ;-) -- balbi signature.asc Description: PGP signature
Re: What are Shared HCD and Companion Controller(HCD?)
On Wed, Apr 20, 2016 at 10:41:42AM +0300, Felipe Balbi wrote: > Peter Chen writes: > > On Tue, Apr 19, 2016 at 10:20:33AM -0400, Alan Stern wrote: > >> On Tue, 19 Apr 2016, Felipe Balbi wrote: > >> > >> > Hi, > >> > > >> > Peter Chen writes: > >> > > Hi all, > >> > > > >> > > When I review the patch [1] for adding companion controller support for > >> > > OTG framework, I am puzzled several concepts, like shared hcd and > >> > > companion controller, companion hcd, companion port, would someone > >> > > please explain them? And why EHCI/OHCI do not use shared hcd, but > >> > > xHCI uses it? Thanks. > >> > > >> > xHCI is modeled as two separate buses (High-speed and Super-speed) which > >> > *share* the same IP block. In the case of EHCI/OHCI, there is a port > >> > being handed over to the a completely separate IP. OHCI is EHCI's > >> > companion for non-HS signalling. > >> > >> That's right. In more detail: > >> > >> Companion controller and companion hcd are the same thing. They exist > >> because EHCI can only handle high speed connections; it can't handle > >> full speed or low speed. When a USB-1.1 device is plugged into an EHCI > >> controller, the EHCI controller can't handle it and so the connection > >> is handed over to the companion controller, which is either OHCI or > >> UHCI. > >> > >> xHCI doesn't have that problem; it can handle all speeds. However the > >> hardware design (not just the software design!) uses two separate > >> buses: one for SuperSpeed and one for high/full/low speed. There > >> actually are two separate sets of wires in a USB-3 cable. > >> > >> If the USB core were designed better, we would have used a single > >> usb_hcd structure for xHCI, with two usb_bus structures inside it. But > >> the structures were designed long before USB-3 was announced, and it > >> would have taken a lot of changes to make that approach work. Instead, > >> xhci-hcd uses two usb_hcd structures, each containing a single usb_bus. > >> The structure for the high/full/low-speed bus is called the primary_hcd > >> and the structure for the SuperSpeed bus is called the shared_hcd. > >> > >> As a result of xHCI's design, the same physical port on the computer > >> will show up as two different ports in the kernel: one attached to the > >> SuperSpeed hcd and one attached to the high/full/low-speed hcd. The > >> peer pointer (not companion!) in struct usb_port connects these two > >> logical ports. > >> > > > > Thanks, Alan, Felipe, Oliver. > > > > After reading the beginning content of EHCI spec, I understand what is > > companion controller. At chipidea USB2 design, it handles FS/LS by > > internal, so I have no knowledge about it. > > > > Integrated Transaction Translator (Multi Port implementations) supports > > directly connected USB legacy (USB 1.1) Full and Low speed devices > > without a companion USB 1.1 host controller or host controller driver > > software. > > > > Embedded Transaction Translator - Allows direct attachment of FS and LS > > devices in host mode without the need for a companion controller. > > TT is only required for hubs, not for roothubs. Some roothubs will > implement it to save silicon area, but regular EHCIs don't ;-) > Yes, the above contents are listed from chipidea's Reference Manual. -- Best Regards, Peter Chen -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb/gadget: fix gadgetfs aio support
On 2016-04-20 09:27, Mathieu Laurendeau wrote:
On 2016-03-23 12:51, Mathieu Laurendeau wrote:
Since commit 7fe3976e0f3ab26f8ffd9430d3d2a19a70f2c8d2 ("gadget: switch
ep_io_operations to ->read_iter/->write_iter") io submissions fail
with
ENODEV.
Signed-off-by: Mathieu Laurendeau
---
drivers/usb/gadget/legacy/inode.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/legacy/inode.c
b/drivers/usb/gadget/legacy/inode.c
index 5cdaf01..416f1017 100644
--- a/drivers/usb/gadget/legacy/inode.c
+++ b/drivers/usb/gadget/legacy/inode.c
@@ -542,7 +542,7 @@ static ssize_t ep_aio(struct kiocb *iocb,
*/
spin_lock_irq(&epdata->dev->lock);
value = -ENODEV;
- if (unlikely(epdata->ep))
+ if (unlikely(epdata->ep == NULL))
goto fail;
req = usb_ep_alloc_request(epdata->ep, GFP_ATOMIC);
Hello,
Please consider reading and applying this patch.
Regards,
Mathieu Laurendeau
I guess this got lost because of a wrong CC.
--
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 v6 06/12] usb: otg: get rid of CONFIG_USB_OTG_FSM in favour of CONFIG_USB_OTG
On 18/04/16 11:05, Peter Chen wrote:
> On Tue, Apr 05, 2016 at 05:05:11PM +0300, Roger Quadros wrote:
>> Let's use CONFIG_USB_OTG as a single config option to enable
>> USB OTG and the OTG FSM. This makes things a lot less confusing.
>>
>> Update all users of CONFIG_USB_OTG_FSM to CONFIG_USB_OTG.
>>
>> Signed-off-by: Roger Quadros
>> ---
>> Documentation/usb/chipidea.txt | 2 +-
>> drivers/usb/Makefile | 1 +
>> drivers/usb/chipidea/Makefile | 2 +-
>> drivers/usb/chipidea/ci.h | 2 +-
>> drivers/usb/chipidea/otg_fsm.h | 2 +-
>> drivers/usb/common/Makefile| 3 ++-
>> drivers/usb/core/Kconfig | 8
>> drivers/usb/phy/Kconfig| 2 +-
>> 8 files changed, 8 insertions(+), 14 deletions(-)
>>
>> diff --git a/Documentation/usb/chipidea.txt b/Documentation/usb/chipidea.txt
>> index 678741b..3b1f263 100644
>> --- a/Documentation/usb/chipidea.txt
>> +++ b/Documentation/usb/chipidea.txt
>> @@ -5,7 +5,7 @@ with 2 Freescale i.MX6Q sabre SD boards.
>>
>> 1.1 How to enable OTG FSM in menuconfig
>> ---
>> -Select CONFIG_USB_OTG_FSM, rebuild kernel Image and modules.
>> +Select CONFIG_USB_OTG, rebuild kernel Image and modules.
>> If you want to check some internal variables for otg fsm,
>> mount debugfs, there are 2 files which can show otg fsm
>> variables and some controller registers value:
>> diff --git a/drivers/usb/Makefile b/drivers/usb/Makefile
>> index dca7856..16a5b55 100644
>> --- a/drivers/usb/Makefile
>> +++ b/drivers/usb/Makefile
>> @@ -59,5 +59,6 @@ obj-$(CONFIG_USB_RENESAS_USBHS)+= renesas_usbhs/
>> obj-$(CONFIG_USB_GADGET)+= gadget/
>>
>> obj-$(CONFIG_USB_COMMON)+= common/
>> +obj-$(CONFIG_USB_OTG) += common/
>
> Why we need to add above line?
It is not needed as USB_OTG can't be set without USB_COMMON.
I'll remove it.
cheers,
-roger
>
> Peter
>>
>> obj-$(CONFIG_USBIP_CORE)+= usbip/
>> diff --git a/drivers/usb/chipidea/Makefile b/drivers/usb/chipidea/Makefile
>> index 518e445..45aa24d 100644
>> --- a/drivers/usb/chipidea/Makefile
>> +++ b/drivers/usb/chipidea/Makefile
>> @@ -3,7 +3,7 @@ obj-$(CONFIG_USB_CHIPIDEA) += ci_hdrc.o
>> ci_hdrc-y := core.o otg.o debug.o
>> ci_hdrc-$(CONFIG_USB_CHIPIDEA_UDC) += udc.o
>> ci_hdrc-$(CONFIG_USB_CHIPIDEA_HOST) += host.o
>> -ci_hdrc-$(CONFIG_USB_OTG_FSM) += otg_fsm.o
>> +ci_hdrc-$(CONFIG_USB_OTG) += otg_fsm.o
>>
>> # Glue/Bridge layers go here
>>
>> diff --git a/drivers/usb/chipidea/ci.h b/drivers/usb/chipidea/ci.h
>> index c523975..1a32b8c 100644
>> --- a/drivers/usb/chipidea/ci.h
>> +++ b/drivers/usb/chipidea/ci.h
>> @@ -406,7 +406,7 @@ static inline u32 hw_test_and_write(struct ci_hdrc *ci,
>> enum ci_hw_regs reg,
>> */
>> static inline bool ci_otg_is_fsm_mode(struct ci_hdrc *ci)
>> {
>> -#ifdef CONFIG_USB_OTG_FSM
>> +#ifdef CONFIG_USB_OTG
>> struct usb_otg_caps *otg_caps = &ci->platdata->ci_otg_caps;
>>
>> return ci->is_otg && ci->roles[CI_ROLE_HOST] &&
>> diff --git a/drivers/usb/chipidea/otg_fsm.h b/drivers/usb/chipidea/otg_fsm.h
>> index 6366fe3..2d451bb 100644
>> --- a/drivers/usb/chipidea/otg_fsm.h
>> +++ b/drivers/usb/chipidea/otg_fsm.h
>> @@ -64,7 +64,7 @@
>>
>> #define TB_AIDL_BDIS (20) /* 4ms ~ 150ms, section 5.2.1 */
>>
>> -#if IS_ENABLED(CONFIG_USB_OTG_FSM)
>> +#if IS_ENABLED(CONFIG_USB_OTG)
>>
>> int ci_hdrc_otg_fsm_init(struct ci_hdrc *ci);
>> int ci_otg_fsm_work(struct ci_hdrc *ci);
>> diff --git a/drivers/usb/common/Makefile b/drivers/usb/common/Makefile
>> index 6bbb3ec..f8f2c88 100644
>> --- a/drivers/usb/common/Makefile
>> +++ b/drivers/usb/common/Makefile
>> @@ -6,5 +6,6 @@ obj-$(CONFIG_USB_COMMON) += usb-common.o
>> usb-common-y += common.o
>> usb-common-$(CONFIG_USB_LED_TRIG) += led.o
>>
>> -obj-$(CONFIG_USB_OTG_FSM) += usb-otg-fsm.o
>> obj-$(CONFIG_USB_ULPI_BUS) += ulpi.o
>> +usbotg-y:= usb-otg-fsm.o
>> +obj-$(CONFIG_USB_OTG) += usbotg.o
>> diff --git a/drivers/usb/core/Kconfig b/drivers/usb/core/Kconfig
>> index dd28010..ae228d0 100644
>> --- a/drivers/usb/core/Kconfig
>> +++ b/drivers/usb/core/Kconfig
>> @@ -75,14 +75,6 @@ config USB_OTG_BLACKLIST_HUB
>>and software costs by not supporting external hubs. So
>>are "Embedded Hosts" that don't offer OTG support.
>>
>> -config USB_OTG_FSM
>> -tristate "USB 2.0 OTG FSM implementation"
>> -depends on USB && USB_OTG
>> -select USB_PHY
>> -help
>> - Implements OTG Finite State Machine as specified in On-The-Go
>> - and Embedded Host Supplement to the USB Revision 2.0 Specification.
>> -
>> config USB_ULPI_BUS
>> tristate "USB ULPI PHY interface support"
>> depends on USB_SUPPORT
>> diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
>> index c690474..06794e2 100644
>> --- a/drivers/usb/phy/Kconfig
>> +++ b/drivers/usb/phy/Kconfig
>> @@ -20,7 +20,7 @@ c
Re: [PATCH] usb/gadget: fix gadgetfs aio support
Hi,
Mathieu Laurendeau writes:
> On 2016-04-20 09:27, Mathieu Laurendeau wrote:
>> On 2016-03-23 12:51, Mathieu Laurendeau wrote:
>>> Since commit 7fe3976e0f3ab26f8ffd9430d3d2a19a70f2c8d2 ("gadget: switch
>>> ep_io_operations to ->read_iter/->write_iter") io submissions fail
>>> with
>>> ENODEV.
>>>
>>> Signed-off-by: Mathieu Laurendeau
>>> ---
>>> drivers/usb/gadget/legacy/inode.c |2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/usb/gadget/legacy/inode.c
>>> b/drivers/usb/gadget/legacy/inode.c
>>> index 5cdaf01..416f1017 100644
>>> --- a/drivers/usb/gadget/legacy/inode.c
>>> +++ b/drivers/usb/gadget/legacy/inode.c
>>> @@ -542,7 +542,7 @@ static ssize_t ep_aio(struct kiocb *iocb,
>>> */
>>> spin_lock_irq(&epdata->dev->lock);
>>> value = -ENODEV;
>>> - if (unlikely(epdata->ep))
>>> + if (unlikely(epdata->ep == NULL))
>>> goto fail;
>>>
>>> req = usb_ep_alloc_request(epdata->ep, GFP_ATOMIC);
>>
>> Hello,
>>
>> Please consider reading and applying this patch.
>>
>> Regards,
>> Mathieu Laurendeau
>
> I guess this got lost because of a wrong CC.
yeah, I don't have the original patch in my inbox anymore, care to
resend rebased on testing/next ? Also, make sure to add proper:
Fixes: 7fe3976e0f3a ("gadget: switch ep_io_operations to
->read_iter/->write_iter")
and:
Cc: # v4.0+
to your commit log
--
balbi
signature.asc
Description: PGP signature
Re: [PATCH v6 01/12] usb: hcd: Initialize hcd->flags to 0
On 19/04/16 04:56, Peter Chen wrote: > On Mon, Apr 18, 2016 at 10:11:29AM -0400, Alan Stern wrote: >> On Mon, 18 Apr 2016, Peter Chen wrote: >> >>> On Wed, Apr 06, 2016 at 09:32:22AM +0300, Roger Quadros wrote: On 06/04/16 09:09, Felipe Balbi wrote: > > Hi, > > Roger Quadros writes: >> diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c >> index 2ca2cef..6b1930d 100644 >> --- a/drivers/usb/core/hcd.c >> +++ b/drivers/usb/core/hcd.c >> @@ -2706,6 +2706,7 @@ int usb_add_hcd(struct usb_hcd *hcd, >> int retval; >> struct usb_device *rhdev; >> >> +hcd->flags = 0; > > seems like this would make more sense in usb_del_hcd() instead. > OK, I'll move it there. >>> >>> It depends on Alan's comments, whether only usb_add_hcd/usb_del_hcd >>> pair can be called repeat. If Alan acks it, I have no idea for it. >> >> Most of the host controller drivers were not written with this in mind, >> but I think it would be a good thing to allow. It would speed up the >> host/device role switches. >> >> This might mean we need to fix up several drivers to make them work >> correctly in an OTG environment. It should be possible to do this. Is >> there any particular reason why it would be difficult for Chipidea? >> > > I just want to do clean remove at OTG environment, like rmmod, so I did > this when I worked on chipidea OTG design. > I am worried if there are some resources dedicated for host device, eg, > clocks, gpio. etc. > > If OTG framework can know well hcd's add and remove, it is ok for chipidea > just calling usb_add_hcd/usb_del_hcd currently, but I suggested roger > adding platform hcd_ops as optional parameter in case the platform > has special requirement for hcd_ops. > We have 2 users now, omap + dwc3 and sh + EHCI/OHCI and we didn't seem to observe any issues with the usb_add/del_hcd approach. Let's keep things minimal for now. In the future, if users need something more we can always extend the framework. cheers, -roger -- 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
[GIT PULL] USB fixes for v4.6-rc5
Hi Greg, here's what I hope to be my last pull request to this -rc series. Patches have been tested (where applicable) with intel platforms I have around. They have also been in next for a little while without any reports of problems. cheers The following changes since commit c3b46c73264b03000d1e18b22f5caf63332547c9: Linux 4.6-rc4 (2016-04-17 19:13:32 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git tags/fixes-for-v4.6-rc5 for you to fetch changes up to 38740a5b87d53ceb89eb2c970150f6e94e00373a: usb: gadget: f_fs: Fix use-after-free (2016-04-20 10:38:06 +0300) usb: fixes for v4.6-rc5 No more major fixes left. Out of the 6 fixes we have here, 4 are on dwc3. The most important is the memory leak fix in dwc3/debugfs.c. We also have a fix for PHY handling in suspend/resume and a fix for dwc3-omap's error handling. Suspend/resume also had the potential to trigger a NULL pointer dereference on dwc3; that's also fixed now. Our good ol' ffs function gets a use-after-free fix while the generic composite.c layer has a robustness fix by making sure reserved fields of a possible SSP device capability descriptor is cleared to 0. Du, Changbin (1): usb: dwc3: fix memory leak of dwc->regset Felipe Balbi (2): usb: dwc3: omap: fix up error path on probe() usb: dwc3: core: fix PHY handling during suspend John Youn (1): usb: gadget: composite: Clear reserved fields of SSP Dev Cap Lars-Peter Clausen (1): usb: gadget: f_fs: Fix use-after-free Roger Quadros (1): usb: dwc3: gadget: Fix suspend/resume during device mode drivers/usb/dwc3/core.c| 23 ++- drivers/usb/dwc3/debugfs.c | 13 - drivers/usb/dwc3/dwc3-omap.c | 12 drivers/usb/dwc3/gadget.c | 6 ++ drivers/usb/gadget/composite.c | 2 ++ drivers/usb/gadget/function/f_fs.c | 5 ++--- 6 files changed, 44 insertions(+), 17 deletions(-) -- balbi signature.asc Description: PGP signature
Re: [PATCH] usb/gadget: fix gadgetfs aio support
On 2016-03-23 12:51, Mathieu Laurendeau wrote:
Since commit 7fe3976e0f3ab26f8ffd9430d3d2a19a70f2c8d2 ("gadget: switch
ep_io_operations to ->read_iter/->write_iter") io submissions fail with
ENODEV.
Signed-off-by: Mathieu Laurendeau
---
drivers/usb/gadget/legacy/inode.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/legacy/inode.c
b/drivers/usb/gadget/legacy/inode.c
index 5cdaf01..416f1017 100644
--- a/drivers/usb/gadget/legacy/inode.c
+++ b/drivers/usb/gadget/legacy/inode.c
@@ -542,7 +542,7 @@ static ssize_t ep_aio(struct kiocb *iocb,
*/
spin_lock_irq(&epdata->dev->lock);
value = -ENODEV;
- if (unlikely(epdata->ep))
+ if (unlikely(epdata->ep == NULL))
goto fail;
req = usb_ep_alloc_request(epdata->ep, GFP_ATOMIC);
Hello,
Please consider reading and applying this patch.
Regards,
Mathieu Laurendeau
--
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 v6 07/12] usb: otg: add OTG/dual-role core
On Wed, Apr 20, 2016 at 09:54:49AM +0300, Roger Quadros wrote:
> On 18/04/16 05:09, Peter Chen wrote:
> > On Fri, Apr 15, 2016 at 02:00:46PM +0300, Roger Quadros wrote:
> >> On 15/04/16 12:25, Peter Chen wrote:
> >>> On Tue, Apr 05, 2016 at 05:05:12PM +0300, Roger Quadros wrote:
> + * usb_otg_register() - Register the OTG/dual-role device to OTG core
> + * @dev: OTG/dual-role controller device.
> + * @config: OTG configuration.
> + *
> + * Registers the OTG/dual-role controller device with the USB OTG core.
> + *
> + * Return: struct usb_otg * if success, ERR_PTR() if error.
> + */
> +struct usb_otg *usb_otg_register(struct device *dev,
> + struct usb_otg_config *config)
> +{
> +struct usb_otg *otg;
> +struct otg_wait_data *wait;
> +int ret = 0;
> +
> +if (!dev || !config || !config->fsm_ops)
> +return ERR_PTR(-EINVAL);
> +
> +/* already in list? */
> +mutex_lock(&otg_list_mutex);
> +if (usb_otg_get_data(dev)) {
> +dev_err(dev, "otg: %s: device already in otg list\n",
> +__func__);
> +ret = -EINVAL;
> +goto unlock;
> +}
> +
> +/* allocate and add to list */
> +otg = kzalloc(sizeof(*otg), GFP_KERNEL);
> +if (!otg) {
> +ret = -ENOMEM;
> +goto unlock;
> +}
> +
> +otg->dev = dev;
> +otg->caps = config->otg_caps;
> +
> +if ((otg->caps->hnp_support || otg->caps->srp_support ||
> + otg->caps->adp_support) && !config->otg_work)
> +dev_info(dev, "otg: limiting to dual-role\n");
> >>>
> >>> What does above mean? Customized otg_work item may be dual-role,
> >>> may be full otg.
> >>
> >> I'm checking for !config->otg_work so we're sure of using the
> >> default dual-role only work function.
> >>
> >
> > I see. But whether it is dual-role or fully otg should depend on
> > otg->caps, the work item may be different according to design.
> > Besides, your code seems to depend on one of the otg capabilities
> > for dual-role.
> >
> Which capability? Id/vbus status?
>
if (otg->caps->hnp_support || otg->caps->srp_support || otg->caps->adp_support)
it is fully otg;
else
it is dual role;
Do you think so?
--
Best Regards,
Peter Chen
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 07/12] usb: otg: add OTG/dual-role core
On Wed, Apr 20, 2016 at 10:02:33AM +0300, Roger Quadros wrote:
> On 19/04/16 11:06, Peter Chen wrote:
> > On Tue, Apr 05, 2016 at 05:05:12PM +0300, Roger Quadros wrote:
> >> +/**
> >> + * usb_otg_start_host - start/stop the host controller
> >> + * @otg: usb_otg instance
> >> + * @on: true to start, false to stop
> >> + *
> >> + * Start/stop the USB host controller. This function is meant
> >> + * for use by the OTG controller driver.
> >> + */
> >> +int usb_otg_start_host(struct usb_otg *otg, int on)
> >> +{
> >> + struct otg_hcd_ops *hcd_ops = otg->hcd_ops;
> >> +
> >> + dev_dbg(otg->dev, "otg: %s %d\n", __func__, on);
> >> + if (!otg->host) {
> >> + WARN_ONCE(1, "otg: fsm running without host\n");
> >> + return 0;
> >> + }
> >> +
> >> + if (on) {
> >> + if (otg->flags & OTG_FLAG_HOST_RUNNING)
> >> + return 0;
> >> +
> >> + otg->flags |= OTG_FLAG_HOST_RUNNING;
> >> +
> >> + /* start host */
> >> + hcd_ops->add(otg->primary_hcd.hcd, otg->primary_hcd.irqnum,
> >> + otg->primary_hcd.irqflags);
> >> + if (otg->shared_hcd.hcd) {
> >> + hcd_ops->add(otg->shared_hcd.hcd,
> >> + otg->shared_hcd.irqnum,
> >> + otg->shared_hcd.irqflags);
> >> + }
> >
> > Check the return value please.
>
> And what should we do on failure?
> Even if things fail, they could potentially start working on next
> remove/add iteration so I didn't bother checking return values.
>
If usb_add_hcd has failed, the hcd may be released (usb_put_hcd is
called), in that case, we can't call usb_remove_hcd, maybe we may
need to add hcd valid check for primary hcd too. Even we can't
stop fsm, we need to show an error message for user.
Chipidea idea have a bug before:
commit 41314fea2ffb6dc716b7e698a47c68b329602fc0
Author: Russell King - ARM Linux
Date: Wed Oct 16 13:45:15 2013 +0100
usb/chipidea: fix oops on memory allocation failure
--
Best Regards,
Peter Chen
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 01/12] usb: hcd: Initialize hcd->flags to 0
On Wed, Apr 20, 2016 at 11:15:30AM +0300, Roger Quadros wrote: > On 19/04/16 04:56, Peter Chen wrote: > > On Mon, Apr 18, 2016 at 10:11:29AM -0400, Alan Stern wrote: > >> On Mon, 18 Apr 2016, Peter Chen wrote: > >> > >>> On Wed, Apr 06, 2016 at 09:32:22AM +0300, Roger Quadros wrote: > On 06/04/16 09:09, Felipe Balbi wrote: > > > > Hi, > > > > Roger Quadros writes: > >> diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c > >> index 2ca2cef..6b1930d 100644 > >> --- a/drivers/usb/core/hcd.c > >> +++ b/drivers/usb/core/hcd.c > >> @@ -2706,6 +2706,7 @@ int usb_add_hcd(struct usb_hcd *hcd, > >>int retval; > >>struct usb_device *rhdev; > >> > >> + hcd->flags = 0; > > > > seems like this would make more sense in usb_del_hcd() instead. > > > > OK, I'll move it there. > > >>> > >>> It depends on Alan's comments, whether only usb_add_hcd/usb_del_hcd > >>> pair can be called repeat. If Alan acks it, I have no idea for it. > >> > >> Most of the host controller drivers were not written with this in mind, > >> but I think it would be a good thing to allow. It would speed up the > >> host/device role switches. > >> > >> This might mean we need to fix up several drivers to make them work > >> correctly in an OTG environment. It should be possible to do this. Is > >> there any particular reason why it would be difficult for Chipidea? > >> > > > > I just want to do clean remove at OTG environment, like rmmod, so I did > > this when I worked on chipidea OTG design. > > I am worried if there are some resources dedicated for host device, eg, > > clocks, gpio. etc. > > > > If OTG framework can know well hcd's add and remove, it is ok for chipidea > > just calling usb_add_hcd/usb_del_hcd currently, but I suggested roger > > adding platform hcd_ops as optional parameter in case the platform > > has special requirement for hcd_ops. > > > We have 2 users now, omap + dwc3 and sh + EHCI/OHCI and we didn't seem to > observe any issues with the usb_add/del_hcd approach. > > Let's keep things minimal for now. In the future, if users need something more > we can always extend the framework. > I agree -- 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
[PATCHv2] usb: Add driver for UCSI
USB Type-C Connector System Software Interface (UCSI) is
specification that defines the registers and data structures
that can be used to control USB Type-C ports on a system.
UCSI is used on several Intel Broxton SoC based platforms.
Things that UCSI can be used to control include at least USB
Data Role swapping, Power Role swapping and controlling of
Alternate Modes on top of providing general details about
the port and the partners that are attached to it.
The initial purpose of the UCSI driver is to make sure USB
is in host mode on desktop and server systems that are USB
dual role capable, and provide UCSI interface.
The goal is to integrate the driver later to an USB Type-C
framework for Linux kernel, and at the same time add support
for more extensive USB Type-C port control that UCSI offers,
for example data role swapping, power role swapping,
Alternate Mode control etc.
The UCSI specification is public can be obtained from here:
http://www.intel.com/content/www/us/en/io/universal-serial-bus/usb-type-c-ucsi-spec.html
Signed-off-by: Heikki Krogerus
---
drivers/usb/misc/Kconfig | 26 +++
drivers/usb/misc/Makefile | 1 +
drivers/usb/misc/ucsi.c | 467 ++
drivers/usb/misc/ucsi.h | 215 +
4 files changed, 709 insertions(+)
create mode 100644 drivers/usb/misc/ucsi.c
create mode 100644 drivers/usb/misc/ucsi.h
Changes since v1:
- Now just always using host mode. Got rid of the modules parameter.
- Replaced the atomic_t with bitop "flags". It's used to sync
communication with the PPMs.
- Refactored the notifier handler based on suggestions from Felipe
and Andy
- Added data structure for CCI as suggested by Felipe
diff --git a/drivers/usb/misc/Kconfig b/drivers/usb/misc/Kconfig
index f7a7fc2..e9e5ae5 100644
--- a/drivers/usb/misc/Kconfig
+++ b/drivers/usb/misc/Kconfig
@@ -268,3 +268,29 @@ config USB_CHAOSKEY
To compile this driver as a module, choose M here: the
module will be called chaoskey.
+
+config UCSI
+ tristate "USB Type-C Connector System Software Interface driver"
+ depends on ACPI
+ help
+ UCSI driver is meant to be used as a convenience tool for desktop and
+ server systems that are not equipped to handle USB in device mode. It
+ will always select USB host role for the USB Type-C ports on systems
+ that provide UCSI interface.
+
+ USB Type-C Connector System Software Interface (UCSI) is a
+ specification for an interface that allows the Operating System to
+ control the USB Type-C ports on a system. Things the need controlling
+ include the USB Data Role (host or device), and when USB Power
+ Delivery is supported, the Power Role (source or sink). With USB
+ Type-C connectors, when two dual role capable devices are attached
+ together, the data role is selected randomly. Therefore it is
+ important to give the OS a way to select the role. Otherwise the user
+ would have to unplug and replug in order in order to attempt to swap
+ the data and power roles.
+
+ The UCSI specification can be downloaded from:
+
http://www.intel.com/content/www/us/en/io/universal-serial-bus/usb-type-c-ucsi-spec.html
+
+ To compile the driver as a module, choose M here: the module will be
+ called ucsi.
diff --git a/drivers/usb/misc/Makefile b/drivers/usb/misc/Makefile
index 45fd4ac..2769cf6 100644
--- a/drivers/usb/misc/Makefile
+++ b/drivers/usb/misc/Makefile
@@ -26,6 +26,7 @@ obj-$(CONFIG_USB_SEVSEG) += usbsevseg.o
obj-$(CONFIG_USB_YUREX)+= yurex.o
obj-$(CONFIG_USB_HSIC_USB3503) += usb3503.o
obj-$(CONFIG_USB_CHAOSKEY) += chaoskey.o
+obj-$(CONFIG_UCSI) += ucsi.o
obj-$(CONFIG_USB_SISUSBVGA)+= sisusbvga/
obj-$(CONFIG_USB_LINK_LAYER_TEST) += lvstest.o
diff --git a/drivers/usb/misc/ucsi.c b/drivers/usb/misc/ucsi.c
new file mode 100644
index 000..1da48d6
--- /dev/null
+++ b/drivers/usb/misc/ucsi.c
@@ -0,0 +1,467 @@
+/*
+ * USB Type-C Connector System Software Interface driver
+ *
+ * Copyright (C) 2016, Intel Corporation
+ * Author: Heikki Krogerus
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+
+#include "ucsi.h"
+
+/* Double the time defined by MIN_TIME_TO_RESPOND_WITH_BUSY */
+#define UCSI_TIMEOUT_MS 20
+
+enum ucsi_status {
+ UCSI_IDLE = 0,
+ UCSI_BUSY,
+ UCSI_ERROR,
+};
+
+struct ucsi_connector {
+ int num;
+ struct ucsi *ucsi;
+ struct work_struct work;
+ struct ucsi_connector_capability cap;
+};
+
+struct ucsi {
+ struct device *dev;
+ struct ucsi_data __iomem *data;
+
+ enum ucsi_status sta
[RESEND PATCH v4] kconfig/symbol.c: handle choice_values that depend on 'm' symbols
If choices consist of choice_values that depend on symbols set to 'm',
those choice_values are not set to 'n' if the choice is changed from
'm' to 'y' (in which case only one active choice_value is allowed).
Those values are also written to the config file causing modules to be
built when they should not.
The following config can be used to reproduce and examine the problem;
with the frontend of your choice set "Choice 0" and "Choice 1" to 'm',
then set "Tristate Choice" to 'y' and save the configuration:
config modules
boolean modules
default y
option modules
config dependency
tristate "Dependency"
default m
choice
prompt "Tristate Choice"
default choice0
config choice0
tristate "Choice 0"
config choice1
tristate "Choice 1"
depends on dependency
endchoice
This patch sets choice_values' visibility that depend on symbols set
to 'm' to 'n' if the corresponding choice is set to 'y'. This makes
them disappear from the choice list and will also cause the
choice_values' value set to 'n' in sym_calc_value() and as a result
they are written as "not set" to the resulting .config file.
Reported-by: Sebastian Andrzej Siewior
Signed-off-by: Dirk Gouders
Tested-by: Sebastian Andrzej Siewior
---
scripts/kconfig/symbol.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/scripts/kconfig/symbol.c b/scripts/kconfig/symbol.c
index c9a6775..06d96c9 100644
--- a/scripts/kconfig/symbol.c
+++ b/scripts/kconfig/symbol.c
@@ -189,12 +189,23 @@ static void sym_validate_range(struct symbol *sym)
static void sym_calc_visibility(struct symbol *sym)
{
struct property *prop;
+ struct symbol *choice_sym = NULL;
tristate tri;
/* any prompt visible? */
tri = no;
+
+ if (sym_is_choice_value(sym))
+ choice_sym = prop_get_symbol(sym_get_choice_prop(sym));
+
for_all_prompts(sym, prop) {
prop->visible.tri = expr_calc_value(prop->visible.expr);
+ /*
+* choice_values with visibility 'mod' are not visible if the
+* corresponding choice's value is 'yes'.
+*/
+ if (prop->visible.tri == mod && (choice_sym &&
choice_sym->curr.tri == yes))
+ prop->visible.tri = no;
tri = EXPR_OR(tri, prop->visible.tri);
}
if (tri == mod && (sym->type != S_TRISTATE || modules_val == no))
--
1.8.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
Re: [RFC] DMA initialization for manually created devices
Hi again, Felipe Balbi writes: > David Woodhouse writes: >> On Tue, 2016-04-19 at 14:38 +0300, Felipe Balbi wrote: >>> >>> The reason for that I'm using a manually created platform_device and >>> that misses dev->archdata which the underlying/parent PCI device has. >> >> Typically we'd expect you to use the parent device for DMA, as in your >> second option. >> >> That said, we're exploring the option of moving the dma_ops to be a >> first-class member of 'struct device' instead of hiding it in archdata, >> and cleaning up the way that it gets initialised for newly-created >> devices. And at that point we might end up letting it get inherited >> from the parent so your original code *would* work... but I wouldn't >> hold your breath for that. >> >> Definitely *don't* mess around in archdata. > > alright, I'll patch it up to use parent device everywhere, at least for > now. reviving this a little bit, it seems like inheritance of DMA bits from parent is the way to go in the future. Let's consider a dual-role instance of dwc3: The peripheral IP is Synopsys' proprietary and gets built into dwc3.ko which is a child device of a parent dwc3-pci.ko (in case of intel, at least). The host side, is regular XHCI, so dwc3.ko creates yet another child device for xhci-plat.ko. The parent-child tree ends up like so: dwc3-pci |_ dwc3 |_ xhci-plat dma for dwc3.ko is simple(-ish), instead of dma_alloc_coherent(dev, ), we just replace that with dma_alloc_coherent(dev->parent, ...). As for XHCI, which is a generic device also used directly by PCI devices, the problem is more peculiar. For dwc3's xHCI, we would have to call dma_alloc_coherent(dev->parent->parent, ...), but that would break regular, non-dwc3 XHCI blocks which have direct access to the pci device. So, for dwc3.ko, I've fixed this with [1], however, if I remove copying of DMA bits from parent to child, xhci-plat.ko will regress. Any hints for this particular situation ? The solution, IMO, is to either automatic copying of parent's DMA bits to child by the time it's registered, or make DMA API search the device parent tree until it finds a parent with a suitable DMA configuration. [1] https://marc.info/?l=linux-usb&m=146107237232681&w=2 -- balbi signature.asc Description: PGP signature
Re: [RESEND PATCH v4] kconfig/symbol.c: handle choice_values that depend on 'm' symbols
Hi,
[auto build test ERROR on v4.6-rc4]
[also build test ERROR on next-20160420]
[if your patch is applied to the wrong git tree, please drop us a note to help
improving the system]
url:
https://github.com/0day-ci/linux/commits/Dirk-Gouders/kconfig-symbol-c-handle-choice_values-that-depend-on-m-symbols/20160420-182514
config: i386-randconfig-i0-201616 (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
drivers/usb/gadget/legacy/dbgp.c: In function 'dbgp_disconnect':
>> drivers/usb/gadget/legacy/dbgp.c:213:25: error: 'struct dbgp' has no member
>> named 'serial'
gserial_disconnect(dbgp.serial);
^
drivers/usb/gadget/legacy/dbgp.c: In function 'dbgp_setup':
drivers/usb/gadget/legacy/dbgp.c:374:29: error: 'struct dbgp' has no member
named 'serial'
err = gserial_connect(dbgp.serial, tty_line);
^
>> drivers/usb/gadget/legacy/dbgp.c:374:38: error: 'tty_line' undeclared (first
>> use in this function)
err = gserial_connect(dbgp.serial, tty_line);
^
drivers/usb/gadget/legacy/dbgp.c:374:38: note: each undeclared identifier is
reported only once for each function it appears in
vim +213 drivers/usb/gadget/legacy/dbgp.c
f6c826a9 drivers/usb/gadget/dbgp.cstephane duverger 2010-07-12
207
f6c826a9 drivers/usb/gadget/dbgp.cstephane duverger 2010-07-12
208 static void dbgp_disconnect(struct usb_gadget *gadget)
f6c826a9 drivers/usb/gadget/dbgp.cstephane duverger 2010-07-12
209 {
f6c826a9 drivers/usb/gadget/dbgp.cstephane duverger 2010-07-12
210 #ifdef CONFIG_USB_G_DBGP_PRINTK
f6c826a9 drivers/usb/gadget/dbgp.cstephane duverger 2010-07-12
211 dbgp_disable_ep();
f6c826a9 drivers/usb/gadget/dbgp.cstephane duverger 2010-07-12
212 #else
f6c826a9 drivers/usb/gadget/dbgp.cstephane duverger 2010-07-12
@213 gserial_disconnect(dbgp.serial);
f6c826a9 drivers/usb/gadget/dbgp.cstephane duverger 2010-07-12
214 #endif
f6c826a9 drivers/usb/gadget/dbgp.cstephane duverger 2010-07-12
215 }
f6c826a9 drivers/usb/gadget/dbgp.cstephane duverger 2010-07-12
216
f6c826a9 drivers/usb/gadget/dbgp.cstephane duverger 2010-07-12
217 static void dbgp_unbind(struct usb_gadget *gadget)
f6c826a9 drivers/usb/gadget/dbgp.cstephane duverger 2010-07-12
218 {
f6c826a9 drivers/usb/gadget/dbgp.cstephane duverger 2010-07-12
219 #ifdef CONFIG_USB_G_DBGP_SERIAL
f6c826a9 drivers/usb/gadget/dbgp.cstephane duverger 2010-07-12
220 kfree(dbgp.serial);
4958cf32 drivers/usb/gadget/legacy/dbgp.c Alexey Khoroshilov2014-08-10
221 dbgp.serial = NULL;
f6c826a9 drivers/usb/gadget/dbgp.cstephane duverger 2010-07-12
222 #endif
f6c826a9 drivers/usb/gadget/dbgp.cstephane duverger 2010-07-12
223 if (dbgp.req) {
f6c826a9 drivers/usb/gadget/dbgp.cstephane duverger 2010-07-12
224 kfree(dbgp.req->buf);
f6c826a9 drivers/usb/gadget/dbgp.cstephane duverger 2010-07-12
225 usb_ep_free_request(gadget->ep0, dbgp.req);
4958cf32 drivers/usb/gadget/legacy/dbgp.c Alexey Khoroshilov2014-08-10
226 dbgp.req = NULL;
f6c826a9 drivers/usb/gadget/dbgp.cstephane duverger 2010-07-12
227 }
f6c826a9 drivers/usb/gadget/dbgp.cstephane duverger 2010-07-12
228 }
f6c826a9 drivers/usb/gadget/dbgp.cstephane duverger 2010-07-12
229
19b10a88 drivers/usb/gadget/dbgp.cSebastian Andrzej Siewior 2012-12-23
230 #ifdef CONFIG_USB_G_DBGP_SERIAL
19b10a88 drivers/usb/gadget/dbgp.cSebastian Andrzej Siewior 2012-12-23
231 static unsigned char tty_line;
19b10a88 drivers/usb/gadget/dbgp.cSebastian Andrzej Siewior 2012-12-23
232 #endif
19b10a88 drivers/usb/gadget/dbgp.cSebastian Andrzej Siewior 2012-12-23
233
6876d58f drivers/usb/gadget/legacy/dbgp.c Kyösti Mälkki 2014-11-03
234 static int dbgp_configure_endpoints(struct usb_gadget *gadget)
f6c826a9 drivers/usb/gadget/dbgp.cstephane duverger 2010-07-12
235 {
f6c826a9 drivers/usb/gadget/dbgp.cstephane duverger 2010-07-12
236 int stp;
f6c826a9 drivers/usb/gadget/dbgp.cstephane duverger 2010-07-12
237
f6c826a9 drivers/usb/gadget/dbgp.cstephane duverger 2010-07-12
238 usb_ep_autoconfig_reset(gadget);
f6c826a9 drivers/usb/gadget/dbgp.cstephane duverger 2010-07-12
239
f6c826a9 drivers/usb/gadget/dbgp.cstephane
Re: [RESEND PATCH v4] kconfig/symbol.c: handle choice_values that depend on 'm' symbols
Hi, [auto build test ERROR on v4.6-rc4] [also build test ERROR on next-20160420] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] url: https://github.com/0day-ci/linux/commits/Dirk-Gouders/kconfig-symbol-c-handle-choice_values-that-depend-on-m-symbols/20160420-182514 config: x86_64-randconfig-s0-04201943 (attached as .config) reproduce: # save the attached .config to linux build tree make ARCH=x86_64 All errors (new ones prefixed by >>): >> fs/romfs/storage.c:18:2: error: #error no ROMFS backing store interface >> configured #error no ROMFS backing store interface configured ^ vim +18 fs/romfs/storage.c da4458bd David Howells2009-02-12 2 * da4458bd David Howells2009-02-12 3 * Copyright © 2007 Red Hat, Inc. All Rights Reserved. da4458bd David Howells2009-02-12 4 * Written by David Howells (dhowe...@redhat.com) da4458bd David Howells2009-02-12 5 * da4458bd David Howells2009-02-12 6 * This program is free software; you can redistribute it and/or da4458bd David Howells2009-02-12 7 * modify it under the terms of the GNU General Public License da4458bd David Howells2009-02-12 8 * as published by the Free Software Foundation; either version da4458bd David Howells2009-02-12 9 * 2 of the License, or (at your option) any later version. da4458bd David Howells2009-02-12 10 */ da4458bd David Howells2009-02-12 11 da4458bd David Howells2009-02-12 12 #include da4458bd David Howells2009-02-12 13 #include da4458bd David Howells2009-02-12 14 #include da4458bd David Howells2009-02-12 15 #include "internal.h" da4458bd David Howells2009-02-12 16 da4458bd David Howells2009-02-12 17 #if !defined(CONFIG_ROMFS_ON_MTD) && !defined(CONFIG_ROMFS_ON_BLOCK) da4458bd David Howells2009-02-12 @18 #error no ROMFS backing store interface configured da4458bd David Howells2009-02-12 19 #endif da4458bd David Howells2009-02-12 20 da4458bd David Howells2009-02-12 21 #ifdef CONFIG_ROMFS_ON_MTD c382fb43 Artem Bityutskiy 2012-01-30 22 #define ROMFS_MTD_READ(sb, ...) mtd_read((sb)->s_mtd, ##__VA_ARGS__) da4458bd David Howells2009-02-12 23 da4458bd David Howells2009-02-12 24 /* da4458bd David Howells2009-02-12 25 * read data from an romfs image on an MTD device da4458bd David Howells2009-02-12 26 */ :: The code at line 18 was first introduced by commit :: da4458bda237aa0cb1688f6c359477f203788f6a NOMMU: Make it possible for RomFS to use MTD devices directly :: TO: David Howells :: CC: David Woodhouse --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: Binary data
Re: 03f0:521d Hewlett-Packard
Hello, I got HP Pro X2 612 G1 with 03f0:521d and unfortunately can not connect to mobile broadband (using network manager). I have tried booting Linux Mint 17.3, Fedora 23, Ubuntu 14.10 from USB stick.. Network Manager shows Mobile Broadband option ((it even shows signal strength)) after: # modprobe usbserial vendor=0x03f0 product=0x521d but I am not able to connect.. Would be thankful for any ideas/recommendations.. Good luck -- 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: [RESEND PATCH v4] kconfig/symbol.c: handle choice_values that depend on 'm' symbols
kbuild test robot writes:
> Hi,
>
> [auto build test ERROR on v4.6-rc4]
> [also build test ERROR on next-20160420]
> [if your patch is applied to the wrong git tree, please drop us a note to
> help improving the system]
>
> url:
> https://github.com/0day-ci/linux/commits/Dirk-Gouders/kconfig-symbol-c-handle-choice_values-that-depend-on-m-symbols/20160420-182514
> config: i386-randconfig-i0-201616 (attached as .config)
> reproduce:
> # save the attached .config to linux build tree
> make ARCH=i386
This problem is because, with this patch we now get a Problem if choices
are all boolean and all of them depend on a symbol set to 'm'. In this
case none of the choices can be other than 'n'. I'm not sure if we want
such a behavior.
In the case of dbgp we could probably fix the Kconfig file by removing
the dependency from the default choice (the choices are surrounded by
"if USB_G_DBGP", anyway).
Suggestions are very welcome.
Dirk
> All errors (new ones prefixed by >>):
>
>drivers/usb/gadget/legacy/dbgp.c: In function 'dbgp_disconnect':
>>> drivers/usb/gadget/legacy/dbgp.c:213:25: error: 'struct dbgp' has no member
>>> named 'serial'
> gserial_disconnect(dbgp.serial);
> ^
>drivers/usb/gadget/legacy/dbgp.c: In function 'dbgp_setup':
>drivers/usb/gadget/legacy/dbgp.c:374:29: error: 'struct dbgp' has no
> member named 'serial'
> err = gserial_connect(dbgp.serial, tty_line);
> ^
>>> drivers/usb/gadget/legacy/dbgp.c:374:38: error: 'tty_line' undeclared
>>> (first use in this function)
> err = gserial_connect(dbgp.serial, tty_line);
> ^
>drivers/usb/gadget/legacy/dbgp.c:374:38: note: each undeclared identifier
> is reported only once for each function it appears in
>
> vim +213 drivers/usb/gadget/legacy/dbgp.c
>
> f6c826a9 drivers/usb/gadget/dbgp.cstephane duverger
> 2010-07-12 207
> f6c826a9 drivers/usb/gadget/dbgp.cstephane duverger
> 2010-07-12 208 static void dbgp_disconnect(struct usb_gadget *gadget)
> f6c826a9 drivers/usb/gadget/dbgp.cstephane duverger
> 2010-07-12 209 {
> f6c826a9 drivers/usb/gadget/dbgp.cstephane duverger
> 2010-07-12 210 #ifdef CONFIG_USB_G_DBGP_PRINTK
> f6c826a9 drivers/usb/gadget/dbgp.cstephane duverger
> 2010-07-12 211 dbgp_disable_ep();
> f6c826a9 drivers/usb/gadget/dbgp.cstephane duverger
> 2010-07-12 212 #else
> f6c826a9 drivers/usb/gadget/dbgp.cstephane duverger
> 2010-07-12 @213 gserial_disconnect(dbgp.serial);
> f6c826a9 drivers/usb/gadget/dbgp.cstephane duverger
> 2010-07-12 214 #endif
> f6c826a9 drivers/usb/gadget/dbgp.cstephane duverger
> 2010-07-12 215 }
> f6c826a9 drivers/usb/gadget/dbgp.cstephane duverger
> 2010-07-12 216
> f6c826a9 drivers/usb/gadget/dbgp.cstephane duverger
> 2010-07-12 217 static void dbgp_unbind(struct usb_gadget *gadget)
> f6c826a9 drivers/usb/gadget/dbgp.cstephane duverger
> 2010-07-12 218 {
> f6c826a9 drivers/usb/gadget/dbgp.cstephane duverger
> 2010-07-12 219 #ifdef CONFIG_USB_G_DBGP_SERIAL
> f6c826a9 drivers/usb/gadget/dbgp.cstephane duverger
> 2010-07-12 220 kfree(dbgp.serial);
> 4958cf32 drivers/usb/gadget/legacy/dbgp.c Alexey Khoroshilov
> 2014-08-10 221 dbgp.serial = NULL;
> f6c826a9 drivers/usb/gadget/dbgp.cstephane duverger
> 2010-07-12 222 #endif
> f6c826a9 drivers/usb/gadget/dbgp.cstephane duverger
> 2010-07-12 223 if (dbgp.req) {
> f6c826a9 drivers/usb/gadget/dbgp.cstephane duverger
> 2010-07-12 224 kfree(dbgp.req->buf);
> f6c826a9 drivers/usb/gadget/dbgp.cstephane duverger
> 2010-07-12 225 usb_ep_free_request(gadget->ep0, dbgp.req);
> 4958cf32 drivers/usb/gadget/legacy/dbgp.c Alexey Khoroshilov
> 2014-08-10 226 dbgp.req = NULL;
> f6c826a9 drivers/usb/gadget/dbgp.cstephane duverger
> 2010-07-12 227 }
> f6c826a9 drivers/usb/gadget/dbgp.cstephane duverger
> 2010-07-12 228 }
> f6c826a9 drivers/usb/gadget/dbgp.cstephane duverger
> 2010-07-12 229
> 19b10a88 drivers/usb/gadget/dbgp.cSebastian Andrzej Siewior
> 2012-12-23 230 #ifdef CONFIG_USB_G_DBGP_SERIAL
> 19b10a88 drivers/usb/gadget/dbgp.cSebastian Andrzej Siewior
> 2012-12-2
[PATCH 1/2] USB: LTM also for USB 3.1
LTM is also defined for SS+. The correct test is to check for anything
slower than SS not exactly SS.
Signed-off-by: Oliver Neukum
---
include/linux/usb.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/usb.h b/include/linux/usb.h
index 6a9a0c2..29aba760 100644
--- a/include/linux/usb.h
+++ b/include/linux/usb.h
@@ -720,7 +720,7 @@ extern void usb_enable_ltm(struct usb_device *udev);
static inline bool usb_device_supports_ltm(struct usb_device *udev)
{
- if (udev->speed != USB_SPEED_SUPER || !udev->bos || !udev->bos->ss_cap)
+ if (udev->speed < USB_SPEED_SUPER || !udev->bos || !udev->bos->ss_cap)
return false;
return udev->bos->ss_cap->bmAttributes & USB_LTM_SUPPORT;
}
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] USB: correct intervals for SS+
SS+ also expresses intervals in units of 125ms. Testing must
be for SS or faster, not SS exactly.
Signed-off-by: Oliver neukum
---
include/linux/usb.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/linux/usb.h b/include/linux/usb.h
index 29aba760..7824f45 100644
--- a/include/linux/usb.h
+++ b/include/linux/usb.h
@@ -1569,7 +1569,7 @@ static inline void usb_fill_bulk_urb(struct urb *urb,
* Initializes a interrupt urb with the proper information needed to submit
* it to a device.
*
- * Note that High Speed and SuperSpeed interrupt endpoints use a logarithmic
+ * Note that High Speed and SuperSpeed(+) interrupt endpoints use a logarithmic
* encoding of the endpoint interval, and express polling intervals in
* microframes (eight per millisecond) rather than in frames (one per
* millisecond).
@@ -1595,7 +1595,7 @@ static inline void usb_fill_int_urb(struct urb *urb,
urb->complete = complete_fn;
urb->context = context;
- if (dev->speed == USB_SPEED_HIGH || dev->speed == USB_SPEED_SUPER) {
+ if (dev->speed == USB_SPEED_HIGH || dev->speed >= USB_SPEED_SUPER) {
/* make sure interval is within allowed range */
interval = clamp(interval, 1, 16);
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] Correcting a few remaining test for USB_SPEED_SUPER
It looks to me like the tests for LTM and the units of intervals for periodic transfers used ==USB_SPEED_SUPER where >=USB_SPEED_SUPER should have been used. Oliver Neukum (2): USB: LTM also for USB 3.1 USB: correct intervals for SS+ include/linux/usb.h | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] hub: admit devices are SS+
If a port can do 10 Gb/s the kernel should say so.
The corresponding check needs to be added.
Signed-off.by: Oliver Neukum >
---
drivers/usb/core/hub.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 38cc4ba..c2270d8 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -104,6 +104,8 @@ static int usb_reset_and_verify_device(struct usb_device
*udev);
static inline char *portspeed(struct usb_hub *hub, int portstatus)
{
+ if (hub_is_superspeedplus(hub->hdev))
+ return "10.0 Gb/s";
if (hub_is_superspeed(hub->hdev))
return "5.0 Gb/s";
if (portstatus & USB_PORT_STAT_HIGH_SPEED)
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] USB: serial: Use IS_ENABLED() instead of checking for FOO || FOO_MODULE
The IS_ENABLED() macro checks if a Kconfig symbol has been enabled either built-in or as a module, use that macro instead of open coding the same. Signed-off-by: Javier Martinez Canillas --- drivers/usb/serial/usb-serial.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/serial/usb-serial.c b/drivers/usb/serial/usb-serial.c index 46f1f13b41f1..7ecf4ff86b9a 100644 --- a/drivers/usb/serial/usb-serial.c +++ b/drivers/usb/serial/usb-serial.c @@ -815,7 +815,7 @@ static int usb_serial_probe(struct usb_interface *interface, } } -#if defined(CONFIG_USB_SERIAL_PL2303) || defined(CONFIG_USB_SERIAL_PL2303_MODULE) +#if IS_ENABLED(CONFIG_USB_SERIAL_PL2303) /* BEGIN HORRIBLE HACK FOR PL2303 */ /* this is needed due to the looney way its endpoints are set up */ if (((le16_to_cpu(dev->descriptor.idVendor) == PL2303_VENDOR_ID) && -- 2.5.5 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: XHCI is slow during boot (bios/efi) and leaves many dmesg messages
Hey all, On 11-04-16 20:29, Janna Martl wrote: On Mon, Apr 11, 2016 at 02:15:24PM -0400, Janna Martl wrote: On Mon, Apr 11, 2016 at 11:22:12AM +0300, Felipe Balbi wrote: Just to confirm, can you check that disabling LPM solves the problem ? I tried your patch on 4.6.0-rc3 but it doesn't seem to change anything. Also I'm quite sure I was using some 3.17.x (and probably 3.18.x) before this issue started for me, but I just tried booting 3.17.1 a few times and am getting the same behavior (there's a delay about half the time). I think the start of the issue might have coincided with trying to boot from usb (but I've booted from usb since then and it hasn't made any difference). Is there any update here, any patch I should try to see if it improves things? -- J.M. -- 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] Documentation: dt-bindings: dwc2: add the resets and reset-names property
From: Dinh Nguyen Document the optional 'resets' and 'reset-names' property for the DWC2 usb core. Signed-off-by: Dinh Nguyen Acked-by: Rob Herring --- Documentation/devicetree/bindings/usb/dwc2.txt | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Documentation/devicetree/bindings/usb/dwc2.txt b/Documentation/devicetree/bindings/usb/dwc2.txt index 20a68bf..c9ccea6 100644 --- a/Documentation/devicetree/bindings/usb/dwc2.txt +++ b/Documentation/devicetree/bindings/usb/dwc2.txt @@ -27,6 +27,9 @@ Refer to phy/phy-bindings.txt for generic phy consumer properties - g-rx-fifo-size: size of rx fifo size in gadget mode. - g-np-tx-fifo-size: size of non-periodic tx fifo size in gadget mode. - g-tx-fifo-size: size of periodic tx fifo per endpoint (except ep0) in gadget mode. +- resets: list of phandle and reset specifier pairs. The should be one entry for + softreset line of the USB IP. +- reset-names: Should be "dwc2". Example: -- 2.6.2 -- 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
[PATCHv6 2/2] usb: dwc2: Add reset control to dwc2
From: Dinh Nguyen
Allow for platforms that have a reset controller driver in place to bring
the USB IP out of reset.
Signed-off-by: Dinh Nguyen
---
v6: fix 80 line checkpatch warning in dev_err print
v5: updated error conditions for not finding the reset property
v4: use dev_dbg() if not a -EPROBE_DEFER
v3: fix compile error
v2: move to lowlevel_hw_init()
---
drivers/usb/dwc2/core.h | 1 +
drivers/usb/dwc2/platform.c | 21 +
2 files changed, 22 insertions(+)
diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index 3c58d63..f748132 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -837,6 +837,7 @@ struct dwc2_hsotg {
void *priv;
int irq;
struct clk *clk;
+ struct reset_control *reset;
unsigned int queuing_high_bandwidth:1;
unsigned int srp_success:1;
diff --git a/drivers/usb/dwc2/platform.c b/drivers/usb/dwc2/platform.c
index 88629be..fa2c097 100644
--- a/drivers/usb/dwc2/platform.c
+++ b/drivers/usb/dwc2/platform.c
@@ -45,6 +45,7 @@
#include
#include
#include
+#include
#include
@@ -337,6 +338,23 @@ static int dwc2_lowlevel_hw_init(struct dwc2_hsotg *hsotg)
{
int i, ret;
+ hsotg->reset = devm_reset_control_get(hsotg->dev, "dwc2");
+ if (IS_ERR(hsotg->reset)) {
+ ret = PTR_ERR(hsotg->reset);
+ switch (ret) {
+ case -ENOENT:
+ hsotg->reset = NULL;
+ break;
+ default:
+ dev_err(hsotg->dev, "error getting reset control %d\n",
+ ret);
+ return ret;
+ }
+ }
+
+ if (hsotg->reset)
+ reset_control_deassert(hsotg->reset);
+
/* Set default UTMI width */
hsotg->phyif = GUSBCFG_PHYIF16;
@@ -434,6 +452,9 @@ static int dwc2_driver_remove(struct platform_device *dev)
if (hsotg->ll_hw_enabled)
dwc2_lowlevel_hw_disable(hsotg);
+ if (hsotg->reset)
+ reset_control_assert(hsotg->reset);
+
return 0;
}
--
2.6.2
--
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
4.5.1: UBSAN: Undefined behaviour in ./arch/x86/include/asm/atomic.h:156:9
Hi, I am not certain to to forward this to, so I am trying linux-usb and ext4. Please add relevant people/lists, thank you. # dmesg | grep "UBSAN: Undefined behaviour" [2.638843] UBSAN: Undefined behaviour in drivers/usb/host/ehci-hub.c:873:47 [8.553620] UBSAN: Undefined behaviour in fs/ext4/mballoc.c:2612:15 [ 25.341048] UBSAN: Undefined behaviour in fs/ext4/mballoc.c:1274:11 [ 41.460542] UBSAN: Undefined behaviour in ./arch/x86/include/asm/atomic.h:156:9 # Full dmesg is attached. Hope this helps, Martin [0.00] Linux version 4.5.1-default-pciehp (root@vostro) (gcc version 5.3.0 (Gentoo 5.3.0 p1.0, pie-0.6.5) ) #1 SMP Thu Apr 14 14:17:48 CEST 2016 [0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-4.5.1 root=/dev/sda5 ro slub_debug=AFPZ pciehp.pciehp_debug=1 pciehp_debug=1 intel_idle.max_cstate=c3 i915.i915_enable_rc6=1 usbcore.autosuspend=-1 [0.00] x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256 [0.00] x86/fpu: Supporting XSAVE feature 0x01: 'x87 floating point registers' [0.00] x86/fpu: Supporting XSAVE feature 0x02: 'SSE registers' [0.00] x86/fpu: Supporting XSAVE feature 0x04: 'AVX registers' [0.00] x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 'standard' format. [0.00] x86/fpu: Using 'eager' FPU context switches. [0.00] e820: BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x0009d3ff] usable [0.00] BIOS-e820: [mem 0x0009d400-0x0009] reserved [0.00] BIOS-e820: [mem 0x000e-0x000f] reserved [0.00] BIOS-e820: [mem 0x0010-0x1fff] usable [0.00] BIOS-e820: [mem 0x2000-0x201f] reserved [0.00] BIOS-e820: [mem 0x2020-0x3fff] usable [0.00] BIOS-e820: [mem 0x4000-0x401f] reserved [0.00] BIOS-e820: [mem 0x4020-0xda4e4fff] usable [0.00] BIOS-e820: [mem 0xda4e5000-0xda527fff] ACPI NVS [0.00] BIOS-e820: [mem 0xda528000-0xda792fff] usable [0.00] BIOS-e820: [mem 0xda793000-0xda966fff] reserved [0.00] BIOS-e820: [mem 0xda967000-0xdaa88fff] usable [0.00] BIOS-e820: [mem 0xdaa89000-0xdad67fff] reserved [0.00] BIOS-e820: [mem 0xdad68000-0xdafe7fff] ACPI NVS [0.00] BIOS-e820: [mem 0xdafe8000-0xdaff] ACPI data [0.00] BIOS-e820: [mem 0xdb80-0xdf9f] reserved [0.00] BIOS-e820: [mem 0xf800-0xfbff] reserved [0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved [0.00] BIOS-e820: [mem 0xfed0-0xfed03fff] reserved [0.00] BIOS-e820: [mem 0xfed1c000-0xfed1] reserved [0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved [0.00] BIOS-e820: [mem 0xff00-0x] reserved [0.00] BIOS-e820: [mem 0x0001-0x00041fdf] usable [0.00] NX (Execute Disable) protection: active [0.00] SMBIOS 2.6 present. [0.00] DMI: Dell Inc. Vostro 3550/, BIOS A12 02/18/2014 [0.00] e820: update [mem 0x-0x0fff] usable ==> reserved [0.00] e820: remove [mem 0x000a-0x000f] usable [0.00] e820: last_pfn = 0x41fe00 max_arch_pfn = 0x4 [0.00] MTRR default type: uncachable [0.00] MTRR fixed ranges enabled: [0.00] 0-9 write-back [0.00] A-B uncachable [0.00] C-C write-protect [0.00] D-E7FFF uncachable [0.00] E8000-F write-protect [0.00] MTRR variable ranges enabled: [0.00] 0 base 0 mask C write-back [0.00] 1 base 4 mask FE000 write-back [0.00] 2 base 0DB80 mask FFF80 uncachable [0.00] 3 base 0DC00 mask FFC00 uncachable [0.00] 4 base 0E000 mask FE000 uncachable [0.00] 5 base 41FE0 mask FFFE0 uncachable [0.00] 6 disabled [0.00] 7 disabled [0.00] 8 disabled [0.00] 9 disabled [0.00] x86/PAT: Configuration [0-7]: WB WC UC- UC WB WC UC- WT [0.00] e820: update [mem 0xdb80-0x] usable ==> reserved [0.00] e820: last_pfn = 0xdaa89 max_arch_pfn = 0x4 [0.00] Base memory trampoline at [88097000] 97000 size 24576 [0.00] reserving inaccessible SNB gfx pages [0.00] BRK [0x046ab000, 0x046abfff] PGTABLE [0.00] BRK [0x046ac000, 0x046acfff] PGTABLE [0.00] BRK [0x046ad000, 0x046adfff] PGTABLE [0.00] BRK [0x046ae000, 0x046aefff] PGTABLE [0.00] BRK [0x046af000, 0x046a] PGTABLE [0.
Re: 03f0:521d Hewlett-Packard
On Wed, Apr 20, 2016 at 12:20:29PM +, mirkt wrote: > Hello, > > I got HP Pro X2 612 G1 with 03f0:521d and unfortunately can not connect to > mobile broadband (using network manager). I have tried booting Linux Mint > 17.3, Fedora 23, Ubuntu 14.10 from USB stick.. Network Manager shows Mobile > Broadband option ((it even shows signal strength)) after: > > # modprobe usbserial vendor=0x03f0 product=0x521d > but I am not able to connect.. > > Would be thankful for any ideas/recommendations.. What is the output of 'lsusb -v -d 03f0:521d' ? thanks, 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: 4.5.1: UBSAN: Undefined behaviour in ./arch/x86/include/asm/atomic.h:156:9
On Thu, Apr 21, 2016 at 12:22:49AM +0200, Martin MOKREJŠ wrote: > Hi, > I am not certain to to forward this to, so I am trying linux-usb and ext4. > Please add relevant people/lists, thank you. > > # dmesg | grep "UBSAN: Undefined behaviour" > [2.638843] UBSAN: Undefined behaviour in > drivers/usb/host/ehci-hub.c:873:47 > [8.553620] UBSAN: Undefined behaviour in fs/ext4/mballoc.c:2612:15 > [ 25.341048] UBSAN: Undefined behaviour in fs/ext4/mballoc.c:1274:11 > [ 41.460542] UBSAN: Undefined behaviour in > ./arch/x86/include/asm/atomic.h:156:9 > # > > Full dmesg is attached. > > Hope this helps, > Martin > [0.00] Linux version 4.5.1-default-pciehp (root@vostro) (gcc version > 5.3.0 (Gentoo 5.3.0 p1.0, pie-0.6.5) ) #1 SMP Thu Apr 14 14:17:48 CEST 2016 Please try 4.6-rc4, a number of UBSAN issues have been fixed there. thansk, 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
[PATCH] usb: xhci-mtk: fixup mouse wakeup failure during system suspend
Click mouse after xhci suspend completion but before system suspend
completion, system will not be waken up by mouse if the duration of
them is larger than 20ms which is the device UFP's resume signaling
lasted. Another reason is that the SPM is not enabled before system
suspend compeltion, this causes SPM also not notice the resume signal.
So in order to reduce the duration less than 20ms, make use of
syscore's suspend/resume interface.
In fact it is a work around solution which only reduces the
probability of failure, because we can't ensure that the duration from
syscore's suspend completion to SPM working is always less than 20ms.
Because the syscore runs on irq disabled context, and xhci's
suspend/resume calls some sleeping functions, enable local irq
and then disable it during suspend/resume. This may be not a problem,
since only boot CPU is runing.
Signed-off-by: Chunfeng Yun
---
drivers/usb/host/xhci-mtk.c | 31 ++-
1 file changed, 30 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/host/xhci-mtk.c b/drivers/usb/host/xhci-mtk.c
index 79959f1..8277f02 100644
--- a/drivers/usb/host/xhci-mtk.c
+++ b/drivers/usb/host/xhci-mtk.c
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
#include "xhci.h"
#include "xhci-mtk.h"
@@ -490,6 +491,8 @@ static int xhci_mtk_setup(struct usb_hcd *hcd)
return xhci_gen_setup(hcd, xhci_mtk_quirks);
}
+static struct device *xhci_mtk_syscore_dev;
+
static int xhci_mtk_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
@@ -512,6 +515,7 @@ static int xhci_mtk_probe(struct platform_device *pdev)
if (!mtk)
return -ENOMEM;
+ xhci_mtk_syscore_dev = dev;
mtk->dev = dev;
mtk->vbus = devm_regulator_get(dev, "vbus");
if (IS_ERR(mtk->vbus)) {
@@ -740,6 +744,29 @@ static int __maybe_unused xhci_mtk_resume(struct device
*dev)
return 0;
}
+static int xhci_mtk_syscore_suspend(void)
+{
+ local_irq_enable();
+ xhci_mtk_suspend(xhci_mtk_syscore_dev);
+ local_irq_disable();
+
+ return 0;
+}
+
+static void xhci_mtk_syscore_resume(void)
+{
+ local_irq_enable();
+ xhci_mtk_resume(xhci_mtk_syscore_dev);
+ local_irq_disable();
+
+ return;
+}
+
+static struct syscore_ops xhci_mtk_syscore_ops = {
+ .suspend = xhci_mtk_syscore_suspend,
+ .resume = xhci_mtk_syscore_resume,
+};
+
static const struct dev_pm_ops xhci_mtk_pm_ops = {
SET_SYSTEM_SLEEP_PM_OPS(xhci_mtk_suspend, xhci_mtk_resume)
};
@@ -758,7 +785,7 @@ static struct platform_driver mtk_xhci_driver = {
.remove = xhci_mtk_remove,
.driver = {
.name = "xhci-mtk",
- .pm = DEV_PM_OPS,
+ /*.pm = DEV_PM_OPS,*/
.of_match_table = of_match_ptr(mtk_xhci_of_match),
},
};
@@ -766,6 +793,7 @@ MODULE_ALIAS("platform:xhci-mtk");
static int __init xhci_mtk_init(void)
{
+ register_syscore_ops(&xhci_mtk_syscore_ops);
xhci_init_driver(&xhci_mtk_hc_driver, &xhci_mtk_overrides);
return platform_driver_register(&mtk_xhci_driver);
}
@@ -774,6 +802,7 @@ module_init(xhci_mtk_init);
static void __exit xhci_mtk_exit(void)
{
platform_driver_unregister(&mtk_xhci_driver);
+ unregister_syscore_ops(&xhci_mtk_syscore_ops);
}
module_exit(xhci_mtk_exit);
--
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
Microsoft wireless usb mouse frequently fails to detect in ubuntu 15.10/16.04
Hello all, I am using ubuntu 16.04 (upgraded yesterday from 15.10) on Dell inspiron 15 3000 series (core i7). While using Microsoft wireless mouse, it fails to detect most of the time. The issue is not there when I use the same mouse in Windows / other linux distro / TV / PS4 etc. Here is the Kernel log for the failure. [ 74.186391] usb 1-1.3: new full-speed USB device number 7 using ehci-pci [ 74.258396] usb 1-1.3: device descriptor read/64, error -32 [ 74.434356] usb 1-1.3: device descriptor read/64, error -32 [ 74.610315] usb 1-1.3: new full-speed USB device number 8 using ehci-pci [ 74.682322] usb 1-1.3: device descriptor read/64, error -32 [ 74.858322] usb 1-1.3: device descriptor read/64, error -32 [ 75.034320] usb 1-1.3: new full-speed USB device number 9 using ehci-pci [ 75.446330] usb 1-1.3: device not accepting address 9, error -32 [ 75.518334] usb 1-1.3: new full-speed USB device number 10 using ehci-pci [ 75.926331] usb 1-1.3: device not accepting address 10, error -32 [ 75.926400] usb 1-1-port3: unable to enumerate USB device [ 93.835769] usb 1-1.3: new full-speed USB device number 11 using ehci-pci [ 93.908028] usb 1-1.3: device descriptor read/64, error -32 [ 94.084569] usb 1-1.3: device descriptor read/64, error -32 [ 94.261110] usb 1-1.3: new full-speed USB device number 12 using ehci-pci [ 94.37] usb 1-1.3: device descriptor read/64, error -32 [ 94.509893] usb 1-1.3: device descriptor read/64, error -32 [ 94.686342] usb 1-1.3: new full-speed USB device number 13 using ehci-pci [ 95.095548] usb 1-1.3: device not accepting address 13, error -32 [ 95.167686] usb 1-1.3: new full-speed USB device number 14 using ehci-pci [ 95.576740] usb 1-1.3: device not accepting address 14, error -32 [ 95.576848] usb 1-1-port3: unable to enumerate USB device - After multiple connect/disconnect of the wireless dongle, it finally detects. Here is the detection log. -- [ 110.221269] usb 1-1.3: new full-speed USB device number 15 using ehci-pci [ 110.319427] usb 1-1.3: New USB device found, idVendor=045e, idProduct=0745 [ 110.319431] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 110.319433] usb 1-1.3: Product: Microsoft® 2.4GHz Transceiver v8.0 [ 110.319435] usb 1-1.3: Manufacturer: Microsoft [ 110.361146] usbcore: registered new interface driver usbhid [ 110.361151] usbhid: USB HID core driver [ 110.380274] input: Microsoft Microsoft® 2.4GHz Transceiver v8.0 as /devices/pci:00/:00:1d.0/usb1/1-1/1-1.3/1-1.3:1.0/0003:045E:0745.0002/input/input14 [ 110.433886] hid-generic 0003:045E:0745.0002: input,hidraw1: USB HID v1.11 Keyboard [Microsoft Microsoft® 2.4GHz Transceiver v8.0] on usb-:00:1d.0-1.3/input0 [ 110.434274] input: Microsoft Microsoft® 2.4GHz Transceiver v8.0 as /devices/pci:00/:00:1d.0/usb1/1-1/1-1.3/1-1.3:1.1/0003:045E:0745.0003/input/input15 [ 110.489634] hid-generic 0003:045E:0745.0003: input,hidraw2: USB HID v1.11 Mouse [Microsoft Microsoft® 2.4GHz Transceiver v8.0] on usb-:00:1d.0-1.3/input1 [ 110.500335] input: Microsoft Microsoft® 2.4GHz Transceiver v8.0 as /devices/pci:00/:00:1d.0/usb1/1-1/1-1.3/1-1.3:1.2/0003:045E:0745.0004/input/input16 [ 110.553640] hid-generic 0003:045E:0745.0004: input,hiddev0,hidraw3: USB HID v1.11 Device [Microsoft Microsoft® 2.4GHz Transceiver v8.0] on usb-:00:1d.0-1.3/input2 - I am not sure of this weird behaviour. Is there some issue with ubuntu kernel for input device? or is there a problem with microsoft mouse driver? regards -Shekhar -- 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: 03f0:521d Hewlett-Packard
Hello, Greg KH writes: > What is the output of 'lsusb -v -d 03f0:521d' ? Bus 001 Device 007: ID 03f0:521d Hewlett-Packard Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 255 Vendor Specific Class bDeviceSubClass 2 bDeviceProtocol 1 bMaxPacketSize064 idVendor 0x03f0 Hewlett-Packard idProduct 0x521d bcdDevice0.01 iManufacturer 5 Hewlett-Packard iProduct4 HP hs3110 HSPA+ Mobile Broadband Device iSerial 0 bNumConfigurations 2 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 253 bNumInterfaces 5 bConfigurationValue 1 iConfiguration 2 configuration 0 bmAttributes 0xa0 (Bus Powered) Remote Wakeup MaxPower 500mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 2 bInterfaceProtocol 1 iInterface 0 ** UNRECOGNIZED: 05 24 00 10 01 ** UNRECOGNIZED: 04 24 02 03 ** UNRECOGNIZED: 05 24 01 00 00 ** UNRECOGNIZED: 05 24 06 00 00 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes3 Transfer TypeInterrupt Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 5 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 32 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 32 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber1 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 2 bInterfaceProtocol 2 iInterface 0 ** UNRECOGNIZED: 05 24 00 10 01 ** UNRECOGNIZED: 04 24 02 02 ** UNRECOGNIZED: 05 24 01 00 01 ** UNRECOGNIZED: 05 24 06 01 01 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 32 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 32 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber2 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 2 bInterfaceProtocol 3 iInterface 0 ** UNRECOGNIZED: 05 24 00 10 01 ** UNRECOGNIZED: 04 24 02 02 ** UNRECOGNIZED: 05 24 01 00 02 ** UNRECOGNIZED: 05 24 06 02 02 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x84 EP 4 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 32 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x03 EP 3 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacket
RE: [PATCH v6 09/12] usb: gadget: udc: adapt to OTG core
Hi,
...
>
> /**
> + * usb_gadget_start - start the usb gadget controller and connect to
> +bus
> + * @gadget: the gadget device to start
> + *
> + * This is external API for use by OTG core.
> + *
> + * Start the usb device controller and connect to bus (enable pull).
> + */
> +static int usb_gadget_start(struct usb_gadget *gadget) {
> + int ret;
> + struct usb_udc *udc = NULL;
> +
> + dev_dbg(&gadget->dev, "%s\n", __func__);
> + mutex_lock(&udc_lock);
> + list_for_each_entry(udc, &udc_list, list)
> + if (udc->gadget == gadget)
> + goto found;
> +
> + dev_err(gadget->dev.parent, "%s: gadget not registered.\n",
> + __func__);
> + mutex_unlock(&udc_lock);
> + return -EINVAL;
> +
> +found:
> + ret = usb_gadget_udc_start(udc);
> + if (ret)
> + dev_err(&udc->dev, "USB Device Controller didn't start: %d\n",
> + ret);
> + else
> + usb_udc_connect_control(udc);
For drd, it's fine, but for real otg, gadget connect should be done
by loc_conn() instead of gadget start.
> +
> + mutex_unlock(&udc_lock);
> +
> + return ret;
> +}
> +
> +/**
> + * usb_gadget_stop - disconnect from bus and stop the usb gadget
> + * @gadget: The gadget device we want to stop
> + *
> + * This is external API for use by OTG core.
> + *
> + * Disconnect from the bus (disable pull) and stop the
> + * gadget controller.
> + */
> +static int usb_gadget_stop(struct usb_gadget *gadget) {
> + struct usb_udc *udc = NULL;
> +
> + dev_dbg(&gadget->dev, "%s\n", __func__);
> + mutex_lock(&udc_lock);
> + list_for_each_entry(udc, &udc_list, list)
> + if (udc->gadget == gadget)
> + goto found;
> +
> + dev_err(gadget->dev.parent, "%s: gadget not registered.\n",
> + __func__);
> + mutex_unlock(&udc_lock);
> + return -EINVAL;
> +
> +found:
> + usb_gadget_disconnect(udc->gadget);
Likewise, gadget disconnect also should be done by loc_conn()
instead of gadget stop.
> + udc->driver->disconnect(udc->gadget);
> + usb_gadget_udc_stop(udc);
> + mutex_unlock(&udc_lock);
> +
> + return 0;
> +}
> +
Li Jun
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What are Shared HCD and Companion Controller(HCD?)
On Tue, Apr 19, 2016 at 10:20:33AM -0400, Alan Stern wrote: > On Tue, 19 Apr 2016, Felipe Balbi wrote: > > > Hi, > > > > Peter Chen writes: > > > Hi all, > > > > > > When I review the patch [1] for adding companion controller support for > > > OTG framework, I am puzzled several concepts, like shared hcd and > > > companion controller, companion hcd, companion port, would someone > > > please explain them? And why EHCI/OHCI do not use shared hcd, but > > > xHCI uses it? Thanks. > > > > xHCI is modeled as two separate buses (High-speed and Super-speed) which > > *share* the same IP block. In the case of EHCI/OHCI, there is a port > > being handed over to the a completely separate IP. OHCI is EHCI's > > companion for non-HS signalling. > > That's right. In more detail: > > Companion controller and companion hcd are the same thing. They exist > because EHCI can only handle high speed connections; it can't handle > full speed or low speed. When a USB-1.1 device is plugged into an EHCI > controller, the EHCI controller can't handle it and so the connection > is handed over to the companion controller, which is either OHCI or > UHCI. > I have one more question, if hcd codes takes primary hcd as USB2 and shared hcd as USB3, are there any problems if EHCI (or OHCI) as primary hcd and OHCI (EHCI) as shared hcd like [1], current hcd code seems to use hcd->shared_hcd at drivers/usb/core/port.c [1] http://www.spinics.net/lists/linux-usb/msg139344.html -- 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
