Re: [PATCH v5 1/4] usb: dbc: early driver for xhci debug capability

[Lu Baolu]

Hi Ingo,

On 01/26/2017 03:19 PM, Ingo Molnar wrote:
> * Lu Baolu  wrote:
>
>> Fair enough.
>>
>> USB connection is stable enough, unless the user unplugs the
>> USB cable during debugging.
> What does the hardware do in this case? The XHCI registers are in the host 
> hardware, so they won't disappear, right? Is there some cable connection 
> status 
> bit we can extract without interrupts?

Yes, there are register bits for us to know the cable status. I will go
through the spec again and give you more accurate answer later.

I'm sorry. I will be off during the next 7 days for Chinese New Year
holiday. My email access will be very limited during this time. I will
revisit this thread after I am back from holiday.

Sorry for the inconvenience.

Best regards,
Lu Baolu

> I.e. if there's any polling component then it would be reasonable to add an 
> error 
> component: poll the status and if it goes 'disconnected' then disable 
> early-printk 
> altogether in this case and trigger an emergency printk() so that there's 
> chance 
> that the user notices [if the system does not misbehave otherwise].
>
> I.e. try to be as robust and informative as lockdep - yet don't lock up the 
> host 
> kernel: lockdep too is called from very deep internals, there are various 
> conditions where it sees corrupt data structures (i.e. a 'disconnect' - a 
> system 
> environment outside the normal bounds of operation), yet of the kernel and 
> over 
> the last 10+ years of lockdep's existence we had very, very few cases of 
> lockdep 
> itself locking up and behaving unpredictably.
>
> Thanks,
>
>   Ingo
>

--
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: Fwd: Regression: Line6 Toneport stops working on 4.10-rc5

[Greg KH]

On Thu, Jan 26, 2017 at 10:35:25AM +0300, Igor Zinovev wrote:
> Hello! This is essentially a replay of
> https://bugzilla.kernel.org/show_bug.cgi?id=193221 but sent to this
> mailing list as recommended by Greg Kroah-Hartman. Please let me know
> if I have missed something in this report.
> 
> So the problem is that I have been running Ubuntu with Linux 4.8
> kernel. Several days ago I have tried switching to latest from
> Mainline, i.e. 4.10-rc5 and the Line6 USB Toneport (UX2 Studio) has
> stopped working. There is no sound, playback freezes when I select the
> device.
> 
> Please let me know what information you need about my system - happy
> to provide logs and debug info.
> 
> Here's what uname says:
> 
> $ uname -a
> Linux precision 4.10.0-041000rc5-generic #201701221730 SMP Sun Jan 22
> 22:32:28 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
> 
> Thanks!
> 
> 
> -- 
> Igor Zinovyev

> [ 1234.842660] usb 1-2.2.3: USB disconnect, device number 10
> [ 1234.844279] snd_usb_toneport 1-2.2.3:1.0: Line 6 POD Studio UX2 now 
> disconnected
> [ 1243.773937] usb 1-2.2.3: new full-speed USB device number 12 using xhci_hcd
> [ 1243.885175] usb 1-2.2.3: New USB device found, idVendor=0e41, 
> idProduct=4151
> [ 1243.885179] usb 1-2.2.3: New USB device strings: Mfr=1, Product=2, 
> SerialNumber=0
> [ 1243.885182] usb 1-2.2.3: Product: UX2
> [ 1243.885185] usb 1-2.2.3: Manufacturer: Line 6
> [ 1243.886828] snd_usb_toneport 1-2.2.3:1.0: Line 6 POD Studio UX2 found
> [ 1243.890506] snd_usb_toneport 1-2.2.3:1.0: receive length failed (error -11)
> [ 1243.891072] snd_usb_toneport 1-2.2.3:1.0: read request failed (error -32)
> [ 1243.891087] snd_usb_toneport 1-2.2.3:1.0: write request failed (error -11)
> [ 1243.892813] snd_usb_toneport 1-2.2.3:1.0: Line 6 POD Studio UX2 now 
> attached
> [ 1244.432695] usb 1-2.2.4: usbfs: interface 1 claimed by usblp while 
> 'PanasonicMFSpus' sets config #1

Did you remove your device and then plug it back in?

And you said 4.8 worked, any chance you can use 'git bisect' to help
track down what commit caused the problem?

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 1/4] usb: dbc: early driver for xhci debug capability

[Ingo Molnar]

* Lu Baolu  wrote:

> 
> Hi,
> 
> On 01/25/2017 10:38 PM, Peter Zijlstra wrote:
> > On Wed, Jan 25, 2017 at 08:27:38PM +0800, Lu Baolu wrote:
> >> In my driver, udelay() is mostly used to handle time out.
> >>
> >> Xdbc hides most USB things in its firmware. Early printk driver only needs
> >> to setup the registers/data structures and wait until link ready or time 
> >> out.
> >> Without udelay(), I have no means to convert the polling times into waiting
> >> time.
> > What is timeout and why?
> 
> Put it in simple:
> 
> The driver sets the RUN bit in control register and polls READY
> bit in status register for the successful USB device enumeration.
> As the USB device enumeration might fail and the READY bit will
> never be set, the driver must have a timeout logic to avoid
> endless loop.

Is there any error status available in the host registers anywhere that tells 
us 
that enumeration did not succeed?

Thanks,

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 1/4] usb: dbc: early driver for xhci debug capability

[Ingo Molnar]

* Lu Baolu  wrote:

> Fair enough.
> 
> USB connection is stable enough, unless the user unplugs the
> USB cable during debugging.

What does the hardware do in this case? The XHCI registers are in the host 
hardware, so they won't disappear, right? Is there some cable connection status 
bit we can extract without interrupts?

I.e. if there's any polling component then it would be reasonable to add an 
error 
component: poll the status and if it goes 'disconnected' then disable 
early-printk 
altogether in this case and trigger an emergency printk() so that there's 
chance 
that the user notices [if the system does not misbehave otherwise].

I.e. try to be as robust and informative as lockdep - yet don't lock up the 
host 
kernel: lockdep too is called from very deep internals, there are various 
conditions where it sees corrupt data structures (i.e. a 'disconnect' - a 
system 
environment outside the normal bounds of operation), yet of the kernel and over 
the last 10+ years of lockdep's existence we had very, very few cases of 
lockdep 
itself locking up and behaving unpredictably.

Thanks,

Ingo
--
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 net v3 0/4] r8152: fix scheduling napi

[Hayes Wang]

David Miller [mailto:da...@davemloft.net]
> Sent: Thursday, January 26, 2017 11:48 AM
[...] 
> Series applied.

Thank you very much. I would try to find better way, too.

Best Regards,
Hayes

--
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 net v3 0/4] r8152: fix scheduling napi

[David Miller]

From: Hayes Wang 
Date: Thu, 26 Jan 2017 09:38:30 +0800

> v3:
> simply the argument for patch #3. Replace >napi with napi.
> 
> v2:
> Add smp_mb__after_atomic() for patch #1.
> 
> v1:
> Scheduling the napi during the following periods would let it be ignored.
> And the events wouldn't be handled until next napi_schedule() is called.
> 
> 1. after napi_disable and before napi_enable().
> 2. after all actions of napi function is completed and before calling
>napi_complete().
> 
> If no next napi_schedule() is called, tx or rx would stop working.
> 
> In order to avoid these situations, the followings solutions are applied.
> 
> 1. prevent start_xmit() from calling napi_schedule() during runtime suspend
>or after napi_disable().
> 2. re-schedule the napi for tx if it is necessary.
> 3. check if any rx is finished or not after napi_enable().

Series applied.
--
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 net v2 0/4] r8152: fix scheduling napi

[David Miller]

From: Hayes Wang 
Date: Thu, 26 Jan 2017 03:04:45 +

> May you apply these patches first, until I find another way to replace
> current one?

Yes, I will.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 1/4] usb: dbc: early driver for xhci debug capability

[Lu Baolu]

Hi,

On 01/26/2017 12:16 AM, Peter Zijlstra wrote:
> On Wed, Jan 25, 2017 at 11:51:34PM +0800, Lu Baolu wrote:
>
>>> What is timeout and why?
>> Put it in simple:
>>
>> The driver sets the RUN bit in control register and polls READY
>> bit in status register for the successful USB device enumeration.
>> As the USB device enumeration might fail and the READY bit will
>> never be set, the driver must have a timeout logic to avoid
>> endless loop.
>>
>> More details:
>>
>> The operational model is that driver sets up all necessary registers
>> and data structures, and then starts the debug engine by setting
>> the RUN/STOP bit in the control register.
>>
>> The debug engine then brings up itself as a ready-for-enumeration
>> USB device. The USB link between host and device starts link training
>> and then host will detect the connected device. The hub driver in
>> host will then starts the USB device enumeration processes (as defined
>> in USB spec). If everything goes smoothly, the device gets enumerated
>> and host can talk with the debug device.
>>
>> After that, xdbc firmware will set the READY bit in status register. And
>> the driver can go ahead with data transfer over USB.
> I have vague memories from a prior discussion where you said this READY
> state can be lost at any time (cable unplug or whatnot) and at that
> point the driver should re-start the setup, right?

Yes. So the documentation requires users not to unplug the usb
cable during debugging. This rule applies to other debug methods
as well.

>
>>>  If there is an error other than !ready, I would
>>> expect the hardware to inform you of this through another status bit,
>>> no?
>> Yeah, this might be another choice of hardware design. But it's not a
>> topic for this driver.
> So is there really no way to way to distinguish between "I did setup and
> am waiting for READY", "I did setup, am waiting for READY, but things
> got hosed" and "I was READY, things be hosed" ?
>
> I suppose the first and last can be distinguished by remembering if you
> ever saw READY, but the first and second are the interesting case I
> think.
>
>>> So why can't you poll indefinitely for either ready or error?
>>>
>> Even if the hardware has both ready and error status bits, it's still
>> nice to have a time out watch dog. Buggy hardware or firmware
>> might not set any of these bits. Polling indefinitely might result in
>> a endless loop.
> Loosing output, esp. without indication, is very _very_ annoying when
> you're debugging things. Its just about on par with a stuck system, at
> least then you know something bad happened.

Fair enough.

USB connection is stable enough, unless the user unplugs the
USB cable during debugging.

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 v5 1/4] usb: dbc: early driver for xhci debug capability

[Lu Baolu]

Hi Ingo,

On 01/25/2017 05:23 PM, Ingo Molnar wrote:
> * Lu Baolu  wrote:
>
>>> Hiding essentially an early udelay() implementation in an early-printk 
>>> driver is 
>>> ugly and counterproductive.
>> Sure. How about below change?
>>
>> diff --git a/drivers/usb/early/xhci-dbc.c b/drivers/usb/early/xhci-dbc.c
>> index d3f0c84..940989e 100644
>> --- a/drivers/usb/early/xhci-dbc.c
>> +++ b/drivers/usb/early/xhci-dbc.c
>> @@ -587,6 +587,35 @@ static int xdbc_bulk_transfer(void *data, int size, 
>> bool read)
>> return size;
>>  }
>>  
>> +static void __init xdbc_udelay_calibration(void)
>> +{
>> +   unsigned long lpj = 0;
>> +   unsigned int tsc_khz, cpu_khz;
>> +
>> +   if (!boot_cpu_has(X86_FEATURE_TSC))
>> +   goto calibration_out;
>> +
>> +   cpu_khz = x86_platform.calibrate_cpu();
>> +   tsc_khz = x86_platform.calibrate_tsc();
>> +
>> +   if (tsc_khz == 0)
>> +   tsc_khz = cpu_khz;
>> +   else if (abs(cpu_khz - tsc_khz) * 10 > tsc_khz)
>> +   cpu_khz = tsc_khz;
>> +
>> +   if (!tsc_khz)
>> +   goto calibration_out;
>> +
>> +   lpj = tsc_khz * 1000;
>> +   do_div(lpj, HZ);
>> +
>> +calibration_out:
>> +   if (!lpj)
>> +   lpj = 1 << 22;
>> +
>> +   loops_per_jiffy = lpj;
>> +}
>> +
>>  static int __init xdbc_early_setup(void)
>>  {
>> int ret;
>> @@ -686,6 +715,8 @@ int __init early_xdbc_parse_parameter(char *s)
>> }
>> xdbc.xdbc_reg = (struct xdbc_regs __iomem *)(xdbc.xhci_base + 
>> offset);
>>  
>> +   xdbc_udelay_calibration();
>> +
>> return 0;
>>  }
> Yeah - so could we do this in a more generic fashion, not in the early-printk 
> driver but in core x86 code?

How about below changes?

diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 4cfba94..aab7faa 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -835,6 +835,26 @@ dump_kernel_offset(struct notifier_block *self, unsigned 
long v, void *p)
return 0;
 }
 
+static void __init simple_udelay_calibration(void)
+{
+   unsigned int tsc_khz, cpu_khz;
+   unsigned long lpj;
+
+   if (!boot_cpu_has(X86_FEATURE_TSC))
+   return;
+
+   cpu_khz = x86_platform.calibrate_cpu();
+   tsc_khz = x86_platform.calibrate_tsc();
+
+   tsc_khz = tsc_khz ? : cpu_khz;
+   if (!tsc_khz)
+   return;
+
+   lpj = tsc_khz * 1000;
+   do_div(lpj, HZ);
+   loops_per_jiffy = lpj;
+}
+
 /*
  * Determine if we were loaded by an EFI loader.  If so, then we have also been
  * passed the efi memmap, systab, etc., so we should use these data structures
@@ -983,6 +1003,8 @@ void __init setup_arch(char **cmdline_p)
 */
x86_configure_nx();
 
+   simple_udelay_calibration();
+
parse_early_param();


If it's okay for you, do you want it in a separated patch or part of patch 2/4?

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 net v2 0/4] r8152: fix scheduling napi

[Hayes Wang]

David Miller [mailto:da...@davemloft.net]
> Sent: Thursday, January 26, 2017 3:31 AM
[...]
> I think the fundamental issue is that since you can't stop URBs from
> queueing up, you cannot properly synchronize NAPI and schedule polling
> properly.
> 
> From my perspective what happened here is you want GRO support, but it
> comes at the expense of this extremely racey NAPI support which does
> not at all achieve one of the main advantages of NAPI which is
> interrupt mitigation.

May you apply these patches first, until I find another way to replace
current one? The driver uses NAPI now and I have no idea to find better
way to replace current one. I think it would take me long time to find
out the solution. And the issue is still there until I finish this work.
If now I give up the NAPI and its advantages except for the interrupt
mitigation, some things would become worse.

Our hw supports packet aggregation. The purpose is interrupt mitigation,
too. I wouldn't say it is better than what the NAPI does. However, I
could say we try to improve it. If the interrupt could be disabled, I
would be happy to do it. However, it is the limitation of USB devices.
That is why I still use NAPI even though the interrupt cannot be disabled
for USB devices. Because one of the advantages of NAPI couldn't be
satisfied, I must not use the NAPI. Doesn't it seem too strict?

Best Regards,
Hayes

--
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: NAPI on USB network drivers

[Hayes Wang]

Eric Dumazet [mailto:eric.duma...@gmail.com]
> Sent: Wednesday, January 25, 2017 10:13 PM
[...]
> You also could use napi_complete_done() instead of napi_complete(), as
> it allows users to tune the performance vs latency for GRO.
> 
> Looking at this driver, I do not see any limitation on the number of
> skbs that can be pushed into tp->rx_queue.
> 
> I wonder if this queue can end up consuming all memory of a host under
> stress.
> 
> diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
> index
> e1466b4d2b6c727148a884672bbd9593bf04b3ac..221df4a931b5c1073f1922d0fa0b
> bff158c73b7d 100644
> --- a/drivers/net/usb/r8152.c
> +++ b/drivers/net/usb/r8152.c
> @@ -1840,7 +1840,10 @@ static int rx_bottom(struct r8152 *tp, int budget)
>   stats->rx_packets++;
>   stats->rx_bytes += pkt_len;
>   } else {
> - __skb_queue_tail(>rx_queue, skb);
> + if (unlikely(skb_queue_len(>rx_queue) >= 
> 1000))
> + kfree_skb(skb);
> + else
> + __skb_queue_tail(>rx_queue, skb);
>   }
> 
>  find_next_rx:

Thanks for your suggestion. I would submit it later.

Best Regards,
Hayes



N�r��yb�X��ǧv�^�)޺{.n�+{��^n�r���z���h�&���G���h�(�階�ݢj"���m��z�ޖ���f���h���~�m�

[PATCH net v3 1/4] r8152: avoid start_xmit to call napi_schedule during autosuspend

[Hayes Wang]

Adjust the setting of the flag of SELECTIVE_SUSPEND to prevent start_xmit()
from calling napi_schedule() directly during runtime suspend.

After calling napi_disable() or clearing the flag of WORK_ENABLE,
scheduling the napi is useless.

Signed-off-by: Hayes Wang 
---
 drivers/net/usb/r8152.c | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index e1466b4..23bef8e 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -3585,10 +3585,15 @@ static int rtl8152_rumtime_suspend(struct r8152 *tp)
struct net_device *netdev = tp->netdev;
int ret = 0;
 
+   set_bit(SELECTIVE_SUSPEND, >flags);
+   smp_mb__after_atomic();
+
if (netif_running(netdev) && test_bit(WORK_ENABLE, >flags)) {
u32 rcr = 0;
 
if (delay_autosuspend(tp)) {
+   clear_bit(SELECTIVE_SUSPEND, >flags);
+   smp_mb__after_atomic();
ret = -EBUSY;
goto out1;
}
@@ -3605,6 +3610,8 @@ static int rtl8152_rumtime_suspend(struct r8152 *tp)
if (!(ocp_data & RXFIFO_EMPTY)) {
rxdy_gated_en(tp, false);
ocp_write_dword(tp, MCU_TYPE_PLA, PLA_RCR, rcr);
+   clear_bit(SELECTIVE_SUSPEND, >flags);
+   smp_mb__after_atomic();
ret = -EBUSY;
goto out1;
}
@@ -3624,8 +3631,6 @@ static int rtl8152_rumtime_suspend(struct r8152 *tp)
}
}
 
-   set_bit(SELECTIVE_SUSPEND, >flags);
-
 out1:
return ret;
 }
@@ -3681,12 +3686,13 @@ static int rtl8152_resume(struct usb_interface *intf)
if (netif_running(tp->netdev) && tp->netdev->flags & IFF_UP) {
if (test_bit(SELECTIVE_SUSPEND, >flags)) {
tp->rtl_ops.autosuspend_en(tp, false);
-   clear_bit(SELECTIVE_SUSPEND, >flags);
napi_disable(>napi);
set_bit(WORK_ENABLE, >flags);
if (netif_carrier_ok(tp->netdev))
rtl_start_rx(tp);
napi_enable(>napi);
+   clear_bit(SELECTIVE_SUSPEND, >flags);
+   smp_mb__after_atomic();
} else {
tp->rtl_ops.up(tp);
netif_carrier_off(tp->netdev);
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH net v3 3/4] r8152: re-schedule napi for tx

[Hayes Wang]

Re-schedule napi after napi_complete() for tx, if it is necessay.

In r8152_poll(), if the tx is completed after tx_bottom() and before
napi_complete(), the scheduling of napi would be lost. Then, no
one handles the next tx until the next napi_schedule() is called.

Signed-off-by: Hayes Wang 
---
 drivers/net/usb/r8152.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index ec882be..4785d2b 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -1936,6 +1936,9 @@ static int r8152_poll(struct napi_struct *napi, int 
budget)
napi_complete(napi);
if (!list_empty(>rx_done))
napi_schedule(napi);
+   else if (!skb_queue_empty(>tx_queue) &&
+!list_empty(>tx_free))
+   napi_schedule(napi);
}
 
return work_done;
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH net v3 4/4] r8152: check rx after napi is enabled

[Hayes Wang]

Schedule the napi after napi_enable() for rx, if it is necessary.

If the rx is completed when napi is disabled, the sheduling of napi
would be lost. Then, no one handles the rx packet until next napi
is scheduled.

Signed-off-by: Hayes Wang 
---
 drivers/net/usb/r8152.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 4785d2b..ad42295 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -32,7 +32,7 @@
 #define NETNEXT_VERSION"08"
 
 /* Information for net */
-#define NET_VERSION"7"
+#define NET_VERSION"8"
 
 #define DRIVER_VERSION "v1." NETNEXT_VERSION "." NET_VERSION
 #define DRIVER_AUTHOR "Realtek linux nic maintainers "
@@ -3561,6 +3561,9 @@ static int rtl8152_post_reset(struct usb_interface *intf)
netif_wake_queue(netdev);
usb_submit_urb(tp->intr_urb, GFP_KERNEL);
 
+   if (!list_empty(>rx_done))
+   napi_schedule(>napi);
+
return 0;
 }
 
@@ -3700,6 +3703,8 @@ static int rtl8152_resume(struct usb_interface *intf)
napi_enable(>napi);
clear_bit(SELECTIVE_SUSPEND, >flags);
smp_mb__after_atomic();
+   if (!list_empty(>rx_done))
+   napi_schedule(>napi);
} else {
tp->rtl_ops.up(tp);
netif_carrier_off(tp->netdev);
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH net v3 0/4] r8152: fix scheduling napi

[Hayes Wang]

v3:
simply the argument for patch #3. Replace >napi with napi.

v2:
Add smp_mb__after_atomic() for patch #1.

v1:
Scheduling the napi during the following periods would let it be ignored.
And the events wouldn't be handled until next napi_schedule() is called.

1. after napi_disable and before napi_enable().
2. after all actions of napi function is completed and before calling
   napi_complete().

If no next napi_schedule() is called, tx or rx would stop working.

In order to avoid these situations, the followings solutions are applied.

1. prevent start_xmit() from calling napi_schedule() during runtime suspend
   or after napi_disable().
2. re-schedule the napi for tx if it is necessary.
3. check if any rx is finished or not after napi_enable().

Hayes Wang (4):
  r8152: avoid start_xmit to call napi_schedule during autosuspend
  r8152: avoid start_xmit to schedule napi when napi is disabled
  r8152: re-schedule napi for tx
  r8152: check rx after napi is enabled

 drivers/net/usb/r8152.c | 26 --
 1 file changed, 20 insertions(+), 6 deletions(-)

-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH net v3 2/4] r8152: avoid start_xmit to schedule napi when napi is disabled

[Hayes Wang]

Stop the tx when the napi is disabled to prevent napi_schedule() is
called.

Signed-off-by: Hayes Wang 
---
 drivers/net/usb/r8152.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 23bef8e..ec882be 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -3155,10 +3155,13 @@ static void set_carrier(struct r8152 *tp)
if (!netif_carrier_ok(netdev)) {
tp->rtl_ops.enable(tp);
set_bit(RTL8152_SET_RX_MODE, >flags);
+   netif_stop_queue(netdev);
napi_disable(>napi);
netif_carrier_on(netdev);
rtl_start_rx(tp);
napi_enable(>napi);
+   netif_wake_queue(netdev);
+   netif_info(tp, link, netdev, "carrier on\n");
}
} else {
if (netif_carrier_ok(netdev)) {
@@ -3166,6 +3169,7 @@ static void set_carrier(struct r8152 *tp)
napi_disable(>napi);
tp->rtl_ops.disable(tp);
napi_enable(>napi);
+   netif_info(tp, link, netdev, "carrier off\n");
}
}
 }
@@ -3515,12 +3519,12 @@ static int rtl8152_pre_reset(struct usb_interface *intf)
if (!netif_running(netdev))
return 0;
 
+   netif_stop_queue(netdev);
napi_disable(>napi);
clear_bit(WORK_ENABLE, >flags);
usb_kill_urb(tp->intr_urb);
cancel_delayed_work_sync(>schedule);
if (netif_carrier_ok(netdev)) {
-   netif_stop_queue(netdev);
mutex_lock(>control);
tp->rtl_ops.disable(tp);
mutex_unlock(>control);
@@ -3548,10 +3552,10 @@ static int rtl8152_post_reset(struct usb_interface 
*intf)
rtl_start_rx(tp);
rtl8152_set_rx_mode(netdev);
mutex_unlock(>control);
-   netif_wake_queue(netdev);
}
 
napi_enable(>napi);
+   netif_wake_queue(netdev);
usb_submit_urb(tp->intr_urb, GFP_KERNEL);
 
return 0;
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH net v2 3/4] r8152: re-schedule napi for tx

[Hayes Wang]

Eric Dumazet [mailto:eric.duma...@gmail.com]
> Sent: Wednesday, January 25, 2017 9:57 PM
[...]
> > napi_complete(napi);
> > if (!list_empty(>rx_done))
> > napi_schedule(napi);
> > +   else if (!skb_queue_empty(>tx_queue) &&
> > +!list_empty(>tx_free))
> > +   napi_schedule(>napi);
> 
> Why using >napi instead of napi here, as done 3 lines above ?

Oops. I would fix it. Thanks.

Best Regards,
Hayes

Re: [PATCH v2] usb: dwc3: handle DWC_USB3_NUM == DWC_USB3_NUM_IN_EPS

[John Youn]

On 1/24/2017 3:14 PM, Bryan O'Donoghue wrote:
>
>
> On 24/01/17 19:25, John Youn wrote:
>> On 1/24/2017 3:05 AM, Bryan O'Donoghue wrote:
>>> On 23/01/17 22:34, John Youn wrote:
 On 1/23/2017 2:10 PM, Alan Stern wrote:
> On Mon, 23 Jan 2017, John Youn wrote:
>
>> On 1/22/2017 5:29 PM, Bryan O'Donoghue wrote:
>>> - DWC_USB3_NUM indicates the number of Device mode single directional
>>>   endpoints, including OUT and IN endpoint 0.
>>>
>>> - DWC_USB3_NUM_IN_EPS indicates the maximum number of Device mode IN
>>>   endpoints active at any time, including control endpoint 0.
>>>
>>> It's possible to configure RTL such that DWC_USB3_NUM_EPS is equal to
>>> DWC_USB3_NUM_IN_EPS.
>>>
>>> dwc3-core calculates the number of OUT endpoints as DWC_USB3_NUM minus
>>> DWC_USB3_NUM_IN_EPS. If RTL has been configured with DWC_USB3_NUM_IN_EPS
>>> equal to DWC_USB3_NUM then dwc3-core will calculate the number of OUT
>>> endpoints as zero.
>>>
>>> For example a from dwc3_core_num_eps() shows:
>>> [1.565000]  /usb0@f01d: found 8 IN and 0 OUT endpoints
>>>
>>> This patch works around this case by detecting when DWC_USB3_NUM_EPS is
>>> equal to DWC3_USB3_NUM_IN_EPS and over-rides the calculation of the 
>>> number
>>
>> What if NUM_IN_EPS=7 and NUM_EPS=8? You will still have a problem.
>>
>> It's possible to fix this for the general case rather than for this
>> specific case.
>
> What is the reason for computing NUM_OUT_EPS in the first place?
> Isn't it true that any endpoint can be used as an OUT endpoint?
>
> So the real restrictions on a configuration are:
>
>   number of IN endpoints <= NUM_IN_EPS, and
>
>   number of IN endpoints + number of OUT endpoints <= NUM_EPS,
>
> where ep0 must be counted twice, as both an IN and an OUT endpoint.
> The value of NUM_OUT_EPS isn't used and shouldn't matter.
>

 Yes that's correct. The general fix should take all that into account
 so that any combination of NUM_EPS and NUM_IN_EPS will work fine.

 However it must also account for FPGA configs where each HW endpoint
 has a fixed number/direction, which the current code is compatible
 with.
>>>
>>> I'm not scanning something here..
>>>
>>> If FPGA configurations can have fixed endpoint directions then you could
>>> conceivably have a control IN/OUT pair plus a number a fixed
>>> configuration of all IN or all OUT endpoints, even checking
>>> GHWPARAMS6.EN_FPGA wouldn't let you know which direction those endpoints
>>> had been configured to.
>>>
>>> If I understand you correctly an FPGA could have pretty much any bit-map
>>> of fixed endpoint directions - so just calculating the number of IN/OUT
>>> endpoints based on some combination of DWC_USB3_NUM_IN_EPS and
>>> DWC_USB3_NUM_EPS wouldn't inform you of the fixed direction of an
>>> individual endpoint ... You'd need a descriptor specifying the fixed
>>> direction of each endpoint right ?
>>>
>>
>> Hi Bryan,
>>
>> The EP num and direction are fixed in a predefined way.
>
> Fair enough.
>
> See
>> DWC_USB3_EN_LOG_PHYS_EP_SUPT in the databook and my earlier reply to
>> Felipe.
>
> Thanks, I'll take a look tomorrow when I have the databook in front of me.
>
>> Unfortunately GHWPARAMS6.EN_FPGA doesn't directly tell you that
>> DWC_USB3_EN_LOG_PHYS_EP_SUPT is disabled. We just have to make that
>> assumption. Or add a quirk.
>
> So, if I'm understanding the conclusion.
>
> 1. We'll go ahead and make a change to just grab the # of endpoints
> I'll send out that patch once its tested.
> 2. For 4.12 Filipe will do something for the # of IN endpoints

Up to here, it should be fine, and it will fix your case. It will work
with all cores but in a more limited fashion by not allowing endpoints
to be truly bidirectional.

> 3. A quirk may eventually be required for DWC_USB3_EN_LOG_PHYS_EP_SUPT
> but lets no do anything on that unless someone actually complains.

I think it should be that if someone complains about the above
limitations:

3. Rework endpoint code to remove the limitations and work correctly
for any direction. This should be the default behavior.

4. Then based on EN_FPGA and/or a quirk, revert to previous behavior.

Regards,
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: [PATCH v2] usb: dwc2: fix "iomem 0x00000000" message

[John Youn]

