[PATCH 2/2] usb: dwc3: gadget: disable automatic calculation of ACK TP NUMP
Now that we calculate DCFG.NUMP, we can disable dwc3's automatic calculation so we maximize our chances of very high throughtput through the use of bursts. Signed-off-by: Felipe Balbi --- drivers/usb/dwc3/core.h | 5 + drivers/usb/dwc3/gadget.c | 11 +++ 2 files changed, 16 insertions(+) diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h index c5f576aa1903..186a8868829f 100644 --- a/drivers/usb/dwc3/core.h +++ b/drivers/usb/dwc3/core.h @@ -165,6 +165,11 @@ #define DWC3_DESCFETCHQ13 #define DWC3_EVENTQ15 +/* Global RX Threshold Configuration Register */ +#define DWC3_GRXTHRCFG_MAXRXBURSTSIZE(n) (((n) & 0x1f) << 19) +#define DWC3_GRXTHRCFG_RXPKTCNT(n) (((n) & 0xf) << 24) +#define DWC3_GRXTHRCFG_PKTCNTSEL (1 << 29) + /* Global Configuration Register */ #define DWC3_GCTL_PWRDNSCALE(n)((n) << 19) #define DWC3_GCTL_U2RSTECN (1 << 16) diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c index 4b681b0d420f..c3b0d01e1960 100644 --- a/drivers/usb/dwc3/gadget.c +++ b/drivers/usb/dwc3/gadget.c @@ -1669,6 +1669,17 @@ static int dwc3_gadget_start(struct usb_gadget *g, } dwc3_writel(dwc->regs, DWC3_DCFG, reg); + /* +* We are telling dwc3 that we want to use DCFG.NUMP as ACK TP's NUMP +* field instead of letting dwc3 itself calculate that automatically. +* +* This way, we maximize the chances that we'll be able to get several +* bursts of data without going through any sort of endpoint throttling. +*/ + reg = dwc3_readl(dwc->regs, DWC3_GRXTHRCFG); + reg &= ~DWC3_GRXTHRCFG_PKTCNTSEL; + dwc3_writel(dwc->regs, DWC3_GRXTHRCFG, reg); + /* Start with SuperSpeed Default */ dwc3_gadget_ep0_desc.wMaxPacketSize = cpu_to_le16(512); -- 2.8.1 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] usb: dwc3: gadget: update DCFG.NumP to max burst size
NumP field of DCFG register is used on NumP field of
ACK TP header and it tells the host how many packets
an endpoint can receive before waiting for
synchronization.
Documentation says it should be set to anything
<=bMaxBurst. Interestingly, however, this setting is
not per-endpoint how it should be (different
endpoints could have different burst sizes), but
things seem to work okay right now.
Signed-off-by: Felipe Balbi
---
drivers/usb/dwc3/core.h | 3 +++
drivers/usb/dwc3/gadget.c | 14 --
2 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 87df6dd20d23..c5f576aa1903 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -271,6 +271,9 @@
#define DWC3_DCFG_LOWSPEED (2 << 0)
#define DWC3_DCFG_FULLSPEED1 (3 << 0)
+#define DWC3_DCFG_NUMP_SHIFT 17
+#define DWC3_DCFG_NUMP(n) (((n) & 0x1f) >> DWC3_DCFG_NUMP_SHIFT)
+#define DWC3_DCFG_NUMP_MASK(0x1f << DWC3_DCFG_NUMP_SHIFT)
#define DWC3_DCFG_LPM_CAP (1 << 22)
/* Device Control Register */
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 43efb627d1cf..4b681b0d420f 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -464,9 +464,19 @@ static int dwc3_gadget_set_ep_config(struct dwc3 *dwc,
struct dwc3_ep *dep,
/* Burst size is only needed in SuperSpeed mode */
if (dwc->gadget.speed >= USB_SPEED_SUPER) {
- u32 burst = dep->endpoint.maxburst - 1;
+ u32 burst = dep->endpoint.maxburst;
+ u32 nump;
+ u32 reg;
- params.param0 |= DWC3_DEPCFG_BURST_SIZE(burst);
+ /* update NumP */
+ reg = dwc3_readl(dwc->regs, DWC3_DCFG);
+ nump = DWC3_DCFG_NUMP(reg);
+ nump = max(nump, burst);
+ reg &= ~DWC3_DCFG_NUMP_MASK;
+ reg |= nump << DWC3_DCFG_NUMP_SHIFT;
+ dwc3_writel(dwc->regs, DWC3_DCFG, reg);
+
+ params.param0 |= DWC3_DEPCFG_BURST_SIZE(burst - 1);
}
if (ignore)
--
2.8.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 07/12] usb: otg: add OTG/dual-role core
On 28/04/16 04:54, Peter Chen wrote:
> On Wed, Apr 27, 2016 at 01:59:44PM +0300, Roger Quadros wrote:
>> Hi,
>>
>> On 27/04/16 06:15, Peter Chen wrote:
>>> On Tue, Apr 26, 2016 at 04:21:07PM +0800, Peter Chen wrote:
On Tue, Apr 26, 2016 at 07:00:22AM +, Jun Li wrote:
> Hi
>
>> -Original Message-
>> From: Peter Chen [mailto:hzpeterc...@gmail.com]
>> Sent: Tuesday, April 26, 2016 2:28 PM
>> To: Jun Li
>> Cc: Roger Quadros ; st...@rowland.harvard.edu;
>> ba...@kernel.org; gre...@linuxfoundation.org; peter.c...@freescale.com;
>> dan.j.willi...@intel.com; jun...@freescale.com;
>> mathias.ny...@linux.intel.com; t...@atomide.com; joao.pi...@synopsys.com;
>> abres...@chromium.org; r.bald...@samsung.com; linux-usb@vger.kernel.org;
>> linux-ker...@vger.kernel.org; linux-o...@vger.kernel.org
>> Subject: Re: [PATCH v6 07/12] usb: otg: add OTG/dual-role core
>>
>> On Tue, Apr 26, 2016 at 05:11:36AM +, Jun Li wrote:
>>> Hi
>>>
-Original Message-
From: Peter Chen [mailto:hzpeterc...@gmail.com]
Sent: Tuesday, April 26, 2016 11:47 AM
To: Jun Li
Cc: Roger Quadros ; st...@rowland.harvard.edu;
ba...@kernel.org; gre...@linuxfoundation.org;
peter.c...@freescale.com; dan.j.willi...@intel.com;
jun...@freescale.com; mathias.ny...@linux.intel.com;
t...@atomide.com; joao.pi...@synopsys.com; abres...@chromium.org;
r.bald...@samsung.com; linux-usb@vger.kernel.org;
linux-ker...@vger.kernel.org; linux-o...@vger.kernel.org
Subject: Re: [PATCH v6 07/12] usb: otg: add OTG/dual-role core
On Tue, Apr 26, 2016 at 02:07:56AM +, Jun Li wrote:
>> +struct usb_otg *usb_otg_register(struct device *dev,
>> + struct usb_otg_config *config) {
>> +struct usb_otg *otg;
>> +struct otg_wait_data *wait;
>> +int ret = 0;
>> +
>> +if (!dev || !config || !config->fsm_ops)
>> +return ERR_PTR(-EINVAL);
>> +
>> +/* already in list? */
>> +mutex_lock(&otg_list_mutex);
>> +if (usb_otg_get_data(dev)) {
>> +dev_err(dev, "otg: %s: device already in otg list\n",
>> +__func__);
>> +ret = -EINVAL;
>> +goto unlock;
>> +}
>> +
>> +/* allocate and add to list */
>> +otg = kzalloc(sizeof(*otg), GFP_KERNEL);
>> +if (!otg) {
>> +ret = -ENOMEM;
>> +goto unlock;
>> +}
>> +
>> +otg->dev = dev;
>> +otg->caps = config->otg_caps;
>> +
>> +if ((otg->caps->hnp_support || otg->caps->srp_support ||
>> + otg->caps->adp_support) && !config->otg_work)
>> +dev_info(dev, "otg: limiting to dual-role\n");
>
> dev_err, this should be an error.
The condition may be wrong, but it is an information to show that
current OTG is dual-role.
>>>
>>> This should not happen in any correct design, I even doubt if we
>>> should try to continue by "downgrade" it to be duel role, currently
>>> the only example user is dual role, so doing like this can't be tested
>>> by real case, this downgrade is not so easy like we image, at least
>>> for chipidea otg driver, simply replace a queue worker may not work,
>>> as we have much more difference between the 2 configs.
>>>
>>
>> Would you show more why chipidea can't work just replace the work item,
>> and see if anything we still can improve for this framework?
>
> In real OTG, we need enable AVV irq,
Enable and Handling AVV is platform stuff. In this framework, we are
focus on how otg device manages host and gadget together, and the state
machine when the related otg event occurs.
> but for duel role, nobody care/handle,
> there are much more resource required for OTG: timers, hnp polling,
> otg test device handling...
They are common things for fully OTG fsm, you can move them
to common code (In fact, hnp polling handling is already common code).
>
> with current design, chipidea driver can support real OTG with its own
> queue worker, or DRD with Roger's drd work item if config is correct.
>
> But improve something to work on a *wrong* config will make it complicated
> and does not make much sense IMO.
>
What does above "config" you mean?
If the configure is fully OTG, you can choose different state machine,
eg otg_statemachine, if you find it is hard for chipidea to use this
framework, just list the reason, and see if we can improve.
>>>
>>> Roger, after discussing with Jun off line
Re: [PATCH v2] xhci: Cleanup only when releasing primary hcd.
Hi Joe, On 27/04/16 23:41, Joe Lawrence wrote: > Hello Mathias, Roger, Gabriel > > I've been chasing strange MSI / legacy IRQ behavior from xHCI for a > couple days and wanted to report a few things that may be effected by > Gabriel's recent "xhci: Cleanup only when releasing primary hcd" patch > (more on this at the bottom). > > After 8c24d6d7b09d "usb: xhci: stop everything on the first call to > xhci_stop" (v4.3+), there exists a device removal window that can later > leak interrupts and other device resources ordinarily cleaned up by > xhci_stop. > > The quick summary is that if the xhci_handshake call from xhci_halt > fails, it will set xhci->xhc_state |= XHCI_STATE_HALTED. Later when the > device is removed, xhci_stop keys off the xhc_state and will exit early > if XHCI_STATE_HALTED is set. > > This manifested itself on my Stratus machine while running repeated > device hotplug removals at various timing intervals during > initialization (for example 3, 6 or 12 seconds after hotplug add). I > didn't grab a backtrace of xhci_halt, so I'm not exactly sure why it was > called after xhci_run, but note that it is not only called from > xhci_stop, but also xhci_handle_command_timeout and others. > > The result was that a later device initialization couldn't allocate its > MSI interrupts -- after much instrumentation I finally traced it back to > the previous initialization / removal failing to free the MSI irqs it > requested. > > Here's the relevent snippet from added trace logging. > (ftmod_ioboard_event and ioboard_bringdown are functions from an > out-of-tree PCI hotplug driver for Stratus hardware platforms. These > routines will call into PCI API to add or remove a set of PCI devices so > I left them here to help mark device lifetimes.) > > Last successful MSI allocation > == > > java-17858 [002] 3005.763238: ftmod_ioboard_event: adding > bus 03 > java-17858 [009] 3009.780359: usb_add_hcd: > request_irq(irq=10, desc(88085f41bba8), hcd(8808518e53d8)) return=0 > java-17858 [004] 3009.808979: usb_add_hcd: > request_irq(irq=11, desc(88085f41bef8), hcd(880482d992a8)) return=0 > java-17858 [008] 3009.828263: xhci_halt: > xhci(88083f5a8258) > java-17858 [008] 3009.828269: xhci_quiesce: > xhci(88083f5a8258) halted=1 > java-17858 [008] 3009.828273: xhci_quiesce: > xhci(88083f5a8258) cmd=0 > java-17858 [008] 3009.829614: xhci_setup_msix: > xhci=88083f5a8258 > java-17858 [008] 3009.829627: xhci_setup_msix: > xhci=88083f5a8258 Failed to enable MSI-X, ret=-22 > java-17858 [008] 3009.829635: xhci_run: > xhci=88083f5a8258 > java-17858 [008] 3009.830069: xhci_run: request_irq(119, > ...) MSI desc=88083ac32e68 ret=0 > java-17858 [007] 3010.009977: xhci_halt: > xhci(88083f5a8258) > > xhci_halt is called, perhaps from > xhci_handle_command_timeout? > > java-17858 [007] 3010.009985: xhci_quiesce: > xhci(88083f5a8258) halted=1 > java-17858 [007] 3010.009986: xhci_quiesce: > xhci(88083f5a8258) cmd= > > cmd = ~0, so the hardware is gone! subsequent > call to xhci_handshake will detect this and return > -ENODEV, xhci_halt will then set > xhci->xhc_state |= XHCI_STATE_HALTED > > java-17858 [007] d... 3010.010381: xhci_irq: > hcd(88083f5a8008)->irq=0 (depth=0, count=300, unhandled=0), status==~0 > > xhci_irq notices the missing hardware, too. > > java-17858 [007] 3010.014476: xhci_stop: > xhci(88083f5a8258)->xhc_state=2 > > xhci_stop is called and exits early because > (xhci->xhc_state & XHCI_STATE_HALTED) > Notice no entries for xhci_free_irq! > > java-17858 [007] 3010.029101: ftmod_ioboard_event: adding > bus 79 >kworker/u97:3-974 [009] 3013.264132: ioboard_bringdown: board 0 >kworker/u97:3-974 [009] 3013.264145: ioboard_bringdown: sbus=0, > removing bus 03 >kworker/u97:3-974 [005] 3016.551113: ioboard_bringdown: sbus=1, > bs->TopLevelBridge[sbus] = 0 >kworker/u97:3-974 [005] 3016.551119: ioboard_bringdown: sbus=2, > bs->TopLevelBridge[sbus] = 0 >kworker/u97:3-974 [005] 3016.551119: ioboard_bringdown: sbus=3, > bs->TopLevelBridge[sbus] = 0 >kworker/u97:3-974 [005] 3016.551119: ioboard_bringdown: sbus=4, > bs->TopLevelBridge[sbus] = 0 >kworker/u97:3-974 [005] 3016.551120: ioboard_bringdown: sbus=5, > bs->TopLevelBridge[sbus] = 0 >kworker/u97:3-974 [005] 3016.551120: ioboard_bringdown: sbus=6, > bs->TopLevelBridge[sbus] = 0 >kworker/u97:3-974 [005] 3016.551120: ioboard_bringdown: sbus=7, > bs->TopLevelBridge[sbus] = 0 >kworker/u97:3-974 [005] 3016.551120: ioboard_bringdown: sbus=8, >
Re: [PATCH v2] xhci: Cleanup only when releasing primary hcd.
Mathias,
On 22/04/16 21:00, Gabriel Krisman Bertazi wrote:
> Mathias Nyman writes:
>
>> Nice catch, and moving xhci_mem_cleanup() until second hcd (primary) is
>> removed is one way to solve it.
>
> Thank you and Roger for your suggestions!
>
>> But I don't think we should even try to handle the interrupt at this stage
>> anymore.
>> The host is already halted and normally the handler should not be called
>> anymore.
>>
>> How about handling interrupts for a halted host in the same way as a dying
>> host?
>> Does something like this work for your TI devices?
>
> I really liked your suggestions. In fact, I agree, we shouldn't be
> handling interrupts anymore at this stage of shutdown. Nevertheless, I
> still think it makes sense to refactor xhci_stop such that we don't trip
> on this again. We definitely shouldn't call xhci_mem_cleanup before
> releasing the primary hcd.
>
> I merged your suggestion to the patch below, how do you feel about this
> version?
>
> Thanks,
>
> -- >8 --
> Subject: [PATCH v2] xhci: Cleanup only when releasing primary hcd
>
> Under stress occasions some TI devices might not return early when
> reading the status register during the quirk invocation of xhci_irq made
> by usb_hcd_pci_remove. This means that instead of returning, we end up
> handling this interruption in the middle of a shutdown. Since
> xhci->event_ring has already been freed in xhci_mem_cleanup, we end up
> accessing freed memory, causing the Oops below.
>
> commit 8c24d6d7b09d ("usb: xhci: stop everything on the first call to
> xhci_stop") is the one that changed the instant in which we clean up the
> event queue when stopping a device. Before, we didn't call
> xhci_mem_cleanup at the first time xhci_stop is executed (for the shared
> HCD), instead, we only did it after the invocation for the primary HCD,
> much later at the removal path. The code flow for this oops looks like
> this:
>
> xhci_pci_remove()
> usb_remove_hcd(xhci->shared)
> xhci_stop(xhci->shared)
> xhci_halt()
> xhci_mem_cleanup(xhci); // Free the event_queue
> usb_hcd_pci_remove(primary)
> xhci_irq() // Access the event_queue if STS_EINT is set. Crash.
> xhci_stop()
> xhci_halt()
> // return early
>
> The fix modifies xhci_stop to only cleanup the xhci data when releasing
> the primary HCD. This way, we still have the event_queue configured
> when invoking xhci_irq. We still halt the device on the first call to
> xhci_stop, though.
>
> I could reproduce this issue several times on the mainline kernel by
> doing a bind-unbind stress test with a specific storage gadget attached.
> I also ran the same test over-night with my patch applied and didn't
> observe the issue anymore.
>
> [ 113.334124] Unable to handle kernel paging request for data at address
> 0x0028
> [ 113.335514] Faulting instruction address: 0xdd4f767c
> [ 113.336839] Oops: Kernel access of bad area, sig: 11 [#1]
> [ 113.338214] SMP NR_CPUS=1024 NUMA PowerNV
>
> [c00efe47ba90] c0720850 usb_hcd_irq+0x50/0x80
> [c00efe47bac0] c073d328 usb_hcd_pci_remove+0x68/0x1f0
> [c00efe47bb00] ddaf0128 xhci_pci_remove+0x78/0xb0
> [xhci_pci]
> [c00efe47bb30] c055cf70 pci_device_remove+0x70/0x110
> [c00efe47bb70] c061c6bc __device_release_driver+0xbc/0x190
> [c00efe47bba0] c061c7d0 device_release_driver+0x40/0x70
> [c00efe47bbd0] c0619510 unbind_store+0x120/0x150
> [c00efe47bc20] c06183c4 drv_attr_store+0x64/0xa0
> [c00efe47bc60] c039f1d0 sysfs_kf_write+0x80/0xb0
> [c00efe47bca0] c039e14c kernfs_fop_write+0x18c/0x1f0
> [c00efe47bcf0] c02e962c __vfs_write+0x6c/0x190
> [c00efe47bd90] c02eab40 vfs_write+0xc0/0x200
> [c00efe47bde0] c02ec85c SyS_write+0x6c/0x110
> [c00efe47be30] c0009260 system_call+0x38/0x108
>
> Signed-off-by: Gabriel Krisman Bertazi
> Cc: Roger Quadros
> Cc: j...@jms.id.au
> Cc: sta...@vger.kernel.org
> Reviewed-by: Roger Quadros
> ---
> drivers/usb/host/xhci-ring.c | 3 ++-
> drivers/usb/host/xhci.c | 27 +++
> 2 files changed, 17 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
> index 99b4ff4..447abaa 100644
> --- a/drivers/usb/host/xhci-ring.c
> +++ b/drivers/usb/host/xhci-ring.c
> @@ -2728,7 +2728,8 @@ hw_died:
> writel(irq_pending, &xhci->ir_set->irq_pending);
> }
>
> - if (xhci->xhc_state & XHCI_STATE_DYING) {
> + if (xhci->xhc_state & XHCI_STATE_DYING ||
> + xhci->xhc_state & XHCI_STATE_HALTED) {
> xhci_dbg(xhci, "xHCI dying, ignoring interrupt. "
> "Shouldn't IRQs be disabled?\n");
> /* Clear the event handler busy flag (RW1C);
> diff --git
Re: [PATCH v6 09/12] usb: gadget: udc: adapt to OTG core
Hi,
On 27/04/16 14:22, Roger Quadros wrote:
> On 26/04/16 03:07, Jun Li wrote:
>> Hi
>>
>>> -Original Message-
>>> From: Roger Quadros [mailto:rog...@ti.com]
>>> Sent: Monday, April 25, 2016 10:04 PM
>>> To: Jun Li ; st...@rowland.harvard.edu; ba...@kernel.org;
>>> gre...@linuxfoundation.org; peter.c...@freescale.com
>>> Cc: dan.j.willi...@intel.com; jun...@freescale.com;
>>> mathias.ny...@linux.intel.com; t...@atomide.com; joao.pi...@synopsys.com;
>>> abres...@chromium.org; r.bald...@samsung.com; linux-usb@vger.kernel.org;
>>> linux-ker...@vger.kernel.org; linux-o...@vger.kernel.org
>>> Subject: Re: [PATCH v6 09/12] usb: gadget: udc: adapt to OTG core
>>>
>>> Hi,
>>>
>>> On 21/04/16 09:38, Jun Li wrote:
Hi,
...
>
> /**
> + * usb_gadget_start - start the usb gadget controller and connect to
> +bus
> + * @gadget: the gadget device to start
> + *
> + * This is external API for use by OTG core.
> + *
> + * Start the usb device controller and connect to bus (enable pull).
> + */
> +static int usb_gadget_start(struct usb_gadget *gadget) {
> + int ret;
> + struct usb_udc *udc = NULL;
> +
> + dev_dbg(&gadget->dev, "%s\n", __func__);
> + mutex_lock(&udc_lock);
> + list_for_each_entry(udc, &udc_list, list)
> + if (udc->gadget == gadget)
> + goto found;
> +
> + dev_err(gadget->dev.parent, "%s: gadget not registered.\n",
> + __func__);
> + mutex_unlock(&udc_lock);
> + return -EINVAL;
> +
> +found:
> + ret = usb_gadget_udc_start(udc);
> + if (ret)
> + dev_err(&udc->dev, "USB Device Controller didn't start: %d\n",
> + ret);
> + else
> + usb_udc_connect_control(udc);
For drd, it's fine, but for real otg, gadget connect should be done by
loc_conn() instead of gadget start.
>>>
>>> It is upto the OTG state machine to call gadget_start() when it needs to
>>> connect to the bus (i.e. loc_conn()). I see no point in calling gadget
>>> start before.
>>>
>>> Do you see any issue in doing so?
>>
>> This is what OTG state machine does:
>> case OTG_STATE_B_PERIPHERAL:
>> otg_chrg_vbus(otg, 0);
>> otg_loc_sof(otg, 0);
>> otg_set_protocol(fsm, PROTO_GADGET);
>> otg_loc_conn(otg, 1);
>> break;
On second thoughts, after seen the OTG state machine.
otg_set_protocol(fsm, PROTO_GADGET); is always followed by otg_loc_conn(otg, 1);
And whenever protocol changes to anything other the PROTO_GADGET, we use
otg_loc_conn(otg, 0);
So otg_loc_conn seems redundant. Can we just get rid of it?
usb_gadget_start() implies that gadget controller starts up and enables pull.
usb_gadget_stop() implies that gadget controller disables pull and stops.
Can you please explain why just these 2 APIs are not sufficient for full OTG?
Do we want anything to happen between gadget controller start/stop and
pull on/off?
cheers,
-roger
>>
>> You intend to abstract something common in this api when start gadget,
>> which should be called by otg_set_protocol(fsm, PROTO_GADGET); and
>> drd_set_protocol(fsm, PROTO_GADGET); right?
>>
>> So you may move usb_udc_connect_control(IMO usb_gadget_connect()
>> is better)out of usb_gadget_start(), then for drd:
>>
>> case OTG_STATE_B_PERIPHERAL:
>> drd_set_protocol(fsm, PROTO_GADGET);
>> otg_drv_vbus(otg, 0);
>> usb_gadget_connect();
>
> OK. I understand now. I'll implement your suggestion. Thanks.
>
> cheers,
> -roger
>
> +
> + mutex_unlock(&udc_lock);
> +
> + return ret;
> +}
> +
> +/**
> + * usb_gadget_stop - disconnect from bus and stop the usb gadget
> + * @gadget: The gadget device we want to stop
> + *
> + * This is external API for use by OTG core.
> + *
> + * Disconnect from the bus (disable pull) and stop the
> + * gadget controller.
> + */
> +static int usb_gadget_stop(struct usb_gadget *gadget) {
> + struct usb_udc *udc = NULL;
> +
> + dev_dbg(&gadget->dev, "%s\n", __func__);
> + mutex_lock(&udc_lock);
> + list_for_each_entry(udc, &udc_list, list)
> + if (udc->gadget == gadget)
> + goto found;
> +
> + dev_err(gadget->dev.parent, "%s: gadget not registered.\n",
> + __func__);
> + mutex_unlock(&udc_lock);
> + return -EINVAL;
> +
> +found:
> + usb_gadget_disconnect(udc->gadget);
Likewise, gadget disconnect also should be done by loc_conn() instead
of gadget stop.
> + udc->driver->disconnect(udc->gadget);
> + usb_gadget_udc_stop(udc);
> + mutex_unlock(&udc_lock);
> +
> + return 0;
> +}
> +
Li Jun
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this li
[PATCH 1/1] usbip: fix NULL pointer dereference on errors
Fix NULL pointer dereference and obsolete comments forgotten when
usbip server was converted from an interface driver to a device driver.
Signed-off-by: Alexander Popov
---
drivers/usb/usbip/stub.h | 1 -
drivers/usb/usbip/stub_dev.c | 4 ++--
drivers/usb/usbip/stub_rx.c | 19 +++
drivers/usb/usbip/stub_tx.c | 6 +++---
4 files changed, 12 insertions(+), 18 deletions(-)
diff --git a/drivers/usb/usbip/stub.h b/drivers/usb/usbip/stub.h
index 266e2b0c..910f027 100644
--- a/drivers/usb/usbip/stub.h
+++ b/drivers/usb/usbip/stub.h
@@ -33,7 +33,6 @@
#define STUB_BUSID_ALLOC 3
struct stub_device {
- struct usb_interface *interface;
struct usb_device *udev;
struct usbip_device ud;
diff --git a/drivers/usb/usbip/stub_dev.c b/drivers/usb/usbip/stub_dev.c
index a3ec49b..47f99ef 100644
--- a/drivers/usb/usbip/stub_dev.c
+++ b/drivers/usb/usbip/stub_dev.c
@@ -219,7 +219,7 @@ static void stub_device_reset(struct usbip_device *ud)
dev_dbg(&udev->dev, "device reset");
- ret = usb_lock_device_for_reset(udev, sdev->interface);
+ ret = usb_lock_device_for_reset(udev, NULL);
if (ret < 0) {
dev_err(&udev->dev, "lock for reset\n");
spin_lock_irq(&ud->lock);
@@ -252,7 +252,7 @@ static void stub_device_unusable(struct usbip_device *ud)
/**
* stub_device_alloc - allocate a new stub_device struct
- * @interface: usb_interface of a new device
+ * @udev: usb_device of a new device
*
* Allocates and initializes a new stub_device struct.
*/
diff --git a/drivers/usb/usbip/stub_rx.c b/drivers/usb/usbip/stub_rx.c
index 00e475c..2df63e3 100644
--- a/drivers/usb/usbip/stub_rx.c
+++ b/drivers/usb/usbip/stub_rx.c
@@ -165,12 +165,7 @@ static int tweak_reset_device_cmd(struct urb *urb)
dev_info(&urb->dev->dev, "usb_queue_reset_device\n");
- /*
-* With the implementation of pre_reset and post_reset the driver no
-* longer unbinds. This allows the use of synchronous reset.
-*/
-
- if (usb_lock_device_for_reset(sdev->udev, sdev->interface) < 0) {
+ if (usb_lock_device_for_reset(sdev->udev, NULL) < 0) {
dev_err(&urb->dev->dev, "could not obtain lock to reset
device\n");
return 0;
}
@@ -321,7 +316,7 @@ static struct stub_priv *stub_priv_alloc(struct stub_device
*sdev,
priv = kmem_cache_zalloc(stub_priv_cache, GFP_ATOMIC);
if (!priv) {
- dev_err(&sdev->interface->dev, "alloc stub_priv\n");
+ dev_err(&sdev->udev->dev, "alloc stub_priv\n");
spin_unlock_irqrestore(&sdev->priv_lock, flags);
usbip_event_add(ud, SDEV_EVENT_ERROR_MALLOC);
return NULL;
@@ -352,7 +347,7 @@ static int get_pipe(struct stub_device *sdev, int epnum,
int dir)
else
ep = udev->ep_out[epnum & 0x7f];
if (!ep) {
- dev_err(&sdev->interface->dev, "no such endpoint?, %d\n",
+ dev_err(&sdev->udev->dev, "no such endpoint?, %d\n",
epnum);
BUG();
}
@@ -387,7 +382,7 @@ static int get_pipe(struct stub_device *sdev, int epnum,
int dir)
}
/* NOT REACHED */
- dev_err(&sdev->interface->dev, "get pipe, epnum %d\n", epnum);
+ dev_err(&sdev->udev->dev, "get pipe, epnum %d\n", epnum);
return 0;
}
@@ -466,7 +461,7 @@ static void stub_recv_cmd_submit(struct stub_device *sdev,
priv->urb = usb_alloc_urb(0, GFP_KERNEL);
if (!priv->urb) {
- dev_err(&sdev->interface->dev, "malloc urb\n");
+ dev_err(&udev->dev, "malloc urb\n");
usbip_event_add(ud, SDEV_EVENT_ERROR_MALLOC);
return;
}
@@ -486,7 +481,7 @@ static void stub_recv_cmd_submit(struct stub_device *sdev,
priv->urb->setup_packet = kmemdup(&pdu->u.cmd_submit.setup, 8,
GFP_KERNEL);
if (!priv->urb->setup_packet) {
- dev_err(&sdev->interface->dev, "allocate setup_packet\n");
+ dev_err(&udev->dev, "allocate setup_packet\n");
usbip_event_add(ud, SDEV_EVENT_ERROR_MALLOC);
return;
}
@@ -517,7 +512,7 @@ static void stub_recv_cmd_submit(struct stub_device *sdev,
usbip_dbg_stub_rx("submit urb ok, seqnum %u\n",
pdu->base.seqnum);
else {
- dev_err(&sdev->interface->dev, "submit_urb error, %d\n", ret);
+ dev_err(&udev->dev, "submit_urb error, %d\n", ret);
usbip_dump_header(pdu);
usbip_dump_urb(priv->urb);
diff --git a/drivers/usb/usbip/stub_tx.c b/drivers/usb/usbip/stub_tx.c
index dbcabc9..af1edad 100644
--- a/drivers/usb/usbip/stub_tx.c
+++ b/drivers/usb/usbip/stub_tx.c
@@ -229,7 +229,7 @@ static int stub_send_ret_submit(struct stub_device *sdev)
}
4.6.0-rc5: kmemleak around dev_pm_qos_constraints_allocate
Hi, anyone has ever seen this? [ 2477.001127] kmemleak: 8 new suspected memory leaks (see /sys/kernel/debug/kmemleak) [ 6249.251894] perf: interrupt took too long (2506 > 2500), lowering kernel.perf_event_max_sample_rate to 79800 [ 9951.944091] perf: interrupt took too long (3136 > 3132), lowering kernel.perf_event_max_sample_rate to 63700 [23076.002641] kmemleak: 1 new suspected memory leaks (see /sys/kernel/debug/kmemleak) [26110.058965] kmemleak: 4 new suspected memory leaks (see /sys/kernel/debug/kmemleak) [39760.167906] kmemleak: 1 new suspected memory leaks (see /sys/kernel/debug/kmemleak) # cat /sys/kernel/debug/kmemleak unreferenced object 0x88040b690008 (size 192): comm "kworker/0:2", pid 1899, jiffies 4294937814 (age 69683.180s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 10 00 69 0b 04 88 ff ff ..i. 10 00 69 0b 04 88 ff ff 00 00 00 00 ad 4e ad de ..i..N.. backtrace: [] kmemleak_alloc+0x49/0xa0 [] kmem_cache_alloc_trace+0xe6/0x190 [] dev_pm_qos_constraints_allocate+0x44/0x110 [] __dev_pm_qos_add_request+0x17a/0x190 [] dev_pm_qos_add_request+0x36/0x50 [] usb_hub_create_port_device+0x138/0x370 [] hub_probe+0x8a7/0xf20 [] usb_probe_interface+0x1c1/0x300 [] driver_probe_device+0x227/0x440 [] __device_attach_driver+0x8f/0x100 [] bus_for_each_drv+0x58/0x90 [] __device_attach+0xb8/0x130 [] device_initial_probe+0xe/0x10 [] bus_probe_device+0x9e/0xb0 [] device_add+0x414/0x5e0 [] usb_set_configuration+0x52f/0x900 ... Martin -- 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 09/12] usb: gadget: udc: adapt to OTG core
Hi
> -Original Message-
> From: Roger Quadros [mailto:rog...@ti.com]
> Sent: Thursday, April 28, 2016 5:55 PM
> To: Jun Li ; st...@rowland.harvard.edu; ba...@kernel.org;
> gre...@linuxfoundation.org; peter.c...@freescale.com
> Cc: dan.j.willi...@intel.com; jun...@freescale.com;
> mathias.ny...@linux.intel.com; t...@atomide.com; joao.pi...@synopsys.com;
> abres...@chromium.org; r.bald...@samsung.com; linux-usb@vger.kernel.org;
> linux-ker...@vger.kernel.org; linux-o...@vger.kernel.org
> Subject: Re: [PATCH v6 09/12] usb: gadget: udc: adapt to OTG core
>
> Hi,
>
> On 27/04/16 14:22, Roger Quadros wrote:
> > On 26/04/16 03:07, Jun Li wrote:
> >> Hi
> >>
> >>> -Original Message-
> >>> From: Roger Quadros [mailto:rog...@ti.com]
> >>> Sent: Monday, April 25, 2016 10:04 PM
> >>> To: Jun Li ; st...@rowland.harvard.edu;
> >>> ba...@kernel.org; gre...@linuxfoundation.org;
> >>> peter.c...@freescale.com
> >>> Cc: dan.j.willi...@intel.com; jun...@freescale.com;
> >>> mathias.ny...@linux.intel.com; t...@atomide.com;
> >>> joao.pi...@synopsys.com; abres...@chromium.org;
> >>> r.bald...@samsung.com; linux-usb@vger.kernel.org;
> >>> linux-ker...@vger.kernel.org; linux-o...@vger.kernel.org
> >>> Subject: Re: [PATCH v6 09/12] usb: gadget: udc: adapt to OTG core
> >>>
> >>> Hi,
> >>>
> >>> On 21/04/16 09:38, Jun Li wrote:
> Hi,
>
> ...
> >
> > /**
> > + * usb_gadget_start - start the usb gadget controller and connect
> > +to bus
> > + * @gadget: the gadget device to start
> > + *
> > + * This is external API for use by OTG core.
> > + *
> > + * Start the usb device controller and connect to bus (enable pull).
> > + */
> > +static int usb_gadget_start(struct usb_gadget *gadget) {
> > + int ret;
> > + struct usb_udc *udc = NULL;
> > +
> > + dev_dbg(&gadget->dev, "%s\n", __func__);
> > + mutex_lock(&udc_lock);
> > + list_for_each_entry(udc, &udc_list, list)
> > + if (udc->gadget == gadget)
> > + goto found;
> > +
> > + dev_err(gadget->dev.parent, "%s: gadget not registered.\n",
> > + __func__);
> > + mutex_unlock(&udc_lock);
> > + return -EINVAL;
> > +
> > +found:
> > + ret = usb_gadget_udc_start(udc);
> > + if (ret)
> > + dev_err(&udc->dev, "USB Device Controller didn't
> start: %d\n",
> > + ret);
> > + else
> > + usb_udc_connect_control(udc);
>
> For drd, it's fine, but for real otg, gadget connect should be done
> by
> loc_conn() instead of gadget start.
> >>>
> >>> It is upto the OTG state machine to call gadget_start() when it
> >>> needs to connect to the bus (i.e. loc_conn()). I see no point in
> >>> calling gadget start before.
> >>>
> >>> Do you see any issue in doing so?
> >>
> >> This is what OTG state machine does:
> >> case OTG_STATE_B_PERIPHERAL:
> >> otg_chrg_vbus(otg, 0);
> >> otg_loc_sof(otg, 0);
> >> otg_set_protocol(fsm, PROTO_GADGET);
> >> otg_loc_conn(otg, 1);
> >> break;
>
> On second thoughts, after seen the OTG state machine.
> otg_set_protocol(fsm, PROTO_GADGET); is always followed by
> otg_loc_conn(otg, 1); And whenever protocol changes to anything other the
> PROTO_GADGET, we use otg_loc_conn(otg, 0);
>
> So otg_loc_conn seems redundant. Can we just get rid of it?
>
> usb_gadget_start() implies that gadget controller starts up and enables
> pull.
> usb_gadget_stop() implies that gadget controller disables pull and stops.
>
>
> Can you please explain why just these 2 APIs are not sufficient for full
> OTG?
>
> Do we want anything to happen between gadget controller start/stop and
> pull on/off?
"loc_conn" is a standard output parameter in OTG spec, it deserves
a separate api, yes, current implementation of OTG state machine code
seems allow you to combine the 2 things into one, but don't do that,
because they do not always happen together, e.g. for peripheral only
B device (also a part OTG spec: section 7.3), will be fixed in gadget
mode, but it will do gadget connect and disconnect in its diff states,
so, to make the framework common, let's keep them separated.
Li Jun
>
> cheers,
> -roger
>
> >>
> >> You intend to abstract something common in this api when start
> >> gadget, which should be called by otg_set_protocol(fsm,
> >> PROTO_GADGET); and drd_set_protocol(fsm, PROTO_GADGET); right?
> >>
> >> So you may move usb_udc_connect_control(IMO usb_gadget_connect() is
> >> better)out of usb_gadget_start(), then for drd:
> >>
> >> case OTG_STATE_B_PERIPHERAL:
> >> drd_set_protocol(fsm, PROTO_GADGET);
> >> otg_drv_vbus(otg, 0);
> >> usb_gadget_connect();
> >
> > OK. I understand now. I'll implement your suggestion. Thanks.
> >
> > cheers,
> > -roger
> >
>
> > +
> > + mutex_unlock(&udc_lock)
[GIT PULL] USB: changes for v4.7 merge window
Hi Greg, here's the gadget pull request for v4.7 merge window. It's mostly dwc3 this time: $ git diff --dirstat v4.6-rc3 74.4% drivers/usb/dwc3/ 13.9% drivers/usb/gadget/udc/ 5.2% drivers/usb/gadget/ 3.6% drivers/usb/renesas_usbhs/ Patches have been tested on Intel platforms and have been soaking on Linux next for a while now. Let me know if you want anything to be changed. cheers The following changes since commit bf16200689118d19de1b8d2a3c314fc21f5dc7bb: Linux 4.6-rc3 (2016-04-10 17:58:30 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git tags/usb-for-v4.7 for you to fetch changes up to 2a58f9c12bb360f38fb39e470bb5ff94014356e6: usb: dwc3: gadget: disable automatic calculation of ACK TP NUMP (2016-04-28 10:56:28 +0300) usb: changes for v4.7 merge window Here's the big USB Gadget pull request. This time not as large as usual with only 57 non-merge commits. The most important part here is, again, all the work on dwc3. This time around we're treating all endpoints (except for control endpoint) exactly the same. They all have the same amount of TRBs on the ring, they all treat the ring as an actual ring with a link TRB pointing to the head, etc. We're also helping the host side burst (on SuperSpeed GEN1 or GEN2 at least) for as long as possible until the endpoint returns NRDY. Other than this big TRB ring rework on dwc3, we also have a dwc3-omap DMA initialization fix, some extra debugfs files to aid in some odd debug sessions and a complete removal of our FIFO resizing logic. We have a new quirk for some dwc3 P3 quirk in some implementations. The rest is basically non-critical fixes and the usual cleanups. Andy Shevchenko (5): usb: gadged: pch_udc: PCI core handles power state for us usb: gadget: pch_udc: convert to devres API usb: gadget: pch_udc: enable MSI if hardware supports usb: gadged: pch_udc: get rid of redundant assignments usb: gadget: pch_udc: sort IDs Arnd Bergmann (1): usb: common: rework CONFIG_USB_COMMON logic Denys Vlasenko (1): usb: gadget: r8a66597-udc: Deinline pipe_change, save 2176 bytes Du, Changbin (1): usb: dwc3: make dwc3_debugfs_init return value be void Fei Yang (1): usb: dwc3: ep0: sanity check test mode selector Felipe Balbi (29): usb: dwc3: drop FIFO resizing logic usb: dwc3: gadget: always enable CSP usb: dwc3: increase maximum number of TRBs per endpoint usb: dwc3: better name for our request management lists usb: gadget: udc: at91: use PTR_ERR_OR_ZERO() usb: phy: qcom: use PTR_ERR_OR_ZERO() usb: dwc3: remove num_event_buffers usb: dwc3: drop ev_buffs array usb: dwc3: gadget: pass ev_buff as cookie to irq handler usb: dwc3: gadget: combine return points into a single one usb: dwc3: gadget: clear SUSPHY bit before ep cmds usb: dwc3: gadget: extract unlocked dwc3_gadget_wakeup() usb: dwc3: gadget: put link to U0 before Start Transfer usb: dwc3: gadget: rename busy/free_slot to trb_enqueue/dequeue usb: dwc3: core: document struct dwc3_request usb: dwc3: switch trb enqueue/dequeue and first_trb_index to u8 usb: dwc3: get rid of DWC3_TRB_MASK usb: dwc3: gadget: add trb enqueue/dequeue helpers usb: dwc3: gadget: move % operation to increment helpers usb: dwc3: gadget: use link TRB for all endpoint types usb: dwc3: gadget: remove newline from trace usb: dwc3: gadget: don't interrupt when chained usb: gadget: pch_udc: don't free devm allocated memory usb: dwc3: core: add fifo space helper usb: dwc3: core: add helper to extract trb type usb: dwc3: debugfs: dump out endpoint details usb: gadget: composite: avoid kernel oops with bad gadgets usb: dwc3: gadget: update DCFG.NumP to max burst size usb: dwc3: gadget: disable automatic calculation of ACK TP NUMP Grygorii Strashko (1): usb: dwc3: omap: drop dma_mask configuration Heikki Krogerus (2): usb: dwc3: pci: make build-in device properties available usb: dwc3: pci: pass the platform device as a parameter to dwc3_pci_quirks() John Youn (1): usb: dwc2: Proper cleanup on dr_mode failure Konrad Leszczynski (1): usb: dwc3: gadget: give better command return code Lars-Peter Clausen (1): usb: gadget: f_fs: Fix EFAULT generation for async read operations Michal Nazarewicz (1): usb: f_mass_storage: test whether thread is running before starting another Rajesh Bhagat (2): Documentation: dt: dwc3: Add snps,dis_rxdet_inp3_quirk property usb: dwc3: add disable receiver detection in P3 quirk Roger Quadros (1): usb: dwc3: omap: get rid of dma_status Sevak Arakelyan (1): usb: dwc2: Fixed SOF interrupt enabling/disabling Vahram
Re: [EXT] Re: [PATCH RESEND 3/5] USB: serial: cp210x: Added comments to CRTSCT flag code.
On Wed, Apr 27, 2016 at 08:06:32PM +, Konstantin Shkolnyy wrote:
> > -Original Message-
> > From: Johan Hovold [mailto:jhov...@gmail.com] On Behalf Of Johan Hovold
> > Sent: Tuesday, April 26, 2016 02:26
> > To: Konstantin Shkolnyy
> > Cc: Johan Hovold; Konstantin Shkolnyy; linux-usb@vger.kernel.org; linux-
> > ker...@vger.kernel.org
> > Subject: Re: [EXT] Re: [PATCH RESEND 3/5] USB: serial: cp210x: Added
> > comments to CRTSCT flag code.
> >
> > On Mon, Apr 25, 2016 at 06:09:01PM +, Konstantin Shkolnyy wrote:
> > > I was planning to define all these bits in a separate future patch.
> > > Would you rather prefer the magic numbers defined before fixing the
> > bugs?
> >
> > Fixing the RTS bug (patch 1), which is the only "real" bug, should be
> > done before adding defines, and fixing and cleaning up the rest.
> >
> > > I guess I can do that. Is something like this acceptable?
> > >
> > > /* CP210X_GET_FLOW/CP210X_SET_FLOW read/write these 0x10 bytes */
> > > struct cp210x_flow_ctl {
> > > u8 SERIAL_DTR_MASK: 2; /* byte 0 */
> > > u8 : 1;
> > > u8 SERIAL_CTS_HANDSHAKE : 1;
> > > u8 SERIAL_DSR_HANDSHAKE : 1;
> > > u8 SERIAL_DCD_HANDSHAKE : 1;
> > > u8 SERIAL_DSR_SENSITIVITY : 1;
> > > u8 : 1;
> > > u8; /* byte 1 */
> > > u8; /* byte 2 */
> > > u8; /* byte 3 */
> > > u8 SERIAL_AUTO_TRANSMIT : 1; /* byte 4 */
> > > u8 SERIAL_AUTO_RECEIVE: 1;
> > > u8 SERIAL_ERROR_CHAR : 1;
> > > u8 SERIAL_NULL_STRIPPING : 1;
> > > u8 SERIAL_BREAK_CHAR : 1;
> > > u8 : 1;
> > > u8 SERIAL_RTS_MASK: 2;
> > > u8; /* byte 5 */
> > > u8; /* byte 6 */
> > > u8 : 7; /* byte 7 */
> > > u8 SERIAL_XOFF_CONTINUE : 1;
> > > __le32 ulXonLimit;
> > > __le32 ulXoffLimit;
> > > } __packed;
> >
> > No, shouldn't rely on the layout of bitfields. Define masks and shifts
> > as needed and the message structure as
> >
> > struct cp210x_flow_ctl {
> > __le32 ulControlHandshake;
> > __le32 ulFlowReplace;
> > __le32 ulXonLimit;
> > __le32 ulXoffLimit;
> > };
> >
> > that is, as per AN571.
>
> OK, from searching www I see that bitfields have bad reputation for
> unclear reasons, so I guess it's now easier to avoid them.
> But doing it like you suggest, instead of splitting it to bytes, would
> complicate the code with endian conversions.
> Is there a reason for this other than making it identical to the spec?\
Staying aligned with the specification is usually a good idea. That also
became apparent when reviewing these patching and trying to match up the
magic constants with the spec.
The endian conversions should not need to complicate things that much.
Get the values using le32_to_cpu, manipulate the bits in a u32, and
store them back using cpu_to_le32.
Thanks,
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: gadget: f_fs: Fix kernel panic for SuperSpeed
On 2016年04月26日 16:49, Jim Lin wrote:
On 2016年04月25日 20:01, Felipe Balbi wrote:
* PGP Signed by an unknown key
Is this happening on set_config() ? If that's the case, why is
gadget->speed set to USB_SPEED_SUPER to start with ? Your controller
should already have negotiated highspeed which means
function_descriptors() should have returned highspeed descriptors,
not a
NULL superspeed.
Care to explain why you haven't negotiated Highspeed ? The only
thing I
can think of is that you're using a Superspeed-capable peripheral
controller (dwc3?) with maximum-speed set to Superspeed, with a
Superspeed-capable cable connected to an XHCI PC, but loading a
high-speed gadget driver (which you got from Android, written with
f_fs)
and this gadget doesn't tell composite that its maximum speed is
Highspeed, instead of super-speed.
We can add a check, sure, to avoid a kernel oops; however, you should
really fix up the gadget implementation and/or set dwc3's
maximum-speed
property accordingly.
Can you check if this patch makes your scenario work while still being
fully functional ?
diff --git a/drivers/usb/gadget/composite.c
b/drivers/usb/gadget/composite.c
index de9ffd60fcfa..3d3cdc5ed20d 100644
--- a/drivers/usb/gadget/composite.c
+++ b/drivers/usb/gadget/composite.c
@@ -66,20 +66,36 @@ function_descriptors(struct usb_function *f,
{
struct usb_descriptor_header **descriptors;
+/*
+ * NOTE: we try to help gadget drivers which might not be setting
+ * max_speed appropriately.
+ */
+
switch (speed) {
case USB_SPEED_SUPER_PLUS:
descriptors = f->ssp_descriptors;
-break;
+if (descriptors)
+break;
+/* FALLTHROUGH */
case USB_SPEED_SUPER:
descriptors = f->ss_descriptors;
-break;
+if (descriptors)
+break;
+/* FALLTHROUGH */
case USB_SPEED_HIGH:
descriptors = f->hs_descriptors;
-break;
+if (descriptors)
+break;
+/* FALLTHROUGH */
default:
descriptors = f->fs_descriptors;
}
+/*
+ * if we can't find any descriptors at all, then this gadget
deserves to
+ * Oops with a NULL pointer dereference
+ */
+
return descriptors;
}
After trying your change, no kernel panic, but SuperSpeed device
(device
mode) is not enumerated by ubuntu 14.04 USB 3.0 host controller as MTP
device with USB3.0 cable.
what do you get on dmesg on host side ? Are you running dwc3 ? If you
are, please capture trace logs of the failure:
# mount -t debugfs none /sys/kernel/debug
# cd /sys/kernel/debug/tracing
# echo 2048 > buffer_size_kb
# echo 1 > events/dwc3/enable
(now connect your cable to host pc)
# cp trace /path/to/non-volatile/storage/trace.txt
Please reply with this trace.txt file and dmesg from host side.
This is not running with dwc3.
dmesg from PC host side (after adding your change without my patch):
[17907.984647] usb 6-2: new SuperSpeed USB device number 54 using
xhci_hcd
[17908.012036] usb 6-2: No SuperSpeed endpoint companion for config 1
interface 1 altsetting 0 ep 2: using minimum values
[17908.012040] usb 6-2: No SuperSpeed endpoint companion for config 1
interface 1 altsetting 0 ep 131: using minimum values
[17908.013652] usb 6-2: New USB device found, idVendor=,
idProduct=
[17908.013656] usb 6-2: New USB device strings: Mfr=1, Product=2,
SerialNumber=3
[17908.013658] usb 6-2: Product: xxx
[17908.013661] usb 6-2: Manufacturer: xx
[17908.013664] usb 6-2: SerialNumber: 1234567890
[17908.014680] xhci_hcd :05:00.0: ERROR: unexpected command
completion code 0x11.
[17908.014690] usb 6-2: can't set config #1, error -22
I also attach git log of system/core/adb/usb_linux_client.cpp of
Android N for your reference.
"
Author: Badhri Jagan Sridharan
Date: Mon Oct 5 13:04:03 2015 -0700
adbd: Add os descriptor support for adb.
Eventhough windows does not rely on extended os
descriptor for adbd, when android usb device is
configures as a composite device such as mtp+adb,
windows discards the extended os descriptor even
if one of the USB function fails to send
the extended compat descriptor. This results in automatic
install of MTP driverto fail when Android device is in
"File Transfer" mode with adb enabled.
https://msdn.microsoft.com/en-us/library/windows/hardware/gg463179.aspx
"
How do we proceed on this patch?
[PATCH] usb: gadget: f_fs: Fix kernel panic for SuperSpeed
Thanks,
--nvpublic
--
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: [PATCHv7] usb: dwc2: Add reset control to dwc2
> From: Dinh Nguyen > > Allow for platforms that have a reset controller driver in place to bring > the USB IP out of reset. > > Signed-off-by: Dinh Nguyen Successful tested with Raspberry Pi B (without reset controller) Tested-by: Stefan Wahren -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: gadget: f_fs: Fix kernel panic for SuperSpeed
Hi,
Jim Lin writes:
> On 2016年04月25日 20:01, Felipe Balbi wrote:
Is this happening on set_config() ? If that's the case, why is
gadget->speed set to USB_SPEED_SUPER to start with ? Your controller
should already have negotiated highspeed which means
function_descriptors() should have returned highspeed descriptors, not a
NULL superspeed.
Care to explain why you haven't negotiated Highspeed ? The only thing I
can think of is that you're using a Superspeed-capable peripheral
controller (dwc3?) with maximum-speed set to Superspeed, with a
Superspeed-capable cable connected to an XHCI PC, but loading a
high-speed gadget driver (which you got from Android, written with f_fs)
and this gadget doesn't tell composite that its maximum speed is
Highspeed, instead of super-speed.
We can add a check, sure, to avoid a kernel oops; however, you should
really fix up the gadget implementation and/or set dwc3's maximum-speed
property accordingly.
Can you check if this patch makes your scenario work while still being
fully functional ?
diff --git a/drivers/usb/gadget/composite.c
b/drivers/usb/gadget/composite.c
index de9ffd60fcfa..3d3cdc5ed20d 100644
--- a/drivers/usb/gadget/composite.c
+++ b/drivers/usb/gadget/composite.c
@@ -66,20 +66,36 @@ function_descriptors(struct usb_function *f,
{
struct usb_descriptor_header **descriptors;
+ /*
+ * NOTE: we try to help gadget drivers which might not be setting
+ * max_speed appropriately.
+ */
+
switch (speed) {
case USB_SPEED_SUPER_PLUS:
descriptors = f->ssp_descriptors;
- break;
+ if (descriptors)
+ break;
+ /* FALLTHROUGH */
case USB_SPEED_SUPER:
descriptors = f->ss_descriptors;
- break;
+ if (descriptors)
+ break;
+ /* FALLTHROUGH */
case USB_SPEED_HIGH:
descriptors = f->hs_descriptors;
- break;
+ if (descriptors)
+ break;
+ /* FALLTHROUGH */
default:
descriptors = f->fs_descriptors;
}
+ /*
+ * if we can't find any descriptors at all, then this gadget deserves to
+ * Oops with a NULL pointer dereference
+ */
+
return descriptors;
}
>>> After trying your change, no kernel panic, but SuperSpeed device (device
>>> mode) is not enumerated by ubuntu 14.04 USB 3.0 host controller as MTP
>>> device with USB3.0 cable.
>> what do you get on dmesg on host side ? Are you running dwc3 ? If you
>> are, please capture trace logs of the failure:
>>
>> # mount -t debugfs none /sys/kernel/debug
>> # cd /sys/kernel/debug/tracing
>> # echo 2048 > buffer_size_kb
>> # echo 1 > events/dwc3/enable
>>
>> (now connect your cable to host pc)
>>
>> # cp trace /path/to/non-volatile/storage/trace.txt
>>
>> Please reply with this trace.txt file and dmesg from host side.
> This is not running with dwc3.
okay
> dmesg from PC host side (after adding your change without my patch):
>
> [17907.984647] usb 6-2: new SuperSpeed USB device number 54 using xhci_hcd
> [17908.012036] usb 6-2: No SuperSpeed endpoint companion for config 1
> interface 1 altsetting 0 ep 2: using minimum values
> [17908.012040] usb 6-2: No SuperSpeed endpoint companion for config 1
> interface 1 altsetting 0 ep 131: using minimum values
> [17908.013652] usb 6-2: New USB device found, idVendor=, idProduct=
> [17908.013656] usb 6-2: New USB device strings: Mfr=1, Product=2,
> SerialNumber=3
> [17908.013658] usb 6-2: Product: xxx
> [17908.013661] usb 6-2: Manufacturer: xx
> [17908.013664] usb 6-2: SerialNumber: 1234567890
> [17908.014680] xhci_hcd :05:00.0: ERROR: unexpected command
> completion code 0x11.
hmmm... completed with unknown code ? Odd. Mathias, any idea what this
is ?
> [17908.014690] usb 6-2: can't set config #1, error -22
>
> I also attach git log of system/core/adb/usb_linux_client.cpp of Android
> N for your reference.
> "
> Author: Badhri Jagan Sridharan
> Date: Mon Oct 5 13:04:03 2015 -0700
>
> adbd: Add os descriptor support for adb.
>
> Eventhough windows does not rely on extended os
> descriptor for adbd, when android usb device is
> configures as a composite device such as mtp+adb,
> windows discards the extended os descriptor even
> if one of the USB function fails to send
> the extended compat descriptor. This results in automatic
> install of MTP driverto fail when Android device is in
> "File Transfer" mode with adb enabled.
>
> https://msdn.microsoft.com/en-us/library/windows/hardware/gg4631
Re: [PATCH v6 09/12] usb: gadget: udc: adapt to OTG core
On 28/04/16 13:23, Jun Li wrote:
> Hi
>
>> -Original Message-
>> From: Roger Quadros [mailto:rog...@ti.com]
>> Sent: Thursday, April 28, 2016 5:55 PM
>> To: Jun Li ; st...@rowland.harvard.edu; ba...@kernel.org;
>> gre...@linuxfoundation.org; peter.c...@freescale.com
>> Cc: dan.j.willi...@intel.com; jun...@freescale.com;
>> mathias.ny...@linux.intel.com; t...@atomide.com; joao.pi...@synopsys.com;
>> abres...@chromium.org; r.bald...@samsung.com; linux-usb@vger.kernel.org;
>> linux-ker...@vger.kernel.org; linux-o...@vger.kernel.org
>> Subject: Re: [PATCH v6 09/12] usb: gadget: udc: adapt to OTG core
>>
>> Hi,
>>
>> On 27/04/16 14:22, Roger Quadros wrote:
>>> On 26/04/16 03:07, Jun Li wrote:
Hi
> -Original Message-
> From: Roger Quadros [mailto:rog...@ti.com]
> Sent: Monday, April 25, 2016 10:04 PM
> To: Jun Li ; st...@rowland.harvard.edu;
> ba...@kernel.org; gre...@linuxfoundation.org;
> peter.c...@freescale.com
> Cc: dan.j.willi...@intel.com; jun...@freescale.com;
> mathias.ny...@linux.intel.com; t...@atomide.com;
> joao.pi...@synopsys.com; abres...@chromium.org;
> r.bald...@samsung.com; linux-usb@vger.kernel.org;
> linux-ker...@vger.kernel.org; linux-o...@vger.kernel.org
> Subject: Re: [PATCH v6 09/12] usb: gadget: udc: adapt to OTG core
>
> Hi,
>
> On 21/04/16 09:38, Jun Li wrote:
>> Hi,
>>
>> ...
>>>
>>> /**
>>> + * usb_gadget_start - start the usb gadget controller and connect
>>> +to bus
>>> + * @gadget: the gadget device to start
>>> + *
>>> + * This is external API for use by OTG core.
>>> + *
>>> + * Start the usb device controller and connect to bus (enable pull).
>>> + */
>>> +static int usb_gadget_start(struct usb_gadget *gadget) {
>>> + int ret;
>>> + struct usb_udc *udc = NULL;
>>> +
>>> + dev_dbg(&gadget->dev, "%s\n", __func__);
>>> + mutex_lock(&udc_lock);
>>> + list_for_each_entry(udc, &udc_list, list)
>>> + if (udc->gadget == gadget)
>>> + goto found;
>>> +
>>> + dev_err(gadget->dev.parent, "%s: gadget not registered.\n",
>>> + __func__);
>>> + mutex_unlock(&udc_lock);
>>> + return -EINVAL;
>>> +
>>> +found:
>>> + ret = usb_gadget_udc_start(udc);
>>> + if (ret)
>>> + dev_err(&udc->dev, "USB Device Controller didn't
>> start: %d\n",
>>> + ret);
>>> + else
>>> + usb_udc_connect_control(udc);
>>
>> For drd, it's fine, but for real otg, gadget connect should be done
>> by
>> loc_conn() instead of gadget start.
>
> It is upto the OTG state machine to call gadget_start() when it
> needs to connect to the bus (i.e. loc_conn()). I see no point in
> calling gadget start before.
>
> Do you see any issue in doing so?
This is what OTG state machine does:
case OTG_STATE_B_PERIPHERAL:
otg_chrg_vbus(otg, 0);
otg_loc_sof(otg, 0);
otg_set_protocol(fsm, PROTO_GADGET);
otg_loc_conn(otg, 1);
break;
>>
>> On second thoughts, after seen the OTG state machine.
>> otg_set_protocol(fsm, PROTO_GADGET); is always followed by
>> otg_loc_conn(otg, 1); And whenever protocol changes to anything other the
>> PROTO_GADGET, we use otg_loc_conn(otg, 0);
>>
>> So otg_loc_conn seems redundant. Can we just get rid of it?
>>
>> usb_gadget_start() implies that gadget controller starts up and enables
>> pull.
>> usb_gadget_stop() implies that gadget controller disables pull and stops.
>>
>>
>> Can you please explain why just these 2 APIs are not sufficient for full
>> OTG?
>>
>> Do we want anything to happen between gadget controller start/stop and
>> pull on/off?
>
> "loc_conn" is a standard output parameter in OTG spec, it deserves
> a separate api, yes, current implementation of OTG state machine code
> seems allow you to combine the 2 things into one, but don't do that,
> because they do not always happen together, e.g. for peripheral only
> B device (also a part OTG spec: section 7.3), will be fixed in gadget
> mode, but it will do gadget connect and disconnect in its diff states,
> so, to make the framework common, let's keep them separated.
I'm sorry but I didn't understand your comment about "it will do gadget
connect and disconnect in its diff states"
I am reading the OTG v2.0 specification and loc_conn is always true when
b_peripheral or a_peripheral is true and false otherwise.
loc_conn is just an internal state variable and it corresponds to our
gadget_start/stop() state.
As per 7.4.2.3
"loc_conn
The “local connect” (loc_conn) variable is TRUE when the local device has
signaled that it is connected to
the bus. This variable is FALSE when the local device has signaled that it is
disconnected from the bus"
Can you ple
[PATCH] usbip: vudc: fix Kconfig dependencies
With the addition of VUDC, the USBIP stack can now be used on
configurations without USB host support, but trying to build
it with USB gadget support disabled fails with
drivers/usb/built-in.o: In function `vep_dequeue':
vudc_main.c:(.text+0xa6ddc): undefined reference to
`usb_gadget_giveback_request'
drivers/usb/built-in.o: In function `nuke':
vudc_main.c:(.text+0xa6ea8): undefined reference to
`usb_gadget_giveback_request'
drivers/usb/built-in.o: In function `vudc_device_reset':
vudc_main.c:(.text+0xa720c): undefined reference to `usb_gadget_udc_reset'
drivers/usb/built-in.o: In function `vudc_probe':
This addresses both issues, by changing the dependency for USBIP_CORE
to USB_COMMON, and adding additional dependencies on USB or USB_GADGET
for the individual portions as needed.
Signed-off-by: Arnd Bergmann
Fixes: 9360575c5837 ("usbip: vudc: Add vudc to Kconfig")
---
drivers/usb/usbip/Kconfig | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/usbip/Kconfig b/drivers/usb/usbip/Kconfig
index ebf4ff050890..17646b25343f 100644
--- a/drivers/usb/usbip/Kconfig
+++ b/drivers/usb/usbip/Kconfig
@@ -1,6 +1,6 @@
config USBIP_CORE
tristate "USB/IP support"
- depends on USB && NET
+ depends on USB_COMMON && NET
---help---
This enables pushing USB packets over IP to allow remote
machines direct access to USB devices. It provides the
@@ -16,7 +16,7 @@ config USBIP_CORE
config USBIP_VHCI_HCD
tristate "VHCI hcd"
- depends on USBIP_CORE
+ depends on USBIP_CORE && USB
---help---
This enables the USB/IP virtual host controller driver,
which is run on the remote machine.
@@ -26,7 +26,7 @@ config USBIP_VHCI_HCD
config USBIP_HOST
tristate "Host driver"
- depends on USBIP_CORE
+ depends on USBIP_CORE && USB
---help---
This enables the USB/IP host driver, which is run on the
machine that is sharing the USB devices.
@@ -36,7 +36,7 @@ config USBIP_HOST
config USBIP_VUDC
tristate "VUDC driver"
- depends on USBIP_CORE
+ depends on USBIP_CORE && USB_GADGET
---help---
This enables the USB/IP virtual USB device controller
driver, which is run on the host machine, allowing the
--
2.7.0
--
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: dwc3: host: inherit dma configuration from parent dev
On Thu, Apr 28, 2016 at 09:37:08AM +0300, Felipe Balbi wrote: > > Hi, > > Arnd Bergmann writes: > >pointer and pass that in platform_data. This is really easy, it's > > Sorry but passing a struct device pointer in platform_data is > ridiculous. Not to mention that, as I said before, we can't assume which > device to pass to xhci_plat in the first place. It might be dwc->dev and > it might be dwc->dev->parent. +1. Passing an unref-counted struct device through platform data is totally mad, Arnd you're off your rocker if you think that's a good idea. What's more is that there's no way to properly refcount the thing. -- RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net. -- 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: dwc3: host: inherit dma configuration from parent dev
On Thursday 28 April 2016 15:16:12 Russell King - ARM Linux wrote: > On Thu, Apr 28, 2016 at 09:37:08AM +0300, Felipe Balbi wrote: > > > > Hi, > > > > Arnd Bergmann writes: > > >pointer and pass that in platform_data. This is really easy, it's > > > > Sorry but passing a struct device pointer in platform_data is > > ridiculous. Not to mention that, as I said before, we can't assume which > > device to pass to xhci_plat in the first place. It might be dwc->dev and > > it might be dwc->dev->parent. > > +1. Passing an unref-counted struct device through platform data is > totally mad, Arnd you're off your rocker if you think that's a good > idea. What's more is that there's no way to properly refcount the > thing. It's the parent device (or NULL), there is no way it can ever go away as it's already refcounted through the device subsystem by the creation of the child device. I do realize that it's a hack, but the idea is to get rid of that as soon as possibly by fixing the way the xhci device is probe so we no longer need to fake a platform_device as the child here and can just use the device itself. Arnd -- 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: dwc3: host: inherit dma configuration from parent dev
Hi, Arnd Bergmann writes: > On Thursday 28 April 2016 15:16:12 Russell King - ARM Linux wrote: >> On Thu, Apr 28, 2016 at 09:37:08AM +0300, Felipe Balbi wrote: >> > >> > Hi, >> > >> > Arnd Bergmann writes: >> > >pointer and pass that in platform_data. This is really easy, it's >> > >> > Sorry but passing a struct device pointer in platform_data is >> > ridiculous. Not to mention that, as I said before, we can't assume which >> > device to pass to xhci_plat in the first place. It might be dwc->dev and >> > it might be dwc->dev->parent. >> >> +1. Passing an unref-counted struct device through platform data is >> totally mad, Arnd you're off your rocker if you think that's a good >> idea. What's more is that there's no way to properly refcount the >> thing. > > It's the parent device (or NULL), there is no way it can ever go away as > it's already refcounted through the device subsystem by the creation > of the child device. you're assuming that based on what we have today. We could get into a situation where we need to use a completely unrelated device and the problem exists again. > I do realize that it's a hack, but the idea is to get rid of that > as soon as possibly by fixing the way the xhci device is probe so > we no longer need to fake a platform_device as the child here and > can just use the device itself. okay, let me try to be extra clear here: We will *not* remove the extra platform_device because it actually *does* exist and helps me hide/abstract a bunch of details and make assumptions about order of certain events. We have already gone through that in the past when I explained why I wrote dwc3 the way it is; if you need a refresher, there are mailing list archives for that. Moreover, this same problem exists for anything under drivers/mfd. It just so happens that they're usually some i2c or spi device which don't do DMA by themselves. -- balbi signature.asc Description: PGP signature
Re: [PATCHv2] musb_host: fix lockup on rxcsr_h_error
Hi,
On Thu, Apr 28, 2016 at 09:51:37AM +0300, Maxim Uvarov wrote:
[snip]
> Hello Bin,
>
> yes, it also works with that reset and go to finish:
>
> diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
> index c3d5fc9..8cd98e7 100644
> --- a/drivers/usb/musb/musb_host.c
> +++ b/drivers/usb/musb/musb_host.c
> @@ -1599,6 +1599,10 @@ void musb_host_rx(struct musb *musb, u8 epnum)
> status = -EPROTO;
> musb_writeb(epio, MUSB_RXINTERVAL, 0);
>
> + rx_csr &= ~MUSB_RXCSR_H_ERROR;
> + musb_writew(epio, MUSB_RXCSR, rx_csr);
> +
> + goto finish;
> } else if (rx_csr & MUSB_RXCSR_DATAERROR) {
>
> if (USB_ENDPOINT_XFER_ISOC != qh->type) {
>
Thanks for testing it.
>
> That I think a key thing, which is done in other error. If that change
> is good for you than I'm also happy with it.
We need to understand why the controller keeps generating the same
interrupt to come out a proper fix.
I will take a look. But I can only use my spare time on this, so be
patient.
>
> I also not sure if musb_writeb(epio, MUSB_RXINTERVAL, 0); is needed.
> In my case it's the same result with it and without it.
> In other scenarios might be reasonable...
It disables NAK timeout.
>
>
> > First of all, I don't like the idea of merging the two branches, it
> > makes the code ugly.
>
> Yes, I don't like that function at all, it's too long and difficult to
> read if you first look on it first time. It will be good to split it
> on 3 small functions for each big if.
This particular function is not that hard to understand, but the driver
in general is messy. But I am not sure if anyone in the community can
refactory this driver. The community had some effort in the past to
clean up this driver, but it always broke usecases on different
platforms.
Regards,
-Bin.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 08/12] usbip: vudc: Add SysFS infrastructure for VUDC
W dniu 27.04.2016 o 00:19, Greg KH pisze: > On Tue, Mar 08, 2016 at 09:49:03PM +0100, Krzysztof Opasiak wrote: >> From: Igor Kotrasinski >> >> Add sysfs attributes to allow controlling vudc from usbip tools. >> >> dev_desc - device descriptor of current gadget. This is required to >> be consisten with current usbip protocol and allow to list >> exportable devices on given machine. >> >> usbip_sockfd - allows to pass socket to kernel to start usbip transfer. >> >> usbip_status - currnent status of device > > For new sysfs files, we need entries in Documentation/ABI/ can you > provide those for these files in a follow-on patch? > > thanks, > > greg k-h I have a question regarding the dev_desc attribute. I pass binary data (the USB descriptor) through it to userspace. Should I make the attribute binary with BIN_ATTR? Igor Kotrasiński -- 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: [GIT PULL] USB: changes for v4.7 merge window
On Thu, Apr 28, 2016 at 01:46:03PM +0300, Felipe Balbi wrote: > > Hi Greg, > > here's the gadget pull request for v4.7 merge window. It's mostly dwc3 > this time: > > $ git diff --dirstat v4.6-rc3 > 74.4% drivers/usb/dwc3/ > 13.9% drivers/usb/gadget/udc/ >5.2% drivers/usb/gadget/ >3.6% drivers/usb/renesas_usbhs/ > > Patches have been tested on Intel platforms and have been soaking on > Linux next for a while now. > > Let me know if you want anything to be changed. > > cheers > > The following changes since commit bf16200689118d19de1b8d2a3c314fc21f5dc7bb: > > Linux 4.6-rc3 (2016-04-10 17:58:30 -0700) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git > tags/usb-for-v4.7 I've pulled and pushed out. There was a merge conflict in drivers/usb/dwc3/debugfs.c, and I think I got it right (well, I resolved it in the way that _I_ would like the code to look like), but if you could check, that would be great. 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 08/12] usbip: vudc: Add SysFS infrastructure for VUDC
On Thu, Apr 28, 2016 at 06:20:29PM +0200, Igor Kotrasiński wrote: > W dniu 27.04.2016 o 00:19, Greg KH pisze: > > On Tue, Mar 08, 2016 at 09:49:03PM +0100, Krzysztof Opasiak wrote: > >> From: Igor Kotrasinski > >> > >> Add sysfs attributes to allow controlling vudc from usbip tools. > >> > >> dev_desc - device descriptor of current gadget. This is required to > >> be consisten with current usbip protocol and allow to list > >> exportable devices on given machine. > >> > >> usbip_sockfd - allows to pass socket to kernel to start usbip transfer. > >> > >> usbip_status - currnent status of device > > > > For new sysfs files, we need entries in Documentation/ABI/ can you > > provide those for these files in a follow-on patch? > > > > thanks, > > > > greg k-h > I have a question regarding the dev_desc attribute. I pass binary data > (the USB descriptor) through it to userspace. Should I make the > attribute binary with BIN_ATTR? You better be doing that, otherwise it's incorrect :) 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 v6 04/10] regulator: fixed: add support for ACPI interface
On Thu, Apr 28, 2016 at 01:55:35PM +0800, Lu Baolu wrote: > How about below code? > + gpiod = gpiod_get(dev, "vbus_en", GPIOD_ASIS); > + if (IS_ERR(gpiod)) > + return PTR_ERR(gpiod); > + > + config->gpio = desc_to_gpio(gpiod); > + config->enable_high = device_property_read_bool(dev, > + "enable-active-high"); > + gpiod_put(gpiod); That looks reasonable, though if you use "gpio" as the name like DT you could keep the code the same which would be even better? Not super crticial though. signature.asc Description: PGP signature
[PATCH 07/10] usb: musb: Manage USB phy from PM runtime calls
This simplifies things and allows idling both MUSB and PHY
when nothing is configured.
Let's also warn if PHY is not configured.
Signed-off-by: Tony Lindgren
---
drivers/usb/musb/omap2430.c | 35 +--
1 file changed, 21 insertions(+), 14 deletions(-)
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index a2a158f..b274923 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -395,6 +395,7 @@ static int omap2430_musb_init(struct musb *musb)
return PTR_ERR(musb->phy);
}
musb->isr = omap2430_musb_interrupt;
+ phy_init(musb->phy);
/*
* Enable runtime PM for musb parent (this driver). We can't
@@ -431,8 +432,6 @@ static int omap2430_musb_init(struct musb *musb)
if (glue->status != MUSB_UNKNOWN)
omap_musb_set_mailbox(glue);
- phy_init(musb->phy);
- phy_power_on(musb->phy);
pm_runtime_put(glue->dev);
return 0;
@@ -491,11 +490,17 @@ static void omap2430_musb_disable(struct musb *musb)
static int omap2430_musb_exit(struct musb *musb)
{
- del_timer_sync(&musb_idle_timer);
+ struct device *dev = musb->controller;
+ struct omap2430_glue *glue = dev_get_drvdata(dev->parent);
+ del_timer_sync(&musb_idle_timer);
+ pm_runtime_get_sync(glue->dev);
omap2430_low_level_exit(musb);
- phy_power_off(musb->phy);
+ pm_runtime_put_sync_suspend(glue->dev);
+ pm_runtime_disable(glue->dev);
phy_exit(musb->phy);
+ musb->phy = NULL;
+ cancel_work_sync(&glue->omap_musb_mailbox_work);
return 0;
}
@@ -661,11 +666,7 @@ static int omap2430_remove(struct platform_device *pdev)
{
struct omap2430_glue*glue = platform_get_drvdata(pdev);
- pm_runtime_get_sync(glue->dev);
- cancel_work_sync(&glue->omap_musb_mailbox_work);
platform_device_unregister(glue->musb);
- pm_runtime_put_sync(glue->dev);
- pm_runtime_disable(glue->dev);
return 0;
}
@@ -677,12 +678,15 @@ static int omap2430_runtime_suspend(struct device *dev)
struct omap2430_glue*glue = dev_get_drvdata(dev);
struct musb *musb = glue_to_musb(glue);
- if (musb) {
- musb->context.otg_interfsel = musb_readl(musb->mregs,
- OTG_INTERFSEL);
+ if (WARN_ON(!musb))
+ return 0;
- omap2430_low_level_exit(musb);
- }
+ musb->context.otg_interfsel = musb_readl(musb->mregs,
+OTG_INTERFSEL);
+
+ omap2430_low_level_exit(musb);
+ if (!WARN_ON(!musb->phy))
+ phy_power_off(musb->phy);
return 0;
}
@@ -692,9 +696,12 @@ static int omap2430_runtime_resume(struct device *dev)
struct omap2430_glue*glue = dev_get_drvdata(dev);
struct musb *musb = glue_to_musb(glue);
- if (!musb)
+ if (WARN_ON(!musb))
return -EPROBE_DEFER;
+ if (!WARN_ON(!musb->phy))
+ phy_power_on(musb->phy);
+
omap2430_low_level_init(musb);
musb_writel(musb->mregs, OTG_INTERFSEL,
musb->context.otg_interfsel);
--
2.8.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 10/10] usb: musb: Remove pm_runtime_set_irq_safe
With the pull up being handled with delayed work, we can
now finally remove pm_runtime_set_irq_safe that blocks the
MUSB glue from idling.
Signed-off-by: Tony Lindgren
---
drivers/usb/musb/musb_core.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index b492316..f4731a0 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -2216,12 +2216,6 @@ musb_init_controller(struct device *dev, int nIrq, void
__iomem *ctrl)
pm_runtime_mark_last_busy(musb->controller);
pm_runtime_put_autosuspend(musb->controller);
- /*
-* For why this is currently needed, see commit 3e43a0725637
-* ("usb: musb: core: add pm_runtime_irq_safe()")
-*/
- pm_runtime_irq_safe(musb->controller);
-
return 0;
fail5:
--
2.8.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 04/10] usb: musb: Remove unnecessary shutdown function
We have remove() already calling shutdown(), so let's drop it
and move the code to remove().
Signed-off-by: Tony Lindgren
---
drivers/usb/musb/musb_core.c | 39 ++-
1 file changed, 14 insertions(+), 25 deletions(-)
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 5fa6187..d7af8ed 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -1090,29 +1090,6 @@ void musb_stop(struct musb *musb)
musb_platform_try_idle(musb, 0);
}
-static void musb_shutdown(struct platform_device *pdev)
-{
- struct musb *musb = dev_to_musb(&pdev->dev);
- unsigned long flags;
-
- pm_runtime_get_sync(musb->controller);
-
- musb_host_cleanup(musb);
- musb_gadget_cleanup(musb);
-
- spin_lock_irqsave(&musb->lock, flags);
- musb_platform_disable(musb);
- musb_generic_disable(musb);
- spin_unlock_irqrestore(&musb->lock, flags);
-
- musb_writeb(musb->mregs, MUSB_DEVCTL, 0);
- musb_platform_exit(musb);
-
- pm_runtime_put(musb->controller);
- /* FIXME power down */
-}
-
-
/*-*/
/*
@@ -2312,6 +2289,7 @@ static int musb_remove(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
struct musb *musb = dev_to_musb(dev);
+ unsigned long flags;
/* this gets called on rmmod.
* - Host mode: host may still be active
@@ -2319,7 +2297,19 @@ static int musb_remove(struct platform_device *pdev)
* - OTG mode: both roles are deactivated (or never-activated)
*/
musb_exit_debugfs(musb);
- musb_shutdown(pdev);
+
+ pm_runtime_get_sync(musb->controller);
+ musb_host_cleanup(musb);
+ musb_gadget_cleanup(musb);
+ spin_lock_irqsave(&musb->lock, flags);
+ musb_platform_disable(musb);
+ musb_generic_disable(musb);
+ spin_unlock_irqrestore(&musb->lock, flags);
+ musb_writeb(musb->mregs, MUSB_DEVCTL, 0);
+ musb_platform_exit(musb);
+ pm_runtime_put(musb->controller);
+ /* FIXME power down */
+
musb_phy_callback = NULL;
if (musb->dma_controller)
@@ -2612,7 +2602,6 @@ static struct platform_driver musb_driver = {
},
.probe = musb_probe,
.remove = musb_remove,
- .shutdown = musb_shutdown,
};
module_platform_driver(musb_driver);
--
2.8.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 06/10] usb: musb: Split PM runtime between wrapper IP and musb core
Let's not tinker with the PM runtime of musb core from the omap2430
wrapper. This allows us to initialize PM runtime for musb core later
on instead of doing it in stages. And omap2430 wrapper has no need
to for accessing musb core at this point.
Note that this does not remove all the PM runtime calls from the
glue layer, those will get removed in a later patch.
Signed-off-by: Tony Lindgren
---
drivers/usb/musb/musb_core.c | 25 ++---
drivers/usb/musb/omap2430.c | 10 --
2 files changed, 10 insertions(+), 25 deletions(-)
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 90ccdb2..b492316 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -2005,11 +2005,6 @@ musb_init_controller(struct device *dev, int nIrq, void
__iomem *ctrl)
musb_readl = musb_default_readl;
musb_writel = musb_default_writel;
- /* We need musb_read/write functions initialized for PM */
- pm_runtime_use_autosuspend(musb->controller);
- pm_runtime_set_autosuspend_delay(musb->controller, 500);
- pm_runtime_enable(musb->controller);
-
/* The musb_platform_init() call:
* - adjusts musb->mregs
* - sets the musb->isr
@@ -2111,6 +2106,10 @@ musb_init_controller(struct device *dev, int nIrq, void
__iomem *ctrl)
if (musb->ops->phy_callback)
musb_phy_callback = musb->ops->phy_callback;
+ /* We need musb_read/write functions initialized for PM */
+ pm_runtime_use_autosuspend(musb->controller);
+ pm_runtime_set_autosuspend_delay(musb->controller, 500);
+ pm_runtime_enable(musb->controller);
pm_runtime_get_sync(musb->controller);
status = usb_phy_init(musb->xceiv);
@@ -2300,6 +2299,9 @@ static int musb_remove(struct platform_device *pdev)
*/
musb_exit_debugfs(musb);
+ cancel_work_sync(&musb->irq_work);
+ cancel_delayed_work_sync(&musb->finish_resume_work);
+ cancel_delayed_work_sync(&musb->deassert_reset_work);
pm_runtime_get_sync(musb->controller);
musb_host_cleanup(musb);
musb_gadget_cleanup(musb);
@@ -2308,21 +2310,14 @@ static int musb_remove(struct platform_device *pdev)
musb_generic_disable(musb);
spin_unlock_irqrestore(&musb->lock, flags);
musb_writeb(musb->mregs, MUSB_DEVCTL, 0);
+ pm_runtime_dont_use_autosuspend(musb->controller);
+ pm_runtime_put_sync(musb->controller);
+ pm_runtime_disable(musb->controller);
musb_platform_exit(musb);
-
musb_phy_callback = NULL;
-
if (musb->dma_controller)
musb_dma_controller_destroy(musb->dma_controller);
-
usb_phy_shutdown(musb->xceiv);
-
- cancel_work_sync(&musb->irq_work);
- cancel_delayed_work_sync(&musb->finish_resume_work);
- cancel_delayed_work_sync(&musb->deassert_reset_work);
- pm_runtime_dont_use_autosuspend(musb->controller);
- pm_runtime_put_sync(musb->controller);
- pm_runtime_disable(musb->controller);
musb_free(musb);
device_init_wakeup(dev, 0);
return 0;
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index c55d4f3..a2a158f 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -406,13 +406,6 @@ static int omap2430_musb_init(struct musb *musb)
if (status < 0)
goto err1;
- status = pm_runtime_get_sync(dev);
- if (status < 0) {
- dev_err(dev, "pm_runtime_get_sync FAILED %d\n", status);
- pm_runtime_put_sync(glue->dev);
- goto err1;
- }
-
l = musb_readl(musb->mregs, OTG_INTERFSEL);
if (data->interface_type == MUSB_INTERFACE_UTMI) {
@@ -440,9 +433,6 @@ static int omap2430_musb_init(struct musb *musb)
phy_init(musb->phy);
phy_power_on(musb->phy);
-
- pm_runtime_mark_last_busy(musb->controller);
- pm_runtime_put_autosuspend(musb->controller);
pm_runtime_put(glue->dev);
return 0;
--
2.8.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 01/10] usb: phy: Fix initial state for twl6030
We need to check the state for the PHY with delayed_work so
as otherwise MUSB will get confused and idles immediately.
Signed-off-by: Tony Lindgren
---
drivers/usb/phy/phy-twl6030-usb.c | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/phy/phy-twl6030-usb.c
b/drivers/usb/phy/phy-twl6030-usb.c
index 014dbbd7..8696736 100644
--- a/drivers/usb/phy/phy-twl6030-usb.c
+++ b/drivers/usb/phy/phy-twl6030-usb.c
@@ -97,6 +97,9 @@ struct twl6030_usb {
struct regulator*usb3v3;
+ /* used to check initial cable status after probe */
+ struct delayed_work get_status_work;
+
/* used to set vbus, in atomic path */
struct work_struct set_vbus_work;
@@ -274,6 +277,15 @@ static irqreturn_t twl6030_usbotg_irq(int irq, void *_twl)
return IRQ_HANDLED;
}
+static void twl6030_status_work(struct work_struct *work)
+{
+ struct twl6030_usb *twl = container_of(work, struct twl6030_usb,
+ get_status_work.work);
+
+ twl6030_usb_irq(twl->irq2, twl);
+ twl6030_usbotg_irq(twl->irq1, twl);
+}
+
static int twl6030_enable_irq(struct twl6030_usb *twl)
{
twl6030_writeb(twl, TWL_MODULE_USB, 0x1, USB_ID_INT_EN_HI_SET);
@@ -284,8 +296,6 @@ static int twl6030_enable_irq(struct twl6030_usb *twl)
REG_INT_MSK_LINE_C);
twl6030_interrupt_unmask(TWL6030_CHARGER_CTRL_INT_MASK,
REG_INT_MSK_STS_C);
- twl6030_usb_irq(twl->irq2, twl);
- twl6030_usbotg_irq(twl->irq1, twl);
return 0;
}
@@ -371,6 +381,7 @@ static int twl6030_usb_probe(struct platform_device *pdev)
dev_warn(&pdev->dev, "could not create sysfs file\n");
INIT_WORK(&twl->set_vbus_work, otg_set_vbus_work);
+ INIT_DELAYED_WORK(&twl->get_status_work, twl6030_status_work);
status = request_threaded_irq(twl->irq1, NULL, twl6030_usbotg_irq,
IRQF_TRIGGER_FALLING | IRQF_TRIGGER_RISING |
IRQF_ONESHOT,
@@ -395,6 +406,7 @@ static int twl6030_usb_probe(struct platform_device *pdev)
twl->asleep = 0;
twl6030_enable_irq(twl);
+ schedule_delayed_work(&twl->get_status_work, HZ);
dev_info(&pdev->dev, "Initialized TWL6030 USB module\n");
return 0;
@@ -404,6 +416,7 @@ static int twl6030_usb_remove(struct platform_device *pdev)
{
struct twl6030_usb *twl = platform_get_drvdata(pdev);
+ cancel_delayed_work(&twl->get_status_work);
twl6030_interrupt_mask(TWL6030_USBOTG_INT_MASK,
REG_INT_MSK_LINE_C);
twl6030_interrupt_mask(TWL6030_USBOTG_INT_MASK,
--
2.8.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 00/10] Get MUSB PM runtime working again
Hi all, Here's a series of fixes to get MUSB PM runtime working again. I can now test PM runtime with the 2430 glue layer with this set, so adding PM runtime support for other glue layers should be possible. Regards, Tony Tony Lindgren (10): usb: phy: Fix initial state for twl6030 usb: musb: Fix idling after host mode by increasing autosuspend delay usb: musb: Fix PM runtime handling for connected cable usb: musb: Remove unnecessary shutdown function usb: musb: Fix PM runtime autosuspend usb: musb: Split PM runtime between wrapper IP and musb core usb: musb: Manage USB phy from PM runtime calls usb: musb: Remove try_idle for 2430 glue layer usb: musb: Fix PM runtime with delayed work usb: musb: Remove pm_runtime_set_irq_safe drivers/usb/musb/musb_core.c | 67 ++-- drivers/usb/musb/musb_core.h | 1 + drivers/usb/musb/musb_gadget.c| 26 +-- drivers/usb/musb/omap2430.c | 155 +- drivers/usb/phy/phy-twl6030-usb.c | 17 - 5 files changed, 93 insertions(+), 173 deletions(-) -- 2.8.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 03/10] usb: musb: Fix PM runtime handling for connected cable
We may have drivers loaded but no configured gadgets
and MUSB may be in host mode. If gadgets are configured
during host mode, PM runtime will get confused.
Disconnect PM runtime from gadget state, and do it only
based on the cable.
Signed-off-by: Tony Lindgren
---
drivers/usb/musb/omap2430.c | 20 +---
1 file changed, 13 insertions(+), 7 deletions(-)
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index c84e0322..9d3645f 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -259,6 +259,13 @@ static void omap_musb_set_mailbox(struct omap2430_glue
*glue)
struct musb_hdrc_platform_data *pdata = dev_get_platdata(dev);
struct omap_musb_board_data *data = pdata->board_data;
struct usb_otg *otg = musb->xceiv->otg;
+ bool cable_connected;
+
+ cable_connected = ((glue->status & MUSB_ID_GROUND) ||
+ (glue->status & MUSB_VBUS_VALID));
+
+ if (cable_connected)
+ pm_runtime_get_sync(dev);
switch (glue->status) {
case MUSB_ID_GROUND:
@@ -268,7 +275,6 @@ static void omap_musb_set_mailbox(struct omap2430_glue
*glue)
musb->xceiv->otg->state = OTG_STATE_A_IDLE;
musb->xceiv->last_event = USB_EVENT_ID;
if (musb->gadget_driver) {
- pm_runtime_get_sync(dev);
omap_control_usb_set_mode(glue->control_otghs,
USB_MODE_HOST);
omap2430_musb_set_vbus(musb, 1);
@@ -281,8 +287,6 @@ static void omap_musb_set_mailbox(struct omap2430_glue
*glue)
otg->default_a = false;
musb->xceiv->otg->state = OTG_STATE_B_IDLE;
musb->xceiv->last_event = USB_EVENT_VBUS;
- if (musb->gadget_driver)
- pm_runtime_get_sync(dev);
omap_control_usb_set_mode(glue->control_otghs, USB_MODE_DEVICE);
break;
@@ -291,11 +295,8 @@ static void omap_musb_set_mailbox(struct omap2430_glue
*glue)
dev_dbg(dev, "VBUS Disconnect\n");
musb->xceiv->last_event = USB_EVENT_NONE;
- if (musb->gadget_driver) {
+ if (musb->gadget_driver)
omap2430_musb_set_vbus(musb, 0);
- pm_runtime_mark_last_busy(dev);
- pm_runtime_put_autosuspend(dev);
- }
if (data->interface_type == MUSB_INTERFACE_UTMI)
otg_set_vbus(musb->xceiv->otg, 0);
@@ -307,6 +308,11 @@ static void omap_musb_set_mailbox(struct omap2430_glue
*glue)
dev_dbg(dev, "ID float\n");
}
+ if (!cable_connected) {
+ pm_runtime_mark_last_busy(dev);
+ pm_runtime_put_autosuspend(dev);
+ }
+
atomic_notifier_call_chain(&musb->xceiv->notifier,
musb->xceiv->last_event, NULL);
}
--
2.8.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 05/10] usb: musb: Fix PM runtime autosuspend
Let's make the PM runtime use the standard autosuspend calls.
Commit 5de85b9d57ab ("PM / runtime: Re-init runtime PM states at probe
error and driver unbind") means we must pair use_autosuspend with
dont_use_autosuspend and then use put_sync to properly idle the
device.
Note that we'll be removing the PM runtime calls from the glue
layer to the MUSB core in the next patch.
Signed-off-by: Tony Lindgren
---
drivers/usb/musb/musb_core.c | 9 ++---
drivers/usb/musb/musb_gadget.c | 3 ++-
drivers/usb/musb/omap2430.c| 5 +++--
3 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index d7af8ed..90ccdb2 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -2214,7 +2214,8 @@ musb_init_controller(struct device *dev, int nIrq, void
__iomem *ctrl)
if (status)
goto fail5;
- pm_runtime_put(musb->controller);
+ pm_runtime_mark_last_busy(musb->controller);
+ pm_runtime_put_autosuspend(musb->controller);
/*
* For why this is currently needed, see commit 3e43a0725637
@@ -2242,6 +2243,7 @@ fail2_5:
usb_phy_shutdown(musb->xceiv);
err_usb_phy_init:
+ pm_runtime_dont_use_autosuspend(musb->controller);
pm_runtime_put_sync(musb->controller);
fail2:
@@ -2307,8 +2309,6 @@ static int musb_remove(struct platform_device *pdev)
spin_unlock_irqrestore(&musb->lock, flags);
musb_writeb(musb->mregs, MUSB_DEVCTL, 0);
musb_platform_exit(musb);
- pm_runtime_put(musb->controller);
- /* FIXME power down */
musb_phy_callback = NULL;
@@ -2320,6 +2320,9 @@ static int musb_remove(struct platform_device *pdev)
cancel_work_sync(&musb->irq_work);
cancel_delayed_work_sync(&musb->finish_resume_work);
cancel_delayed_work_sync(&musb->deassert_reset_work);
+ pm_runtime_dont_use_autosuspend(musb->controller);
+ pm_runtime_put_sync(musb->controller);
+ pm_runtime_disable(musb->controller);
musb_free(musb);
device_init_wakeup(dev, 0);
return 0;
diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c
index 152865b..fff5a8a 100644
--- a/drivers/usb/musb/musb_gadget.c
+++ b/drivers/usb/musb/musb_gadget.c
@@ -1963,7 +1963,8 @@ static int musb_gadget_stop(struct usb_gadget *g)
* that currently misbehaves.
*/
- pm_runtime_put(musb->controller);
+ pm_runtime_mark_last_busy(musb->controller);
+ pm_runtime_put_autosuspend(musb->controller);
return 0;
}
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index 9d3645f..c55d4f3 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -441,8 +441,9 @@ static int omap2430_musb_init(struct musb *musb)
phy_init(musb->phy);
phy_power_on(musb->phy);
- pm_runtime_put_noidle(musb->controller);
- pm_runtime_put_noidle(glue->dev);
+ pm_runtime_mark_last_busy(musb->controller);
+ pm_runtime_put_autosuspend(musb->controller);
+ pm_runtime_put(glue->dev);
return 0;
err1:
--
2.8.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 09/10] usb: musb: Fix PM runtime with delayed work
We have MUSB setting pm_runtime_irq_safe with the following
commits:
30a70b026b4c ("usb: musb: fix obex in g_nokia.ko causing kernel panic")
3e43a0725637 ("usb: musb: core: add pm_runtime_irq_safe()")
Let's fix things to use delayed work so we can remove the
pm_runtime_irq_safe.
Note that we may want to set this up in a generic way in the
gadget framework eventually.
Signed-off-by: Tony Lindgren
---
drivers/usb/musb/musb_core.h | 1 +
drivers/usb/musb/musb_gadget.c | 23 +--
2 files changed, 18 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index b6afe9e..2947384 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -312,6 +312,7 @@ struct musb {
struct work_struct irq_work;
struct delayed_work deassert_reset_work;
struct delayed_work finish_resume_work;
+ struct delayed_work gadget_work;
u16 hwvers;
u16 intrrxe;
diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c
index fff5a8a..2fc6557 100644
--- a/drivers/usb/musb/musb_gadget.c
+++ b/drivers/usb/musb/musb_gadget.c
@@ -1656,6 +1656,19 @@ static int musb_gadget_vbus_draw(struct usb_gadget
*gadget, unsigned mA)
return usb_phy_set_power(musb->xceiv, mA);
}
+static void musb_gadget_work(struct work_struct *work)
+{
+ struct musb *musb;
+ unsigned long flags;
+
+ musb = container_of(work, struct musb, gadget_work.work);
+ pm_runtime_get_sync(musb->controller);
+ spin_lock_irqsave(&musb->lock, flags);
+ musb_pullup(musb, musb->softconnect);
+ spin_unlock_irqrestore(&musb->lock, flags);
+ pm_runtime_put(musb->controller);
+}
+
static int musb_gadget_pullup(struct usb_gadget *gadget, int is_on)
{
struct musb *musb = gadget_to_musb(gadget);
@@ -1663,20 +1676,16 @@ static int musb_gadget_pullup(struct usb_gadget
*gadget, int is_on)
is_on = !!is_on;
- pm_runtime_get_sync(musb->controller);
-
/* NOTE: this assumes we are sensing vbus; we'd rather
* not pullup unless the B-session is active.
*/
spin_lock_irqsave(&musb->lock, flags);
if (is_on != musb->softconnect) {
musb->softconnect = is_on;
- musb_pullup(musb, is_on);
+ schedule_delayed_work(&musb->gadget_work, 0);
}
spin_unlock_irqrestore(&musb->lock, flags);
- pm_runtime_put(musb->controller);
-
return 0;
}
@@ -1845,7 +1854,7 @@ int musb_gadget_setup(struct musb *musb)
#elif IS_ENABLED(CONFIG_USB_MUSB_GADGET)
musb->g.is_otg = 0;
#endif
-
+ INIT_DELAYED_WORK(&musb->gadget_work, musb_gadget_work);
musb_g_init_endpoints(musb);
musb->is_active = 0;
@@ -1866,6 +1875,8 @@ void musb_gadget_cleanup(struct musb *musb)
{
if (musb->port_mode == MUSB_PORT_MODE_HOST)
return;
+
+ cancel_delayed_work_sync(&musb->gadget_work);
usb_del_gadget_udc(&musb->g);
}
--
2.8.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 02/10] usb: musb: Fix idling after host mode by increasing autosuspend delay
Looks like at least 2430 glue won't idle reliably with the 200 ms autosuspend delay. This causes deeper idle states being blocked for the whole SoC when disconnecting OTG A cable. Increasing the delay to 500 ms seems to idle both MUSB and the PHY reliably. This is probably because of time needed by the hardware based negotiation between MUSB and the PHY. Signed-off-by: Tony Lindgren --- drivers/usb/musb/musb_core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c index 39fd958..5fa6187 100644 --- a/drivers/usb/musb/musb_core.c +++ b/drivers/usb/musb/musb_core.c @@ -2030,7 +2030,7 @@ musb_init_controller(struct device *dev, int nIrq, void __iomem *ctrl) /* We need musb_read/write functions initialized for PM */ pm_runtime_use_autosuspend(musb->controller); - pm_runtime_set_autosuspend_delay(musb->controller, 200); + pm_runtime_set_autosuspend_delay(musb->controller, 500); pm_runtime_enable(musb->controller); /* The musb_platform_init() call: -- 2.8.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 08/10] usb: musb: Remove try_idle for 2430 glue layer
This is no longer needed with PM runtime at least for 2430 glue.
We can now rely only on PM runtime and cable detection.
The other glue layers can probably remove try_idle too, but that
needs to be tested for each platform before doing it.
Signed-off-by: Tony Lindgren
---
drivers/usb/musb/omap2430.c | 91 -
1 file changed, 91 deletions(-)
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index b274923..c352511 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -54,92 +54,6 @@ struct omap2430_glue {
static struct omap2430_glue*_glue;
-static struct timer_list musb_idle_timer;
-
-static void musb_do_idle(unsigned long _musb)
-{
- struct musb *musb = (void *)_musb;
- unsigned long flags;
- u8 power;
- u8 devctl;
-
- spin_lock_irqsave(&musb->lock, flags);
-
- switch (musb->xceiv->otg->state) {
- case OTG_STATE_A_WAIT_BCON:
-
- devctl = musb_readb(musb->mregs, MUSB_DEVCTL);
- if (devctl & MUSB_DEVCTL_BDEVICE) {
- musb->xceiv->otg->state = OTG_STATE_B_IDLE;
- MUSB_DEV_MODE(musb);
- } else {
- musb->xceiv->otg->state = OTG_STATE_A_IDLE;
- MUSB_HST_MODE(musb);
- }
- break;
- case OTG_STATE_A_SUSPEND:
- /* finish RESUME signaling? */
- if (musb->port1_status & MUSB_PORT_STAT_RESUME) {
- power = musb_readb(musb->mregs, MUSB_POWER);
- power &= ~MUSB_POWER_RESUME;
- dev_dbg(musb->controller, "root port resume stopped,
power %02x\n", power);
- musb_writeb(musb->mregs, MUSB_POWER, power);
- musb->is_active = 1;
- musb->port1_status &= ~(USB_PORT_STAT_SUSPEND
- | MUSB_PORT_STAT_RESUME);
- musb->port1_status |= USB_PORT_STAT_C_SUSPEND << 16;
- usb_hcd_poll_rh_status(musb->hcd);
- /* NOTE: it might really be A_WAIT_BCON ... */
- musb->xceiv->otg->state = OTG_STATE_A_HOST;
- }
- break;
- case OTG_STATE_A_HOST:
- devctl = musb_readb(musb->mregs, MUSB_DEVCTL);
- if (devctl & MUSB_DEVCTL_BDEVICE)
- musb->xceiv->otg->state = OTG_STATE_B_IDLE;
- else
- musb->xceiv->otg->state = OTG_STATE_A_WAIT_BCON;
- default:
- break;
- }
- spin_unlock_irqrestore(&musb->lock, flags);
-}
-
-
-static void omap2430_musb_try_idle(struct musb *musb, unsigned long timeout)
-{
- unsigned long default_timeout = jiffies + msecs_to_jiffies(3);
- static unsigned longlast_timer;
-
- if (timeout == 0)
- timeout = default_timeout;
-
- /* Never idle if active, or when VBUS timeout is not set as host */
- if (musb->is_active || ((musb->a_wait_bcon == 0)
- && (musb->xceiv->otg->state == OTG_STATE_A_WAIT_BCON)))
{
- dev_dbg(musb->controller, "%s active, deleting timer\n",
- usb_otg_state_string(musb->xceiv->otg->state));
- del_timer(&musb_idle_timer);
- last_timer = jiffies;
- return;
- }
-
- if (time_after(last_timer, timeout)) {
- if (!timer_pending(&musb_idle_timer))
- last_timer = timeout;
- else {
- dev_dbg(musb->controller, "Longer idle timer already
pending, ignoring\n");
- return;
- }
- }
- last_timer = timeout;
-
- dev_dbg(musb->controller, "%s inactive, for idle timer for %lu ms\n",
- usb_otg_state_string(musb->xceiv->otg->state),
- (unsigned long)jiffies_to_msecs(timeout - jiffies));
- mod_timer(&musb_idle_timer, timeout);
-}
-
static void omap2430_musb_set_vbus(struct musb *musb, int is_on)
{
struct usb_otg *otg = musb->xceiv->otg;
@@ -427,8 +341,6 @@ static int omap2430_musb_init(struct musb *musb)
musb_readl(musb->mregs, OTG_INTERFSEL),
musb_readl(musb->mregs, OTG_SIMENABLE));
- setup_timer(&musb_idle_timer, musb_do_idle, (unsigned long) musb);
-
if (glue->status != MUSB_UNKNOWN)
omap_musb_set_mailbox(glue);
@@ -493,7 +405,6 @@ static int omap2430_musb_exit(struct musb *musb)
struct device *dev = musb->controller;
struct omap2430_glue *glue = dev_get_drvdata(dev->parent);
- del_timer_sync(&musb_idle_timer);
pm_runtime_get_sync(glue->dev);
omap2430_low_level_exit(musb);
pm_runtime_put_sync_suspend(glue->dev);
@@ -515,8 +426
Re: [PATCH 03/10] usb: musb: Fix PM runtime handling for connected cable
Hello. On 04/28/2016 08:33 PM, Tony Lindgren wrote: We may have drivers loaded but no configured gadgets and MUSB may be in host mode. If gadgets are configured during host mode, PM runtime will get confused. Disconnect PM runtime from gadget state, and do it only based on the cable. Signed-off-by: Tony Lindgren --- drivers/usb/musb/omap2430.c | 20 +--- 1 file changed, 13 insertions(+), 7 deletions(-) diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c index c84e0322..9d3645f 100644 --- a/drivers/usb/musb/omap2430.c +++ b/drivers/usb/musb/omap2430.c @@ -259,6 +259,13 @@ static void omap_musb_set_mailbox(struct omap2430_glue *glue) struct musb_hdrc_platform_data *pdata = dev_get_platdata(dev); struct omap_musb_board_data *data = pdata->board_data; struct usb_otg *otg = musb->xceiv->otg; + bool cable_connected; + + cable_connected = ((glue->status & MUSB_ID_GROUND) || + (glue->status & MUSB_VBUS_VALID)); cable_connected = glue->status & (MUSB_ID_GROUND | MUSB_VBUS_VALID); [...] MBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/8] staging: rtl8192u: check return value of read_nic_word_E
The call of read_nic_word_E may fail, therefore its return value must be
checked and propagated in the case of error.
Signed-off-by: Salah Triki
---
drivers/staging/rtl8192u/r8180_93cx6.c | 30 --
drivers/staging/rtl8192u/r8180_93cx6.h | 2 +-
2 files changed, 25 insertions(+), 7 deletions(-)
diff --git a/drivers/staging/rtl8192u/r8180_93cx6.c
b/drivers/staging/rtl8192u/r8180_93cx6.c
index 97d9b3f..9e9959a 100644
--- a/drivers/staging/rtl8192u/r8180_93cx6.c
+++ b/drivers/staging/rtl8192u/r8180_93cx6.c
@@ -23,8 +23,11 @@
static void eprom_cs(struct net_device *dev, short bit)
{
u8 cmdreg;
+ int err;
- read_nic_byte_E(dev, EPROM_CMD, &cmdreg);
+ err = read_nic_byte_E(dev, EPROM_CMD, &cmdreg);
+ if (err)
+ return;
if (bit)
/* enable EPROM */
write_nic_byte_E(dev, EPROM_CMD, cmdreg | EPROM_CS_BIT);
@@ -40,8 +43,11 @@ static void eprom_cs(struct net_device *dev, short bit)
static void eprom_ck_cycle(struct net_device *dev)
{
u8 cmdreg;
+ int err;
- read_nic_byte_E(dev, EPROM_CMD, &cmdreg);
+ err = read_nic_byte_E(dev, EPROM_CMD, &cmdreg);
+ if (err)
+ return;
write_nic_byte_E(dev, EPROM_CMD, cmdreg | EPROM_CK_BIT);
force_pci_posting(dev);
udelay(EPROM_DELAY);
@@ -56,8 +62,11 @@ static void eprom_ck_cycle(struct net_device *dev)
static void eprom_w(struct net_device *dev, short bit)
{
u8 cmdreg;
+ int err;
- read_nic_byte_E(dev, EPROM_CMD, &cmdreg);
+ err = read_nic_byte_E(dev, EPROM_CMD, &cmdreg);
+ if (err)
+ return;
if (bit)
write_nic_byte_E(dev, EPROM_CMD, cmdreg | EPROM_W_BIT);
else
@@ -71,8 +80,12 @@ static void eprom_w(struct net_device *dev, short bit)
static short eprom_r(struct net_device *dev)
{
u8 bit;
+ int err;
+
+ err = read_nic_byte_E(dev, EPROM_CMD, &bit);
+ if (err)
+ return err;
- read_nic_byte_E(dev, EPROM_CMD, &bit);
udelay(EPROM_DELAY);
if (bit & EPROM_R_BIT)
@@ -93,7 +106,7 @@ static void eprom_send_bits_string(struct net_device *dev,
short b[], int len)
}
-u32 eprom_read(struct net_device *dev, u32 addr)
+int eprom_read(struct net_device *dev, u32 addr)
{
struct r8192_priv *priv = ieee80211_priv(dev);
short read_cmd[] = {1, 1, 0};
@@ -101,6 +114,7 @@ u32 eprom_read(struct net_device *dev, u32 addr)
int i;
int addr_len;
u32 ret;
+ int err;
ret = 0;
/* enable EPROM programming */
@@ -144,7 +158,11 @@ u32 eprom_read(struct net_device *dev, u32 addr)
* and reading data. (eeprom outs a dummy 0)
*/
eprom_ck_cycle(dev);
- ret |= (eprom_r(dev)<<(15-i));
+ err = eprom_r(dev);
+ if (err)
+ return err;
+
+ ret |= err<<(15-i);
}
eprom_cs(dev, 0);
diff --git a/drivers/staging/rtl8192u/r8180_93cx6.h
b/drivers/staging/rtl8192u/r8180_93cx6.h
index b840348..9cf7f58 100644
--- a/drivers/staging/rtl8192u/r8180_93cx6.h
+++ b/drivers/staging/rtl8192u/r8180_93cx6.h
@@ -40,4 +40,4 @@
#define EPROM_TXPW1 0x3d
-u32 eprom_read(struct net_device *dev, u32 addr); /* reads a 16 bits word */
+int eprom_read(struct net_device *dev, u32 addr); /* reads a 16 bits word */
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 8/8] staging: rtl8192u: propagate errors in write_nic_dword
Propagate errors from kzalloc and usb_control_msg and change the
return type of write_nic_dword from void to int.
Signed-off-by: Salah Triki
---
drivers/staging/rtl8192u/r8192U.h | 2 +-
drivers/staging/rtl8192u/r8192U_core.c | 9 ++---
2 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/rtl8192u/r8192U.h
b/drivers/staging/rtl8192u/r8192U.h
index 27f9aa5..eb0c351 100644
--- a/drivers/staging/rtl8192u/r8192U.h
+++ b/drivers/staging/rtl8192u/r8192U.h
@@ -1132,7 +1132,7 @@ int read_nic_word(struct net_device *dev, int x, u16
*data);
int write_nic_byte(struct net_device *dev, int x, u8 y);
int write_nic_byte_E(struct net_device *dev, int x, u8 y);
int write_nic_word(struct net_device *dev, int x, u16 y);
-void write_nic_dword(struct net_device *dev, int x, u32 y);
+int write_nic_dword(struct net_device *dev, int x, u32 y);
void force_pci_posting(struct net_device *dev);
void rtl8192_rtx_disable(struct net_device *);
diff --git a/drivers/staging/rtl8192u/r8192U_core.c
b/drivers/staging/rtl8192u/r8192U_core.c
index 9303715..695faed 100644
--- a/drivers/staging/rtl8192u/r8192U_core.c
+++ b/drivers/staging/rtl8192u/r8192U_core.c
@@ -357,7 +357,7 @@ int write_nic_word(struct net_device *dev, int indx, u16
data)
}
-void write_nic_dword(struct net_device *dev, int indx, u32 data)
+int write_nic_dword(struct net_device *dev, int indx, u32 data)
{
int status;
@@ -367,7 +367,7 @@ void write_nic_dword(struct net_device *dev, int indx, u32
data)
u32 *usbdata = kzalloc(sizeof(data), GFP_KERNEL);
if (!usbdata)
- return;
+ return -ENOMEM;
*usbdata = data;
status = usb_control_msg(udev, usb_sndctrlpipe(udev, 0),
@@ -377,10 +377,13 @@ void write_nic_dword(struct net_device *dev, int indx,
u32 data)
kfree(usbdata);
- if (status < 0)
+ if (status < 0){
netdev_err(dev, "write_nic_dword TimeOut! status: %d\n",
status);
+ return status;
+ }
+ return 0;
}
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/8] staging: rtl8192u: check return value eprom_read
The call of eprom_read may fail, therefore its return value must be
checked.
Signed-off-by: Salah Triki
---
drivers/staging/rtl8192u/r8192U_core.c | 147 +++--
1 file changed, 104 insertions(+), 43 deletions(-)
diff --git a/drivers/staging/rtl8192u/r8192U_core.c
b/drivers/staging/rtl8192u/r8192U_core.c
index 3a93218..1c09c61 100644
--- a/drivers/staging/rtl8192u/r8192U_core.c
+++ b/drivers/staging/rtl8192u/r8192U_core.c
@@ -2432,6 +2432,7 @@ static inline u16 endian_swap(u16 *data)
*data = (tmp >> 8) | (tmp << 8);
return *data;
}
+
static void rtl8192_read_eeprom_info(struct net_device *dev)
{
u16 wEPROM_ID = 0;
@@ -2440,9 +2441,13 @@ static void rtl8192_read_eeprom_info(struct net_device
*dev)
struct r8192_priv *priv = ieee80211_priv(dev);
u16 tmpValue = 0;
int i;
+ int ret;
RT_TRACE(COMP_EPROM, "===>%s()\n", __func__);
- wEPROM_ID = eprom_read(dev, 0); /* first read EEPROM ID out; */
+ ret = eprom_read(dev, 0); /* first read EEPROM ID out; */
+ if (ret)
+ return;
+ wEPROM_ID = (u16)ret;
RT_TRACE(COMP_EPROM, "EEPROM ID is 0x%x\n", wEPROM_ID);
if (wEPROM_ID != RTL8190_EEPROM_ID)
@@ -2453,14 +2458,25 @@ static void rtl8192_read_eeprom_info(struct net_device
*dev)
bLoad_From_EEPOM = true;
if (bLoad_From_EEPOM) {
- tmpValue = eprom_read(dev, EEPROM_VID >> 1);
+ ret = eprom_read(dev, EEPROM_VID >> 1);
+ if (ret)
+ return;
+ tmpValue = (u16)ret;
priv->eeprom_vid = endian_swap(&tmpValue);
- priv->eeprom_pid = eprom_read(dev, EEPROM_PID >> 1);
- tmpValue = eprom_read(dev, EEPROM_ChannelPlan >> 1);
+ ret = eprom_read(dev, EEPROM_PID >> 1);
+ if (ret)
+ return;
+ priv->eeprom_pid = (u16)ret;
+ ret = eprom_read(dev, EEPROM_ChannelPlan >> 1);
+ if (ret)
+ return;
+ tmpValue = (u16)ret;
priv->eeprom_ChannelPlan = (tmpValue & 0xff00) >> 8;
priv->btxpowerdata_readfromEEPORM = true;
- priv->eeprom_CustomerID =
- eprom_read(dev, (EEPROM_Customer_ID >> 1)) >> 8;
+ ret = eprom_read(dev, (EEPROM_Customer_ID >> 1)) >> 8;
+ if (ret)
+ return;
+ priv->eeprom_CustomerID = (u16)ret;
} else {
priv->eeprom_vid = 0;
priv->eeprom_pid = 0;
@@ -2478,10 +2494,11 @@ static void rtl8192_read_eeprom_info(struct net_device
*dev)
int i;
for (i = 0; i < 6; i += 2) {
- u16 tmp = 0;
-
- tmp = eprom_read(dev, (u16)((EEPROM_NODE_ADDRESS_BYTE_0
+ i) >> 1));
- *(u16 *)(&dev->dev_addr[i]) = tmp;
+ ret = eprom_read(dev,
+(u16)((EEPROM_NODE_ADDRESS_BYTE_0 + i)
>> 1));
+ if (ret)
+ return;
+ *(u16 *)(&dev->dev_addr[i]) = (u16)ret;
}
} else {
memcpy(dev->dev_addr, bMac_Tmp_Addr, 6);
@@ -2493,48 +2510,77 @@ static void rtl8192_read_eeprom_info(struct net_device
*dev)
if (priv->card_8192_version == (u8)VERSION_819xU_A) {
/* read Tx power gain offset of legacy OFDM to HT rate */
- if (bLoad_From_EEPOM)
- priv->EEPROMTxPowerDiff = (eprom_read(dev,
(EEPROM_TxPowerDiff >> 1)) & 0xff00) >> 8;
- else
+ if (bLoad_From_EEPOM) {
+ ret = eprom_read(dev, (EEPROM_TxPowerDiff >> 1));
+ if (ret)
+ return;
+ priv->EEPROMTxPowerDiff = ((u16)ret & 0xff00) >> 8;
+ } else {
priv->EEPROMTxPowerDiff = EEPROM_Default_TxPower;
+ }
RT_TRACE(COMP_EPROM, "TxPowerDiff:%d\n",
priv->EEPROMTxPowerDiff);
/* read ThermalMeter from EEPROM */
- if (bLoad_From_EEPOM)
- priv->EEPROMThermalMeter = (u8)(eprom_read(dev,
(EEPROM_ThermalMeter >> 1)) & 0x00ff);
- else
+ if (bLoad_From_EEPOM) {
+ ret = eprom_read(dev, (EEPROM_ThermalMeter >> 1));
+ if (ret)
+ return;
+ priv->EEPROMThermalMeter = (u8)((u16)ret & 0x00ff);
+ } else {
priv->EEPROMThermalMeter = EEPROM_Default_ThermalMeter;
+ }
RT_TRACE(COMP_EPROM, "ThermalMeter:%d\n",
priv->EEPROMThermalMeter);
/* for tx power track */
priv->TSSI_13dB
[PATCH 7/8] staging: rtl8192u: propagate errors in write_nic_word
Propagate errors from kzalloc and usb_control_msg and change the
return type of write_nic_word from void to int.
Signed-off-by: Salah Triki
---
drivers/staging/rtl8192u/r8192U.h | 2 +-
drivers/staging/rtl8192u/r8192U_core.c | 9 ++---
2 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/rtl8192u/r8192U.h
b/drivers/staging/rtl8192u/r8192U.h
index e0abcf5..27f9aa5 100644
--- a/drivers/staging/rtl8192u/r8192U.h
+++ b/drivers/staging/rtl8192u/r8192U.h
@@ -1131,7 +1131,7 @@ int read_nic_dword(struct net_device *dev, int x, u32
*data);
int read_nic_word(struct net_device *dev, int x, u16 *data);
int write_nic_byte(struct net_device *dev, int x, u8 y);
int write_nic_byte_E(struct net_device *dev, int x, u8 y);
-void write_nic_word(struct net_device *dev, int x, u16 y);
+int write_nic_word(struct net_device *dev, int x, u16 y);
void write_nic_dword(struct net_device *dev, int x, u32 y);
void force_pci_posting(struct net_device *dev);
diff --git a/drivers/staging/rtl8192u/r8192U_core.c
b/drivers/staging/rtl8192u/r8192U_core.c
index 4c6d444..9303715 100644
--- a/drivers/staging/rtl8192u/r8192U_core.c
+++ b/drivers/staging/rtl8192u/r8192U_core.c
@@ -329,7 +329,7 @@ int write_nic_byte(struct net_device *dev, int indx, u8
data)
}
-void write_nic_word(struct net_device *dev, int indx, u16 data)
+int write_nic_word(struct net_device *dev, int indx, u16 data)
{
int status;
@@ -339,7 +339,7 @@ void write_nic_word(struct net_device *dev, int indx, u16
data)
u16 *usbdata = kzalloc(sizeof(data), GFP_KERNEL);
if (!usbdata)
- return;
+ return -ENOMEM;
*usbdata = data;
status = usb_control_msg(udev, usb_sndctrlpipe(udev, 0),
@@ -348,9 +348,12 @@ void write_nic_word(struct net_device *dev, int indx, u16
data)
usbdata, 2, HZ / 2);
kfree(usbdata);
- if (status < 0)
+ if (status < 0){
netdev_err(dev, "write_nic_word TimeOut! status: %d\n", status);
+ return status;
+ }
+ return 0;
}
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V3 0/8] staging: rtl8192u: Checking return value/propagating errors
These patchs check the return value/propagate error of the functions read_nic_word_E, eprom_r, eprom_read, rtl8192_read_eeprom_info, write_nic_*. Salah Triki (8): staging: rtl8192u: check return value of read_nic_word_E staging: rtl8192u: check return value eprom_read staging: rtl8192u: propagate errors in rtl8192_read_eeprom_info staging: rtl8192u: check return value of rtl8192_read_eeprom_info staging: rtl8192u: propagate errors in write_nic_byte staging: rtl8192u: propagate errors in write_nic_byte_E staging: rtl8192u: propagate errors in write_nic_word staging: rtl8192u: propagate errors in write_nic_dword drivers/staging/rtl8192u/r8180_93cx6.c | 30 - drivers/staging/rtl8192u/r8180_93cx6.h | 2 +- drivers/staging/rtl8192u/r8192U.h | 8 +- drivers/staging/rtl8192u/r8192U_core.c | 193 +++-- 4 files changed, 164 insertions(+), 69 deletions(-) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/8] staging: rtl8192u: propagate errors in write_nic_byte_E
Propagate errors from kzalloc and usb_control_msg and change the
return type of write_nic_byte_E from void to int.
Signed-off-by: Salah Triki
---
drivers/staging/rtl8192u/r8192U.h | 2 +-
drivers/staging/rtl8192u/r8192U_core.c | 9 ++---
2 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/rtl8192u/r8192U.h
b/drivers/staging/rtl8192u/r8192U.h
index da9b92b..e0abcf5 100644
--- a/drivers/staging/rtl8192u/r8192U.h
+++ b/drivers/staging/rtl8192u/r8192U.h
@@ -1130,7 +1130,7 @@ int read_nic_byte_E(struct net_device *dev, int x, u8
*data);
int read_nic_dword(struct net_device *dev, int x, u32 *data);
int read_nic_word(struct net_device *dev, int x, u16 *data);
int write_nic_byte(struct net_device *dev, int x, u8 y);
-void write_nic_byte_E(struct net_device *dev, int x, u8 y);
+int write_nic_byte_E(struct net_device *dev, int x, u8 y);
void write_nic_word(struct net_device *dev, int x, u16 y);
void write_nic_dword(struct net_device *dev, int x, u32 y);
void force_pci_posting(struct net_device *dev);
diff --git a/drivers/staging/rtl8192u/r8192U_core.c
b/drivers/staging/rtl8192u/r8192U_core.c
index 678f4e7..4c6d444 100644
--- a/drivers/staging/rtl8192u/r8192U_core.c
+++ b/drivers/staging/rtl8192u/r8192U_core.c
@@ -254,7 +254,7 @@ u32 read_cam(struct net_device *dev, u8 addr)
return data;
}
-void write_nic_byte_E(struct net_device *dev, int indx, u8 data)
+int write_nic_byte_E(struct net_device *dev, int indx, u8 data)
{
int status;
struct r8192_priv *priv = (struct r8192_priv *)ieee80211_priv(dev);
@@ -262,7 +262,7 @@ void write_nic_byte_E(struct net_device *dev, int indx, u8
data)
u8 *usbdata = kzalloc(sizeof(data), GFP_KERNEL);
if (!usbdata)
- return;
+ return -ENOMEM;
*usbdata = data;
status = usb_control_msg(udev, usb_sndctrlpipe(udev, 0),
@@ -270,9 +270,12 @@ void write_nic_byte_E(struct net_device *dev, int indx, u8
data)
indx | 0xfe00, 0, usbdata, 1, HZ / 2);
kfree(usbdata);
- if (status < 0)
+ if (status < 0){
netdev_err(dev, "write_nic_byte_E TimeOut! status: %d\n",
status);
+ return status;
+ }
+ return 0;
}
int read_nic_byte_E(struct net_device *dev, int indx, u8 *data)
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/8] staging: rtl8192u: propagate errors in write_nic_byte
Propagate errors from kzalloc and usb_control_msg and change the
return type of write_nic_byte from void to int.
Signed-off-by: Salah Triki
---
drivers/staging/rtl8192u/r8192U.h | 2 +-
drivers/staging/rtl8192u/r8192U_core.c | 12 +++-
2 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/rtl8192u/r8192U.h
b/drivers/staging/rtl8192u/r8192U.h
index ee1c722..da9b92b 100644
--- a/drivers/staging/rtl8192u/r8192U.h
+++ b/drivers/staging/rtl8192u/r8192U.h
@@ -1129,7 +1129,7 @@ int read_nic_byte(struct net_device *dev, int x, u8
*data);
int read_nic_byte_E(struct net_device *dev, int x, u8 *data);
int read_nic_dword(struct net_device *dev, int x, u32 *data);
int read_nic_word(struct net_device *dev, int x, u16 *data);
-void write_nic_byte(struct net_device *dev, int x, u8 y);
+int write_nic_byte(struct net_device *dev, int x, u8 y);
void write_nic_byte_E(struct net_device *dev, int x, u8 y);
void write_nic_word(struct net_device *dev, int x, u16 y);
void write_nic_dword(struct net_device *dev, int x, u32 y);
diff --git a/drivers/staging/rtl8192u/r8192U_core.c
b/drivers/staging/rtl8192u/r8192U_core.c
index 1f23a65..678f4e7 100644
--- a/drivers/staging/rtl8192u/r8192U_core.c
+++ b/drivers/staging/rtl8192u/r8192U_core.c
@@ -299,7 +299,7 @@ int read_nic_byte_E(struct net_device *dev, int indx, u8
*data)
return 0;
}
/* as 92U has extend page from 4 to 16, so modify functions below. */
-void write_nic_byte(struct net_device *dev, int indx, u8 data)
+int write_nic_byte(struct net_device *dev, int indx, u8 data)
{
int status;
@@ -308,7 +308,7 @@ void write_nic_byte(struct net_device *dev, int indx, u8
data)
u8 *usbdata = kzalloc(sizeof(data), GFP_KERNEL);
if (!usbdata)
- return;
+ return -ENOMEM;
*usbdata = data;
status = usb_control_msg(udev, usb_sndctrlpipe(udev, 0),
@@ -317,10 +317,12 @@ void write_nic_byte(struct net_device *dev, int indx, u8
data)
usbdata, 1, HZ / 2);
kfree(usbdata);
- if (status < 0)
+ if (status < 0){
netdev_err(dev, "write_nic_byte TimeOut! status: %d\n", status);
-
-
+ return status;
+ }
+
+ return 0;
}
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/8] staging: rtl8192u: propagate errors in rtl8192_read_eeprom_info
Propagate error from eprom_read and change the return type of
rtl8192_read_eeprom_info from void to int.
Signed-off-by: Salah Triki
---
drivers/staging/rtl8192u/r8192U_core.c | 37 +-
1 file changed, 19 insertions(+), 18 deletions(-)
diff --git a/drivers/staging/rtl8192u/r8192U_core.c
b/drivers/staging/rtl8192u/r8192U_core.c
index 1c09c61..e7168da 100644
--- a/drivers/staging/rtl8192u/r8192U_core.c
+++ b/drivers/staging/rtl8192u/r8192U_core.c
@@ -2433,7 +2433,7 @@ static inline u16 endian_swap(u16 *data)
return *data;
}
-static void rtl8192_read_eeprom_info(struct net_device *dev)
+static int rtl8192_read_eeprom_info(struct net_device *dev)
{
u16 wEPROM_ID = 0;
u8 bMac_Tmp_Addr[6] = {0x00, 0xe0, 0x4c, 0x00, 0x00, 0x02};
@@ -2446,7 +2446,7 @@ static void rtl8192_read_eeprom_info(struct net_device
*dev)
RT_TRACE(COMP_EPROM, "===>%s()\n", __func__);
ret = eprom_read(dev, 0); /* first read EEPROM ID out; */
if (ret)
- return;
+ return ret;
wEPROM_ID = (u16)ret;
RT_TRACE(COMP_EPROM, "EEPROM ID is 0x%x\n", wEPROM_ID);
@@ -2460,22 +2460,22 @@ static void rtl8192_read_eeprom_info(struct net_device
*dev)
if (bLoad_From_EEPOM) {
ret = eprom_read(dev, EEPROM_VID >> 1);
if (ret)
- return;
+ return ret;
tmpValue = (u16)ret;
priv->eeprom_vid = endian_swap(&tmpValue);
ret = eprom_read(dev, EEPROM_PID >> 1);
if (ret)
- return;
+ return ret;
priv->eeprom_pid = (u16)ret;
ret = eprom_read(dev, EEPROM_ChannelPlan >> 1);
if (ret)
- return;
+ return ret;
tmpValue = (u16)ret;
priv->eeprom_ChannelPlan = (tmpValue & 0xff00) >> 8;
priv->btxpowerdata_readfromEEPORM = true;
ret = eprom_read(dev, (EEPROM_Customer_ID >> 1)) >> 8;
if (ret)
- return;
+ return ret;
priv->eeprom_CustomerID = (u16)ret;
} else {
priv->eeprom_vid = 0;
@@ -2497,7 +2497,7 @@ static void rtl8192_read_eeprom_info(struct net_device
*dev)
ret = eprom_read(dev,
(u16)((EEPROM_NODE_ADDRESS_BYTE_0 + i)
>> 1));
if (ret)
- return;
+ return ret;
*(u16 *)(&dev->dev_addr[i]) = (u16)ret;
}
} else {
@@ -2513,7 +2513,7 @@ static void rtl8192_read_eeprom_info(struct net_device
*dev)
if (bLoad_From_EEPOM) {
ret = eprom_read(dev, (EEPROM_TxPowerDiff >> 1));
if (ret)
- return;
+ return ret;
priv->EEPROMTxPowerDiff = ((u16)ret & 0xff00) >> 8;
} else {
priv->EEPROMTxPowerDiff = EEPROM_Default_TxPower;
@@ -2523,7 +2523,7 @@ static void rtl8192_read_eeprom_info(struct net_device
*dev)
if (bLoad_From_EEPOM) {
ret = eprom_read(dev, (EEPROM_ThermalMeter >> 1));
if (ret)
- return;
+ return ret;
priv->EEPROMThermalMeter = (u8)((u16)ret & 0x00ff);
} else {
priv->EEPROMThermalMeter = EEPROM_Default_ThermalMeter;
@@ -2535,7 +2535,7 @@ static void rtl8192_read_eeprom_info(struct net_device
*dev)
if (bLoad_From_EEPOM) {
ret = eprom_read(dev, (EEPROM_PwDiff >> 1));
if (ret)
- return;
+ return ret;
priv->EEPROMPwDiff = ((u16)ret & 0x0f00) >> 8;
} else {
priv->EEPROMPwDiff = EEPROM_Default_PwDiff;
@@ -2545,7 +2545,7 @@ static void rtl8192_read_eeprom_info(struct net_device
*dev)
if (bLoad_From_EEPOM) {
ret = eprom_read(dev, (EEPROM_CrystalCap >> 1));
if (ret)
- return;
+ return ret;
priv->EEPROMCrystalCap = ((u16)ret & 0x0f);
} else {
priv->EEPROMCrystalCap = EEPROM_Default_CrystalCap;
@@ -2555,7 +2555,7 @@ static void rtl8192_read_eeprom_info(struct net_device
*dev)
if (bLoad_From_EEPOM) {
ret = eprom_read(dev, (EEPROM_TxPwIndex_Ver >> 1));
if (ret)
- return;
+
[PATCH 4/8] staging: rtl8192u: check return value of rtl8192_read_eeprom_info
The call of rtl8192_read_eeprom_info may fail, therefore its return value must
be checked and propagated in the case of error.
Signed-off-by: Salah Triki
---
drivers/staging/rtl8192u/r8192U_core.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/rtl8192u/r8192U_core.c
b/drivers/staging/rtl8192u/r8192U_core.c
index e7168da..1f23a65 100644
--- a/drivers/staging/rtl8192u/r8192U_core.c
+++ b/drivers/staging/rtl8192u/r8192U_core.c
@@ -2741,6 +2741,8 @@ static short rtl8192_init(struct net_device *dev)
{
struct r8192_priv *priv = ieee80211_priv(dev);
+ int err;
+
memset(&(priv->stats), 0, sizeof(struct Stats));
memset(priv->txqueue_to_outpipemap, 0, 9);
#ifdef PIPE12
@@ -2761,7 +2763,9 @@ static short rtl8192_init(struct net_device *dev)
rtl8192_init_priv_lock(priv);
rtl8192_init_priv_task(dev);
rtl8192_get_eeprom_size(dev);
- rtl8192_read_eeprom_info(dev);
+ err = rtl8192_read_eeprom_info(dev);
+ if (err)
+ return err;
rtl8192_get_channel_map(dev);
init_hal_dm(dev);
setup_timer(&priv->watch_dog_timer, watch_dog_timer_callback,
--
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 03/10] usb: musb: Fix PM runtime handling for connected cable
* Sergei Shtylyov [160428 10:55]: > Hello. > > On 04/28/2016 08:33 PM, Tony Lindgren wrote: > > >We may have drivers loaded but no configured gadgets > >and MUSB may be in host mode. If gadgets are configured > >during host mode, PM runtime will get confused. > > > >Disconnect PM runtime from gadget state, and do it only > >based on the cable. > > > >Signed-off-by: Tony Lindgren > >--- > > drivers/usb/musb/omap2430.c | 20 +--- > > 1 file changed, 13 insertions(+), 7 deletions(-) > > > >diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c > >index c84e0322..9d3645f 100644 > >--- a/drivers/usb/musb/omap2430.c > >+++ b/drivers/usb/musb/omap2430.c > >@@ -259,6 +259,13 @@ static void omap_musb_set_mailbox(struct omap2430_glue > >*glue) > > struct musb_hdrc_platform_data *pdata = dev_get_platdata(dev); > > struct omap_musb_board_data *data = pdata->board_data; > > struct usb_otg *otg = musb->xceiv->otg; > >+bool cable_connected; > >+ > >+cable_connected = ((glue->status & MUSB_ID_GROUND) || > >+ (glue->status & MUSB_VBUS_VALID)); > > cable_connected = glue->status & (MUSB_ID_GROUND | > MUSB_VBUS_VALID); Thanks, actually that's an enumeration so needs fixing. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] usbip: vudc: rename find_endpoint to vep_find_endpoint
Avoid namespace pollution.
Signed-off-by: Igor Kotrasinski
---
drivers/usb/usbip/vudc.h | 2 +-
drivers/usb/usbip/vudc_dev.c | 2 +-
drivers/usb/usbip/vudc_rx.c | 2 +-
drivers/usb/usbip/vudc_transfer.c | 6 +++---
4 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/usbip/vudc.h b/drivers/usb/usbip/vudc.h
index 3fd5772..19140d6 100644
--- a/drivers/usb/usbip/vudc.h
+++ b/drivers/usb/usbip/vudc.h
@@ -174,7 +174,7 @@ void v_stop_timer(struct vudc *udc);
struct urbp *alloc_urbp(void);
void free_urbp_and_urb(struct urbp *urb_p);
-struct vep *find_endpoint(struct vudc *udc, u8 address);
+struct vep *vep_find_endpoint(struct vudc *udc, u8 address);
struct vudc_device *alloc_vudc_device(int devid);
void put_vudc_device(struct vudc_device *udc_dev);
diff --git a/drivers/usb/usbip/vudc_dev.c b/drivers/usb/usbip/vudc_dev.c
index 231571f..e6bfdbf 100644
--- a/drivers/usb/usbip/vudc_dev.c
+++ b/drivers/usb/usbip/vudc_dev.c
@@ -114,7 +114,7 @@ static void stop_activity(struct vudc *udc)
}
}
-struct vep *find_endpoint(struct vudc *udc, u8 address)
+struct vep *vep_find_endpoint(struct vudc *udc, u8 address)
{
int i;
diff --git a/drivers/usb/usbip/vudc_rx.c b/drivers/usb/usbip/vudc_rx.c
index 2ab5023..f8d7f41 100644
--- a/drivers/usb/usbip/vudc_rx.c
+++ b/drivers/usb/usbip/vudc_rx.c
@@ -117,7 +117,7 @@ static int v_recv_cmd_submit(struct vudc *udc,
address |= USB_DIR_IN;
spin_lock_irq(&udc->lock);
- urb_p->ep = find_endpoint(udc, address);
+ urb_p->ep = vep_find_endpoint(udc, address);
if (!urb_p->ep) {
/* we don't know the type, there may be isoc data! */
dev_err(&udc->pdev->dev, "request to nonexistent endpoint");
diff --git a/drivers/usb/usbip/vudc_transfer.c
b/drivers/usb/usbip/vudc_transfer.c
index 842e811..9d42c92 100644
--- a/drivers/usb/usbip/vudc_transfer.c
+++ b/drivers/usb/usbip/vudc_transfer.c
@@ -110,7 +110,7 @@ static int handle_control_request(struct vudc *udc, struct
urb *urb,
}
} else if (setup->bRequestType == EP_REQUEST) {
/* endpoint halt */
- ep2 = find_endpoint(udc, w_index);
+ ep2 = vep_find_endpoint(udc, w_index);
if (!ep2 || ep2->ep.name == udc->ep[0].ep.name) {
ret_val = -EOPNOTSUPP;
break;
@@ -143,7 +143,7 @@ static int handle_control_request(struct vudc *udc, struct
urb *urb,
}
} else if (setup->bRequestType == EP_REQUEST) {
/* endpoint halt */
- ep2 = find_endpoint(udc, w_index);
+ ep2 = vep_find_endpoint(udc, w_index);
if (!ep2) {
ret_val = -EOPNOTSUPP;
break;
@@ -167,7 +167,7 @@ static int handle_control_request(struct vudc *udc, struct
urb *urb,
buf = (char *)urb->transfer_buffer;
if (urb->transfer_buffer_length > 0) {
if (setup->bRequestType == EP_INREQUEST) {
- ep2 = find_endpoint(udc, w_index);
+ ep2 = vep_find_endpoint(udc, w_index);
if (!ep2) {
ret_val = -EOPNOTSUPP;
break;
--
2.7.3
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3] Follow-on patches for usbip-vudc driver
These are follow-on patches to the series of patches adding the usbip-vudc driver. They fix a namespace pollution issue, change one of the sysfs attributes to binary type and provide documentation for attributes. Igor Kotrasinski (3): usbip: vudc: rename find_endpoint to vep_find_endpoint usbip: vudc: make dev_desc attribute binary usbip: vudc: add sysfs attribute descriptions .../ABI/stable/sysfs-driver-usb-usbip-vudc | 23 ++ MAINTAINERS| 1 + drivers/usb/usbip/vudc.h | 2 +- drivers/usb/usbip/vudc_dev.c | 2 +- drivers/usb/usbip/vudc_rx.c| 2 +- drivers/usb/usbip/vudc_sysfs.c | 20 +-- drivers/usb/usbip/vudc_transfer.c | 6 +++--- 7 files changed, 44 insertions(+), 12 deletions(-) create mode 100644 Documentation/ABI/stable/sysfs-driver-usb-usbip-vudc -- 2.7.3 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] usbip: vudc: make dev_desc attribute binary
We read a struct usb_device_descriptor from it, so make it an actual
binary attribute.
Signed-off-by: Igor Kotrasinski
---
drivers/usb/usbip/vudc_sysfs.c | 20 ++--
1 file changed, 14 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/usbip/vudc_sysfs.c b/drivers/usb/usbip/vudc_sysfs.c
index 79b4955..b101af0 100644
--- a/drivers/usb/usbip/vudc_sysfs.c
+++ b/drivers/usb/usbip/vudc_sysfs.c
@@ -99,17 +99,20 @@ int descriptor_cache(struct vudc *udc)
/*
* Fetches device descriptor from the gadget driver.
*/
-static ssize_t dev_desc_show(struct device *dev,
- struct device_attribute *attr, char *out)
+static ssize_t dev_desc_read(struct file *file, struct kobject *kobj,
+struct bin_attribute *attr, char *out,
+loff_t off, size_t count)
{
+ struct device *dev = kobj_to_dev(kobj);
struct vudc *udc = (struct vudc *) dev_get_drvdata(dev);
+ char *desc_ptr = (char *) &udc->dev_desc;
if (!udc->driver)
return -ENODEV;
- memcpy(out, &udc->dev_desc, sizeof(udc->dev_desc));
- return sizeof(struct usb_device_descriptor);
+ memcpy(out, desc_ptr + off, count);
+ return count;
}
-static DEVICE_ATTR_RO(dev_desc);
+static BIN_ATTR_RO(dev_desc, sizeof(struct usb_device_descriptor));
static ssize_t store_sockfd(struct device *dev, struct device_attribute *attr,
const char *in, size_t count)
@@ -194,12 +197,17 @@ static ssize_t usbip_status_show(struct device *dev,
static DEVICE_ATTR_RO(usbip_status);
static struct attribute *dev_attrs[] = {
- &dev_attr_dev_desc.attr,
&dev_attr_usbip_sockfd.attr,
&dev_attr_usbip_status.attr,
NULL,
};
+static struct bin_attribute *dev_bin_attrs[] = {
+ &bin_attr_dev_desc,
+ NULL,
+};
+
const struct attribute_group vudc_attr_group = {
.attrs = dev_attrs,
+ .bin_attrs = dev_bin_attrs,
};
--
2.7.3
--
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 1/3] usbip: vudc: rename find_endpoint to vep_find_endpoint
Duplicated. Already fixed yesterday:
http://marc.info/?l=linux-usb&m=146178014931956&w=2
Best regards,
Krzysztof Opasiak
On Thu, Apr 28, 2016 at 8:44 PM, Igor Kotrasinski wrote:
> Avoid namespace pollution.
>
> Signed-off-by: Igor Kotrasinski
> ---
> drivers/usb/usbip/vudc.h | 2 +-
> drivers/usb/usbip/vudc_dev.c | 2 +-
> drivers/usb/usbip/vudc_rx.c | 2 +-
> drivers/usb/usbip/vudc_transfer.c | 6 +++---
> 4 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/usb/usbip/vudc.h b/drivers/usb/usbip/vudc.h
> index 3fd5772..19140d6 100644
> --- a/drivers/usb/usbip/vudc.h
> +++ b/drivers/usb/usbip/vudc.h
> @@ -174,7 +174,7 @@ void v_stop_timer(struct vudc *udc);
> struct urbp *alloc_urbp(void);
> void free_urbp_and_urb(struct urbp *urb_p);
>
> -struct vep *find_endpoint(struct vudc *udc, u8 address);
> +struct vep *vep_find_endpoint(struct vudc *udc, u8 address);
>
> struct vudc_device *alloc_vudc_device(int devid);
> void put_vudc_device(struct vudc_device *udc_dev);
> diff --git a/drivers/usb/usbip/vudc_dev.c b/drivers/usb/usbip/vudc_dev.c
> index 231571f..e6bfdbf 100644
> --- a/drivers/usb/usbip/vudc_dev.c
> +++ b/drivers/usb/usbip/vudc_dev.c
> @@ -114,7 +114,7 @@ static void stop_activity(struct vudc *udc)
> }
> }
>
> -struct vep *find_endpoint(struct vudc *udc, u8 address)
> +struct vep *vep_find_endpoint(struct vudc *udc, u8 address)
> {
> int i;
>
> diff --git a/drivers/usb/usbip/vudc_rx.c b/drivers/usb/usbip/vudc_rx.c
> index 2ab5023..f8d7f41 100644
> --- a/drivers/usb/usbip/vudc_rx.c
> +++ b/drivers/usb/usbip/vudc_rx.c
> @@ -117,7 +117,7 @@ static int v_recv_cmd_submit(struct vudc *udc,
> address |= USB_DIR_IN;
>
> spin_lock_irq(&udc->lock);
> - urb_p->ep = find_endpoint(udc, address);
> + urb_p->ep = vep_find_endpoint(udc, address);
> if (!urb_p->ep) {
> /* we don't know the type, there may be isoc data! */
> dev_err(&udc->pdev->dev, "request to nonexistent endpoint");
> diff --git a/drivers/usb/usbip/vudc_transfer.c
> b/drivers/usb/usbip/vudc_transfer.c
> index 842e811..9d42c92 100644
> --- a/drivers/usb/usbip/vudc_transfer.c
> +++ b/drivers/usb/usbip/vudc_transfer.c
> @@ -110,7 +110,7 @@ static int handle_control_request(struct vudc *udc,
> struct urb *urb,
> }
> } else if (setup->bRequestType == EP_REQUEST) {
> /* endpoint halt */
> - ep2 = find_endpoint(udc, w_index);
> + ep2 = vep_find_endpoint(udc, w_index);
> if (!ep2 || ep2->ep.name == udc->ep[0].ep.name) {
> ret_val = -EOPNOTSUPP;
> break;
> @@ -143,7 +143,7 @@ static int handle_control_request(struct vudc *udc,
> struct urb *urb,
> }
> } else if (setup->bRequestType == EP_REQUEST) {
> /* endpoint halt */
> - ep2 = find_endpoint(udc, w_index);
> + ep2 = vep_find_endpoint(udc, w_index);
> if (!ep2) {
> ret_val = -EOPNOTSUPP;
> break;
> @@ -167,7 +167,7 @@ static int handle_control_request(struct vudc *udc,
> struct urb *urb,
> buf = (char *)urb->transfer_buffer;
> if (urb->transfer_buffer_length > 0) {
> if (setup->bRequestType == EP_INREQUEST) {
> - ep2 = find_endpoint(udc, w_index);
> + ep2 = vep_find_endpoint(udc, w_index);
> if (!ep2) {
> ret_val = -EOPNOTSUPP;
> break;
> --
> 2.7.3
>
--
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: usbip: vudc: Add VUDC main file
Hello Igor Kotrasinski,
The patch 80fd9cd52de6: "usbip: vudc: Add VUDC main file" from Mar 8,
2016, leads to the following static checker warning:
drivers/usb/usbip/vudc_main.c:88 init()
warn: perhaps platform_device_put() was intended here?
drivers/usb/usbip/vudc_main.c
56 retval = platform_driver_register(&vudc_driver);
57 if (retval < 0)
58 goto out;
59
60 for (i = 0; i < vudc_number; i++) {
61 udc_dev = alloc_vudc_device(i);
62 if (!udc_dev) {
63 retval = -ENOMEM;
64 goto cleanup;
65 }
66
67 retval = platform_device_add(udc_dev->pdev);
68 if (retval < 0) {
69 put_vudc_device(udc_dev);
70 goto cleanup;
71 }
72
73 list_add_tail(&udc_dev->dev_entry, &vudc_devices);
74 if (!platform_get_drvdata(udc_dev->pdev)) {
75 /*
76 * The udc was added successfully but its probe
77 * function failed for some reason.
78 */
79 retval = -EINVAL;
80 goto cleanup;
81 }
82 }
83 goto out;
84
85 cleanup:
86 list_for_each_entry_safe(udc_dev, udc_dev2, &vudc_devices,
dev_entry) {
87 list_del(&udc_dev->dev_entry);
88 platform_device_del(udc_dev->pdev);
^^
I had to look through my git log to find why Smatch generates this
warning. Apparently the check was inspired by e9a1c5129de1caf
"wm8350-regulator: fix wm8350_register_regulator error handling". I
wrote it in 2010 and this is the first time this warning has ever been
triggered. I'm very excited! But I have no idea if it's a false
positive or a real bug.
89 put_vudc_device(udc_dev);
90 }
regards,
dan carpenter
--
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 0/3] Follow-on patches for usbip-vudc driver
On Thu, Apr 28, 2016 at 08:44:12PM +0200, Igor Kotrasinski wrote: > These are follow-on patches to the series of patches adding the usbip-vudc > driver. They fix a namespace pollution issue, change one of the sysfs > attributes to binary type and provide documentation for attributes. > > Igor Kotrasinski (3): > usbip: vudc: rename find_endpoint to vep_find_endpoint > usbip: vudc: make dev_desc attribute binary > usbip: vudc: add sysfs attribute descriptions I only see 2 patches here, what happened to patch 2/3? 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 0/3] Follow-on patches for usbip-vudc driver
W dniu 28.04.2016 o 20:44, Igor Kotrasinski pisze: > These are follow-on patches to the series of patches adding the usbip-vudc > driver. They fix a namespace pollution issue, change one of the sysfs > attributes to binary type and provide documentation for attributes. > > Igor Kotrasinski (3): > usbip: vudc: rename find_endpoint to vep_find_endpoint > usbip: vudc: make dev_desc attribute binary > usbip: vudc: add sysfs attribute descriptions > > .../ABI/stable/sysfs-driver-usb-usbip-vudc | 23 > ++ > MAINTAINERS| 1 + > drivers/usb/usbip/vudc.h | 2 +- > drivers/usb/usbip/vudc_dev.c | 2 +- > drivers/usb/usbip/vudc_rx.c| 2 +- > drivers/usb/usbip/vudc_sysfs.c | 20 +-- > drivers/usb/usbip/vudc_transfer.c | 6 +++--- > 7 files changed, 44 insertions(+), 12 deletions(-) > create mode 100644 Documentation/ABI/stable/sysfs-driver-usb-usbip-vudc > Dropping, some of the patches are duplicate. I'll resend the non-duplicate ones. -- 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 0/3] Follow-on patches for usbip-vudc driver
W dniu 28.04.2016 o 21:28, Greg KH pisze: > On Thu, Apr 28, 2016 at 08:44:12PM +0200, Igor Kotrasinski wrote: >> These are follow-on patches to the series of patches adding the usbip-vudc >> driver. They fix a namespace pollution issue, change one of the sysfs >> attributes to binary type and provide documentation for attributes. >> >> Igor Kotrasinski (3): >> usbip: vudc: rename find_endpoint to vep_find_endpoint >> usbip: vudc: make dev_desc attribute binary >> usbip: vudc: add sysfs attribute descriptions > I only see 2 patches here, what happened to patch 2/3? > > thanks, > > greg k-h I'm afraid gmail is marking some of my mails as spam and refusing to send them. This patchset turned out to have duplicates either way, I'll resend the patchset with only the new patches. Igor Kotrasiński -- 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 1/3] usbip: vudc: rename find_endpoint to vep_find_endpoint
On Thu, Apr 28, 2016 at 09:01:01PM +0200, Krzysztof Opasiak wrote: > Duplicated. Already fixed yesterday: > > http://marc.info/?l=linux-usb&m=146178014931956&w=2 I just applied this one. 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 0/3] Follow-on patches for usbip-vudc driver
On Thu, Apr 28, 2016 at 12:28:01PM -0700, Greg KH wrote: > On Thu, Apr 28, 2016 at 08:44:12PM +0200, Igor Kotrasinski wrote: > > These are follow-on patches to the series of patches adding the usbip-vudc > > driver. They fix a namespace pollution issue, change one of the sysfs > > attributes to binary type and provide documentation for attributes. > > > > Igor Kotrasinski (3): > > usbip: vudc: rename find_endpoint to vep_find_endpoint > > usbip: vudc: make dev_desc attribute binary > > usbip: vudc: add sysfs attribute descriptions > > I only see 2 patches here, what happened to patch 2/3? Make that 3/3, I have 2/3, sorry. -- 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 2/3] usbip: vudc: make dev_desc attribute binary
On Thu, Apr 28, 2016 at 08:44:14PM +0200, Igor Kotrasinski wrote: > We read a struct usb_device_descriptor from it, so make it an actual > binary attribute. > > Signed-off-by: Igor Kotrasinski > --- > drivers/usb/usbip/vudc_sysfs.c | 20 ++-- > 1 file changed, 14 insertions(+), 6 deletions(-) Doesn't apply to my tree anymore :( -- 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: dwc3: usb/dwc3: fake dissconnect event when turn off pullup
On 4/27/2016 11:48 PM, Felipe Balbi wrote: > > Hi, > > (we don't top-post on this forum ;-) > > "Du, Changbin" writes: >> Hi, Balbi, >> >> The step to reproduce this issue is: >> 1) connect device to a host and wait its enumeration. >> 2) trigger software disconnect by calling function >> usb_gadget_disconnect(), which finally call >>dwc3_gadget_pullup(false). Do not reconnect device >> (I mean no enumeration go on, keep bit Run/Stop 0.). >> >> At here, gadget driver's disconnect callback should be >> Called, right? We has been disconnected. But no, as >> You said " not generating disconnect IRQ after you >> drop Run/Stop is expected". >> >> And I am testing on an Android device, Android only >> use dwc3_gadget_pullup(false) to issue a soft disconnection. >> This confused user that the UI still show usb as connected >> State, caused by missing a disconnect event. > > okay, so I know what this is. This is caused by Android gadget itself > not notifying the gadget that a disconnect has happened. Just look at > udc-core's soft_connect implementation for the sysfs interface, and > you'll see what I mean. > > This should be fixed at Android gadget itself. The only thing we could > do is introduce a new usb_gadget_soft_connect()/disconnect() to wrap the > logic so it's easier for Android gadget to use; but even that I'm a > little bit reluctant to do because Android should be using our > soft_connect interface instead of reimplementing it (wrongly) by its > own. > We've run in to the same issue with our usb_gadget_driver. If the usb_gadget_disconnect() API function, which seems like it is intended to be called by the gadget_driver, does cause the gadget to disconnect, it seems reasonable to expect the gadget or the UDC core to notify the gadget_driver via the callback. As you mentioned this is handled in the soft_disconnect sysfs. Why shouldn't usb_gadget_disconnect() do the same thing, if not the gadget itself? Exposing the sysfs as an API function would work too. Though both functions are "soft" disconnects and both are called "disconnect". In our gadget_driver we do the workaround where we notify ourself that we called the usb_gadget_disconnect() and that we should now be disconnected. It just seems more correct that we shouldn't have to handle that. By the way, I'm not completely sure of the correct terminology, but I'm referring to the struct usb_gadget (dwc3, dwc2, etc) as the "gadget" and the struct usb_gadget_driver as the "gadget_driver" (normally this would be the composite gadget framework, but we are using our own driver in this case). Is there a less confusing way to refer to these :) 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: [PATCHv3] usb: Add driver for UCSI
On Thu, Apr 21, 2016 at 03:43:40PM +0300, Heikki Krogerus wrote: > USB Type-C Connector System Software Interface (UCSI) is > specification that defines the registers and data structures > that can be used to control USB Type-C ports on a system. > UCSI is used on several Intel Broxton SoC based platforms. > Things that UCSI can be used to control include at least USB > Data Role swapping, Power Role swapping and controlling of > Alternate Modes on top of providing general details about > the port and the partners that are attached to it. > > The initial purpose of the UCSI driver is to make sure USB > is in host mode on desktop and server systems that are USB > dual role capable, and provide UCSI interface. > > The goal is to integrate the driver later to an USB Type-C > framework for Linux kernel, and at the same time add support > for more extensive USB Type-C port control that UCSI offers, > for example data role swapping, power role swapping, > Alternate Mode control etc. My big worry here is this second thing "integrate into a USB Type-C framework". We don't have one upstream, but we have lots of different ones floating around in different products at the moment, all of them seeming to only do one-off things (i.e. only work for one specific device.) How is this going to be integrated into such a future scheme? Are you working on this larger task? Or working with others who are? Any ideas of when this will happen? 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 v1 1/1] usbip: adding names db to port operation
On Tue, Mar 22, 2016 at 04:31:03PM +0900, Nobuo Iwata wrote:
> Adding names database to port command.
>
> BEFORE) 'unknown' for vendor and product string.
>
> Imported USB devices
>
> Port 00: at Low Speed(1.5Mbps)
>unknown vendor : unknown product (03f0:0224)
>3-1 -> usbip://10.0.2.15:3240/5-1
>-> remote bus/dev 005/002
>
> AFTER) Most vendor string will be converted.
>
> Imported USB devices
>
> Port 00: at Low Speed(1.5Mbps)
>Hewlett-Packard : unknown product (03f0:0224)
>3-1 -> usbip://10.0.2.15:3240/5-1
>-> remote bus/dev 005/002
>
> Signed-off-by: Nobuo Iwata
> ---
> tools/usb/usbip/src/usbip_port.c | 13 +++--
> 1 file changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/tools/usb/usbip/src/usbip_port.c
> b/tools/usb/usbip/src/usbip_port.c
> index a2e884fd..7bd74fb 100644
> --- a/tools/usb/usbip/src/usbip_port.c
> +++ b/tools/usb/usbip/src/usbip_port.c
> @@ -22,10 +22,13 @@ static int list_imported_devices(void)
> struct usbip_imported_device *idev;
> int ret;
>
> + if (usbip_names_init(USBIDS_FILE))
> + err("failed to open %s", USBIDS_FILE);
> +
> ret = usbip_vhci_driver_open();
> if (ret < 0) {
> err("open vhci_driver");
> - return -1;
> + goto err_names_free;
> }
>
> printf("Imported USB devices\n");
> @@ -35,13 +38,19 @@ static int list_imported_devices(void)
> idev = &vhci_driver->idev[i];
>
> if (usbip_vhci_imported_device_dump(idev) < 0)
> - ret = -1;
> + goto err_driver_close;
> }
>
> usbip_vhci_driver_close();
> + usbip_names_free();
>
> return ret;
>
> +err_driver_close:
> + usbip_vhci_driver_close();
> +err_names_free:
> + usbip_names_free();
> + return -1;
> }
>
> int usbip_port_show(__attribute__((unused)) int argc,
Does nothing need to be changed in the usbip code to add this new
feature? Is this a stand-alone patch I can take without anything else?
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: EHCI: make all debugging depend on CONFIG_DYNAMIC_DEBUG
On Fri, Apr 15, 2016 at 12:12:26PM -0400, Alan Stern wrote: > The debugging facilities in ehci-dbg.c follow an uneven pattern. Some > of them are protected by "#ifdef CONFIG_DYNAMIC_DEBUG" and some > aren't, presumably in the hope of having some of the debugging output > available in any configuration. > > This leads to build problems when dynamic debugging isn't configured. > Rather than try to keep this complicated state of affairs, let's just > make everything dependent on CONFIG_DYNAMIC_DEBUG. > > Signed-off-by: Alan Stern > Tested-by: Rafał Miłecki > > --- > > > [as1799] > > > drivers/usb/host/ehci-dbg.c | 80 > +++- > drivers/usb/host/ehci.h |5 -- > 2 files changed, 35 insertions(+), 50 deletions(-) This doesn't apply to the tree at all, did I mess something up? 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
[PATCH v2] Follow-on patches for usbip-vudc driver
This follow-on patchset makes the dev_desc attribute binary, as it should have been. Resent without duplicate patches in the previous patchset. Igor Kotrasinski (1): usbip: vudc: make dev_desc attribute binary drivers/usb/usbip/vudc_sysfs.c | 20 ++-- 1 file changed, 14 insertions(+), 6 deletions(-) -- 2.7.3 -- 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 v2] Follow-on patches for usbip-vudc driver
On Thu, Apr 28, 2016 at 10:08:13PM +0200, Igor Kotrasinski wrote: > This follow-on patchset makes the dev_desc attribute binary, as it > should have been. Resent without duplicate patches in the previous > patchset. > > Igor Kotrasinski (1): > usbip: vudc: make dev_desc attribute binary > > drivers/usb/usbip/vudc_sysfs.c | 20 ++-- > 1 file changed, 14 insertions(+), 6 deletions(-) No patch made it through :( -- 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 v2] Follow-on patches for usbip-vudc driver
W dniu 28.04.2016 o 22:36, Greg KH pisze: > On Thu, Apr 28, 2016 at 10:08:13PM +0200, Igor Kotrasinski wrote: >> This follow-on patchset makes the dev_desc attribute binary, as it >> should have been. Resent without duplicate patches in the previous >> patchset. >> >> Igor Kotrasinski (1): >> usbip: vudc: make dev_desc attribute binary >> >> drivers/usb/usbip/vudc_sysfs.c | 20 ++-- >> 1 file changed, 14 insertions(+), 6 deletions(-) > No patch made it through :( I gave up on fighting gmail, I'll have Krzysztof send the patch tomorrow for me. Igor Kotrasiński -- 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 1/2] usb: dwc3: gadget: update DCFG.NumP to max burst size
On 4/28/2016 1:01 AM, Felipe Balbi wrote:
> NumP field of DCFG register is used on NumP field of
> ACK TP header and it tells the host how many packets
> an endpoint can receive before waiting for
> synchronization.
>
> Documentation says it should be set to anything
> <=bMaxBurst. Interestingly, however, this setting is
> not per-endpoint how it should be (different
> endpoints could have different burst sizes), but
> things seem to work okay right now.
>
> Signed-off-by: Felipe Balbi
> ---
> drivers/usb/dwc3/core.h | 3 +++
> drivers/usb/dwc3/gadget.c | 14 --
> 2 files changed, 15 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
> index 87df6dd20d23..c5f576aa1903 100644
> --- a/drivers/usb/dwc3/core.h
> +++ b/drivers/usb/dwc3/core.h
> @@ -271,6 +271,9 @@
> #define DWC3_DCFG_LOWSPEED (2 << 0)
> #define DWC3_DCFG_FULLSPEED1 (3 << 0)
>
> +#define DWC3_DCFG_NUMP_SHIFT 17
> +#define DWC3_DCFG_NUMP(n)(((n) & 0x1f) >> DWC3_DCFG_NUMP_SHIFT)
> +#define DWC3_DCFG_NUMP_MASK (0x1f << DWC3_DCFG_NUMP_SHIFT)
> #define DWC3_DCFG_LPM_CAP(1 << 22)
>
> /* Device Control Register */
> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
> index 43efb627d1cf..4b681b0d420f 100644
> --- a/drivers/usb/dwc3/gadget.c
> +++ b/drivers/usb/dwc3/gadget.c
> @@ -464,9 +464,19 @@ static int dwc3_gadget_set_ep_config(struct dwc3 *dwc,
> struct dwc3_ep *dep,
>
> /* Burst size is only needed in SuperSpeed mode */
> if (dwc->gadget.speed >= USB_SPEED_SUPER) {
> - u32 burst = dep->endpoint.maxburst - 1;
> + u32 burst = dep->endpoint.maxburst;
> + u32 nump;
> + u32 reg;
>
> - params.param0 |= DWC3_DEPCFG_BURST_SIZE(burst);
> + /* update NumP */
> + reg = dwc3_readl(dwc->regs, DWC3_DCFG);
> + nump = DWC3_DCFG_NUMP(reg);
> + nump = max(nump, burst);
> + reg &= ~DWC3_DCFG_NUMP_MASK;
> + reg |= nump << DWC3_DCFG_NUMP_SHIFT;
> + dwc3_writel(dwc->regs, DWC3_DCFG, reg);
> +
> + params.param0 |= DWC3_DEPCFG_BURST_SIZE(burst - 1);
Hi Felipe,
The controller already takes care not to send a NUMP greater than the
configured maxburst for the endpoint. So there is no need to do
this. You can just set it globally in core init.
NUMP actually should be a global setting because The NUMP is a
function of the space left on the singular, global, RX fifo,
regardless of what EP is receiving the data.
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: Major improvements to the ch341 driver v4
On 2016-04-15 23:14, Grigori Goronzy wrote: Hi, here's a hopefully final v4 of my ch341 patchset. Changelog below this time, because it's cleary better this way. Please review. Ping? -- 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 04/10] regulator: fixed: add support for ACPI interface
Hi, On 04/29/2016 01:15 AM, Mark Brown wrote: > On Thu, Apr 28, 2016 at 01:55:35PM +0800, Lu Baolu wrote: > >> How about below code? >> + gpiod = gpiod_get(dev, "vbus_en", GPIOD_ASIS); >> + if (IS_ERR(gpiod)) >> + return PTR_ERR(gpiod); >> + >> + config->gpio = desc_to_gpio(gpiod); >> + config->enable_high = device_property_read_bool(dev, >> + >> "enable-active-high"); >> + gpiod_put(gpiod); > > That looks reasonable, though if you use "gpio" as the name like DT you > could keep the code the same which would be even better? Not super > crticial though. Systems might implement the name mapping in BIOS by implementing _DSD. The "gpio" looks a little generic. I'd like to use a function specific name. I will send a refreshed patch later. Best regards, Lu Baolu -- 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 1/2] usb: dwc3: gadget: update DCFG.NumP to max burst size
Hi,
John Youn writes:
> On 4/28/2016 1:01 AM, Felipe Balbi wrote:
>> NumP field of DCFG register is used on NumP field of
>> ACK TP header and it tells the host how many packets
>> an endpoint can receive before waiting for
>> synchronization.
>>
>> Documentation says it should be set to anything
>> <=bMaxBurst. Interestingly, however, this setting is
>> not per-endpoint how it should be (different
>> endpoints could have different burst sizes), but
>> things seem to work okay right now.
>>
>> Signed-off-by: Felipe Balbi
>> ---
>> drivers/usb/dwc3/core.h | 3 +++
>> drivers/usb/dwc3/gadget.c | 14 --
>> 2 files changed, 15 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
>> index 87df6dd20d23..c5f576aa1903 100644
>> --- a/drivers/usb/dwc3/core.h
>> +++ b/drivers/usb/dwc3/core.h
>> @@ -271,6 +271,9 @@
>> #define DWC3_DCFG_LOWSPEED (2 << 0)
>> #define DWC3_DCFG_FULLSPEED1(3 << 0)
>>
>> +#define DWC3_DCFG_NUMP_SHIFT17
>> +#define DWC3_DCFG_NUMP(n) (((n) & 0x1f) >> DWC3_DCFG_NUMP_SHIFT)
>> +#define DWC3_DCFG_NUMP_MASK (0x1f << DWC3_DCFG_NUMP_SHIFT)
>> #define DWC3_DCFG_LPM_CAP (1 << 22)
>>
>> /* Device Control Register */
>> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
>> index 43efb627d1cf..4b681b0d420f 100644
>> --- a/drivers/usb/dwc3/gadget.c
>> +++ b/drivers/usb/dwc3/gadget.c
>> @@ -464,9 +464,19 @@ static int dwc3_gadget_set_ep_config(struct dwc3 *dwc,
>> struct dwc3_ep *dep,
>>
>> /* Burst size is only needed in SuperSpeed mode */
>> if (dwc->gadget.speed >= USB_SPEED_SUPER) {
>> -u32 burst = dep->endpoint.maxburst - 1;
>> +u32 burst = dep->endpoint.maxburst;
>> +u32 nump;
>> +u32 reg;
>>
>> -params.param0 |= DWC3_DEPCFG_BURST_SIZE(burst);
>> +/* update NumP */
>> +reg = dwc3_readl(dwc->regs, DWC3_DCFG);
>> +nump = DWC3_DCFG_NUMP(reg);
>> +nump = max(nump, burst);
>> +reg &= ~DWC3_DCFG_NUMP_MASK;
>> +reg |= nump << DWC3_DCFG_NUMP_SHIFT;
>> +dwc3_writel(dwc->regs, DWC3_DCFG, reg);
>> +
>> +params.param0 |= DWC3_DEPCFG_BURST_SIZE(burst - 1);
>
> Hi Felipe,
>
> The controller already takes care not to send a NUMP greater than the
> configured maxburst for the endpoint. So there is no need to do
> this. You can just set it globally in core init.
iow, we just set this to the maximum value and forget about it ? That
doesn't appear to be documented. We can patch this up for v4.8, then
since $subject has no negative side-effect and Greg has already merged
this to his tree :-)
> NUMP actually should be a global setting because The NUMP is a
> function of the space left on the singular, global, RX fifo,
> regardless of what EP is receiving the data.
Understood :-)
--
balbi
signature.asc
Description: PGP signature
Re: [PATCH] usb: dwc3: usb/dwc3: fake dissconnect event when turn off pullup
Hi, John Youn writes: >> "Du, Changbin" writes: >>> Hi, Balbi, >>> >>> The step to reproduce this issue is: >>> 1) connect device to a host and wait its enumeration. >>> 2) trigger software disconnect by calling function >>> usb_gadget_disconnect(), which finally call >>>dwc3_gadget_pullup(false). Do not reconnect device >>> (I mean no enumeration go on, keep bit Run/Stop 0.). >>> >>> At here, gadget driver's disconnect callback should be >>> Called, right? We has been disconnected. But no, as >>> You said " not generating disconnect IRQ after you >>> drop Run/Stop is expected". >>> >>> And I am testing on an Android device, Android only >>> use dwc3_gadget_pullup(false) to issue a soft disconnection. >>> This confused user that the UI still show usb as connected >>> State, caused by missing a disconnect event. >> >> okay, so I know what this is. This is caused by Android gadget itself >> not notifying the gadget that a disconnect has happened. Just look at >> udc-core's soft_connect implementation for the sysfs interface, and >> you'll see what I mean. >> >> This should be fixed at Android gadget itself. The only thing we could >> do is introduce a new usb_gadget_soft_connect()/disconnect() to wrap the >> logic so it's easier for Android gadget to use; but even that I'm a >> little bit reluctant to do because Android should be using our >> soft_connect interface instead of reimplementing it (wrongly) by its >> own. >> > > We've run in to the same issue with our usb_gadget_driver. > > If the usb_gadget_disconnect() API function, which seems like it is > intended to be called by the gadget_driver, does cause the gadget to > disconnect, it seems reasonable to expect the gadget or the UDC core > to notify the gadget_driver via the callback. Well, the API is supposed to disconnect D+ pullup and that's about it. > As you mentioned this is handled in the soft_disconnect sysfs. Why > shouldn't usb_gadget_disconnect() do the same thing, if not the gadget because there might be cases where we don't need/want the gadget to know about this disconnect. > itself? Exposing the sysfs as an API function would work too. Though it already _is_ exported. I just don't know why people are re-inventing the same solution :-) > both functions are "soft" disconnects and both are called > "disconnect". > > In our gadget_driver we do the workaround where we notify ourself that > we called the usb_gadget_disconnect() and that we should now be you could just rely on the sysfs interface, right ? :-) > disconnected. It just seems more correct that we shouldn't have to > handle that. > > By the way, I'm not completely sure of the correct terminology, but > I'm referring to the struct usb_gadget (dwc3, dwc2, etc) as the > "gadget" and the struct usb_gadget_driver as the "gadget_driver" > (normally this would be the composite gadget framework, but we are > using our own driver in this case). Is there a less confusing way to > refer to these :) what I've been doing is that I refer to dwc3, dwc3, etc as UDC (as in USB Device Controller) and g_mass_storage, g_ether, g_zero, etc as gadget driver. -- balbi signature.asc Description: PGP signature
Re: [GIT PULL] USB: changes for v4.7 merge window
Hi, Greg Kroah-Hartman writes: > On Thu, Apr 28, 2016 at 01:46:03PM +0300, Felipe Balbi wrote: >> >> Hi Greg, >> >> here's the gadget pull request for v4.7 merge window. It's mostly dwc3 >> this time: >> >> $ git diff --dirstat v4.6-rc3 >> 74.4% drivers/usb/dwc3/ >> 13.9% drivers/usb/gadget/udc/ >>5.2% drivers/usb/gadget/ >>3.6% drivers/usb/renesas_usbhs/ >> >> Patches have been tested on Intel platforms and have been soaking on >> Linux next for a while now. >> >> Let me know if you want anything to be changed. >> >> cheers >> >> The following changes since commit bf16200689118d19de1b8d2a3c314fc21f5dc7bb: >> >> Linux 4.6-rc3 (2016-04-10 17:58:30 -0700) >> >> are available in the git repository at: >> >> git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git >> tags/usb-for-v4.7 > > I've pulled and pushed out. There was a merge conflict in > drivers/usb/dwc3/debugfs.c, and I think I got it right (well, I resolved > it in the way that _I_ would like the code to look like), but if you > could check, that would be great. looks good and runs okay :-) -- balbi signature.asc Description: PGP signature
[PATCH v7 7/7] MAINTAINERS: add maintainer entry for Intel USB dual role mux drivers
Add a maintainer entry for Intel USB dual role mux drivers and add myself as a maintainer. Signed-off-by: Lu Baolu --- MAINTAINERS | 10 ++ 1 file changed, 10 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 1d5b4be..682c8a5 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -5879,6 +5879,16 @@ S: Maintained F: arch/x86/include/asm/intel_telemetry.h F: drivers/platform/x86/intel_telemetry* +INTEL USB DUAL ROLE PORT MUX DRIVERS +M: Lu Baolu +L: linux-usb@vger.kernel.org +S: Supported +F: include/linux/usb/intel-mux.h +F: drivers/usb/mux/intel-mux.c +F: drivers/usb/mux/intel-mux-gpio.c +F: drivers/usb/mux/intel-mux-drcfg.c +F: drivers/mfd/intel-vuport.c + IOC3 ETHERNET DRIVER M: Ralf Baechle L: linux-m...@linux-mips.org -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v7 2/7] usb: mux: add generic code for dual role port mux
Several Intel platforms implement USB dual role by having completely
separate xHCI and dwc3 IPs in PCH or SOC silicons. These two IPs share
a single USB port. There is another external port mux which controls
where the data lines should go. While the USB controllers are part of
the silicon, the port mux design are platform specific.
This patch adds the generic code to handle such usb port mux. It listens
to the USB HOST extcon cable, and switch the port by calling the port
switch ops provided by the individual port mux driver. It also registers
the mux device with sysfs, so that users can control the port mux from
user space.
Some other archs (e.g. Renesas R-Car gen2 SoCs) need an external mux to
swap usb roles as well. This code could be leveraged for those archs
as well.
Signed-off-by: Lu Baolu
Reviewed-by: Heikki Krogerus
Reviewed-by: Felipe Balbi
Reviewed-by: Chanwoo Choi
[baolu: extcon usage reviewed by Chanwoo Choi]
---
Documentation/ABI/testing/sysfs-bus-platform | 17 +++
drivers/usb/Kconfig | 2 +
drivers/usb/Makefile | 1 +
drivers/usb/mux/Kconfig | 11 ++
drivers/usb/mux/Makefile | 4 +
drivers/usb/mux/portmux-core.c | 217 +++
include/linux/usb/portmux.h | 78 ++
7 files changed, 330 insertions(+)
create mode 100644 drivers/usb/mux/Kconfig
create mode 100644 drivers/usb/mux/Makefile
create mode 100644 drivers/usb/mux/portmux-core.c
create mode 100644 include/linux/usb/portmux.h
diff --git a/Documentation/ABI/testing/sysfs-bus-platform
b/Documentation/ABI/testing/sysfs-bus-platform
index 5172a61..f33f0a5 100644
--- a/Documentation/ABI/testing/sysfs-bus-platform
+++ b/Documentation/ABI/testing/sysfs-bus-platform
@@ -18,3 +18,20 @@ Description:
devices to opt-out of driver binding using a driver_override
name such as "none". Only a single driver may be specified in
the override, there is no support for parsing delimiters.
+
+What: /sys/bus/platform/devices/.../portmux.N/name
+ /sys/bus/platform/devices/.../portmux.N/state
+Date: April 2016
+Contact: Lu Baolu
+Description:
+ In some platforms, a single USB port is shared between a USB
host
+ controller and a device controller. A USB mux driver is needed
to
+ handle the port mux. Read-only attribute "name" shows the name
of
+ the port mux device. "state" attribute shows and stores the mux
+ state.
+ For read:
+ 'peripheral' - mux switched to PERIPHERAL controller;
+ 'host' - mux switched to HOST controller.
+ For write:
+ 'peripheral' - mux will be switched to PERIPHERAL controller;
+ 'host' - mux will be switched to HOST controller.
diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig
index 8689dcb..328916e 100644
--- a/drivers/usb/Kconfig
+++ b/drivers/usb/Kconfig
@@ -148,6 +148,8 @@ endif # USB
source "drivers/usb/phy/Kconfig"
+source "drivers/usb/mux/Kconfig"
+
source "drivers/usb/gadget/Kconfig"
config USB_LED_TRIG
diff --git a/drivers/usb/Makefile b/drivers/usb/Makefile
index dca7856..9a92338 100644
--- a/drivers/usb/Makefile
+++ b/drivers/usb/Makefile
@@ -6,6 +6,7 @@
obj-$(CONFIG_USB) += core/
obj-$(CONFIG_USB_SUPPORT) += phy/
+obj-$(CONFIG_USB_SUPPORT) += mux/
obj-$(CONFIG_USB_DWC3) += dwc3/
obj-$(CONFIG_USB_DWC2) += dwc2/
diff --git a/drivers/usb/mux/Kconfig b/drivers/usb/mux/Kconfig
new file mode 100644
index 000..d91909f
--- /dev/null
+++ b/drivers/usb/mux/Kconfig
@@ -0,0 +1,11 @@
+#
+# USB port mux driver configuration
+#
+
+menu "USB Port MUX drivers"
+config USB_PORTMUX
+ select EXTCON
+ def_bool n
+ help
+ Generic USB dual role port mux support.
+endmenu
diff --git a/drivers/usb/mux/Makefile b/drivers/usb/mux/Makefile
new file mode 100644
index 000..f85df92
--- /dev/null
+++ b/drivers/usb/mux/Makefile
@@ -0,0 +1,4 @@
+#
+# Makefile for USB port mux drivers
+#
+obj-$(CONFIG_USB_PORTMUX) += portmux-core.o
diff --git a/drivers/usb/mux/portmux-core.c b/drivers/usb/mux/portmux-core.c
new file mode 100644
index 000..0e3548b
--- /dev/null
+++ b/drivers/usb/mux/portmux-core.c
@@ -0,0 +1,217 @@
+/**
+ * intel_mux.c - USB Port Mux support
+ *
+ * Copyright (C) 2016 Intel Corporation
+ *
+ * Author: Lu Baolu
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include
+#include
+#include
+#include
+#include
+
+static int usb_mux_change_state(struct portmux_dev *pdev, int state)
+{
+ int ret;
+ struct device *dev = &pdev->dev;
+
+ dev_WARN_ONCE(d
[PATCH v7 6/7] usb: pci-quirks: add Intel USB drcfg mux device
In some Intel platforms, a single usb port is shared between USB host
and device controllers. The shared port is under control of a switch
which is defined in the Intel vendor defined extended capability for
xHCI.
This patch adds the support to detect and create the platform device
for the port mux switch.
Signed-off-by: Lu Baolu
Reviewed-by: Felipe Balbi
---
drivers/usb/host/pci-quirks.c| 45 ++--
drivers/usb/host/xhci-ext-caps.h | 2 ++
2 files changed, 45 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c
index 35af362..9bb7aa1 100644
--- a/drivers/usb/host/pci-quirks.c
+++ b/drivers/usb/host/pci-quirks.c
@@ -16,10 +16,11 @@
#include
#include
#include
+#include
+
#include "pci-quirks.h"
#include "xhci-ext-caps.h"
-
#define UHCI_USBLEGSUP 0xc0/* legacy support */
#define UHCI_USBCMD0 /* command register */
#define UHCI_USBINTR 4 /* interrupt register */
@@ -78,6 +79,8 @@
#define USB_INTEL_USB3_PSSEN 0xD8
#define USB_INTEL_USB3PRM 0xDC
+#define DEVICE_ID_INTEL_BROXTON_P_XHCI 0x5aa8
+
/*
* amd_chipset_gen values represent AMD different chipset generations
*/
@@ -956,6 +959,41 @@ void usb_disable_xhci_ports(struct pci_dev *xhci_pdev)
}
EXPORT_SYMBOL_GPL(usb_disable_xhci_ports);
+static void create_intel_usb_mux_device(struct pci_dev *xhci_pdev,
+ void __iomem *base)
+{
+ struct platform_device *plat_dev;
+ struct property_set pset;
+ int ret;
+
+ struct property_entry pentry[] = {
+ PROPERTY_ENTRY_U64("reg-start",
+ pci_resource_start(xhci_pdev, 0) + 0x80d8),
+ PROPERTY_ENTRY_U64("reg-size", 8),
+ { },
+ };
+
+ if (!xhci_find_next_ext_cap(base, 0, XHCI_EXT_CAPS_INTEL_USB_MUX))
+ return;
+
+ plat_dev = platform_device_alloc("intel-mux-drcfg",
+PLATFORM_DEVID_NONE);
+ if (!plat_dev)
+ return;
+
+ plat_dev->dev.parent = &xhci_pdev->dev;
+ pset.properties = pentry;
+ platform_device_add_properties(plat_dev, &pset);
+
+ ret = platform_device_add(plat_dev);
+ if (ret) {
+ dev_warn(&xhci_pdev->dev,
+"failed to create mux device with error %d",
+ ret);
+ platform_device_put(plat_dev);
+ }
+}
+
/**
* PCI Quirks for xHCI.
*
@@ -1022,8 +1060,11 @@ static void quirk_usb_handoff_xhci(struct pci_dev *pdev)
writel(val, base + ext_cap_offset + XHCI_LEGACY_CONTROL_OFFSET);
hc_init:
- if (pdev->vendor == PCI_VENDOR_ID_INTEL)
+ if (pdev->vendor == PCI_VENDOR_ID_INTEL) {
usb_enable_intel_xhci_ports(pdev);
+ if (pdev->device == DEVICE_ID_INTEL_BROXTON_P_XHCI)
+ create_intel_usb_mux_device(pdev, base);
+ }
op_reg_base = base + XHCI_HC_LENGTH(readl(base));
diff --git a/drivers/usb/host/xhci-ext-caps.h b/drivers/usb/host/xhci-ext-caps.h
index e0244fb..e368ccb 100644
--- a/drivers/usb/host/xhci-ext-caps.h
+++ b/drivers/usb/host/xhci-ext-caps.h
@@ -51,6 +51,8 @@
#define XHCI_EXT_CAPS_ROUTE5
/* IDs 6-9 reserved */
#define XHCI_EXT_CAPS_DEBUG10
+/* Vendor defined 192-255 */
+#define XHCI_EXT_CAPS_INTEL_USB_MUX192
/* USB Legacy Support Capability - section 7.1.1 */
#define XHCI_HC_BIOS_OWNED (1 << 16)
#define XHCI_HC_OS_OWNED (1 << 24)
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v7 3/7] usb: mux: add driver for Intel gpio controlled port mux
In some Intel platforms, a single usb port is shared between USB host
and device controller. The shared port is under control of GPIO pins.
This patch adds the support for USB GPIO controlled port mux.
[baolu: removed .owner per platform_no_drv_owner.cocci]
Signed-off-by: David Cohen
Signed-off-by: Lu Baolu
Reviewed-by: Heikki Krogerus
Reviewed-by: Felipe Balbi
---
drivers/usb/mux/Kconfig | 11 +++
drivers/usb/mux/Makefile | 1 +
drivers/usb/mux/portmux-intel-gpio.c | 149 +++
3 files changed, 161 insertions(+)
create mode 100644 drivers/usb/mux/portmux-intel-gpio.c
diff --git a/drivers/usb/mux/Kconfig b/drivers/usb/mux/Kconfig
index d91909f..1dc1f33 100644
--- a/drivers/usb/mux/Kconfig
+++ b/drivers/usb/mux/Kconfig
@@ -8,4 +8,15 @@ config USB_PORTMUX
def_bool n
help
Generic USB dual role port mux support.
+
+config INTEL_MUX_GPIO
+ tristate "Intel dual role port mux controlled by GPIOs"
+ depends on GPIOLIB
+ depends on REGULATOR
+ depends on X86 && ACPI
+ select USB_PORTMUX
+ help
+ Say Y here to enable support for Intel dual role port mux
+ controlled by GPIOs.
+
endmenu
diff --git a/drivers/usb/mux/Makefile b/drivers/usb/mux/Makefile
index f85df92..4eb5582 100644
--- a/drivers/usb/mux/Makefile
+++ b/drivers/usb/mux/Makefile
@@ -2,3 +2,4 @@
# Makefile for USB port mux drivers
#
obj-$(CONFIG_USB_PORTMUX) += portmux-core.o
+obj-$(CONFIG_INTEL_MUX_GPIO) += portmux-intel-gpio.o
diff --git a/drivers/usb/mux/portmux-intel-gpio.c
b/drivers/usb/mux/portmux-intel-gpio.c
new file mode 100644
index 000..b07ae2c
--- /dev/null
+++ b/drivers/usb/mux/portmux-intel-gpio.c
@@ -0,0 +1,149 @@
+/*
+ * USB Dual Role Port Mux driver controlled by gpios
+ *
+ * Copyright (c) 2016, Intel Corporation.
+ * Author: David Cohen
+ * Author: Lu Baolu
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+struct vuport {
+ struct portmux_desc desc;
+ struct portmux_dev *pdev;
+ struct regulator *regulator;
+ struct gpio_desc *gpio_usb_mux;
+};
+
+/*
+ * id == 0, HOST connected, USB port should be set to peripheral
+ * id == 1, HOST disconnected, USB port should be set to host
+ *
+ * Peripheral: set USB mux to peripheral and disable VBUS
+ * Host: set USB mux to host and enable VBUS
+ */
+static inline int vuport_set_port(struct device *dev, int id)
+{
+ struct vuport *vup;
+
+ dev_dbg(dev, "USB PORT ID: %s\n", id ? "HOST" : "PERIPHERAL");
+
+ vup = dev_get_drvdata(dev);
+
+ gpiod_set_value_cansleep(vup->gpio_usb_mux, !id);
+
+ if (!id ^ regulator_is_enabled(vup->regulator))
+ return id ? regulator_disable(vup->regulator) :
+ regulator_enable(vup->regulator);
+
+ return 0;
+}
+
+static int vuport_cable_set(struct device *dev)
+{
+ return vuport_set_port(dev, 1);
+}
+
+static int vuport_cable_unset(struct device *dev)
+{
+ return vuport_set_port(dev, 0);
+}
+
+static const struct portmux_ops vuport_ops = {
+ .cable_set_cb = vuport_cable_set,
+ .cable_unset_cb = vuport_cable_unset,
+};
+
+static int vuport_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct vuport *vup;
+
+ vup = devm_kzalloc(dev, sizeof(*vup), GFP_KERNEL);
+ if (!vup)
+ return -ENOMEM;
+
+ vup->regulator = devm_regulator_get_exclusive(dev,
+ "regulator-usb-gpio");
+ if (IS_ERR(vup->regulator))
+ return -EPROBE_DEFER;
+
+ vup->gpio_usb_mux = devm_gpiod_get_optional(dev,
+ "usb_mux", GPIOD_ASIS);
+ if (IS_ERR(vup->gpio_usb_mux))
+ return PTR_ERR(vup->gpio_usb_mux);
+
+ vup->desc.dev = dev;
+ vup->desc.name = "intel-mux-gpio";
+ vup->desc.extcon_name = "extcon-usb-gpio";
+ vup->desc.ops = &vuport_ops;
+ vup->desc.initial_state = -1;
+ dev_set_drvdata(dev, vup);
+ vup->pdev = portmux_register(&vup->desc);
+
+ return PTR_ERR_OR_ZERO(vup->pdev);
+}
+
+static int vuport_remove(struct platform_device *pdev)
+{
+ struct vuport *vup;
+
+ vup = platform_get_drvdata(pdev);
+ portmux_unregister(vup->pdev);
+
+ return 0;
+}
+
+#ifdef CONFIG_PM_SLEEP
+/*
+ * In case a micro A cable was plugged in while device was sleeping,
+ * we missed the interrupt. We need to poll usb id gpio when waking the
+ * driver to detect the missed event.
+ * We use 'complete' callback to give time to all extcon listeners to
+ * resume before we send new events.
+ */
+static void vuport_complete(struct device *dev)
+{
+ struct
[PATCH v7 0/7] usb: add support for Intel dual role port mux
Intel SOC chips are featured with USB dual role. The host role is provided by Intel xHCI IP, and the gadget role is provided by IP from designware. Tablet platform designs always share a single port for both host and gadget controllers. There is a mux to switch the port to the right controller according to the cable type. OS needs to provide the callback to control the mux when a plug-in event raises. The method to control the mux is platform dependent. At least three types of implementation can be found across current devices. 1) GPIO pins; 2) a unit which can be controlled by memory mapped registers; 3) ACPI ASL code. This patch series adds supports for Intel dual role port mux. It includes: (1) A helper layer on top of extcon for individual mux driver. It listens to the USB-HOST extcon cable and call the switch call-back when the cable state changes. (2) Drivers for GPIO controlled port mux which could be found on Baytrail devices. A mfd driver is used to split the GPIOs into a USB gpio extcon device, a fixed regulator for gpio controlled USB VCC, and a USB mux device. Driver for USB gpio extcon device is already in upstream Linux. This patch series includes a driver for GPIO USB mux. (3) Drivers for USB port mux controlled through memory mapped registers and the logic to create the mux device. This type of dual role port mux could be found in Cherry Trail and Broxton devices. Lu Baolu (7): regulator: fixed: add support for ACPI interface usb: mux: add generic code for dual role port mux usb: mux: add driver for Intel gpio controlled port mux usb: mux: add driver for Intel drcfg controlled port mux mfd: intel_vuport: Add Intel virtual USB port MFD Driver usb: pci-quirks: add Intel USB drcfg mux device MAINTAINERS: add maintainer entry for Intel USB dual role mux drivers Change log: v6->v7: - Two patches have been picked up by extcon maintainer. Hence, remove them since this version. - extcon: usb-gpio: add device binding for platform device - extcon: usb-gpio: add support for ACPI gpio interface - In patch "regulator: fixed: add support for ACPI interface", a static gpio name is used to get the regulator gpio. - In patch "mfd: intel_vuport: Add Intel virtual USB port MFD Driver", unnecessary "gpio-name" string property has been removed. v5->v6: Work internally with Felipe to improve the whole patch series. Below changes have been made since last version. - rework the common code to make it a generic interface for mux devices; - split the vbus gpio handling to a fixed regulator device; - removed unnecessary filtering for state change; - removed unnecessary WARN statement; - removed globals in mux drivers; - removed unnecessary register polling and waiting in drcfg driver; v4->v5: - Change the extcon interfaces with the new ones suggested by 2a9de9c0f08d6 (extcon: Use the unique id for external connector instead of string) - remove patch "usb: pci-quirks: add Intel USB drcfg mux device" from this serial due to that it's not driver staff. Will be submitted seperately. v3->v4: - Check all patches with "checkpatch.pl --strict", and fix all CHECKs; - Change sysfs node from "intel_mux" to "port_mux"; - Refines below confusing functions: intel_usb_mux_register() -> intel_usb_mux_bind_cable() intel_usb_mux_unregister() -> intel_usb_mux_unbind_cable(); - Remove unnecessary struct intel_mux_dev. v2->v3: - uvport mfd driver got reviewed by Lee Jones, the following changes were made accordingly. - seperate uvport driver from the mux drivers in MAINTAINERS file - refine the description in Kconfig - refine the mfd_cell structure data v1->v2: - move mux driver from drivers/usb/misc to drivers/usb/mux; - replace debugfs with sysfs for user level mux control; - remove unnecessary register restore if mux registeration failed; - Add "Acked-by: Chanwoo Choi " to extcon changes; - Make the file names and exported function names more specific; - Remove the usb_mux_get_dev() interface; - Move "struct intel_usb_mux" from .h to .c file; - Fix various kbuild robot warnings. Documentation/ABI/testing/sysfs-bus-platform | 17 +++ MAINTAINERS | 10 ++ drivers/mfd/Kconfig | 8 + drivers/mfd/Makefile | 1 + drivers/mfd/intel-vuport.c | 89 +++ drivers/regulator/fixed.c| 46 ++ drivers/usb/Kconfig | 2 + drivers/usb/Makefile | 1 + drivers/usb/host/pci-quirks.c| 45 +- drivers/usb/host/xhci-ext-caps.h | 2 + drivers/usb/mux/Kconfig | 30 drivers/usb/mux/Makefile | 6 + drivers/usb/mux/portmux-core.c | 217 +++ drivers/usb/mux/portmux-intel-drcfg.c| 171 + drivers/usb/
[PATCH v7 1/7] regulator: fixed: add support for ACPI interface
Add support to retrieve fixed voltage configure information through
ACPI interface. This is needed for Intel Bay Trail devices, where a
GPIO is used to control the USB vbus.
Signed-off-by: Lu Baolu
---
drivers/regulator/fixed.c | 46 ++
1 file changed, 46 insertions(+)
diff --git a/drivers/regulator/fixed.c b/drivers/regulator/fixed.c
index ff62d69..68057dc 100644
--- a/drivers/regulator/fixed.c
+++ b/drivers/regulator/fixed.c
@@ -30,6 +30,9 @@
#include
#include
#include
+#include
+#include
+#include
struct fixed_voltage_data {
struct regulator_desc desc;
@@ -104,6 +107,44 @@ of_get_fixed_voltage_config(struct device *dev,
return config;
}
+/**
+ * acpi_get_fixed_voltage_config - extract fixed_voltage_config structure info
+ * @dev: device requesting for fixed_voltage_config
+ * @desc: regulator description
+ *
+ * Populates fixed_voltage_config structure by extracting data through ACPI
+ * interface, returns a pointer to the populated structure of NULL if memory
+ * alloc fails.
+ */
+static struct fixed_voltage_config *
+acpi_get_fixed_voltage_config(struct device *dev,
+ const struct regulator_desc *desc)
+{
+ struct fixed_voltage_config *config;
+ const char *supply_name, *gpio_name;
+ struct gpio_desc *gpiod;
+ int ret;
+
+ config = devm_kzalloc(dev, sizeof(*config), GFP_KERNEL);
+ if (!config)
+ return ERR_PTR(-ENOMEM);
+
+ ret = device_property_read_string(dev, "supply-name", &supply_name);
+ if (!ret)
+ config->supply_name = supply_name;
+
+ gpiod = gpiod_get(dev, "vbus_en", GPIOD_ASIS);
+ if (IS_ERR(gpiod))
+ return PTR_ERR(gpiod);
+
+ config->gpio = desc_to_gpio(gpiod);
+ config->enable_high = device_property_read_bool(dev,
+ "enable-active-high");
+ gpiod_put(gpiod);
+
+ return config;
+}
+
static struct regulator_ops fixed_voltage_ops = {
};
@@ -124,6 +165,11 @@ static int reg_fixed_voltage_probe(struct platform_device
*pdev)
&drvdata->desc);
if (IS_ERR(config))
return PTR_ERR(config);
+ } else if (ACPI_HANDLE(&pdev->dev)) {
+ config = acpi_get_fixed_voltage_config(&pdev->dev,
+ &drvdata->desc);
+ if (IS_ERR(config))
+ return PTR_ERR(config);
} else {
config = dev_get_platdata(&pdev->dev);
}
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v7 5/7] mfd: intel_vuport: Add Intel virtual USB port MFD Driver
Some Intel platforms have an USB port mux controlled by GPIOs.
There's a single ACPI platform device that provides 1) USB ID
extcon device; 2) USB vbus regulator device; and 3) USB port
switch device. This MFD driver will split these 3 devices for
their respective drivers.
[baolu: removed .owner per platform_no_drv_owner.cocci]
Suggested-by: David Cohen
Signed-off-by: Lu Baolu
Reviewed-by: Felipe Balbi
---
drivers/mfd/Kconfig| 8 +
drivers/mfd/Makefile | 1 +
drivers/mfd/intel-vuport.c | 89 ++
3 files changed, 98 insertions(+)
create mode 100644 drivers/mfd/intel-vuport.c
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index eea61e3..7e115ab 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -1578,5 +1578,13 @@ config MFD_VEXPRESS_SYSREG
System Registers are the platform configuration block
on the ARM Ltd. Versatile Express board.
+config MFD_INTEL_VUPORT
+ tristate "Intel virtual USB port controller"
+ select MFD_CORE
+ depends on X86 && ACPI
+ help
+ Say Y here to enable support for Intel's dual role port mux
+ controlled by GPIOs.
+
endmenu
endif
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 5eaa6465d..65b0518 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -203,3 +203,4 @@ intel-soc-pmic-objs := intel_soc_pmic_core.o
intel_soc_pmic_crc.o
intel-soc-pmic-$(CONFIG_INTEL_PMC_IPC) += intel_soc_pmic_bxtwc.o
obj-$(CONFIG_INTEL_SOC_PMIC) += intel-soc-pmic.o
obj-$(CONFIG_MFD_MT6397) += mt6397-core.o
+obj-$(CONFIG_MFD_INTEL_VUPORT) += intel-vuport.o
diff --git a/drivers/mfd/intel-vuport.c b/drivers/mfd/intel-vuport.c
new file mode 100644
index 000..1cb4ea3
--- /dev/null
+++ b/drivers/mfd/intel-vuport.c
@@ -0,0 +1,89 @@
+/*
+ * MFD driver for Intel virtual USB port
+ *
+ * Copyright(c) 2016 Intel Corporation.
+ * Author: Lu Baolu
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+/* ACPI GPIO Mappings */
+static const struct acpi_gpio_params id_gpio = { 0, 0, false };
+static const struct acpi_gpio_params vbus_gpio = { 1, 0, false };
+static const struct acpi_gpio_params mux_gpio = { 2, 0, false };
+static const struct acpi_gpio_mapping acpi_usb_gpios[] = {
+ { "id-gpios", &id_gpio, 1 },
+ { "vbus_en-gpios", &vbus_gpio, 1 },
+ { "usb_mux-gpios", &mux_gpio, 1 },
+ { },
+};
+
+static struct property_entry reg_properties[] = {
+ PROPERTY_ENTRY_STRING("supply-name", "regulator-usb-gpio"),
+ { },
+};
+
+static const struct property_set reg_properties_pset = {
+ .properties = reg_properties,
+};
+
+static const struct mfd_cell intel_vuport_mfd_cells[] = {
+ { .name = "extcon-usb-gpio", },
+ {
+ .name = "reg-fixed-voltage",
+ .pset = ®_properties_pset,
+ },
+ { .name = "intel-mux-gpio", },
+};
+
+static int vuport_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ int ret;
+
+ ret = acpi_dev_add_driver_gpios(ACPI_COMPANION(dev), acpi_usb_gpios);
+ if (ret)
+ return ret;
+
+ return mfd_add_devices(&pdev->dev, PLATFORM_DEVID_NONE,
+ intel_vuport_mfd_cells,
+ ARRAY_SIZE(intel_vuport_mfd_cells), NULL, 0,
+ NULL);
+}
+
+static int vuport_remove(struct platform_device *pdev)
+{
+ mfd_remove_devices(&pdev->dev);
+ acpi_dev_remove_driver_gpios(ACPI_COMPANION(&pdev->dev));
+
+ return 0;
+}
+
+static struct acpi_device_id vuport_acpi_match[] = {
+ { "INT3496" },
+ { }
+};
+MODULE_DEVICE_TABLE(acpi, vuport_acpi_match);
+
+static struct platform_driver vuport_driver = {
+ .driver = {
+ .name = "intel-vuport",
+ .acpi_match_table = ACPI_PTR(vuport_acpi_match),
+ },
+ .probe = vuport_probe,
+ .remove = vuport_remove,
+};
+
+module_platform_driver(vuport_driver);
+
+MODULE_AUTHOR("Lu Baolu ");
+MODULE_DESCRIPTION("Intel virtual USB port");
+MODULE_LICENSE("GPL v2");
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v7 4/7] usb: mux: add driver for Intel drcfg controlled port mux
Several Intel PCHs and SOCs have an internal mux that is used to
share one USB port between device controller and host controller.
The mux is handled through the Dual Role Configuration Register.
Signed-off-by: Heikki Krogerus
Signed-off-by: Lu Baolu
Signed-off-by: Wu Hao
Reviewed-by: Felipe Balbi
---
drivers/usb/mux/Kconfig | 8 ++
drivers/usb/mux/Makefile | 1 +
drivers/usb/mux/portmux-intel-drcfg.c | 171 ++
3 files changed, 180 insertions(+)
create mode 100644 drivers/usb/mux/portmux-intel-drcfg.c
diff --git a/drivers/usb/mux/Kconfig b/drivers/usb/mux/Kconfig
index 1dc1f33..ae3f746 100644
--- a/drivers/usb/mux/Kconfig
+++ b/drivers/usb/mux/Kconfig
@@ -19,4 +19,12 @@ config INTEL_MUX_GPIO
Say Y here to enable support for Intel dual role port mux
controlled by GPIOs.
+config INTEL_MUX_DRCFG
+ tristate "Intel dual role port mux controlled by register"
+ depends on X86
+ select USB_PORTMUX
+ help
+ Say Y here to enable support for Intel dual role port mux
+ controlled by the Dual Role Configuration Register.
+
endmenu
diff --git a/drivers/usb/mux/Makefile b/drivers/usb/mux/Makefile
index 4eb5582..0f102b5 100644
--- a/drivers/usb/mux/Makefile
+++ b/drivers/usb/mux/Makefile
@@ -3,3 +3,4 @@
#
obj-$(CONFIG_USB_PORTMUX) += portmux-core.o
obj-$(CONFIG_INTEL_MUX_GPIO) += portmux-intel-gpio.o
+obj-$(CONFIG_INTEL_MUX_DRCFG) += portmux-intel-drcfg.o
diff --git a/drivers/usb/mux/portmux-intel-drcfg.c
b/drivers/usb/mux/portmux-intel-drcfg.c
new file mode 100644
index 000..0bb6b08
--- /dev/null
+++ b/drivers/usb/mux/portmux-intel-drcfg.c
@@ -0,0 +1,171 @@
+/**
+ * intel-mux-drcfg.c - Driver for Intel USB mux via register
+ *
+ * Copyright (C) 2016 Intel Corporation
+ * Author: Heikki Krogerus
+ * Author: Lu Baolu
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define INTEL_MUX_CFG0 0x00
+#define INTEL_MUX_CFG1 0x04
+#define CFG0_SW_IDPIN BIT(20)
+#define CFG0_SW_IDPIN_EN BIT(21)
+#define CFG0_SW_VBUS_VALID BIT(24)
+#define CFG1_MODE BIT(29)
+
+struct intel_mux_drcfg {
+ struct portmux_desc desc;
+ struct device *dev;
+ void __iomem *regs;
+ struct portmux_dev *pdev;
+};
+
+static inline int intel_mux_drcfg_switch(struct device *dev, bool host)
+{
+ u32 data;
+ struct intel_mux_drcfg *mux;
+
+ mux = dev_get_drvdata(dev);
+
+ /* Check and set mux to SW controlled mode */
+ data = readl(mux->regs + INTEL_MUX_CFG0);
+ if (!(data & CFG0_SW_IDPIN_EN)) {
+ data |= CFG0_SW_IDPIN_EN;
+ writel(data, mux->regs + INTEL_MUX_CFG0);
+ }
+
+ /*
+* Configure CFG0 to switch the mux and VBUS_VALID bit is
+* required for device mode.
+*/
+ data = readl(mux->regs + INTEL_MUX_CFG0);
+ if (host)
+ data &= ~(CFG0_SW_IDPIN | CFG0_SW_VBUS_VALID);
+ else
+ data |= (CFG0_SW_IDPIN | CFG0_SW_VBUS_VALID);
+ writel(data, mux->regs + INTEL_MUX_CFG0);
+
+ return 0;
+}
+
+static int intel_mux_drcfg_cable_set(struct device *dev)
+{
+ dev_dbg(dev, "drcfg mux switch to HOST\n");
+
+ return intel_mux_drcfg_switch(dev, true);
+}
+
+static int intel_mux_drcfg_cable_unset(struct device *dev)
+{
+ dev_dbg(dev, "drcfg mux switch to DEVICE\n");
+
+ return intel_mux_drcfg_switch(dev, false);
+}
+
+static const struct portmux_ops drcfg_ops = {
+ .cable_set_cb = intel_mux_drcfg_cable_set,
+ .cable_unset_cb = intel_mux_drcfg_cable_unset,
+};
+
+static int intel_mux_drcfg_probe(struct platform_device *pdev)
+{
+ struct intel_mux_drcfg *mux;
+ struct device *dev = &pdev->dev;
+ const char *extcon_name = NULL;
+ u64 start, size;
+ int ret;
+
+ mux = devm_kzalloc(dev, sizeof(*mux), GFP_KERNEL);
+ if (!mux)
+ return -ENOMEM;
+
+ ret = device_property_read_u64(dev, "reg-start", &start);
+ ret |= device_property_read_u64(dev, "reg-size", &size);
+ if (ret)
+ return -ENODEV;
+
+ ret = device_property_read_string(dev, "extcon-name", &extcon_name);
+ if (!ret)
+ mux->desc.extcon_name = extcon_name;
+
+ mux->regs = devm_ioremap_nocache(dev, start, size);
+ if (!mux->regs)
+ return -ENOMEM;
+
+ mux->desc.dev = dev;
+ mux->desc.name = "intel-mux-drcfg";
+ mux->desc.ops = &drcfg_ops;
+ mux->desc.initial_state =
+ !!(readl(mux->regs + INTEL_MUX_CFG1) & CFG1_MODE);
+ dev_set_drvdata(dev, mux);
+ mux->pdev = portmux_register(&mux->desc);
