Re: High CPU load produced by USB (DW2)
On Tue, 13 Mar 2018 06:11:06 +, Minas Harutyunyan wrote: > Hi Paul, > > On 3/13/2018 2:39 AM, Paul Zimmerman wrote: > > On Mon, 12 Mar 2018 12:06:55 +, Minas Harutyunyan > > wrote: > > > >> Hi Paul, > >> > >> Nice to hear you again! Hope you are doing well. > > > > Thanks, same to you. > > > >> On 3/8/2018 1:51 PM, Paul Zimmerman wrote: > >>> On 03/06/2018 09:09 AM, Minas Harutyunyan wrote: > Driver debug log not required. > Based on lsusb output: to dwc2 port connected "Standard Microsystems > Corp. USB 2.0 Hub" to which connected your HS device "SanDisk Corp. > Ultra". Because of connected HUB, which have periodic endpoint > (Interrupt IN EP1) like all HUB's, dwc2 forced in Buffer DMA mode unmask > SOF interrupts. > >>> > >>> Hmm. It seems to me that for hubs, where the interrupt EP is only used to > >>> poll for connection changes (so the accuracy of the polling interval is > >>> not > >>> important), an OS timer could be used instead of enabling SOF interrupts. > >>> > >>> I have a Raspberry Pi 3 around here somewhere, maybe I'll dig it out and > >>> try playing around with this idea. No promises though! > >>> > >> > >> As I correctly understand, you suggest to mask SOF's and schedule in > >> dwc2 timer with expiration time 125us*interval. Based on timer > >> expiration get first urb from periodic queue and start transfer on > >> Interrupt IN EPn. In this case interrupt count will be decreased by > >> 'interval' times. But how you going to recognized inside dwc2 that this > >> Interrupt IN EPn is HUB endpoint or not? > > > > Yes, you understand correctly. But on second thought, we would need to treat > > *all* interrupt EPs this way, since things like mice and keyboards also have > > interrupt EPs. But I'm not sure if any device really needs highly accurate > > polling intervals on their interrupt EPs, so my idea may still work. > > > > In any case, I have my RPI3 set up and I can build a working kernel for it > > (sort of, but that's another story), so I will start experimenting with > > this. > > > > Idea is really good, but I'm not sure it's will work or no. See, if > interrupt IN transfers target frame is N. Due to timer can't be very > accurate it can will expire in N-1 or N+1 uframe and if we will start > transfer in that uframes, then not clear how will behave device if IN > token will received in not exact expecting uframe. > BTW, your suggestion only for Interrupt IN or OUT also? The USB spec says the device "can depend only on the fact that the host will ensure that the time duration between two transaction attempts with the endpoint will be no longer than the desired period. Note that errors on the bus can prevent an interrupt transaction from being successfully delivered over the bus and consequently exceed the desired period. Also, the endpoint is only polled when the software client has an IRP for an interrupt transfer pending". So the device can't be that picky about the exact uframe the transfer is requested. I will do both Interrupt IN and OUT. And if an Interrupt EP with a very short interval is submitted, or an Isoch EP, then I will revert to unmasking the SOF interrupt and handling all periodic EPs the old way. Yeah, I'm not sure this will work either, but I'll give it a try. -- Paul -- 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: Leak of queue heads in DWC2 driver?
Hi Paul, On 3/13/2018 6:26 AM, Paul Zimmerman wrote: > Hi Minas, > > While looking at the QH queuing in the DWC2 driver, I think I've found > some places where the QH struct may not be freed. Normally, the sequence is: > > dwc2_hcd_qh_unlink(); > < other stuff > > dwc2_hcd_qh_free(); > > or else: > > dwc2_hcd_qh_unlink(); > < other stuff > > < link the QH to some other list > > > For non-periodic EPs, dwc2_hcd_qh_unlink() does > list_del_init(&qh->qh_list_entry), or for periodic EPs it calls > dwc2_deschedule_periodic() which in turn does the list_del_init(). > This means the QH is removed from whatever list it was on. > > So after the call to dwc2_hcd_qh_unlink(), the QH either needs to be freed > by calling dwc2_hcd_qh_free(), or it needs to be re-linked to another list, > otherwise the QH would be "lost" and could never be freed. > > The places where I think a problem can happen are in dwc2_hcd_qh_deactivate(), > dwc_hcd_urb_dequeue(), and dwc_hcd_complete_xfer_ddma(). In most if not all > of these places, interrupts are disabled, which means that dwc2_hcd_qh_free() > cannot be called, since it can sleep. So maybe the freeing was omitted because > it was hard to do in these places? > > What do you think, am I reading the code correctly and this could be a real > problem, or am I crazy? :) > Thank you for your input. I'm planing to review all host code in 1 or 2 months. Yes, in host code there are lot of stuff should be updated/corrected. Currently we want to complete all fixes/improvements on gadget side. We still have lot of prepared patches in our queue which need to be included in mainline Kernel. BTW, besides fixes/improvements there are few new features like Service Interval support on device side which currently under development and debugging. Thanks, Minas -- 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 3/4] usb: host: xhci-plat: revert "usb: host: xhci-plat: enable clk in resume timing"
Hi Greg,
> From: Greg KH, Sent: Saturday, March 10, 2018 2:08 AM
>
> On Fri, Mar 09, 2018 at 01:48:37AM +, Yoshihiro Shimoda wrote:
> > Hi Greg,
> >
> > > From: Greg KH, Sent: Friday, March 9, 2018 2:06 AM
> > >
> > > On Thu, Mar 08, 2018 at 05:17:16PM +0200, Mathias Nyman wrote:
> > > > From: Yoshihiro Shimoda
< snip >
> > > > Fixes: 835e4241e714 ("usb: host: xhci-plat: enable clk in resume
> > > > timing")
> > > > Signed-off-by: Yoshihiro Shimoda
> > > > Signed-off-by: Mathias Nyman
> > >
> > > This really should go to 4.15-stable, right? I'll go add the tag if
> > > needed, but want your confirmation first.
> >
> > Since 4.15 is not longterm release, I think Renesas will not consume 4.15.
>
> But it fixes a bug in 4.15, so someone might care :)
:)
> > So, I don't think this really should go to 4.15-stable.
> > In such case, should I not add Fixes: tag? If not, I'll be careful in the
> > future.
>
> No, the fixes tag was great. I'll just leave it as-is.
I got it. Thank you for your comment!
Best regards,
Yoshihiro Shimoda
> 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: High CPU load produced by USB (DW2)
Hi Paul, On 3/13/2018 2:39 AM, Paul Zimmerman wrote: > On Mon, 12 Mar 2018 12:06:55 +, Minas Harutyunyan > wrote: > >> Hi Paul, >> >> Nice to hear you again! Hope you are doing well. > > Thanks, same to you. > >> On 3/8/2018 1:51 PM, Paul Zimmerman wrote: >>> On 03/06/2018 09:09 AM, Minas Harutyunyan wrote: Driver debug log not required. Based on lsusb output: to dwc2 port connected "Standard Microsystems Corp. USB 2.0 Hub" to which connected your HS device "SanDisk Corp. Ultra". Because of connected HUB, which have periodic endpoint (Interrupt IN EP1) like all HUB's, dwc2 forced in Buffer DMA mode unmask SOF interrupts. >>> >>> Hmm. It seems to me that for hubs, where the interrupt EP is only used to >>> poll for connection changes (so the accuracy of the polling interval is not >>> important), an OS timer could be used instead of enabling SOF interrupts. >>> >>> I have a Raspberry Pi 3 around here somewhere, maybe I'll dig it out and >>> try playing around with this idea. No promises though! >>> >> >> As I correctly understand, you suggest to mask SOF's and schedule in >> dwc2 timer with expiration time 125us*interval. Based on timer >> expiration get first urb from periodic queue and start transfer on >> Interrupt IN EPn. In this case interrupt count will be decreased by >> 'interval' times. But how you going to recognized inside dwc2 that this >> Interrupt IN EPn is HUB endpoint or not? > > Yes, you understand correctly. But on second thought, we would need to treat > *all* interrupt EPs this way, since things like mice and keyboards also have > interrupt EPs. But I'm not sure if any device really needs highly accurate > polling intervals on their interrupt EPs, so my idea may still work. > > In any case, I have my RPI3 set up and I can build a working kernel for it > (sort of, but that's another story), so I will start experimenting with this. > Idea is really good, but I'm not sure it's will work or no. See, if interrupt IN transfers target frame is N. Due to timer can't be very accurate it can will expire in N-1 or N+1 uframe and if we will start transfer in that uframes, then not clear how will behave device if IN token will received in not exact expecting uframe. BTW, your suggestion only for Interrupt IN or OUT also? Thanks, Minas -- 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
Hello
Good day dear, i hope this mail meets you well? I know this may seem inappropriate so i ask for your forgiveness but i wish to get to know you better, if I may be so bold. I consider myself an easy-going man, adventurous, honest and fun loving person but I am currently looking for a relationship in which I will feel loved. I promise to answer any question that you may want to ask me...all i need is just your attention and the chance to know you more. Please tell me more about yourself, if you do not mind. Hope to hear back from you soon. Bauer -- 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
Leak of queue heads in DWC2 driver?
Hi Minas, While looking at the QH queuing in the DWC2 driver, I think I've found some places where the QH struct may not be freed. Normally, the sequence is: dwc2_hcd_qh_unlink(); < other stuff > dwc2_hcd_qh_free(); or else: dwc2_hcd_qh_unlink(); < other stuff > < link the QH to some other list > For non-periodic EPs, dwc2_hcd_qh_unlink() does list_del_init(&qh->qh_list_entry), or for periodic EPs it calls dwc2_deschedule_periodic() which in turn does the list_del_init(). This means the QH is removed from whatever list it was on. So after the call to dwc2_hcd_qh_unlink(), the QH either needs to be freed by calling dwc2_hcd_qh_free(), or it needs to be re-linked to another list, otherwise the QH would be "lost" and could never be freed. The places where I think a problem can happen are in dwc2_hcd_qh_deactivate(), dwc_hcd_urb_dequeue(), and dwc_hcd_complete_xfer_ddma(). In most if not all of these places, interrupts are disabled, which means that dwc2_hcd_qh_free() cannot be called, since it can sleep. So maybe the freeing was omitted because it was hard to do in these places? What do you think, am I reading the code correctly and this could be a real problem, or am I crazy? :) -- Paul -- 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 v4 01/15] usb: dwc3: Add SoftReset PHY synchonization delay
Hi Felipe, On 3/12/2018 3:24 AM, Felipe Balbi wrote: > Thinh Nguyen writes: > >> From DWC_usb31 programming guide section 1.3.2, once DWC3_DCTL_CSFTRST >> bit is cleared, we must wait at least 50ms before accessing the PHY >> domain (synchronization delay). >> >> Signed-off-by: Thinh Nguyen > > checking file drivers/usb/dwc3/core.c > Hunk #1 FAILED at 228. > 1 out of 1 hunk FAILED > I don't see conflict when applying this patch series to your next branch. The conflict is maybe from its previous version currently on your 'next' and 'testing/next' branch. BR, Thinh -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH] usb: typec: tcpm: match source fixed pdo with sink variable pdo
This patch tries to fix the problem describled on revert patch commit[1],
suppose any supported voltage ranges of sink should be describled by
variable pdo, so instead of revert the patch of only comparing source and
sink pdo to select one source pdo, this patch adds the match between source
fixed pdo and sink variable pdo.
[1] https://www.spinics.net/lists/linux-usb/msg166366.html
CC: Hans de Goede
CC: Guenter Roeck
CC: Heikki Krogerus
CC: Adam Thomson
CC: Badhri Jagan Sridharan
Signed-off-by: Li Jun
---
drivers/usb/typec/tcpm.c | 31 +++
1 file changed, 31 insertions(+)
diff --git a/drivers/usb/typec/tcpm.c b/drivers/usb/typec/tcpm.c
index ef3a60d..8a74a43 100644
--- a/drivers/usb/typec/tcpm.c
+++ b/drivers/usb/typec/tcpm.c
@@ -1815,6 +1815,37 @@ static int tcpm_pd_select_pdo(struct tcpm_port *port,
int *sink_pdo,
break;
}
}
+
+ /*
+* If the source pdo has the same voltage with one
+* fixed pdo, no need check variable pdo for it.
+*/
+ if (j < port->nr_fixed)
+ continue;
+
+ for (j = port->nr_fixed +
+port->nr_batt;
+j < port->nr_fixed +
+port->nr_batt +
+port->nr_var;
+j++) {
+ if (pdo_fixed_voltage(pdo) >=
+pdo_min_voltage(port->snk_pdo[j]) &&
+pdo_fixed_voltage(pdo) <=
+pdo_max_voltage(port->snk_pdo[j])) {
+ ma = min_current(pdo, port->snk_pdo[j]);
+ mv = pdo_fixed_voltage(pdo);
+ mw = ma * mv / 1000;
+ if (mw > max_mw ||
+ (mw == max_mw && mv > max_mv)) {
+ ret = 0;
+ *src_pdo = i;
+ *sink_pdo = j;
+ max_mw = mw;
+ max_mv = mv;
+ }
+ }
+ }
} else if (type == PDO_TYPE_BATT) {
for (j = port->nr_fixed;
j < port->nr_fixed +
--
2.7.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: High CPU load produced by USB (DW2)
On Mon, 12 Mar 2018 12:06:55 +, Minas Harutyunyan wrote: > Hi Paul, > > Nice to hear you again! Hope you are doing well. Thanks, same to you. > On 3/8/2018 1:51 PM, Paul Zimmerman wrote: > > On 03/06/2018 09:09 AM, Minas Harutyunyan wrote: > >> Driver debug log not required. > >> Based on lsusb output: to dwc2 port connected "Standard Microsystems > >> Corp. USB 2.0 Hub" to which connected your HS device "SanDisk Corp. > >> Ultra". Because of connected HUB, which have periodic endpoint > >> (Interrupt IN EP1) like all HUB's, dwc2 forced in Buffer DMA mode unmask > >> SOF interrupts. > > > > Hmm. It seems to me that for hubs, where the interrupt EP is only used to > > poll for connection changes (so the accuracy of the polling interval is not > > important), an OS timer could be used instead of enabling SOF interrupts. > > > > I have a Raspberry Pi 3 around here somewhere, maybe I'll dig it out and > > try playing around with this idea. No promises though! > > > > As I correctly understand, you suggest to mask SOF's and schedule in > dwc2 timer with expiration time 125us*interval. Based on timer > expiration get first urb from periodic queue and start transfer on > Interrupt IN EPn. In this case interrupt count will be decreased by > 'interval' times. But how you going to recognized inside dwc2 that this > Interrupt IN EPn is HUB endpoint or not? Yes, you understand correctly. But on second thought, we would need to treat *all* interrupt EPs this way, since things like mice and keyboards also have interrupt EPs. But I'm not sure if any device really needs highly accurate polling intervals on their interrupt EPs, so my idea may still work. In any case, I have my RPI3 set up and I can build a working kernel for it (sort of, but that's another story), so I will start experimenting with this. -- Paul -- 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 v4 2/2] usb/gadget: Add driver for Aspeed SoC virtual hub
On Fri, 2018-03-09 at 11:20 +0200, Felipe Balbi wrote:
>
> > diff --git a/drivers/usb/gadget/udc/aspeed-vhub/core.c
> > b/drivers/usb/gadget/udc/aspeed-vhub/core.c
> > new file mode 100644
> > index ..31ed2b6e241b
> > --- /dev/null
> > +++ b/drivers/usb/gadget/udc/aspeed-vhub/core.c
> > @@ -0,0 +1,429 @@
>
> missing SPDX license identifier (all files)
Ah yup, the driver predates me knowing about them, I'll fix.
> > +static bool force_usb1 = false;
> > +static bool no_dma_desc = false;
> > +
> > +module_param_named(force_usb1, force_usb1, bool, 0644);
> > +MODULE_PARM_DESC(force_usb1, "Set to true to force to USB1 speed");
> > +module_param_named(no_dma_desc, no_dma_desc, bool, 0644);
> > +MODULE_PARM_DESC(no_dma_desc, "Set to true to disable use of DMA
> > descriptors");
>
> module parameters? Sorry, but no.
Why ? Any suggestion then for the two above ? They are mostly meant as
diagnostic/debug features if something doesn't work (for example, the
board has some sub-standard wiring making USB2 unreliable, or a driver
bug with DMA descriptors).
I can just take them out completely but it feels like module parameters
are the right thing to do in that specific case.
> > +void ast_vhub_done(struct ast_vhub_ep *ep, struct ast_vhub_req *req,
> > + int status)
> > +{
> > + bool internal = req->internal;
> > +
> > + EPVDBG(ep, "completing request @%p, status %d\n", req, status);
> > +
> > + list_del_init(&req->queue);
> > +
> > + if (req->req.status == -EINPROGRESS)
> > + req->req.status = status;
> > +
> > + if (req->req.dma) {
> > + if (!WARN_ON(!ep->dev))
> > + usb_gadget_unmap_request(&ep->dev->gadget,
> > +&req->req, ep->epn.is_in);
> > + req->req.dma = 0;
> > + }
> > +
> > + /*
> > +* If this isn't an internal EP0 request, call the core
> > +* to call the gadget completion.
> > +*/
> > + if (!internal) {
> > + spin_unlock(&ep->vhub->lock);
> > + usb_gadget_giveback_request(&ep->ep, &req->req);
> > + spin_lock(&ep->vhub->lock);
> > + }
> > +}
> > +
> > +void ast_vhub_nuke(struct ast_vhub_ep *ep, int status)
> > +{
> > + struct ast_vhub_req *req;
> > +
> > + EPDBG(ep, "Nuking\n");
> > +
> > + /* terminate any request in the queue */
> > + if (list_empty(&ep->queue))
> > + return;
>
> unnecessary test.
Right.
>
> > +
> > + /* Beware, lock will be dropped & req-acquired by done() */
> > + while (!list_empty(&ep->queue)) {
> > + req = list_first_entry(&ep->queue, struct ast_vhub_req, queue);
>
> list_for_each_entry_safe() ??
No, list_for_each_entry_safe is about the current entry being removed
by the loop. In this case, we drop the lock in done(), so any entry
including the next one could go away concurrently. This is why this
construct is necessary.
> > + ast_vhub_done(ep, req, status);
> > + }
> > +}
> > +
> > +struct usb_request *ast_vhub_alloc_request(struct usb_ep *u_ep,
> > + gfp_t gfp_flags)
> > +{
> > + struct ast_vhub_req *req;
> > +
> > + req = kzalloc(sizeof(*req), gfp_flags);
> > + if (!req)
> > + return NULL;
>
> Don't you wanna keep a reference to the endpoint that owns $this
> request?
What for ? I haven't had needed one so far...
> > + INIT_LIST_HEAD(&req->queue);
>
> unnecessary list initialization
Ah right, I wanted to poison it actually but just leaving it NULL is
probably fine.
> > + return &req->req;
> > +}
> > +
> > +void ast_vhub_free_request(struct usb_ep *u_ep, struct usb_request *u_req)
> > +{
> > + struct ast_vhub_req *req = to_ast_req(u_req);
> > +
> > + kfree(req);
> > +}
> > +
> > +static irqreturn_t ast_vhub_irq (int irq, void *data)
>
> ^
> unnecessary space
Ok.
> > +{
> > + struct ast_vhub *vhub = data;
> > + irqreturn_t iret = IRQ_NONE;
> > + u32 istat;
> > +
> > + /* Stale interrupt while tearing down */
> > + if (!vhub->ep0_bufs)
> > + return IRQ_NONE;
> > +
> > + spin_lock(&vhub->lock);
>
> this is your hardirq handler right? Do you really need this lock here?
Yup, pretty much everything it calls needs to be protected, it also
protects vs a concurrent remove.
> > +
> > + /* Read and ACK interrupts */
> > + istat = readl(vhub->regs + AST_VHUB_ISR);
> > + if (!istat)
> > + goto bail;
> > + writel(istat, vhub->regs + AST_VHUB_ISR);
> > + iret = IRQ_HANDLED;
> > +
> > + UDCVDBG(vhub, "irq status=%08x, ep_acks=%08x ep_nacks=%08x\n",
> > + istat,
> > + readl(vhub->regs + AST_VHUB_EP_ACK_ISR),
> > + readl(vhub->regs + AST_VHUB_EP_NACK_ISR));
> > +
> > + /* Handle generic EPs first */
> > + if (istat & VHUB_IRQ_EP_POOL_ACK_STALL) {
> > + u32 i, ep_acks = readl(vhub->regs + AST_VHUB_EP_ACK_ISR);
> > + writel(ep_acks, vhub-
Re: [PATCH v2] usb: musb: Fix external abort in musb_remove on omap2430
Hi Bin, On 09/03/18 15:11, Bin Liu wrote: > Hi, > > On Thu, Mar 08, 2018 at 11:19:48PM +0100, Merlijn Wajer wrote: >> This fixes an oops on unbind / module unload (on the musb omap2430 >> platform). >> >> musb_remove function now calls musb_platform_exit before disabling >> runtime pm. >> >> Signed-off-by: Merlijn Wajer > > Applied. Thanks. Thank you. Is there any chance that this patch and the vbus patch could end up in the 4.16-rc series? I was waiting for another rc to see if the vbus patch would land, but it didn't land with 4.16-rc5. Cheers, Merlijn signature.asc Description: OpenPGP digital signature
Re: [PATCH v7 00/12] USB Type-C device-connection, mux and switch support
Hi,
On 12-03-18 15:34, Heikki Krogerus wrote:
Hi,
This is version 7 of Hans' and my series introducing support for USB muxes and
generic device-connections. The api naming for device-connections is now made
according to proposal from Greg, connection.h is dropped and the prototypes are
now in device.h. kbuild test robot also found stylistic
problems from patches 9/12 and 10/12 which were fixed. The patch 4/12 ("usb:
typec: Separate the definitions for data and power roles") was added to the
series.
Thanks.
I've given this new series a quick test run and it works for me :)
Regards,
Hans
Check the v6 from here:
https://lkml.org/lkml/2018/3/2/340
Here is the cover-letter of v6:
Hi All,
Here is version 6 of Heikki's and my USB Type-C device-connection, mux and
switch support series. Versions 2 - 5 bring various small code and style
fixes based on review (no major changes). Version 6 is rebased on top of
the latest usb-next and brings one small but important code fix in
the devcon code.
Here is the original cover-letter of v1:
Some devices with an USB Type-C connector have a bunch of muxes
behind that connector which need to be controlled by the kernel (rather
then having them controlled by firmware as on most devices).
Quite a while back I submitted a patch-series to tie together these muxes
and the Type-C Port Manager (tcpm) code, using the then new drivers/mux
framework. But the way I used the mux framework went against what it was
designed for, so in the end that series got nowhere.
Heikki Krogerus from Intel, who maintains the USB TYPEC subsystem, has
recently been working on solving the same problem for some boards he is
doing hardware-enablement for.
Heikki has come up with a number of infrastructure patches for this.
The first one is a new device-connection framework. This solves the
problem of describing non bus device-links on x86 in what in my experience
with this problematic area is a really nice simple, clean and *generic*
way. This could for example in the near future also replace the custom
lookup code in the pwm subsys and the custom pwm_add_table() /
pwm_remove_table() functions.
The other 3 patches add a framework for the different type of Type-C /
USB "muxes".
Heikki and I have gone through a number of iterations of these patches
together and we believe these are now ready for merging. Since merging
infrastructure patches without users is not done and Heikki's own use-case
for these is not yet ready for merging, the rest of this series consists
of patches by me to make the Type-C connector found on some Cherry Trail
devices (finally) be able to actually work as an USB port and not just
a charge port.
The last patch uses the new usb-role-switch framework to also do proper
devcie / host switching on CHT devices with a USB micro AB connector.
This is also a big feature for CHT users, because before this they had
to do a reboot to get an OTG-host cable recognized (on some devices).
Part of this series is an usb-role-switch driver for the role-switch
found inside the xhci controller on e.g. CHT devices, this is currently
implemented as the generic xhci controller instantiating a platform
child-device for this, since this really is a separate chunk of HW
which happens to sit in the XHCI mmio space. This approach may not be
universally liked, given that in this new series the role-switch driver
is much smaller and does not have any external deps anymore we could
just integrate it into the xhci code if that is preferred.
About merging this series (once everything is reviewed, etc.), there are
quite some interdependencies in it esp. a lot of the patches depend on
the first patch. Luckily patches 1-10 all apply to subsystems which are
maintained by Greg (most to the USB subsys). Which just leaves patches
11 and 12 once 1-10 are merged. Greg, can you create an immutable branch
for the platform/x86 and extcon maintainers to merge once this is done?
Regards,
Hans
Hans de Goede (7):
usb: typec: tcpm: Set USB role switch to device mode when configured
as such
usb: typec: tcpm: Use new Type-C switch/mux and usb-role-switch
functions
xhci: Add Intel extended cap / otg phy mux handling
usb: roles: Add Intel xHCI USB role switch driver
usb: typec: driver for Pericom PI3USB30532 Type-C cross switch
platform/x86: intel_cht_int33fe: Add device connections for the Type-C
port
extcon: axp288: Set USB role where necessary
Heikki Krogerus (4):
drivers: base: Unified device connection lookup
usb: typec: API for controlling USB Type-C Multiplexers
usb: common: Small class for USB role switches
usb: typec: Separate the definitions for data and power roles
Mathias Nyman (1):
xhci: Add option to get next extended capability in list by passing id
= 0
Documentation/ABI/testing/sysfs-class-usb_role | 21 ++
Documentation/driver-api/device_connection.rst | 43
Documentation/driver-api/usb/typec.rst | 73 +-
MAI
help needed: dvb-usb: recv bulk message failed: -110 AND dw2102: i2c transfer failed
Hallo I get this with kernel 4.15.8 and 4.16-rc5 ... [ 166.277588] dvb-usb: Terratec Cinergy S2 USB BOX successfully deinitialized and disconnected. [ 168.406828] usb 1-1: new high-speed USB device number 6 using xhci_hcd [ 168.534421] dw2102: su3000_identify_state [ 168.534424] dvb-usb: found a 'Terratec Cinergy S2 USB BOX' in warm state. [ 168.534433] dw2102: su3000_power_ctrl: 1, initialized 0 [ 168.534642] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. [ 168.534708] dvbdev: DVB: registering new adapter (Terratec Cinergy S2 USB BOX) [ 168.538862] dvb-usb: MAC address: bc:ea:2b:46:13:a5 [ 168.849764] m88ds3103 5-0068: Unknown device. Chip_id=52 [ 168.849816] dvb-usb: no frontend was attached by 'Terratec Cinergy S2 USB BOX' [ 168.849945] Registered IR keymap rc-tt-1500 [ 168.850002] rc rc0: Terratec Cinergy S2 USB BOX as /devices/pci:00/:00:14.0/usb1/1-1/rc/rc0 [ 168.850084] input: Terratec Cinergy S2 USB BOX as /devices/pci:00/:00:14.0/usb1/1-1/rc/rc0/input20 [ 168.850287] dvb-usb: schedule remote query interval to 250 msecs. [ 168.850291] dw2102: su3000_power_ctrl: 0, initialized 1 [ 168.850293] dvb-usb: Terratec Cinergy S2 USB BOX successfully initialized and connected. [ 171.141939] dvb-usb: recv bulk message failed: -110 [ 171.141949] dw2102: i2c transfer failed. more to read: https://forum.libreelec.tv/thread/11784-does-this-dvb-s2-tuner-work/?pageNo=4 -- Greeting Ronald -- 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 11/11] usb: dwc2: Enable LPM
On 03/09/2018 12:06 AM, Felipe Balbi wrote: Hi, Grigor Tovmasyan writes: From: John Youn Set 'lpm_capable' flag in the gadget structure so indicating that LPM is supported. Signed-off-by: Sevak Arakelyan Signed-off-by: Grigor Tovmasyan Missing John's Signed-off-by. What gives? I'll drop this from my queue for now. Sorry, it must have gotten dropped somehow. Do you need me to resend? If not please add: Signed-off-by: John Youn John -- 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: [Proxmox] usb 1-1.2: clear tt 1 (0050) error -7
On Mon, 12 Mar 2018, Cristian wrote: > Hello, > > I'm working with Proxmox... > > dmesg: > [ 202.138960] usb 1-1.2: clear tt 1 (0050) error -71 > [ 202.146341] usb 1-1.2-port4: cannot reset (err = -71) > [ 202.150578] usb 1-1.2-port4: cannot reset (err = -71) > [ 202.154828] usb 1-1.2-port4: cannot reset (err = -71) > [ 202.159100] usb 1-1.2-port4: cannot reset (err = -71) > [ 202.163328] usb 1-1.2-port4: cannot reset (err = -71) > [ 202.163361] usb 1-1.2-port4: Cannot enable. Maybe the USB cable is bad? > [ 202.167578] usb 1-1.2-port4: cannot disable (err = -71) > [ 202.171828] usb 1-1.2-port4: cannot reset (err = -71) > [ 202.176077] usb 1-1.2-port4: cannot reset (err = -71) > [ 202.180326] usb 1-1.2-port4: cannot reset (err = -71) > [ 202.184578] usb 1-1.2-port4: cannot reset (err = -71) > [ 202.188828] usb 1-1.2-port4: cannot reset (err = -71) > [ 202.188860] usb 1-1.2-port4: Cannot enable. Maybe the USB cable is bad? > [ 202.193087] usb 1-1.2-port4: cannot disable (err = -71) > [ 202.197329] usb 1-1.2-port4: cannot reset (err = -71) > [ 202.201587] usb 1-1.2-port4: cannot reset (err = -71) > [ 202.205830] usb 1-1.2-port4: cannot reset (err = -71) Those messages are quite normal. They appeared when you unplugged the hub that the Logitech mouse and Chicony keyboard were plugged into. When that happened the computer was no longer able to communicate with the hub, the mouse, or the keyboard -- that's why the errors were logged. The computer couldn't tell why the errors occurred until it received the notification that the hub had been unplugged, which arrived about 0.07 seconds later. Alan Stern > [ 202.209077] usb 1-1.2: USB disconnect, device number 3 > [ 202.209080] usb 1-1.2.3: USB disconnect, device number 8 > [ 202.210079] usb 1-1.2-port4: cannot reset (err = -71) > [ 202.254480] usb 1-1.2.4: USB disconnect, device number 5 > [ 202.370465] input: Chicony HP Elite USB Keyboard as > /devices/pci:00/:00:1a.0/usb1/1-1/1-1.2/1-1.2.4/1-1.2.4:1.0/input/input13 > [ 202.406336] input: failed to attach handler kbd to device input13, error: > -5 > [ 202.422338] sysrq: Failed to open input device, error -5 > [ 202.442336] input: failed to attach handler sysrq to device > input13, error: -5 > [ 202.482335] input: failed to attach handler leds to device input13, error: > -5 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] net: drivers/net: Remove unnecessary skb_copy_expand OOM messages
skb_copy_expand without __GFP_NOWARN already does a dump_stack
on OOM so these messages are redundant.
Signed-off-by: Joe Perches
---
drivers/net/ethernet/qualcomm/qca_spi.c | 1 -
drivers/net/usb/lg-vl600.c | 6 +-
drivers/net/wimax/i2400m/usb-rx.c | 3 ---
drivers/net/wireless/ti/wl1251/tx.c | 4 +---
drivers/usb/gadget/function/f_eem.c | 1 -
net/mac80211/rx.c | 5 +
net/netfilter/nfnetlink_queue.c | 5 +
7 files changed, 4 insertions(+), 21 deletions(-)
diff --git a/drivers/net/ethernet/qualcomm/qca_spi.c
b/drivers/net/ethernet/qualcomm/qca_spi.c
index 9c236298fe21..5803cd6db406 100644
--- a/drivers/net/ethernet/qualcomm/qca_spi.c
+++ b/drivers/net/ethernet/qualcomm/qca_spi.c
@@ -705,7 +705,6 @@ qcaspi_netdev_xmit(struct sk_buff *skb, struct net_device
*dev)
tskb = skb_copy_expand(skb, QCAFRM_HEADER_LEN,
QCAFRM_FOOTER_LEN + pad_len, GFP_ATOMIC);
if (!tskb) {
- netdev_dbg(qca->net_dev, "could not allocate
tx_buff\n");
qca->stats.out_of_mem++;
return NETDEV_TX_BUSY;
}
diff --git a/drivers/net/usb/lg-vl600.c b/drivers/net/usb/lg-vl600.c
index dbabd7ca5268..257916f172cd 100644
--- a/drivers/net/usb/lg-vl600.c
+++ b/drivers/net/usb/lg-vl600.c
@@ -157,12 +157,8 @@ static int vl600_rx_fixup(struct usbnet *dev, struct
sk_buff *skb)
s->current_rx_buf = skb_copy_expand(skb, 0,
le32_to_cpup(&frame->len), GFP_ATOMIC);
- if (!s->current_rx_buf) {
- netif_err(dev, ifup, dev->net, "Reserving %i bytes "
- "for packet assembly failed.\n",
- le32_to_cpup(&frame->len));
+ if (!s->current_rx_buf)
dev->net->stats.rx_errors++;
- }
return 0;
}
diff --git a/drivers/net/wimax/i2400m/usb-rx.c
b/drivers/net/wimax/i2400m/usb-rx.c
index b78ee676e102..5b64bda7d9e7 100644
--- a/drivers/net/wimax/i2400m/usb-rx.c
+++ b/drivers/net/wimax/i2400m/usb-rx.c
@@ -263,9 +263,6 @@ struct sk_buff *i2400mu_rx(struct i2400mu *i2400mu, struct
sk_buff *rx_skb)
new_skb = skb_copy_expand(rx_skb, 0, rx_size - rx_skb->len,
GFP_KERNEL);
if (new_skb == NULL) {
- if (printk_ratelimit())
- dev_err(dev, "RX: Can't reallocate skb to %d; "
- "RX dropped\n", rx_size);
kfree_skb(rx_skb);
rx_skb = NULL;
goto out; /* drop it...*/
diff --git a/drivers/net/wireless/ti/wl1251/tx.c
b/drivers/net/wireless/ti/wl1251/tx.c
index de2fa6705574..12ed14ebc307 100644
--- a/drivers/net/wireless/ti/wl1251/tx.c
+++ b/drivers/net/wireless/ti/wl1251/tx.c
@@ -221,10 +221,8 @@ static int wl1251_tx_send_packet(struct wl1251 *wl, struct
sk_buff *skb,
struct sk_buff *newskb = skb_copy_expand(skb, 0, 3,
GFP_KERNEL);
- if (unlikely(newskb == NULL)) {
- wl1251_error("Can't allocate skb!");
+ if (unlikely(newskb == NULL))
return -EINVAL;
- }
tx_hdr = (struct tx_double_buffer_desc *) newskb->data;
diff --git a/drivers/usb/gadget/function/f_eem.c
b/drivers/usb/gadget/function/f_eem.c
index 37557651b600..c13befa31110 100644
--- a/drivers/usb/gadget/function/f_eem.c
+++ b/drivers/usb/gadget/function/f_eem.c
@@ -507,7 +507,6 @@ static int eem_unwrap(struct gether *port,
0,
GFP_ATOMIC);
if (unlikely(!skb3)) {
- DBG(cdev, "unable to realign EEM packet\n");
dev_kfree_skb_any(skb2);
continue;
}
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index d01743234cf6..9c898a3688c6 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -2549,11 +2549,8 @@ ieee80211_rx_h_mesh_fwding(struct ieee80211_rx_data *rx)
fwd_skb = skb_copy_expand(skb, local->tx_headroom +
sdata->encrypt_headroom, 0, GFP_ATOMIC);
- if (!fwd_skb) {
- net_info_ratelimited("%s: failed to clone mesh frame\n",
- sdata->name);
+ if (!fwd_skb)
goto out;
- }
fwd_hdr = (struct ieee80211_hdr *) fwd_skb->data;
fwd_hdr->frame_control &= ~cpu_to_le16(IEEE80211_FCTL_RETRY);
diff --git a/net/netfilter/nfnetlink_q
[PATCH v7 01/12] drivers: base: Unified device connection lookup
Several frameworks - clk, gpio, phy, pmw, etc. - maintain lookup tables for describing connections and provide custom API for handling them. This introduces a single generic lookup table and API for the connections. The motivation for this commit is centralizing the connection lookup, but the goal is to ultimately extract the connection descriptions also from firmware by using the fwnode_graph_* functions and other mechanisms that are available. Reviewed-by: Hans de Goede Reviewed-by: Andy Shevchenko Signed-off-by: Heikki Krogerus --- Changes in v7: - API naming improvements suggested by Greg - Prototypes to device.h, also suggested by Greg - I removed the DEVCON() macro as it was not used yet and it needs to be rewritten Changes in v6: -Fix data and match arguments being swapped in __device_find_connection() call in device_find_connection() (as noticed by Jun Li) Changes in v5: -Add missing documentation for @list struct devcon member Changes in v4: -Add Andy's Reviewed-by Changes in v3: -Various spelling and gramar fixes in the docs pointed out by Randy Dunlap Changes in v2: -Add a (struct devcon) cast to the DEVCON() macro --- Documentation/driver-api/device_connection.rst | 43 drivers/base/Makefile | 3 +- drivers/base/devcon.c | 141 + include/linux/device.h | 22 4 files changed, 208 insertions(+), 1 deletion(-) create mode 100644 Documentation/driver-api/device_connection.rst create mode 100644 drivers/base/devcon.c diff --git a/Documentation/driver-api/device_connection.rst b/Documentation/driver-api/device_connection.rst new file mode 100644 index ..affbc5566ab0 --- /dev/null +++ b/Documentation/driver-api/device_connection.rst @@ -0,0 +1,43 @@ +== +Device connections +== + +Introduction + + +Devices often have connections to other devices that are outside of the direct +child/parent relationship. A serial or network communication controller, which +could be a PCI device, may need to be able to get a reference to its PHY +component, which could be attached for example to the I2C bus. Some device +drivers need to be able to control the clocks or the GPIOs for their devices, +and so on. + +Device connections are generic descriptions of any type of connection between +two separate devices. + +Device connections alone do not create a dependency between the two devices. +They are only descriptions which are not tied to either of the devices directly. +A dependency between the two devices exists only if one of the two endpoint +devices requests a reference to the other. The descriptions themselves can be +defined in firmware (not yet supported) or they can be built-in. + +Usage +- + +Device connections should exist before device ``->probe`` callback is called for +either endpoint device in the description. If the connections are defined in +firmware, this is not a problem. It should be considered if the connection +descriptions are "built-in", and need to be added separately. + +The connection description consists of the names of the two devices with the +connection, i.e. the endpoints, and unique identifier for the connection which +is needed if there are multiple connections between the two devices. + +After a description exists, the devices in it can request reference to the other +endpoint device, or they can request the description itself. + +API +--- + +.. kernel-doc:: drivers/base/devcon.c + : functions: device_connection_find_match device_connection_find device_connection_add device_connection_remove diff --git a/drivers/base/Makefile b/drivers/base/Makefile index e32a52490051..12a7f64d35a9 100644 --- a/drivers/base/Makefile +++ b/drivers/base/Makefile @@ -5,7 +5,8 @@ obj-y := component.o core.o bus.o dd.o syscore.o \ driver.o class.o platform.o \ cpu.o firmware.o init.o map.o devres.o \ attribute_container.o transport_class.o \ - topology.o container.o property.o cacheinfo.o + topology.o container.o property.o cacheinfo.o \ + devcon.o obj-$(CONFIG_DEVTMPFS) += devtmpfs.o obj-$(CONFIG_DMA_CMA) += dma-contiguous.o obj-y += power/ diff --git a/drivers/base/devcon.c b/drivers/base/devcon.c new file mode 100644 index ..e783c2c2ed1a --- /dev/null +++ b/drivers/base/devcon.c @@ -0,0 +1,141 @@ +// SPDX-License-Identifier: GPL-2.0 +/** + * Device connections + * + * Copyright (C) 2018 Intel Corporation + * Author: Heikki Krogerus + */ + +#include + +static DEFINE_MUTEX(devcon_lock); +static LIST_HEAD(devcon_list); + +/** + * device_connection_find_match - Find physical connection to a device + * @dev: Device with the connection + * @con_id: Identifier for the connection + * @data: Data for the match f
[PATCH v7 03/12] usb: common: Small class for USB role switches
USB role switch is a device that can be used to choose the
data role for USB connector. With dual-role capable USB
controllers, the controller itself will be the switch, but
on some platforms the USB host and device controllers are
separate IPs and there is a mux between them and the
connector. On those platforms the mux driver will need to
register the switch.
With USB Type-C connectors, the host-to-device relationship
is negotiated over the Configuration Channel (CC). That
means the USB Type-C drivers need to be in control of the
role switch. The class provides a simple API for the USB
Type-C drivers for the control.
For other types of USB connectors (mainly microAB) the class
provides user space control via sysfs attribute file that
can be used to request role swapping from the switch.
Reviewed-by: Hans de Goede
Reviewed-by: Andy Shevchenko
Signed-off-by: Heikki Krogerus
---
Changes in v4:
-Consistently use IS_ERR_OR_NULL where applicable
-Add Andy's Reviewed-by
Changes in v2:
-Minor style fixes from review of v1
---
Documentation/ABI/testing/sysfs-class-usb_role | 21 ++
drivers/usb/Kconfig| 3 +
drivers/usb/common/Makefile| 1 +
drivers/usb/common/roles.c | 305 +
include/linux/usb/role.h | 53 +
5 files changed, 383 insertions(+)
create mode 100644 Documentation/ABI/testing/sysfs-class-usb_role
create mode 100644 drivers/usb/common/roles.c
create mode 100644 include/linux/usb/role.h
diff --git a/Documentation/ABI/testing/sysfs-class-usb_role
b/Documentation/ABI/testing/sysfs-class-usb_role
new file mode 100644
index ..3b810a425a52
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-usb_role
@@ -0,0 +1,21 @@
+What: /sys/class/usb_role/
+Date: Jan 2018
+Contact: Heikki Krogerus
+Description:
+ Place in sysfs for USB Role Switches. USB Role Switch is a
+ device that can select the data role (host or device) for USB
+ port.
+
+What: /sys/class/usb_role//role
+Date: Jan 2018
+Contact: Heikki Krogerus
+Description:
+ The current role of the switch. This attribute can be used for
+ requesting role swapping with non-USB Type-C ports. With USB
+ Type-C ports, the ABI defined for USB Type-C connector class
+ must be used.
+
+ Valid values:
+ - none
+ - host
+ - device
diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig
index 148f3ee70286..f278958e04ca 100644
--- a/drivers/usb/Kconfig
+++ b/drivers/usb/Kconfig
@@ -203,4 +203,7 @@ config USB_ULPI_BUS
To compile this driver as a module, choose M here: the module will
be called ulpi.
+config USB_ROLE_SWITCH
+ tristate
+
endif # USB_SUPPORT
diff --git a/drivers/usb/common/Makefile b/drivers/usb/common/Makefile
index 0a7c45e85481..fb4d5ef4165c 100644
--- a/drivers/usb/common/Makefile
+++ b/drivers/usb/common/Makefile
@@ -9,3 +9,4 @@ usb-common-$(CONFIG_USB_LED_TRIG) += led.o
obj-$(CONFIG_USB_OTG_FSM) += usb-otg-fsm.o
obj-$(CONFIG_USB_ULPI_BUS) += ulpi.o
+obj-$(CONFIG_USB_ROLE_SWITCH) += roles.o
diff --git a/drivers/usb/common/roles.c b/drivers/usb/common/roles.c
new file mode 100644
index ..15cc76e22123
--- /dev/null
+++ b/drivers/usb/common/roles.c
@@ -0,0 +1,305 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * USB Role Switch Support
+ *
+ * Copyright (C) 2018 Intel Corporation
+ * Author: Heikki Krogerus
+ * Hans de Goede
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+static struct class *role_class;
+
+struct usb_role_switch {
+ struct device dev;
+ struct mutex lock; /* device lock*/
+ enum usb_role role;
+
+ /* From descriptor */
+ struct device *usb2_port;
+ struct device *usb3_port;
+ struct device *udc;
+ usb_role_switch_set_t set;
+ usb_role_switch_get_t get;
+ bool allow_userspace_control;
+};
+
+#define to_role_switch(d) container_of(d, struct usb_role_switch, dev)
+
+/**
+ * usb_role_switch_set_role - Set USB role for a switch
+ * @sw: USB role switch
+ * @role: USB role to be switched to
+ *
+ * Set USB role @role for @sw.
+ */
+int usb_role_switch_set_role(struct usb_role_switch *sw, enum usb_role role)
+{
+ int ret;
+
+ if (IS_ERR_OR_NULL(sw))
+ return 0;
+
+ mutex_lock(&sw->lock);
+
+ ret = sw->set(sw->dev.parent, role);
+ if (!ret)
+ sw->role = role;
+
+ mutex_unlock(&sw->lock);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(usb_role_switch_set_role);
+
+/**
+ * usb_role_switch_get_role - Get the USB role for a switch
+ * @sw: USB role switch
+ *
+ * Depending on the role-switch-driver this function returns either a cached
+ * value of the last set role, or reads back the actual value from the
[PATCH v7 02/12] usb: typec: API for controlling USB Type-C Multiplexers
USB Type-C connectors consist of various muxes and switches
that route the pins on the connector to the right locations.
The USB Type-C drivers need to be able to control the muxes,
as they are the ones that know things like the cable plug
orientation, and the current mode that was negotiated with
the partner.
This introduces a small API for registering and controlling
cable plug orientation switches, and separate small API for
registering and controlling pin multiplexer/demultiplexer
switches that are needed with Accessory/Alternate Modes.
Reviewed-by: Hans de Goede
Reviewed-by: Andy Shevchenko
Signed-off-by: Heikki Krogerus
---
Changes in v4:
-Add Andy's Reviewed-by
Changes in v3:
-Add #include-s for a few missing headers to drivers/usb/typec/mux.c
-Various spelling and gramar fixes in the docs pointed out by Randy Dunlap
---
Documentation/driver-api/usb/typec.rst | 73 +++--
drivers/usb/typec/Makefile | 1 +
drivers/usb/typec/{typec.c => class.c} | 70
drivers/usb/typec/mux.c| 191 +
include/linux/usb/typec.h | 14 +++
include/linux/usb/typec_mux.h | 55 ++
6 files changed, 393 insertions(+), 11 deletions(-)
rename drivers/usb/typec/{typec.c => class.c} (95%)
create mode 100644 drivers/usb/typec/mux.c
create mode 100644 include/linux/usb/typec_mux.h
diff --git a/Documentation/driver-api/usb/typec.rst
b/Documentation/driver-api/usb/typec.rst
index 8a7249f2ff04..feb31946490b 100644
--- a/Documentation/driver-api/usb/typec.rst
+++ b/Documentation/driver-api/usb/typec.rst
@@ -61,7 +61,7 @@ Registering the ports
The port drivers will describe every Type-C port they control with struct
typec_capability data structure, and register them with the following API:
-.. kernel-doc:: drivers/usb/typec/typec.c
+.. kernel-doc:: drivers/usb/typec/class.c
:functions: typec_register_port typec_unregister_port
When registering the ports, the prefer_role member in struct typec_capability
@@ -80,7 +80,7 @@ typec_partner_desc. The class copies the details of the
partner during
registration. The class offers the following API for registering/unregistering
partners.
-.. kernel-doc:: drivers/usb/typec/typec.c
+.. kernel-doc:: drivers/usb/typec/class.c
:functions: typec_register_partner typec_unregister_partner
The class will provide a handle to struct typec_partner if the registration was
@@ -92,7 +92,7 @@ should include handle to struct usb_pd_identity instance. The
class will then
create a sysfs directory for the identity under the partner device. The result
of Discover Identity command can then be reported with the following API:
-.. kernel-doc:: drivers/usb/typec/typec.c
+.. kernel-doc:: drivers/usb/typec/class.c
:functions: typec_partner_set_identity
Registering Cables
@@ -113,7 +113,7 @@ typec_cable_desc and about a plug in struct
typec_plug_desc. The class copies
the details during registration. The class offers the following API for
registering/unregistering cables and their plugs:
-.. kernel-doc:: drivers/usb/typec/typec.c
+.. kernel-doc:: drivers/usb/typec/class.c
:functions: typec_register_cable typec_unregister_cable typec_register_plug
typec_unregister_plug
The class will provide a handle to struct typec_cable and struct typec_plug if
@@ -125,7 +125,7 @@ include handle to struct usb_pd_identity instance. The
class will then create a
sysfs directory for the identity under the cable device. The result of Discover
Identity command can then be reported with the following API:
-.. kernel-doc:: drivers/usb/typec/typec.c
+.. kernel-doc:: drivers/usb/typec/class.c
:functions: typec_cable_set_identity
Notifications
@@ -135,7 +135,7 @@ When the partner has executed a role change, or when the
default roles change
during connection of a partner or cable, the port driver must use the following
APIs to report it to the class:
-.. kernel-doc:: drivers/usb/typec/typec.c
+.. kernel-doc:: drivers/usb/typec/class.c
:functions: typec_set_data_role typec_set_pwr_role typec_set_vconn_role
typec_set_pwr_opmode
Alternate Modes
@@ -150,7 +150,7 @@ and struct typec_altmode_desc which is a container for all
the supported modes.
Ports that support Alternate Modes need to register each SVID they support with
the following API:
-.. kernel-doc:: drivers/usb/typec/typec.c
+.. kernel-doc:: drivers/usb/typec/class.c
:functions: typec_port_register_altmode
If a partner or cable plug provides a list of SVIDs as response to USB Power
@@ -159,12 +159,12 @@ registered.
API for the partners:
-.. kernel-doc:: drivers/usb/typec/typec.c
+.. kernel-doc:: drivers/usb/typec/class.c
:functions: typec_partner_register_altmode
API for the Cable Plugs:
-.. kernel-doc:: drivers/usb/typec/typec.c
+.. kernel-doc:: drivers/usb/typec/class.c
:functions: typec_plug_register_altmode
So ports, partners and cable plugs will register the altern
[PATCH v7 04/12] usb: typec: Separate the definitions for data and power roles
USB Type-C specification v1.2 separated the power and data
roles more clearly. Dual-Role-Data term was introduced, and
the meaning of DRP was changed from "Dual-Role-Port" to
"Dual-Role-Power".
In order to allow the port drivers to describe the
capabilities of the ports more clearly according to the
newest specifications, introducing separate definitions for
the data roles.
Reviewed-by: Guenter Roeck
Signed-off-by: Heikki Krogerus
---
Changes in v7:
- This patch was added to the series
---
drivers/usb/typec/class.c | 56 ++---
drivers/usb/typec/fusb302/fusb302.c | 1 +
drivers/usb/typec/tcpm.c| 9 +++---
drivers/usb/typec/tps6598x.c| 26 +++--
drivers/usb/typec/typec_wcove.c | 1 +
drivers/usb/typec/ucsi/ucsi.c | 13 +++--
include/linux/usb/tcpm.h| 1 +
include/linux/usb/typec.h | 14 --
8 files changed, 80 insertions(+), 41 deletions(-)
diff --git a/drivers/usb/typec/class.c b/drivers/usb/typec/class.c
index 2620a694704f..53df10df2f9d 100644
--- a/drivers/usb/typec/class.c
+++ b/drivers/usb/typec/class.c
@@ -282,10 +282,10 @@ typec_altmode_roles_show(struct device *dev, struct
device_attribute *attr,
ssize_t ret;
switch (mode->roles) {
- case TYPEC_PORT_DFP:
+ case TYPEC_PORT_SRC:
ret = sprintf(buf, "source\n");
break;
- case TYPEC_PORT_UFP:
+ case TYPEC_PORT_SNK:
ret = sprintf(buf, "sink\n");
break;
case TYPEC_PORT_DRP:
@@ -797,14 +797,14 @@ static const char * const typec_data_roles[] = {
};
static const char * const typec_port_types[] = {
- [TYPEC_PORT_DFP] = "source",
- [TYPEC_PORT_UFP] = "sink",
+ [TYPEC_PORT_SRC] = "source",
+ [TYPEC_PORT_SNK] = "sink",
[TYPEC_PORT_DRP] = "dual",
};
static const char * const typec_port_types_drp[] = {
- [TYPEC_PORT_DFP] = "dual [source] sink",
- [TYPEC_PORT_UFP] = "dual source [sink]",
+ [TYPEC_PORT_SRC] = "dual [source] sink",
+ [TYPEC_PORT_SNK] = "dual source [sink]",
[TYPEC_PORT_DRP] = "[dual] source sink",
};
@@ -875,9 +875,7 @@ static ssize_t data_role_store(struct device *dev,
return ret;
mutex_lock(&port->port_type_lock);
- if (port->port_type != TYPEC_PORT_DRP) {
- dev_dbg(dev, "port type fixed at \"%s\"",
-typec_port_types[port->port_type]);
+ if (port->cap->data != TYPEC_PORT_DRD) {
ret = -EOPNOTSUPP;
goto unlock_and_ret;
}
@@ -897,7 +895,7 @@ static ssize_t data_role_show(struct device *dev,
{
struct typec_port *port = to_typec_port(dev);
- if (port->cap->type == TYPEC_PORT_DRP)
+ if (port->cap->data == TYPEC_PORT_DRD)
return sprintf(buf, "%s\n", port->data_role == TYPEC_HOST ?
"[host] device" : "host [device]");
@@ -1328,7 +1326,6 @@ struct typec_port *typec_register_port(struct device
*parent,
const struct typec_capability *cap)
{
struct typec_port *port;
- int role;
int ret;
int id;
@@ -1354,21 +1351,36 @@ struct typec_port *typec_register_port(struct device
*parent,
goto err_mux;
}
- if (cap->type == TYPEC_PORT_DFP)
- role = TYPEC_SOURCE;
- else if (cap->type == TYPEC_PORT_UFP)
- role = TYPEC_SINK;
- else
- role = cap->prefer_role;
-
- if (role == TYPEC_SOURCE) {
- port->data_role = TYPEC_HOST;
+ switch (cap->type) {
+ case TYPEC_PORT_SRC:
port->pwr_role = TYPEC_SOURCE;
port->vconn_role = TYPEC_SOURCE;
- } else {
- port->data_role = TYPEC_DEVICE;
+ break;
+ case TYPEC_PORT_SNK:
port->pwr_role = TYPEC_SINK;
port->vconn_role = TYPEC_SINK;
+ break;
+ case TYPEC_PORT_DRP:
+ if (cap->prefer_role != TYPEC_NO_PREFERRED_ROLE)
+ port->pwr_role = cap->prefer_role;
+ else
+ port->pwr_role = TYPEC_SINK;
+ break;
+ }
+
+ switch (cap->data) {
+ case TYPEC_PORT_DFP:
+ port->data_role = TYPEC_HOST;
+ break;
+ case TYPEC_PORT_UFP:
+ port->data_role = TYPEC_DEVICE;
+ break;
+ case TYPEC_PORT_DRD:
+ if (cap->prefer_role == TYPEC_SOURCE)
+ port->data_role = TYPEC_HOST;
+ else
+ port->data_role = TYPEC_DEVICE;
+ break;
}
port->id = id;
diff --git a/drivers/usb/typec/fusb302/fusb302.c
b/drivers/usb/typec/fusb302/fusb302.c
index da179aaf789e..f2d98c3c1f30 100644
--- a/drivers/usb/typec/fusb30
[PATCH v7 05/12] usb: typec: tcpm: Set USB role switch to device mode when configured as such
From: Hans de Goede
Setting the mux to MUX_NONE and the switch to USB_SWITCH_DISCONNECT when
the data-role is device is not correct. Plenty of devices support
operating as USB device through a (separate) USB device controller.
We really need 2 different versions of USB_SWITCH_CONNECT,
USB_SWITCH_CONNECT_HOST and USB_SWITCH_DEVICE. Rather then modifying the
tcpc_usb_switch enum for this, simply remove it and switch to the
usb_role enum which provides exactly this, this will save use needing to
convert betweent the 2 enums when calling an usb-role-switch driver later.
Besides switching to the usb_role type, this commit also actually sets the
mux to TYPEC_MUX_USB and the switch to USB_ROLE_DEVICE instead of setting
both to none when the data-role is device.
This commit also makes tcpm_reset_port() call tcpm_mux_set(port,
TYPEC_MUX_NONE, USB_ROLE_NONE) so that the mux and switch
do _not_ stay in their last mode after a detach.
Signed-off-by: Hans de Goede
Revieved-by: Heikki Krogerus
Reviewed-by: Guenter Roeck
Reviewed-by: Andy Shevchenko
Signed-off-by: Heikki Krogerus
---
Changes in v4:
-Add Andy's Reviewed-by
Changes in v3:
-Add Guenter's Reviewed-by
Changes in v2:
-Added Heikki's Reviewed-by
---
drivers/usb/typec/tcpm.c | 22 +++---
include/linux/usb/tcpm.h | 8 ++--
2 files changed, 13 insertions(+), 17 deletions(-)
diff --git a/drivers/usb/typec/tcpm.c b/drivers/usb/typec/tcpm.c
index 064b456dcf04..5e527e2e1506 100644
--- a/drivers/usb/typec/tcpm.c
+++ b/drivers/usb/typec/tcpm.c
@@ -607,15 +607,15 @@ void tcpm_pd_transmit_complete(struct tcpm_port *port,
EXPORT_SYMBOL_GPL(tcpm_pd_transmit_complete);
static int tcpm_mux_set(struct tcpm_port *port, enum tcpc_mux_mode mode,
- enum tcpc_usb_switch config)
+ enum usb_role usb_role)
{
int ret = 0;
- tcpm_log(port, "Requesting mux mode %d, config %d, polarity %d",
-mode, config, port->polarity);
+ tcpm_log(port, "Requesting mux mode %d, usb-role %d, polarity %d",
+mode, usb_role, port->polarity);
if (port->tcpc->mux)
- ret = port->tcpc->mux->set(port->tcpc->mux, mode, config,
+ ret = port->tcpc->mux->set(port->tcpc->mux, mode, usb_role,
port->polarity);
return ret;
@@ -731,14 +731,15 @@ static int tcpm_set_attached_state(struct tcpm_port
*port, bool attached)
static int tcpm_set_roles(struct tcpm_port *port, bool attached,
enum typec_role role, enum typec_data_role data)
{
+ enum usb_role usb_role;
int ret;
if (data == TYPEC_HOST)
- ret = tcpm_mux_set(port, TYPEC_MUX_USB,
- TCPC_USB_SWITCH_CONNECT);
+ usb_role = USB_ROLE_HOST;
else
- ret = tcpm_mux_set(port, TYPEC_MUX_NONE,
- TCPC_USB_SWITCH_DISCONNECT);
+ usb_role = USB_ROLE_DEVICE;
+
+ ret = tcpm_mux_set(port, TYPEC_MUX_USB, usb_role);
if (ret < 0)
return ret;
@@ -2085,7 +2086,7 @@ static int tcpm_src_attach(struct tcpm_port *port)
out_disable_pd:
port->tcpc->set_pd_rx(port->tcpc, false);
out_disable_mux:
- tcpm_mux_set(port, TYPEC_MUX_NONE, TCPC_USB_SWITCH_DISCONNECT);
+ tcpm_mux_set(port, TYPEC_MUX_NONE, USB_ROLE_NONE);
return ret;
}
@@ -2129,6 +2130,7 @@ static void tcpm_reset_port(struct tcpm_port *port)
tcpm_init_vconn(port);
tcpm_set_current_limit(port, 0, 0);
tcpm_set_polarity(port, TYPEC_POLARITY_CC1);
+ tcpm_mux_set(port, TYPEC_MUX_NONE, USB_ROLE_NONE);
tcpm_set_attached_state(port, false);
port->try_src_count = 0;
port->try_snk_count = 0;
@@ -2179,8 +2181,6 @@ static int tcpm_snk_attach(struct tcpm_port *port)
static void tcpm_snk_detach(struct tcpm_port *port)
{
tcpm_detach(port);
-
- /* XXX: (Dis)connect SuperSpeed mux? */
}
static int tcpm_acc_attach(struct tcpm_port *port)
diff --git a/include/linux/usb/tcpm.h b/include/linux/usb/tcpm.h
index 5a5e1d8c5b65..3e8bdaa5085a 100644
--- a/include/linux/usb/tcpm.h
+++ b/include/linux/usb/tcpm.h
@@ -16,6 +16,7 @@
#define __LINUX_USB_TCPM_H
#include
+#include
#include
#include "pd.h"
@@ -98,11 +99,6 @@ struct tcpc_config {
const struct typec_altmode_desc *alt_modes;
};
-enum tcpc_usb_switch {
- TCPC_USB_SWITCH_CONNECT,
- TCPC_USB_SWITCH_DISCONNECT,
-};
-
/* Mux state attributes */
#define TCPC_MUX_USB_ENABLED BIT(0) /* USB enabled */
#define TCPC_MUX_DP_ENABLEDBIT(1) /* DP enabled */
@@ -119,7 +115,7 @@ enum tcpc_mux_mode {
struct tcpc_mux_dev {
int (*set)(struct tcpc_mux_dev *dev, enum tcpc_mux_mode mux_mode,
- enum tcpc_usb_switch usb_config,
+ enum usb_role usb_role,
enum typec_cc_polarity
[PATCH v7 06/12] usb: typec: tcpm: Use new Type-C switch/mux and usb-role-switch functions
From: Hans de Goede
Remove the unused (not implemented anywhere) tcpc_mux_dev abstraction
and replace it with calling the new typec_set_orientation,
usb_role_switch_set and typec_set_mode functions.
Signed-off-by: Hans de Goede
Revieved-by: Heikki Krogerus
Reviewed-by: Guenter Roeck
Reviewed-by: Andy Shevchenko
Signed-off-by: Heikki Krogerus
---
Changes in v4:
-Add Andy's Reviewed-by
Changes in v3:
-Add Guenter's Reviewed-by
Changes in v2:
-Added Heikki's Reviewed-by
---
drivers/usb/typec/Kconfig | 1 +
drivers/usb/typec/fusb302/fusb302.c | 1 -
drivers/usb/typec/tcpm.c| 46 -
include/linux/usb/tcpm.h| 10
4 files changed, 36 insertions(+), 22 deletions(-)
diff --git a/drivers/usb/typec/Kconfig b/drivers/usb/typec/Kconfig
index bcb2744c5977..a2a0684e7c82 100644
--- a/drivers/usb/typec/Kconfig
+++ b/drivers/usb/typec/Kconfig
@@ -48,6 +48,7 @@ if TYPEC
config TYPEC_TCPM
tristate "USB Type-C Port Controller Manager"
depends on USB
+ select USB_ROLE_SWITCH
help
The Type-C Port Controller Manager provides a USB PD and USB Type-C
state machine for use with Type-C Port Controllers.
diff --git a/drivers/usb/typec/fusb302/fusb302.c
b/drivers/usb/typec/fusb302/fusb302.c
index f2d98c3c1f30..f0a2f8954bbd 100644
--- a/drivers/usb/typec/fusb302/fusb302.c
+++ b/drivers/usb/typec/fusb302/fusb302.c
@@ -1239,7 +1239,6 @@ static void init_tcpc_dev(struct tcpc_dev
*fusb302_tcpc_dev)
fusb302_tcpc_dev->set_roles = tcpm_set_roles;
fusb302_tcpc_dev->start_drp_toggling = tcpm_start_drp_toggling;
fusb302_tcpc_dev->pd_transmit = tcpm_pd_transmit;
- fusb302_tcpc_dev->mux = NULL;
}
static const char * const cc_polarity_name[] = {
diff --git a/drivers/usb/typec/tcpm.c b/drivers/usb/typec/tcpm.c
index 5e527e2e1506..3f0851bfe18f 100644
--- a/drivers/usb/typec/tcpm.c
+++ b/drivers/usb/typec/tcpm.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -176,6 +177,7 @@ struct tcpm_port {
struct typec_port *typec_port;
struct tcpc_dev *tcpc;
+ struct usb_role_switch *role_sw;
enum typec_role vconn_role;
enum typec_role pwr_role;
@@ -607,18 +609,25 @@ void tcpm_pd_transmit_complete(struct tcpm_port *port,
EXPORT_SYMBOL_GPL(tcpm_pd_transmit_complete);
static int tcpm_mux_set(struct tcpm_port *port, enum tcpc_mux_mode mode,
- enum usb_role usb_role)
+ enum usb_role usb_role,
+ enum typec_orientation orientation)
{
- int ret = 0;
+ int ret;
- tcpm_log(port, "Requesting mux mode %d, usb-role %d, polarity %d",
-mode, usb_role, port->polarity);
+ tcpm_log(port, "Requesting mux mode %d, usb-role %d, orientation %d",
+mode, usb_role, orientation);
- if (port->tcpc->mux)
- ret = port->tcpc->mux->set(port->tcpc->mux, mode, usb_role,
- port->polarity);
+ ret = typec_set_orientation(port->typec_port, orientation);
+ if (ret)
+ return ret;
- return ret;
+ if (port->role_sw) {
+ ret = usb_role_switch_set_role(port->role_sw, usb_role);
+ if (ret)
+ return ret;
+ }
+
+ return typec_set_mode(port->typec_port, mode);
}
static int tcpm_set_polarity(struct tcpm_port *port,
@@ -731,15 +740,21 @@ static int tcpm_set_attached_state(struct tcpm_port
*port, bool attached)
static int tcpm_set_roles(struct tcpm_port *port, bool attached,
enum typec_role role, enum typec_data_role data)
{
+ enum typec_orientation orientation;
enum usb_role usb_role;
int ret;
+ if (port->polarity == TYPEC_POLARITY_CC1)
+ orientation = TYPEC_ORIENTATION_NORMAL;
+ else
+ orientation = TYPEC_ORIENTATION_REVERSE;
+
if (data == TYPEC_HOST)
usb_role = USB_ROLE_HOST;
else
usb_role = USB_ROLE_DEVICE;
- ret = tcpm_mux_set(port, TYPEC_MUX_USB, usb_role);
+ ret = tcpm_mux_set(port, TYPEC_MUX_USB, usb_role, orientation);
if (ret < 0)
return ret;
@@ -2086,7 +2101,8 @@ static int tcpm_src_attach(struct tcpm_port *port)
out_disable_pd:
port->tcpc->set_pd_rx(port->tcpc, false);
out_disable_mux:
- tcpm_mux_set(port, TYPEC_MUX_NONE, USB_ROLE_NONE);
+ tcpm_mux_set(port, TYPEC_MUX_NONE, USB_ROLE_NONE,
+TYPEC_ORIENTATION_NONE);
return ret;
}
@@ -2130,7 +2146,8 @@ static void tcpm_reset_port(struct tcpm_port *port)
tcpm_init_vconn(port);
tcpm_set_current_limit(port, 0, 0);
tcpm_set_polarity(port, TYPEC_POLARITY_CC1);
- tcpm_mux_set(port, TYPEC_MUX_NONE, USB_ROLE_NONE);
+ tcpm_mux_set(port, T
[PATCH v7 07/12] xhci: Add option to get next extended capability in list by passing id = 0
From: Mathias Nyman Modify xhci_find_next_ext_cap(base, offset, id) to return the next capability offset if 0 is passed for id. Otherwise it will behave as previously and return the offset of the next capability with matching id capability id 0 is not used by xHCI (reserved) This is useful when we want to loop through all capabilities. Signed-off-by: Mathias Nyman Revieved-by: Heikki Krogerus Reviewed-by: Andy Shevchenko Signed-off-by: Heikki Krogerus --- Changes in v4: -Add Andy's Reviewed-by Changes in v2: -Added Heikki's Reviewed-by --- drivers/usb/host/xhci-ext-caps.h | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/usb/host/xhci-ext-caps.h b/drivers/usb/host/xhci-ext-caps.h index bf7316e130d3..631e7cc62604 100644 --- a/drivers/usb/host/xhci-ext-caps.h +++ b/drivers/usb/host/xhci-ext-caps.h @@ -84,7 +84,8 @@ * @base PCI MMIO registers base address. * @start address at which to start looking, (0 or HCC_PARAMS to start at * beginning of list) - * @id Extended capability ID to search for. + * @id Extended capability ID to search for, or 0 for the next + * capability * * Returns the offset of the next matching extended capability structure. * Some capabilities can occur several times, e.g., the XHCI_EXT_CAPS_PROTOCOL, @@ -110,7 +111,7 @@ static inline int xhci_find_next_ext_cap(void __iomem *base, u32 start, int id) val = readl(base + offset); if (val == ~0) return 0; - if (XHCI_EXT_CAPS_ID(val) == id && offset != start) + if (offset != start && (id == 0 || XHCI_EXT_CAPS_ID(val) == id)) return offset; next = XHCI_EXT_CAPS_NEXT(val); -- 2.16.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 v7 08/12] xhci: Add Intel extended cap / otg phy mux handling
From: Hans de Goede
The xHCI controller on various Intel SoCs has an extended cap mmio-range
which contains registers to control the muxing to the xHCI (host mode)
or the dwc3 (device mode) and vbus-detection for the otg usb-phy.
Having a role-sw driver included in the xHCI code (under drivers/usb/host)
is not desirable. So this commit adds a simple handler for this extended
capability, which creates a platform device with the caps mmio region as
resource, this allows us to write a separate platform role-sw driver for
the role-switch.
Note this commit adds a call to the new xhci_ext_cap_init() function
to xhci_pci_probe(), it is added here because xhci_ext_cap_init() must
be called only once. If in the future we also want to handle ext-caps
on non pci xHCI HCDs from xhci_ext_cap_init() a call to it should also
be added to other bus probe paths.
Signed-off-by: Hans de Goede
Acked-by: Mathias Nyman
Revieved-by: Heikki Krogerus
Reviewed-by: Andy Shevchenko
Signed-off-by: Heikki Krogerus
---
Changes in v4:
-Add Andy's Reviewed-by
Changes in v2:
-Use SPDX license header
-Various small style cleanups / changes
-Add Heikki's Reviewed-by
Changes from some time ago when this patch was part of another patch-set:
-Check xHCI controller PCI device-id instead of only checking for the
Intel Extended capability ID, as the Extended capability ID is used on
other model Intel xHCI controllers too
-Add a new generic xhci_ext_cap_init() function and handle the new
XHCI_INTEL_CHT_USB_MUX quirk there.
-Stop using Cherry Trail / CHT in various places as other Intel SoCs
(e.g. Broxton / Apollo Lake) also have this
---
drivers/usb/host/Makefile| 2 +-
drivers/usb/host/xhci-ext-caps.c | 90
drivers/usb/host/xhci-ext-caps.h | 2 +
drivers/usb/host/xhci-pci.c | 5 +++
drivers/usb/host/xhci.h | 2 +
5 files changed, 100 insertions(+), 1 deletion(-)
create mode 100644 drivers/usb/host/xhci-ext-caps.c
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index 4ede4ce12366..8a8cffe0b445 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -11,7 +11,7 @@ fhci-y += fhci-mem.o fhci-tds.o fhci-sched.o
fhci-$(CONFIG_FHCI_DEBUG) += fhci-dbg.o
-xhci-hcd-y := xhci.o xhci-mem.o
+xhci-hcd-y := xhci.o xhci-mem.o xhci-ext-caps.o
xhci-hcd-y += xhci-ring.o xhci-hub.o xhci-dbg.o
xhci-hcd-y += xhci-trace.o
diff --git a/drivers/usb/host/xhci-ext-caps.c b/drivers/usb/host/xhci-ext-caps.c
new file mode 100644
index ..399113f9fc5c
--- /dev/null
+++ b/drivers/usb/host/xhci-ext-caps.c
@@ -0,0 +1,90 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * XHCI extended capability handling
+ *
+ * Copyright (c) 2017 Hans de Goede
+ */
+
+#include
+#include "xhci.h"
+
+#define USB_SW_DRV_NAME"intel_xhci_usb_sw"
+#define USB_SW_RESOURCE_SIZE 0x400
+
+static void xhci_intel_unregister_pdev(void *arg)
+{
+ platform_device_unregister(arg);
+}
+
+static int xhci_create_intel_xhci_sw_pdev(struct xhci_hcd *xhci, u32
cap_offset)
+{
+ struct usb_hcd *hcd = xhci_to_hcd(xhci);
+ struct device *dev = hcd->self.controller;
+ struct platform_device *pdev;
+ struct resource res = { 0, };
+ int ret;
+
+ pdev = platform_device_alloc(USB_SW_DRV_NAME, PLATFORM_DEVID_NONE);
+ if (!pdev) {
+ xhci_err(xhci, "couldn't allocate %s platform device\n",
+USB_SW_DRV_NAME);
+ return -ENOMEM;
+ }
+
+ res.start = hcd->rsrc_start + cap_offset;
+ res.end = res.start + USB_SW_RESOURCE_SIZE - 1;
+ res.name = USB_SW_DRV_NAME;
+ res.flags = IORESOURCE_MEM;
+
+ ret = platform_device_add_resources(pdev, &res, 1);
+ if (ret) {
+ dev_err(dev, "couldn't add resources to intel_xhci_usb_sw
pdev\n");
+ platform_device_put(pdev);
+ return ret;
+ }
+
+ pdev->dev.parent = dev;
+
+ ret = platform_device_add(pdev);
+ if (ret) {
+ dev_err(dev, "couldn't register intel_xhci_usb_sw pdev\n");
+ platform_device_put(pdev);
+ return ret;
+ }
+
+ ret = devm_add_action_or_reset(dev, xhci_intel_unregister_pdev, pdev);
+ if (ret) {
+ dev_err(dev, "couldn't add unregister action for
intel_xhci_usb_sw pdev\n");
+ return ret;
+ }
+
+ return 0;
+}
+
+int xhci_ext_cap_init(struct xhci_hcd *xhci)
+{
+ void __iomem *base = &xhci->cap_regs->hc_capbase;
+ u32 offset, val;
+ int ret;
+
+ offset = xhci_find_next_ext_cap(base, 0, 0);
+
+ while (offset) {
+ val = readl(base + offset);
+
+ switch (XHCI_EXT_CAPS_ID(val)) {
+ case XHCI_EXT_CAPS_VENDOR_INTEL:
+ if (xhci->quirks & XHCI_INTEL_USB_ROLE_SW) {
+ ret = xhci_create_intel_xhci_sw_pdev(xhci,
+
[PATCH v7 09/12] usb: roles: Add Intel xHCI USB role switch driver
From: Hans de Goede
Various Intel SoCs (Cherry Trail, Broxton and others) have an internal USB
role switch for swiching the OTG USB data lines between the xHCI host
controller and the dwc3 gadget controller.
Note on some Cherry Trail systems there is ACPI/AML code listening to
edge interrupts on the id-pin (through an _AIE ACPI method) and switching
the role between ROLE_HOST and ROLE_NONE based on the id-pin. Note it does
not set the role to ROLE_DEVICE, because device-mode is usually not used
under Windows.
The presence of AML code which modifies the cfg0 reg (on some systems)
means that our read/write/modify of cfg0 may race with the AML code
doing the same to avoid this we take the global ACPI lock while doing
the read/write/modify.
Signed-off-by: Hans de Goede
Reviewed-by: Heikki Krogerus
Reviewed-by: Andy Shevchenko
Signed-off-by: Heikki Krogerus
---
Changes in v7:
- Declare intel_xhci_usb_remove() as static
Changes in v4:
-Add Andy's Reviewed-by
-Add Heikki's Reviewed-by
Changes in v2:
-Drop unnecessary depends on EXTCON from Kconfig
-Use BIT(), resource_size()
-Various other small style fixes
---
MAINTAINERS| 6 +
drivers/usb/Kconfig| 2 +
drivers/usb/Makefile | 2 +
drivers/usb/roles/Kconfig | 14 ++
drivers/usb/roles/Makefile | 1 +
drivers/usb/roles/intel-xhci-usb-role-switch.c | 192 +
6 files changed, 217 insertions(+)
create mode 100644 drivers/usb/roles/Kconfig
create mode 100644 drivers/usb/roles/Makefile
create mode 100644 drivers/usb/roles/intel-xhci-usb-role-switch.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 93a12af4f180..5f1988cddbe8 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -14385,6 +14385,12 @@ S: Maintained
F: Documentation/hid/hiddev.txt
F: drivers/hid/usbhid/
+USB INTEL XHCI ROLE MUX DRIVER
+M: Hans de Goede
+L: linux-usb@vger.kernel.org
+S: Maintained
+F: drivers/usb/roles/intel-xhci-usb-role-switch.c
+
USB ISP116X DRIVER
M: Olav Kongas
L: linux-usb@vger.kernel.org
diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig
index f278958e04ca..75f7fb151f71 100644
--- a/drivers/usb/Kconfig
+++ b/drivers/usb/Kconfig
@@ -171,6 +171,8 @@ source "drivers/usb/gadget/Kconfig"
source "drivers/usb/typec/Kconfig"
+source "drivers/usb/roles/Kconfig"
+
config USB_LED_TRIG
bool "USB LED Triggers"
depends on LEDS_CLASS && LEDS_TRIGGERS
diff --git a/drivers/usb/Makefile b/drivers/usb/Makefile
index 060643a1b5c8..7d1b8c82b208 100644
--- a/drivers/usb/Makefile
+++ b/drivers/usb/Makefile
@@ -65,3 +65,5 @@ obj-$(CONFIG_USB_COMMON) += common/
obj-$(CONFIG_USBIP_CORE) += usbip/
obj-$(CONFIG_TYPEC)+= typec/
+
+obj-$(CONFIG_USB_ROLE_SWITCH) += roles/
diff --git a/drivers/usb/roles/Kconfig b/drivers/usb/roles/Kconfig
new file mode 100644
index ..f5a5e6f79f1b
--- /dev/null
+++ b/drivers/usb/roles/Kconfig
@@ -0,0 +1,14 @@
+if USB_ROLE_SWITCH
+
+config USB_ROLES_INTEL_XHCI
+ tristate "Intel XHCI USB Role Switch"
+ depends on ACPI && X86
+ help
+ Driver for the internal USB role switch for switching the USB data
+ lines between the xHCI host controller and the dwc3 gadget controller
+ found on various Intel SoCs.
+
+ To compile the driver as a module, choose M here: the module will
+ be called intel-xhci-usb-role-switch.
+
+endif # USB_ROLE_SWITCH
diff --git a/drivers/usb/roles/Makefile b/drivers/usb/roles/Makefile
new file mode 100644
index ..e44b179ba275
--- /dev/null
+++ b/drivers/usb/roles/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_USB_ROLES_INTEL_XHCI) += intel-xhci-usb-role-switch.o
diff --git a/drivers/usb/roles/intel-xhci-usb-role-switch.c
b/drivers/usb/roles/intel-xhci-usb-role-switch.c
new file mode 100644
index ..58c1b60a33c1
--- /dev/null
+++ b/drivers/usb/roles/intel-xhci-usb-role-switch.c
@@ -0,0 +1,192 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Intel XHCI (Cherry Trail, Broxton and others) USB OTG role switch driver
+ *
+ * Copyright (c) 2016-2017 Hans de Goede
+ *
+ * Loosely based on android x86 kernel code which is:
+ *
+ * Copyright (C) 2014 Intel Corp.
+ *
+ * Author: Wu, Hao
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* register definition */
+#define DUAL_ROLE_CFG0 0x68
+#define SW_VBUS_VALID BIT(24)
+#define SW_IDPIN_ENBIT(21)
+#define SW_IDPIN BIT(20)
+
+#define DUAL_ROLE_CFG1 0x6c
+#define HOST_MODE BIT(29)
+
+#define DUAL_ROLE_CFG1_POLL_TIMEOUT1000
+
+#define DRV_NAME "intel_xhci_usb_sw"
+
+struct intel_xhci_usb_data {
+ struct usb_role_switch *role_sw;
+ void __iomem *base;
+};
+
+struct intel_xhci_acpi_match {
+
[PATCH v7 10/12] usb: typec: driver for Pericom PI3USB30532 Type-C cross switch
From: Hans de Goede
Add a driver for the Pericom PI3USB30532 Type-C cross switch /
mux chip found on some devices with a Type-C port.
Signed-off-by: Hans de Goede
Reviewed-by: Heikki Krogerus
Reviewed-by: Andy Shevchenko
Signed-off-by: Heikki Krogerus
---
Changes in v7:
- Remove unneeded semicolon
Changes in v4:
-Add Andy's Reviewed-by
Changes in v2:
-Cleanup pi3usb30532_set_conf() error handling
-Add Heikki's Reviewed-by
Changes in v1:
-This is a rewrite of my previous driver which was using the
drivers/mux framework to use the new drivers/usb/typec/mux framework
---
MAINTAINERS | 6 ++
drivers/usb/typec/Kconfig | 2 +
drivers/usb/typec/Makefile | 1 +
drivers/usb/typec/mux/Kconfig | 10 ++
drivers/usb/typec/mux/Makefile | 3 +
drivers/usb/typec/mux/pi3usb30532.c | 178
6 files changed, 200 insertions(+)
create mode 100644 drivers/usb/typec/mux/Kconfig
create mode 100644 drivers/usb/typec/mux/Makefile
create mode 100644 drivers/usb/typec/mux/pi3usb30532.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 5f1988cddbe8..17b64236719f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -14521,6 +14521,12 @@ F: drivers/usb/
F: include/linux/usb.h
F: include/linux/usb/
+USB TYPEC PI3USB30532 MUX DRIVER
+M: Hans de Goede
+L: linux-usb@vger.kernel.org
+S: Maintained
+F: drivers/usb/typec/mux/pi3usb30532.c
+
USB TYPEC SUBSYSTEM
M: Heikki Krogerus
L: linux-usb@vger.kernel.org
diff --git a/drivers/usb/typec/Kconfig b/drivers/usb/typec/Kconfig
index a2a0684e7c82..030f88cb0c3f 100644
--- a/drivers/usb/typec/Kconfig
+++ b/drivers/usb/typec/Kconfig
@@ -85,4 +85,6 @@ config TYPEC_TPS6598X
If you choose to build this driver as a dynamically linked module, the
module will be called tps6598x.ko.
+source "drivers/usb/typec/mux/Kconfig"
+
endif # TYPEC
diff --git a/drivers/usb/typec/Makefile b/drivers/usb/typec/Makefile
index 56b2e9516ec1..1f599a6c30cc 100644
--- a/drivers/usb/typec/Makefile
+++ b/drivers/usb/typec/Makefile
@@ -6,3 +6,4 @@ obj-y += fusb302/
obj-$(CONFIG_TYPEC_WCOVE) += typec_wcove.o
obj-$(CONFIG_TYPEC_UCSI) += ucsi/
obj-$(CONFIG_TYPEC_TPS6598X) += tps6598x.o
+obj-$(CONFIG_TYPEC)+= mux/
diff --git a/drivers/usb/typec/mux/Kconfig b/drivers/usb/typec/mux/Kconfig
new file mode 100644
index ..9a954d2b8d8f
--- /dev/null
+++ b/drivers/usb/typec/mux/Kconfig
@@ -0,0 +1,10 @@
+menu "USB Type-C Multiplexer/DeMultiplexer Switch support"
+
+config TYPEC_MUX_PI3USB30532
+ tristate "Pericom PI3USB30532 Type-C cross switch driver"
+ depends on I2C
+ help
+ Say Y or M if your system has a Pericom PI3USB30532 Type-C cross
+ switch / mux chip found on some devices with a Type-C port.
+
+endmenu
diff --git a/drivers/usb/typec/mux/Makefile b/drivers/usb/typec/mux/Makefile
new file mode 100644
index ..1332e469b8a0
--- /dev/null
+++ b/drivers/usb/typec/mux/Makefile
@@ -0,0 +1,3 @@
+# SPDX-License-Identifier: GPL-2.0
+
+obj-$(CONFIG_TYPEC_MUX_PI3USB30532)+= pi3usb30532.o
diff --git a/drivers/usb/typec/mux/pi3usb30532.c
b/drivers/usb/typec/mux/pi3usb30532.c
new file mode 100644
index ..b0e88db60ecf
--- /dev/null
+++ b/drivers/usb/typec/mux/pi3usb30532.c
@@ -0,0 +1,178 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Pericom PI3USB30532 Type-C cross switch / mux driver
+ *
+ * Copyright (c) 2017-2018 Hans de Goede
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define PI3USB30532_CONF 0x00
+
+#define PI3USB30532_CONF_OPEN 0x00
+#define PI3USB30532_CONF_SWAP 0x01
+#define PI3USB30532_CONF_4LANE_DP 0x02
+#define PI3USB30532_CONF_USB3 0x04
+#define PI3USB30532_CONF_USB3_AND_2LANE_DP 0x06
+
+struct pi3usb30532 {
+ struct i2c_client *client;
+ struct mutex lock; /* protects the cached conf register */
+ struct typec_switch sw;
+ struct typec_mux mux;
+ u8 conf;
+};
+
+static int pi3usb30532_set_conf(struct pi3usb30532 *pi, u8 new_conf)
+{
+ int ret = 0;
+
+ if (pi->conf == new_conf)
+ return 0;
+
+ ret = i2c_smbus_write_byte_data(pi->client, PI3USB30532_CONF, new_conf);
+ if (ret) {
+ dev_err(&pi->client->dev, "Error writing conf: %d\n", ret);
+ return ret;
+ }
+
+ pi->conf = new_conf;
+ return 0;
+}
+
+static int pi3usb30532_sw_set(struct typec_switch *sw,
+ enum typec_orientation orientation)
+{
+ struct pi3usb30532 *pi = container_of(sw, struct pi3usb30532, sw);
+ u8 new_conf;
+ int ret;
+
+ mutex_lock(&pi->lock);
+ new_conf = pi->conf;
+
+ switch (orientation) {
+ case TYPEC_ORIENTATION_NONE:
+ new_conf = PI3USB30532_CONF_OPEN;
[PATCH v7 11/12] platform/x86: intel_cht_int33fe: Add device connections for the Type-C port
From: Hans de Goede
We need to add device-connections for the Type-C mux/switch and usb-role
code to be able to find the PI3USB30532 Type-C cross-switch and the
device/host role-switch integrated in the CHT SoC.
Signed-off-by: Hans de Goede
Reviewed-by: Heikki Krogerus
Reviewed-by: Andy Shevchenko
Signed-off-by: Heikki Krogerus
---
Changes in v4:
-Replace Andy's Acked-by with his Reviewed-by
Changes in v2:
-Add Andy's Acked-by
-Add Heikki's Reviewed-by
---
drivers/platform/x86/intel_cht_int33fe.c | 24
1 file changed, 24 insertions(+)
diff --git a/drivers/platform/x86/intel_cht_int33fe.c
b/drivers/platform/x86/intel_cht_int33fe.c
index 380ef7ec094f..39d4100c60a2 100644
--- a/drivers/platform/x86/intel_cht_int33fe.c
+++ b/drivers/platform/x86/intel_cht_int33fe.c
@@ -33,6 +33,8 @@ struct cht_int33fe_data {
struct i2c_client *max17047;
struct i2c_client *fusb302;
struct i2c_client *pi3usb30532;
+ /* Contain a list-head must be per device */
+ struct device_connection connections[3];
};
/*
@@ -172,6 +174,20 @@ static int cht_int33fe_probe(struct i2c_client *client)
return -EPROBE_DEFER; /* Wait for i2c-adapter to load */
}
+ data->connections[0].endpoint[0] = "i2c-fusb302";
+ data->connections[0].endpoint[1] = "i2c-pi3usb30532";
+ data->connections[0].id = "typec-switch";
+ data->connections[1].endpoint[0] = "i2c-fusb302";
+ data->connections[1].endpoint[1] = "i2c-pi3usb30532";
+ data->connections[1].id = "typec-mux";
+ data->connections[2].endpoint[0] = "i2c-fusb302";
+ data->connections[2].endpoint[1] = "intel_xhci_usb_sw-role-switch";
+ data->connections[2].id = "usb-role-switch";
+
+ device_connection_add(&data->connections[0]);
+ device_connection_add(&data->connections[1]);
+ device_connection_add(&data->connections[2]);
+
memset(&board_info, 0, sizeof(board_info));
strlcpy(board_info.type, "typec_fusb302", I2C_NAME_SIZE);
board_info.dev_name = "fusb302";
@@ -201,6 +217,10 @@ static int cht_int33fe_probe(struct i2c_client *client)
if (data->max17047)
i2c_unregister_device(data->max17047);
+ device_connection_remove(&data->connections[2]);
+ device_connection_remove(&data->connections[1]);
+ device_connection_remove(&data->connections[0]);
+
return -EPROBE_DEFER; /* Wait for the i2c-adapter to load */
}
@@ -213,6 +233,10 @@ static int cht_int33fe_remove(struct i2c_client *i2c)
if (data->max17047)
i2c_unregister_device(data->max17047);
+ device_connection_remove(&data->connections[2]);
+ device_connection_remove(&data->connections[1]);
+ device_connection_remove(&data->connections[0]);
+
return 0;
}
--
2.16.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 v7 12/12] extcon: axp288: Set USB role where necessary
From: Hans de Goede
The AXP288 BC1.2 charger detection / extcon code may seem like a strange
place to add code to control the USB role-switch on devices with an AXP288,
but there are 2 reasons to do this inside the axp288 extcon code:
1) On many devices the USB role is controlled by ACPI AML code, but the AML
code only switches between the host and none roles, because of Windows
not really using device mode. To make device mode work we need to toggle
between the none/device roles based on Vbus presence, and the axp288
extcon gets interrupts on Vbus insertion / removal.
2) In order for our BC1.2 charger detection to work properly the role
mux must be properly set to device mode before we do the detection.
Also note the Kconfig help-text / obsolete depends on USB_PHY which are
remnants from older never upstreamed code also controlling the mux from
the axp288 extcon code.
This commit also adds code to get notifications from the INT3496 extcon
device, which is used on some devices to notify the kernel about id-pin
changes instead of them being handled through AML code.
This fixes:
-Device mode not working on most CHT devices with an AXP288
-Host mode not working on devices with an INT3496 ACPI device
-Charger-type misdetection (always SDP) on devices with an INT3496 when the
USB role (always) gets initialized as host
Signed-off-by: Hans de Goede
Reviewed-by: Heikki Krogerus
Reviewed-by: Andy Shevchenko
Signed-off-by: Heikki Krogerus
---
Changes in v4:
-Add Andy's Reviewed-by
Changes in v2:
-Add depends on X86 to Kconfig (the AXP288 PMIC is only used on X86)
-Use new acpi_dev_get_first_match_name() helper to get the INT3496 device-name
-Add Heikki's Reviewed-by
---
drivers/extcon/Kconfig | 3 +-
drivers/extcon/extcon-axp288.c | 176 +++--
2 files changed, 170 insertions(+), 9 deletions(-)
diff --git a/drivers/extcon/Kconfig b/drivers/extcon/Kconfig
index a7bca4207f44..de15bf55895b 100644
--- a/drivers/extcon/Kconfig
+++ b/drivers/extcon/Kconfig
@@ -30,7 +30,8 @@ config EXTCON_ARIZONA
config EXTCON_AXP288
tristate "X-Power AXP288 EXTCON support"
- depends on MFD_AXP20X && USB_PHY
+ depends on MFD_AXP20X && USB_SUPPORT && X86
+ select USB_ROLE_SWITCH
help
Say Y here to enable support for USB peripheral detection
and USB MUX switching by X-Power AXP288 PMIC.
diff --git a/drivers/extcon/extcon-axp288.c b/drivers/extcon/extcon-axp288.c
index 3ec4c715e240..a983708b77a6 100644
--- a/drivers/extcon/extcon-axp288.c
+++ b/drivers/extcon/extcon-axp288.c
@@ -1,6 +1,7 @@
/*
* extcon-axp288.c - X-Power AXP288 PMIC extcon cable detection driver
*
+ * Copyright (c) 2017-2018 Hans de Goede
* Copyright (C) 2015 Intel Corporation
* Author: Ramakrishna Pallala
*
@@ -14,6 +15,7 @@
* GNU General Public License for more details.
*/
+#include
#include
#include
#include
@@ -25,6 +27,11 @@
#include
#include
#include
+#include
+#include
+
+#include
+#include
/* Power source status register */
#define PS_STAT_VBUS_TRIGGER BIT(0)
@@ -97,9 +104,19 @@ struct axp288_extcon_info {
struct device *dev;
struct regmap *regmap;
struct regmap_irq_chip_data *regmap_irqc;
+ struct usb_role_switch *role_sw;
+ struct work_struct role_work;
int irq[EXTCON_IRQ_END];
struct extcon_dev *edev;
+ struct extcon_dev *id_extcon;
+ struct notifier_block id_nb;
unsigned int previous_cable;
+ bool vbus_attach;
+};
+
+static const struct x86_cpu_id cherry_trail_cpu_ids[] = {
+ { X86_VENDOR_INTEL, 6, INTEL_FAM6_ATOM_AIRMONT, X86_FEATURE_ANY },
+ {}
};
/* Power up/down reason string array */
@@ -137,20 +154,74 @@ static void axp288_extcon_log_rsi(struct
axp288_extcon_info *info)
regmap_write(info->regmap, AXP288_PS_BOOT_REASON_REG, clear_mask);
}
-static int axp288_handle_chrg_det_event(struct axp288_extcon_info *info)
+/*
+ * The below code to control the USB role-switch on devices with an AXP288
+ * may seem out of place, but there are 2 reasons why this is the best place
+ * to control the USB role-switch on such devices:
+ * 1) On many devices the USB role is controlled by AML code, but the AML code
+ *only switches between the host and none roles, because of Windows not
+ *really using device mode. To make device mode work we need to toggle
+ *between the none/device roles based on Vbus presence, and this driver
+ *gets interrupts on Vbus insertion / removal.
+ * 2) In order for our BC1.2 charger detection to work properly the role
+ *mux must be properly set to device mode before we do the detection.
+ */
+
+/* Returns the id-pin value, note pulled low / false == host-mode */
+static bool axp288_get_id_pin(struct axp288_extcon_info *info)
{
- int ret, stat, cfg, pwr_stat;
- u8 chrg_type;
- unsigned int cable = info->previous_cable;
-
[PATCH v7 00/12] USB Type-C device-connection, mux and switch support
Hi,
This is version 7 of Hans' and my series introducing support for USB muxes and
generic device-connections. The api naming for device-connections is now made
according to proposal from Greg, connection.h is dropped and the prototypes are
now in device.h. kbuild test robot also found stylistic
problems from patches 9/12 and 10/12 which were fixed. The patch 4/12 ("usb:
typec: Separate the definitions for data and power roles") was added to the
series.
Check the v6 from here:
https://lkml.org/lkml/2018/3/2/340
Here is the cover-letter of v6:
Hi All,
Here is version 6 of Heikki's and my USB Type-C device-connection, mux and
switch support series. Versions 2 - 5 bring various small code and style
fixes based on review (no major changes). Version 6 is rebased on top of
the latest usb-next and brings one small but important code fix in
the devcon code.
Here is the original cover-letter of v1:
Some devices with an USB Type-C connector have a bunch of muxes
behind that connector which need to be controlled by the kernel (rather
then having them controlled by firmware as on most devices).
Quite a while back I submitted a patch-series to tie together these muxes
and the Type-C Port Manager (tcpm) code, using the then new drivers/mux
framework. But the way I used the mux framework went against what it was
designed for, so in the end that series got nowhere.
Heikki Krogerus from Intel, who maintains the USB TYPEC subsystem, has
recently been working on solving the same problem for some boards he is
doing hardware-enablement for.
Heikki has come up with a number of infrastructure patches for this.
The first one is a new device-connection framework. This solves the
problem of describing non bus device-links on x86 in what in my experience
with this problematic area is a really nice simple, clean and *generic*
way. This could for example in the near future also replace the custom
lookup code in the pwm subsys and the custom pwm_add_table() /
pwm_remove_table() functions.
The other 3 patches add a framework for the different type of Type-C /
USB "muxes".
Heikki and I have gone through a number of iterations of these patches
together and we believe these are now ready for merging. Since merging
infrastructure patches without users is not done and Heikki's own use-case
for these is not yet ready for merging, the rest of this series consists
of patches by me to make the Type-C connector found on some Cherry Trail
devices (finally) be able to actually work as an USB port and not just
a charge port.
The last patch uses the new usb-role-switch framework to also do proper
devcie / host switching on CHT devices with a USB micro AB connector.
This is also a big feature for CHT users, because before this they had
to do a reboot to get an OTG-host cable recognized (on some devices).
Part of this series is an usb-role-switch driver for the role-switch
found inside the xhci controller on e.g. CHT devices, this is currently
implemented as the generic xhci controller instantiating a platform
child-device for this, since this really is a separate chunk of HW
which happens to sit in the XHCI mmio space. This approach may not be
universally liked, given that in this new series the role-switch driver
is much smaller and does not have any external deps anymore we could
just integrate it into the xhci code if that is preferred.
About merging this series (once everything is reviewed, etc.), there are
quite some interdependencies in it esp. a lot of the patches depend on
the first patch. Luckily patches 1-10 all apply to subsystems which are
maintained by Greg (most to the USB subsys). Which just leaves patches
11 and 12 once 1-10 are merged. Greg, can you create an immutable branch
for the platform/x86 and extcon maintainers to merge once this is done?
Regards,
Hans
Hans de Goede (7):
usb: typec: tcpm: Set USB role switch to device mode when configured
as such
usb: typec: tcpm: Use new Type-C switch/mux and usb-role-switch
functions
xhci: Add Intel extended cap / otg phy mux handling
usb: roles: Add Intel xHCI USB role switch driver
usb: typec: driver for Pericom PI3USB30532 Type-C cross switch
platform/x86: intel_cht_int33fe: Add device connections for the Type-C
port
extcon: axp288: Set USB role where necessary
Heikki Krogerus (4):
drivers: base: Unified device connection lookup
usb: typec: API for controlling USB Type-C Multiplexers
usb: common: Small class for USB role switches
usb: typec: Separate the definitions for data and power roles
Mathias Nyman (1):
xhci: Add option to get next extended capability in list by passing id
= 0
Documentation/ABI/testing/sysfs-class-usb_role | 21 ++
Documentation/driver-api/device_connection.rst | 43
Documentation/driver-api/usb/typec.rst | 73 +-
MAINTAINERS| 12 +
drivers/base/Makefile | 3 +-
drivers/base/devcon.c | 141 +
usb 1-1.2: clear tt 1 (0050) error -7
Hello, I'm working with Proxmox... dmesg: [ 202.138960] usb 1-1.2: clear tt 1 (0050) error -71 [ 202.146341] usb 1-1.2-port4: cannot reset (err = -71) [ 202.150578] usb 1-1.2-port4: cannot reset (err = -71) [ 202.154828] usb 1-1.2-port4: cannot reset (err = -71) [ 202.159100] usb 1-1.2-port4: cannot reset (err = -71) [ 202.163328] usb 1-1.2-port4: cannot reset (err = -71) [ 202.163361] usb 1-1.2-port4: Cannot enable. Maybe the USB cable is bad? [ 202.167578] usb 1-1.2-port4: cannot disable (err = -71) [ 202.171828] usb 1-1.2-port4: cannot reset (err = -71) [ 202.176077] usb 1-1.2-port4: cannot reset (err = -71) [ 202.180326] usb 1-1.2-port4: cannot reset (err = -71) [ 202.184578] usb 1-1.2-port4: cannot reset (err = -71) [ 202.188828] usb 1-1.2-port4: cannot reset (err = -71) [ 202.188860] usb 1-1.2-port4: Cannot enable. Maybe the USB cable is bad? [ 202.193087] usb 1-1.2-port4: cannot disable (err = -71) [ 202.197329] usb 1-1.2-port4: cannot reset (err = -71) [ 202.201587] usb 1-1.2-port4: cannot reset (err = -71) [ 202.205830] usb 1-1.2-port4: cannot reset (err = -71) [ 202.209077] usb 1-1.2: USB disconnect, device number 3 [ 202.209080] usb 1-1.2.3: USB disconnect, device number 8 [ 202.210079] usb 1-1.2-port4: cannot reset (err = -71) [ 202.254480] usb 1-1.2.4: USB disconnect, device number 5 [ 202.370465] input: Chicony HP Elite USB Keyboard as /devices/pci:00/:00:1a.0/usb1/1-1/1-1.2/1-1.2.4/1-1.2.4:1.0/input/input13 [ 202.406336] input: failed to attach handler kbd to device input13, error: -5 [ 202.422338] sysrq: Failed to open input device, error -5 [ 202.442336] input: failed to attach handler sysrq to device input13, error: -5 [ 202.482335] input: failed to attach handler leds to device input13, error: -5 Regards, -- Cristian Aravena Romero (caravena) -- 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 v1 10/14] usb: dwc2: Add dwc2_enter_hibernation(), dwc2_exit_hibernation()
Hi,
Grigor Tovmasyan writes:
> On 3/12/2018 5:34 PM, Felipe Balbi wrote:
>>
>> Hi,
>>
>> Grigor Tovmasyan writes:
>>> One more thing.
>>>
>>> In "969d58abe57d usb: dwc2: Enable LPM" patch the author's (John Youn)
>>> Signed-off is missing.
>>>
>>> Could you please manually add his Signed-off ("Signed-off-by: John Youn
>>> ") or it's against rules?
>>
>> I need John to give me his S-o-B line, without it, I'll have to drop the
>> patch and, consequently, the rest of the series.
>>
>
> I have a call with him today. I will told him to give you his S-o-B line
> as soon as possible.
Thanks
--
balbi
signature.asc
Description: PGP signature
Re: Webcams not recognized on a Dell Latitude 5285 laptop
lsmod: Module Size Used by rfcomm 77824 4 cmac 16384 1 bnep 20480 2 wacom 106496 0 dell_rbtn 16384 0 nls_iso8859_1 16384 1 dell_laptop 20480 0 dcdbas 16384 0 arc4 16384 2 snd_hda_codec_hdmi 49152 1 dell_smm_hwmon 16384 0 snd_soc_skl 98304 0 snd_soc_skl_ipc 65536 1 snd_soc_skl intel_rapl 20480 0 x86_pkg_temp_thermal 16384 0 snd_hda_ext_core 24576 1 snd_soc_skl intel_powerclamp 16384 0 snd_soc_sst_dsp 32768 1 snd_soc_skl_ipc coretemp 16384 0 snd_soc_sst_ipc 16384 1 snd_soc_skl_ipc kvm_intel 163840 0 snd_hda_codec_realtek 94208 1 snd_soc_acpi 16384 1 snd_soc_skl snd_hda_codec_generic 73728 1 snd_hda_codec_realtek snd_soc_core 241664 1 snd_soc_skl kvm 598016 1 kvm_intel snd_compress 20480 1 snd_soc_core ac97_bus 16384 1 snd_soc_core snd_pcm_dmaengine 16384 1 snd_soc_core irqbypass 16384 1 kvm crct10dif_pclmul 16384 0 crc32_pclmul 16384 0 ghash_clmulni_intel 16384 0 pcbc 16384 0 aesni_intel 188416 2 aes_x86_64 20480 1 aesni_intel crypto_simd 16384 1 aesni_intel glue_helper 16384 1 aesni_intel cryptd 24576 3 crypto_simd,ghash_clmulni_intel,aesni_intel intel_cstate 20480 0 intel_rapl_perf 16384 0 iwlmvm 368640 0 serio_raw 16384 0 dell_wmi 16384 0 dell_smbios_wmi 16384 0 mac80211 778240 1 iwlmvm dell_smbios 16384 3 dell_wmi,dell_laptop,dell_smbios_wmi wmi_bmof 16384 0 dell_wmi_descriptor 16384 2 dell_wmi,dell_smbios_wmi iwlwifi 282624 1 iwlmvm snd_hda_intel 40960 6 snd_hda_codec 126976 4 snd_hda_intel,snd_hda_codec_hdmi,snd_hda_codec_generic,snd_hda_codec_realtek snd_hda_core 81920 7 snd_hda_intel,snd_hda_codec,snd_hda_ext_core,snd_soc_skl,snd_hda_codec_hdmi,snd_hda_codec_generic,snd_hda_codec_realtek snd_usb_audio 196608 0 snd_usbmidi_lib 32768 1 snd_usb_audio rtsx_pci_ms 20480 0 snd_hwdep 20480 2 snd_hda_codec,snd_usb_audio memstick 16384 1 rtsx_pci_ms snd_pcm 98304 9 snd_hda_intel,snd_hda_codec,snd_usb_audio,snd_pcm_dmaengine,snd_hda_ext_core,snd_hda_core,snd_soc_skl,snd_hda_codec_hdmi,snd_soc_core cfg80211 626688 3 iwlmvm,iwlwifi,mac80211 snd_seq_midi 16384 0 snd_seq_midi_event 16384 1 snd_seq_midi snd_rawmidi 32768 2 snd_seq_midi,snd_usbmidi_lib snd_seq 65536 2 snd_seq_midi_event,snd_seq_midi snd_seq_device 16384 3 snd_seq,snd_rawmidi,snd_seq_midi snd_timer 32768 2 snd_seq,snd_pcm joydev 20480 0 input_leds 16384 0 cdc_ether 16384 0 snd 81920 27 snd_compress,snd_hda_intel,snd_hwdep,snd_seq,snd_hda_codec,snd_usb_audio,snd_timer,snd_rawmidi,snd_hda_codec_hdmi,snd_hda_codec_generic,snd_usbmidi_lib,snd_seq_device,snd_hda_codec_realtek,snd_soc_core,snd_pcm usbnet 45056 1 cdc_ether uvcvideo 94208 0 r8152 61440 0 ti_usb_3410_5052 28672 0 hid_multitouch 20480 0 usbserial 45056 1 ti_usb_3410_5052 btusb 45056 0 videobuf2_vmalloc 16384 1 uvcvideo btrtl 16384 1 btusb btbcm 16384 1 btusb soundcore 16384 1 snd mii 16384 2 usbnet,r8152 btintel 20480 1 btusb bluetooth 544768 33 btrtl,btintel,bnep,btbcm,rfcomm,btusb idma64 20480 0 mei_me 40960 0 virt_dma 16384 1 idma64 shpchp 36864 0 mei 90112 1 mei_me ipu3_cio2 32768 0 ecdh_generic 24576 2 bluetooth v4l2_fwnode 20480 1 ipu3_cio2 videobuf2_dma_sg 16384 1 ipu3_cio2 videobuf2_memops 16384 2 videobuf2_dma_sg,videobuf2_vmalloc videobuf2_v4l2 24576 2 uvcvideo,ipu3_cio2 intel_lpss_pci 20480 0 videobuf2_common 40960 3 uvcvideo,ipu3_cio2,videobuf2_v4l2 hid_sensor_accel_3d 16384 1 hid_sensor_als 16384 1 hid_sensor_magn_3d 16384 1 hid_sensor_gyro_3d 16384 0 hid_sensor_rotation 16384 0 hid_sensor_incl_3d 16384 0 videodev 180224 5 v4l2_fwnode,uvcvideo,videobuf2_common,ipu3_cio2,videobuf2_v4l2 hid_sensor_trigger 16384 14 hid_sensor_incl_3d,hid_sensor_als,hid_sensor_accel_3d,hid_sensor_magn_3d,hid_sensor_gyro_3d,hid_sensor_rotation industrialio_triggered_buffer 16384 6 hid_sensor_incl_3d,hid_sensor_als,hid_sensor_accel_3d,hid_sensor_magn_3d,hid_sensor_gyro_3d,hid_sensor_rotation intel_pch_thermal 16384 0 kfifo_buf 16384 1 industrialio_triggered_buffer media 40960 3 uvcvideo,videodev,ipu3_cio2 hid_sensor_iio_common 16384 7 hid_sensor_incl_3d,hid_sensor_als,hid_sensor_accel_3d,hid_sensor_trigger,hid_sensor_magn_3d,hid_sensor_gyro_3d,hid_sensor_rotation industrialio 69632 12 hid_sensor_incl_3d,hid_sensor_als,hid_sensor_accel_3d,hid_sensor_trigger,hid_sensor_magn_3d,hid_sensor_gyro_3d,hid_sensor_rotation,industrialio_triggered_buffer,kfifo_buf processor_thermal_device 16384 0 intel_soc_dts_iosf 16384 1 processor_thermal_device soc_button_array 16384 0 int3403_thermal 16384 0 int340x_thermal_zone 16384 2 int3403_thermal,processor_thermal_device intel_vbtn 16384 0 intel_hid 16384 0 intel_lpss_acpi 16384 0 intel_lpss 16384 2 intel_lpss_pci,intel_lpss_acpi acpi_pad 180224 0 mac_hid 16384 0 sparse_keymap 16384 3 dell_wmi,intel_hid,intel_vbtn int3400_thermal 16384 0 tpm_crb 16384 0 acpi_thermal_rel 16384 1 int3400_thermal sch_fq_codel 20480 5 parport_pc 32768 0 ppdev 20480 0 lp 20480 0 parport 49152 3 lp,parport_pc,ppdev ip_tables 24576 0 x_tables 4096
Re: Webcams not recognized on a Dell Latitude 5285 laptop
Am Montag, den 12.03.2018, 11:58 +0100 schrieb Frédéric Parrenin : Hi, it looks like it just does not load. Can you post lsmod and lspci -vk? 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
Re: [PATCH v1 10/14] usb: dwc2: Add dwc2_enter_hibernation(), dwc2_exit_hibernation()
On 3/12/2018 5:34 PM, Felipe Balbi wrote:
>
> Hi,
>
> Grigor Tovmasyan writes:
>> One more thing.
>>
>> In "969d58abe57d usb: dwc2: Enable LPM" patch the author's (John Youn)
>> Signed-off is missing.
>>
>> Could you please manually add his Signed-off ("Signed-off-by: John Youn
>> ") or it's against rules?
>
> I need John to give me his S-o-B line, without it, I'll have to drop the
> patch and, consequently, the rest of the series.
>
I have a call with him today. I will told him to give you his S-o-B line
as soon as possible.
Thanks again.
--
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 v1 10/14] usb: dwc2: Add dwc2_enter_hibernation(), dwc2_exit_hibernation()
Hi,
Grigor Tovmasyan writes:
> One more thing.
>
> In "969d58abe57d usb: dwc2: Enable LPM" patch the author's (John Youn)
> Signed-off is missing.
>
> Could you please manually add his Signed-off ("Signed-off-by: John Youn
> ") or it's against rules?
I need John to give me his S-o-B line, without it, I'll have to drop the
patch and, consequently, the rest of the series.
--
balbi
signature.asc
Description: PGP signature
Re: [PATCH v1 10/14] usb: dwc2: Add dwc2_enter_hibernation(), dwc2_exit_hibernation()
One more thing.
In "969d58abe57d usb: dwc2: Enable LPM" patch the author's (John Youn)
Signed-off is missing.
Could you please manually add his Signed-off ("Signed-off-by: John Youn
") or it's against rules?
On 3/12/2018 5:07 PM, Felipe Balbi wrote:
>
> (no top-posting!!)
>
> Grigor Tovmasyan writes:
>> Hi,
>>
>> Yes. I'm verifying, it's okay.
>>
>> Sorry for inconvenience.
>
> thank you. I'll move the changes to 'next'.
>
--
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 v1 10/14] usb: dwc2: Add dwc2_enter_hibernation(), dwc2_exit_hibernation()
(no top-posting!!) Grigor Tovmasyan writes: > Hi, > > Yes. I'm verifying, it's okay. > > Sorry for inconvenience. thank you. I'll move the changes to 'next'. -- balbi signature.asc Description: PGP signature
Re: [PATCH v1 10/14] usb: dwc2: Add dwc2_enter_hibernation(), dwc2_exit_hibernation()
Hi, Yes. I'm verifying, it's okay. Sorry for inconvenience. Thanks, Grigor. On 3/12/2018 4:47 PM, Felipe Balbi wrote: > > (please avoid top-posting) > > Hi, > > Grigor Tovmasyan writes: >> Hi Balbi, >> >> Please also cherry-pick following commit from your 'testing/next' to >> 'tmp' right before 01/14. It will solve the problem. >> >> 969d58abe57d usb: dwc2: Enable LPM > > testing/next has been updated. Can you verify it's okay? > -- 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 v1 10/14] usb: dwc2: Add dwc2_enter_hibernation(), dwc2_exit_hibernation()
(please avoid top-posting) Hi, Grigor Tovmasyan writes: > Hi Balbi, > > Please also cherry-pick following commit from your 'testing/next' to > 'tmp' right before 01/14. It will solve the problem. > > 969d58abe57d usb: dwc2: Enable LPM testing/next has been updated. Can you verify it's okay? -- balbi signature.asc Description: PGP signature
Re: [PATCH v1 10/14] usb: dwc2: Add dwc2_enter_hibernation(), dwc2_exit_hibernation()
Hi Balbi,
Please also cherry-pick following commit from your 'testing/next' to
'tmp' right before 01/14. It will solve the problem.
969d58abe57d usb: dwc2: Enable LPM
On 3/12/2018 4:03 PM, Felipe Balbi wrote:
>
> Hi,
>
> Grigor Tovmasyan writes:
>> Hi Balbi,
>>
>> Did you tried to apply your patch of the top of your testing/next branch?
>>
>> If yes, could you please apply 01/14 ("[PATCH v1 01/14] usb: dwc2:
>> Rename hibernation to partial_power_down")
>> and 02/14 ([PATCH v1 02/14] usb: dwc2: Add hibernation field into
>> dwc2_hw_params) patches right before 03/14 ([PATCH v1 03/14] usb: dwc2:
>> gadget: Moved dtxfsiz backup array place).
>>
>> You can use "git rebase --interactive HEAD~10" command just adding
>> following lines starting with "x" in the top of opened file.
>>
>> x git apply <01/14 patch>
>> x git apply <02/14 patch>
>> pick 3d6c862d9361 usb: dwc2: gadget: Moved dtxfsiz backup array place
>
> if I do that, patch 6/14 won't apply anymore. I've pushed a 'tmp' branch
> to kernel.org with patches 1/14 - 5/14 on top of my 'next' branch. Now
> 6/14 doesn't apply to that.
>
--
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: High CPU load produced by USB (DW2)
Hi Paul, Nice to hear you again! Hope you are doing well. On 3/8/2018 1:51 PM, Paul Zimmerman wrote: > On 03/06/2018 09:09 AM, Minas Harutyunyan wrote: >> Hi, >> >> On 3/6/2018 10:45 AM, Minas Harutyunyan wrote: >>> Hi, >>> >>> On 3/5/2018 11:14 PM, Marek Vasut wrote: On 02/20/2018 06:51 AM, Minas Harutyunyan wrote: [...] Is there a way to reduce that or is that the absolute minimum in HS mode? >>> We already discussed, in this email thread earlier, why SOF interrupts >>> required and unmasked. >>> Only in case when connected device with CTRL+BLK EP's only (like flash >>> drive) and directly connected to cores root HUB, SOF's will be masked. >> >> That's the setup I have on Altera SoCFPGA, yet the SOFs are still >> present. >> > Could you please send verbose lsusb on connected to dwc2 device See attached > and driver debug log. What exactly do you mean by this one ? >>> Enable debugging messages and verbose debugging messages for dwc2 from >>> make menuconfig. Provide dmesg starting from dwc2 load till HS device >>> connected to dwc2 port and enumerated. >>> >>> Thanks, >>> Minas >>> >> Driver debug log not required. >> Based on lsusb output: to dwc2 port connected "Standard Microsystems >> Corp. USB 2.0 Hub" to which connected your HS device "SanDisk Corp. >> Ultra". Because of connected HUB, which have periodic endpoint >> (Interrupt IN EP1) like all HUB's, dwc2 forced in Buffer DMA mode unmask >> SOF interrupts. > > Hmm. It seems to me that for hubs, where the interrupt EP is only used to > poll for connection changes (so the accuracy of the polling interval is not > important), an OS timer could be used instead of enabling SOF interrupts. > > I have a Raspberry Pi 3 around here somewhere, maybe I'll dig it out and > try playing around with this idea. No promises though! > As I correctly understand, you suggest to mask SOF's and schedule in dwc2 timer with expiration time 125us*interval. Based on timer expiration get first urb from periodic queue and start transfer on Interrupt IN EPn. In this case interrupt count will be decreased by 'interval' times. But how you going to recognized inside dwc2 that this Interrupt IN EPn is HUB endpoint or not? Thanks, Minas -- 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 v1 10/14] usb: dwc2: Add dwc2_enter_hibernation(), dwc2_exit_hibernation()
Hi,
Grigor Tovmasyan writes:
> Hi Balbi,
>
> Did you tried to apply your patch of the top of your testing/next branch?
>
> If yes, could you please apply 01/14 ("[PATCH v1 01/14] usb: dwc2:
> Rename hibernation to partial_power_down")
> and 02/14 ([PATCH v1 02/14] usb: dwc2: Add hibernation field into
> dwc2_hw_params) patches right before 03/14 ([PATCH v1 03/14] usb: dwc2:
> gadget: Moved dtxfsiz backup array place).
>
> You can use "git rebase --interactive HEAD~10" command just adding
> following lines starting with "x" in the top of opened file.
>
> x git apply <01/14 patch>
> x git apply <02/14 patch>
> pick 3d6c862d9361 usb: dwc2: gadget: Moved dtxfsiz backup array place
if I do that, patch 6/14 won't apply anymore. I've pushed a 'tmp' branch
to kernel.org with patches 1/14 - 5/14 on top of my 'next' branch. Now
6/14 doesn't apply to that.
--
balbi
signature.asc
Description: PGP signature
[PATCH] staging: typec: modify parameter of tcpci_irq
From: ShuFan Lee
The parameter, dev_id, of tcpci_irq should be tcpci_chip.
Remove definition of TCPC_CC_STATUS_DRPRST in tcpci.h.
Fixes: 8f9439022648("staging: typec: handle vendor defined part and modify drp
toggling flow")
Signed-off-by: ShuFan Lee
Reviewed-by: Li Jun
Tested-by: Li Jun
---
drivers/staging/typec/tcpci.c | 4 ++--
drivers/staging/typec/tcpci.h | 1 -
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/typec/tcpci.c b/drivers/staging/typec/tcpci.c
index 804374056a1e..076d97eaff6f 100644
--- a/drivers/staging/typec/tcpci.c
+++ b/drivers/staging/typec/tcpci.c
@@ -451,9 +451,9 @@ irqreturn_t tcpci_irq(struct tcpci *tcpci)
static irqreturn_t _tcpci_irq(int irq, void *dev_id)
{
- struct tcpci *tcpci = dev_id;
+ struct tcpci_chip *chip = dev_id;
- return tcpci_irq(tcpci);
+ return tcpci_irq(chip->tcpci);
}
static const struct regmap_config tcpci_regmap_config = {
diff --git a/drivers/staging/typec/tcpci.h b/drivers/staging/typec/tcpci.h
index a2c1754ca222..34c865f0dcf6 100644
--- a/drivers/staging/typec/tcpci.h
+++ b/drivers/staging/typec/tcpci.h
@@ -59,7 +59,6 @@
#define TCPC_POWER_CTRL_VCONN_ENABLE BIT(0)
#define TCPC_CC_STATUS 0x1d
-#define TCPC_CC_STATUS_DRPRST BIT(5)
#define TCPC_CC_STATUS_TERMBIT(4)
#define TCPC_CC_STATUS_CC2_SHIFT 2
#define TCPC_CC_STATUS_CC2_MASK0x3
--
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
Re: [PATCH v1 10/14] usb: dwc2: Add dwc2_enter_hibernation(), dwc2_exit_hibernation()
Hi Balbi,
Did you tried to apply your patch of the top of your testing/next branch?
If yes, could you please apply 01/14 ("[PATCH v1 01/14] usb: dwc2:
Rename hibernation to partial_power_down")
and 02/14 ([PATCH v1 02/14] usb: dwc2: Add hibernation field into
dwc2_hw_params) patches right before 03/14 ([PATCH v1 03/14] usb: dwc2:
gadget: Moved dtxfsiz backup array place).
You can use "git rebase --interactive HEAD~10" command just adding
following lines starting with "x" in the top of opened file.
x git apply <01/14 patch>
x git apply <02/14 patch>
pick 3d6c862d9361 usb: dwc2: gadget: Moved dtxfsiz backup array place
On 3/12/2018 2:22 PM, Felipe Balbi wrote:
> Grigor Tovmasyan writes:
>
>> Hi Balbi,
>>
>> This patch didn't apply, because you missing 01/14 and 02/14 commits
>> from this patch seria.
>> Please apply following patches and try again.
>> [PATCH v1 01/14] usb: dwc2: Rename hibernation to partial_power_down
>> [PATCH v1 02/14] usb: dwc2: Add hibernation field into dwc2_hw_params
>
> right, and patch 1 doesn't apply:
>
> error: patch failed: drivers/usb/dwc2/core.h:1117
> error: drivers/usb/dwc2/core.h: patch does not apply
> error: patch failed: drivers/usb/dwc2/hcd.c:4378
> error: drivers/usb/dwc2/hcd.c: patch does not apply
> Applying: usb: dwc2: Rename hibernation to partial_power_down
> Patch failed at 0001 usb: dwc2: Rename hibernation to partial_power_down
> The copy of the patch that failed is found in: .git/rebase-apply/patch
> When you have resolved this problem, run "git am --continue".
> If you prefer to skip this patch, run "git am --skip" instead.
> To restore the original branch and stop patching, run "git am --abort".
>
--
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: Webcams not recognized on a Dell Latitude 5285 laptop
Thanks Oliver. Below is my dmesg. --- [0.00] Linux version 4.16.0-041600rc4-generic (kernel@gloin) (gcc version 7.2.0 (Ubuntu 7.2.0-8ubuntu3.2)) #201803041930 SMP Mon Mar 5 00:32:34 UTC 2018 [0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-4.16.0-041600rc4-generic root=UUID=a8f0bf7f-c112-468e-92ea-9595dd3c48c1 ro quiet splash vt.handoff=1 [0.00] KERNEL supported cpus: [0.00] Intel GenuineIntel [0.00] AMD AuthenticAMD [0.00] Centaur CentaurHauls [0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers' [0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers' [0.00] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers' [0.00] x86/fpu: Supporting XSAVE feature 0x008: 'MPX bounds registers' [0.00] x86/fpu: Supporting XSAVE feature 0x010: 'MPX CSR' [0.00] x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256 [0.00] x86/fpu: xstate_offset[3]: 832, xstate_sizes[3]: 64 [0.00] x86/fpu: xstate_offset[4]: 896, xstate_sizes[4]: 64 [0.00] x86/fpu: Enabled xstate features 0x1f, context size is 960 bytes, using 'compacted' format. [0.00] e820: BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x00057fff] usable [0.00] BIOS-e820: [mem 0x00058000-0x00058fff] reserved [0.00] BIOS-e820: [mem 0x00059000-0x0009efff] usable [0.00] BIOS-e820: [mem 0x0009f000-0x000f] reserved [0.00] BIOS-e820: [mem 0x0010-0x9eb94fff] usable [0.00] BIOS-e820: [mem 0x9eb95000-0x9eb95fff] ACPI NVS [0.00] BIOS-e820: [mem 0x9eb96000-0x9eb96fff] reserved [0.00] BIOS-e820: [mem 0x9eb97000-0xaa22efff] usable [0.00] BIOS-e820: [mem 0xaa22f000-0xaa5a5fff] reserved [0.00] BIOS-e820: [mem 0xaa5a6000-0xaa5ebfff] ACPI data [0.00] BIOS-e820: [mem 0xaa5ec000-0xaaf0] ACPI NVS [0.00] BIOS-e820: [mem 0xaaf1-0xab4f5fff] reserved [0.00] BIOS-e820: [mem 0xab4f6000-0xab5fefff] type 20 [0.00] BIOS-e820: [mem 0xab5ff000-0xab5f] usable [0.00] BIOS-e820: [mem 0xab60-0xaf7f] reserved [0.00] BIOS-e820: [mem 0xe000-0xefff] reserved [0.00] BIOS-e820: [mem 0xfe00-0xfe010fff] reserved [0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved [0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved [0.00] BIOS-e820: [mem 0xff00-0x] reserved [0.00] BIOS-e820: [mem 0x0001-0x00044e7f] usable [0.00] NX (Execute Disable) protection: active [0.00] efi: EFI v2.40 by American Megatrends [0.00] efi: ACPI=0xaa5b4000 ACPI 2.0=0xaa5b4000 SMBIOS=0xab33c000 SMBIOS 3.0=0xab33b000 ESRT=0xab2ab018 MPS=0xfcbd0 MEMATTR=0xa66ea018 [0.00] random: fast init done [0.00] SMBIOS 3.0.0 present. [0.00] DMI: Dell Inc. Latitude 5285/0P10Y3, BIOS 1.3.4 01/25/2018 [0.00] e820: update [mem 0x-0x0fff] usable ==> reserved [0.00] e820: remove [mem 0x000a-0x000f] usable [0.00] e820: last_pfn = 0x44e800 max_arch_pfn = 0x4 [0.00] MTRR default type: write-back [0.00] MTRR fixed ranges enabled: [0.00] 0-9 write-back [0.00] A-B uncachable [0.00] C-F write-protect [0.00] MTRR variable ranges enabled: [0.00] 0 base 00C000 mask 7FC000 uncachable [0.00] 1 base 00B000 mask 7FF000 uncachable [0.00] 2 base 00AE00 mask 7FFE00 uncachable [0.00] 3 base 00AD00 mask 7FFF00 uncachable [0.00] 4 disabled [0.00] 5 disabled [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 WP UC- WT [0.00] e820: last_pfn = 0xab600 max_arch_pfn = 0x4 [0.00] found SMP MP-table at [mem 0x000fce40-0x000fce4f] mapped at [(ptrval)] [0.00] esrt: Reserving ESRT space from 0xab2ab018 to 0xab2ab050. [0.00] Scanning 1 areas for low memory corruption [0.00] Base memory trampoline at [(ptrval)] 97000 size 24576 [0.00] Using GB pages for direct mapping [0.00] BRK [0x16034, 0x160340fff] PGTABLE [0.00] BRK [0x160341000, 0x160341fff] PGTABLE [0.00] BRK [0x160342000, 0x160342fff] PGTABLE [0.00] BRK [0x160343000, 0x160343fff] PGTABLE [0.00] BRK [0x160344000, 0x160344fff] PGTAB
Re: [PATCH] Fixes: 8f9439022648("staging: typec: modify parameter of tcpci_irq")
On Mon, Mar 12, 2018 at 07:26:07PM +0800, 李書帆 wrote:
> Hi Greg,
>
> 2018-03-12 19:07 GMT+08:00 Greg KH :
> > On Mon, Mar 12, 2018 at 05:46:42PM +0800, ShuFan Lee wrote:
> >> From: ShuFan Lee
> >
> > Your subject is odd, that line should be below, in the signed-off-by:
> > area, not as the subject of the patch :(
> >
> > Can you fix this up and resend?
> Yes.
> If I understand correctly, the title should be like
> staging: typec: modify parameter of tcpci_irq
> and the "Fixes" tag should be put in the signed-off-by area.
Correct.
> Should it be in the beginning of the area:
> Fixes: 8f9439022648("staging: typec: handle vendor defined part and
> modify drp toggling flow")
> Signed-off-by: xxx
>
> or the end of the area?
> Signed-off-by: xxx
> Fixes: 8f9439022648("staging: typec: handle vendor defined part and
> modify drp toggling flow")
Either is acceptable, but usually you see the first example here.
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: [PATCH] Fixes: 8f9439022648("staging: typec: modify parameter of tcpci_irq")
Hi Greg,
2018-03-12 19:07 GMT+08:00 Greg KH :
> On Mon, Mar 12, 2018 at 05:46:42PM +0800, ShuFan Lee wrote:
>> From: ShuFan Lee
>
> Your subject is odd, that line should be below, in the signed-off-by:
> area, not as the subject of the patch :(
>
> Can you fix this up and resend?
Yes.
If I understand correctly, the title should be like
staging: typec: modify parameter of tcpci_irq
and the "Fixes" tag should be put in the signed-off-by area.
Should it be in the beginning of the area:
Fixes: 8f9439022648("staging: typec: handle vendor defined part and
modify drp toggling flow")
Signed-off-by: xxx
or the end of the area?
Signed-off-by: xxx
Fixes: 8f9439022648("staging: typec: handle vendor defined part and
modify drp toggling flow")
>
> thanks,
>
> greg k-h
--
Best Regards,
書帆
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: BUG xhci_hcd usb3 module WARNS with JMicron JMS567 when writing to disk
Hello, I think its UAS: >From the dmesg: [ 652.335275] usb 1-1.3: Product: SABRENT [ 652.335279] usb 1-1.3: Manufacturer: SABRENT [ 652.335283] usb 1-1.3: SerialNumber: DB98765432123 [ 652.337283] scsi host8: uas [ 652.338731] scsi 8:0:0:0: Direct-Access SABRENT 4101 PQ: 0 ANSI: 6 SABRENT Is the HDD craddle. I have an external Toshiba HDD running on the same computer with the xhci_hcd driver for years without problems. But it reads: >>> usb-storage 4-1:1.0: USB Mass Storage device detected so i think its fundamentally different. Yes. data corruption ocurred when Oopsing. Like i said, i tried different HDDs and have two HDD Craddles to play with. all combinations brought the same result. Both craddles have SATA-USB3 chipsets from JMicrion. running on a USB2 chipset with the ehci driver works fine. Regards Tomas On Mon, Mar 12, 2018 at 6:52 AM, Oliver Neukum wrote: > Am Sonntag, den 11.03.2018, 10:48 -0300 schrieb Tomas M: >> Hello, >> >> I reported the bug here and was suggested to forward it to the ML. >> https://bugzilla.kernel.org/show_bug.cgi?id=199075 >> >> find attached the owed dmesg with the stack trace. >> >> using the ehci ports produces no error. >> using the xhci ports fails very fast when writing. >> >> this happens with the >> Bus 001 Device 005: ID 152d:0578 JMicron Technology Corp. / JMicron >> USA Technology Corp. JMS567 SATA 6Gb/s bridge >> >> and another similar chipset from JMicron too. >> >> I have another external USB3 drive using the xhci driver without problems. >> >> Regards > > UAS or storage? > > A CRC error is really unusual and an oops in RCU is arcane. > Do you have errors with other Super Speed devices? This looks > like data corruption. > > 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
Re: need UASP/UAS spec
Am Montag, den 12.03.2018, 12:09 +0530 schrieb Tushar Nimkar: > Hi, > Can u please help me in getting UAS spec.? > I have "UASP Revision 1.0" but which is very old. > > Want to understand what this "uas-tags"/ "initiator transfer tags" mean. > For only one case transfer (Command IU) it is 0x0002 rest case it is 0x0001 > > Please provide any link so that I can download spec. > Any help on "tags" is welcome. Hi, UAS in contrast to usb-storage can operate multiple SCSI commands at the same time. Therefore the host and the device must have a way to identify commands so that status and error reports can be attributed to the correct command. The way to do that is the tag, which is basically just a number the host assigns to a command. The range of tags you use is determined by the number of streams that are supported, so that each tag can be linked to a stream, meaning that data transfers are independent of each other. HTH 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
Re: Webcams not recognized on a Dell Latitude 5285 laptop
Am Sonntag, den 11.03.2018, 13:38 +0100 schrieb FRÉDÉRIC PARRENIN : > Dear Oliver and all, > > So I was expecting linux-4.16 to recognize my webcams, thanks to this new PCI > driver Oliver mentioned. > Therefore I installed 4.16-rc4. > Unfortunately, there is still no /dev/video* device > > Any idea what could be done to have these webcams working? Dmesg? Out of the mere fact of it not working we can draw little conclusion. 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
Re: [PATCH] Fixes: 8f9439022648("staging: typec: modify parameter of tcpci_irq")
On Mon, Mar 12, 2018 at 05:46:42PM +0800, ShuFan Lee wrote: > From: ShuFan Lee Your subject is odd, that line should be below, in the signed-off-by: area, not as the subject of the patch :( Can you fix this up and resend? 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: [PATCH] usb: typec: Separate the definitions for data and power roles
On Mon, Mar 12, 2018 at 10:27:19AM +0200, Heikki Krogerus wrote: > On Fri, Mar 09, 2018 at 09:41:38AM -0800, Greg Kroah-Hartman wrote: > > On Fri, Mar 09, 2018 at 02:09:18PM +0300, Heikki Krogerus wrote: > > > USB Type-C specification v1.2 separated the power and data > > > roles more clearly. Dual-Role-Data term was introduced, and > > > the meaning of DRP was changed from "Dual-Role-Port" to > > > "Dual-Role-Power". > > > > > > In order to allow the port drivers to describe the > > > capabilities of the ports more clearly according to the > > > newest specifications, introducing separate definitions for > > > the data roles. > > > > > > Signed-off-by: Heikki Krogerus > > > Reviewed-by: Guenter Roeck > > > --- > > > drivers/usb/typec/class.c | 56 > > > ++--- > > > > This file isn't in the tree, what tree/branch did you make this patch > > against? > > > > confused, > > The patch was made on top of the series we prepared with Hans for the > USB muxes [1], which I totally failed to point out. Sorry for that. > > Since we need one more round (v7) with those to make the API changes > you proposed to the device-connection support, I'll just add this > patch to that series. I hope that's okay. That would be fine, 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: [PATCH v5 1/6] dt-bindings: add bindings for USB physical connector
Andrezej, Why don't you have any of the USB maintainers in to/cc? Greg Kroah-Hartman (supporter:USB SUBSYSTEM) Felipe Balbi (maintainer:USB GADGET/PERIPHERAL SUBSYSTEM) On 12/03/18 09:02, Andrzej Hajda wrote: > On 09.03.2018 11:24, Roger Quadros wrote: >> Hi, >> >> On 27/02/18 09:11, Andrzej Hajda wrote: >>> These bindings allow to describe most known standard USB connectors >>> and it should be possible to extend it if necessary. >>> USB connectors, beside USB can be used to route other protocols, >>> for example UART, Audio, MHL. In such case every device passing data >>> through the connector should have appropriate graph bindings. >>> >>> Signed-off-by: Andrzej Hajda >>> --- >>> v4: >>> - improved 'type' description (Rob), >>> - improved description of 2nd example (Rob). >>> v3: >>> - removed MHL port (samsung connector will have separate bindings), >>> - added 2nd example for USB-C, >>> - improved formatting. >>> v2: >>> - moved connector type(A,B,C) to compatible string (Rob), >>> - renamed size property to type (Rob), >>> - changed type description to be less confusing (Laurent), >>> - removed vendor specific compatibles (implied by graph port number), >>> - added requirement of connector being a child of IC (Rob), >>> - removed max-mode (subtly suggested by Rob, it should be detected anyway >>> by USB Controller in runtime, downside is that device is not able to >>> report its real capabilities, maybe better would be to make it >>> optional(?)), >>> - assigned port numbers to data buses (Rob). >>> >>> Regards >>> Andrzej >>> --- >>> .../bindings/connector/usb-connector.txt | 75 >>> ++ >>> 1 file changed, 75 insertions(+) >>> create mode 100644 >>> Documentation/devicetree/bindings/connector/usb-connector.txt >>> >>> diff --git a/Documentation/devicetree/bindings/connector/usb-connector.txt >>> b/Documentation/devicetree/bindings/connector/usb-connector.txt >>> new file mode 100644 >>> index ..e1463f14af38 >>> --- /dev/null >>> +++ b/Documentation/devicetree/bindings/connector/usb-connector.txt Should this lie in bindings/usb/connector? >>> @@ -0,0 +1,75 @@ >>> +USB Connector >>> += >>> + >>> +USB connector node represents physical USB connector. It should be >>> +a child of USB interface controller. >>> + >>> +Required properties: >>> +- compatible: describes type of the connector, must be one of: >>> +"usb-a-connector", >>> +"usb-b-connector", >>> +"usb-c-connector". >> compatible should be just "usb-connector" >> >> Type should be a property >> >> type: type of usb connector "A", "B", "AB", "C" >> AB is for dual-role connectors. > > I have proposed such property (and size also) in my first RFC [1]. Rod > did not like it :) > > [1]: https://marc.info/?l=devicetree&m=150660411515233&w=2 > This is what Rob says here https://patchwork.kernel.org/patch/9976043/ "We did "type" for hdmi-connector, but I think I'd really prefer compatible be used to distinguish as least where it may matter to s/w. In the HDMI case, they all are pretty much the same, just different physical size." So the question is. Does it matter to this particular software implementation if it is type A,B,C connector? If yes, how? Type A will never have any alternate function. It is always dedicated to USB. Also does the size "full", "micro", "mini" matter to software? > >> >> micro super-speed and high-speed connectors are different. How do you >> differentiate that? > > I am aware of it, and property differentiating it was also in my earlier > iterations. > If there will be need to differentiate such connectors, adding property > max-speed or max-mode would do the thing. USB controller binding (bindings/usb/generic.txt) has the speed. I don't think there is any value for replicating it for the connector. Maybe it could be added later if needed. > >> >>> + >>> +Optional properties: >>> +- label: symbolic name for the connector, >> Why do you need label? We can't maintain consistency as people will put >> creative names there. >> Device/bus driver could generate a valid label. > > It follows convention for other connectors: HDMI, DVI, > >> >>> +- type: size of the connector, should be specified in case of USB-A, USB-B >>> + non-fullsize connectors: "mini", "micro". >> type is misleading. Type is usually A/B/C. It should be size here instead. > > As you can see in discussion for previous iterations it follows > convention already established for other connectors. > >> >> size: size of the connector if not standard size. "mini", "micro" >> >> If not specified it is treated as standard sized connector. >> e.g. for Type-C there is no mini/micro. so size doesn't have to be specificed > Few lines above it is described: should be specified in case of USB-A, > USB-B non-fullsize connectors. > >> >> What about Type-C connector? >>> + >>> +Required nodes: >>> +- any data bus to the connector should be modeled using the OF graph >>
Re: [PATCH 2/2] USB: serial: option: use mass-storage class define
On Wed, Mar 07, 2018 at 06:57:14AM -0800, Greg Kroah-Hartman wrote: > On Wed, Mar 07, 2018 at 11:49:56AM +0100, Johan Hovold wrote: > > Use the USB class define rather than a magic number when refusing to > > bind to mass-storage interfaces. > > > > Signed-off-by: Johan Hovold > > Reviewed-by: Greg Kroah-Hartman Thanks for reviewing. Both patches applied for -next. Johan -- 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: serial: option: reimplement interface masking
On Wed, Mar 07, 2018 at 11:54:47AM -0800, Greg Kroah-Hartman wrote:
> On Wed, Mar 07, 2018 at 05:40:48PM +0100, Johan Hovold wrote:
> > Reimplement interface masking using device flags stored directly in the
> > device-id table. This will make it easier to add and maintain device-id
> > entries by using a more compact and readable notation compared to the
> > current implementation (which manages pairs of masks in separate
> > blacklist structs).
> >
> > Two convenience macros are used to flag an interface as either reserved
> > or as not supporting modem-control requests:
> >
> > { USB_DEVICE(TELIT_VENDOR_ID, TELIT_PRODUCT_ME910_DUAL_MODEM),
> > .driver_info = NCTRL(0) | RSVD(3) },
> >
> > For now, we limit the highest maskable interface number to seven, which
> > allows for (up to 16) additional device flags to be added later should
> > need arise.
> >
> > Note that this will likely need to be backported to stable in order to
> > make future device-id backports more manageable.
> >
> > Signed-off-by: Johan Hovold
>
> Reviewed-by: Greg Kroah-Hartman
Thanks for the review. Now applied for -next.
Johan
--
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 v4 01/15] usb: dwc3: Add SoftReset PHY synchonization delay
Thinh Nguyen writes: > From DWC_usb31 programming guide section 1.3.2, once DWC3_DCTL_CSFTRST > bit is cleared, we must wait at least 50ms before accessing the PHY > domain (synchronization delay). > > Signed-off-by: Thinh Nguyen checking file drivers/usb/dwc3/core.c Hunk #1 FAILED at 228. 1 out of 1 hunk FAILED -- balbi signature.asc Description: PGP signature
Re: [PATCH v1 10/14] usb: dwc2: Add dwc2_enter_hibernation(), dwc2_exit_hibernation()
Grigor Tovmasyan writes: > Hi Balbi, > > This patch didn't apply, because you missing 01/14 and 02/14 commits > from this patch seria. > Please apply following patches and try again. > [PATCH v1 01/14] usb: dwc2: Rename hibernation to partial_power_down > [PATCH v1 02/14] usb: dwc2: Add hibernation field into dwc2_hw_params right, and patch 1 doesn't apply: error: patch failed: drivers/usb/dwc2/core.h:1117 error: drivers/usb/dwc2/core.h: patch does not apply error: patch failed: drivers/usb/dwc2/hcd.c:4378 error: drivers/usb/dwc2/hcd.c: patch does not apply Applying: usb: dwc2: Rename hibernation to partial_power_down Patch failed at 0001 usb: dwc2: Rename hibernation to partial_power_down The copy of the patch that failed is found in: .git/rebase-apply/patch When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". -- balbi signature.asc Description: PGP signature
Re: [PATCH 2/2] net/usb/ax88179_178a: Delete three unnecessary variables in ax88179_chk_eee()
Am Samstag, den 10.03.2018, 19:26 +0100 schrieb SF Markus Elfring: > From: Markus Elfring > Date: Sat, 10 Mar 2018 18:53:28 +0100 > > Use three values directly for a condition check without assigning them > to intermediate variables. Hi, what is the benefit of this? It looks like needless code churn to me. 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
[usb:usb-next 43/44] drivers/usb/core/quirks.c:135:9: error: implicit declaration of function 'param_set_copystring'
tree: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-next
head: 8f94390226487bcb86c554ddc12eef0d27bdec3b
commit: b27560e4d9e5240b5544c9c5650c7442e482646e [43/44] usb: core: Add
"quirks" parameter for usbcore
config: sparc64-allyesconfig (attached as .config)
compiler: sparc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout b27560e4d9e5240b5544c9c5650c7442e482646e
# save the attached .config to linux build tree
make.cross ARCH=sparc64
All error/warnings (new ones prefixed by >>):
>> drivers/usb/core/quirks.c:27:59: warning: 'struct kernel_param' declared
>> inside parameter list will not be visible outside of this definition or
>> declaration
static int quirks_param_set(const char *val, const struct kernel_param *kp)
^~~~
drivers/usb/core/quirks.c: In function 'quirks_param_set':
>> drivers/usb/core/quirks.c:135:9: error: implicit declaration of function
>> 'param_set_copystring' [-Werror=implicit-function-declaration]
return param_set_copystring(val, kp);
^~~~
drivers/usb/core/quirks.c: At top level:
>> drivers/usb/core/quirks.c:138:21: error: variable 'quirks_param_ops' has
>> initializer but incomplete type
static const struct kernel_param_ops quirks_param_ops = {
^~~~
>> drivers/usb/core/quirks.c:139:3: error: 'const struct kernel_param_ops' has
>> no member named 'set'
.set = quirks_param_set,
^~~
>> drivers/usb/core/quirks.c:139:9: warning: excess elements in struct
>> initializer
.set = quirks_param_set,
^~~~
drivers/usb/core/quirks.c:139:9: note: (near initialization for
'quirks_param_ops')
>> drivers/usb/core/quirks.c:140:3: error: 'const struct kernel_param_ops' has
>> no member named 'get'
.get = param_get_string,
^~~
>> drivers/usb/core/quirks.c:140:9: error: 'param_get_string' undeclared here
>> (not in a function); did you mean 'page_get_link'?
.get = param_get_string,
^~~~
page_get_link
drivers/usb/core/quirks.c:140:9: warning: excess elements in struct
initializer
drivers/usb/core/quirks.c:140:9: note: (near initialization for
'quirks_param_ops')
>> drivers/usb/core/quirks.c:143:15: error: variable 'quirks_param_string' has
>> initializer but incomplete type
static struct kparam_string quirks_param_string = {
^
>> drivers/usb/core/quirks.c:144:3: error: 'struct kparam_string' has no member
>> named 'maxlen'
.maxlen = sizeof(quirks_param),
^~
drivers/usb/core/quirks.c:144:12: warning: excess elements in struct
initializer
.maxlen = sizeof(quirks_param),
^~
drivers/usb/core/quirks.c:144:12: note: (near initialization for
'quirks_param_string')
>> drivers/usb/core/quirks.c:145:3: error: 'struct kparam_string' has no member
>> named 'string'
.string = quirks_param,
^~
drivers/usb/core/quirks.c:145:12: warning: excess elements in struct
initializer
.string = quirks_param,
^~~~
drivers/usb/core/quirks.c:145:12: note: (near initialization for
'quirks_param_string')
>> drivers/usb/core/quirks.c:148:25: error: expected ')' before '&' token
module_param_cb(quirks, &quirks_param_ops, &quirks_param_string, 0644);
^
>> drivers/usb/core/quirks.c:149:26: error: expected ')' before string constant
MODULE_PARM_DESC(quirks, "Add/modify USB quirks by specifying
quirks=vendorID:productID:quirks");
^~
>> drivers/usb/core/quirks.c:138:38: error: storage size of 'quirks_param_ops'
>> isn't known
static const struct kernel_param_ops quirks_param_ops = {
^~~~
>> drivers/usb/core/quirks.c:143:29: error: storage size of
>> 'quirks_param_string' isn't known
static struct kparam_string quirks_param_string = {
^~~
drivers/usb/core/quirks.c:143:29: warning: 'quirks_param_string' defined but
not used [-Wunused-variable]
cc1: some warnings being treated as errors
vim +/param_set_copystring +135 drivers/usb/core/quirks.c
26
> 27 static int quirks_param_set(const char *val, const struct kernel_param
*kp)
28 {
29 char *p, *field;
30 u16 vid, pid;
31 u32 flags;
32 size_t i;
33
34 mutex_lock(&quirk_mutex);
35
36 if (!val || !*val) {
37 quirk_count = 0;
38 kfree(quirk_list);
39 quirk_list = NULL;
40
Re: BUG xhci_hcd usb3 module WARNS with JMicron JMS567 when writing to disk
Am Sonntag, den 11.03.2018, 10:48 -0300 schrieb Tomas M: > Hello, > > I reported the bug here and was suggested to forward it to the ML. > https://bugzilla.kernel.org/show_bug.cgi?id=199075 > > find attached the owed dmesg with the stack trace. > > using the ehci ports produces no error. > using the xhci ports fails very fast when writing. > > this happens with the > Bus 001 Device 005: ID 152d:0578 JMicron Technology Corp. / JMicron > USA Technology Corp. JMS567 SATA 6Gb/s bridge > > and another similar chipset from JMicron too. > > I have another external USB3 drive using the xhci driver without problems. > > Regards UAS or storage? A CRC error is really unusual and an oops in RCU is arcane. Do you have errors with other Super Speed devices? This looks like data corruption. 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] Fixes: 8f9439022648("staging: typec: modify parameter of tcpci_irq")
From: ShuFan Lee
The parameter, dev_id, of tcpci_irq should be tcpci_chip.
Remove definition of TCPC_CC_STATUS_DRPRST in tcpci.h.
Signed-off-by: ShuFan Lee
Reviewed-by: Li Jun
Tested-by: Li Jun
---
drivers/staging/typec/tcpci.c | 4 ++--
drivers/staging/typec/tcpci.h | 1 -
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/typec/tcpci.c b/drivers/staging/typec/tcpci.c
index 804374056a1e..076d97eaff6f 100644
--- a/drivers/staging/typec/tcpci.c
+++ b/drivers/staging/typec/tcpci.c
@@ -451,9 +451,9 @@ irqreturn_t tcpci_irq(struct tcpci *tcpci)
static irqreturn_t _tcpci_irq(int irq, void *dev_id)
{
- struct tcpci *tcpci = dev_id;
+ struct tcpci_chip *chip = dev_id;
- return tcpci_irq(tcpci);
+ return tcpci_irq(chip->tcpci);
}
static const struct regmap_config tcpci_regmap_config = {
diff --git a/drivers/staging/typec/tcpci.h b/drivers/staging/typec/tcpci.h
index a2c1754ca222..34c865f0dcf6 100644
--- a/drivers/staging/typec/tcpci.h
+++ b/drivers/staging/typec/tcpci.h
@@ -59,7 +59,6 @@
#define TCPC_POWER_CTRL_VCONN_ENABLE BIT(0)
#define TCPC_CC_STATUS 0x1d
-#define TCPC_CC_STATUS_DRPRST BIT(5)
#define TCPC_CC_STATUS_TERMBIT(4)
#define TCPC_CC_STATUS_CC2_SHIFT 2
#define TCPC_CC_STATUS_CC2_MASK0x3
--
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
Re: [PATCH v6 01/12] drivers: base: Unified device connection lookup
On Mon, Mar 12, 2018 at 10:19:34AM +0100, Hans de Goede wrote: > > > I currently have significantly less bandwidth for this due to > > > personal circumstances, so if a new version of this patch-set > > > is necessary it would be great if you (Heikki) can do a v7. > > > > Sure thing. I'll prepare the v7. > > Great, thank you. Don't forget to squash in the 2 fixes from > fengguang...@intel.com . Ah, from build-bot! Good that you reminded, I would not have remembered those :-) Thanks, -- heikki -- 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] drivers: base: Unified device connection lookup
Hi, On 12-03-18 09:13, Heikki Krogerus wrote: On Sun, Mar 11, 2018 at 07:24:18PM +0100, Hans de Goede wrote: Hi all, On 09-03-18 18:53, Greg Kroah-Hartman wrote: On Fri, Mar 02, 2018 at 11:20:46AM +0100, Hans de Goede wrote: From: Heikki Krogerus Several frameworks - clk, gpio, phy, pmw, etc. - maintain lookup tables for describing connections and provide custom API for handling them. This introduces a single generic lookup table and API for the connections. The motivation for this commit is centralizing the connection lookup, but the goal is to ultimately extract the connection descriptions also from firmware by using the fwnode_graph_* functions and other mechanisms that are available. Signed-off-by: Heikki Krogerus Reviewed-by: Hans de Goede Reviewed-by: Andy Shevchenko Signed-off-by: Hans de Goede Sorry for the delay, just now reviewing this patch... The content is fine (if not scary for the obvious reason of passing around 'struct device' of different bus types, but ok...), but the api naming is "rough": Heikki, I think it is best if you answer Greg's remarks. FWIW I'm fine with the changes Greg proposes. Me too. I currently have significantly less bandwidth for this due to personal circumstances, so if a new version of this patch-set is necessary it would be great if you (Heikki) can do a v7. Sure thing. I'll prepare the v7. Great, thank you. Don't forget to squash in the 2 fixes from fengguang...@intel.com . Regards, Hans -- 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: need UASP/UAS spec
On Mon, Mar 12, 2018 at 12:09:31PM +0530, Tushar Nimkar wrote: > Hi, > Can u please help me in getting UAS spec.? > I have "UASP Revision 1.0" but which is very old. > > Want to understand what this "uas-tags"/ "initiator transfer tags" mean. > For only one case transfer (Command IU) it is 0x0002 rest case it is 0x0001 > > Please provide any link so that I can download spec. All public USB specs can be found at http://www.usb.org/developers/docs/ Hope this helps, 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: [PATCH v4 0/7] typec: tcpm: Add sink side support for PPS
On 09 March 2018 17:34, Greg Kroah-Hartman wrote: > On Tue, Jan 02, 2018 at 03:50:48PM +, Adam Thomson wrote: > > This patch set adds sink side support for the PPS feature introduced in the > > USB PD 3.0 specification. > > > > The source PPS supply is represented using the Power Supply framework to > > provide > > access and control APIs for dealing with it's operating voltage and current, > > and switching between a standard PDO and PPS APDO operation. During standard > PDO > > operation the voltage and current is read-only, but for APDO PPS these are > > writable as well to allow for control. > > > > It should be noted that the keepalive for PPS is not handled within TCPM. > > The > > expectation is that the external user will be required to ensure re-requests > > occur regularly to ensure PPS remains and the source does not hard reset. > > I've applied the first 3 patches now. Can you rebase and resend based > on the feedback so far? That's great. Thanks. Need to also rebase based on the patch 'Revert "typec: tcpm: Only request matching pdos"' as this impacts the APDO selection logic. This is on my TODO list and will try and deal with it ASAP, hopefully this week. -- 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: typec: Separate the definitions for data and power roles
On Fri, Mar 09, 2018 at 09:41:38AM -0800, Greg Kroah-Hartman wrote: > On Fri, Mar 09, 2018 at 02:09:18PM +0300, Heikki Krogerus wrote: > > USB Type-C specification v1.2 separated the power and data > > roles more clearly. Dual-Role-Data term was introduced, and > > the meaning of DRP was changed from "Dual-Role-Port" to > > "Dual-Role-Power". > > > > In order to allow the port drivers to describe the > > capabilities of the ports more clearly according to the > > newest specifications, introducing separate definitions for > > the data roles. > > > > Signed-off-by: Heikki Krogerus > > Reviewed-by: Guenter Roeck > > --- > > drivers/usb/typec/class.c | 56 > > ++--- > > This file isn't in the tree, what tree/branch did you make this patch > against? > > confused, The patch was made on top of the series we prepared with Hans for the USB muxes [1], which I totally failed to point out. Sorry for that. Since we need one more round (v7) with those to make the API changes you proposed to the device-connection support, I'll just add this patch to that series. I hope that's okay. [1] https://lkml.org/lkml/2018/3/2/340 Thanks, -- heikki -- 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] drivers: base: Unified device connection lookup
On Sun, Mar 11, 2018 at 07:24:18PM +0100, Hans de Goede wrote: > Hi all, > > On 09-03-18 18:53, Greg Kroah-Hartman wrote: > > On Fri, Mar 02, 2018 at 11:20:46AM +0100, Hans de Goede wrote: > > > From: Heikki Krogerus > > > > > > Several frameworks - clk, gpio, phy, pmw, etc. - maintain > > > lookup tables for describing connections and provide custom > > > API for handling them. This introduces a single generic > > > lookup table and API for the connections. > > > > > > The motivation for this commit is centralizing the > > > connection lookup, but the goal is to ultimately extract the > > > connection descriptions also from firmware by using the > > > fwnode_graph_* functions and other mechanisms that are > > > available. > > > > > > Signed-off-by: Heikki Krogerus > > > Reviewed-by: Hans de Goede > > > Reviewed-by: Andy Shevchenko > > > Signed-off-by: Hans de Goede > > > > Sorry for the delay, just now reviewing this patch... > > > > The content is fine (if not scary for the obvious reason of passing > > around 'struct device' of different bus types, but ok...), but the api > > naming is "rough": > > Heikki, I think it is best if you answer Greg's remarks. FWIW I'm > fine with the changes Greg proposes. Me too. > I currently have significantly less bandwidth for this due to > personal circumstances, so if a new version of this patch-set > is necessary it would be great if you (Heikki) can do a v7. Sure thing. I'll prepare the v7. Thanks, -- heikki -- 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 v7] staging: typec: handle vendor defined part and modify drp toggling flow
> -Original Message-
> From: 李書帆 [mailto:leechu...@gmail.com]
> Sent: 2018年3月12日 14:57
> To: Jun Li
> Cc: Greg Kroah-Hartman ;
> heikki.kroge...@linux.intel.com; li...@roeck-us.net; g...@kroah.com;
> shufan_...@richtek.com; cy_hu...@richtek.com;
> linux-ker...@vger.kernel.org; linux-usb@vger.kernel.org
> Subject: Re: [PATCH v7] staging: typec: handle vendor defined part and modify
> drp toggling flow
>
> Hi Jun,
>
> 2018-03-12 13:58 GMT+08:00 Jun Li :
> > Hi
> >> -Original Message-
> >> From: 李書帆 [mailto:leechu...@gmail.com]
> >> Sent: 2018年3月12日 13:22
> >> To: Jun Li
> >> Cc: Greg Kroah-Hartman ;
> >> heikki.kroge...@linux.intel.com; li...@roeck-us.net; g...@kroah.com;
> >> shufan_...@richtek.com; cy_hu...@richtek.com;
> >> linux-ker...@vger.kernel.org; linux-usb@vger.kernel.org
> >> Subject: Re: [PATCH v7] staging: typec: handle vendor defined part
> >> and modify drp toggling flow
> >>
> >> Hi Jun,
> >>
> >> Thank you.
> >>
> >> 2018-03-12 12:33 GMT+08:00 Jun Li :
> >> > Hi,
> >> >
> >> >> +static irqreturn_t _tcpci_irq(int irq, void *dev_id) {
> >> >> + struct tcpci *tcpci = dev_id;
> >> >> +
> >> >> + return tcpci_irq(tcpci);
> >> >> +}
> >> >>
> >> > ...
> >> >
> >> >> + err = devm_request_threaded_irq(&client->dev, client->irq, NULL,
> >> >> + _tcpci_irq,
> >> >> IRQF_ONESHOT |
> >> IRQF_TRIGGER_LOW,
> >> >> - dev_name(tcpci->dev),
> tcpci);
> >> >> + dev_name(&client->dev),
> >> >> + chip);
> >> >
> >> > - dev_name(&client->dev), chip);
> >> > + dev_name(&client->dev), chip->tcpci);
> >> >
> >> > Did you ever test this patch?
> >> I've tested this patch with tcpci_rt1711h.c that will be sent out for
> >> reviewing in the next patch after tcpci's modification is passed.
> >> Because interrupt handler is registered in tcpci_rt1711h.c, here is
> >> the place I didn't notice.
> >
> > Understood.
> >
> >> The interrupt handler for tcpci.c should be modified as following:
> >> static irqreturn_t _tcpci_irq(int irq, void *dev_id) {
> >> - struct tcpci *tcpci = dev_id;
> >> + struct tcpci_chip *chip = dev_id;
> >>
> >> - return tcpci_irq(tcpci);
> >> + return tcpci_irq(chip->tcpci);
> >> }
> >>
> >
> > Either way is OK to fix it.
> > You may send out your v8 and notify Greg to drop your v7 version.
> >
> > Jun Li
>
> May I add you in the Reported-by list?
I just gave a run with your patch on my HW, so for your new version,
you can directly add:
Reviewed-by: Li Jun
Tested-by: Li Jun
>
> --
> Best Regards,
> 書帆
N�r��yb�X��ǧv�^�){.n�+{��^n�r���z���h�&�� �G���h�(�階�ݢj"���m��z�ޖ���f���h���~�m�
Re: [PATCH v5 1/6] dt-bindings: add bindings for USB physical connector
On 12.03.2018 08:02, Andrzej Hajda wrote:
> On 09.03.2018 11:24, Roger Quadros wrote:
>> Hi,
>>
>> On 27/02/18 09:11, Andrzej Hajda wrote:
>>> These bindings allow to describe most known standard USB connectors
>>> and it should be possible to extend it if necessary.
>>> USB connectors, beside USB can be used to route other protocols,
>>> for example UART, Audio, MHL. In such case every device passing data
>>> through the connector should have appropriate graph bindings.
>>>
>>> Signed-off-by: Andrzej Hajda
>>> ---
>>> v4:
>>> - improved 'type' description (Rob),
>>> - improved description of 2nd example (Rob).
>>> v3:
>>> - removed MHL port (samsung connector will have separate bindings),
>>> - added 2nd example for USB-C,
>>> - improved formatting.
>>> v2:
>>> - moved connector type(A,B,C) to compatible string (Rob),
>>> - renamed size property to type (Rob),
>>> - changed type description to be less confusing (Laurent),
>>> - removed vendor specific compatibles (implied by graph port number),
>>> - added requirement of connector being a child of IC (Rob),
>>> - removed max-mode (subtly suggested by Rob, it should be detected anyway
>>> by USB Controller in runtime, downside is that device is not able to
>>> report its real capabilities, maybe better would be to make it
>>> optional(?)),
>>> - assigned port numbers to data buses (Rob).
>>>
>>> Regards
>>> Andrzej
>>> ---
>>> .../bindings/connector/usb-connector.txt | 75
>>> ++
>>> 1 file changed, 75 insertions(+)
>>> create mode 100644
>>> Documentation/devicetree/bindings/connector/usb-connector.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/connector/usb-connector.txt
>>> b/Documentation/devicetree/bindings/connector/usb-connector.txt
>>> new file mode 100644
>>> index ..e1463f14af38
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/connector/usb-connector.txt
>>> @@ -0,0 +1,75 @@
>>> +USB Connector
>>> +=
>>> +
>>> +USB connector node represents physical USB connector. It should be
>>> +a child of USB interface controller.
>>> +
>>> +Required properties:
>>> +- compatible: describes type of the connector, must be one of:
>>> +"usb-a-connector",
>>> +"usb-b-connector",
>>> +"usb-c-connector".
>> compatible should be just "usb-connector"
>>
>> Type should be a property
>>
>> type: type of usb connector "A", "B", "AB", "C"
>> AB is for dual-role connectors.
> I have proposed such property (and size also) in my first RFC [1]. Rod
> did not like it :)
Ups, ugly typo, I meant Rob, of course.
Regards
Andrzej
>
> [1]: https://marc.info/?l=devicetree&m=150660411515233&w=2
>
>
>> micro super-speed and high-speed connectors are different. How do you
>> differentiate that?
> I am aware of it, and property differentiating it was also in my earlier
> iterations.
> If there will be need to differentiate such connectors, adding property
> max-speed or max-mode would do the thing.
>
>>> +
>>> +Optional properties:
>>> +- label: symbolic name for the connector,
>> Why do you need label? We can't maintain consistency as people will put
>> creative names there.
>> Device/bus driver could generate a valid label.
> It follows convention for other connectors: HDMI, DVI,
>
>>> +- type: size of the connector, should be specified in case of USB-A, USB-B
>>> + non-fullsize connectors: "mini", "micro".
>> type is misleading. Type is usually A/B/C. It should be size here instead.
> As you can see in discussion for previous iterations it follows
> convention already established for other connectors.
>
>> size: size of the connector if not standard size. "mini", "micro"
>>
>> If not specified it is treated as standard sized connector.
>> e.g. for Type-C there is no mini/micro. so size doesn't have to be specificed
> Few lines above it is described: should be specified in case of USB-A,
> USB-B non-fullsize connectors.
>
>> What about Type-C connector?
>>> +
>>> +Required nodes:
>>> +- any data bus to the connector should be modeled using the OF graph
>>> bindings
>> s/modeled/modelled
>>> + specified in bindings/graph.txt, unless the bus is between parent node
>>> and
>>> + the connector. Since single connector can have multpile data buses every
>>> bus
>> s/multpile/multiple
> OK, I will fix both typos.
>
>>> + has assigned OF graph port number as follows:
>>> +0: High Speed (HS), present in all connectors,
>>> +1: Super Speed (SS), present in SS capable connectors,
>>> +2: Sideband use (SBU), present in USB-C.
>>> +
>>> +Examples
>>> +
>>> +
>>> +1. Micro-USB connector with HS lines routed via controller (MUIC):
>>> +
>>> +muic-max77843@66 {
>>> + ...
>>> + usb_con: connector {
>>> + compatible = "usb-b-connector";
>>> + label = "micro-USB";
>>> + type = "micro";
>>> + };
>>> +};
>>> +
>>> +2. USB-C connector attached to CC controller (s2mm005), HS lines routed
>>> +to companion PMIC (max77865), SS lines to
Re: [PATCH v5 1/6] dt-bindings: add bindings for USB physical connector
On 09.03.2018 11:24, Roger Quadros wrote:
> Hi,
>
> On 27/02/18 09:11, Andrzej Hajda wrote:
>> These bindings allow to describe most known standard USB connectors
>> and it should be possible to extend it if necessary.
>> USB connectors, beside USB can be used to route other protocols,
>> for example UART, Audio, MHL. In such case every device passing data
>> through the connector should have appropriate graph bindings.
>>
>> Signed-off-by: Andrzej Hajda
>> ---
>> v4:
>> - improved 'type' description (Rob),
>> - improved description of 2nd example (Rob).
>> v3:
>> - removed MHL port (samsung connector will have separate bindings),
>> - added 2nd example for USB-C,
>> - improved formatting.
>> v2:
>> - moved connector type(A,B,C) to compatible string (Rob),
>> - renamed size property to type (Rob),
>> - changed type description to be less confusing (Laurent),
>> - removed vendor specific compatibles (implied by graph port number),
>> - added requirement of connector being a child of IC (Rob),
>> - removed max-mode (subtly suggested by Rob, it should be detected anyway
>> by USB Controller in runtime, downside is that device is not able to
>> report its real capabilities, maybe better would be to make it
>> optional(?)),
>> - assigned port numbers to data buses (Rob).
>>
>> Regards
>> Andrzej
>> ---
>> .../bindings/connector/usb-connector.txt | 75
>> ++
>> 1 file changed, 75 insertions(+)
>> create mode 100644
>> Documentation/devicetree/bindings/connector/usb-connector.txt
>>
>> diff --git a/Documentation/devicetree/bindings/connector/usb-connector.txt
>> b/Documentation/devicetree/bindings/connector/usb-connector.txt
>> new file mode 100644
>> index ..e1463f14af38
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/connector/usb-connector.txt
>> @@ -0,0 +1,75 @@
>> +USB Connector
>> +=
>> +
>> +USB connector node represents physical USB connector. It should be
>> +a child of USB interface controller.
>> +
>> +Required properties:
>> +- compatible: describes type of the connector, must be one of:
>> +"usb-a-connector",
>> +"usb-b-connector",
>> +"usb-c-connector".
> compatible should be just "usb-connector"
>
> Type should be a property
>
> type: type of usb connector "A", "B", "AB", "C"
> AB is for dual-role connectors.
I have proposed such property (and size also) in my first RFC [1]. Rod
did not like it :)
[1]: https://marc.info/?l=devicetree&m=150660411515233&w=2
>
> micro super-speed and high-speed connectors are different. How do you
> differentiate that?
I am aware of it, and property differentiating it was also in my earlier
iterations.
If there will be need to differentiate such connectors, adding property
max-speed or max-mode would do the thing.
>
>> +
>> +Optional properties:
>> +- label: symbolic name for the connector,
> Why do you need label? We can't maintain consistency as people will put
> creative names there.
> Device/bus driver could generate a valid label.
It follows convention for other connectors: HDMI, DVI,
>
>> +- type: size of the connector, should be specified in case of USB-A, USB-B
>> + non-fullsize connectors: "mini", "micro".
> type is misleading. Type is usually A/B/C. It should be size here instead.
As you can see in discussion for previous iterations it follows
convention already established for other connectors.
>
> size: size of the connector if not standard size. "mini", "micro"
>
> If not specified it is treated as standard sized connector.
> e.g. for Type-C there is no mini/micro. so size doesn't have to be specificed
Few lines above it is described: should be specified in case of USB-A,
USB-B non-fullsize connectors.
>
> What about Type-C connector?
>> +
>> +Required nodes:
>> +- any data bus to the connector should be modeled using the OF graph
>> bindings
> s/modeled/modelled
>> + specified in bindings/graph.txt, unless the bus is between parent node and
>> + the connector. Since single connector can have multpile data buses every
>> bus
> s/multpile/multiple
OK, I will fix both typos.
>
>> + has assigned OF graph port number as follows:
>> +0: High Speed (HS), present in all connectors,
>> +1: Super Speed (SS), present in SS capable connectors,
>> +2: Sideband use (SBU), present in USB-C.
>> +
>> +Examples
>> +
>> +
>> +1. Micro-USB connector with HS lines routed via controller (MUIC):
>> +
>> +muic-max77843@66 {
>> +...
>> +usb_con: connector {
>> +compatible = "usb-b-connector";
>> +label = "micro-USB";
>> +type = "micro";
>> +};
>> +};
>> +
>> +2. USB-C connector attached to CC controller (s2mm005), HS lines routed
>> +to companion PMIC (max77865), SS lines to USB3 PHY and SBU to DisplayPort.
>> +DisplayPort video lines are routed to the connector via SS mux in USB3 PHY.
>> +
>> +ccic: s2mm005@33 {
>> +...
>> +usb_con: connector {
>> +compatible = "usb-c-connector