On 1/25/2017 2:14 PM, Heiner Kallweit wrote:
> Set the iomem parameters in the usb_hcd to fix this misleading
> message during driver load:
> dwc2 c910.usb: irq 22, io mem 0x
>
> Signed-off-by: Heiner Kallweit 
> ---
> v2:
> - get info from hsotg->dev instead of adding a function parameter
> ---
>  drivers/usb/dwc2/hcd.c | 7 +++
>  1 file changed, 7 insertions(+)
>
> diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
> index 98249be1..fa8a9f27 100644
> --- a/drivers/usb/dwc2/hcd.c
> +++ b/drivers/usb/dwc2/hcd.c
> @@ -42,6 +42,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -4966,6 +4967,8 @@ static void dwc2_hcd_release(struct dwc2_hsotg *hsotg)
>   */
>  int dwc2_hcd_init(struct dwc2_hsotg *hsotg, int irq)
>  {
> + struct platform_device *pdev = to_platform_device(hsotg->dev);
> + struct resource *res;
>   struct usb_hcd *hcd;
>   struct dwc2_host_chan *channel;
>   u32 hcfg;
> @@ -5021,6 +5024,10 @@ int dwc2_hcd_init(struct dwc2_hsotg *hsotg, int irq)
>
>   hcd->has_tt = 1;
>
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + hcd->rsrc_start = res->start;
> + hcd->rsrc_len = resource_size(res);
> +
>   ((struct wrapper_priv_data *)>hcd_priv)->hsotg = hsotg;
>   hsotg->priv = hcd;
>
>


Acked-by: John Youn 

Thanks,
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: [PATCH] usb: dwc2: eliminate irq parameter from dwc2_hcd_init

[John Youn]

On 1/25/2017 2:14 PM, Heiner Kallweit wrote:
> The irq is available in hsotg already, so there's no need to
> pass it as separate function parameter.
>
> Signed-off-by: Heiner Kallweit 
> ---
>  drivers/usb/dwc2/core.h | 2 +-
>  drivers/usb/dwc2/hcd.c  | 4 ++--
>  drivers/usb/dwc2/hcd.h  | 2 +-
>  drivers/usb/dwc2/platform.c | 2 +-
>  4 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
> index 570a8004..e89943ff 100644
> --- a/drivers/usb/dwc2/core.h
> +++ b/drivers/usb/dwc2/core.h
> @@ -1245,7 +1245,7 @@ static inline void dwc2_hcd_connect(struct dwc2_hsotg 
> *hsotg) {}
>  static inline void dwc2_hcd_disconnect(struct dwc2_hsotg *hsotg, bool force) 
> {}
>  static inline void dwc2_hcd_start(struct dwc2_hsotg *hsotg) {}
>  static inline void dwc2_hcd_remove(struct dwc2_hsotg *hsotg) {}
> -static inline int dwc2_hcd_init(struct dwc2_hsotg *hsotg, int irq)
> +static inline int dwc2_hcd_init(struct dwc2_hsotg *hsotg)
>  { return 0; }
>  static inline int dwc2_backup_host_registers(struct dwc2_hsotg *hsotg)
>  { return 0; }
> diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
> index fa8a9f27..ef568c46 100644
> --- a/drivers/usb/dwc2/hcd.c
> +++ b/drivers/usb/dwc2/hcd.c
> @@ -4965,7 +4965,7 @@ static void dwc2_hcd_release(struct dwc2_hsotg *hsotg)
>   * USB bus with the core and calls the hc_driver->start() function. It 
> returns
>   * a negative error on failure.
>   */
> -int dwc2_hcd_init(struct dwc2_hsotg *hsotg, int irq)
> +int dwc2_hcd_init(struct dwc2_hsotg *hsotg)
>  {
>   struct platform_device *pdev = to_platform_device(hsotg->dev);
>   struct resource *res;
> @@ -5168,7 +5168,7 @@ int dwc2_hcd_init(struct dwc2_hsotg *hsotg, int irq)
>* allocates the DMA buffer pool, registers the USB bus, requests the
>* IRQ line, and calls hcd_start method.
>*/
> - retval = usb_add_hcd(hcd, irq, IRQF_SHARED);
> + retval = usb_add_hcd(hcd, hsotg->irq, IRQF_SHARED);
>   if (retval < 0)
>   goto error4;
>
> diff --git a/drivers/usb/dwc2/hcd.h b/drivers/usb/dwc2/hcd.h
> index 58bfe9f5..11c3c145 100644
> --- a/drivers/usb/dwc2/hcd.h
> +++ b/drivers/usb/dwc2/hcd.h
> @@ -521,7 +521,7 @@ static inline u8 dwc2_hcd_is_pipe_out(struct 
> dwc2_hcd_pipe_info *pipe)
>   return !dwc2_hcd_is_pipe_in(pipe);
>  }
>
> -int dwc2_hcd_init(struct dwc2_hsotg *hsotg, int irq);
> +int dwc2_hcd_init(struct dwc2_hsotg *hsotg);
>  void dwc2_hcd_remove(struct dwc2_hsotg *hsotg);
>
>  /* Transaction Execution Functions */
> diff --git a/drivers/usb/dwc2/platform.c b/drivers/usb/dwc2/platform.c
> index 3f59a73d..9564bc76 100644
> --- a/drivers/usb/dwc2/platform.c
> +++ b/drivers/usb/dwc2/platform.c
> @@ -445,7 +445,7 @@ static int dwc2_driver_probe(struct platform_device *dev)
>   }
>
>   if (hsotg->dr_mode != USB_DR_MODE_PERIPHERAL) {
> - retval = dwc2_hcd_init(hsotg, hsotg->irq);
> + retval = dwc2_hcd_init(hsotg);
>   if (retval) {
>   if (hsotg->gadget_enabled)
>   dwc2_hsotg_remove(hsotg);
>

Acked-by: John Youn 

John

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v8 2/3] phy: Add support for Qualcomm's USB HSIC phy

[Stephen Boyd]

The HSIC USB controller on qcom SoCs has an integrated all
digital phy controlled via the ULPI viewport.

Cc: Kishon Vijay Abraham I 
Acked-by: Rob Herring 
Cc: 
Signed-off-by: Stephen Boyd 
---
 .../devicetree/bindings/phy/qcom,usb-hsic-phy.txt  |  65 +
 drivers/phy/Kconfig|   7 +
 drivers/phy/Makefile   |   1 +
 drivers/phy/phy-qcom-usb-hsic.c| 160 +
 4 files changed, 233 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/qcom,usb-hsic-phy.txt
 create mode 100644 drivers/phy/phy-qcom-usb-hsic.c

diff --git a/Documentation/devicetree/bindings/phy/qcom,usb-hsic-phy.txt 
b/Documentation/devicetree/bindings/phy/qcom,usb-hsic-phy.txt
new file mode 100644
index ..3c7cb2be4b12
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/qcom,usb-hsic-phy.txt
@@ -0,0 +1,65 @@
+Qualcomm's USB HSIC PHY
+
+PROPERTIES
+
+- compatible:
+Usage: required
+Value type: 
+Definition: Should contain "qcom,usb-hsic-phy" and more specifically one 
of the
+   following:
+
+   "qcom,usb-hsic-phy-mdm9615"
+   "qcom,usb-hsic-phy-msm8974"
+
+- #phy-cells:
+Usage: required
+Value type: 
+Definition: Should contain 0
+
+- clocks:
+Usage: required
+Value type: 
+Definition: Should contain clock specifier for phy, calibration and
+a calibration sleep clock
+
+- clock-names:
+Usage: required
+Value type: 
+Definition: Should contain "phy, "cal" and "cal_sleep"
+
+- pinctrl-names:
+Usage: required
+Value type: 
+Definition: Should contain "init" and "default" in that order
+
+- pinctrl-0:
+Usage: required
+Value type: 
+Definition: List of pinctrl settings to apply to keep HSIC pins in a glitch
+free state
+
+- pinctrl-1:
+Usage: required
+Value type: 
+Definition: List of pinctrl settings to apply to mux out the HSIC pins
+
+EXAMPLE
+
+usb-controller {
+   ulpi {
+   phy {
+   compatible = "qcom,usb-hsic-phy-msm8974",
+"qcom,usb-hsic-phy";
+   #phy-cells = <0>;
+   pinctrl-names = "init", "default";
+   pinctrl-0 = <_sleep>;
+   pinctrl-1 = <_default>;
+   clocks = < GCC_USB_HSIC_CLK>,
+< GCC_USB_HSIC_IO_CAL_CLK>,
+< GCC_USB_HSIC_IO_CAL_SLEEP_CLK>;
+   clock-names = "phy", "cal", "cal_sleep";
+   assigned-clocks = < GCC_USB_HSIC_IO_CAL_CLK>;
+   assigned-clock-rates = <96>;
+   };
+   };
+};
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index e8eb7f225a88..a430a64981d5 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -437,6 +437,13 @@ config PHY_QCOM_UFS
help
  Support for UFS PHY on QCOM chipsets.
 
+config PHY_QCOM_USB_HSIC
+   tristate "Qualcomm USB HSIC ULPI PHY module"
+   depends on USB_ULPI_BUS
+   select GENERIC_PHY
+   help
+ Support for the USB HSIC ULPI compliant PHY on QCOM chipsets.
+
 config PHY_TUSB1210
tristate "TI TUSB1210 ULPI PHY module"
depends on USB_ULPI_BUS
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 65eb2f436a41..c43c9df5d301 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -52,6 +52,7 @@ obj-$(CONFIG_PHY_STIH407_USB) += phy-stih407-usb.o
 obj-$(CONFIG_PHY_QCOM_UFS) += phy-qcom-ufs.o
 obj-$(CONFIG_PHY_QCOM_UFS) += phy-qcom-ufs-qmp-20nm.o
 obj-$(CONFIG_PHY_QCOM_UFS) += phy-qcom-ufs-qmp-14nm.o
+obj-$(CONFIG_PHY_QCOM_USB_HSIC)+= phy-qcom-usb-hsic.o
 obj-$(CONFIG_PHY_TUSB1210) += phy-tusb1210.o
 obj-$(CONFIG_PHY_BRCM_SATA)+= phy-brcm-sata.o
 obj-$(CONFIG_PHY_PISTACHIO_USB)+= phy-pistachio-usb.o
diff --git a/drivers/phy/phy-qcom-usb-hsic.c b/drivers/phy/phy-qcom-usb-hsic.c
new file mode 100644
index ..47690f9945b9
--- /dev/null
+++ b/drivers/phy/phy-qcom-usb-hsic.c
@@ -0,0 +1,160 @@
+/**
+ * Copyright (C) 2016 Linaro Ltd
+ *
+ * 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 
+#include 
+
+#include "ulpi_phy.h"
+
+#define ULPI_HSIC_CFG  0x30
+#define ULPI_HSIC_IO_CAL   0x33
+
+struct qcom_usb_hsic_phy {
+   struct ulpi *ulpi;
+   struct phy *phy;
+   struct pinctrl *pctl;
+   struct clk *phy_clk;
+   struct clk *cal_clk;
+   struct clk *cal_sleep_clk;
+};
+
+static int 

[PATCH v8 0/3] Support qcom's HSIC USB and rewrite USB2 HS support

[Stephen Boyd]

This patch series continues the usb chipidea rewrite for 
Qualcommm platforms. I've dropped the patches that were applied
to Peter's tree for chipidea. Now the phy drivers are left,
along with the patch to call phy_set_mode() at the right place.

I've left the HSIC phy driver here, because it wasn't merged in
the last round. Nothing has changed in that driver, so I believe
it is ready to be merged now. The chipidea patch is independent and
can be merged without causing any dependency with the phy tree.

Patches based on v4.10-rc1 + first 22 patches from v5. Full
branch is here[1].

Changes from v7:
 * Dropped set_vbus() callback (Kishon)
 * Made phy_set_mode() generic and moved into ci_platform_configure() (Peter)

Changes from v6:
 * Dropped first 22 applied patches
 * Rewrote phy_set_mode() patch to be msm specific
 * New set_vbus() callback in phy framework
 * Updated HS phy driver for set_vbus() callback

Changes from v5:
 * Replaced "Emulate OTGSC interrupt enable path" patch with a patch
   from Peter
 * Updated HS phy driver to support set_mode callback to handle pullup
 * New patch to set the mode to device or host in chipidea udc pullup
   function to toggle the pullup for HS mode
 * New patch to drop lock around event_notify callback to avoid lockdep
   issues
 * Removal of extcon usage from HS phy driver
 * Picked up acks from Heikki and Peter on ULPI core patch

Changes from v4:
 * Picked up Acks from Rob
 * Updated HS phy init sequence DT property to restrict it to offsets

Changes from v3:
 * Picked up Acks from Peter
 * Updated extcon consolidation patch per Peter's comments
 * Folded in simplification from Heikki for ULPI DT matching

Changes from v2:
 * Added SoC specific compatibles in phy bindings
 * Dropped AVVIS patch for OTG statemachine
 * New patch to consolidate extcon handlers
 * Picked up Acks from Peter
 * Rebased onto v4.8-rc1
 * Reworked ULPI OF code to look at vid == 0 instead of pid == 0
 * Dropped ULPI bindings for vid and pid overrides

Changes from v1:
 * Reworked ULPI device probing to keep using vendor/product ids that
   come from DT if needed and falls back to OF style match when product id
   is 0
 * PHY init later patch was rejected so that moved to a quirk flag and
   the msm wrapper started managing the phy on/off
 * Updated clk requirements for HSIC phy in binding doc
 * Added optional clk in wrapper for "housekeeping" found on older qcom
   platforms
 * Bug fix to OTGSC polling function
 * Changed runtime PM patch to set as active instead of get/put

TODO:
 * DMA fails on arm64 so we need something like [2] to make it work.
 * The db410c needs a driver to toggle the onboard switch to connect
   the usb hub instead of micro port when the usb cable is disconnected.
   I've sent a patch set for this[3], which needs some further
   discussion/development. The current plan is to reintroduce the usb
   mux framework.
 * apq8064 platforms need a vbus regulator to really use otg and I haven't
   tried out the RPM based regulators yet
 * The HSIC phy on the apq8074 dragonboard is connected to a usb4604
   device which requires the i2c driver to probe and send an i2c
   sequence before the HSIC controller enumerates or HSIC doesn't work.
   Right now I have a hack to force the controller to probe defer
   once so that usb4604 probes first. This needs a more proper solution
   like having the DT describe a linkage between the controller and
   the usb device so we can enforce probe ordering. My current plan
   is to use DT graphs/endpoints for this.

[1] https://git.linaro.org/people/stephen.boyd/linux.git/log/?h=usb-hsic-8074
[2] https://patchwork.kernel.org/patch/9319527/
[3] https://lkml.kernel.org/r/20160914014246.31847-1-stephen.b...@linaro.org

Stephen Boyd (3):
  usb: chipidea: Configure phy for appropriate mode
  phy: Add support for Qualcomm's USB HSIC phy
  phy: Add support for Qualcomm's USB HS phy

 .../devicetree/bindings/phy/qcom,usb-hs-phy.txt|  84 ++
 .../devicetree/bindings/phy/qcom,usb-hsic-phy.txt  |  65 +
 drivers/phy/Kconfig|  15 ++
 drivers/phy/Makefile   |   2 +
 drivers/phy/phy-qcom-usb-hs.c  | 296 +
 drivers/phy/phy-qcom-usb-hsic.c| 160 +++
 drivers/usb/chipidea/core.c|  20 +-
 7 files changed, 636 insertions(+), 6 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/phy/qcom,usb-hs-phy.txt
 create mode 100644 Documentation/devicetree/bindings/phy/qcom,usb-hsic-phy.txt
 create mode 100644 drivers/phy/phy-qcom-usb-hs.c
 create mode 100644 drivers/phy/phy-qcom-usb-hsic.c

-- 
2.10.0.297.gf6727b0

--
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 v8 1/3] usb: chipidea: Configure phy for appropriate mode

[Stephen Boyd]

When the qcom chipidea controller is used with an extcon, we need
to signal device mode or host mode to the phy so it can configure
itself for the correct mode. This should be done after the phy is
powered up, so that the register writes work correctly. Add in
the appropriate phy_set_mode() call here.

Cc: Peter Chen 
Cc: Greg Kroah-Hartman 
Signed-off-by: Stephen Boyd 
---
 drivers/usb/chipidea/core.c | 20 ++--
 1 file changed, 14 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index 802ca253cf6d..fc3b9e07aa81 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -428,13 +428,21 @@ void ci_platform_configure(struct ci_hdrc *ci)
is_device_mode = hw_read(ci, OP_USBMODE, USBMODE_CM) == USBMODE_CM_DC;
is_host_mode = hw_read(ci, OP_USBMODE, USBMODE_CM) == USBMODE_CM_HC;
 
-   if (is_device_mode &&
-   (ci->platdata->flags & CI_HDRC_DISABLE_DEVICE_STREAMING))
-   hw_write(ci, OP_USBMODE, USBMODE_CI_SDIS, USBMODE_CI_SDIS);
+   if (is_device_mode) {
+   phy_set_mode(ci->phy, PHY_MODE_USB_DEVICE);
 
-   if (is_host_mode &&
-   (ci->platdata->flags & CI_HDRC_DISABLE_HOST_STREAMING))
-   hw_write(ci, OP_USBMODE, USBMODE_CI_SDIS, USBMODE_CI_SDIS);
+   if (ci->platdata->flags & CI_HDRC_DISABLE_DEVICE_STREAMING)
+   hw_write(ci, OP_USBMODE, USBMODE_CI_SDIS,
+USBMODE_CI_SDIS);
+   }
+
+   if (is_host_mode) {
+   phy_set_mode(ci->phy, PHY_MODE_USB_HOST);
+
+   if (ci->platdata->flags & CI_HDRC_DISABLE_HOST_STREAMING)
+   hw_write(ci, OP_USBMODE, USBMODE_CI_SDIS,
+USBMODE_CI_SDIS);
+   }
 
if (ci->platdata->flags & CI_HDRC_FORCE_FULLSPEED) {
if (ci->hw_bank.lpm)
-- 
2.10.0.297.gf6727b0

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] usb: phy: ab8500: remove unused ab8500_eyediagram_workaroud()

[Arnd Bergmann]

The only caller of this function is gone, so now we get a warning:

drivers/usb/phy/phy-ab8500-usb.c:1026:17: error: 'ab8500_eyediagram_workaroud' 
defined but not used [-Werror=unused-function]

It is possible that we should in fact still call the function from
somewhere else, but I don't see from where.

Fixes: 635f997a499b ("usb: phy: ab8500: Remove the set_power callback")
Signed-off-by: Arnd Bergmann 
---
 drivers/usb/phy/phy-ab8500-usb.c | 13 -
 1 file changed, 13 deletions(-)

diff --git a/drivers/usb/phy/phy-ab8500-usb.c b/drivers/usb/phy/phy-ab8500-usb.c
index 3dfbb978de67..61bf2285d5b1 100644
--- a/drivers/usb/phy/phy-ab8500-usb.c
+++ b/drivers/usb/phy/phy-ab8500-usb.c
@@ -1023,19 +1023,6 @@ static void ab8500_usb_vbus_turn_on_event_work(struct 
work_struct *work)
ab->enabled_charging_detection = true;
 }
 
-static unsigned ab8500_eyediagram_workaroud(struct ab8500_usb *ab, unsigned mA)
-{
-   /*
-* AB8500 V2 has eye diagram issues when drawing more than 100mA from
-* VBUS.  Set charging current to 100mA in case of standard host
-*/
-   if (is_ab8500_2p0_or_earlier(ab->ab8500))
-   if (mA > 100)
-   mA = 100;
-
-   return mA;
-}
-
 static int ab8500_usb_set_suspend(struct usb_phy *x, int suspend)
 {
/* TODO */
-- 
2.9.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

[PATCH] usb: dwc2: eliminate irq parameter from dwc2_hcd_init

[Heiner Kallweit]

The irq is available in hsotg already, so there's no need to
pass it as separate function parameter.

Signed-off-by: Heiner Kallweit 
---
 drivers/usb/dwc2/core.h | 2 +-
 drivers/usb/dwc2/hcd.c  | 4 ++--
 drivers/usb/dwc2/hcd.h  | 2 +-
 drivers/usb/dwc2/platform.c | 2 +-
 4 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index 570a8004..e89943ff 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -1245,7 +1245,7 @@ static inline void dwc2_hcd_connect(struct dwc2_hsotg 
*hsotg) {}
 static inline void dwc2_hcd_disconnect(struct dwc2_hsotg *hsotg, bool force) {}
 static inline void dwc2_hcd_start(struct dwc2_hsotg *hsotg) {}
 static inline void dwc2_hcd_remove(struct dwc2_hsotg *hsotg) {}
-static inline int dwc2_hcd_init(struct dwc2_hsotg *hsotg, int irq)
+static inline int dwc2_hcd_init(struct dwc2_hsotg *hsotg)
 { return 0; }
 static inline int dwc2_backup_host_registers(struct dwc2_hsotg *hsotg)
 { return 0; }
diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
index fa8a9f27..ef568c46 100644
--- a/drivers/usb/dwc2/hcd.c
+++ b/drivers/usb/dwc2/hcd.c
@@ -4965,7 +4965,7 @@ static void dwc2_hcd_release(struct dwc2_hsotg *hsotg)
  * USB bus with the core and calls the hc_driver->start() function. It returns
  * a negative error on failure.
  */
-int dwc2_hcd_init(struct dwc2_hsotg *hsotg, int irq)
+int dwc2_hcd_init(struct dwc2_hsotg *hsotg)
 {
struct platform_device *pdev = to_platform_device(hsotg->dev);
struct resource *res;
@@ -5168,7 +5168,7 @@ int dwc2_hcd_init(struct dwc2_hsotg *hsotg, int irq)
 * allocates the DMA buffer pool, registers the USB bus, requests the
 * IRQ line, and calls hcd_start method.
 */
-   retval = usb_add_hcd(hcd, irq, IRQF_SHARED);
+   retval = usb_add_hcd(hcd, hsotg->irq, IRQF_SHARED);
if (retval < 0)
goto error4;
 
diff --git a/drivers/usb/dwc2/hcd.h b/drivers/usb/dwc2/hcd.h
index 58bfe9f5..11c3c145 100644
--- a/drivers/usb/dwc2/hcd.h
+++ b/drivers/usb/dwc2/hcd.h
@@ -521,7 +521,7 @@ static inline u8 dwc2_hcd_is_pipe_out(struct 
dwc2_hcd_pipe_info *pipe)
return !dwc2_hcd_is_pipe_in(pipe);
 }
 
-int dwc2_hcd_init(struct dwc2_hsotg *hsotg, int irq);
+int dwc2_hcd_init(struct dwc2_hsotg *hsotg);
 void dwc2_hcd_remove(struct dwc2_hsotg *hsotg);
 
 /* Transaction Execution Functions */
diff --git a/drivers/usb/dwc2/platform.c b/drivers/usb/dwc2/platform.c
index 3f59a73d..9564bc76 100644
--- a/drivers/usb/dwc2/platform.c
+++ b/drivers/usb/dwc2/platform.c
@@ -445,7 +445,7 @@ static int dwc2_driver_probe(struct platform_device *dev)
}
 
if (hsotg->dr_mode != USB_DR_MODE_PERIPHERAL) {
-   retval = dwc2_hcd_init(hsotg, hsotg->irq);
+   retval = dwc2_hcd_init(hsotg);
if (retval) {
if (hsotg->gadget_enabled)
dwc2_hsotg_remove(hsotg);
-- 
2.11.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: dwc2: fix "iomem 0x00000000" message by setting iomem parameters in usb_hcd

[Heiner Kallweit]

Am 25.01.2017 um 22:28 schrieb John Youn:
> On 1/15/2017 12:37 PM, Heiner Kallweit wrote:
>> Set the iomem parameters in the usb_hcd to fix this misleading
>> message during driver load:
>> dwc2 c910.usb: irq 22, io mem 0x
>>
>> Signed-off-by: Heiner Kallweit 
>> ---
>>  drivers/usb/dwc2/core.h | 3 ++-
>>  drivers/usb/dwc2/hcd.c  | 5 -
>>  drivers/usb/dwc2/hcd.h  | 3 ++-
>>  drivers/usb/dwc2/platform.c | 2 +-
>>  4 files changed, 9 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
>> index 9548d3e0..b66eaeea 100644
>> --- a/drivers/usb/dwc2/core.h
>> +++ b/drivers/usb/dwc2/core.h
>> @@ -1229,7 +1229,8 @@ static inline void dwc2_hcd_connect(struct dwc2_hsotg 
>> *hsotg) {}
>>  static inline void dwc2_hcd_disconnect(struct dwc2_hsotg *hsotg, bool 
>> force) {}
>>  static inline void dwc2_hcd_start(struct dwc2_hsotg *hsotg) {}
>>  static inline void dwc2_hcd_remove(struct dwc2_hsotg *hsotg) {}
>> -static inline int dwc2_hcd_init(struct dwc2_hsotg *hsotg, int irq)
>> +static inline int dwc2_hcd_init(struct dwc2_hsotg *hsotg, int irq,
>> +struct resource *res)
>>  { return 0; }
>>  static inline int dwc2_backup_host_registers(struct dwc2_hsotg *hsotg)
>>  { return 0; }
>> diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
>> index 911c3b36..2cfbd10e 100644
>> --- a/drivers/usb/dwc2/hcd.c
>> +++ b/drivers/usb/dwc2/hcd.c
>> @@ -4964,7 +4964,7 @@ static void dwc2_hcd_release(struct dwc2_hsotg *hsotg)
>>   * USB bus with the core and calls the hc_driver->start() function. It 
>> returns
>>   * a negative error on failure.
>>   */
>> -int dwc2_hcd_init(struct dwc2_hsotg *hsotg, int irq)
>> +int dwc2_hcd_init(struct dwc2_hsotg *hsotg, int irq, struct resource *res)
>>  {
>>  struct usb_hcd *hcd;
>>  struct dwc2_host_chan *channel;
>> @@ -5021,6 +5021,9 @@ int dwc2_hcd_init(struct dwc2_hsotg *hsotg, int irq)
>>
>>  hcd->has_tt = 1;
>>
>> +hcd->rsrc_start = res->start;
>> +hcd->rsrc_len = resource_size(res);
> 
> You should be able to get the same from hsotg->dev instead of adding a
> paramter.
> 
> In fact, looks like the irq parameter is not needed either since it is 
> already stored in hsotg and can anyway get it from dev as well.
> 
> John
> 
Indeed. I'll send a v2 for the patch and another one for getting rid of
the irq function parameter.

Heiner

--
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] usb: dwc2: fix "iomem 0x00000000" message

[Heiner Kallweit]

Set the iomem parameters in the usb_hcd to fix this misleading
message during driver load:
dwc2 c910.usb: irq 22, io mem 0x

Signed-off-by: Heiner Kallweit 
---
v2:
- get info from hsotg->dev instead of adding a function parameter
---
 drivers/usb/dwc2/hcd.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
index 98249be1..fa8a9f27 100644
--- a/drivers/usb/dwc2/hcd.c
+++ b/drivers/usb/dwc2/hcd.c
@@ -42,6 +42,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -4966,6 +4967,8 @@ static void dwc2_hcd_release(struct dwc2_hsotg *hsotg)
  */
 int dwc2_hcd_init(struct dwc2_hsotg *hsotg, int irq)
 {
+   struct platform_device *pdev = to_platform_device(hsotg->dev);
+   struct resource *res;
struct usb_hcd *hcd;
struct dwc2_host_chan *channel;
u32 hcfg;
@@ -5021,6 +5024,10 @@ int dwc2_hcd_init(struct dwc2_hsotg *hsotg, int irq)
 
hcd->has_tt = 1;
 
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+   hcd->rsrc_start = res->start;
+   hcd->rsrc_len = resource_size(res);
+
((struct wrapper_priv_data *)>hcd_priv)->hsotg = hsotg;
hsotg->priv = hcd;
 
-- 
2.11.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: dwc2: fix "iomem 0x00000000" message by setting iomem parameters in usb_hcd

[John Youn]

On 1/15/2017 12:37 PM, Heiner Kallweit wrote:
> Set the iomem parameters in the usb_hcd to fix this misleading
> message during driver load:
> dwc2 c910.usb: irq 22, io mem 0x
>
> Signed-off-by: Heiner Kallweit 
> ---
>  drivers/usb/dwc2/core.h | 3 ++-
>  drivers/usb/dwc2/hcd.c  | 5 -
>  drivers/usb/dwc2/hcd.h  | 3 ++-
>  drivers/usb/dwc2/platform.c | 2 +-
>  4 files changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
> index 9548d3e0..b66eaeea 100644
> --- a/drivers/usb/dwc2/core.h
> +++ b/drivers/usb/dwc2/core.h
> @@ -1229,7 +1229,8 @@ static inline void dwc2_hcd_connect(struct dwc2_hsotg 
> *hsotg) {}
>  static inline void dwc2_hcd_disconnect(struct dwc2_hsotg *hsotg, bool force) 
> {}
>  static inline void dwc2_hcd_start(struct dwc2_hsotg *hsotg) {}
>  static inline void dwc2_hcd_remove(struct dwc2_hsotg *hsotg) {}
> -static inline int dwc2_hcd_init(struct dwc2_hsotg *hsotg, int irq)
> +static inline int dwc2_hcd_init(struct dwc2_hsotg *hsotg, int irq,
> + struct resource *res)
>  { return 0; }
>  static inline int dwc2_backup_host_registers(struct dwc2_hsotg *hsotg)
>  { return 0; }
> diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
> index 911c3b36..2cfbd10e 100644
> --- a/drivers/usb/dwc2/hcd.c
> +++ b/drivers/usb/dwc2/hcd.c
> @@ -4964,7 +4964,7 @@ static void dwc2_hcd_release(struct dwc2_hsotg *hsotg)
>   * USB bus with the core and calls the hc_driver->start() function. It 
> returns
>   * a negative error on failure.
>   */
> -int dwc2_hcd_init(struct dwc2_hsotg *hsotg, int irq)
> +int dwc2_hcd_init(struct dwc2_hsotg *hsotg, int irq, struct resource *res)
>  {
>   struct usb_hcd *hcd;
>   struct dwc2_host_chan *channel;
> @@ -5021,6 +5021,9 @@ int dwc2_hcd_init(struct dwc2_hsotg *hsotg, int irq)
>
>   hcd->has_tt = 1;
>
> + hcd->rsrc_start = res->start;
> + hcd->rsrc_len = resource_size(res);

You should be able to get the same from hsotg->dev instead of adding a
paramter.

In fact, looks like the irq parameter is not needed either since it is 
already stored in hsotg and can anyway get it from dev as well.

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: [PATCH] usb: musb: constify musb_hdrc_config structures

[Greg KH]

On Wed, Jan 25, 2017 at 10:58:15AM -0600, Bin Liu wrote:
> On Wed, Jan 25, 2017 at 12:52:22AM +0530, Bhumika Goyal wrote:
> > Declare musb_hdrc_config structures as const as they are only stored in
> > the config field of a musb_hdrc_platform_data structure. This field is of
> > type const, so musb_hdrc_config structures having this property can be
> > made const too.
> > Done using Coccinelle:
> > 
> > @r disable optional_qualifier@
> > identifier x;
> > position p;
> > @@
> > static struct musb_hdrc_config x@p={...};
> > 
> > @ok@
> > struct musb_hdrc_platform_data pdata;
> > identifier r.x;
> > position p;
> > @@
> > pdata.config=@p;
> > 
> > @bad@
> > position p != {r.p,ok.p};
> > identifier r.x;
> > @@
> > x@p
> > 
> > @depends on !bad disable optional_qualifier@
> > identifier r.x;
> > @@
> > +const
> > struct musb_hdrc_config x;
> > 
> > File size before:
> >textdata bss dec hex filename
> >1212 338   01550 60e drivers/usb/musb/jz4740.o
> > 
> > File size after:
> >textdata bss dec hex filename
> >1268 290   01558 616 drivers/usb/musb/jz4740.o
> > 
> > File size before:
> >textdata bss dec hex filename
> >6151 333  1665001964 drivers/usb/musb/sunxi.o
> > 
> > File size after:
> >textdata bss dec hex filename
> >6215 269  1665001964 drivers/usb/musb/sunxi.o
> > 
> > File size before:
> >textdata bss dec hex filename
> >3668 864   0453211b4 drivers/usb/musb/ux500.o
> > 
> > File size after:
> >textdata bss dec hex filename
> >3724 808   0453211b4 drivers/usb/musb/ux500.o
> > 
> > Signed-off-by: Bhumika Goyal 
> 
> Hi Greg,
> 
> Why you don't want this patch go through my tree? Now it causes me tree
> rebase failed. It should be easy to fix, but just wanted to learn your
> rules.

What are you rebasing?  And why?  Just send me patches, I can merge them
when they come in just fine.

Normally yes, I do wait for these to go through your tree, but it was
just so simple, and obvious, and in a bunch of others from the author,
that I figured I could just take it as-is.

sorry if it caused you problems, but you might want to look at your
development process if it is.  You should always be able to handle other
people changing files in your area at any point in time.  Kernel
maintainership is not "no one else can ever touch this!" type of
development, you have to be able to handle stuff like this easily.

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: dwc2: fix "iomem 0x00000000" message by setting iomem parameters in usb_hcd

[John Youn]

On 1/25/2017 12:37 PM, Heiner Kallweit wrote:
> Am 24.01.2017 um 09:46 schrieb Felipe Balbi:
>>
>> Hi,
>>
>> John Youn  writes:
 John Youn  writes:
> @@ -1229,7 +1229,8 @@ static inline void dwc2_hcd_connect(struct 
> dwc2_hsotg *hsotg) {}
>  static inline void dwc2_hcd_disconnect(struct dwc2_hsotg *hsotg, 
> bool force) {}
>  static inline void dwc2_hcd_start(struct dwc2_hsotg *hsotg) {}
>  static inline void dwc2_hcd_remove(struct dwc2_hsotg *hsotg) {}
> -static inline int dwc2_hcd_init(struct dwc2_hsotg *hsotg, int irq)
> +static inline int dwc2_hcd_init(struct dwc2_hsotg *hsotg, int irq,
> + struct resource *res)
>  { return 0; }
>  static inline int dwc2_backup_host_registers(struct dwc2_hsotg 
> *hsotg)
>  { return 0; }
> diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
> index 911c3b36..2cfbd10e 100644
> --- a/drivers/usb/dwc2/hcd.c
> +++ b/drivers/usb/dwc2/hcd.c
> @@ -4964,7 +4964,7 @@ static void dwc2_hcd_release(struct dwc2_hsotg 
> *hsotg)
>   * USB bus with the core and calls the hc_driver->start() function. 
> It returns
>   * a negative error on failure.
>   */
> -int dwc2_hcd_init(struct dwc2_hsotg *hsotg, int irq)
> +int dwc2_hcd_init(struct dwc2_hsotg *hsotg, int irq, struct resource 
> *res)
>  {
>   struct usb_hcd *hcd;
>   struct dwc2_host_chan *channel;
> @@ -5021,6 +5021,9 @@ int dwc2_hcd_init(struct dwc2_hsotg *hsotg, int 
> irq)
>
>   hcd->has_tt = 1;
>
> + hcd->rsrc_start = res->start;
> + hcd->rsrc_len = resource_size(res);
> +
>   ((struct wrapper_priv_data *) >hcd_priv)->hsotg = hsotg;
>   hsotg->priv = hcd;
>
> diff --git a/drivers/usb/dwc2/hcd.h b/drivers/usb/dwc2/hcd.h
> index 1ed5fa2b..2305b5fb 100644
> --- a/drivers/usb/dwc2/hcd.h
> +++ b/drivers/usb/dwc2/hcd.h
> @@ -521,7 +521,8 @@ static inline u8 dwc2_hcd_is_pipe_out(struct 
> dwc2_hcd_pipe_info *pipe)
>   return !dwc2_hcd_is_pipe_in(pipe);
>  }
>
> -extern int dwc2_hcd_init(struct dwc2_hsotg *hsotg, int irq);
> +extern int dwc2_hcd_init(struct dwc2_hsotg *hsotg, int irq,
> +  struct resource *res);
>  extern void dwc2_hcd_remove(struct dwc2_hsotg *hsotg);
>
>  /* Transaction Execution Functions */
> diff --git a/drivers/usb/dwc2/platform.c b/drivers/usb/dwc2/platform.c
> index 4fc8c603..5ddc8860 100644
> --- a/drivers/usb/dwc2/platform.c
> +++ b/drivers/usb/dwc2/platform.c
> @@ -445,7 +445,7 @@ static int dwc2_driver_probe(struct 
> platform_device *dev)
>   }
>
>   if (hsotg->dr_mode != USB_DR_MODE_PERIPHERAL) {
> - retval = dwc2_hcd_init(hsotg, hsotg->irq);
> + retval = dwc2_hcd_init(hsotg, hsotg->irq, res);

 This is a good idea, but there's more work that can come out of this, 
 if
 you're interested:

 i) devm_ioremap_resource() could be called by the generic layer
 ii) devm_request_irq() could be move to the generic layer
 iii) dwc2_hcd_init() could also be called generically as long as 
 dr_mode
  is set properly.
 iv) dwc2_debugfs_init() could be called generically as well

 IOW, dwc2_driver_probe() could be as minimal as:

 static int dwc2_driver_probe(struct platform_device *dev)
 {
struct dwc2_hsotg *hsotg;
struct resource *res;
int retval;

hsotg = devm_kzalloc(>dev, sizeof(*hsotg), GFP_KERNEL);
if (!hsotg)
return -ENOMEM;

hsotg->dev = >dev;

if (!dev->dev.dma_mask)
dev->dev.dma_mask = >dev.coherent_dma_mask;

retval = dma_set_coherent_mask(>dev, DMA_BIT_MASK(32));
if (retval)
return retval;

hsotg->res = platform_get_resource(dev, IORESOURCE_MEM, 0);
hsotg->irq = platform_get_irq(dev, 0);

retval = dwc2_get_dr_mode(hsotg);
if (retval)
return retval;

retval = dwc2_get_hwparams(hsotg);
if (retval)
return retval;

platform_set_drvdata(dev, hsotg);

retval = dwc2_core_init(hsotg);
if (retval)

Re: [PATCH 2/2] USB: serial: drop unused ASYNC flags

[Greg KH]

On Wed, Jan 25, 2017 at 06:22:54PM +0100, Johan Hovold wrote:
> Do not report ASYNC_SKIP_TEST or ASYNC_AUTO_IRQ as being set in
> TIOCGSERIAL handlers as these flags are not supported and do not really
> make any sense for USB serial devices in the first place.
> 
> Signed-off-by: Johan Hovold 
> ---
>  drivers/usb/serial/io_edgeport.c | 1 -
>  drivers/usb/serial/io_ti.c   | 1 -
>  drivers/usb/serial/mos7720.c | 1 -
>  drivers/usb/serial/mos7840.c | 1 -
>  drivers/usb/serial/opticon.c | 1 -
>  drivers/usb/serial/quatech2.c| 1 -
>  drivers/usb/serial/ssu100.c  | 1 -
>  drivers/usb/serial/whiteheat.c   | 1 -
>  8 files changed, 8 deletions(-)
> 
> diff --git a/drivers/usb/serial/io_edgeport.c 
> b/drivers/usb/serial/io_edgeport.c
> index 8ab5f5b49ef3..92abf92e5669 100644
> --- a/drivers/usb/serial/io_edgeport.c
> +++ b/drivers/usb/serial/io_edgeport.c
> @@ -1572,7 +1572,6 @@ static int get_serial_info(struct edgeport_port 
> *edge_port,
>   tmp.line= edge_port->port->minor;
>   tmp.port= edge_port->port->port_number;
>   tmp.irq = 0;
> - tmp.flags   = ASYNC_SKIP_TEST | ASYNC_AUTO_IRQ;
>   tmp.xmit_fifo_size  = edge_port->maxTxCredits;
>   tmp.baud_base   = 9600;
>   tmp.close_delay = 5*HZ;
> diff --git a/drivers/usb/serial/io_ti.c b/drivers/usb/serial/io_ti.c
> index 9a0db2965fbb..ceaeebaa6f90 100644
> --- a/drivers/usb/serial/io_ti.c
> +++ b/drivers/usb/serial/io_ti.c
> @@ -2468,7 +2468,6 @@ static int get_serial_info(struct edgeport_port 
> *edge_port,
>   tmp.line= edge_port->port->minor;
>   tmp.port= edge_port->port->port_number;
>   tmp.irq = 0;
> - tmp.flags   = ASYNC_SKIP_TEST | ASYNC_AUTO_IRQ;
>   tmp.xmit_fifo_size  = edge_port->port->bulk_out_size;
>   tmp.baud_base   = 9600;
>   tmp.close_delay = 5*HZ;
> diff --git a/drivers/usb/serial/mos7720.c b/drivers/usb/serial/mos7720.c
> index acf431e02699..f075121c6e32 100644
> --- a/drivers/usb/serial/mos7720.c
> +++ b/drivers/usb/serial/mos7720.c
> @@ -1851,7 +1851,6 @@ static int get_serial_info(struct moschip_port 
> *mos7720_port,
>   tmp.line= mos7720_port->port->minor;
>   tmp.port= mos7720_port->port->port_number;
>   tmp.irq = 0;
> - tmp.flags   = ASYNC_SKIP_TEST | ASYNC_AUTO_IRQ;
>   tmp.xmit_fifo_size  = NUM_URBS * URB_TRANSFER_BUFFER_SIZE;
>   tmp.baud_base   = 9600;
>   tmp.close_delay = 5*HZ;
> diff --git a/drivers/usb/serial/mos7840.c b/drivers/usb/serial/mos7840.c
> index 155006acf918..d1b92f582478 100644
> --- a/drivers/usb/serial/mos7840.c
> +++ b/drivers/usb/serial/mos7840.c
> @@ -1963,7 +1963,6 @@ static int mos7840_get_serial_info(struct moschip_port 
> *mos7840_port,
>   tmp.line = mos7840_port->port->minor;
>   tmp.port = mos7840_port->port->port_number;
>   tmp.irq = 0;
> - tmp.flags = ASYNC_SKIP_TEST | ASYNC_AUTO_IRQ;
>   tmp.xmit_fifo_size = NUM_URBS * URB_TRANSFER_BUFFER_SIZE;
>   tmp.baud_base = 9600;
>   tmp.close_delay = 5 * HZ;
> diff --git a/drivers/usb/serial/opticon.c b/drivers/usb/serial/opticon.c
> index b3c64f557d60..3937b9c3cc69 100644
> --- a/drivers/usb/serial/opticon.c
> +++ b/drivers/usb/serial/opticon.c
> @@ -343,7 +343,6 @@ static int get_serial_info(struct usb_serial_port *port,
>   tmp.line= port->minor;
>   tmp.port= 0;
>   tmp.irq = 0;
> - tmp.flags   = ASYNC_SKIP_TEST | ASYNC_AUTO_IRQ;
>   tmp.xmit_fifo_size  = 1024;
>   tmp.baud_base   = 9600;
>   tmp.close_delay = 5*HZ;
> diff --git a/drivers/usb/serial/quatech2.c b/drivers/usb/serial/quatech2.c
> index cf29128327d3..fdbb904d153f 100644
> --- a/drivers/usb/serial/quatech2.c
> +++ b/drivers/usb/serial/quatech2.c
> @@ -465,7 +465,6 @@ static int get_serial_info(struct usb_serial_port *port,
>   tmp.line= port->minor;
>   tmp.port= 0;
>   tmp.irq = 0;
> - tmp.flags   = ASYNC_SKIP_TEST | ASYNC_AUTO_IRQ;
>   tmp.xmit_fifo_size  = port->bulk_out_size;
>   tmp.baud_base   = 9600;
>   tmp.close_delay = 5*HZ;
> diff --git a/drivers/usb/serial/ssu100.c b/drivers/usb/serial/ssu100.c
> index 55814538ff1f..5aa7bbbeba3d 100644
> --- a/drivers/usb/serial/ssu100.c
> +++ b/drivers/usb/serial/ssu100.c
> @@ -339,7 +339,6 @@ static int get_serial_info(struct usb_serial_port *port,
>   tmp.line= port->minor;
>   tmp.port= 0;
>   tmp.irq = 0;
> - tmp.flags   = ASYNC_SKIP_TEST | ASYNC_AUTO_IRQ;
>   tmp.xmit_fifo_size  = port->bulk_out_size;
>   tmp.baud_base   = 9600;
>   

Re: [PATCH 1/2] USB: serial: ftdi_sio: clean up ioctl handler

[Greg KH]

On Wed, Jan 25, 2017 at 06:22:53PM +0100, Johan Hovold wrote:
> Clean up the ioctl handler and make sure to pass an unsigned-int rather
> than serial_struct pointer to the TIOCSERGETLSR helper as this it what
> the user argument really is.
> 
> Signed-off-by: Johan Hovold 
> ---
>  drivers/usb/serial/ftdi_sio.c | 19 +++
>  1 file changed, 7 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
> index 4bd556d9307d..e82dbb3d0883 100644
> --- a/drivers/usb/serial/ftdi_sio.c
> +++ b/drivers/usb/serial/ftdi_sio.c
> @@ -1534,7 +1534,7 @@ static int set_serial_info(struct tty_struct *tty,
>  }
>  
>  static int get_lsr_info(struct usb_serial_port *port,
> - struct serial_struct __user *retinfo)
> + unsigned int __user *retinfo)
>  {
>   struct ftdi_private *priv = usb_get_serial_port_data(port);
>   unsigned int result = 0;
> @@ -2485,20 +2485,15 @@ static int ftdi_ioctl(struct tty_struct *tty,
>   unsigned int cmd, unsigned long arg)
>  {
>   struct usb_serial_port *port = tty->driver_data;
> + void __user *argp = (void __user *)arg;
>  
> - /* Based on code from acm.c and others */
>   switch (cmd) {
> -
> - case TIOCGSERIAL: /* gets serial port data */
> - return get_serial_info(port,
> - (struct serial_struct __user *) arg);
> -
> - case TIOCSSERIAL: /* sets serial port data */
> - return set_serial_info(tty, port,
> - (struct serial_struct __user *) arg);
> + case TIOCGSERIAL:
> + return get_serial_info(port, argp);
> + case TIOCSSERIAL:
> + return set_serial_info(tty, port, argp);
>   case TIOCSERGETLSR:
> - return get_lsr_info(port, (struct serial_struct __user *)arg);
> - break;
> + return get_lsr_info(port, argp);
>   default:
>   break;
>   }

Ah, nice catch!

Reviewed-by: Greg Kroah-Hartman 
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] usb: gadget: udc: fsl: Add missing complete function.

[Magnus Lilja]

Commit 304f7e5e1d08 ("usb: gadget: Refactor request completion")
removed check if req->req.complete is non-NULL, resulting in a NULL
pointer derefence and a kernel panic.
This patch adds an empty complete function instead of re-introducing
the req->req.complete check.

Fixes: 304f7e5e1d08 ("usb: gadget: Refactor request completion")

Signed-off-by: Magnus Lilja 
Cc:  # 3.18+
---
This patch is the result of the discussion in
https://marc.info/?t=14846881971=1=2
---
 drivers/usb/gadget/udc/fsl_udc_core.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/gadget/udc/fsl_udc_core.c 
b/drivers/usb/gadget/udc/fsl_udc_core.c
index 71094e4..55c7553 100644
--- a/drivers/usb/gadget/udc/fsl_udc_core.c
+++ b/drivers/usb/gadget/udc/fsl_udc_core.c
@@ -1248,6 +1248,12 @@ static const struct usb_gadget_ops fsl_gadget_ops = {
.udc_stop = fsl_udc_stop,
 };
 
+/*
+ * Empty complete function used by this driver to fill in the req->complete
+ * field when creating a request since the complete field is mandatory.
+ */
+static void fsl_noop_complete(struct usb_ep *ep, struct usb_request *req) { }
+
 /* Set protocol stall on ep0, protocol stall will automatically be cleared
on new transaction */
 static void ep0stall(struct fsl_udc *udc)
@@ -1282,7 +1288,7 @@ static int ep0_prime_status(struct fsl_udc *udc, int 
direction)
req->req.length = 0;
req->req.status = -EINPROGRESS;
req->req.actual = 0;
-   req->req.complete = NULL;
+   req->req.complete = fsl_noop_complete;
req->dtd_count = 0;
 
ret = usb_gadget_map_request(>udc->gadget, >req, ep_is_in(ep));
@@ -1365,7 +1371,7 @@ static void ch9getstatus(struct fsl_udc *udc, u8 
request_type, u16 value,
req->req.length = 2;
req->req.status = -EINPROGRESS;
req->req.actual = 0;
-   req->req.complete = NULL;
+   req->req.complete = fsl_noop_complete;
req->dtd_count = 0;
 
ret = usb_gadget_map_request(>udc->gadget, >req, ep_is_in(ep));
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V2 1/2] dt-bindings: leds: document new led-triggers property

[Jacek Anaszewski]

On 01/25/2017 10:03 AM, Rafał Miłecki wrote:
> On 21 January 2017 at 22:42, Jacek Anaszewski
>  wrote:
>> On 01/21/2017 05:24 PM, Rafał Miłecki wrote:
>>> On 20 January 2017 at 23:35, Jacek Anaszewski
>>>  wrote:
 On 01/20/2017 10:56 PM, Rafał Miłecki wrote:
> From: Rafał Miłecki 
>
> Some LEDs can be related to particular devices described in DT. This
> property allows specifying such relations. E.g. USB LED should usually
> be used to indicate some USB port(s) state.
>
> Signed-off-by: Rafał Miłecki 
> ---
> V2: Replace "usb-ports" with "led-triggers" property which is more 
> generic and
> allows specifying other devices as well.
>
> When bindings patch is related to some followup implementation, they 
> usually go
> through the same tree.
>
> Greg: this patch is based on top of e64b8cc72bf9 ("DT: leds: Improve 
> examples by
> adding some context") from kernel/git/j.anaszewski/linux-leds.git . Is 
> there any
> way to solve this dependency issue? Or should this patch wait until 3.11 
> is
> released?
> ---
>  Documentation/devicetree/bindings/leds/common.txt | 16 
>  1 file changed, 16 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/leds/common.txt 
> b/Documentation/devicetree/bindings/leds/common.txt
> index 24b656014089..17632a041196 100644
> --- a/Documentation/devicetree/bindings/leds/common.txt
> +++ b/Documentation/devicetree/bindings/leds/common.txt
> @@ -49,6 +49,17 @@ Optional properties for child nodes:
>  - panic-indicator : This property specifies that the LED should be used,
>   if at all possible, as a panic indicator.
>
> +- led-triggers : List of devices that should trigger this LED activity. 
> Some
> +  LEDs can be related to a specific device and should somehow
> +  indicate its state. E.g. USB 2.0 LED may react to 
> device(s) in
> +  a USB 2.0 port(s). Another common example is switch or 
> router
> +  with multiple Ethernet ports each of them having its own 
> LED
> +  assigned (assuminled-trigger-usbportg they are not 
> hardwired).
> +  In such cases this property should contain phandle(s) of
> +  related device(s). In many cases LED can be related to more
> +  than one device (e.g. one USB LED vs. multiple USB ports) 
> so a
> +  list of entries can be specified.
> +

 This implies that it is possible to define multiple triggers for
 a LED class device but it is not supported by LED Trigger core.
 There is linux,default-trigger property which allows to define one
 trigger that will be initially assigned.
>>
>>> With proposed "led-triggers" property one could assign different
>>> trigger *sources* to a LED. You could e.g. assign 2 USB ports, network
>>> device & CPU to a single LED. For reason explained above Linux
>>> couldn't support all of them at once.
>>>
>>>
 I am aware that this is renamed usb-ports property from v1,
 that attempts to address Rob's comment, but we can't do that this way.
 Maybe usb-ports property could be documented in led-trigger-usbport's
 specific bindings and a reference to it could be added next to the
 related entry on the list of the available LED triggers (which is
 actually missing) in Documentation/devicetree/bindings/leds/common.txt.
>>>
>>> I'm wondering if we need to care about this Linux limitation and if it
>>> should stop us from adding this flexible DT property. Maybe we could
>>> live with Linux having limitation of supporting one trigger type at a
>>> time?
>>
>> That's what I meant. Generally I have objections to the generic
>> property for defining list of allowed triggers. That's why I proposed
>> to stay by usb-ports property that would be specific to only one
>> trigger: led-trigger-usbport.
>>
>> led-trigger-usbport in fact is an entirely new type of LED trigger.
>> LED triggers is a kernel based source of events. All existing triggers
>> react only to a single, well defined source of events, whereas
>> led-trigger-usbport allows to define the scope of events (usb ports)
>> to notify about. Activity on each port is treated similarly and the LED
>> class device that listens to the trigger notifications doesn't know
>> which exact port triggered the notification.
>>
>> From this POV led-trigger-usbport is kind of facade, which allows
>> for it to fit well into the LED Trigger design and API, and usb ports
>> are not identical with LED triggers, but sit rather one level below.
>> It is led-trigger-usbport which is visible to the LED subsystem, and
>> not every single usb port.
> 
> I of course agree with your nice usbport 

Re: [PATCH V2 1/2] dt-bindings: leds: document new led-triggers property

[Jacek Anaszewski]

On 01/25/2017 10:08 AM, Rafał Miłecki wrote:
> On 01/23/2017 05:45 PM, Rob Herring wrote:
>> On Fri, Jan 20, 2017 at 11:35:20PM +0100, Jacek Anaszewski wrote:
>>> Hi Rafał,
>>>
>>> On 01/20/2017 10:56 PM, Rafał Miłecki wrote:
 From: Rafał Miłecki 

 Some LEDs can be related to particular devices described in DT. This
 property allows specifying such relations. E.g. USB LED should usually
 be used to indicate some USB port(s) state.

 Signed-off-by: Rafał Miłecki 
 ---
 V2: Replace "usb-ports" with "led-triggers" property which is more
 generic and
 allows specifying other devices as well.

 When bindings patch is related to some followup implementation, they
 usually go
 through the same tree.

 Greg: this patch is based on top of e64b8cc72bf9 ("DT: leds: Improve
 examples by
 adding some context") from kernel/git/j.anaszewski/linux-leds.git .
 Is there any
 way to solve this dependency issue? Or should this patch wait until
 3.11 is
 released?
 ---
  Documentation/devicetree/bindings/leds/common.txt | 16
 
  1 file changed, 16 insertions(+)

 diff --git a/Documentation/devicetree/bindings/leds/common.txt
 b/Documentation/devicetree/bindings/leds/common.txt
 index 24b656014089..17632a041196 100644
 --- a/Documentation/devicetree/bindings/leds/common.txt
 +++ b/Documentation/devicetree/bindings/leds/common.txt
 @@ -49,6 +49,17 @@ Optional properties for child nodes:
  - panic-indicator : This property specifies that the LED should be
 used,
  if at all possible, as a panic indicator.

 +- led-triggers : List of devices that should trigger this LED
 activity. Some
 + LEDs can be related to a specific device and should somehow
 + indicate its state. E.g. USB 2.0 LED may react to
 device(s) in
 + a USB 2.0 port(s). Another common example is switch or router
 + with multiple Ethernet ports each of them having its own LED
 + assigned (assuminled-trigger-usbportg they are not
 hardwired).
 + In such cases this property should contain phandle(s) of
 + related device(s). In many cases LED can be related to more
 + than one device (e.g. one USB LED vs. multiple USB ports)
 so a
 + list of entries can be specified.
 +
>>>
>>> This implies that it is possible to define multiple triggers for
>>> a LED class device but it is not supported by LED Trigger core.
>>
>> Not really relevant for designing (and future proofing) a binding.
> 
> This is what I really like in this "led-triggers" property: it's future
> proof. I
> will be able to reuse it in other trigger drivers and I won't be trying
> to sneak
> properties like
> * usb-port-triggers
> * net-interface-triggers
> * cpu-triggers
> etc.

Very well, but led-triggers in this approach are not LED trigger drivers
but sources of events. Therefore I proposed trigger-sources.

> Saying that thanks Rob for rejecting my initial "usb-ports" property try :P
> .
> 

-- 
Best regards,
Jacek Anaszewski
--
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 1/2] dt-bindings: leds: document new led-triggers property

[Jacek Anaszewski]

On 01/25/2017 10:18 AM, Rafał Miłecki wrote:
> On 01/23/2017 09:51 PM, Jacek Anaszewski wrote:
>> On 01/23/2017 05:45 PM, Rob Herring wrote:
>>> On Fri, Jan 20, 2017 at 11:35:20PM +0100, Jacek Anaszewski wrote:
 Hi Rafał,

 On 01/20/2017 10:56 PM, Rafał Miłecki wrote:
> From: Rafał Miłecki 
>
> Some LEDs can be related to particular devices described in DT. This
> property allows specifying such relations. E.g. USB LED should usually
> be used to indicate some USB port(s) state.
>
> Signed-off-by: Rafał Miłecki 
> ---
> V2: Replace "usb-ports" with "led-triggers" property which is more
> generic and
> allows specifying other devices as well.
>
> When bindings patch is related to some followup implementation,
> they usually go
> through the same tree.
>
> Greg: this patch is based on top of e64b8cc72bf9 ("DT: leds:
> Improve examples by
> adding some context") from kernel/git/j.anaszewski/linux-leds.git .
> Is there any
> way to solve this dependency issue? Or should this patch wait until
> 3.11 is
> released?
> ---
>  Documentation/devicetree/bindings/leds/common.txt | 16
> 
>  1 file changed, 16 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/leds/common.txt
> b/Documentation/devicetree/bindings/leds/common.txt
> index 24b656014089..17632a041196 100644
> --- a/Documentation/devicetree/bindings/leds/common.txt
> +++ b/Documentation/devicetree/bindings/leds/common.txt
> @@ -49,6 +49,17 @@ Optional properties for child nodes:
>  - panic-indicator : This property specifies that the LED should be
> used,
>  if at all possible, as a panic indicator.
>
> +- led-triggers : List of devices that should trigger this LED
> activity. Some
> + LEDs can be related to a specific device and should somehow
> + indicate its state. E.g. USB 2.0 LED may react to
> device(s) in
> + a USB 2.0 port(s). Another common example is switch or
> router
> + with multiple Ethernet ports each of them having its own LED
> + assigned (assuminled-trigger-usbportg they are not
> hardwired).
> + In such cases this property should contain phandle(s) of
> + related device(s). In many cases LED can be related to more
> + than one device (e.g. one USB LED vs. multiple USB ports)
> so a
> + list of entries can be specified.
> +

 This implies that it is possible to define multiple triggers for
 a LED class device but it is not supported by LED Trigger core.
>>>
>>> Not really relevant for designing (and future proofing) a binding.
>>
>> But relevant for LED Trigger ABI, which would have to be changed to
>> support the semantics in this form. I think that changing the property
>> name to linux,trigger-sources would make its purpose more clear.
>>
>> Note that we have to also associate somehow this property with the
>> triggers that will make use of the information it provides. I can
>> imagine also other compound triggers that could benefit on it.
>>
>> What follows, the trigger sources would trigger LED activity only
>> if the LED class device was assigned appropriate trigger. We need to
>> define somewhere which triggers support this property.
>>
>> Trigger specific bindings?
> 
> Maybe this is something I'm missing. Why adding this "led-triggers"
> property
> would mean/require ABI breakage?

As I explained in the other message, LED Triggers are drivers registered
in the LED Trigger core. LED subsystem allows for only one active
trigger at a time (triggers sysfs file reports selected trigger by
wrapping its name with square brackets on the space separated list
of all available LED Triggers).

The problem is in the property name, which can easily lead to wrong
conclusions for the reader not familiar with the LED Trigger core
design.

> AFAIU adding support for "led-triggers" to the "usbport" trigger driver
> (see
> patch 2/2) didn't break anything, I hope?
> 

No, it didn't, but ambiguity in the documentation can lead to
misunderstanding and hinder learning LED subsystem API.

-- 
Best regards,
Jacek Anaszewski
--
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: NAPI on USB network drivers

[Alexander Duyck]

On Wed, Jan 25, 2017 at 5:33 AM, Oliver Hartkopp  wrote:
> On 01/25/2017 10:39 AM, Hayes Wang wrote:
>>
>> Oliver Neukum [mailto:oneu...@suse.com]
>>>
>>> Sent: Wednesday, January 25, 2017 5:35 PM
>>
>> [...]
>>>
>>> looking at r8152 I noticed that it uses NAPI. I never considered
>>> this for the generic USB networking code as you cannot disable
>>> interrupts for USB. Is it still worth it? What are the benefits?
>>
>>
>> You could use napi_gro_receive() and it influences the performance.
>
>
> Another positive effect with NAPI is that you won't face out-of-order
> ethernet frames as you get with non-NAPI drivers, e.g. ax88179_178a
>
> http://marc.info/?l=linux-can=148049063812807=2
>
> We have the issue with CAN drivers where all USB drivers and >90% of the I/O
> mapped drivers do not use NAPI.
>
> I wonder whether it makes sense to add NAPI to a driver which only has ONE
> RX buffer ... but when searching for a solution for o-o-o frames I was
> always pointed to NAPI.
>
> Regards,
> Oliver
>

You could probably get around the o-o-o problem by enabling RPS for
the interface.  I have found that it works for me to do that in order
to resolve o-o-o frames generated by VMs on virtual interfaces that
can't use NAPI.

- Alex
--
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 v6] USB: serial: Add uPD78F0730 USB to Serial Adaptor Driver

[Maksim Salau]

The adaptor can be found on development boards for 78k, RL78 and V850
microcontrollers produced by Renesas Electronics Corporation.

This is not a full-featured USB to serial converter, however it allows
basic communication and simple control which is enough for programming of
on-board flash and debugging through a debug monitor.

uPD78F0730 is a USB-enabled microcontroller with USB-to-UART conversion
implemented in firmware.

This chip is also present in some debugging adaptors which use it for
USB-to-SPI conversion as well. The present driver doesn't cover SPI,
only USB-to-UART conversion is supported.

Signed-off-by: Maksim Salau 
---
Changes in v6:
  Changed commit message prefix to 'USB: serial:'
  Removed '__func__ - ' prefix from all WARN and ERR messages
  Removed the attach callback (duplicates functionality of generic driver)
  Refined handling of failures in upd78f0730_send_ctl
  Changed type of the 'data' argument of upd78f0730_send_ctl
'void *' -> 'const void *'
  Added check for negative values in the 'size' argument of
the upd78f0730_send_ctl function.

Changes in v5:
  Fixed a typo in assignment of opcode of the SET_DTR_RTS request

Changes in v4:
  Added prefix to declarations of command structures
  Added '__func__ - ' prefix to all messages
  Changed order of declaraion of local variables (simple types last)
  Changed word 'reset' to 'clear' in messages about
modem control signals operations
  Added support of BOTHER and B0 baudrates
  Removed support of hardware flow control
  Fixed license in MODULE_LICENSE to be "GPL v2"
  Added the 'attach' callback to check for bulk endpoints

 drivers/usb/serial/Kconfig  |   9 +
 drivers/usb/serial/Makefile |   1 +
 drivers/usb/serial/upd78f0730.c | 440 
 3 files changed, 450 insertions(+)
 create mode 100644 drivers/usb/serial/upd78f0730.c

diff --git a/drivers/usb/serial/Kconfig b/drivers/usb/serial/Kconfig
index d9bc8da..a8d5f2e 100644
--- a/drivers/usb/serial/Kconfig
+++ b/drivers/usb/serial/Kconfig
@@ -713,6 +713,15 @@ config USB_SERIAL_QT2
  To compile this driver as a module, choose M here: the
  module will be called quatech-serial.
 
+config USB_SERIAL_UPD78F0730
+   tristate "USB Renesas uPD78F0730 Single Port Serial Driver"
+   help
+ Say Y here if you want to use the Renesas uPD78F0730
+ serial driver.
+
+ To compile this driver as a module, choose M here: the
+ module will be called upd78f0730.
+
 config USB_SERIAL_DEBUG
tristate "USB Debugging Device"
help
diff --git a/drivers/usb/serial/Makefile b/drivers/usb/serial/Makefile
index 9e43b7b..5a21a82 100644
--- a/drivers/usb/serial/Makefile
+++ b/drivers/usb/serial/Makefile
@@ -56,6 +56,7 @@ obj-$(CONFIG_USB_SERIAL_SSU100)   += 
ssu100.o
 obj-$(CONFIG_USB_SERIAL_SYMBOL)+= symbolserial.o
 obj-$(CONFIG_USB_SERIAL_WWAN)  += usb_wwan.o
 obj-$(CONFIG_USB_SERIAL_TI)+= ti_usb_3410_5052.o
+obj-$(CONFIG_USB_SERIAL_UPD78F0730)+= upd78f0730.o
 obj-$(CONFIG_USB_SERIAL_VISOR) += visor.o
 obj-$(CONFIG_USB_SERIAL_WISHBONE)  += wishbone-serial.o
 obj-$(CONFIG_USB_SERIAL_WHITEHEAT) += whiteheat.o
diff --git a/drivers/usb/serial/upd78f0730.c b/drivers/usb/serial/upd78f0730.c
new file mode 100644
index 000..55b9a18
--- /dev/null
+++ b/drivers/usb/serial/upd78f0730.c
@@ -0,0 +1,440 @@
+/*
+ * Renesas Electronics uPD78F0730 USB to serial converter driver
+ *
+ * Copyright (C) 2014,2016 Maksim Salau 
+ *
+ * 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.
+ *
+ * Protocol of the adaptor is described in the application note U19660EJ1V0AN00
+ * μPD78F0730 8-bit Single-Chip Microcontroller
+ * USB-to-Serial Conversion Software
+ * 
+ *
+ * The adaptor functionality is limited to the following:
+ * - data bits: 7 or 8
+ * - stop bits: 1 or 2
+ * - parity: even, odd or none
+ * - flow control: none
+ * - baud rates: 0, 2400, 4800, 9600, 19200, 38400, 57600, 115200
+ * - signals: DTR, RTS and BREAK
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DRIVER_DESC "Renesas uPD78F0730 USB to serial converter driver"
+
+#define DRIVER_AUTHOR "Maksim Salau "
+
+static const struct usb_device_id id_table[] = {
+   { USB_DEVICE(0x045B, 0x0212) }, /* YRPBRL78G13, YRPBRL78G14 */
+   { USB_DEVICE(0x0409, 0x0063) }, /* V850ESJX3-STICK */
+   {}
+};
+
+MODULE_DEVICE_TABLE(usb, id_table);
+
+/*
+ * Each adaptor is associated with a private structure, that holds the current
+ * state of control signals (DTR, RTS and BREAK).
+ */
+struct 

Re: [PATCH] usb: dwc2: fix "iomem 0x00000000" message by setting iomem parameters in usb_hcd

[Heiner Kallweit]

Am 24.01.2017 um 09:46 schrieb Felipe Balbi:
> 
> Hi,
> 
> John Youn  writes:
>>> John Youn  writes:
 @@ -1229,7 +1229,8 @@ static inline void dwc2_hcd_connect(struct 
 dwc2_hsotg *hsotg) {}
  static inline void dwc2_hcd_disconnect(struct dwc2_hsotg *hsotg, bool 
 force) {}
  static inline void dwc2_hcd_start(struct dwc2_hsotg *hsotg) {}
  static inline void dwc2_hcd_remove(struct dwc2_hsotg *hsotg) {}
 -static inline int dwc2_hcd_init(struct dwc2_hsotg *hsotg, int irq)
 +static inline int dwc2_hcd_init(struct dwc2_hsotg *hsotg, int irq,
 +  struct resource *res)
  { return 0; }
  static inline int dwc2_backup_host_registers(struct dwc2_hsotg *hsotg)
  { return 0; }
 diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
 index 911c3b36..2cfbd10e 100644
 --- a/drivers/usb/dwc2/hcd.c
 +++ b/drivers/usb/dwc2/hcd.c
 @@ -4964,7 +4964,7 @@ static void dwc2_hcd_release(struct dwc2_hsotg 
 *hsotg)
   * USB bus with the core and calls the hc_driver->start() function. 
 It returns
   * a negative error on failure.
   */
 -int dwc2_hcd_init(struct dwc2_hsotg *hsotg, int irq)
 +int dwc2_hcd_init(struct dwc2_hsotg *hsotg, int irq, struct resource 
 *res)
  {
struct usb_hcd *hcd;
struct dwc2_host_chan *channel;
 @@ -5021,6 +5021,9 @@ int dwc2_hcd_init(struct dwc2_hsotg *hsotg, int 
 irq)

hcd->has_tt = 1;

 +  hcd->rsrc_start = res->start;
 +  hcd->rsrc_len = resource_size(res);
 +
((struct wrapper_priv_data *) >hcd_priv)->hsotg = hsotg;
hsotg->priv = hcd;

 diff --git a/drivers/usb/dwc2/hcd.h b/drivers/usb/dwc2/hcd.h
 index 1ed5fa2b..2305b5fb 100644
 --- a/drivers/usb/dwc2/hcd.h
 +++ b/drivers/usb/dwc2/hcd.h
 @@ -521,7 +521,8 @@ static inline u8 dwc2_hcd_is_pipe_out(struct 
 dwc2_hcd_pipe_info *pipe)
return !dwc2_hcd_is_pipe_in(pipe);
  }

 -extern int dwc2_hcd_init(struct dwc2_hsotg *hsotg, int irq);
 +extern int dwc2_hcd_init(struct dwc2_hsotg *hsotg, int irq,
 +   struct resource *res);
  extern void dwc2_hcd_remove(struct dwc2_hsotg *hsotg);

  /* Transaction Execution Functions */
 diff --git a/drivers/usb/dwc2/platform.c b/drivers/usb/dwc2/platform.c
 index 4fc8c603..5ddc8860 100644
 --- a/drivers/usb/dwc2/platform.c
 +++ b/drivers/usb/dwc2/platform.c
 @@ -445,7 +445,7 @@ static int dwc2_driver_probe(struct 
 platform_device *dev)
}

if (hsotg->dr_mode != USB_DR_MODE_PERIPHERAL) {
 -  retval = dwc2_hcd_init(hsotg, hsotg->irq);
 +  retval = dwc2_hcd_init(hsotg, hsotg->irq, res);
>>>
>>> This is a good idea, but there's more work that can come out of this, if
>>> you're interested:
>>>
>>> i) devm_ioremap_resource() could be called by the generic layer
>>> ii) devm_request_irq() could be move to the generic layer
>>> iii) dwc2_hcd_init() could also be called generically as long as dr_mode
>>>  is set properly.
>>> iv) dwc2_debugfs_init() could be called generically as well
>>>
>>> IOW, dwc2_driver_probe() could be as minimal as:
>>>
>>> static int dwc2_driver_probe(struct platform_device *dev)
>>> {
>>> struct dwc2_hsotg *hsotg;
>>> struct resource *res;
>>> int retval;
>>>
>>> hsotg = devm_kzalloc(>dev, sizeof(*hsotg), GFP_KERNEL);
>>> if (!hsotg)
>>> return -ENOMEM;
>>>
>>> hsotg->dev = >dev;
>>>
>>> if (!dev->dev.dma_mask)
>>> dev->dev.dma_mask = >dev.coherent_dma_mask;
>>>
>>> retval = dma_set_coherent_mask(>dev, DMA_BIT_MASK(32));
>>> if (retval)
>>> return retval;
>>>
>>> hsotg->res = platform_get_resource(dev, IORESOURCE_MEM, 0);
>>> hsotg->irq = platform_get_irq(dev, 0);
>>>
>>> retval = dwc2_get_dr_mode(hsotg);
>>> if (retval)
>>> return retval;
>>>
>>> retval = dwc2_get_hwparams(hsotg);
>>> if (retval)
>>> return retval;
>>>
>>> platform_set_drvdata(dev, hsotg);
>>>
>>> retval = dwc2_core_init(hsotg);
>>> if (retval)
>>> return retval;
>>>
>>> return 0;
>>> }
>>>
>>> dwc2_core_init() needs to implemented, of course, but it could hide all
>>> 

[RESEND][PATCH] media/usb: Fix pctv452e

[Wolfgang Rohdewald]

I sent this 9 days ago but got no answer.

Is anything wrong with this patch?

Commit 73d5c5c864f40 made sure that media/usb drivers don't do DMA on stack.

That made pctv452e oops while initialising:

[...]
BUG: unable to handle kernel NULL pointer dereference at   (null)
[...]
[9.051527]  [] mutex_lock+0x17/0x30
[9.051531]  [] pctv452e_power_ctrl+0x85/0x190 
[dvb_usb_pctv452e]
[9.051536]  [] dvb_usb_device_power_ctrl+0x3f/0x50 
[dvb_usb]
[9.051541]  [] dvb_usb_device_init+0x225/0x620 
[dvb_usb]
[9.051546]  [] pctv452e_usb_probe+0x51/0x60 
[dvb_usb_pctv452e]
[9.051550]  [] usb_probe_interface+0x159/0x2d0
[...]

Commit 7724325a1 fixed most drivers but not all - I guess that only
those using data_mutex for locking got fixes. But some gave the
mutex a different name, in pctv452e it was ca_mutex.

This patches only pctv452e but grep mutex_lock in usb/dvb-usb makes me
believe that more drivers need to be fixed.

Fixes: 73d5c5c8 ("[media] pctv452e: don't do DMA on stack")
WolfgangSigned-off-by:  Rohdewald 
CC: Mauro Carvalho Chehab 
---
 drivers/media/usb/dvb-usb/pctv452e.c | 31 +++
 1 file changed, 15 insertions(+), 16 deletions(-)

diff --git a/drivers/media/usb/dvb-usb/pctv452e.c b/drivers/media/usb/dvb-
usb/pctv452e.c
index 07fa08b..5f9cd32 100644
--- a/drivers/media/usb/dvb-usb/pctv452e.c
+++ b/drivers/media/usb/dvb-usb/pctv452e.c
@@ -92,7 +92,6 @@ static struct stb0899_postproc pctv45e_postproc[] = {
  */
 struct pctv452e_state {
struct dvb_ca_en50221 ca;
-   struct mutex ca_mutex;
 
u8 c;  /* transaction counter, wraps around...  */
u8 initialized; /* set to 1 if 0x15 has been sent */
@@ -114,7 +113,7 @@ static int tt3650_ci_msg(struct dvb_usb_device *d, u8 
cmd, u8 *data,
return -EIO;
}
 
-   mutex_lock(>ca_mutex);
+   mutex_lock(>data_mutex);
id = state->c++;
 
state->data[0] = SYNC_BYTE_OUT;
@@ -136,14 +135,14 @@ static int tt3650_ci_msg(struct dvb_usb_device *d, u8 
cmd, u8 *data,
 
memcpy(data, state->data + 4, read_len);
 
-   mutex_unlock(>ca_mutex);
+   mutex_unlock(>data_mutex);
return 0;
 
 failed:
err("CI error %d; %02X %02X %02X -> %*ph.",
 ret, SYNC_BYTE_OUT, id, cmd, 3, state->data);
 
-   mutex_unlock(>ca_mutex);
+   mutex_unlock(>data_mutex);
return ret;
 }
 
@@ -155,9 +154,9 @@ static int tt3650_ci_msg_locked(struct dvb_ca_en50221 
*ca,
struct pctv452e_state *state = (struct pctv452e_state *)d->priv;
int ret;
 
-   mutex_lock(>ca_mutex);
+   mutex_lock(>data_mutex);
ret = tt3650_ci_msg(d, cmd, data, write_len, read_len);
-   mutex_unlock(>ca_mutex);
+   mutex_unlock(>data_mutex);
 
return ret;
 }
@@ -296,7 +295,7 @@ static int tt3650_ci_slot_reset(struct dvb_ca_en50221 
*ca, int slot)
 
buf[0] = 0;
 
-   mutex_lock(>ca_mutex);
+   mutex_lock(>data_mutex);
 
ret = tt3650_ci_msg(d, TT3650_CMD_CI_RESET, buf, 1, 1);
if (0 != ret)
@@ -317,7 +316,7 @@ static int tt3650_ci_slot_reset(struct dvb_ca_en50221 
*ca, int slot)
ret = tt3650_ci_msg(d, TT3650_CMD_CI_SET_VIDEO_PORT, buf, 1, 1);
 
  failed:
-   mutex_unlock(>ca_mutex);
+   mutex_unlock(>data_mutex);
 
return ret;
 }
@@ -376,7 +375,7 @@ static int tt3650_ci_init(struct dvb_usb_adapter *a)
 
ci_dbg("%s", __func__);
 
-   mutex_init(>ca_mutex);
+   mutex_init(>data_mutex);
 
state->ca.owner = THIS_MODULE;
state->ca.read_attribute_mem = tt3650_ci_read_attribute_mem;
@@ -413,7 +412,7 @@ static int pctv452e_i2c_msg(struct dvb_usb_device *d, u8 
addr,
u8 id;
int ret;
 
-   mutex_lock(>ca_mutex);
+   mutex_lock(>data_mutex);
id = state->c++;
 
ret = -EINVAL;
@@ -447,7 +446,7 @@ static int pctv452e_i2c_msg(struct dvb_usb_device *d, u8 
addr,
goto failed;
 
memcpy(rcv_buf, state->data + 7, rcv_len);
-   mutex_unlock(>ca_mutex);
+   mutex_unlock(>data_mutex);
 
return rcv_len;
 
@@ -456,7 +455,7 @@ static int pctv452e_i2c_msg(struct dvb_usb_device *d, u8 
addr,
 ret, SYNC_BYTE_OUT, id, addr << 1, snd_len, rcv_len,
 7, state->data);
 
-   mutex_unlock(>ca_mutex);
+   mutex_unlock(>data_mutex);
return ret;
 }
 
@@ -520,7 +519,7 @@ static int pctv452e_power_ctrl(struct dvb_usb_device *d, 
int i)
if (!rx)
return -ENOMEM;
 
-   mutex_lock(>ca_mutex);
+   mutex_lock(>data_mutex);
/* hmm where shoud this should go? */
ret = usb_set_interface(d->udev, 0, ISOC_INTERFACE_ALTERNATIVE);
if (ret != 0)
@@ -548,7 +547,7 @@ static int pctv452e_power_ctrl(struct dvb_usb_device *d, 
int i)
state->initialized = 1;
 
 ret:
-   mutex_unlock(>ca_mutex);
+   mutex_unlock(>data_mutex);
kfree(rx);
 

Re: NAPI on USB network drivers

[David Miller]

From: Oliver Neukum 
Date: Wed, 25 Jan 2017 10:34:41 +0100

> looking at r8152 I noticed that it uses NAPI. I never considered
> this for the generic USB networking code as you cannot disable
> interrupts for USB. Is it still worth it? What are the benefits?

I think it's not a good approach for getting GRO.

Exactly because of the issue you raise, in that USB drivers
cannot stop the URBs from coming in while running their poll
method.
--
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 net v2 0/4] r8152: fix scheduling napi

[David Miller]

From: Hayes Wang 
Date: Wed, 25 Jan 2017 16:13:17 +0800

> v2:
> Add smp_mb__after_atomic() for patch #1.
> 
> v1:
> Scheduling the napi during the following periods would let it be ignored.
> And the events wouldn't be handled until next napi_schedule() is called.
> 
> 1. after napi_disable and before napi_enable().
> 2. after all actions of napi function is completed and before calling
>napi_complete().
> 
> If no next napi_schedule() is called, tx or rx would stop working.
> 
> In order to avoid these situations, the followings solutions are applied.
> 
> 1. prevent start_xmit() from calling napi_schedule() during runtime suspend
>or after napi_disable().
> 2. re-schedule the napi for tx if it is necessary.
> 3. check if any rx is finished or not after napi_enable().

I think the fundamental issue is that since you can't stop URBs from
queueing up, you cannot properly synchronize NAPI and schedule polling
properly.

>From my perspective what happened here is you want GRO support, but it
comes at the expense of this extremely racey NAPI support which does
not at all achieve one of the main advantages of NAPI which is
interrupt mitigation.

It would have been so much better to implement a generic way for
drivers to get GRO support without NAPI, especially if their packet
feeding engine works the way that the USB networking drivers's do.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5] USB: Add uPD78F0730 USB to Serial Adaptor Driver

[Maksim Salau]

Hi Johan,

> You made some further changes than what I suggested but forgot to
> document those. Often better to explicitly list the changes made rather
> than refer to review comments this way.

Sorry for that, I'll try to describe changes more verbosely.

> > +   if (res < 0)
> > +   return res;
> > +
> > +   if (res != size) {
> > +   dev_err(dev, "%s - send failed: opcode=%02x, size=%d, res=%d\n",
> > +   __func__, *(u8 *)data, size, res);
> 
> You still want an error message in case res < 0 (as in v3), but you can
> return that errno instead of -EIO then.
> 
> You can drop the __func__ prefixes you added to error messages in v5
> throughout, better to spell out what went wrong (e.g. "failed to send
> control request %02x: %d\n", *(u8 *)data, res).

Thanks.

> 
> This is new in v5, and should have been mentioned in the changelog above.
> 
> Note that this is not strictly necessary, though. Some drivers
> dereferenced pointers without the appropriate sanity checks, but this
> driver and the generic callbacks it uses, does not suffer from such
> problems.
> 
> I suggest you just drop this check (i.e. the attach callback).

Ok. I saw a bunch of patches in the list that added such check to almost
every driver, so I suspected such check is required in this one too.

Thanks,
Maksim.
--
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 -next] usb: chipidea: msm: Fix return value check in ci_hdrc_msm_probe()

[Stephen Boyd]

Quoting Wei Yongjun (2017-01-25 06:02:48)
> From: Wei Yongjun 
> 
> In case of error, the function devm_ioremap_resource() returns ERR_PTR()
> and never returns NULL. The NULL test in the return value check should
> be replaced with IS_ERR().
> 
> Fixes: 2fc305be364e ("usb: chipidea: msm: Mux over secondary phy at the
> right time")
> Signed-off-by: Wei Yongjun 

Thanks.

Reviewed-by: Stephen Boyd 
--
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: [PATCHv15 2/3] usb: USB Type-C connector class

[Guenter Roeck]

On Mon, Jan 23, 2017 at 04:44:23PM +0200, Felipe Balbi wrote:
> 
> Hi,
> 
> Heikki Krogerus  writes:
> > +static void typec_report_identity(struct device *dev)
> > +{
> > +   sysfs_notify(>kobj, "identity", "id_header");
> > +   sysfs_notify(>kobj, "identity", "cert_stat");
> > +   sysfs_notify(>kobj, "identity", "product");
> 
> if you sysfs_notify() all three everytime this might cause issues for
> userspace pollers. What will happen is that you're gonna change
> e.g. id_header and threads polling id_header, cert_stat and product will
> be notified of what's supposed to be new data. Maybe this should know
> what it's notifying and only notify what actually changed. Seems like
> just passing one extra char * argument is enough:
> 
> static void typec_report_identity(struct device *dev, const char *prop)
> {
>   sysfs_notify(>kobj, "identity", prop);
> }
> 
I must admit that I am kind of lost here. In practice all three values are
provided by the PD protocol in a single message, meaning they are all updated
at the same time. The result of this code is that I have to call the function
three times, each time providing what I think should be a class-internal string
as parameter (the low level code should not really be concerned about the
sysfs attribute names). What exactly are we gaining from this ?

Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: dts: Odroid XU4: fix USB3.0 ports

[Anand Moon]

Hi Krzysztof,

On 25 January 2017 at 19:47, Krzysztof Kozlowski  wrote:
> On Wed, Jan 25, 2017 at 3:48 PM, Marek Szyprowski
>  wrote:
>> Hi Krzysztof,
>>
>> On 2017-01-25 08:55, Krzysztof Kozlowski wrote:
>>>
>>> On Wed, Jan 25, 2017 at 7:51 AM, Anand Moon  wrote:

 On 24 January 2017 at 19:18, Richard Genoud 
 wrote:
>
> Since commit 2164a476205ccc ("usb: dwc3: set SUSPHY bit for all cores"),
> the USB ports on odroid-XU4 don't work anymore.
>
> Inserting an usb key (USB2.0) on the USB3.0 port result in:
> [ 64.488264] xhci-hcd xhci-hcd.2.auto: Port resume took longer than
> 2 msec, port status = 0xc400fe3
> [   74.568156] xhci-hcd xhci-hcd.2.auto: xHCI host not responding to
> stop endpoint command.
> [   74.574806] xhci-hcd xhci-hcd.2.auto: Assuming host is dying, halting
> host.
> [   74.601970] xhci-hcd xhci-hcd.2.auto: HC died; cleaning up
> [   74.606276] usb 3-1: USB disconnect, device number 2
> [   74.613565] usb 4-1: USB disconnect, device number 2
> [   74.621208] usb usb3-port1: couldn't allocate usb_device
> NB: it's not related to USB2.0 devices, I get the same result with an
> USB3.0 device (SATA to USB3 for instance).
> NB2: it doesn't happen on an odriod-XU3 board, that doesn't have the
> realtek RTL8153 chip.
>
> If the lines:
>  if (dwc->revision > DWC3_REVISION_194A)
>  reg |= DWC3_GUSB3PIPECTL_SUSPHY;
> are commented out, the USB3.0 start working.
>
> For a full analyse: https://lkml.org/lkml/2017/1/18/678
>
> Felipe suggested that suspend should be disabled temporarily while
> what's wrong with DCW3 is figured out.
>
> Tested on Odroid XU4
>
> Suggested-by: Felipe Balbi 
> Tested-by: Richard Genoud 
> Signed-off-by: Richard Genoud 
> Cc: sta...@vger.kernel.org # 4.4+
> Fixes: 2164a476205ccc ("usb: dwc3: set SUSPHY bit for all cores")
> ---
>   arch/arm/boot/dts/exynos5422-odroidxu4.dts | 9 +
>   1 file changed, 9 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos5422-odroidxu4.dts
> b/arch/arm/boot/dts/exynos5422-odroidxu4.dts
> index 2faf88627a48..f62dbd9b5ad3 100644
> --- a/arch/arm/boot/dts/exynos5422-odroidxu4.dts
> +++ b/arch/arm/boot/dts/exynos5422-odroidxu4.dts
> @@ -43,6 +43,15 @@
>  status = "okay";
>   };
>
> +_dwc3_0 {
> +   /*
> +* without that, usb devices are not recognized when
> +* they are plugged.
> +* cf: https://lkml.org/lkml/2017/1/18/678
> +*/
> +   snps,dis_u3_susphy_quirk;
> +};
> +
>   _dwc3_1 {
>  dr_mode = "host";
>   };
> --

 Thanks for this patch.
 But could you consider moving this changes as below.

 https://lkml.org/lkml/2015/3/18/400
>>>
>>> The patch above (and other DTS patches from the set) was not even sent
>>> to linux-samsung-soc nor to me... It is sad how easily one's work can
>>> disappear. Also, it is really worthless to solve the same problem
>>> twice.
>>
>>
>> Well, they were sent about 2 years ago... and you were also working on this
>> topic. ;)
>
> Nope, I have never worked on this. That time I was in Korea so my
> tasks were completely different. Later when I got back, I took for a
> second U3 OTG which was not involving this thing.
>
>>> Cc Marek and Bartlomiej,
>>> Guys, do you want to continue with Robert's patch (linked above by
>>> Anand)? If yes, please take the ownership (Robert's address is not
>>> valid anymore). If not, I will take Richard's patch after
>>> resubmission.
>>
>>
>> Take Richard's patch because it has a bit more details describing why such
>> quirk
>> is needed.
>>
>> Richard: in Roberts patch there is also a quirk for USB 2.0 mode
>> (snps,dis_u2_susphy_quirk). Could you check if it really needed?
>>
>> Maybe it would make sense to set those quirks for both DWC3 controllers, as
>> this
>> issue with PHY suspend seems to be a Exynos specific thing.
>
> Okay,
> Richard, please continue with your patch.
>
> Best regards,
> Krzysztof

Their is certainly some issue with respect PHY in phy-exynos5-usbdrd
or dwc3-exynos.c

odroid@odroidxu4n:~$ lsusb -v|egrep "^Bus|MaxPower"
Bus 006 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
MaxPower0mA
Bus 005 Device 002: ID 0bda:8153 Realtek Semiconductor Corp.
MaxPower  180mA
MaxPower  180mA
Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
MaxPower0mA
Bus 004 Device 099: ID 174c:5106 ASMedia Technology Inc. ASM1051 SATA
3Gb/s bridge
MaxPower0mA
Bus 004 Device 002: ID 05e3:0616 Genesys Logic, Inc. hub
MaxPower 

Re: [PATCH net-next] r8152: fix the wrong spelling

[David Miller]

From: Hayes Wang 
Date: Wed, 25 Jan 2017 13:41:45 +0800

> Replace rumtime with runtime.
> 
> Signed-off-by: Hayes Wang 

Applied, thanks.
--
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 i-g-t v7 0/1] usb: xhci: plat: Enable runtime PM

[Robert Foss]

This series enables runtime PM and asynchronous resume/suspend support for
xhci-plat devices.

Due to Baolin Wangs series[1] part 1/2 of this series is now dropped.

[1] https://lkml.org/lkml/2016/12/13/32

Andrew Bresticker (1):
  usb: xhci: plat: Enable async suspend/resume

 drivers/usb/host/xhci-plat.c | 1 +
 1 file changed, 1 insertion(+)

-- 
2.11.0.453.g787f75f05

--
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 i-g-t v7 1/1] usb: xhci: plat: Enable async suspend/resume

[Robert Foss]

From: Andrew Bresticker 

USB host controllers can take a significant amount of time to suspend
and resume, adding several hundred miliseconds to the kernel resume
time. Since the XHCI controller has no outside dependencies (other than
clocks, which are suspended late/resumed early), allow it to suspend and
resume asynchronously.

Signed-off-by: Andrew Bresticker 
Tested-by: Andrew Bresticker 
Tested-by: Robert Foss 
Signed-off-by: Robert Foss 
---
 drivers/usb/host/xhci-plat.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 3cf8e120c620..4d6741a0d8f8 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -257,6 +257,7 @@ static int xhci_plat_probe(struct platform_device *pdev)
 
pm_runtime_set_active(>dev);
pm_runtime_enable(>dev);
+   device_enable_async_suspend(>dev);
 
return 0;
 
-- 
2.11.0.453.g787f75f05

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 2/2] usb: dwc3: core: Support the dwc3 host suspend/resume

[Robert Foss]

Looks good to me.

Feel free to add my r-b.


Rob.

On 2016-12-13 02:49 AM, Baolin Wang wrote:

For some mobile devices with strict power management, we also want to suspend
the host when the slave is detached for power saving. Thus we add the host
suspend/resume functions to support this requirement.

Signed-off-by: Baolin Wang 
---
Changes since v4:
 - Remove Kconfig and just enable host suspend/resume.
 - Simplify the dwc3_host_suspend/resume() function.

Changes since v3:
 - No updates.

Changes since v2:
 - Remove pm_children_suspended() and other unused macros.

Changes since v1:
 - Add pm_runtime.h head file to avoid kbuild error.
---
 drivers/usb/dwc3/core.c |   26 +-
 drivers/usb/dwc3/core.h |7 +++
 drivers/usb/dwc3/host.c |   21 +
 3 files changed, 53 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 9a4a5e4..7ad4bc3 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -1091,6 +1091,7 @@ static int dwc3_probe(struct platform_device *pdev)
pm_runtime_use_autosuspend(dev);
pm_runtime_set_autosuspend_delay(dev, DWC3_DEFAULT_AUTOSUSPEND_DELAY);
pm_runtime_enable(dev);
+   pm_suspend_ignore_children(dev, true);
ret = pm_runtime_get_sync(dev);
if (ret < 0)
goto err1;
@@ -1215,15 +1216,27 @@ static int dwc3_remove(struct platform_device *pdev)
 static int dwc3_suspend_common(struct dwc3 *dwc)
 {
unsigned long   flags;
+   int ret;

switch (dwc->dr_mode) {
case USB_DR_MODE_PERIPHERAL:
+   spin_lock_irqsave(>lock, flags);
+   dwc3_gadget_suspend(dwc);
+   spin_unlock_irqrestore(>lock, flags);
+   break;
case USB_DR_MODE_OTG:
+   ret = dwc3_host_suspend(dwc);
+   if (ret)
+   return ret;
+
spin_lock_irqsave(>lock, flags);
dwc3_gadget_suspend(dwc);
spin_unlock_irqrestore(>lock, flags);
break;
case USB_DR_MODE_HOST:
+   ret = dwc3_host_suspend(dwc);
+   if (ret)
+   return ret;
default:
/* do nothing */
break;
@@ -1245,12 +1258,23 @@ static int dwc3_resume_common(struct dwc3 *dwc)

switch (dwc->dr_mode) {
case USB_DR_MODE_PERIPHERAL:
+   spin_lock_irqsave(>lock, flags);
+   dwc3_gadget_resume(dwc);
+   spin_unlock_irqrestore(>lock, flags);
+   break;
case USB_DR_MODE_OTG:
+   ret = dwc3_host_resume(dwc);
+   if (ret)
+   return ret;
+
spin_lock_irqsave(>lock, flags);
dwc3_gadget_resume(dwc);
spin_unlock_irqrestore(>lock, flags);
-   /* FALLTHROUGH */
+   break;
case USB_DR_MODE_HOST:
+   ret = dwc3_host_resume(dwc);
+   if (ret)
+   return ret;
default:
/* do nothing */
break;
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index b585a30..1099168 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -1158,11 +1158,18 @@ static inline bool dwc3_is_usb31(struct dwc3 *dwc)
 #if IS_ENABLED(CONFIG_USB_DWC3_HOST) || IS_ENABLED(CONFIG_USB_DWC3_DUAL_ROLE)
 int dwc3_host_init(struct dwc3 *dwc);
 void dwc3_host_exit(struct dwc3 *dwc);
+int dwc3_host_suspend(struct dwc3 *dwc);
+int dwc3_host_resume(struct dwc3 *dwc);
 #else
 static inline int dwc3_host_init(struct dwc3 *dwc)
 { return 0; }
 static inline void dwc3_host_exit(struct dwc3 *dwc)
 { }
+
+static inline int dwc3_host_suspend(struct dwc3 *dwc)
+{ return 0; }
+static inline int dwc3_host_resume(struct dwc3 *dwc)
+{ return 0; }
 #endif

 #if IS_ENABLED(CONFIG_USB_DWC3_GADGET) || IS_ENABLED(CONFIG_USB_DWC3_DUAL_ROLE)
diff --git a/drivers/usb/dwc3/host.c b/drivers/usb/dwc3/host.c
index ed82464..7959ef0 100644
--- a/drivers/usb/dwc3/host.c
+++ b/drivers/usb/dwc3/host.c
@@ -16,6 +16,7 @@
  */

 #include 
+#include 

 #include "core.h"

@@ -130,3 +131,23 @@ void dwc3_host_exit(struct dwc3 *dwc)
  dev_name(>xhci->dev));
platform_device_unregister(dwc->xhci);
 }
+
+int dwc3_host_suspend(struct dwc3 *dwc)
+{
+   struct device *xhci = >xhci->dev;
+
+   /*
+* Note: if we get the -EBUSY, which means the xHCI children devices are
+* not in suspend state yet, the glue layer need to wait for a while and
+* try to suspend xHCI device again.
+*/
+   return pm_runtime_put_sync(xhci);
+}
+
+int dwc3_host_resume(struct dwc3 *dwc)
+{
+   struct device *xhci = >xhci->dev;
+
+   /* Resume the xHCI device synchronously. */
+   return pm_runtime_get_sync(xhci);
+}


--
To unsubscribe from this list: send 

Re: [PATCH v5 1/2] usb: host: plat: Enable xhci plat runtime PM

[Robert Foss]

Looks good to me.

Feel free to add my r-b.

On 2016-12-13 02:49 AM, Baolin Wang wrote:

Enable the xhci plat runtime PM for parent device to suspend/resume xhci.
Also call pm_runtime_get_noresume() in probe() function in case the parent
device doesn't call suspend/resume callback by runtime PM now.

Signed-off-by: Baolin Wang 
---
Changes since v4:
 - No updates.

Changes since v3:
 - Fix kbuild error.

Changes since v2:
 - Add pm_runtime_get_noresume() in probe() function.
 - Add pm_runtime_set_suspended()/pm_runtime_put_noidle() in remove() function.

Changes since v1:
 - No updates.
---
 drivers/usb/host/xhci-plat.c |   41 -
 1 file changed, 36 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index ed56bf9..5805c6a 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -246,6 +246,10 @@ static int xhci_plat_probe(struct platform_device *pdev)
if (ret)
goto dealloc_usb2_hcd;

+   pm_runtime_get_noresume(>dev);
+   pm_runtime_set_active(>dev);
+   pm_runtime_enable(>dev);
+
return 0;


@@ -274,6 +278,10 @@ static int xhci_plat_remove(struct platform_device *dev)
struct xhci_hcd *xhci = hcd_to_xhci(hcd);
struct clk *clk = xhci->clk;

+   pm_runtime_set_suspended(>dev);
+   pm_runtime_put_noidle(>dev);
+   pm_runtime_disable(>dev);
+
usb_remove_hcd(xhci->shared_hcd);
usb_phy_shutdown(hcd->usb_phy);

@@ -311,14 +319,37 @@ static int xhci_plat_resume(struct device *dev)

return xhci_resume(xhci, 0);
 }
+#endif /* CONFIG_PM_SLEEP */
+
+#ifdef CONFIG_PM
+static int xhci_plat_runtime_suspend(struct device *dev)
+{
+   struct usb_hcd  *hcd = dev_get_drvdata(dev);
+   struct xhci_hcd *xhci = hcd_to_xhci(hcd);
+
+   return xhci_suspend(xhci, device_may_wakeup(dev));
+}
+
+static int xhci_plat_runtime_resume(struct device *dev)
+{
+   struct usb_hcd  *hcd = dev_get_drvdata(dev);
+   struct xhci_hcd *xhci = hcd_to_xhci(hcd);
+
+   return xhci_resume(xhci, 0);
+}
+
+static int xhci_plat_runtime_idle(struct device *dev)
+{
+   return 0;
+}
+#endif /* CONFIG_PM */

 static const struct dev_pm_ops xhci_plat_pm_ops = {
SET_SYSTEM_SLEEP_PM_OPS(xhci_plat_suspend, xhci_plat_resume)
+
+   SET_RUNTIME_PM_OPS(xhci_plat_runtime_suspend, xhci_plat_runtime_resume,
+  xhci_plat_runtime_idle)
 };
-#define DEV_PM_OPS (_plat_pm_ops)
-#else
-#define DEV_PM_OPS NULL
-#endif /* CONFIG_PM */

 static const struct acpi_device_id usb_xhci_acpi_match[] = {
/* XHCI-compliant USB Controller */
@@ -332,7 +363,7 @@ static int xhci_plat_resume(struct device *dev)
.remove = xhci_plat_remove,
.driver = {
.name = "xhci-hcd",
-   .pm = DEV_PM_OPS,
+   .pm = _plat_pm_ops,
.of_match_table = of_match_ptr(usb_xhci_of_match),
.acpi_match_table = ACPI_PTR(usb_xhci_acpi_match),
},


--
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: serial: ftdi_sio: clean up ioctl handler

[Johan Hovold]

Clean up the ioctl handler and make sure to pass an unsigned-int rather
than serial_struct pointer to the TIOCSERGETLSR helper as this it what
the user argument really is.

Signed-off-by: Johan Hovold 
---
 drivers/usb/serial/ftdi_sio.c | 19 +++
 1 file changed, 7 insertions(+), 12 deletions(-)

diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
index 4bd556d9307d..e82dbb3d0883 100644
--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -1534,7 +1534,7 @@ static int set_serial_info(struct tty_struct *tty,
 }
 
 static int get_lsr_info(struct usb_serial_port *port,
-   struct serial_struct __user *retinfo)
+   unsigned int __user *retinfo)
 {
struct ftdi_private *priv = usb_get_serial_port_data(port);
unsigned int result = 0;
@@ -2485,20 +2485,15 @@ static int ftdi_ioctl(struct tty_struct *tty,
unsigned int cmd, unsigned long arg)
 {
struct usb_serial_port *port = tty->driver_data;
+   void __user *argp = (void __user *)arg;
 
-   /* Based on code from acm.c and others */
switch (cmd) {
-
-   case TIOCGSERIAL: /* gets serial port data */
-   return get_serial_info(port,
-   (struct serial_struct __user *) arg);
-
-   case TIOCSSERIAL: /* sets serial port data */
-   return set_serial_info(tty, port,
-   (struct serial_struct __user *) arg);
+   case TIOCGSERIAL:
+   return get_serial_info(port, argp);
+   case TIOCSSERIAL:
+   return set_serial_info(tty, port, argp);
case TIOCSERGETLSR:
-   return get_lsr_info(port, (struct serial_struct __user *)arg);
-   break;
+   return get_lsr_info(port, argp);
default:
break;
}
-- 
2.10.2

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/2] USB: serial: drop unused ASYNC flags

[Johan Hovold]

Do not report ASYNC_SKIP_TEST or ASYNC_AUTO_IRQ as being set in
TIOCGSERIAL handlers as these flags are not supported and do not really
make any sense for USB serial devices in the first place.

Signed-off-by: Johan Hovold 
---
 drivers/usb/serial/io_edgeport.c | 1 -
 drivers/usb/serial/io_ti.c   | 1 -
 drivers/usb/serial/mos7720.c | 1 -
 drivers/usb/serial/mos7840.c | 1 -
 drivers/usb/serial/opticon.c | 1 -
 drivers/usb/serial/quatech2.c| 1 -
 drivers/usb/serial/ssu100.c  | 1 -
 drivers/usb/serial/whiteheat.c   | 1 -
 8 files changed, 8 deletions(-)

diff --git a/drivers/usb/serial/io_edgeport.c b/drivers/usb/serial/io_edgeport.c
index 8ab5f5b49ef3..92abf92e5669 100644
--- a/drivers/usb/serial/io_edgeport.c
+++ b/drivers/usb/serial/io_edgeport.c
@@ -1572,7 +1572,6 @@ static int get_serial_info(struct edgeport_port 
*edge_port,
tmp.line= edge_port->port->minor;
tmp.port= edge_port->port->port_number;
tmp.irq = 0;
-   tmp.flags   = ASYNC_SKIP_TEST | ASYNC_AUTO_IRQ;
tmp.xmit_fifo_size  = edge_port->maxTxCredits;
tmp.baud_base   = 9600;
tmp.close_delay = 5*HZ;
diff --git a/drivers/usb/serial/io_ti.c b/drivers/usb/serial/io_ti.c
index 9a0db2965fbb..ceaeebaa6f90 100644
--- a/drivers/usb/serial/io_ti.c
+++ b/drivers/usb/serial/io_ti.c
@@ -2468,7 +2468,6 @@ static int get_serial_info(struct edgeport_port 
*edge_port,
tmp.line= edge_port->port->minor;
tmp.port= edge_port->port->port_number;
tmp.irq = 0;
-   tmp.flags   = ASYNC_SKIP_TEST | ASYNC_AUTO_IRQ;
tmp.xmit_fifo_size  = edge_port->port->bulk_out_size;
tmp.baud_base   = 9600;
tmp.close_delay = 5*HZ;
diff --git a/drivers/usb/serial/mos7720.c b/drivers/usb/serial/mos7720.c
index acf431e02699..f075121c6e32 100644
--- a/drivers/usb/serial/mos7720.c
+++ b/drivers/usb/serial/mos7720.c
@@ -1851,7 +1851,6 @@ static int get_serial_info(struct moschip_port 
*mos7720_port,
tmp.line= mos7720_port->port->minor;
tmp.port= mos7720_port->port->port_number;
tmp.irq = 0;
-   tmp.flags   = ASYNC_SKIP_TEST | ASYNC_AUTO_IRQ;
tmp.xmit_fifo_size  = NUM_URBS * URB_TRANSFER_BUFFER_SIZE;
tmp.baud_base   = 9600;
tmp.close_delay = 5*HZ;
diff --git a/drivers/usb/serial/mos7840.c b/drivers/usb/serial/mos7840.c
index 155006acf918..d1b92f582478 100644
--- a/drivers/usb/serial/mos7840.c
+++ b/drivers/usb/serial/mos7840.c
@@ -1963,7 +1963,6 @@ static int mos7840_get_serial_info(struct moschip_port 
*mos7840_port,
tmp.line = mos7840_port->port->minor;
tmp.port = mos7840_port->port->port_number;
tmp.irq = 0;
-   tmp.flags = ASYNC_SKIP_TEST | ASYNC_AUTO_IRQ;
tmp.xmit_fifo_size = NUM_URBS * URB_TRANSFER_BUFFER_SIZE;
tmp.baud_base = 9600;
tmp.close_delay = 5 * HZ;
diff --git a/drivers/usb/serial/opticon.c b/drivers/usb/serial/opticon.c
index b3c64f557d60..3937b9c3cc69 100644
--- a/drivers/usb/serial/opticon.c
+++ b/drivers/usb/serial/opticon.c
@@ -343,7 +343,6 @@ static int get_serial_info(struct usb_serial_port *port,
tmp.line= port->minor;
tmp.port= 0;
tmp.irq = 0;
-   tmp.flags   = ASYNC_SKIP_TEST | ASYNC_AUTO_IRQ;
tmp.xmit_fifo_size  = 1024;
tmp.baud_base   = 9600;
tmp.close_delay = 5*HZ;
diff --git a/drivers/usb/serial/quatech2.c b/drivers/usb/serial/quatech2.c
index cf29128327d3..fdbb904d153f 100644
--- a/drivers/usb/serial/quatech2.c
+++ b/drivers/usb/serial/quatech2.c
@@ -465,7 +465,6 @@ static int get_serial_info(struct usb_serial_port *port,
tmp.line= port->minor;
tmp.port= 0;
tmp.irq = 0;
-   tmp.flags   = ASYNC_SKIP_TEST | ASYNC_AUTO_IRQ;
tmp.xmit_fifo_size  = port->bulk_out_size;
tmp.baud_base   = 9600;
tmp.close_delay = 5*HZ;
diff --git a/drivers/usb/serial/ssu100.c b/drivers/usb/serial/ssu100.c
index 55814538ff1f..5aa7bbbeba3d 100644
--- a/drivers/usb/serial/ssu100.c
+++ b/drivers/usb/serial/ssu100.c
@@ -339,7 +339,6 @@ static int get_serial_info(struct usb_serial_port *port,
tmp.line= port->minor;
tmp.port= 0;
tmp.irq = 0;
-   tmp.flags   = ASYNC_SKIP_TEST | ASYNC_AUTO_IRQ;
tmp.xmit_fifo_size  = port->bulk_out_size;
tmp.baud_base   = 9600;
tmp.close_delay = 5*HZ;
diff --git a/drivers/usb/serial/whiteheat.c b/drivers/usb/serial/whiteheat.c
index d3ea90bef84d..5ab65eb1dacc 100644
--- 

[PATCH] USB: cdc-acm: fix TIOCGSERIAL flags

[Johan Hovold]

The driver reports that it always uses a low-latency mode by returning
the ASYNC_LOW_LATENCY flag through TIOCGSERIAL.

Even if this behaviour could not be changed, this may have made some
sense prior to 7a9a65ced11e ("cdc-acm: Fix long standing abuse of
tty->low_latency") which removed the unconditional setting of the
corresponding tty low_latency flag (something which had always been
broken in itself).

Since the driver does not have a low-latency mode, let's drop the flag.

Signed-off-by: Johan Hovold 
---
 drivers/usb/class/cdc-acm.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/usb/class/cdc-acm.c b/drivers/usb/class/cdc-acm.c
index e35b1508d3eb..235e305f8473 100644
--- a/drivers/usb/class/cdc-acm.c
+++ b/drivers/usb/class/cdc-acm.c
@@ -913,7 +913,6 @@ static int get_serial_info(struct acm *acm, struct 
serial_struct __user *info)
struct serial_struct tmp;
 
memset(, 0, sizeof(tmp));
-   tmp.flags = ASYNC_LOW_LATENCY;
tmp.xmit_fifo_size = acm->writesize;
tmp.baud_base = le32_to_cpu(acm->line.dwDTERate);
tmp.close_delay = acm->port.close_delay / 10;
-- 
2.10.2

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] usb: musb: constify musb_hdrc_config structures

[Bin Liu]

On Wed, Jan 25, 2017 at 12:52:22AM +0530, Bhumika Goyal wrote:
> Declare musb_hdrc_config structures as const as they are only stored in
> the config field of a musb_hdrc_platform_data structure. This field is of
> type const, so musb_hdrc_config structures having this property can be
> made const too.
> Done using Coccinelle:
> 
> @r disable optional_qualifier@
> identifier x;
> position p;
> @@
> static struct musb_hdrc_config x@p={...};
> 
> @ok@
> struct musb_hdrc_platform_data pdata;
> identifier r.x;
> position p;
> @@
> pdata.config=@p;
> 
> @bad@
> position p != {r.p,ok.p};
> identifier r.x;
> @@
> x@p
> 
> @depends on !bad disable optional_qualifier@
> identifier r.x;
> @@
> +const
> struct musb_hdrc_config x;
> 
> File size before:
>text  data bss dec hex filename
>1212   338   01550 60e drivers/usb/musb/jz4740.o
> 
> File size after:
>text  data bss dec hex filename
>1268   290   01558 616 drivers/usb/musb/jz4740.o
> 
> File size before:
>text  data bss dec hex filename
>6151   333  1665001964 drivers/usb/musb/sunxi.o
> 
> File size after:
>text  data bss dec hex filename
>6215   269  1665001964 drivers/usb/musb/sunxi.o
> 
> File size before:
>text  data bss dec hex filename
>3668   864   0453211b4 drivers/usb/musb/ux500.o
> 
> File size after:
>text  data bss dec hex filename
>3724   808   0453211b4 drivers/usb/musb/ux500.o
> 
> Signed-off-by: Bhumika Goyal 

Hi Greg,

Why you don't want this patch go through my tree? Now it causes me tree
rebase failed. It should be easy to fix, but just wanted to learn your
rules.

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 v5 1/4] usb: dbc: early driver for xhci debug capability

[Peter Zijlstra]

On Wed, Jan 25, 2017 at 11:51:34PM +0800, Lu Baolu wrote:

> > What is timeout and why?
> 
> Put it in simple:
> 
> The driver sets the RUN bit in control register and polls READY
> bit in status register for the successful USB device enumeration.
> As the USB device enumeration might fail and the READY bit will
> never be set, the driver must have a timeout logic to avoid
> endless loop.
> 
> More details:
> 
> The operational model is that driver sets up all necessary registers
> and data structures, and then starts the debug engine by setting
> the RUN/STOP bit in the control register.
> 
> The debug engine then brings up itself as a ready-for-enumeration
> USB device. The USB link between host and device starts link training
> and then host will detect the connected device. The hub driver in
> host will then starts the USB device enumeration processes (as defined
> in USB spec). If everything goes smoothly, the device gets enumerated
> and host can talk with the debug device.
> 
> After that, xdbc firmware will set the READY bit in status register. And
> the driver can go ahead with data transfer over USB.

I have vague memories from a prior discussion where you said this READY
state can be lost at any time (cable unplug or whatnot) and at that
point the driver should re-start the setup, right?

> >  If there is an error other than !ready, I would
> > expect the hardware to inform you of this through another status bit,
> > no?
> 
> Yeah, this might be another choice of hardware design. But it's not a
> topic for this driver.

So is there really no way to way to distinguish between "I did setup and
am waiting for READY", "I did setup, am waiting for READY, but things
got hosed" and "I was READY, things be hosed" ?

I suppose the first and last can be distinguished by remembering if you
ever saw READY, but the first and second are the interesting case I
think.

> > So why can't you poll indefinitely for either ready or error?
> >
> 
> Even if the hardware has both ready and error status bits, it's still
> nice to have a time out watch dog. Buggy hardware or firmware
> might not set any of these bits. Polling indefinitely might result in
> a endless loop.

Loosing output, esp. without indication, is very _very_ annoying when
you're debugging things. Its just about on par with a stuck system, at
least then you know something bad happened.

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] USB: serial: ftdi_sio: fix extreme low-latency setting

[Johan Hovold]

On Wed, Jan 25, 2017 at 04:42:01PM +0100, Greg Kroah-Hartman wrote:
> On Wed, Jan 25, 2017 at 04:14:36PM +0100, Johan Hovold wrote:
> > On Wed, Jan 25, 2017 at 04:06:47PM +0100, Greg Kroah-Hartman wrote:
> > > On Wed, Jan 25, 2017 at 03:35:20PM +0100, Johan Hovold wrote:
> > > > Since commit 557aaa7ffab6 ("ft232: support the ASYNC_LOW_LATENCY
> > > > flag") the FTDI driver has been using a receive latency-timer value of
> > > > 1 ms instead of the device default of 16 ms.
> > > > 
> > > > The latency timer is used to periodically empty a non-full receive
> > > > buffer, but a status header is always sent when the timer expires
> > > > including when the buffer is empty. This means that a two-byte bulk
> > > > message is received every millisecond also for an otherwise idle port as
> > > > long as it is open.
> > > > 
> > > > Let's restore the pre-2009 behaviour which reduces rate of status
> > > > messages to 1/16th (e.g. interrupt frequency drops from 1 kHz to 62.5
> > > > Hz) by not setting ASYNC_LOW_LATENCY by default.
> > > > 
> > > > Anyone willing to pay the price for the minimum-latency behaviour should
> > > > set the flag explicitly instead using the TIOCSSERIAL ioctl or a tool
> > > > such as setserial (e.g. setserial /dev/ttyUSB0 low_latency).
> > > > 
> > > > Note that since commit 0cbd81a9f6ba ("USB: ftdi_sio: remove
> > > > tty->low_latency") the ASYNC_LOW_LATENCY flag has no other effects but
> > > > to set a minimal latency timer.
> > > > 
> > > > Reported-by: Antoine Aubert 
> > > > Fixes: 557aaa7ffab6 ("ft232: support the ASYNC_LOW_LATENCY flag")
> > > > Cc: stable  # v2.6.31
> > > > Signed-off-by: Johan Hovold 
> > > > ---
> > > > 
> > > > Greg,
> > > > 
> > > > I've been aware of this overhead for a while, but never realised it was
> > > > actually a regression introduced in 2009.
> > > > 
> > > > Fixing something like this after such a long time obviously means
> > > > risking a regression for anyone who is now relying on the new default
> > > > behaviour instead. I still think it's reasonable in this case to restore
> > > > the earlier behaviour given the penalty everyone else is paying for a
> > > > minimal-latency behaviour that they likely do not need or want.
> > > > 
> > > > Whether this should go to stable is a different question. Perhaps the
> > > > stable tag is not warranted, and this should just be the default
> > > > behaviour going forward? What do you think?
> > > 
> > > I think the stable tag is warrented here.  Do you want me to take this
> > > patch now into my usb-linus tree, or will you include it in a pull
> > > request?
> > 
> > I'll include it in a pull request. I was gonna apply it for -next, but
> > if you prefer I can send it along with some new device ids I have queued
> > up for 4.10-rc?
> 
> -next is probably good, it's not like there is a rush for it :)

True. Don't really wanna think about how much power has been wasted on
these insane interrupt rates considering the number of these devices
that are out there though...

Now applied for -next, with a stable dependency on patch already in my
tree which did not need to be backported while ASYNC_LOW_LATENCY was
set.

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 v5 1/4] usb: dbc: early driver for xhci debug capability

[Lu Baolu]

Hi,

On 01/25/2017 10:38 PM, Peter Zijlstra wrote:
> On Wed, Jan 25, 2017 at 08:27:38PM +0800, Lu Baolu wrote:
>> In my driver, udelay() is mostly used to handle time out.
>>
>> Xdbc hides most USB things in its firmware. Early printk driver only needs
>> to setup the registers/data structures and wait until link ready or time out.
>> Without udelay(), I have no means to convert the polling times into waiting
>> time.
> What is timeout and why?

Put it in simple:

The driver sets the RUN bit in control register and polls READY
bit in status register for the successful USB device enumeration.
As the USB device enumeration might fail and the READY bit will
never be set, the driver must have a timeout logic to avoid
endless loop.

More details:

The operational model is that driver sets up all necessary registers
and data structures, and then starts the debug engine by setting
the RUN/STOP bit in the control register.

The debug engine then brings up itself as a ready-for-enumeration
USB device. The USB link between host and device starts link training
and then host will detect the connected device. The hub driver in
host will then starts the USB device enumeration processes (as defined
in USB spec). If everything goes smoothly, the device gets enumerated
and host can talk with the debug device.

After that, xdbc firmware will set the READY bit in status register. And
the driver can go ahead with data transfer over USB.

>  If there is an error other than !ready, I would
> expect the hardware to inform you of this through another status bit,
> no?

Yeah, this might be another choice of hardware design. But it's not a
topic for this driver.

>
> So why can't you poll indefinitely for either ready or error?
>
>

Even if the hardware has both ready and error status bits, it's still
nice to have a time out watch dog. Buggy hardware or firmware
might not set any of these bits. Polling indefinitely might result in
a endless loop.

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] USB: serial: ftdi_sio: fix extreme low-latency setting

[Greg Kroah-Hartman]

On Wed, Jan 25, 2017 at 04:14:36PM +0100, Johan Hovold wrote:
> On Wed, Jan 25, 2017 at 04:06:47PM +0100, Greg Kroah-Hartman wrote:
> > On Wed, Jan 25, 2017 at 03:35:20PM +0100, Johan Hovold wrote:
> > > Since commit 557aaa7ffab6 ("ft232: support the ASYNC_LOW_LATENCY
> > > flag") the FTDI driver has been using a receive latency-timer value of
> > > 1 ms instead of the device default of 16 ms.
> > > 
> > > The latency timer is used to periodically empty a non-full receive
> > > buffer, but a status header is always sent when the timer expires
> > > including when the buffer is empty. This means that a two-byte bulk
> > > message is received every millisecond also for an otherwise idle port as
> > > long as it is open.
> > > 
> > > Let's restore the pre-2009 behaviour which reduces rate of status
> > > messages to 1/16th (e.g. interrupt frequency drops from 1 kHz to 62.5
> > > Hz) by not setting ASYNC_LOW_LATENCY by default.
> > > 
> > > Anyone willing to pay the price for the minimum-latency behaviour should
> > > set the flag explicitly instead using the TIOCSSERIAL ioctl or a tool
> > > such as setserial (e.g. setserial /dev/ttyUSB0 low_latency).
> > > 
> > > Note that since commit 0cbd81a9f6ba ("USB: ftdi_sio: remove
> > > tty->low_latency") the ASYNC_LOW_LATENCY flag has no other effects but
> > > to set a minimal latency timer.
> > > 
> > > Reported-by: Antoine Aubert 
> > > Fixes: 557aaa7ffab6 ("ft232: support the ASYNC_LOW_LATENCY flag")
> > > Cc: stable    # v2.6.31
> > > Signed-off-by: Johan Hovold 
> > > ---
> > > 
> > > Greg,
> > > 
> > > I've been aware of this overhead for a while, but never realised it was
> > > actually a regression introduced in 2009.
> > > 
> > > Fixing something like this after such a long time obviously means
> > > risking a regression for anyone who is now relying on the new default
> > > behaviour instead. I still think it's reasonable in this case to restore
> > > the earlier behaviour given the penalty everyone else is paying for a
> > > minimal-latency behaviour that they likely do not need or want.
> > > 
> > > Whether this should go to stable is a different question. Perhaps the
> > > stable tag is not warranted, and this should just be the default
> > > behaviour going forward? What do you think?
> > 
> > I think the stable tag is warrented here.  Do you want me to take this
> > patch now into my usb-linus tree, or will you include it in a pull
> > request?
> 
> I'll include it in a pull request. I was gonna apply it for -next, but
> if you prefer I can send it along with some new device ids I have queued
> up for 4.10-rc?

-next is probably good, it's not like there is a rush for it :)
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH] USB: serial: ftdi_sio: fix extreme low-latency setting

[David Laight]

From: Johan Hovold
> Sent: 25 January 2017 14:35
> Since commit 557aaa7ffab6 ("ft232: support the ASYNC_LOW_LATENCY
> flag") the FTDI driver has been using a receive latency-timer value of
> 1 ms instead of the device default of 16 ms.
> 
> The latency timer is used to periodically empty a non-full receive
> buffer, but a status header is always sent when the timer expires
> including when the buffer is empty. This means that a two-byte bulk
> message is received every millisecond also for an otherwise idle port as
> long as it is open.
...

I'd wondered what all those packets were.
It seems beyond stupid that the hardware is sending them at all.

David

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] USB: serial: ftdi_sio: fix extreme low-latency setting

[Johan Hovold]

On Wed, Jan 25, 2017 at 04:06:47PM +0100, Greg Kroah-Hartman wrote:
> On Wed, Jan 25, 2017 at 03:35:20PM +0100, Johan Hovold wrote:
> > Since commit 557aaa7ffab6 ("ft232: support the ASYNC_LOW_LATENCY
> > flag") the FTDI driver has been using a receive latency-timer value of
> > 1 ms instead of the device default of 16 ms.
> > 
> > The latency timer is used to periodically empty a non-full receive
> > buffer, but a status header is always sent when the timer expires
> > including when the buffer is empty. This means that a two-byte bulk
> > message is received every millisecond also for an otherwise idle port as
> > long as it is open.
> > 
> > Let's restore the pre-2009 behaviour which reduces rate of status
> > messages to 1/16th (e.g. interrupt frequency drops from 1 kHz to 62.5
> > Hz) by not setting ASYNC_LOW_LATENCY by default.
> > 
> > Anyone willing to pay the price for the minimum-latency behaviour should
> > set the flag explicitly instead using the TIOCSSERIAL ioctl or a tool
> > such as setserial (e.g. setserial /dev/ttyUSB0 low_latency).
> > 
> > Note that since commit 0cbd81a9f6ba ("USB: ftdi_sio: remove
> > tty->low_latency") the ASYNC_LOW_LATENCY flag has no other effects but
> > to set a minimal latency timer.
> > 
> > Reported-by: Antoine Aubert 
> > Fixes: 557aaa7ffab6 ("ft232: support the ASYNC_LOW_LATENCY flag")
> > Cc: stable  # v2.6.31
> > Signed-off-by: Johan Hovold 
> > ---
> > 
> > Greg,
> > 
> > I've been aware of this overhead for a while, but never realised it was
> > actually a regression introduced in 2009.
> > 
> > Fixing something like this after such a long time obviously means
> > risking a regression for anyone who is now relying on the new default
> > behaviour instead. I still think it's reasonable in this case to restore
> > the earlier behaviour given the penalty everyone else is paying for a
> > minimal-latency behaviour that they likely do not need or want.
> > 
> > Whether this should go to stable is a different question. Perhaps the
> > stable tag is not warranted, and this should just be the default
> > behaviour going forward? What do you think?
> 
> I think the stable tag is warrented here.  Do you want me to take this
> patch now into my usb-linus tree, or will you include it in a pull
> request?

I'll include it in a pull request. I was gonna apply it for -next, but
if you prefer I can send it along with some new device ids I have queued
up for 4.10-rc?

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: serial: ftdi_sio: fix extreme low-latency setting

[Greg Kroah-Hartman]

On Wed, Jan 25, 2017 at 03:35:20PM +0100, Johan Hovold wrote:
> Since commit 557aaa7ffab6 ("ft232: support the ASYNC_LOW_LATENCY
> flag") the FTDI driver has been using a receive latency-timer value of
> 1 ms instead of the device default of 16 ms.
> 
> The latency timer is used to periodically empty a non-full receive
> buffer, but a status header is always sent when the timer expires
> including when the buffer is empty. This means that a two-byte bulk
> message is received every millisecond also for an otherwise idle port as
> long as it is open.
> 
> Let's restore the pre-2009 behaviour which reduces rate of status
> messages to 1/16th (e.g. interrupt frequency drops from 1 kHz to 62.5
> Hz) by not setting ASYNC_LOW_LATENCY by default.
> 
> Anyone willing to pay the price for the minimum-latency behaviour should
> set the flag explicitly instead using the TIOCSSERIAL ioctl or a tool
> such as setserial (e.g. setserial /dev/ttyUSB0 low_latency).
> 
> Note that since commit 0cbd81a9f6ba ("USB: ftdi_sio: remove
> tty->low_latency") the ASYNC_LOW_LATENCY flag has no other effects but
> to set a minimal latency timer.
> 
> Reported-by: Antoine Aubert 
> Fixes: 557aaa7ffab6 ("ft232: support the ASYNC_LOW_LATENCY flag")
> Cc: stable    # v2.6.31
> Signed-off-by: Johan Hovold 
> ---
> 
> Greg,
> 
> I've been aware of this overhead for a while, but never realised it was
> actually a regression introduced in 2009.
> 
> Fixing something like this after such a long time obviously means
> risking a regression for anyone who is now relying on the new default
> behaviour instead. I still think it's reasonable in this case to restore
> the earlier behaviour given the penalty everyone else is paying for a
> minimal-latency behaviour that they likely do not need or want.
> 
> Whether this should go to stable is a different question. Perhaps the
> stable tag is not warranted, and this should just be the default
> behaviour going forward? What do you think?

I think the stable tag is warrented here.  Do you want me to take this
patch now into my usb-linus tree, or will you include it in a pull
request?

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 1/4] usb: dbc: early driver for xhci debug capability

[Peter Zijlstra]

On Wed, Jan 25, 2017 at 08:27:38PM +0800, Lu Baolu wrote:
> In my driver, udelay() is mostly used to handle time out.
> 
> Xdbc hides most USB things in its firmware. Early printk driver only needs
> to setup the registers/data structures and wait until link ready or time out.
> Without udelay(), I have no means to convert the polling times into waiting
> time.

What is timeout and why? If there is an error other than !ready, I would
expect the hardware to inform you of this through another status bit,
no?

So why can't you poll indefinitely for either ready or error?

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] USB: serial: ftdi_sio: fix extreme low-latency setting

[Johan Hovold]

Since commit 557aaa7ffab6 ("ft232: support the ASYNC_LOW_LATENCY
flag") the FTDI driver has been using a receive latency-timer value of
1 ms instead of the device default of 16 ms.

The latency timer is used to periodically empty a non-full receive
buffer, but a status header is always sent when the timer expires
including when the buffer is empty. This means that a two-byte bulk
message is received every millisecond also for an otherwise idle port as
long as it is open.

Let's restore the pre-2009 behaviour which reduces rate of status
messages to 1/16th (e.g. interrupt frequency drops from 1 kHz to 62.5
Hz) by not setting ASYNC_LOW_LATENCY by default.

Anyone willing to pay the price for the minimum-latency behaviour should
set the flag explicitly instead using the TIOCSSERIAL ioctl or a tool
such as setserial (e.g. setserial /dev/ttyUSB0 low_latency).

Note that since commit 0cbd81a9f6ba ("USB: ftdi_sio: remove
tty->low_latency") the ASYNC_LOW_LATENCY flag has no other effects but
to set a minimal latency timer.

Reported-by: Antoine Aubert 
Fixes: 557aaa7ffab6 ("ft232: support the ASYNC_LOW_LATENCY flag")
Cc: stable  # v2.6.31
Signed-off-by: Johan Hovold 
---

Greg,

I've been aware of this overhead for a while, but never realised it was
actually a regression introduced in 2009.

Fixing something like this after such a long time obviously means
risking a regression for anyone who is now relying on the new default
behaviour instead. I still think it's reasonable in this case to restore
the earlier behaviour given the penalty everyone else is paying for a
minimal-latency behaviour that they likely do not need or want.

Whether this should go to stable is a different question. Perhaps the
stable tag is not warranted, and this should just be the default
behaviour going forward? What do you think?

Thanks,
Johan



 drivers/usb/serial/ftdi_sio.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
index b064fad8e3ee..4bd556d9307d 100644
--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -1805,8 +1805,6 @@ static int ftdi_sio_port_probe(struct usb_serial_port 
*port)
 
mutex_init(>cfg_lock);
 
-   priv->flags = ASYNC_LOW_LATENCY;
-
if (quirk && quirk->port_probe)
quirk->port_probe(priv);
 
-- 
2.10.2

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: dts: Odroid XU4: fix USB3.0 ports

[Krzysztof Kozlowski]

On Wed, Jan 25, 2017 at 3:48 PM, Marek Szyprowski
 wrote:
> Hi Krzysztof,
>
> On 2017-01-25 08:55, Krzysztof Kozlowski wrote:
>>
>> On Wed, Jan 25, 2017 at 7:51 AM, Anand Moon  wrote:
>>>
>>> On 24 January 2017 at 19:18, Richard Genoud 
>>> wrote:

 Since commit 2164a476205ccc ("usb: dwc3: set SUSPHY bit for all cores"),
 the USB ports on odroid-XU4 don't work anymore.

 Inserting an usb key (USB2.0) on the USB3.0 port result in:
 [ 64.488264] xhci-hcd xhci-hcd.2.auto: Port resume took longer than
 2 msec, port status = 0xc400fe3
 [   74.568156] xhci-hcd xhci-hcd.2.auto: xHCI host not responding to
 stop endpoint command.
 [   74.574806] xhci-hcd xhci-hcd.2.auto: Assuming host is dying, halting
 host.
 [   74.601970] xhci-hcd xhci-hcd.2.auto: HC died; cleaning up
 [   74.606276] usb 3-1: USB disconnect, device number 2
 [   74.613565] usb 4-1: USB disconnect, device number 2
 [   74.621208] usb usb3-port1: couldn't allocate usb_device
 NB: it's not related to USB2.0 devices, I get the same result with an
 USB3.0 device (SATA to USB3 for instance).
 NB2: it doesn't happen on an odriod-XU3 board, that doesn't have the
 realtek RTL8153 chip.

 If the lines:
  if (dwc->revision > DWC3_REVISION_194A)
  reg |= DWC3_GUSB3PIPECTL_SUSPHY;
 are commented out, the USB3.0 start working.

 For a full analyse: https://lkml.org/lkml/2017/1/18/678

 Felipe suggested that suspend should be disabled temporarily while
 what's wrong with DCW3 is figured out.

 Tested on Odroid XU4

 Suggested-by: Felipe Balbi 
 Tested-by: Richard Genoud 
 Signed-off-by: Richard Genoud 
 Cc: sta...@vger.kernel.org # 4.4+
 Fixes: 2164a476205ccc ("usb: dwc3: set SUSPHY bit for all cores")
 ---
   arch/arm/boot/dts/exynos5422-odroidxu4.dts | 9 +
   1 file changed, 9 insertions(+)

 diff --git a/arch/arm/boot/dts/exynos5422-odroidxu4.dts
 b/arch/arm/boot/dts/exynos5422-odroidxu4.dts
 index 2faf88627a48..f62dbd9b5ad3 100644
 --- a/arch/arm/boot/dts/exynos5422-odroidxu4.dts
 +++ b/arch/arm/boot/dts/exynos5422-odroidxu4.dts
 @@ -43,6 +43,15 @@
  status = "okay";
   };

 +_dwc3_0 {
 +   /*
 +* without that, usb devices are not recognized when
 +* they are plugged.
 +* cf: https://lkml.org/lkml/2017/1/18/678
 +*/
 +   snps,dis_u3_susphy_quirk;
 +};
 +
   _dwc3_1 {
  dr_mode = "host";
   };
 --
>>>
>>> Thanks for this patch.
>>> But could you consider moving this changes as below.
>>>
>>> https://lkml.org/lkml/2015/3/18/400
>>
>> The patch above (and other DTS patches from the set) was not even sent
>> to linux-samsung-soc nor to me... It is sad how easily one's work can
>> disappear. Also, it is really worthless to solve the same problem
>> twice.
>
>
> Well, they were sent about 2 years ago... and you were also working on this
> topic. ;)

Nope, I have never worked on this. That time I was in Korea so my
tasks were completely different. Later when I got back, I took for a
second U3 OTG which was not involving this thing.

>> Cc Marek and Bartlomiej,
>> Guys, do you want to continue with Robert's patch (linked above by
>> Anand)? If yes, please take the ownership (Robert's address is not
>> valid anymore). If not, I will take Richard's patch after
>> resubmission.
>
>
> Take Richard's patch because it has a bit more details describing why such
> quirk
> is needed.
>
> Richard: in Roberts patch there is also a quirk for USB 2.0 mode
> (snps,dis_u2_susphy_quirk). Could you check if it really needed?
>
> Maybe it would make sense to set those quirks for both DWC3 controllers, as
> this
> issue with PHY suspend seems to be a Exynos specific thing.

Okay,
Richard, please continue with your patch.

Best regards,
Krzysztof
--
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: NAPI on USB network drivers

[Eric Dumazet]

On Wed, 2017-01-25 at 09:39 +, Hayes Wang wrote:
> Oliver Neukum [mailto:oneu...@suse.com]
> > Sent: Wednesday, January 25, 2017 5:35 PM
> [...]
> > looking at r8152 I noticed that it uses NAPI. I never considered
> > this for the generic USB networking code as you cannot disable
> > interrupts for USB. Is it still worth it? What are the benefits?
> 
> You could use napi_gro_receive() and it influences the performance.

You also could use napi_complete_done() instead of napi_complete(), as
it allows users to tune the performance vs latency for GRO.

Looking at this driver, I do not see any limitation on the number of
skbs that can be pushed into tp->rx_queue.

I wonder if this queue can end up consuming all memory of a host under
stress.

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 
e1466b4d2b6c727148a884672bbd9593bf04b3ac..221df4a931b5c1073f1922d0fa0bbff158c73b7d
 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -1840,7 +1840,10 @@ static int rx_bottom(struct r8152 *tp, int budget)
stats->rx_packets++;
stats->rx_bytes += pkt_len;
} else {
-   __skb_queue_tail(>rx_queue, skb);
+   if (unlikely(skb_queue_len(>rx_queue) >= 
1000))
+   kfree_skb(skb);
+   else
+   __skb_queue_tail(>rx_queue, skb);
}
 
 find_next_rx:


--
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 -next] usb: chipidea: msm: Fix return value check in ci_hdrc_msm_probe()

[Wei Yongjun]

From: Wei Yongjun 

In case of error, the function devm_ioremap_resource() returns ERR_PTR()
and never returns NULL. The NULL test in the return value check should
be replaced with IS_ERR().

Fixes: 2fc305be364e ("usb: chipidea: msm: Mux over secondary phy at the
right time")
Signed-off-by: Wei Yongjun 
---
 drivers/usb/chipidea/ci_hdrc_msm.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/chipidea/ci_hdrc_msm.c 
b/drivers/usb/chipidea/ci_hdrc_msm.c
index f1ede79..0bdfcdc 100644
--- a/drivers/usb/chipidea/ci_hdrc_msm.c
+++ b/drivers/usb/chipidea/ci_hdrc_msm.c
@@ -218,8 +218,8 @@ static int ci_hdrc_msm_probe(struct platform_device *pdev)
 
res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
ci->base = devm_ioremap_resource(>dev, res);
-   if (!ci->base)
-   return -ENOMEM;
+   if (IS_ERR(ci->base))
+   return PTR_ERR(ci->base);
 
ci->rcdev.owner = THIS_MODULE;
ci->rcdev.ops = _hdrc_msm_reset_ops;

--
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 net v2 3/4] r8152: re-schedule napi for tx

[Eric Dumazet]

On Wed, 2017-01-25 at 16:13 +0800, Hayes Wang wrote:
> Re-schedule napi after napi_complete() for tx, if it is necessay.
> 
> In r8152_poll(), if the tx is completed after tx_bottom() and before
> napi_complete(), the scheduling of napi would be lost. Then, no
> one handles the next tx until the next napi_schedule() is called.
> 
> Signed-off-by: Hayes Wang 
> ---
>  drivers/net/usb/r8152.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
> index ec882be..45d168e 100644
> --- a/drivers/net/usb/r8152.c
> +++ b/drivers/net/usb/r8152.c
> @@ -1936,6 +1936,9 @@ static int r8152_poll(struct napi_struct *napi, int 
> budget)
>   napi_complete(napi);
>   if (!list_empty(>rx_done))
>   napi_schedule(napi);
> + else if (!skb_queue_empty(>tx_queue) &&
> +  !list_empty(>tx_free))
> + napi_schedule(>napi);

Why using >napi instead of napi here, as done 3 lines above ?



--
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] ARM: dts: Odroid XU4: fix USB3.0 ports

[Marek Szyprowski]

Hi Krzysztof,

On 2017-01-25 08:55, Krzysztof Kozlowski wrote:

On Wed, Jan 25, 2017 at 7:51 AM, Anand Moon  wrote:

On 24 January 2017 at 19:18, Richard Genoud  wrote:

Since commit 2164a476205ccc ("usb: dwc3: set SUSPHY bit for all cores"),
the USB ports on odroid-XU4 don't work anymore.

Inserting an usb key (USB2.0) on the USB3.0 port result in:
[   64.488264] xhci-hcd xhci-hcd.2.auto: Port resume took longer than 2 
msec, port status = 0xc400fe3
[   74.568156] xhci-hcd xhci-hcd.2.auto: xHCI host not responding to stop 
endpoint command.
[   74.574806] xhci-hcd xhci-hcd.2.auto: Assuming host is dying, halting host.
[   74.601970] xhci-hcd xhci-hcd.2.auto: HC died; cleaning up
[   74.606276] usb 3-1: USB disconnect, device number 2
[   74.613565] usb 4-1: USB disconnect, device number 2
[   74.621208] usb usb3-port1: couldn't allocate usb_device
NB: it's not related to USB2.0 devices, I get the same result with an USB3.0 
device (SATA to USB3 for instance).
NB2: it doesn't happen on an odriod-XU3 board, that doesn't have the realtek 
RTL8153 chip.

If the lines:
 if (dwc->revision > DWC3_REVISION_194A)
 reg |= DWC3_GUSB3PIPECTL_SUSPHY;
are commented out, the USB3.0 start working.

For a full analyse: https://lkml.org/lkml/2017/1/18/678

Felipe suggested that suspend should be disabled temporarily while
what's wrong with DCW3 is figured out.

Tested on Odroid XU4

Suggested-by: Felipe Balbi 
Tested-by: Richard Genoud 
Signed-off-by: Richard Genoud 
Cc: sta...@vger.kernel.org # 4.4+
Fixes: 2164a476205ccc ("usb: dwc3: set SUSPHY bit for all cores")
---
  arch/arm/boot/dts/exynos5422-odroidxu4.dts | 9 +
  1 file changed, 9 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5422-odroidxu4.dts 
b/arch/arm/boot/dts/exynos5422-odroidxu4.dts
index 2faf88627a48..f62dbd9b5ad3 100644
--- a/arch/arm/boot/dts/exynos5422-odroidxu4.dts
+++ b/arch/arm/boot/dts/exynos5422-odroidxu4.dts
@@ -43,6 +43,15 @@
 status = "okay";
  };

+_dwc3_0 {
+   /*
+* without that, usb devices are not recognized when
+* they are plugged.
+* cf: https://lkml.org/lkml/2017/1/18/678
+*/
+   snps,dis_u3_susphy_quirk;
+};
+
  _dwc3_1 {
 dr_mode = "host";
  };
--

Thanks for this patch.
But could you consider moving this changes as below.

https://lkml.org/lkml/2015/3/18/400

The patch above (and other DTS patches from the set) was not even sent
to linux-samsung-soc nor to me... It is sad how easily one's work can
disappear. Also, it is really worthless to solve the same problem
twice.


Well, they were sent about 2 years ago... and you were also working on this
topic. ;)


Cc Marek and Bartlomiej,
Guys, do you want to continue with Robert's patch (linked above by
Anand)? If yes, please take the ownership (Robert's address is not
valid anymore). If not, I will take Richard's patch after
resubmission.


Take Richard's patch because it has a bit more details describing why 
such quirk

is needed.

Richard: in Roberts patch there is also a quirk for USB 2.0 mode
(snps,dis_u2_susphy_quirk). Could you check if it really needed?

Maybe it would make sense to set those quirks for both DWC3 controllers, 
as this

issue with PHY suspend seems to be a Exynos specific thing.

Best regards
--
Marek Szyprowski, PhD
Samsung R Institute Poland

--
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: NAPI on USB network drivers

[Oliver Hartkopp]

On 01/25/2017 10:39 AM, Hayes Wang wrote:

Oliver Neukum [mailto:oneu...@suse.com]

Sent: Wednesday, January 25, 2017 5:35 PM

[...]

looking at r8152 I noticed that it uses NAPI. I never considered
this for the generic USB networking code as you cannot disable
interrupts for USB. Is it still worth it? What are the benefits?


You could use napi_gro_receive() and it influences the performance.


Another positive effect with NAPI is that you won't face out-of-order 
ethernet frames as you get with non-NAPI drivers, e.g. ax88179_178a


http://marc.info/?l=linux-can=148049063812807=2

We have the issue with CAN drivers where all USB drivers and >90% of the 
I/O mapped drivers do not use NAPI.


I wonder whether it makes sense to add NAPI to a driver which only has 
ONE RX buffer ... but when searching for a solution for o-o-o frames I 
was always pointed to NAPI.


Regards,
Oliver

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] usb: musb: Fix host mode error -71 regression

[Bin Liu]

On Wed, Jan 25, 2017 at 02:17:11PM +0100, Greg KH wrote:
> On Wed, Jan 25, 2017 at 06:59:47AM -0600, Bin Liu wrote:
> > On Wed, Jan 25, 2017 at 11:01:30AM +0100, Greg KH wrote:
> > > On Tue, Jan 24, 2017 at 09:18:57AM -0600, Bin Liu wrote:
> > > > From: Tony Lindgren 
> > > > 
> > > > Commit 467d5c980709 ("usb: musb: Implement session bit based runtime PM 
> > > > for
> > > > musb-core") started implementing musb generic runtime PM support by
> > > > introducing devctl register session bit based state control.
> > > > 
> > > > This caused a regression where if a USB mass storage device is connected
> > > > to a USB hub, we can get:
> > > > 
> > > > usb 1-1: reset high-speed USB device number 2 using musb-hdrc
> > > > usb 1-1: device descriptor read/64, error -71
> > > > usb 1-1.1: new high-speed USB device number 4 using musb-hdrc
> > > > 
> > > > This is because before the USB storage device is connected, musb is
> > > > in OTG_STATE_A_SUSPEND. And we currently only set need_finish_resume
> > > > in musb_stage0_irq() and the related code calling finish_resume_work
> > > > in musb_resume() and musb_runtime_resume() never gets called.
> > > > 
> > > > To fix the issue, we can call schedule_delayed_work() directly in
> > > > musb_stage0_irq() to have finish_resume_work run.
> > > > 
> > > > And we should no longer never get interrupts when when suspended.
> > > > We have changed musb to no longer need pm_runtime_irqsafe().
> > > > The need_finish_resume flag was added in commit 9298b4aad37e ("usb:
> > > > musb: fix device hotplug behind hub") and no longer applies as far
> > > > as I can tell. So let's just remove the earlier code that no longer
> > > > is needed.
> > > > 
> > > > Fixes: 467d5c980709 ("usb: musb: Implement session bit based
> > > > runtime PM for musb-core")
> > > > Reported-by: Bin Liu 
> > > > Signed-off-by: Tony Lindgren 
> > > > Signed-off-by: Bin Liu 
> > > > ---
> > > >  drivers/usb/musb/musb_core.c | 15 ++-
> > > >  drivers/usb/musb/musb_core.h |  1 -
> > > >  2 files changed, 2 insertions(+), 14 deletions(-)
> > > 
> > > As the problem showed up in 4.9, this should go into 4.9-stable, right?
> > 
> > Yes.
> 
> Great, please remember to add a cc: stable line for the patch next time
> so I don't have to do it manually...

Ahh, sorry about this. I was thinking about cc stable for a second, but
somehow I thought the 'Fixes:' will do it but now I realized it is
either 'Fixes:' + 'cc stable' or without 'Fixes:' + 'cc stable #'. I guess I was context switching too fast in my work... I will
ensure to double check whenever in doubt in future.

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 1/2] usb: musb: Fix host mode error -71 regression

[Greg KH]

On Wed, Jan 25, 2017 at 06:59:47AM -0600, Bin Liu wrote:
> On Wed, Jan 25, 2017 at 11:01:30AM +0100, Greg KH wrote:
> > On Tue, Jan 24, 2017 at 09:18:57AM -0600, Bin Liu wrote:
> > > From: Tony Lindgren 
> > > 
> > > Commit 467d5c980709 ("usb: musb: Implement session bit based runtime PM 
> > > for
> > > musb-core") started implementing musb generic runtime PM support by
> > > introducing devctl register session bit based state control.
> > > 
> > > This caused a regression where if a USB mass storage device is connected
> > > to a USB hub, we can get:
> > > 
> > > usb 1-1: reset high-speed USB device number 2 using musb-hdrc
> > > usb 1-1: device descriptor read/64, error -71
> > > usb 1-1.1: new high-speed USB device number 4 using musb-hdrc
> > > 
> > > This is because before the USB storage device is connected, musb is
> > > in OTG_STATE_A_SUSPEND. And we currently only set need_finish_resume
> > > in musb_stage0_irq() and the related code calling finish_resume_work
> > > in musb_resume() and musb_runtime_resume() never gets called.
> > > 
> > > To fix the issue, we can call schedule_delayed_work() directly in
> > > musb_stage0_irq() to have finish_resume_work run.
> > > 
> > > And we should no longer never get interrupts when when suspended.
> > > We have changed musb to no longer need pm_runtime_irqsafe().
> > > The need_finish_resume flag was added in commit 9298b4aad37e ("usb:
> > > musb: fix device hotplug behind hub") and no longer applies as far
> > > as I can tell. So let's just remove the earlier code that no longer
> > > is needed.
> > > 
> > > Fixes: 467d5c980709 ("usb: musb: Implement session bit based
> > > runtime PM for musb-core")
> > > Reported-by: Bin Liu 
> > > Signed-off-by: Tony Lindgren 
> > > Signed-off-by: Bin Liu 
> > > ---
> > >  drivers/usb/musb/musb_core.c | 15 ++-
> > >  drivers/usb/musb/musb_core.h |  1 -
> > >  2 files changed, 2 insertions(+), 14 deletions(-)
> > 
> > As the problem showed up in 4.9, this should go into 4.9-stable, right?
> 
> Yes.

Great, please remember to add a cc: stable line for the patch next time
so I don't have to do it manually...
--
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: musb: Fix host mode error -71 regression

[Bin Liu]

On Wed, Jan 25, 2017 at 11:01:30AM +0100, Greg KH wrote:
> On Tue, Jan 24, 2017 at 09:18:57AM -0600, Bin Liu wrote:
> > From: Tony Lindgren 
> > 
> > Commit 467d5c980709 ("usb: musb: Implement session bit based runtime PM for
> > musb-core") started implementing musb generic runtime PM support by
> > introducing devctl register session bit based state control.
> > 
> > This caused a regression where if a USB mass storage device is connected
> > to a USB hub, we can get:
> > 
> > usb 1-1: reset high-speed USB device number 2 using musb-hdrc
> > usb 1-1: device descriptor read/64, error -71
> > usb 1-1.1: new high-speed USB device number 4 using musb-hdrc
> > 
> > This is because before the USB storage device is connected, musb is
> > in OTG_STATE_A_SUSPEND. And we currently only set need_finish_resume
> > in musb_stage0_irq() and the related code calling finish_resume_work
> > in musb_resume() and musb_runtime_resume() never gets called.
> > 
> > To fix the issue, we can call schedule_delayed_work() directly in
> > musb_stage0_irq() to have finish_resume_work run.
> > 
> > And we should no longer never get interrupts when when suspended.
> > We have changed musb to no longer need pm_runtime_irqsafe().
> > The need_finish_resume flag was added in commit 9298b4aad37e ("usb:
> > musb: fix device hotplug behind hub") and no longer applies as far
> > as I can tell. So let's just remove the earlier code that no longer
> > is needed.
> > 
> > Fixes: 467d5c980709 ("usb: musb: Implement session bit based
> > runtime PM for musb-core")
> > Reported-by: Bin Liu 
> > Signed-off-by: Tony Lindgren 
> > Signed-off-by: Bin Liu 
> > ---
> >  drivers/usb/musb/musb_core.c | 15 ++-
> >  drivers/usb/musb/musb_core.h |  1 -
> >  2 files changed, 2 insertions(+), 14 deletions(-)
> 
> As the problem showed up in 4.9, this should go into 4.9-stable, right?

Yes.

> 
> thanks,
> 
> greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 1/4] usb: dbc: early driver for xhci debug capability

[Lu Baolu]

Hi,

On 01/25/2017 05:57 PM, Peter Zijlstra wrote:
> On Wed, Jan 25, 2017 at 10:23:55AM +0100, Ingo Molnar wrote:
>> * Lu Baolu  wrote:
>>
 Hiding essentially an early udelay() implementation in an early-printk 
 driver is 
 ugly and counterproductive.
>> Yeah - so could we do this in a more generic fashion, not in the 
>> early-printk 
>> driver but in core x86 code?
> So ideally early_printk() would not depend on udelay() being setup.
>
> In fact, ideally early_printk() wouldn't even use udelay -- this very
> much includes its own copy.
>
> Why is udelay() required? Can't the thing simply poll its own register
> state to wait for completion?

In my driver, udelay() is mostly used to handle time out.

Xdbc hides most USB things in its firmware. Early printk driver only needs
to setup the registers/data structures and wait until link ready or time out.
Without udelay(), I have no means to convert the polling times into waiting
time.

Best regards,
Lu Baolu

>
> This all sounds like xdbc cruft is still unreliably garbage..
>

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 1/4] usb: dbc: early driver for xhci debug capability

[Lu Baolu]

Hi,

On 01/25/2017 05:23 PM, Ingo Molnar wrote:
> * Lu Baolu  wrote:
>
>>> Hiding essentially an early udelay() implementation in an early-printk 
>>> driver is 
>>> ugly and counterproductive.
>> Sure. How about below change?
>>
>> diff --git a/drivers/usb/early/xhci-dbc.c b/drivers/usb/early/xhci-dbc.c
>> index d3f0c84..940989e 100644
>> --- a/drivers/usb/early/xhci-dbc.c
>> +++ b/drivers/usb/early/xhci-dbc.c
>> @@ -587,6 +587,35 @@ static int xdbc_bulk_transfer(void *data, int size, 
>> bool read)
>> return size;
>>  }
>>  
>> +static void __init xdbc_udelay_calibration(void)
>> +{
>> +   unsigned long lpj = 0;
>> +   unsigned int tsc_khz, cpu_khz;
>> +
>> +   if (!boot_cpu_has(X86_FEATURE_TSC))
>> +   goto calibration_out;
>> +
>> +   cpu_khz = x86_platform.calibrate_cpu();
>> +   tsc_khz = x86_platform.calibrate_tsc();
>> +
>> +   if (tsc_khz == 0)
>> +   tsc_khz = cpu_khz;
>> +   else if (abs(cpu_khz - tsc_khz) * 10 > tsc_khz)
>> +   cpu_khz = tsc_khz;
>> +
>> +   if (!tsc_khz)
>> +   goto calibration_out;
>> +
>> +   lpj = tsc_khz * 1000;
>> +   do_div(lpj, HZ);
>> +
>> +calibration_out:
>> +   if (!lpj)
>> +   lpj = 1 << 22;
>> +
>> +   loops_per_jiffy = lpj;
>> +}
>> +
>>  static int __init xdbc_early_setup(void)
>>  {
>> int ret;
>> @@ -686,6 +715,8 @@ int __init early_xdbc_parse_parameter(char *s)
>> }
>> xdbc.xdbc_reg = (struct xdbc_regs __iomem *)(xdbc.xhci_base + 
>> offset);
>>  
>> +   xdbc_udelay_calibration();
>> +
>> return 0;
>>  }
> Yeah - so could we do this in a more generic fashion, not in the early-printk 
> driver but in core x86 code?
>

Sure. I will move this to arch/x86/kernel/setup.c.

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

[PATCH v3] ARM: davinci: Make the usb20 clock available to PM runtime

[Alexandre Bailon]

Since USB20 subsystem uses just one clock, there is no need of a con_id,
so we are using NULL.

Signed-off-by: Alexandre Bailon 
Suggested-by: Sekhar Nori 
---
 arch/arm/mach-davinci/da830.c | 2 +-
 arch/arm/mach-davinci/da850.c | 2 +-
 arch/arm/mach-davinci/usb-da8xx.c | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-davinci/da830.c b/arch/arm/mach-davinci/da830.c
index 073c458..2cfd9d7 100644
--- a/arch/arm/mach-davinci/da830.c
+++ b/arch/arm/mach-davinci/da830.c
@@ -412,7 +412,7 @@ static struct clk_lookup da830_clks[] = {
CLK("davinci-mcasp.0",  NULL,   _clk),
CLK("davinci-mcasp.1",  NULL,   _clk),
CLK("davinci-mcasp.2",  NULL,   _clk),
-   CLK("musb-da8xx",   "usb20",_clk),
+   CLK("musb-da8xx",   NULL,   _clk),
CLK(NULL,   "aemif",_clk),
CLK(NULL,   "aintc",_clk),
CLK(NULL,   "secu_mgr", _mgr_clk),
diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
index 9780829..5fe32ae 100644
--- a/arch/arm/mach-davinci/da850.c
+++ b/arch/arm/mach-davinci/da850.c
@@ -559,7 +559,7 @@ static struct clk_lookup da850_clks[] = {
CLK("ti-aemif", NULL,   _clk),
CLK("davinci-nand.0",   "aemif",_nand_clk),
CLK("ohci-da8xx",   "usb11",_clk),
-   CLK("musb-da8xx",   "usb20",_clk),
+   CLK("musb-da8xx",   NULL,   _clk),
CLK("spi_davinci.0",NULL,   _clk),
CLK("spi_davinci.1",NULL,   _clk),
CLK("vpif", NULL,   _clk),
diff --git a/arch/arm/mach-davinci/usb-da8xx.c 
b/arch/arm/mach-davinci/usb-da8xx.c
index 9a6af0b..9b66768 100644
--- a/arch/arm/mach-davinci/usb-da8xx.c
+++ b/arch/arm/mach-davinci/usb-da8xx.c
@@ -275,7 +275,7 @@ int __init da8xx_register_usb20_phy_clk(bool 
use_usb_refclkin)
struct clk *parent;
int ret;
 
-   usb20_clk = clk_get(_usb20_dev.dev, "usb20");
+   usb20_clk = clk_get(_usb20_dev.dev, NULL);
ret = PTR_ERR_OR_ZERO(usb20_clk);
if (ret)
return ret;
-- 
2.10.2

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH v2 28/37] usb: host: xhci: combine event TRB completion debugging messages

[David Laight]

From: Janusz Dziedzic
> Sent: 24 January 2017 12:06
> On 23 January 2017 at 13:20, Mathias Nyman
>  wrote:
> > From: Felipe Balbi 
> >
> > If we just provide a helper to convert completion code to string, we can
> > combine all debugging messages into a single print.
> >
> > [keep the old debug messages, for warn and grep -Mathias]
> > Signed-off-by: Felipe Balbi 
> > Signed-off-by: Mathias Nyman 
> > ---
> >  drivers/usb/host/xhci.h | 80 
> > +
> >  1 file changed, 80 insertions(+)
> >
> > diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
> > index aa63e38..ebdd920 100644
> > --- a/drivers/usb/host/xhci.h
> > +++ b/drivers/usb/host/xhci.h
> > @@ -1097,6 +1097,86 @@ struct xhci_transfer_event {
> >  #define COMP_SECONDARY_BANDWIDTH_ERROR 35
> >  #define COMP_SPLIT_TRANSACTION_ERROR   36
> >
> > +static inline const char *xhci_trb_comp_code_string(u8 status)
> > +{
> 
> BTW, maybe in the future we should use enum for status
> and next:
> 
> #define C2S(x) case x: return #x
> static inline const char *xhci_trb_comp_code_string(enum
> xhci_trb_comp_code code)
> {
> switch(code) {
> C2S(COMP_INVALID);
> C2S(COMP_SUCCESS);
> ...
>default:
> return "Unknown!!";
> }
> }
> #undef C2S

A more interesting 'trick' is to get cpp to expand a macro in different ways.
So you have (if I type it correctly):

#define XHCI_ERRS(x) \
x(COMP_SUCCESS), 0, "success") \
... \
x(COMP_SECONDARY_BANDWIDTH_ERROR, 35, "secondary bandwidth error") \
x(COMP_SPLIT_TRANSACTION_ERROR,   36, "split transaction error") \

#define X(tag, val, str) tag = val,
enum (XHCI_ERRS(X) COMP_NUM_ERRS);
#undef X

const char * xhci_trb_comp_code_string(unsigned int code)
{
#define X(tag, val, str) [tag] = str,
static const char *const errmsg[] = { XHCI_ERRS(X) };
#undef X
if (code < ARRAY_SIZE(errmsg))
return errmsg[code];
...
}

/* or */
const char * xhci_trb_comp_code_string(unsigned int code)
{
#define X(tag, val, str) case tag: return str;
switch (code) {
XHCI_ERRS(X);
default:
...
#undef X

This all has the advantage of keeping the error number and message text
on the same line of the header file.

David

Re: usb: gadget: Kernel panic (NULL pointer dereference) when using fsl_udc2_core on i.MX31 PDK

[Felipe Balbi]

Hi,

Magnus Lilja  writes:
> I tried the fsl_udc_core gadget driver on the i.MX31 PDK board and 
> got a
> kernel panic (NULL pointer dereference) when connecting the USB 
> cable. I
> had the g_serial module loaded as well.
>
> The NULL pointer panic comes from gadget/udc/core.c
> usb_gadget_giveback_request() which calls req->complete() and in some
> cases req->complete is NULL.
>
> Commit 304f7e5e1d08 ("usb: gadget: Refactor request completion") 
> changed
> fsl_udc2_core.c (and several other files) and in fsl_udc2_core.c a 
> check
> that req->complete is non-NULL was removed:
>
> --- a/drivers/usb/gadget/udc/fsl_udc_core.c
> +++ b/drivers/usb/gadget/udc/fsl_udc_core.c
> @@ -197,10 +197,8 @@ __acquires(ep->udc->lock)
>  ep->stopped = 1;
>
>  spin_unlock(>udc->lock);
> -   /* complete() is from gadget layer,
> -* eg fsg->bulk_in_complete() */
> -   if (req->req.complete)
> -   req->req.complete(>ep, >req);
> +
> +   usb_gadget_giveback_request(>ep, >req);
>
>  spin_lock(>udc->lock);
>  ep->stopped = stopped;
>
> If I re-introduce the check (either in fsl_udc_core.c or core.c) at
> least USB gadget operation using g_serial seems to work just fine.
>
> I don't know the logic in detail to understand whether this is a 
> proper
> fix or if there is some other more problem with the fls_udc_core 
> driver.
> Does anyone have input in this matter?
>
> I can produce a proper patch that fixes this problem by re-introducing
> the check (in either fsl_udc_core.c or core.c) if that is a proper
> solution and I can also assist in testing other fixes to the problem.

 ->complete() is supposed to be mandatory. Which gadget do you have that
 ->doesn't set ->complete() to a valid function pointer?
>>>
>>> I'm modprobing g_serial so the following modules are loaded (using my 
>>> patch):
>>>
>>> ~ # lsmod
>>> usb_f_acm
>>> u_serial
>>> g_serial
>>> libcomposite
>>> configfs
>>> fsl_usb2_udc
>>
>> okay, can you figure out which request is coming without ->complete()
>> set? To which endpoint is this request being queued? It would be nice to
>> know these details. Maybe this is an old bug which ought to be fixed.
>
> Sure, I can try figure that out. Any input to make the debug of the
> faster is appreciated if you have any.

 well, the easiest way is to add something like:

 if (!req->complete)
 dump_stack();

 to fsl udc driver. Then you would know who queued the request without
 ->complete. A slightly better approach would be to:

 if (WARN(!req->complete,
 "%s: queueing request without ->complete\n", ep->name))
 return;

 Or something like that.
>>>
>>> Well, I think I found it.
>>>
>>> fsl_udc_core.c:ep0_prime_status() sets req->req.complete = NULL before
>>> it queues a transfer and my printk()'s indicate that this is indeed
>>> the offending function.
>>>
>>> fsl_udc_core.c:ch9getstatus() also sets complete to NULL but in my
>>> tests right now I haven't seen that one.
>>>
>>> So it's an internal problem in the fsl_udc_core.c file.
>>
>> seems like it. It's rather odd that fsl_udc doesn't wanna know about
>> completion of Status stage. Oh well, I guess in this case it doesn't
>> matter if you add a complete function or reinstate the previous check
>> for valid complete.
>>
>> If you decide to reinstate the check, please add a comment above the
>> check explaining that fsl_udc itself queues requests with NULL
>> ->complete().
>>
>> I must say, however, that I would suggest adding a complete callback
>> since that will help us BUG with NULL pointer deref on bad gadget
>> drivers ;-)
>
> I can do that. Such a complete() callback function would be a no-op
> then I assume (with a comment in it why it is a no-op).

that's right :-)

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCHv15 3/3] usb: typec: add driver for Intel Whiskey Cove PMIC USB Type-C PHY

[Felipe Balbi]

Hi,

Heikki Krogerus  writes:
>> Heikki Krogerus  writes:
>> >> > +   wcove->cap.prefer_role = TYPEC_NO_PREFERRED_ROLE;
>> >> 
>> >> we have a slight problem here that affects users of this particular
>> >> driver. Well, more specifically, it affects Intel Joule.
>> >> 
>> >> Because of the way ASL was written and the way Intel's DRD mux works, we
>> >> don't have a state which means "don't route USB signals to either Host
>> >> or Peripheral". Because of that, when we plug the type-c cable either
>> >> XHCI or dwc3 will have noise coming into the IP.
>> >> 
>> >> If default mode ends up being peripheral we have two possible problems
>> >> here:
>> >> 
>> >> i) device-to-device cable assembly
>> >> 
>> >>   this won't be a big problem because we will just negotiate who's
>> >>   Sink and who's Source then change mux on one side.
>> >> 
>> >> ii) lack of disconnect IRQ on dwc3
>> >> 
>> >>   Because of how ASL was written, when we unplug the cable, mux's
>> >>   VBUS_VALID bit won't be cleared which means dwc3 won't generate
>> >>   disconnect interrupt. This means that upon cable reconnect (!!)
>> >>   we will run ->disconnect() callback. The result is that dwc3
>> >>   will never runtime suspend.
>> >> 
>> >> If default mode ends up being host we're possibly going to end up with a
>> >> host-to-host cable assembly. Now this can cause 2 issues:
>> >> 
>> >> i) port config error
>> >> 
>> >>   host-to-host is not a supported cable assembly. While we see
>> >>   errors on dmesg, eventually type-c negotiation will happen and
>> >>   nothing will actually break.
>> >> 
>> >> ii) DbC can start on the other end of the cable
>> >> 
>> >>   Now this was really surprising to me. When testing this on Intel
>> >>   Joule and plugging Intel Joule straight to my PC's roothub port,
>> >>   I noticed Joule ended up being host and my Desktop () became
>> >>   a peripheral enumerated by Joule. I can only assume this is DbC
>> >>   somehow being started.
>> >> 
>> >>   The only way to have Joule become a peripheral is to connect it
>> >>   through an external hub to my PC. Odd, ain't it?
>> >> 
>> >> I'm not sure how to solve this problem apart from modifying BIOS :-( Any
>> >> ideas?
>> >
>> > I don't think there is any other way to fix this expect modifying BIOS.
>> >
>> > The VBUS_VALID bit would need to be handled separate in ASL.
>> 
>> That means we need some method for figuring out VBUS is above 4.4V.
>
> The VBUSOK bit means VBUS valid.

okay, good. Then we're settled.

-- 
balbi


signature.asc
Description: PGP signature

[PATCH v3] usb: dwc3: gadget: read IN ep FIFO size from HW

[Felipe Balbi]

Instead of assuming all IN endpoints support 1024
bytes, let's read the actual value from HW and pass
that to gadget API.

Signed-off-by: Felipe Balbi 
---

changes since v2:
- Actually commit "ret" variable :-s

changes since v1:
- Fix a bug where we weren't setting endpoints.ops nor addding
  EP to ep_list.

 drivers/usb/dwc3/gadget.c | 38 ++
 1 file changed, 38 insertions(+)

diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 0a664d8eba3f..4db97ecae885 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -1967,6 +1967,44 @@ static int dwc3_gadget_init_hw_endpoints(struct dwc3 
*dwc,
dep->endpoint.ops = _gadget_ep0_ops;
if (!epnum)
dwc->gadget.ep0 = >endpoint;
+   } else if (direction) {
+   int mdwidth;
+   int size;
+   int ret;
+   int num;
+
+   mdwidth = DWC3_MDWIDTH(dwc->hwparams.hwparams0);
+   /* MDWIDTH is represented in bits, we need it in bytes 
*/
+   mdwidth /= 8;
+
+   size = dwc3_readl(dwc->regs, DWC3_GTXFIFOSIZ(i));
+   size = DWC3_GTXFIFOSIZ_TXFDEF(size);
+
+   /* FIFO Depth is in MDWDITH bytes. Multiply */
+   size *= mdwidth;
+
+   num = size / 1024;
+   if (num == 0)
+   num = 1;
+
+   /*
+* FIFO sizes account an extra MDWIDTH * (num + 1) 
bytes for
+* internal overhead. We don't really know how these 
are used,
+* but documentation say it exists.
+*/
+   size -= mdwidth * (num + 1);
+   size /= num;
+
+   usb_ep_set_maxpacket_limit(>endpoint, size);
+
+   dep->endpoint.max_streams = 15;
+   dep->endpoint.ops = _gadget_ep_ops;
+   list_add_tail(>endpoint.ep_list,
+   >gadget.ep_list);
+
+   ret = dwc3_alloc_trb_pool(dep);
+   if (ret)
+   return ret;
} else {
int ret;
 
-- 
2.11.0.295.gd7dffce1ce

--
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: [PATCHv15 3/3] usb: typec: add driver for Intel Whiskey Cove PMIC USB Type-C PHY

[Heikki Krogerus]

On Wed, Jan 25, 2017 at 12:27:28PM +0200, Felipe Balbi wrote:
> 
> Hi,
> 
> Heikki Krogerus  writes:
> >> > +wcove->cap.prefer_role = TYPEC_NO_PREFERRED_ROLE;
> >> 
> >> we have a slight problem here that affects users of this particular
> >> driver. Well, more specifically, it affects Intel Joule.
> >> 
> >> Because of the way ASL was written and the way Intel's DRD mux works, we
> >> don't have a state which means "don't route USB signals to either Host
> >> or Peripheral". Because of that, when we plug the type-c cable either
> >> XHCI or dwc3 will have noise coming into the IP.
> >> 
> >> If default mode ends up being peripheral we have two possible problems
> >> here:
> >> 
> >> i) device-to-device cable assembly
> >> 
> >>this won't be a big problem because we will just negotiate who's
> >>Sink and who's Source then change mux on one side.
> >> 
> >> ii) lack of disconnect IRQ on dwc3
> >> 
> >>Because of how ASL was written, when we unplug the cable, mux's
> >>VBUS_VALID bit won't be cleared which means dwc3 won't generate
> >>disconnect interrupt. This means that upon cable reconnect (!!)
> >>we will run ->disconnect() callback. The result is that dwc3
> >>will never runtime suspend.
> >> 
> >> If default mode ends up being host we're possibly going to end up with a
> >> host-to-host cable assembly. Now this can cause 2 issues:
> >> 
> >> i) port config error
> >> 
> >>host-to-host is not a supported cable assembly. While we see
> >>errors on dmesg, eventually type-c negotiation will happen and
> >>nothing will actually break.
> >> 
> >> ii) DbC can start on the other end of the cable
> >> 
> >>Now this was really surprising to me. When testing this on Intel
> >>Joule and plugging Intel Joule straight to my PC's roothub port,
> >>I noticed Joule ended up being host and my Desktop () became
> >>a peripheral enumerated by Joule. I can only assume this is DbC
> >>somehow being started.
> >> 
> >>The only way to have Joule become a peripheral is to connect it
> >>through an external hub to my PC. Odd, ain't it?
> >> 
> >> I'm not sure how to solve this problem apart from modifying BIOS :-( Any
> >> ideas?
> >
> > I don't think there is any other way to fix this expect modifying BIOS.
> >
> > The VBUS_VALID bit would need to be handled separate in ASL.
> 
> That means we need some method for figuring out VBUS is above 4.4V.

The VBUSOK bit means VBUS valid.


-- 
heikki
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 00/24] usb: dwc2: Rework params, FIFO, and other changes

[Felipe Balbi]

Hi,

John Youn  writes:
> On 1/23/2017 2:52 PM, John Youn wrote:
>> Hi Felipe,
>>
>> This is a consolidation, rebase, and resend of several dwc2 patch
>> series that were submitted to this list in the past month or so. See
>> v2 [1] of this series for a summary.
>>
>> This latest revision is rebased to apply cleanly to your latest
>> testing/next.
>>
>> This series also rebases the FIFO series from Sevak [2]. So there's no
>> need to pick that up separately.
>>
>> The first 4 patches revert commits that were mistakenly added to your
>> next branch.
>>
>> Regards,
>> John
>>
>> [1] https://www.spinics.net/lists/linux-usb/msg152258.html
>> [2] https://www.spinics.net/lists/linux-usb/msg152322.html
>>
>
>
> Hi Felipe,
>
> Thanks for adding to your testing/next. It looks good so far.
>
> Can you rebase it on -rc5 or later? There might be merge conflicts
> otherwise

it's too late for rebased. I need to freeze my branch so I can send it
Greg. We will handle conflicts manually, should they come.

-- 
balbi


signature.asc
Description: PGP signature

Re: functionfs on dwc3, xhci host: endpoint cannot be used in both directions ?

[Felipe Balbi]

Hi,

Vincent Pelletier  writes:
> Hello,
>
> On Tue, 24 Jan 2017 11:02:10 +0200, Felipe Balbi
>  wrote:
>> that's correct. Maybe I should always set bulk capability. Thanks for
>> catching that, I'll send v2 shortly.
>
> I just tested v2 from your branch, but the original "else" contains
> several inits which are now skipped for IN endpoints, making them
> unavailable and causing a NULL pointer dereference in
> dwc3_ep_trb_ring_show.
>
> Replacing the original usb_ep_set_maxpacket_limit call with:
>   int size;
>   if (direction) {
> ...
> size /= num;
>   }
>   else {
> size = 1024;
>   }
>   usb_ep_set_maxpacket_limit(>endpoint, size);
> seems to do the trick.

right, I fixed that up yesterday night and just sent another version.

> Also, I noticed there are two (consistent) macros to extract MDWIDTH,
> each used once:
> core.h:#define DWC3_GHWPARAMS0_MDWIDTH(n)   (((n) >> 8) & 0xff)
> core.h:#define DWC3_MDWIDTH(n)  (((n) & 0xff00) >> 8)
> Neither a bug nor new, but I thought I should mention it.

Thanks, I'll clean that up later :-)

-- 
balbi


signature.asc
Description: PGP signature

[PATCH v2] usb: dwc3: gadget: read IN ep FIFO size from HW

[Felipe Balbi]

Instead of assuming all IN endpoints support 1024
bytes, let's read the actual value from HW and pass
that to gadget API.

Signed-off-by: Felipe Balbi 
---
changes since v1:
- Fix a bug where we weren't setting endpoints.ops nor addding
  EP to ep_list.

 drivers/usb/dwc3/gadget.c | 37 +
 1 file changed, 37 insertions(+)

diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 0a664d8eba3f..891373edb29a 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -1967,6 +1967,43 @@ static int dwc3_gadget_init_hw_endpoints(struct dwc3 
*dwc,
dep->endpoint.ops = _gadget_ep0_ops;
if (!epnum)
dwc->gadget.ep0 = >endpoint;
+   } else if (direction) {
+   int mdwidth;
+   int size;
+   int num;
+
+   mdwidth = DWC3_MDWIDTH(dwc->hwparams.hwparams0);
+   /* MDWIDTH is represented in bits, we need it in bytes 
*/
+   mdwidth /= 8;
+
+   size = dwc3_readl(dwc->regs, DWC3_GTXFIFOSIZ(i));
+   size = DWC3_GTXFIFOSIZ_TXFDEF(size);
+
+   /* FIFO Depth is in MDWDITH bytes. Multiply */
+   size *= mdwidth;
+
+   num = size / 1024;
+   if (num == 0)
+   num = 1;
+
+   /*
+* FIFO sizes account an extra MDWIDTH * (num + 1) 
bytes for
+* internal overhead. We don't really know how these 
are used,
+* but documentation say it exists.
+*/
+   size -= mdwidth * (num + 1);
+   size /= num;
+
+   usb_ep_set_maxpacket_limit(>endpoint, size);
+
+   dep->endpoint.max_streams = 15;
+   dep->endpoint.ops = _gadget_ep_ops;
+   list_add_tail(>endpoint.ep_list,
+   >gadget.ep_list);
+
+   ret = dwc3_alloc_trb_pool(dep);
+   if (ret)
+   return ret;
} else {
int ret;
 
-- 
2.11.0.295.gd7dffce1ce

--
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 v5 0/5] usb: musb: da8xx: Add DMA support

[Alexandre Bailon]

This series update MUSB driver to add DMA support to DA8xx.
It should be applied on top of
"[PATCH v3 0/3] usb: musb: cppi41: Add a way to manage DMA irq" but
"[PATCH v3 0/3] dmaengine: cppi41: Add dma support to da8xx" and
"[PATCH] arm: davinci: Make the usb20 clock available to PM runtime"
are required to make it work.

Changes in v5:
- Fix a typo in commit message of patch 4

Changes in v4:
- Update and clarify the commit message of patch 5
- Fix the typo in patch 3

Changes in v3:
- Remove PM runtime callbacks.
  I have update arch/arm/mach-davinci/pm_domain.c to let PM runtime control
  the usb20 clock.
- Only use PM runtime sync operation.

Changes in v2:
- Clock and IRQ management has been moved to MUSB DA8xx glue
  (was in CPPI 4.1 driver)
- I have added a partial support PM runtime. The goal was to use PM
  runtime to manage clock of MUSB and CPPI 4.1 (they use the same clock).
- CPPI 4.1 is now achild of MUSB DA8xx glue.

Alexandre Bailon (5):
  usb: musb: da8xx: Remove CPPI 3.0 quirk and methods
  usb: musb: Use shared irq
  usb: musb: Add support of CPPI 4.1 DMA controller to DA8xx
  usb: musb: musb_cppi41: Workaround DMA stall issue during teardown
  usb: musb: da8xx: Add a primary support of PM runtime

 drivers/usb/musb/Kconfig   |  4 +--
 drivers/usb/musb/da8xx.c   | 60 +++---
 drivers/usb/musb/musb_core.c   |  2 +-
 drivers/usb/musb/musb_core.h   |  1 +
 drivers/usb/musb/musb_cppi41.c |  4 +++
 5 files changed, 47 insertions(+), 24 deletions(-)

-- 
2.10.2

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 1/5] usb: musb: da8xx: Remove CPPI 3.0 quirk and methods

[Alexandre Bailon]

DA8xx driver is registering and using the CPPI 3.0 DMA controller but
actually, the DA8xx has a CPPI 4.1 DMA controller.
Remove the CPPI 3.0 quirk and methods.

Fixes: f8e9f34f80a2 ("usb: musb: Fix up DMA related macros")
Fixes: 7f6283ed6fe8 ("usb: musb: Set up function pointers for DMA")
Signed-off-by: Alexandre Bailon 
Acked-by: Sergei Shtylyov 
Acked-by: Tony Lindgren 
---
 drivers/usb/musb/da8xx.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/usb/musb/da8xx.c b/drivers/usb/musb/da8xx.c
index e89708d..cd3d763 100644
--- a/drivers/usb/musb/da8xx.c
+++ b/drivers/usb/musb/da8xx.c
@@ -458,15 +458,11 @@ static inline u8 get_vbus_power(struct device *dev)
 }
 
 static const struct musb_platform_ops da8xx_ops = {
-   .quirks = MUSB_DMA_CPPI | MUSB_INDEXED_EP,
+   .quirks = MUSB_INDEXED_EP,
.init   = da8xx_musb_init,
.exit   = da8xx_musb_exit,
 
.fifo_mode  = 2,
-#ifdef CONFIG_USB_TI_CPPI_DMA
-   .dma_init   = cppi_dma_controller_create,
-   .dma_exit   = cppi_dma_controller_destroy,
-#endif
.enable = da8xx_musb_enable,
.disable= da8xx_musb_disable,
 
-- 
2.10.2

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 2/5] usb: musb: Use shared irq

[Alexandre Bailon]

In the DA8xx, USB and CPPI 4.1 are sharing the same interrupt line.
Update the driver to request a shared irq.

Signed-off-by: Alexandre Bailon 
---
 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 fca288bb..cf40adf 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -2329,7 +2329,7 @@ musb_init_controller(struct device *dev, int nIrq, void 
__iomem *ctrl)
setup_timer(>otg_timer, musb_otg_timer_func, (unsigned long) 
musb);
 
/* attach to the IRQ */
-   if (request_irq(nIrq, musb->isr, 0, dev_name(dev), musb)) {
+   if (request_irq(nIrq, musb->isr, IRQF_SHARED, dev_name(dev), musb)) {
dev_err(dev, "request_irq %d failed!\n", nIrq);
status = -ENODEV;
goto fail3;
-- 
2.10.2

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 4/5] usb: musb: musb_cppi41: Workaround DMA stall issue during teardown

[Alexandre Bailon]

The DMA may hang up if a teardown is initiated while an endpoint is still
active (Advisory 2.3.27 of DA8xx errata).
To workaround this issue, add a delay before to initiate the teardown.

Signed-off-by: Alexandre Bailon 
---
 drivers/usb/musb/da8xx.c   | 2 +-
 drivers/usb/musb/musb_core.h   | 1 +
 drivers/usb/musb/musb_cppi41.c | 4 
 3 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/musb/da8xx.c b/drivers/usb/musb/da8xx.c
index d279438..d87fb9b 100644
--- a/drivers/usb/musb/da8xx.c
+++ b/drivers/usb/musb/da8xx.c
@@ -483,7 +483,7 @@ da8xx_dma_controller_create(struct musb *musb, void __iomem 
*base)
 #endif
 
 static const struct musb_platform_ops da8xx_ops = {
-   .quirks = MUSB_INDEXED_EP | MUSB_DMA_CPPI41,
+   .quirks = MUSB_INDEXED_EP | MUSB_DMA_CPPI41 | MUSB_DA8XX,
.init   = da8xx_musb_init,
.exit   = da8xx_musb_exit,
 
diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index ade902e..d129278 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -172,6 +172,7 @@ struct musb_io;
  */
 struct musb_platform_ops {
 
+#define MUSB_DA8XX BIT(7)
 #define MUSB_DMA_UX500 BIT(6)
 #define MUSB_DMA_CPPI41BIT(5)
 #define MUSB_DMA_CPPI  BIT(4)
diff --git a/drivers/usb/musb/musb_cppi41.c b/drivers/usb/musb/musb_cppi41.c
index 00e272b..2df37be 100644
--- a/drivers/usb/musb/musb_cppi41.c
+++ b/drivers/usb/musb/musb_cppi41.c
@@ -552,6 +552,10 @@ static int cppi41_dma_channel_abort(struct dma_channel 
*channel)
}
}
 
+   /* DA8xx Advisory 2.3.27: wait 250 ms before to start the teardown */
+   if (musb->io.quirks & MUSB_DA8XX)
+   mdelay(250);
+
tdbit = 1 << cppi41_channel->port_num;
if (is_tx)
tdbit <<= 16;
-- 
2.10.2

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 3/5] usb: musb: Add support of CPPI 4.1 DMA controller to DA8xx

[Alexandre Bailon]

Currently, only the PIO mode is supported.
This add support of CPPI 4.1 to DA8xx.
As the In DA8xx the CPPI 4.1 DMA is a part of the USB.
Create the CPPI 4.1 device as a child of USB.

Signed-off-by: Alexandre Bailon 
---
 drivers/usb/musb/Kconfig |  4 ++--
 drivers/usb/musb/da8xx.c | 35 ++-
 2 files changed, 36 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig
index 72a2a50..5506a9c 100644
--- a/drivers/usb/musb/Kconfig
+++ b/drivers/usb/musb/Kconfig
@@ -160,8 +160,8 @@ config USB_TI_CPPI_DMA
  Enable DMA transfers when TI CPPI DMA is available.
 
 config USB_TI_CPPI41_DMA
-   bool 'TI CPPI 4.1 (AM335x)'
-   depends on ARCH_OMAP && DMADEVICES
+   bool 'TI CPPI 4.1'
+   depends on (ARCH_OMAP || ARCH_DAVINCI_DA8XX) && DMADEVICES
select TI_CPPI41
 
 config USB_TUSB_OMAP_DMA
diff --git a/drivers/usb/musb/da8xx.c b/drivers/usb/musb/da8xx.c
index cd3d763..d279438 100644
--- a/drivers/usb/musb/da8xx.c
+++ b/drivers/usb/musb/da8xx.c
@@ -33,6 +33,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -457,12 +458,40 @@ static inline u8 get_vbus_power(struct device *dev)
return current_uA / 1000 / 2;
 }
 
+#ifdef CONFIG_USB_TI_CPPI41_DMA
+static void da8xx_dma_controller_callback(struct dma_controller *c)
+{
+   struct musb *musb = c->musb;
+   void __iomem *reg_base = musb->ctrl_base;
+
+   musb_writel(reg_base, DA8XX_USB_END_OF_INTR_REG, 0);
+}
+
+static struct dma_controller *
+da8xx_dma_controller_create(struct musb *musb, void __iomem *base)
+{
+   struct dma_controller *controller;
+
+   controller = cppi41_dma_controller_create(musb, base);
+   if (IS_ERR_OR_NULL(controller))
+   return controller;
+
+   controller->dma_callback = da8xx_dma_controller_callback;
+
+   return controller;
+}
+#endif
+
 static const struct musb_platform_ops da8xx_ops = {
-   .quirks = MUSB_INDEXED_EP,
+   .quirks = MUSB_INDEXED_EP | MUSB_DMA_CPPI41,
.init   = da8xx_musb_init,
.exit   = da8xx_musb_exit,
 
.fifo_mode  = 2,
+#ifdef CONFIG_USB_TI_CPPI41_DMA
+   .dma_init   = da8xx_dma_controller_create,
+   .dma_exit   = cppi41_dma_controller_destroy,
+#endif
.enable = da8xx_musb_enable,
.disable= da8xx_musb_disable,
 
@@ -534,6 +563,10 @@ static int da8xx_probe(struct platform_device *pdev)
}
platform_set_drvdata(pdev, glue);
 
+   ret = of_platform_populate(pdev->dev.of_node, NULL, NULL, >dev);
+   if (ret)
+   return ret;
+
memset(musb_resources, 0x00, sizeof(*musb_resources) *
ARRAY_SIZE(musb_resources));
 
-- 
2.10.2

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 5/5] usb: musb: da8xx: Add a primary support of PM runtime

[Alexandre Bailon]

Currently, MUSB DA8xx glue driver doesn't have PM runtime support.
Because the CPPI 4.1 is using the same clock as MUSB DA8xx and
CPPI 4.1 is a child of MUSB DA8xx glue, add support of PM runtime
to the DA8xx glue driver in order to let the CPPI 4.1 driver manage
the clock by using PM runtime.

Signed-off-by: Alexandre Bailon 
---
 drivers/usb/musb/da8xx.c | 23 ++-
 1 file changed, 6 insertions(+), 17 deletions(-)

diff --git a/drivers/usb/musb/da8xx.c b/drivers/usb/musb/da8xx.c
index d87fb9b..bebc9ed 100644
--- a/drivers/usb/musb/da8xx.c
+++ b/drivers/usb/musb/da8xx.c
@@ -30,7 +30,6 @@
  */
 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -86,7 +85,6 @@ struct da8xx_glue {
struct device   *dev;
struct platform_device  *musb;
struct platform_device  *usb_phy;
-   struct clk  *clk;
struct phy  *phy;
 };
 
@@ -377,11 +375,7 @@ static int da8xx_musb_init(struct musb *musb)
 
musb->mregs += DA8XX_MENTOR_CORE_OFFSET;
 
-   ret = clk_prepare_enable(glue->clk);
-   if (ret) {
-   dev_err(glue->dev, "failed to enable clock\n");
-   return ret;
-   }
+   pm_runtime_get_sync(musb->controller->parent);
 
/* Returns zero if e.g. not clocked */
rev = musb_readl(reg_base, DA8XX_USB_REVISION_REG);
@@ -424,7 +418,7 @@ static int da8xx_musb_init(struct musb *musb)
 err_phy_power_on:
phy_exit(glue->phy);
 fail:
-   clk_disable_unprepare(glue->clk);
+   pm_runtime_put(musb->controller->parent);
return ret;
 }
 
@@ -436,7 +430,7 @@ static int da8xx_musb_exit(struct musb *musb)
 
phy_power_off(glue->phy);
phy_exit(glue->phy);
-   clk_disable_unprepare(glue->clk);
+   pm_runtime_put(musb->controller->parent);
 
usb_put_phy(musb->xceiv);
 
@@ -519,7 +513,6 @@ static int da8xx_probe(struct platform_device *pdev)
struct musb_hdrc_platform_data  *pdata = dev_get_platdata(>dev);
struct da8xx_glue   *glue;
struct platform_device_info pinfo;
-   struct clk  *clk;
struct device_node  *np = pdev->dev.of_node;
int ret;
 
@@ -527,12 +520,6 @@ static int da8xx_probe(struct platform_device *pdev)
if (!glue)
return -ENOMEM;
 
-   clk = devm_clk_get(>dev, "usb20");
-   if (IS_ERR(clk)) {
-   dev_err(>dev, "failed to get clock\n");
-   return PTR_ERR(clk);
-   }
-
glue->phy = devm_phy_get(>dev, "usb-phy");
if (IS_ERR(glue->phy)) {
if (PTR_ERR(glue->phy) != -EPROBE_DEFER)
@@ -541,7 +528,6 @@ static int da8xx_probe(struct platform_device *pdev)
}
 
glue->dev   = >dev;
-   glue->clk   = clk;
 
if (IS_ENABLED(CONFIG_OF) && np) {
pdata = devm_kzalloc(>dev, sizeof(*pdata), GFP_KERNEL);
@@ -587,6 +573,8 @@ static int da8xx_probe(struct platform_device *pdev)
pinfo.data = pdata;
pinfo.size_data = sizeof(*pdata);
 
+   pm_runtime_enable(>dev);
+
glue->musb = platform_device_register_full();
ret = PTR_ERR_OR_ZERO(glue->musb);
if (ret) {
@@ -603,6 +591,7 @@ static int da8xx_remove(struct platform_device *pdev)
 
platform_device_unregister(glue->musb);
usb_phy_generic_unregister(glue->usb_phy);
+   pm_runtime_disable(>dev);
 
return 0;
 }
-- 
2.10.2

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv15 3/3] usb: typec: add driver for Intel Whiskey Cove PMIC USB Type-C PHY

[Felipe Balbi]

Hi,

Heikki Krogerus  writes:
>> > +  wcove->cap.prefer_role = TYPEC_NO_PREFERRED_ROLE;
>> 
>> we have a slight problem here that affects users of this particular
>> driver. Well, more specifically, it affects Intel Joule.
>> 
>> Because of the way ASL was written and the way Intel's DRD mux works, we
>> don't have a state which means "don't route USB signals to either Host
>> or Peripheral". Because of that, when we plug the type-c cable either
>> XHCI or dwc3 will have noise coming into the IP.
>> 
>> If default mode ends up being peripheral we have two possible problems
>> here:
>> 
>> i) device-to-device cable assembly
>> 
>>  this won't be a big problem because we will just negotiate who's
>>  Sink and who's Source then change mux on one side.
>> 
>> ii) lack of disconnect IRQ on dwc3
>> 
>>  Because of how ASL was written, when we unplug the cable, mux's
>>  VBUS_VALID bit won't be cleared which means dwc3 won't generate
>>  disconnect interrupt. This means that upon cable reconnect (!!)
>>  we will run ->disconnect() callback. The result is that dwc3
>>  will never runtime suspend.
>> 
>> If default mode ends up being host we're possibly going to end up with a
>> host-to-host cable assembly. Now this can cause 2 issues:
>> 
>> i) port config error
>> 
>>  host-to-host is not a supported cable assembly. While we see
>>  errors on dmesg, eventually type-c negotiation will happen and
>>  nothing will actually break.
>> 
>> ii) DbC can start on the other end of the cable
>> 
>>  Now this was really surprising to me. When testing this on Intel
>>  Joule and plugging Intel Joule straight to my PC's roothub port,
>>  I noticed Joule ended up being host and my Desktop () became
>>  a peripheral enumerated by Joule. I can only assume this is DbC
>>  somehow being started.
>> 
>>  The only way to have Joule become a peripheral is to connect it
>>  through an external hub to my PC. Odd, ain't it?
>> 
>> I'm not sure how to solve this problem apart from modifying BIOS :-( Any
>> ideas?
>
> I don't think there is any other way to fix this expect modifying BIOS.
>
> The VBUS_VALID bit would need to be handled separate in ASL.

That means we need some method for figuring out VBUS is above 4.4V.

-- 
balbi


signature.asc
Description: PGP signature

[PATCH v5 2/6] usb: musb: cppi41: Detect aborted transfers in cppi41_dma_callback()

[Alexandre Bailon]

Update cppi41_dma_callback() to detect an aborted transfer.
This was not required before because cppi41_dma_callback() was only
invoked on transfer completion.
In order to make CPPI 4.1 driver more generic, cppi41_dma_callback()
will be invoked after a transfer abort in order to let the MUSB driver
perform some action such as acknowledge the interrupt that may be fired
during a teardown.

Signed-off-by: Alexandre Bailon 
---
 drivers/usb/musb/musb_cppi41.c | 13 +
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/musb/musb_cppi41.c b/drivers/usb/musb/musb_cppi41.c
index f7d3d27..1fe7eae 100644
--- a/drivers/usb/musb/musb_cppi41.c
+++ b/drivers/usb/musb/musb_cppi41.c
@@ -99,7 +99,8 @@ static bool musb_is_tx_fifo_empty(struct musb_hw_ep *hw_ep)
return true;
 }
 
-static void cppi41_dma_callback(void *private_data);
+static void cppi41_dma_callback(void *private_data,
+   const struct dmaengine_result *result);
 
 static void cppi41_trans_done(struct cppi41_dma_channel *cppi41_channel)
 {
@@ -154,7 +155,7 @@ static void cppi41_trans_done(struct cppi41_dma_channel 
*cppi41_channel)
if (WARN_ON(!dma_desc))
return;
 
-   dma_desc->callback = cppi41_dma_callback;
+   dma_desc->callback_result = cppi41_dma_callback;
dma_desc->callback_param = _channel->channel;
cppi41_channel->cookie = dma_desc->tx_submit(dma_desc);
trace_musb_cppi41_cont(cppi41_channel);
@@ -204,7 +205,8 @@ static enum hrtimer_restart cppi41_recheck_tx_req(struct 
hrtimer *timer)
return ret;
 }
 
-static void cppi41_dma_callback(void *private_data)
+static void cppi41_dma_callback(void *private_data,
+   const struct dmaengine_result *result)
 {
struct dma_channel *channel = private_data;
struct cppi41_dma_channel *cppi41_channel = channel->private_data;
@@ -221,6 +223,9 @@ static void cppi41_dma_callback(void *private_data)
if (controller->controller.dma_callback)
controller->controller.dma_callback(>controller);
 
+   if (result->result == DMA_TRANS_ABORTED)
+   return;
+
spin_lock_irqsave(>lock, flags);
 
dmaengine_tx_status(cppi41_channel->dc, cppi41_channel->cookie,
@@ -403,7 +408,7 @@ static bool cppi41_configure_channel(struct dma_channel 
*channel,
if (!dma_desc)
return false;
 
-   dma_desc->callback = cppi41_dma_callback;
+   dma_desc->callback_result = cppi41_dma_callback;
dma_desc->callback_param = channel;
cppi41_channel->cookie = dma_desc->tx_submit(dma_desc);
cppi41_channel->channel.rx_packet_done = false;
-- 
2.10.2

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 1/6] usb: musb: dma: Add a DMA completion platform callback

[Alexandre Bailon]

Currently, the CPPI 4.1 driver is not completely generic and
only works on DSPS. This is because of IRQ management.
Add a callback to dma_controller that could be invoked on DMA completion
to acknowledge the IRQ.

Signed-off-by: Alexandre Bailon 
---
 drivers/usb/musb/musb_cppi41.c | 7 +--
 drivers/usb/musb/musb_dma.h| 5 +
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/musb/musb_cppi41.c b/drivers/usb/musb/musb_cppi41.c
index 1636385..f7d3d27 100644
--- a/drivers/usb/musb/musb_cppi41.c
+++ b/drivers/usb/musb/musb_cppi41.c
@@ -217,6 +217,10 @@ static void cppi41_dma_callback(void *private_data)
int is_hs = 0;
bool empty;
 
+   controller = cppi41_channel->controller;
+   if (controller->controller.dma_callback)
+   controller->controller.dma_callback(>controller);
+
spin_lock_irqsave(>lock, flags);
 
dmaengine_tx_status(cppi41_channel->dc, cppi41_channel->cookie,
@@ -249,8 +253,6 @@ static void cppi41_dma_callback(void *private_data)
 * We spin on HS (no longer than than 25us and setup a timer on
 * FS to check for the bit and complete the transfer.
 */
-   controller = cppi41_channel->controller;
-
if (is_host_active(musb)) {
if (musb->port1_status & USB_PORT_STAT_HIGH_SPEED)
is_hs = 1;
@@ -695,6 +697,7 @@ cppi41_dma_controller_create(struct musb *musb, void 
__iomem *base)
controller->controller.channel_program = cppi41_dma_channel_program;
controller->controller.channel_abort = cppi41_dma_channel_abort;
controller->controller.is_compatible = cppi41_is_compatible;
+   controller->controller.musb = musb;
 
ret = cppi41_dma_controller_start(controller);
if (ret)
diff --git a/drivers/usb/musb/musb_dma.h b/drivers/usb/musb/musb_dma.h
index 46357e1..04c3bd8 100644
--- a/drivers/usb/musb/musb_dma.h
+++ b/drivers/usb/musb/musb_dma.h
@@ -173,6 +173,7 @@ dma_channel_status(struct dma_channel *c)
 
 /**
  * struct dma_controller - A DMA Controller.
+ * @musb: the usb controller
  * @start: call this to start a DMA controller;
  * return 0 on success, else negative errno
  * @stop: call this to stop a DMA controller
@@ -181,10 +182,13 @@ dma_channel_status(struct dma_channel *c)
  * @channel_release: call this to release a DMA channel
  * @channel_abort: call this to abort a pending DMA transaction,
  * returning it to FREE (but allocated) state
+ * @dma_callback: invoked on DMA completion, useful to run platform
+ * code such IRQ acknowledgment.
  *
  * Controllers manage dma channels.
  */
 struct dma_controller {
+   struct musb *musb;
struct dma_channel  *(*channel_alloc)(struct dma_controller *,
struct musb_hw_ep *, u8 is_tx);
void(*channel_release)(struct dma_channel *);
@@ -196,6 +200,7 @@ struct dma_controller {
int (*is_compatible)(struct dma_channel *channel,
u16 maxpacket,
void *buf, u32 length);
+   void(*dma_callback)(struct dma_controller *);
 };
 
 /* called after channel_program(), may indicate a fault */
-- 
2.10.2

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 4/6] usb: musb: cppi_dma: Clean up cppi41_dma_controller structure

[Alexandre Bailon]

A pointer to musb is now present in the dma_controller structure.
Remove the one present in cppi41_dma_controller structure.

Signed-off-by: Alexandre Bailon 
---
 drivers/usb/musb/musb_cppi41.c | 29 +
 1 file changed, 13 insertions(+), 16 deletions(-)

diff --git a/drivers/usb/musb/musb_cppi41.c b/drivers/usb/musb/musb_cppi41.c
index 1fe7eae..00e272b 100644
--- a/drivers/usb/musb/musb_cppi41.c
+++ b/drivers/usb/musb/musb_cppi41.c
@@ -30,7 +30,6 @@ struct cppi41_dma_controller {
struct dma_controller controller;
struct cppi41_dma_channel rx_channel[MUSB_DMA_NUM_CHANNELS];
struct cppi41_dma_channel tx_channel[MUSB_DMA_NUM_CHANNELS];
-   struct musb *musb;
struct hrtimer early_tx;
struct list_head early_tx_list;
u32 rx_mode;
@@ -45,7 +44,7 @@ static void save_rx_toggle(struct cppi41_dma_channel 
*cppi41_channel)
 
if (cppi41_channel->is_tx)
return;
-   if (!is_host_active(cppi41_channel->controller->musb))
+   if (!is_host_active(cppi41_channel->controller->controller.musb))
return;
 
csr = musb_readw(cppi41_channel->hw_ep->regs, MUSB_RXCSR);
@@ -78,8 +77,7 @@ static void update_rx_toggle(struct cppi41_dma_channel 
*cppi41_channel)
if (!toggle && toggle == cppi41_channel->usb_toggle) {
csr |= MUSB_RXCSR_H_DATATOGGLE | MUSB_RXCSR_H_WR_DATATOGGLE;
musb_writew(cppi41_channel->hw_ep->regs, MUSB_RXCSR, csr);
-   musb_dbg(cppi41_channel->controller->musb,
-   "Restoring DATA1 toggle.");
+   musb_dbg(musb, "Restoring DATA1 toggle.");
}
 
cppi41_channel->usb_toggle = toggle;
@@ -180,7 +178,7 @@ static enum hrtimer_restart cppi41_recheck_tx_req(struct 
hrtimer *timer)
 
controller = container_of(timer, struct cppi41_dma_controller,
early_tx);
-   musb = controller->musb;
+   musb = controller->controller.musb;
 
spin_lock_irqsave(>lock, flags);
list_for_each_entry_safe(cppi41_channel, n, >early_tx_list,
@@ -309,6 +307,7 @@ static void cppi41_set_dma_mode(struct cppi41_dma_channel 
*cppi41_channel,
unsigned mode)
 {
struct cppi41_dma_controller *controller = cppi41_channel->controller;
+   struct musb *musb = controller->controller.musb;
u32 port;
u32 new_mode;
u32 old_mode;
@@ -324,12 +323,10 @@ static void cppi41_set_dma_mode(struct cppi41_dma_channel 
*cppi41_channel,
return;
if (cppi41_channel->is_tx) {
controller->tx_mode = new_mode;
-   musb_writel(controller->musb->ctrl_base, USB_CTRL_TX_MODE,
-   new_mode);
+   musb_writel(musb->ctrl_base, USB_CTRL_TX_MODE, new_mode);
} else {
controller->rx_mode = new_mode;
-   musb_writel(controller->musb->ctrl_base, USB_CTRL_RX_MODE,
-   new_mode);
+   musb_writel(musb->ctrl_base, USB_CTRL_RX_MODE, new_mode);
}
 }
 
@@ -348,7 +345,8 @@ static void cppi41_set_autoreq_mode(struct 
cppi41_dma_channel *cppi41_channel,
if (new_mode == old_mode)
return;
controller->auto_req = new_mode;
-   musb_writel(controller->musb->ctrl_base, USB_CTRL_AUTOREQ, new_mode);
+   musb_writel(controller->controller.musb->ctrl_base, USB_CTRL_AUTOREQ,
+   new_mode);
 }
 
 static bool cppi41_configure_channel(struct dma_channel *channel,
@@ -359,7 +357,7 @@ static bool cppi41_configure_channel(struct dma_channel 
*channel,
struct dma_chan *dc = cppi41_channel->dc;
struct dma_async_tx_descriptor *dma_desc;
enum dma_transfer_direction direction;
-   struct musb *musb = cppi41_channel->controller->musb;
+   struct musb *musb = cppi41_channel->controller->controller.musb;
unsigned use_gen_rndis = 0;
 
cppi41_channel->buf_addr = dma_addr;
@@ -472,7 +470,7 @@ static int cppi41_dma_channel_program(struct dma_channel 
*channel,
BUG_ON(channel->status == MUSB_DMA_STATUS_UNKNOWN ||
channel->status == MUSB_DMA_STATUS_BUSY);
 
-   if (is_host_active(cppi41_channel->controller->musb)) {
+   if (is_host_active(cppi41_channel->controller->controller.musb)) {
if (cppi41_channel->is_tx)
hb_mult = cppi41_channel->hw_ep->out_qh->hb_mult;
else
@@ -497,7 +495,7 @@ static int cppi41_is_compatible(struct dma_channel 
*channel, u16 maxpacket,
 {
struct cppi41_dma_channel *cppi41_channel = channel->private_data;
struct cppi41_dma_controller *controller = cppi41_channel->controller;
-   struct musb *musb = controller->musb;
+   struct musb *musb = controller->controller.musb;
 
if (is_host_active(musb)) {
WARN_ON(1);
@@ -515,7 +513,7 @@ static int 

[PATCH v5 5/6] usb: musb: cppi_dma: Clean up tusb_omap_dma structure

[Alexandre Bailon]

A pointer to musb is now present in the dma_controller structure.
Remove the one present in tusb_omap_dma structure.

Signed-off-by: Alexandre Bailon 
---
 drivers/usb/musb/tusb6010_omap.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/musb/tusb6010_omap.c b/drivers/usb/musb/tusb6010_omap.c
index e6959cc..8b43c4b 100644
--- a/drivers/usb/musb/tusb6010_omap.c
+++ b/drivers/usb/musb/tusb6010_omap.c
@@ -56,7 +56,6 @@ struct tusb_omap_dma_ch {
 
 struct tusb_omap_dma {
struct dma_controller   controller;
-   struct musb *musb;
void __iomem*tbase;
 
int ch;
@@ -497,7 +496,7 @@ tusb_omap_dma_allocate(struct dma_controller *c,
u32 reg;
 
tusb_dma = container_of(c, struct tusb_omap_dma, controller);
-   musb = tusb_dma->musb;
+   musb = tusb_dma->controller.musb;
tbase = musb->ctrl_base;
 
reg = musb_readl(tbase, TUSB_DMA_INT_MASK);
@@ -534,7 +533,7 @@ tusb_omap_dma_allocate(struct dma_controller *c,
dev_name = "TUSB receive";
}
 
-   chdat->musb = tusb_dma->musb;
+   chdat->musb = tusb_dma->controller.musb;
chdat->tbase = tusb_dma->tbase;
chdat->hw_ep = hw_ep;
chdat->epnum = hw_ep->epnum;
@@ -667,7 +666,7 @@ tusb_dma_controller_create(struct musb *musb, void __iomem 
*base)
if (!tusb_dma)
goto out;
 
-   tusb_dma->musb = musb;
+   tusb_dma->controller.musb = musb;
tusb_dma->tbase = musb->ctrl_base;
 
tusb_dma->ch = -1;
-- 
2.10.2

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 3/6] usb: musb: cppi_dma: Clean up cppi structure

[Alexandre Bailon]

A pointer to musb is now present in the dma_controller structure.
Remove the one present in cppi structure.

Signed-off-by: Alexandre Bailon 
---
 drivers/usb/musb/cppi_dma.c | 26 +-
 drivers/usb/musb/cppi_dma.h |  1 -
 2 files changed, 13 insertions(+), 14 deletions(-)

diff --git a/drivers/usb/musb/cppi_dma.c b/drivers/usb/musb/cppi_dma.c
index 1ae48e6..c4fabe95 100644
--- a/drivers/usb/musb/cppi_dma.c
+++ b/drivers/usb/musb/cppi_dma.c
@@ -224,7 +224,7 @@ static void cppi_controller_stop(struct cppi *controller)
int i;
struct musb *musb;
 
-   musb = controller->musb;
+   musb = controller->controller.musb;
 
tibase = controller->tibase;
/* DISABLE INDIVIDUAL CHANNEL Interrupts */
@@ -288,7 +288,7 @@ cppi_channel_allocate(struct dma_controller *c,
 
controller = container_of(c, struct cppi, controller);
tibase = controller->tibase;
-   musb = controller->musb;
+   musb = c->musb;
 
/* ep0 doesn't use DMA; remember cppi indices are 0..N-1 */
index = ep->epnum - 1;
@@ -336,7 +336,7 @@ static void cppi_channel_release(struct dma_channel 
*channel)
c = container_of(channel, struct cppi_channel, channel);
tibase = c->controller->tibase;
if (!c->hw_ep)
-   musb_dbg(c->controller->musb,
+   musb_dbg(c->controller->controller.musb,
"releasing idle DMA channel %p", c);
else if (!c->transmit)
core_rxirq_enable(tibase, c->index + 1);
@@ -355,7 +355,7 @@ cppi_dump_rx(int level, struct cppi_channel *c, const char 
*tag)
 
musb_ep_select(base, c->index + 1);
 
-   musb_dbg(c->controller->musb,
+   musb_dbg(c->controller->controller.musb,
"RX DMA%d%s: %d left, csr %04x, "
"%08x H%08x S%08x C%08x, "
"B%08x L%08x %08x .. %08x",
@@ -385,7 +385,7 @@ cppi_dump_tx(int level, struct cppi_channel *c, const char 
*tag)
 
musb_ep_select(base, c->index + 1);
 
-   musb_dbg(c->controller->musb,
+   musb_dbg(c->controller->controller.musb,
"TX DMA%d%s: csr %04x, "
"H%08x S%08x C%08x %08x, "
"F%08x L%08x .. %08x",
@@ -954,7 +954,7 @@ static int cppi_channel_program(struct dma_channel *ch,
 
cppi_ch = container_of(ch, struct cppi_channel, channel);
controller = cppi_ch->controller;
-   musb = controller->musb;
+   musb = controller->controller.musb;
 
switch (ch->status) {
case MUSB_DMA_STATUS_BUS_ABORT:
@@ -1009,7 +1009,7 @@ static bool cppi_rx_scan(struct cppi *cppi, unsigned ch)
int i;
dma_addr_t  safe2ack;
void __iomem*regs = rx->hw_ep->regs;
-   struct musb *musb = cppi->musb;
+   struct musb *musb = cppi->controller.musb;
 
cppi_dump_rx(6, rx, "/K");
 
@@ -1121,7 +1121,7 @@ static bool cppi_rx_scan(struct cppi *cppi, unsigned ch)
 * setting it here "should" be racey, but seems to work
 */
csr = musb_readw(rx->hw_ep->regs, MUSB_RXCSR);
-   if (is_host_active(cppi->musb)
+   if (is_host_active(cppi->controller.musb)
&& bd
&& !(csr & MUSB_RXCSR_H_REQPKT)) {
csr |= MUSB_RXCSR_H_REQPKT;
@@ -1311,7 +1311,7 @@ cppi_dma_controller_create(struct musb *musb, void 
__iomem *mregs)
controller->mregs = mregs;
controller->tibase = mregs - DAVINCI_BASE_OFFSET;
 
-   controller->musb = musb;
+   controller->controller.musb = musb;
controller->controller.channel_alloc = cppi_channel_allocate;
controller->controller.channel_release = cppi_channel_release;
controller->controller.channel_program = cppi_channel_program;
@@ -1323,7 +1323,7 @@ cppi_dma_controller_create(struct musb *musb, void 
__iomem *mregs)
 
/* setup BufferPool */
controller->pool = dma_pool_create("cppi",
-   controller->musb->controller,
+   controller->controller.musb->controller,
sizeof(struct cppi_descriptor),
CPPI_DESCRIPTOR_ALIGN, 0);
if (!controller->pool) {
@@ -1357,7 +1357,7 @@ void cppi_dma_controller_destroy(struct dma_controller *c)
cppi_controller_stop(cppi);
 
if (cppi->irq)
-   free_irq(cppi->irq, cppi->musb);
+   free_irq(cppi->irq, cppi->controller.musb);
 
/* assert:  caller stopped the controller first */
dma_pool_destroy(cppi->pool);
@@ -1469,7 +1469,7 @@ static int cppi_channel_abort(struct dma_channel *channel)
core_rxirq_disable(tibase, cppi_ch->index + 1);
 
/* for host, ensure ReqPkt is never 

[PATCH v5 0/6] usb: musb: cppi41: Add a way to manage DMA irq

[Alexandre Bailon]

This series was "dmaengine: cppi41: Make the driver more generic".
I have tried to separate as munch I could CPPI 4.1 MUSB driver changes.

Currently, the DMA interrupt is managed by the CPPI 4.1 driver.
The issue here is the CPPI 4.1 driver must access to MUSB glue registers
to manage its interrupt.
In order to move the interrupts management from CPPI 4.1 driver to MUSB
(and then make it more generic), update the MUSB CPPI 4.1 driver with
changes that will help to manage DMA interrupt from MUSB driver.

Changes in v5:
- Clean up patch 4 and 5

Changes in v4:
- Remove musb pointer from struct cppi, cppi41_dma_controller and
  tusb_omap_dma.

Changes in v3:
- Move a patch from another series to this one to avoid build error report
  from kbuild test robot
- Instead of adding and exporting function, add one callback and a pointer
  to musb in struct dma_controller
- Surround the DMA function introduced in musb_dsps with #ifdef / #endif.

Changes in v2:
- Fix some typo in commit messages
- Add more explanation about some changes made by patch 2 in commit message

Alexandre Bailon (6):
  usb: musb: dma: Add a DMA completion platform callback
  usb: musb: cppi41: Detect aborted transfers in cppi41_dma_callback()
  usb: musb: cppi_dma: Clean up cppi structure
  usb: musb: cppi_dma: Clean up cppi41_dma_controller structure
  usb: musb: cppi_dma: Clean up tusb_omap_dma structure
  usb: musb: dsps: Manage CPPI 4.1 DMA interrupt in DSPS

 drivers/dma/cppi41.c | 28 --
 drivers/usb/musb/cppi_dma.c  | 26 ++---
 drivers/usb/musb/cppi_dma.h  |  1 -
 drivers/usb/musb/musb_cppi41.c   | 49 +---
 drivers/usb/musb/musb_dma.h  |  5 +++
 drivers/usb/musb/musb_dsps.c | 81 +++-
 drivers/usb/musb/tusb6010_omap.c |  7 ++--
 7 files changed, 134 insertions(+), 63 deletions(-)

-- 
2.10.2

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 6/6] usb: musb: dsps: Manage CPPI 4.1 DMA interrupt in DSPS

[Alexandre Bailon]

Despite the CPPI 4.1 is a generic DMA, it is tied to USB.
On the DSPS, CPPI 4.1 interrupt's registers are in USBSS (the MUSB glue).
Currently, to enable / disable and clear interrupts, the CPPI 4.1 driver
maps and accesses to USBSS's register, which making CPPI 4.1 driver not
really generic.
Move the interrupt management to DSPS driver.

Signed-off-by: Alexandre Bailon 
---
 drivers/dma/cppi41.c | 28 ---
 drivers/usb/musb/musb_dsps.c | 81 ++--
 2 files changed, 86 insertions(+), 23 deletions(-)

diff --git a/drivers/dma/cppi41.c b/drivers/dma/cppi41.c
index d5ba43a..4999e7d 100644
--- a/drivers/dma/cppi41.c
+++ b/drivers/dma/cppi41.c
@@ -79,14 +79,6 @@
 #define QMGR_QUEUE_C(n)(0x2008 + (n) * 0x10)
 #define QMGR_QUEUE_D(n)(0x200c + (n) * 0x10)
 
-/* Glue layer specific */
-/* USBSS  / USB AM335x */
-#define USBSS_IRQ_STATUS   0x28
-#define USBSS_IRQ_ENABLER  0x2c
-#define USBSS_IRQ_CLEARR   0x30
-
-#define USBSS_IRQ_PD_COMP  (1 <<  2)
-
 /* Packet Descriptor */
 #define PD2_ZERO_LENGTH(1 << 19)
 
@@ -288,14 +280,8 @@ static irqreturn_t cppi41_irq(int irq, void *data)
 {
struct cppi41_dd *cdd = data;
struct cppi41_channel *c;
-   u32 status;
int i;
 
-   status = cppi_readl(cdd->usbss_mem + USBSS_IRQ_STATUS);
-   if (!(status & USBSS_IRQ_PD_COMP))
-   return IRQ_NONE;
-   cppi_writel(status, cdd->usbss_mem + USBSS_IRQ_STATUS);
-
for (i = QMGR_PENDING_SLOT_Q(FIST_COMPLETION_QUEUE); i < QMGR_NUM_PEND;
i++) {
u32 val;
@@ -599,6 +585,7 @@ static void cppi41_compute_td_desc(struct cppi41_desc *d)
 
 static int cppi41_tear_down_chan(struct cppi41_channel *c)
 {
+   struct dmaengine_result abort_result;
struct cppi41_dd *cdd = c->cdd;
struct cppi41_desc *td;
u32 reg;
@@ -682,6 +669,12 @@ static int cppi41_tear_down_chan(struct cppi41_channel *c)
c->td_seen = 0;
c->td_desc_seen = 0;
cppi_writel(0, c->gcr_reg);
+
+   /* Invoke the callback to do the necessary clean-up */
+   abort_result.result = DMA_TRANS_ABORTED;
+   dma_cookie_complete(>txd);
+   dmaengine_desc_get_callback_invoke(>txd, _result);
+
return 0;
 }
 
@@ -1044,8 +1037,6 @@ static int cppi41_dma_probe(struct platform_device *pdev)
goto err_irq;
}
 
-   cppi_writel(USBSS_IRQ_PD_COMP, cdd->usbss_mem + USBSS_IRQ_ENABLER);
-
ret = devm_request_irq(>dev, irq, glue_info->isr, IRQF_SHARED,
dev_name(dev), cdd);
if (ret)
@@ -1069,7 +1060,6 @@ static int cppi41_dma_probe(struct platform_device *pdev)
dma_async_device_unregister(>ddev);
 err_dma_reg:
 err_irq:
-   cppi_writel(0, cdd->usbss_mem + USBSS_IRQ_CLEARR);
cleanup_chans(cdd);
 err_chans:
deinit_cppi41(dev, cdd);
@@ -1097,7 +1087,6 @@ static int cppi41_dma_remove(struct platform_device *pdev)
of_dma_controller_free(pdev->dev.of_node);
dma_async_device_unregister(>ddev);
 
-   cppi_writel(0, cdd->usbss_mem + USBSS_IRQ_CLEARR);
devm_free_irq(>dev, cdd->irq, cdd);
cleanup_chans(cdd);
deinit_cppi41(>dev, cdd);
@@ -1116,7 +1105,6 @@ static int __maybe_unused cppi41_suspend(struct device 
*dev)
struct cppi41_dd *cdd = dev_get_drvdata(dev);
 
cdd->dma_tdfdq = cppi_readl(cdd->ctrl_mem + DMA_TDFDQ);
-   cppi_writel(0, cdd->usbss_mem + USBSS_IRQ_CLEARR);
disable_sched(cdd);
 
return 0;
@@ -1142,8 +1130,6 @@ static int __maybe_unused cppi41_resume(struct device 
*dev)
cppi_writel(QMGR_SCRATCH_SIZE, cdd->qmgr_mem + QMGR_LRAM_SIZE);
cppi_writel(0, cdd->qmgr_mem + QMGR_LRAM1_BASE);
 
-   cppi_writel(USBSS_IRQ_PD_COMP, cdd->usbss_mem + USBSS_IRQ_ENABLER);
-
return 0;
 }
 
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 9f125e1..461bc09 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -121,6 +121,7 @@ struct dsps_glue {
struct timer_list timer;/* otg_workaround timer */
unsigned long last_timer;/* last timer data for each instance */
bool sw_babble_enabled;
+   void __iomem *usbss_base;
 
struct dsps_context context;
struct debugfs_regset32 regset;
@@ -145,6 +146,13 @@ static const struct debugfs_reg32 dsps_musb_regs[] = {
{ "mode",   0xe8 },
 };
 
+/* USBSS  / USB AM335x */
+#define USBSS_IRQ_STATUS   0x28
+#define USBSS_IRQ_ENABLER  0x2c
+#define USBSS_IRQ_CLEARR   0x30
+
+#define USBSS_IRQ_PD_COMP  (1 << 2)
+
 /**
  * dsps_musb_enable - enable interrupts
  */
@@ -619,14 +627,76 @@ static void dsps_read_fifo32(struct musb_hw_ep *hw_ep, 
u16 len, u8 *dst)
}
 }
 
+#ifdef CONFIG_USB_TI_CPPI41_DMA
+static void dsps_dma_controller_callback(struct dma_controller *c)

Re: [PATCH 1/2] usb: musb: Fix host mode error -71 regression

[Greg KH]

On Tue, Jan 24, 2017 at 09:18:57AM -0600, Bin Liu wrote:
> From: Tony Lindgren 
> 
> Commit 467d5c980709 ("usb: musb: Implement session bit based runtime PM for
> musb-core") started implementing musb generic runtime PM support by
> introducing devctl register session bit based state control.
> 
> This caused a regression where if a USB mass storage device is connected
> to a USB hub, we can get:
> 
> usb 1-1: reset high-speed USB device number 2 using musb-hdrc
> usb 1-1: device descriptor read/64, error -71
> usb 1-1.1: new high-speed USB device number 4 using musb-hdrc
> 
> This is because before the USB storage device is connected, musb is
> in OTG_STATE_A_SUSPEND. And we currently only set need_finish_resume
> in musb_stage0_irq() and the related code calling finish_resume_work
> in musb_resume() and musb_runtime_resume() never gets called.
> 
> To fix the issue, we can call schedule_delayed_work() directly in
> musb_stage0_irq() to have finish_resume_work run.
> 
> And we should no longer never get interrupts when when suspended.
> We have changed musb to no longer need pm_runtime_irqsafe().
> The need_finish_resume flag was added in commit 9298b4aad37e ("usb:
> musb: fix device hotplug behind hub") and no longer applies as far
> as I can tell. So let's just remove the earlier code that no longer
> is needed.
> 
> Fixes: 467d5c980709 ("usb: musb: Implement session bit based
> runtime PM for musb-core")
> Reported-by: Bin Liu 
> Signed-off-by: Tony Lindgren 
> Signed-off-by: Bin Liu 
> ---
>  drivers/usb/musb/musb_core.c | 15 ++-
>  drivers/usb/musb/musb_core.h |  1 -
>  2 files changed, 2 insertions(+), 14 deletions(-)

As the problem showed up in 4.9, this should go into 4.9-stable, right?

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 1/4] usb: dbc: early driver for xhci debug capability

[Peter Zijlstra]

On Wed, Jan 25, 2017 at 10:23:55AM +0100, Ingo Molnar wrote:
> 
> * Lu Baolu  wrote:
> 
> > > Hiding essentially an early udelay() implementation in an early-printk 
> > > driver is 
> > > ugly and counterproductive.

> Yeah - so could we do this in a more generic fashion, not in the early-printk 
> driver but in core x86 code?

So ideally early_printk() would not depend on udelay() being setup.

In fact, ideally early_printk() wouldn't even use udelay -- this very
much includes its own copy.

Why is udelay() required? Can't the thing simply poll its own register
state to wait for completion?

This all sounds like xdbc cruft is still unreliably garbage..
--
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