[PATCH] usb: dwc2: Remove deprecated create_singlethread_workqueue
alloc_ordered_workqueue replaces the deprecated
create_singlethread_workqueue.
There are multiple work items on the work queue, which require
ordering. Hence, an ordered workqueue has been used.
The workqueue "wq_otg" is not being used on a memory reclaim path.
Hence, WQ_MEM_RECLAIM has not been set.
Signed-off-by: Bhaktipriya Shridhar
---
drivers/usb/dwc2/hcd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
index 2df3d04..df5a065 100644
--- a/drivers/usb/dwc2/hcd.c
+++ b/drivers/usb/dwc2/hcd.c
@@ -5040,7 +5040,7 @@ int dwc2_hcd_init(struct dwc2_hsotg *hsotg, int irq)
/* Create new workqueue and init work */
retval = -ENOMEM;
- hsotg->wq_otg = create_singlethread_workqueue("dwc2");
+ hsotg->wq_otg = alloc_ordered_workqueue("dwc2", 0);
if (!hsotg->wq_otg) {
dev_err(hsotg->dev, "Failed to create workqueue\n");
goto error2;
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb: lvstest: Remove deprecated create_singlethread_workqueue
The workqueue has a single work item(&lvs->rh_work) and hence
doesn't require ordering. Also, it is not being used on a memory
reclaim path. Hence, the singlethreaded workqueue has been replaced
with the use of system_wq.
System workqueues have been able to handle high level of concurrency
for a long time now and hence it's not required to have a singlethreaded
workqueue just to gain concurrency. Unlike a dedicated per-cpu workqueue
created with create_singlethread_workqueue(), system_wq allows multiple
work items to overlap executions even on the same CPU; however, a
per-cpu workqueue doesn't have any CPU locality or global ordering
guarantee unless the target CPU is explicitly specified and thus the
increase of local concurrency shouldn't make any difference.
The work item has been flushed in lvs_rh_disconnect() to ensure that
there are no pending tasks while disconnecting the driver.
Signed-off-by: Bhaktipriya Shridhar
---
drivers/usb/misc/lvstest.c | 17 +++--
1 file changed, 3 insertions(+), 14 deletions(-)
diff --git a/drivers/usb/misc/lvstest.c b/drivers/usb/misc/lvstest.c
index 86b4e4b..a985cad 100644
--- a/drivers/usb/misc/lvstest.c
+++ b/drivers/usb/misc/lvstest.c
@@ -34,8 +34,6 @@ struct lvs_rh {
struct usb_hub_descriptor descriptor;
/* urb for polling interrupt pipe */
struct urb *urb;
- /* LVS RH work queue */
- struct workqueue_struct *rh_queue;
/* LVH RH work */
struct work_struct rh_work;
/* RH port status */
@@ -355,7 +353,7 @@ static void lvs_rh_irq(struct urb *urb)
{
struct lvs_rh *lvs = urb->context;
- queue_work(lvs->rh_queue, &lvs->rh_work);
+ schedule_work(&lvs->rh_work);
}
static int lvs_rh_probe(struct usb_interface *intf,
@@ -402,19 +400,12 @@ static int lvs_rh_probe(struct usb_interface *intf,
return -ENOMEM;
}
- lvs->rh_queue = create_singlethread_workqueue("lvs_rh_queue");
- if (!lvs->rh_queue) {
- dev_err(&intf->dev, "couldn't create workqueue\n");
- ret = -ENOMEM;
- goto free_urb;
- }
-
INIT_WORK(&lvs->rh_work, lvs_rh_work);
ret = sysfs_create_group(&intf->dev.kobj, &lvs_attr_group);
if (ret < 0) {
dev_err(&intf->dev, "Failed to create sysfs node %d\n", ret);
- goto destroy_queue;
+ goto free_urb;
}
pipe = usb_rcvintpipe(hdev, endpoint->bEndpointAddress);
@@ -432,8 +423,6 @@ static int lvs_rh_probe(struct usb_interface *intf,
sysfs_remove:
sysfs_remove_group(&intf->dev.kobj, &lvs_attr_group);
-destroy_queue:
- destroy_workqueue(lvs->rh_queue);
free_urb:
usb_free_urb(lvs->urb);
return ret;
@@ -444,7 +433,7 @@ static void lvs_rh_disconnect(struct usb_interface *intf)
struct lvs_rh *lvs = usb_get_intfdata(intf);
sysfs_remove_group(&intf->dev.kobj, &lvs_attr_group);
- destroy_workqueue(lvs->rh_queue);
+ flush_work(&lvs->rh_work);
usb_free_urb(lvs->urb);
}
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
xhci_hcd crash on linux 4.7.0
Hello all, Hope this is the right place to report a bug; if not, please direct me to where it should go. I am running a mainline kernel build by the Ubuntu mainline PPA, on a 2015 Macbook. It is being tainted by use of the vboxdrv module. I am repeatedly getting errors on xhci_hcd irq handler. There is detailed data below. I generally associate the error with plugging in the external mouse, but I can't reproduce reliably. The relevant trace in dmesg are listed below: [ 699.935961] [ cut here ] [ 699.935971] WARNING: CPU: 2 PID: 0 at /home/kernel/COD/linux/lib/list_debug.c:59 handle_cmd_completion+0x4db/0xc60 [xhci_hcd] [ 699.935972] list_del corruption. prev->next should be 8800829fc680, but was 8801c12ad5c0 [ 699.935973] Modules linked in: fuse asix usbnet libphy mii rfcomm bnep zram zsmalloc lz4_compress nls_utf8 nls_cp437 vfat intel_rapl x86_pkg_temp_thermal intel_powerclamp coretemp fat kvm _intel kvm irqbypass crct10dif_pclmul crc32_pclmul applesmc input_polldev ghash_clmulni_intel hmac drbg ansi_cprng efi_pstore joydev aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_help er cryptd intel_cstate intel_rapl_perf sg efivars intel_pch_thermal btusb btrtl btbcm btintel bluetooth thunderbolt bcm5974 brcmfmac brcmutil cfg80211 snd_hda_codec_cirrus snd_hda_codec_hdmi snd_hda_codec_generic snd_hda_intel snd_hda_codec mmc_core snd_seq_midi snd_seq_midi_event rfkill snd_rawmidi lpc_ich mfd_core snd_hda_core snd_hwdep snd_seq snd_pcm mei_me mei shpchp snd_s eq_device snd_timer snd sbs acpi_als kfifo_buf sbshc [ 699.936004] industrialio apple_bl soundcore battery ac evdev tpm_tis tpm binfmt_misc pci_stub vboxpci(OE) vboxnetflt(OE) vboxnetadp(OE) vboxdrv(OE) parport_pc ppdev lp parport nfsd auth_ rpcgss nfs_acl lockd grace sunrpc efivarfs autofs4 ext4 crc16 jbd2 mbcache sd_mod hid_microsoft hid_apple uas usb_storage hid_generic usbhid hid crc32c_intel ahci libahci libata scsi_mod i91 5 i2c_algo_bit drm_kms_helper video xhci_pci drm xhci_hcd fjes usbcore usb_common button [ 699.936025] CPU: 2 PID: 0 Comm: swapper/2 Tainted: G OE 4.7.0-040700-generic #201607241632 [ 699.936026] Hardware name: Apple Inc. MacBookPro12,1/Mac-E43C1C25D4880AD6, BIOS MBP121.88Z.0167.B17.1606231721 06/23/2016 [ 699.936027] 0086 635d5f6d3a177785 81321405 88026ec83d90 [ 699.936029] 81078a3e 8800829fc690 88026ec83de8 [ 699.936030] 880264fa6258 8800829fc680 88025f75e840 [ 699.936032] Call Trace: [ 699.936033][] ? dump_stack+0x5c/0x77 [ 699.936038] [] ? __warn+0xbe/0xe0 [ 699.936040] [] ? warn_slowpath_fmt+0x5f/0x80 [ 699.936044] [] ? handle_cmd_completion+0x4db/0xc60 [xhci_hcd] [ 699.936047] [] ? xhci_irq+0x326/0xb00 [xhci_hcd] [ 699.936049] [] ? hrtimer_get_next_event+0x3d/0x60 [ 699.936051] [] ? handle_irq_event_percpu+0x78/0x1b0 [ 699.936053] [] ? handle_irq_event+0x39/0x60 [ 699.936054] [] ? handle_edge_irq+0x7b/0x140 [ 699.936056] [] ? handle_irq+0x19/0x30 [ 699.936058] [] ? do_IRQ+0x46/0xd0 [ 699.936060] [] ? common_interrupt+0x82/0x82 [ 699.936060][] ? cpuidle_enter_state+0x126/0x2c0 [ 699.936066] [] ? cpuidle_enter_state+0x113/0x2c0 [ 699.936068] [] ? cpu_startup_entry+0x290/0x330 [ 699.936069] [] ? start_secondary+0x151/0x190 [ 699.936071] ---[ end trace c80c12250204793e ]--- [ 839.946955] [ cut here ] [ 839.946981] WARNING: CPU: 2 PID: 0 at /home/kernel/COD/linux/lib/list_debug.c:59 handle_cmd_completion+0x4db/0xc60 [xhci_hcd] [ 839.946983] list_del corruption. prev->next should be 8800354c7380, but was (null) [ 839.946984] Modules linked in: fuse asix usbnet libphy mii rfcomm bnep zram zsmalloc lz4_compress nls_utf8 nls_cp437 vfat intel_rapl x86_pkg_temp_thermal intel_powerclamp coretemp fat kvm_intel kvm irqbypass crct10dif_pclmul crc32_pclmul applesmc input_polldev ghash_clmulni_intel hmac drbg ansi_cprng efi_pstore joydev aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_helper cryptd intel_cstate intel_rapl_perf sg efivars intel_pch_thermal btusb btrtl btbcm btintel bluetooth thunderbolt bcm5974 brcmfmac brcmutil cfg80211 snd_hda_codec_cirrus snd_hda_codec_hdmi snd_hda_codec_generic snd_hda_intel snd_hda_codec mmc_core snd_seq_midi snd_seq_midi_event rfkill snd_rawmidi lpc_ich mfd_core snd_hda_core snd_hwdep snd_seq snd_pcm mei_me mei shpchp snd_seq_device snd_timer snd sbs acpi_als kfifo_buf sbshc [ 839.947035] industrialio apple_bl soundcore battery ac evdev tpm_tis tpm binfmt_misc pci_stub vboxpci(OE) vboxnetflt(OE) vboxnetadp(OE) vboxdrv(OE) parport_pc ppdev lp parport nfsd auth_rpcgss nfs_acl lockd grace sunrpc efivarfs autofs4 ext4 crc16 jbd2 mbcache sd_mod hid_microsoft hid_apple uas usb_storage hid_generic usbhid hid crc32c_intel ahci libahci libata scsi_mod i915 i2c_algo_bit drm_kms_helper video xhci_pci drm xhci_hcd fjes usbcore usb_common button [ 839.947068] CPU: 2 PID: 0 Comm: s
Re: xhci_hcd crash on linux 4.7.0
On Thu, Jul 28, 2016 at 11:29:41AM +0100, Alex Damian wrote: > Hello all, > > Hope this is the right place to report a bug; if not, please direct me > to where it should go. > > I am running a mainline kernel build by the Ubuntu mainline PPA, on a > 2015 Macbook. It is being tainted by use of the vboxdrv module. I am > repeatedly getting errors on xhci_hcd irq handler. > > There is detailed data below. I generally associate the error with > plugging in the external mouse, but I can't reproduce reliably. > > > The relevant trace in dmesg are listed below: > > [ 699.935961] [ cut here ] > [ 699.935971] WARNING: CPU: 2 PID: 0 at > /home/kernel/COD/linux/lib/list_debug.c:59 > handle_cmd_completion+0x4db/0xc60 [xhci_hcd] > [ 699.935972] list_del corruption. prev->next should be > 8800829fc680, but was 8801c12ad5c0 This isn't a "crash", but just a warning of some kernel debug options. If you can reproduce this without the horrid vboxdrv kernel modules, please let us know, otherwise you are going to have to ask the virtual box developers, as there's nothing we can do if their code is loaded in the kernel (and their code is really really really horrid, seriously, I don't even understand how it is semi-stable at all, it's the stuff of nightmares and there's good reasons why it is not included in the upstream kernel releases.) Best of luck, 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: hub: Fix unbalanced reference count and memory leak
On Wed, 27 Jul 2016, Viresh Kumar wrote:
> If the hub gets disconnected while the core is still activating it, this
> can result in leaking memory of few USB structures.
>
> This will happen if we have done a kref_get() from hub_activate() and
> scheduled a delayed work item for HUB_INIT2/3. Now if hub_disconnect()
> gets called before the delayed work expires, then we will cancel the
> work from hub_quiesce(), but wouldn't do a kref_put(). And so the
> unbalance.
>
> kmemleak reports this as (with the commit e50293ef9775 backported to
> 3.10 kernel with other changes, though the same is true for mainline as
> well):
...
> Fix this by putting the reference in hub_quiesce() if we canceled a
> pending work.
>
> CC: #4.4+
> Fixes: e50293ef9775 ("USB: fix invalid memory access in hub_activate()")
> Signed-off-by: Viresh Kumar
> ---
> Greg,
>
> This is tested over 3.10 with backported patches only, sorry didn't had
> a mainline setup to test this out. :(
Arg. This is exactly the sort of thing I should have foreseen when
writing the earlier commit.
> drivers/usb/core/hub.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
> index bee13517676f..3173693fa8e3 100644
> --- a/drivers/usb/core/hub.c
> +++ b/drivers/usb/core/hub.c
> @@ -1315,7 +1315,8 @@ static void hub_quiesce(struct usb_hub *hub, enum
> hub_quiescing_type type)
> struct usb_device *hdev = hub->hdev;
> int i;
>
> - cancel_delayed_work_sync(&hub->init_work);
> + if (cancel_delayed_work_sync(&hub->init_work))
> + kref_put(&hub->kref, hub_release);
>
> /* hub_wq and related activity won't re-trigger */
> hub->quiescing = 1;
Another possibility is to remove the cancel_delayed_work_sync call
entirely. Either way, you can add
Acked-by: Alan Stern
Alan Stern
--
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: hub: Fix unbalanced reference count and memory leak
On 28-07-16, 10:13, Alan Stern wrote:
> On Wed, 27 Jul 2016, Viresh Kumar wrote:
>
> > If the hub gets disconnected while the core is still activating it, this
> > can result in leaking memory of few USB structures.
> >
> > This will happen if we have done a kref_get() from hub_activate() and
> > scheduled a delayed work item for HUB_INIT2/3. Now if hub_disconnect()
> > gets called before the delayed work expires, then we will cancel the
> > work from hub_quiesce(), but wouldn't do a kref_put(). And so the
> > unbalance.
> >
> > kmemleak reports this as (with the commit e50293ef9775 backported to
> > 3.10 kernel with other changes, though the same is true for mainline as
> > well):
>
> ...
>
> > Fix this by putting the reference in hub_quiesce() if we canceled a
> > pending work.
> >
> > CC: #4.4+
> > Fixes: e50293ef9775 ("USB: fix invalid memory access in hub_activate()")
> > Signed-off-by: Viresh Kumar
> > ---
> > Greg,
> >
> > This is tested over 3.10 with backported patches only, sorry didn't had
> > a mainline setup to test this out. :(
>
> Arg. This is exactly the sort of thing I should have foreseen when
> writing the earlier commit.
>
> > drivers/usb/core/hub.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
> > index bee13517676f..3173693fa8e3 100644
> > --- a/drivers/usb/core/hub.c
> > +++ b/drivers/usb/core/hub.c
> > @@ -1315,7 +1315,8 @@ static void hub_quiesce(struct usb_hub *hub, enum
> > hub_quiescing_type type)
> > struct usb_device *hdev = hub->hdev;
> > int i;
> >
> > - cancel_delayed_work_sync(&hub->init_work);
> > + if (cancel_delayed_work_sync(&hub->init_work))
> > + kref_put(&hub->kref, hub_release);
> >
> > /* hub_wq and related activity won't re-trigger */
> > hub->quiescing = 1;
>
> Another possibility is to remove the cancel_delayed_work_sync call
> entirely. Either way, you can add
>
> Acked-by: Alan Stern
Thanks Alan, I thought about that as well but didn't like it much as
that is unnecessary overhead (timer+work). I mean, we know that the
work is of no use anymore, why keep it around and let it fire? Also,
in the worst case it may end up waking up an idle CPU, which isn't
good as well.
--
viresh
--
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 0/6] power: add power sequence library
Hi, Peter On 07/20/2016 02:40 AM, Peter Chen wrote: > Hi all, > > This is a follow-up for my last power sequence framework patch set [1]. > According to Rob Herring and Ulf Hansson's comments[2], I use a generic > power sequence library for parsing the power sequence elements on DT, > and implement generic power sequence on library. The host driver > can allocate power sequence instance, and calls pwrseq APIs accordingly. > > In future, if there are special power sequence requirements, the special > power sequence library can be created. > > This patch set is tested on i.mx6 sabresx evk using a dts change, I use > two hot-plug devices to simulate this use case, the related binding > change is updated at patch [1/6], The udoo board changes were tested > using my last power sequence patch set.[3] > > Except for hard-wired MMC and USB devices, I find the USB ULPI PHY also > need to power on itself before it can be found by ULPI bus. > > [1] http://www.spinics.net/lists/linux-usb/msg142755.html > [2] http://www.spinics.net/lists/linux-usb/msg143106.html > [3] http://www.spinics.net/lists/linux-usb/msg142815.html > > Changes for v3: > - Delete "power-sequence" property at binding-doc, and change related code > at both library and user code. > - Change binding-doc example node name with Rob's comments > - of_get_named_gpio_flags only gets the gpio, but without setting gpio flags, > add additional code request gpio with proper gpio flags > - Add Philipp Zabel's Ack and MAINTAINER's entry > > Changes for v2: > - Delete "pwrseq" prefix and clock-names for properties at dt binding > - Should use structure not but its pointer for kzalloc > - Since chipidea core has no of_node, let core's of_node equals glue > layer's at core's probe > > Peter Chen (6): > binding-doc: power: pwrseq-generic: add binding doc for generic power > sequence library > power: add power sequence library > binding-doc: usb: usb-device: add optional properties for power > sequencediff --git a/drivers/usb/core/Makefile b/drivers/usb/core/Makefile > index 9780877..da36b78 100644 > --- a/drivers/usb/core/Makefile > +++ b/drivers/usb/core/Makefile > @@ -5,8 +5,9 @@ > usbcore-y := usb.o hub.o hcd.o urb.o message.o driver.o > usbcore-y += config.o file.o buffer.o sysfs.o endpoint.o > usbcore-y += devio.o notify.o generic.o quirks.o devices.o > -usbcore-y += port.o of.o > +usbcore-y += port.o > > +usbcore-$(CONFIG_OF) += of.o > usbcore-$(CONFIG_PCI)+= hcd-pci.o > usbcore-$(CONFIG_ACPI) += usb-acpi.o > > diff --git a/drivers/usb/core/of.c b/drivers/usb/core/of.c > index 2289700..3de4f88 100644 > --- a/drivers/usb/core/of.c > +++ b/drivers/usb/core/of.c > @@ -18,6 +18,7 @@ > */ > > #include > +#include > usb: core: add power sequence handling for USB devices > usb: chipidea: let chipidea core device of_node equal's glue layer > device of_node > ARM: dts: imx6qdl-udoo.dtsi: fix onboard USB HUB property > > .../bindings/power/pwrseq/pwrseq-generic.txt | 48 +++ > .../devicetree/bindings/usb/usb-device.txt | 10 +- > MAINTAINERS| 9 ++ > arch/arm/boot/dts/imx6qdl-udoo.dtsi| 26 ++-- > drivers/power/Kconfig | 1 + > drivers/power/Makefile | 1 + > drivers/power/pwrseq/Kconfig | 20 +++ > drivers/power/pwrseq/Makefile | 2 + > drivers/power/pwrseq/core.c| 71 ++ > drivers/power/pwrseq/pwrseq_generic.c | 151 > + > drivers/usb/chipidea/core.c| 10 ++ > drivers/usb/core/Makefile | 1 + > drivers/usb/core/hub.c | 12 +- > drivers/usb/core/hub.h | 12 ++ > drivers/usb/core/pwrseq.c | 100 ++ > include/linux/power/pwrseq.h | 50 +++ > 16 files changed, 507 insertions(+), 17 deletions(-) > create mode 100644 > Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt > create mode 100644 drivers/power/pwrseq/Kconfig > create mode 100644 drivers/power/pwrseq/Makefile > create mode 100644 drivers/power/pwrseq/core.c > create mode 100644 drivers/power/pwrseq/pwrseq_generic.c > create mode 100644 drivers/usb/core/pwrseq.c > create mode 100644 include/linux/power/pwrseq.h > With these patches our on-board USB hub, a Microchip USB2513BI-AEZG, works exactly as it does with the fake regulator kludge, so... Tested-by Joshua Clayton I assume there is a v4 coming due to rmk's comments on patch 5. I couldn't figure out where to null the of_node in error paths, but in testing we did put a line of code to null the of_node on release. but... As an aside, I was hoping this series would magically fix a problem with the imx6q-evi which has forced us to disabl
Re: pwc over musb: 100% frame drop (lost) on high resolution stream
Hello,
I've just bisected commit, which fixed the issue in v4.7
commit 9fa64d6424adabf0e3a546ae24d01a62a927b342
Merge: f55532a febce40
Author: Rafael J. Wysocki
Date: Sat Apr 2 01:07:17 2016 +0200
Merge back intel_pstate fixes for v4.6.
* pm-cpufreq:
intel_pstate: Avoid extra invocation of intel_pstate_sample()
intel_pstate: Do not set utilization update hook too early
Unfortunately, intel_pstate branch doesn't have
f551e13529833e052f75ec628a8af7b034af20f9 applied.
I'll try to bisect this branch with the patch manually applied.
2016-07-27 20:34 GMT+03:00 Matwey V. Kornilov :
> Hello,
>
> I've just biseced commit, which introduced this issue
>
> commit f551e13529833e052f75ec628a8af7b034af20f9
> Author: Bin Liu
> Date: Mon Apr 25 15:53:30 2016 -0500
>
> Revert "usb: musb: musb_host: Enable HCD_BH flag to handle urb
> return in bottom half"
>
> I have not checked yet, if it was intentionnaly fixed.
>
> 2016-07-23 22:24 GMT+03:00 Matwey V. Kornilov :
>> 2016-07-20 21:56 GMT+03:00 Matwey V. Kornilov :
>>> 2016-07-20 18:06 GMT+03:00 Bin Liu :
Hi,
On Wed, Jul 20, 2016 at 05:44:56PM +0300, Matwey V. Kornilov wrote:
> 2016-07-20 17:13 GMT+03:00 Bin Liu :
> > Hi,
> >
> > On Wed, Jul 20, 2016 at 09:09:42AM +0300, Matwey V. Kornilov wrote:
> >> 2016-07-20 0:34 GMT+03:00 Bin Liu :
> >> > Hi,
> >> >
> >> > On Wed, Jul 20, 2016 at 12:25:44AM +0300, Matwey V. Kornilov wrote:
> >> >> 2016-07-19 23:56 GMT+03:00 Bin Liu :
> >> >> > Hi,
> >> >> >
> >> >> > On Tue, Jul 19, 2016 at 11:21:17PM +0300, mat...@sai.msu.ru wrote:
> >> >> >> Hello,
> >> >> >>
> >> >> >> I have Philips SPC 900 camera (0471:0329) connected to my AM335x
> >> >> >> based BeagleBoneBlack SBC.
> >> >> >> I am sure that both of them are fine and work properly.
> >> >> >> I am running Linux 4.6.4 (my kernel config is available at
> >> >> >> https://clck.ru/A2kQs ) and I've just discovered, that there is
> >> >> >> an issue with frame transfer when high resolution formats are
> >> >> >> used.
> >> >> >>
> >> >> >> The issue is the following. I use simple v4l2 example tool
> >> >> >> (taken from API docs), which source code is available at
> >> >> >> http://pastebin.com/grcNXxfe
> >> >> >>
> >> >> >> When I use (see line 488) 640x480 frames
> >> >> >>
> >> >> >> fmt.fmt.pix.width = 640;
> >> >> >> fmt.fmt.pix.height = 480;
> >> >> >>
> >> >> >> then I get "select timeout" and don't get any frames.
> >> >> >>
> >> >> >> When I use 320x240 frames
> >> >> >>
> >> >> >> fmt.fmt.pix.width = 320;
> >> >> >> fmt.fmt.pix.height = 240;
> >> >> >>
> >> >> >> then about 60% frames are missed. An example outpout of ./a.out
> >> >> >> -f is available at https://yadi.sk/d/aRka8xWPtSc4y
> >> >> >> It looks like there are pauses between bulks of frames (frame
> >> >> >> counter and timestamp as returned from v4l2 API):
> >> >> >>
> >> >> >> 3 3705.142553
> >> >> >> 8 3705.342533
> >> >> >> 13 3705.542517
> >> >> >> 110 3708.776208
> >> >> >> 115 3708.976190
> >> >> >> 120 3709.176169
> >> >> >> 125 3709.376152
> >> >> >> 130 3709.576144
> >> >> >> 226 3712.807848
> >> >> >>
> >> >> >> When I use tiny 160x120 frames
> >> >> >>
> >> >> >> fmt.fmt.pix.width = 160;
> >> >> >> fmt.fmt.pix.height = 120;
> >> >> >>
> >> >> >> then more frames are received. See output example at
> >> >> >> https://yadi.sk/d/DedBmH6ftSc9t
> >> >> >> That is why I thought that everything was fine in May when used
> >> >> >> tiny xawtv window to check kernel OOPS presence (see
> >> >> >> http://www.spinics.net/lists/linux-usb/msg141188.html for
> >> >> >> reference)
> >> >> >>
> >> >> >> Even more. When I introduce USB hub between the host and the
> >> >> >> webcam, I can not receive even any 320x240 frames.
> >> >> >>
> >> >> >> I've managed to use ftrace to see what is going on when no
> >> >> >> frames are received.
> >> >> >> I've found that pwc_isoc_handler is called frequently as the
> >> >> >> following:
> >> >> >>
> >> >> >> 0) | pwc_isoc_handler [pwc]() {
> >> >> >> 0) |usb_submit_urb [usbcore]() {
> >> >> >> 0) | usb_submit_urb.part.3 [usbcore]() {
> >> >> >> 0) |usb_hcd_submit_urb [usbcore]() {
> >> >> >> 0) 0.834 us| usb_get_urb [usbcore]();
> >> >> >> 0) | musb_map_urb_for_dma [musb_hdrc]() {
> >> >> >> 0) 0.792 us|usb_hcd_map_urb_for_dma
> >> >> >> [usbcore]();
> >> >> >> 0) 5.750 us| }
> >> >> >> 0) |
Re: [PATCH v3 4/6] usb: core: add power sequence handling for USB devices
Peter, On 07/27/2016 06:45 PM, Peter Chen wrote: > On Wed, Jul 27, 2016 at 09:25:11AM -0700, Joshua Clayton wrote: >> Patch 4 does not apply for me >> (The Makefile has a "usbcore-$(CONFIG_OF) += of.o" >> line which I don't see in 4.7 or linux/next master). >> Is there another patch set this series depends on? > It seems below patch has not been queued: > > https://git.kernel.org/cgit/linux/kernel/git/peter.chen/usb.git/commit/?h=add_pwrseq_for_usb&id=2efd73d0f935ffbc66135553da0ac807c0b4c3fe > > This pwrseq-lib patch set does not depend on it, I will send patch set > on top of a clean mainline next time, sorry for confusing. > Good to know. I just wanted to make sure I wasn't missing something important. Thanks, Joshua Clayton -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
USB vulnerability
Alan, Hi, I am an engineer at Cisco Systems, and this summer we tasked some interns with performing USB fuzzing. One of the interns, Jake Lamberson, was able to cause a kernel panic when emulating an HID keyboard because the OHCI driver fails to reserve bandwidth for the device. Please see the attachment for details. Thank you, Rosie Hall Headline: Linux Kernel Panic Over USB with HID Keyboard wMaxPacketSize Platforms:Ubuntu Versions: Linux Kernel 4.4.0-22-generic CVSS Score: 4.7 CVSS Vector: AV:L/AC:M/Au:N/C:N/I:N/A:C Filed Defects: Related Defects: CWE Tags: Cycle: Found by: Jake Lamberson Linux Kernel panics when using an OHCI controller if a USB device reports being a generic HID keyboard and reports a wMaxPacketSize of over 4095. The OHCI controller driver fails to reserve bandwidth for the device, causing the keyboard handler to fail when attaching to the HID. Later, when the device is removed, the system crashes due to a null pointer dereference in a linked list of endpoint descriptors. The crash can be re-created using a Facedancer and UMAP software. Given an appropriately configured Facedancer and UMAP setup, the crash can be re-created with: sudo board=facedancer21 python3 umap.py -P /dev/serial_device_here -f 03:00:00:E:0046 -l LOG Note: OHCI is a USB 1.1 controller standard that can be included with devices that support either USB 1.1 or 2.0 as their highest USB spec. USB 3.0 devices all use xHCI, which implements USB 1.1, 2.0, and 3.0, making them immune to this particular bug. signature.asc Description: OpenPGP digital signature
Re: [PATCH v3 0/6] power: add power sequence library
Hi Joshua, On Thu, Jul 28, 2016 at 12:56 PM, Joshua Clayton wrote: > I assume there is a v4 coming due to rmk's comments on patch 5. > I couldn't figure out where to null the of_node in error paths, but in testing > we did put a line of code to null the of_node on release. > > but... > As an aside, > I was hoping this series would magically fix a problem > with the imx6q-evi which has forced us to disable > runtime power management. But it did not. :( I also see a similar problem on a mx28 board with a hub. Does it help in your case if you pass 'usbcore.autosuspend=-1' in the kernel command line? Regards, Fabio Estevam -- 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: USB vulnerability
On Thu, Jul 28, 2016 at 12:23:01PM -0400, roswest wrote: > > Alan, > > Hi, I am an engineer at Cisco Systems, and this summer we tasked some > interns with performing USB fuzzing. One of the interns, Jake Lamberson, > was able to cause a kernel panic when emulating an HID keyboard because > the OHCI driver fails to reserve bandwidth for the device. Please see > the attachment for details. > > Thank you, > Rosie Hall > > Headline: Linux Kernel Panic Over USB with HID Keyboard wMaxPacketSize > Platforms:Ubuntu > Versions: Linux Kernel 4.4.0-22-generic > CVSS Score: 4.7 > CVSS Vector: AV:L/AC:M/Au:N/C:N/I:N/A:C > Filed Defects: > Related Defects: > CWE Tags: > Cycle: > Found by: Jake Lamberson > > > Linux Kernel panics when using an OHCI controller if a USB device reports > being > a generic HID keyboard and reports a wMaxPacketSize of over 4095. The OHCI > controller driver fails to reserve bandwidth for the device, causing the > keyboard handler to fail when attaching to the HID. Later, when the device is > removed, the system crashes due to a null pointer dereference in a linked > list > of endpoint descriptors. The crash can be re-created using a Facedancer and > UMAP > software. Given an appropriately configured Facedancer and UMAP setup, the > crash > can be re-created with: > sudo board=facedancer21 python3 umap.py -P /dev/serial_device_here -f > 03:00:00:E:0046 -l LOG > > Note: OHCI is a USB 1.1 controller standard that can be included with devices > that support either USB 1.1 or 2.0 as their highest USB spec. USB 3.0 devices > all use xHCI, which implements USB 1.1, 2.0, and 3.0, making them immune to > this particular bug. Do you happen to have a copy of the oops message from the crash to help let us know where we should be fixing this? Odds are we should just be catching this in the USB core and not be relying on the host controller to get it 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: USB vulnerability
On Thu, 28 Jul 2016, Greg KH wrote: > On Thu, Jul 28, 2016 at 12:23:01PM -0400, roswest wrote: > > > > Alan, > > > > Hi, I am an engineer at Cisco Systems, and this summer we tasked some > > interns with performing USB fuzzing. One of the interns, Jake Lamberson, > > was able to cause a kernel panic when emulating an HID keyboard because > > the OHCI driver fails to reserve bandwidth for the device. Please see > > the attachment for details. > > > > Thank you, > > Rosie Hall > > > > > Headline: Linux Kernel Panic Over USB with HID Keyboard > > wMaxPacketSize > > Platforms:Ubuntu > > Versions: Linux Kernel 4.4.0-22-generic > > CVSS Score: 4.7 > > CVSS Vector: AV:L/AC:M/Au:N/C:N/I:N/A:C > > Filed Defects: > > Related Defects: > > CWE Tags: > > Cycle: > > Found by: Jake Lamberson > > > > > > Linux Kernel panics when using an OHCI controller if a USB device reports > > being > > a generic HID keyboard and reports a wMaxPacketSize of over 4095. The OHCI > > controller driver fails to reserve bandwidth for the device, causing the > > keyboard handler to fail when attaching to the HID. Later, when the device > > is > > removed, the system crashes due to a null pointer dereference in a linked > > list > > of endpoint descriptors. The crash can be re-created using a Facedancer and > > UMAP > > software. Given an appropriately configured Facedancer and UMAP setup, the > > crash > > can be re-created with: > > sudo board=facedancer21 python3 umap.py -P /dev/serial_device_here -f > > 03:00:00:E:0046 -l LOG > > > > Note: OHCI is a USB 1.1 controller standard that can be included with > > devices > > that support either USB 1.1 or 2.0 as their highest USB spec. USB 3.0 > > devices > > all use xHCI, which implements USB 1.1, 2.0, and 3.0, making them immune to > > this particular bug. > > Do you happen to have a copy of the oops message from the crash to help > let us know where we should be fixing this? Odds are we should just be > catching this in the USB core and not be relying on the host controller > to get it right. Only bits 10..0 of the wMaxPacketSize field contain the maximum packet size; bits 12..11 contain something else (valid only for high-speed periodic endpoints) and bits 15..13 are reserved (see Table 9-13 in the USB-2.0 spec). Furthermore, the value in bits 10..0 is never supposed to be larger than 1024 (or less depending on the speed and the endpoint type). We should check these things in config.c/usb_parse_endpoint(). I will whip up a patch for this shortly. Alan Stern -- 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: USB vulnerability
Greg, Oops message attached. Rosie Hall On Thu Jul 28 2016 12:45:06 GMT-0400 (EDT), Greg KH wrote: > On Thu, Jul 28, 2016 at 12:23:01PM -0400, roswest wrote: >> >> Alan, >> >> Hi, I am an engineer at Cisco Systems, and this summer we tasked some >> interns with performing USB fuzzing. One of the interns, Jake Lamberson, >> was able to cause a kernel panic when emulating an HID keyboard because >> the OHCI driver fails to reserve bandwidth for the device. Please see >> the attachment for details. >> >> Thank you, >> Rosie Hall > >> >> Headline: Linux Kernel Panic Over USB with HID Keyboard >> wMaxPacketSize >> Platforms:Ubuntu >> Versions: Linux Kernel 4.4.0-22-generic >> CVSS Score: 4.7 >> CVSS Vector: AV:L/AC:M/Au:N/C:N/I:N/A:C >> Filed Defects: >> Related Defects: >> CWE Tags: >> Cycle: >> Found by: Jake Lamberson >> >> >> Linux Kernel panics when using an OHCI controller if a USB device reports >> being >> a generic HID keyboard and reports a wMaxPacketSize of over 4095. The OHCI >> controller driver fails to reserve bandwidth for the device, causing the >> keyboard handler to fail when attaching to the HID. Later, when the device >> is >> removed, the system crashes due to a null pointer dereference in a linked >> list >> of endpoint descriptors. The crash can be re-created using a Facedancer and >> UMAP >> software. Given an appropriately configured Facedancer and UMAP setup, the >> crash >> can be re-created with: >> sudo board=facedancer21 python3 umap.py -P /dev/serial_device_here -f >> 03:00:00:E:0046 -l LOG >> >> Note: OHCI is a USB 1.1 controller standard that can be included with devices >> that support either USB 1.1 or 2.0 as their highest USB spec. USB 3.0 devices >> all use xHCI, which implements USB 1.1, 2.0, and 3.0, making them immune to >> this particular bug. > > Do you happen to have a copy of the oops message from the crash to help > let us know where we should be fixing this? Odds are we should just be > catching this in the USB core and not be relying on the host controller > to get it right. > > thanks, > > greg k-h > oops_info.tar.gz Description: GNU Zip compressed data signature.asc Description: OpenPGP digital signature
[PATCH v3] usb: serial: ftdi_sio Added 0a5c:6422 device ID for WICED USB UART dev board
BCM20706V2_EVAL is a WICED dev board designed with FT2232H USB 2.0 UART/FIFO IC.
To support BCM920706V2_EVAL dev board for WICED development on Linux. Add the
VID(0a5c) and
PID(6422) to ftdi_sio driver to allow loading ftdi_sio for this board.
Signed-off-by: Sheng-Hui Chu
---
drivers/usb/serial/ftdi_sio.c | 1 +
drivers/usb/serial/ftdi_sio_ids.h | 6
2 files changed, 7 insertions(+)
diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
index 0082080..ef19af4 100644
--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -1008,6 +1008,7 @@ static const struct usb_device_id id_table_combined[] = {
{ USB_DEVICE(ICPDAS_VID, ICPDAS_I7560U_PID) },
{ USB_DEVICE(ICPDAS_VID, ICPDAS_I7561U_PID) },
{ USB_DEVICE(ICPDAS_VID, ICPDAS_I7563U_PID) },
+{ USB_DEVICE(WICED_USB_VID, WICED_USB20706V2_PID) },
{ }/* Terminating entry */
};
diff --git a/drivers/usb/serial/ftdi_sio_ids.h
b/drivers/usb/serial/ftdi_sio_ids.h
index c5d6c1e..b29f280 100644
--- a/drivers/usb/serial/ftdi_sio_ids.h
+++ b/drivers/usb/serial/ftdi_sio_ids.h
@@ -1485,3 +1485,11 @@
#define CHETCO_SEASMART_DISPLAY_PID0xA5AD /* SeaSmart NMEA2000 Display */
#define CHETCO_SEASMART_LITE_PID0xA5AE /* SeaSmart Lite USB Adapter */
#define CHETCO_SEASMART_ANALOG_PID0xA5AF /* SeaSmart Analog Adapter */
+
+/*
+ * WICED USB UART
+ */
+#define WICED_USB_VID0x0A5C
+#define WICED_USB20706V2_PID0x6422
--
2.1.4
This message and any attachments may contain Cypress (or its subsidiaries)
confidential information. If it has been received in error, please advise the
sender and immediately delete this message.
--
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
[PACTH v1] cdc-wdm: Clear read pipeline in case of error
From: Prathmesh Prabhu
Implemented queued response handling. This queue is processed every time the
WDM_READ flag is cleared.
In case of a read error, userspace may not actually read the data, since the
driver returns an error through wdm_poll. After this, the underlying device may
attempt to send us more data, but the queue is not processed. While userspace is
also blocked, because the read error is never cleared.
After this patch, we proactively process the queue on a read error. If there was
an outstanding response to handle, that will clear the error (or go through the
same logic again, if another read error occurs). If there was no outstanding
response, this will bring the queue size back to 0, unblocking a future response
from the underlying device.
Signed-off-by: Prathmesh Prabhu
Tested-by: Robert Foss
Signed-off-by: Robert Foss
---
drivers/usb/class/cdc-wdm.c | 34 +-
1 file changed, 25 insertions(+), 9 deletions(-)
diff --git a/drivers/usb/class/cdc-wdm.c b/drivers/usb/class/cdc-wdm.c
index 337948c..521011c 100644
--- a/drivers/usb/class/cdc-wdm.c
+++ b/drivers/usb/class/cdc-wdm.c
@@ -154,6 +154,9 @@ static void wdm_out_callback(struct urb *urb)
wake_up(&desc->wait);
}
+/* forward declaration */
+static int service_outstanding_interrupt(struct wdm_device *desc);
+
static void wdm_in_callback(struct urb *urb)
{
struct wdm_device *desc = urb->context;
@@ -201,9 +204,22 @@ static void wdm_in_callback(struct urb *urb)
}
}
skip_error:
+ set_bit(WDM_READ, &desc->flags);
wake_up(&desc->wait);
- set_bit(WDM_READ, &desc->flags);
+ if (desc->rerr) {
+ /*
+* Since there was an error, userspace may decide to not read
+* any data after poll'ing.
+* We should respond to further attempts from the device to send
+* data, so that we can get unstuck.
+* Note that, this means it is no longer guaranteed that
+* userspace will see desc->rerr, since the device could send us
+* new data before userspace has a chance to see the error.
+*/
+ service_outstanding_interrupt(desc);
+ }
+
spin_unlock(&desc->iuspin);
}
@@ -436,17 +452,14 @@ out_free_mem:
}
/*
- * clear WDM_READ flag and possibly submit the read urb if resp_count
- * is non-zero.
+ * Submit the read urb if resp_count is non-zero.
*
* Called with desc->iuspin locked
*/
-static int clear_wdm_read_flag(struct wdm_device *desc)
+static int service_outstanding_interrupt(struct wdm_device *desc)
{
int rv = 0;
- clear_bit(WDM_READ, &desc->flags);
-
/* submit read urb only if the device is waiting for it */
if (!desc->resp_count || !--desc->resp_count)
goto out;
@@ -538,7 +551,8 @@ retry:
if (!desc->reslength) { /* zero length read */
dev_dbg(&desc->intf->dev, "%s: zero length - clearing
WDM_READ\n", __func__);
- rv = clear_wdm_read_flag(desc);
+ clear_bit(WDM_READ, &desc->flags);
+ rv = service_outstanding_interrupt(desc);
spin_unlock_irq(&desc->iuspin);
if (rv < 0)
goto err;
@@ -563,8 +577,10 @@ retry:
desc->length -= cntr;
/* in case we had outstanding data */
- if (!desc->length)
- clear_wdm_read_flag(desc);
+ if (!desc->length) {
+ clear_bit(WDM_READ, &desc->flags);
+ service_outstanding_interrupt(desc);
+ }
spin_unlock_irq(&desc->iuspin);
rv = cntr;
--
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] USB: ftdi_sio: Added custom PIDs for Ivium Technologies electrochemical interface products
Ivium Technologies uses the FTDI VID with custom PIDs for their line of
electrochemical interfaces and the PalmSens they developed for PalmSens BV.
PIDs are kept in numerical order, entries in id_table_combined[] are at
the same position as far as possible.
Signed-off-by: Robert Delien
---
drivers/usb/serial/ftdi_sio.c | 2 ++
drivers/usb/serial/ftdi_sio_ids.h | 6 ++
2 files changed, 8 insertions(+)
diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
index 0082080..8962cdc 100644
--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -648,6 +648,8 @@ static const struct usb_device_id id_table_combined[] = {
{ USB_DEVICE(FTDI_VID, FTDI_ELV_TFD128_PID) },
{ USB_DEVICE(FTDI_VID, FTDI_ELV_FM3RX_PID) },
{ USB_DEVICE(FTDI_VID, FTDI_ELV_WS777_PID) },
+ { USB_DEVICE(FTDI_VID, FTDI_PALMSENS_PID) },
+ { USB_DEVICE(FTDI_VID, FTDI_IVIUM_XSTAT_PID) },
{ USB_DEVICE(FTDI_VID, LINX_SDMUSBQSS_PID) },
{ USB_DEVICE(FTDI_VID, LINX_MASTERDEVEL2_PID) },
{ USB_DEVICE(FTDI_VID, LINX_FUTURE_0_PID) },
diff --git a/drivers/usb/serial/ftdi_sio_ids.h
b/drivers/usb/serial/ftdi_sio_ids.h
index c5d6c1e..067e3a6 100644
--- a/drivers/usb/serial/ftdi_sio_ids.h
+++ b/drivers/usb/serial/ftdi_sio_ids.h
@@ -406,6 +406,12 @@
#define FTDI_4N_GALAXY_DE_3_PID0xF3C2
/*
+ * Ivium Technologies product IDs
+ */
+#define FTDI_PALMSENS_PID 0xf440
+#define FTDI_IVIUM_XSTAT_PID 0xf441
+
+/*
* Linx Technologies product ids
*/
#define LINX_SDMUSBQSS_PID 0xF448 /* Linx SDM-USB-QS-S */
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] usb: serial: ftdi_sio Added 0a5c:6422 device ID for WICED USB UART dev board
On Thu, Jul 28, 2016 at 01:38:22PM +, Sheng-Hui Chu wrote:
> BCM20706V2_EVAL is a WICED dev board designed with FT2232H USB 2.0 UART/FIFO
> IC.
>
> To support BCM920706V2_EVAL dev board for WICED development on Linux. Add
> the VID(0a5c) and
> PID(6422) to ftdi_sio driver to allow loading ftdi_sio for this board.
>
> Signed-off-by: Sheng-Hui Chu
> ---
> drivers/usb/serial/ftdi_sio.c | 1 +
> drivers/usb/serial/ftdi_sio_ids.h | 6
> 2 files changed, 7 insertions(+)
>
> diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
> index 0082080..ef19af4 100644
> --- a/drivers/usb/serial/ftdi_sio.c
> +++ b/drivers/usb/serial/ftdi_sio.c
> @@ -1008,6 +1008,7 @@ static const struct usb_device_id id_table_combined[] =
> {
> { USB_DEVICE(ICPDAS_VID, ICPDAS_I7560U_PID) },
> { USB_DEVICE(ICPDAS_VID, ICPDAS_I7561U_PID) },
> { USB_DEVICE(ICPDAS_VID, ICPDAS_I7563U_PID) },
> +{ USB_DEVICE(WICED_USB_VID, WICED_USB20706V2_PID) },
> { }/* Terminating entry */
> };
All whitespace was eaten by your email client, so we can't even apply
this patch :(
Can you use 'git send-email' instead? That should work properly.
And please use scripts/get_maintainer.pl on your patch to know who to
copy on the patch.
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: USB vulnerability
On Thu, 28 Jul 2016, Alan Stern wrote:
> Only bits 10..0 of the wMaxPacketSize field contain the maximum packet
> size; bits 12..11 contain something else (valid only for high-speed
> periodic endpoints) and bits 15..13 are reserved (see Table 9-13 in the
> USB-2.0 spec).
>
> Furthermore, the value in bits 10..0 is never supposed to be larger
> than 1024 (or less depending on the speed and the endpoint type). We
> should check these things in config.c/usb_parse_endpoint().
>
> I will whip up a patch for this shortly.
And here it is. Rosie, can you or your intern check that this fixes
the problem?
Alan Stern
Index: usb-4.x/drivers/usb/core/config.c
===
--- usb-4.x.orig/drivers/usb/core/config.c
+++ usb-4.x/drivers/usb/core/config.c
@@ -171,6 +171,31 @@ static void usb_parse_ss_endpoint_compan
ep, buffer, size);
}
+static const unsigned short low_speed_maxpacket_maxes[4] = {
+ [USB_ENDPOINT_XFER_CONTROL] = 8,
+ [USB_ENDPOINT_XFER_ISOC] = 0,
+ [USB_ENDPOINT_XFER_BULK] = 0,
+ [USB_ENDPOINT_XFER_INT] = 8,
+};
+static const unsigned short full_speed_maxpacket_maxes[4] = {
+ [USB_ENDPOINT_XFER_CONTROL] = 64,
+ [USB_ENDPOINT_XFER_ISOC] = 1023,
+ [USB_ENDPOINT_XFER_BULK] = 64,
+ [USB_ENDPOINT_XFER_INT] = 64,
+};
+static const unsigned short high_speed_maxpacket_maxes[4] = {
+ [USB_ENDPOINT_XFER_CONTROL] = 64,
+ [USB_ENDPOINT_XFER_ISOC] = 1024,
+ [USB_ENDPOINT_XFER_BULK] = 512,
+ [USB_ENDPOINT_XFER_INT] = 1023,
+};
+static const unsigned short super_speed_maxpacket_maxes[4] = {
+ [USB_ENDPOINT_XFER_CONTROL] = 512,
+ [USB_ENDPOINT_XFER_ISOC] = 1024,
+ [USB_ENDPOINT_XFER_BULK] = 1024,
+ [USB_ENDPOINT_XFER_INT] = 1024,
+};
+
static int usb_parse_endpoint(struct device *ddev, int cfgno, int inum,
int asnum, struct usb_host_interface *ifp, int num_ep,
unsigned char *buffer, int size)
@@ -179,6 +204,8 @@ static int usb_parse_endpoint(struct dev
struct usb_endpoint_descriptor *d;
struct usb_host_endpoint *endpoint;
int n, i, j, retval;
+ unsigned int maxp;
+ const unsigned short *maxpacket_maxes;
d = (struct usb_endpoint_descriptor *) buffer;
buffer += d->bLength;
@@ -290,6 +317,42 @@ static int usb_parse_endpoint(struct dev
endpoint->desc.wMaxPacketSize = cpu_to_le16(8);
}
+ /* Validate the wMaxPacketSize field */
+ maxp = usb_endpoint_maxp(&endpoint->desc);
+
+ /* Find the highest legal maxpacket size for this endpoint */
+ i = 0; /* additional transactions per microframe */
+ switch (to_usb_device(ddev)->speed) {
+ case USB_SPEED_LOW:
+ maxpacket_maxes = low_speed_maxpacket_maxes;
+ break;
+ case USB_SPEED_FULL:
+ maxpacket_maxes = full_speed_maxpacket_maxes;
+ break;
+ case USB_SPEED_HIGH:
+ /* Bits 12..11 are allowed only for HS periodic endpoints */
+ if (usb_endpoint_xfer_int(d) || usb_endpoint_xfer_isoc(d)) {
+ i = maxp & (BIT(12) | BIT(11));
+ maxp &= ~i;
+ }
+ /* fallthrough */
+ default:
+ maxpacket_maxes = high_speed_maxpacket_maxes;
+ break;
+ case USB_SPEED_SUPER:
+ case USB_SPEED_SUPER_PLUS:
+ maxpacket_maxes = super_speed_maxpacket_maxes;
+ break;
+ }
+ j = maxpacket_maxes[usb_endpoint_type(&endpoint->desc)];
+
+ if (maxp > j) {
+ dev_warn(ddev, "config %d interface %d altsetting %d endpoint
0x%X has invalid maxpacket %d, setting to %d\n",
+ cfgno, inum, asnum, d->bEndpointAddress, maxp, j);
+ maxp = j;
+ endpoint->desc.wMaxPacketSize = cpu_to_le16(i | maxp);
+ }
+
/*
* Some buggy high speed devices have bulk endpoints using
* maxpacket sizes other than 512. High speed HCDs may not
@@ -297,9 +360,6 @@ static int usb_parse_endpoint(struct dev
*/
if (to_usb_device(ddev)->speed == USB_SPEED_HIGH
&& usb_endpoint_xfer_bulk(d)) {
- unsigned maxp;
-
- maxp = usb_endpoint_maxp(&endpoint->desc) & 0x07ff;
if (maxp != 512)
dev_warn(ddev, "config %d interface %d altsetting %d "
"bulk endpoint 0x%X has invalid maxpacket %d\n",
--
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: USB vulnerability
On Thu, 28 Jul 2016, Alan Stern wrote:
> On Thu, 28 Jul 2016, Greg KH wrote:
>
> > On Thu, Jul 28, 2016 at 12:23:01PM -0400, roswest wrote:
> > >
> > > Alan,
> > >
> > > Hi, I am an engineer at Cisco Systems, and this summer we tasked some
> > > interns with performing USB fuzzing. One of the interns, Jake Lamberson,
> > > was able to cause a kernel panic when emulating an HID keyboard because
> > > the OHCI driver fails to reserve bandwidth for the device. Please see
> > > the attachment for details.
> > >
> > > Thank you,
> > > Rosie Hall
> >
> > >
> > > Headline: Linux Kernel Panic Over USB with HID Keyboard
> > > wMaxPacketSize
> > > Platforms:Ubuntu
> > > Versions: Linux Kernel 4.4.0-22-generic
> > > CVSS Score: 4.7
> > > CVSS Vector: AV:L/AC:M/Au:N/C:N/I:N/A:C
> > > Filed Defects:
> > > Related Defects:
> > > CWE Tags:
> > > Cycle:
> > > Found by: Jake Lamberson
> > >
> > >
> > > Linux Kernel panics when using an OHCI controller if a USB device reports
> > > being
> > > a generic HID keyboard and reports a wMaxPacketSize of over 4095. The OHCI
> > > controller driver fails to reserve bandwidth for the device, causing the
> > > keyboard handler to fail when attaching to the HID. Later, when the
> > > device is
> > > removed, the system crashes due to a null pointer dereference in a linked
> > > list
> > > of endpoint descriptors. The crash can be re-created using a Facedancer
> > > and UMAP
> > > software. Given an appropriately configured Facedancer and UMAP setup,
> > > the crash
> > > can be re-created with:
> > > sudo board=facedancer21 python3 umap.py -P /dev/serial_device_here -f
> > > 03:00:00:E:0046 -l LOG
I forgot to mention that the original NULL-pointer dereference bug
should already be fixed by commit c66f59ee5050 ("USB: OHCI: Don't mark
EDs as ED_OPER if scheduling fails"). However I don't know if this
commit has been back-ported to the kernel being tested.
Alan Stern
--
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 v4] usb: serial: ftdi_sio Added 0a5c:6422 device ID for WICED USB UART dev board
BCM20706V2_EVAL is a WICED dev board designed with FT2232H USB 2.0 UART/FIFO
IC.
To support BCM920706V2_EVAL dev board for WICED development on Linux. Add
the VID(0a5c) and
PID(6422) to ftdi_sio driver to allow loading ftdi_sio for this board.
Signed-off-by: Sheng-Hui J. Chu
---
drivers/usb/serial/ftdi_sio.c | 1 +
drivers/usb/serial/ftdi_sio_ids.h | 6
2 files changed, 7 insertions(+)
diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
index 0082080..ef19af4 100644
--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -1008,6 +1008,7 @@ static const struct usb_device_id id_table_combined[]
= {
{ USB_DEVICE(ICPDAS_VID, ICPDAS_I7560U_PID) },
{ USB_DEVICE(ICPDAS_VID, ICPDAS_I7561U_PID) },
{ USB_DEVICE(ICPDAS_VID, ICPDAS_I7563U_PID) },
+ { USB_DEVICE(WICED_USB_VID, WICED_USB20706V2_PID) },
{ } /* Terminating entry */
};
diff --git a/drivers/usb/serial/ftdi_sio_ids.h
b/drivers/usb/serial/ftdi_sio_ids.h
index c5d6c1e..b29f280 100644
--- a/drivers/usb/serial/ftdi_sio_ids.h
+++ b/drivers/usb/serial/ftdi_sio_ids.h
@@ -1485,3 +1485,11 @@
#define CHETCO_SEASMART_DISPLAY_PID0xA5AD /* SeaSmart NMEA2000 Display
*/
#define CHETCO_SEASMART_LITE_PID 0xA5AE /* SeaSmart Lite USB Adapter
*/
#define CHETCO_SEASMART_ANALOG_PID 0xA5AF /* SeaSmart Analog Adapter */
+
+/*
+ * WICED USB UART
+ */
+#define WICED_USB_VID 0x0A5C
+#define WICED_USB20706V2_PID 0x6422
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4] usb: serial: ftdi_sio Added 0a5c:6422 device ID for WICED USB UART dev board
On Thu, Jul 28, 2016 at 04:05:40PM -0400, Sheng-Hui J. Chu wrote:
> BCM20706V2_EVAL is a WICED dev board designed with FT2232H USB 2.0 UART/FIFO
> IC.
>
> To support BCM920706V2_EVAL dev board for WICED development on Linux. Add
> the VID(0a5c) and
> PID(6422) to ftdi_sio driver to allow loading ftdi_sio for this board.
>
> Signed-off-by: Sheng-Hui J. Chu
> ---
> drivers/usb/serial/ftdi_sio.c | 1 +
> drivers/usb/serial/ftdi_sio_ids.h | 6
> 2 files changed, 7 insertions(+)
>
> diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
> index 0082080..ef19af4 100644
> --- a/drivers/usb/serial/ftdi_sio.c
> +++ b/drivers/usb/serial/ftdi_sio.c
> @@ -1008,6 +1008,7 @@ static const struct usb_device_id id_table_combined[]
> = {
> { USB_DEVICE(ICPDAS_VID, ICPDAS_I7560U_PID) },
> { USB_DEVICE(ICPDAS_VID, ICPDAS_I7561U_PID) },
> { USB_DEVICE(ICPDAS_VID, ICPDAS_I7563U_PID) },
> + { USB_DEVICE(WICED_USB_VID, WICED_USB20706V2_PID) },
> { } /* Terminating entry */
> };
>
> diff --git a/drivers/usb/serial/ftdi_sio_ids.h
> b/drivers/usb/serial/ftdi_sio_ids.h
> index c5d6c1e..b29f280 100644
> --- a/drivers/usb/serial/ftdi_sio_ids.h
> +++ b/drivers/usb/serial/ftdi_sio_ids.h
> @@ -1485,3 +1485,11 @@
> #define CHETCO_SEASMART_DISPLAY_PID 0xA5AD /* SeaSmart NMEA2000 Display
> */
> #define CHETCO_SEASMART_LITE_PID 0xA5AE /* SeaSmart Lite USB Adapter
> */
Ah, so close!
You have the whitespace issues fixed, but your patch is now line-wrapped :(
5th try?
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5] usb: serial: ftdi_sio Added 0a5c:6422 device ID for WICED USB UART dev board
BCM20706V2_EVAL is a WICED dev board designed with FT2232H USB 2.0 UART/FIFO IC.
To support BCM920706V2_EVAL dev board for WICED development on Linux. Add the
VID(0a5c) and
PID(6422) to ftdi_sio driver to allow loading ftdi_sio for this board.
Signed-off-by: Sheng-Hui Chu
---
drivers/usb/serial/ftdi_sio.c | 1 +
drivers/usb/serial/ftdi_sio_ids.h | 6
2 files changed, 7 insertions(+)
diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
index 0082080..ef19af4 100644
--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -1008,6 +1008,7 @@ static const struct usb_device_id id_table_combined[] = {
{ USB_DEVICE(ICPDAS_VID, ICPDAS_I7560U_PID) },
{ USB_DEVICE(ICPDAS_VID, ICPDAS_I7561U_PID) },
{ USB_DEVICE(ICPDAS_VID, ICPDAS_I7563U_PID) },
+ { USB_DEVICE(WICED_USB_VID, WICED_USB20706V2_PID) },
{ } /* Terminating entry */
};
diff --git a/drivers/usb/serial/ftdi_sio_ids.h
b/drivers/usb/serial/ftdi_sio_ids.h
index c5d6c1e..b29f280 100644
--- a/drivers/usb/serial/ftdi_sio_ids.h
+++ b/drivers/usb/serial/ftdi_sio_ids.h
@@ -1485,3 +1485,11 @@
#define CHETCO_SEASMART_DISPLAY_PID0xA5AD /* SeaSmart NMEA2000 Display */
#define CHETCO_SEASMART_LITE_PID 0xA5AE /* SeaSmart Lite USB Adapter */
#define CHETCO_SEASMART_ANALOG_PID 0xA5AF /* SeaSmart Analog Adapter */
+
+/*
+ * WICED USB UART
+ */
+#define WICED_USB_VID 0x0A5C
+#define WICED_USB20706V2_PID 0x6422
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6] usb: serial: ftdi_sio Added 0a5c:6422 device ID for WICED USB UART dev board
BCM20706V2_EVAL is a WICED dev board designed with FT2232H USB 2.0 UART/FIFO IC.
To support BCM920706V2_EVAL dev board for WICED development on Linux. Add the
VID(0a5c) and
PID(6422) to ftdi_sio driver to allow loading ftdi_sio for this board.
Signed-off-by: Sheng-Hui J. Chu
---
drivers/usb/serial/ftdi_sio.c | 1 +
drivers/usb/serial/ftdi_sio_ids.h | 6
2 files changed, 7 insertions(+)
diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
index 0082080..ef19af4 100644
--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -1008,6 +1008,7 @@ static const struct usb_device_id id_table_combined[] = {
{ USB_DEVICE(ICPDAS_VID, ICPDAS_I7560U_PID) },
{ USB_DEVICE(ICPDAS_VID, ICPDAS_I7561U_PID) },
{ USB_DEVICE(ICPDAS_VID, ICPDAS_I7563U_PID) },
+ { USB_DEVICE(WICED_USB_VID, WICED_USB20706V2_PID) },
{ } /* Terminating entry */
};
diff --git a/drivers/usb/serial/ftdi_sio_ids.h
b/drivers/usb/serial/ftdi_sio_ids.h
index c5d6c1e..b29f280 100644
--- a/drivers/usb/serial/ftdi_sio_ids.h
+++ b/drivers/usb/serial/ftdi_sio_ids.h
@@ -1485,3 +1485,11 @@
#define CHETCO_SEASMART_DISPLAY_PID0xA5AD /* SeaSmart NMEA2000 Display */
#define CHETCO_SEASMART_LITE_PID 0xA5AE /* SeaSmart Lite USB Adapter */
#define CHETCO_SEASMART_ANALOG_PID 0xA5AF /* SeaSmart Analog Adapter */
+
+/*
+ * WICED USB UART
+ */
+#define WICED_USB_VID 0x0A5C
+#define WICED_USB20706V2_PID 0x6422
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB vulnerability
On Thu, Jul 28, 2016 at 04:01:53PM -0400, Alan Stern wrote:
> On Thu, 28 Jul 2016, Alan Stern wrote:
>
> > On Thu, 28 Jul 2016, Greg KH wrote:
> >
> > > On Thu, Jul 28, 2016 at 12:23:01PM -0400, roswest wrote:
> > > >
> > > > Alan,
> > > >
> > > > Hi, I am an engineer at Cisco Systems, and this summer we tasked some
> > > > interns with performing USB fuzzing. One of the interns, Jake Lamberson,
> > > > was able to cause a kernel panic when emulating an HID keyboard because
> > > > the OHCI driver fails to reserve bandwidth for the device. Please see
> > > > the attachment for details.
> > > >
> > > > Thank you,
> > > > Rosie Hall
> > >
> > > >
> > > > Headline: Linux Kernel Panic Over USB with HID Keyboard
> > > > wMaxPacketSize
> > > > Platforms:Ubuntu
> > > > Versions: Linux Kernel 4.4.0-22-generic
> > > > CVSS Score: 4.7
> > > > CVSS Vector: AV:L/AC:M/Au:N/C:N/I:N/A:C
> > > > Filed Defects:
> > > > Related Defects:
> > > > CWE Tags:
> > > > Cycle:
> > > > Found by: Jake Lamberson
> > > >
> > > >
> > > > Linux Kernel panics when using an OHCI controller if a USB device
> > > > reports being
> > > > a generic HID keyboard and reports a wMaxPacketSize of over 4095. The
> > > > OHCI
> > > > controller driver fails to reserve bandwidth for the device, causing
> > > > the
> > > > keyboard handler to fail when attaching to the HID. Later, when the
> > > > device is
> > > > removed, the system crashes due to a null pointer dereference in a
> > > > linked list
> > > > of endpoint descriptors. The crash can be re-created using a Facedancer
> > > > and UMAP
> > > > software. Given an appropriately configured Facedancer and UMAP setup,
> > > > the crash
> > > > can be re-created with:
> > > > sudo board=facedancer21 python3 umap.py -P /dev/serial_device_here -f
> > > > 03:00:00:E:0046 -l LOG
>
> I forgot to mention that the original NULL-pointer dereference bug
> should already be fixed by commit c66f59ee5050 ("USB: OHCI: Don't mark
> EDs as ED_OPER if scheduling fails"). However I don't know if this
> commit has been back-ported to the kernel being tested.
I doubt it, it hasn't even hit the "normal" stable kernels yet, I'll go
do that now...
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6] usb: serial: ftdi_sio Added 0a5c:6422 device ID for WICED USB UART dev board
On Thu, Jul 28, 2016 at 05:01:45PM -0400, Sheng-Hui J. Chu wrote:
> BCM20706V2_EVAL is a WICED dev board designed with FT2232H USB 2.0 UART/FIFO
> IC.
>
> To support BCM920706V2_EVAL dev board for WICED development on Linux. Add
> the VID(0a5c) and
> PID(6422) to ftdi_sio driver to allow loading ftdi_sio for this board.
>
> Signed-off-by: Sheng-Hui J. Chu
> ---
> drivers/usb/serial/ftdi_sio.c | 1 +
> drivers/usb/serial/ftdi_sio_ids.h | 6
> 2 files changed, 7 insertions(+)
>
> diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
> index 0082080..ef19af4 100644
> --- a/drivers/usb/serial/ftdi_sio.c
> +++ b/drivers/usb/serial/ftdi_sio.c
> @@ -1008,6 +1008,7 @@ static const struct usb_device_id id_table_combined[] =
> {
> { USB_DEVICE(ICPDAS_VID, ICPDAS_I7560U_PID) },
> { USB_DEVICE(ICPDAS_VID, ICPDAS_I7561U_PID) },
> { USB_DEVICE(ICPDAS_VID, ICPDAS_I7563U_PID) },
> + { USB_DEVICE(WICED_USB_VID, WICED_USB20706V2_PID) },
> { } /* Terminating entry */
> };
>
> diff --git a/drivers/usb/serial/ftdi_sio_ids.h
> b/drivers/usb/serial/ftdi_sio_ids.h
> index c5d6c1e..b29f280 100644
> --- a/drivers/usb/serial/ftdi_sio_ids.h
> +++ b/drivers/usb/serial/ftdi_sio_ids.h
> @@ -1485,3 +1485,11 @@
> #define CHETCO_SEASMART_DISPLAY_PID 0xA5AD /* SeaSmart NMEA2000 Display */
> #define CHETCO_SEASMART_LITE_PID 0xA5AE /* SeaSmart Lite USB Adapter */
> #define CHETCO_SEASMART_ANALOG_PID 0xA5AF /* SeaSmart Analog Adapter */
> +
> +/*
> + * WICED USB UART
> + */
> +#define WICED_USB_VID0x0A5C
> +#define WICED_USB20706V2_PID 0x6422
> --
> 2.1.4
Yeah!!!
I'll let Johan queue this up, and forward it on to my trees in a few
days. Thanks so much for sticking with this.
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
[PACTH v1 2/2] usb: xhci: plat: Enable async suspend/resume
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 fbd45c2..ce3375d 100644 --- a/drivers/usb/host/xhci-plat.c +++ b/drivers/usb/host/xhci-plat.c @@ -248,6 +248,7 @@ static int xhci_plat_probe(struct platform_device *pdev) pm_runtime_set_active(&pdev->dev); pm_runtime_enable(&pdev->dev); + device_enable_async_suspend(&pdev->dev); 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
[PACTH v1 0/2] usb: xhci: plat: Enable PM, async resume/suspend
From: Robert Foss This series enables runtime PM and asynchronous resume/suspend support for xhci-plat devices. Andrew Bresticker (2): usb: xhci: plat: Enable runtime PM usb: xhci: plat: Enable async suspend/resume drivers/usb/host/xhci-plat.c | 20 ++-- 1 file changed, 18 insertions(+), 2 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
[PACTH v1 1/2] usb: xhci: plat: Enable runtime PM
From: Andrew Bresticker
Enable runtime PM for the xhci-plat device so that the parent device
may implement runtime PM.
Signed-off-by: Andrew Bresticker
Tested-by: Robert Foss
Signed-off-by: Robert Foss
---
drivers/usb/host/xhci-plat.c | 19 +--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index ed56bf9..fbd45c2 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -246,6 +246,9 @@ static int xhci_plat_probe(struct platform_device *pdev)
if (ret)
goto dealloc_usb2_hcd;
+ pm_runtime_set_active(&pdev->dev);
+ pm_runtime_enable(&pdev->dev);
+
return 0;
@@ -274,6 +277,8 @@ static int xhci_plat_remove(struct platform_device *dev)
struct xhci_hcd *xhci = hcd_to_xhci(hcd);
struct clk *clk = xhci->clk;
+ pm_runtime_disable(&dev->dev);
+
usb_remove_hcd(xhci->shared_hcd);
usb_phy_shutdown(hcd->usb_phy);
@@ -292,7 +297,9 @@ static int xhci_plat_suspend(struct device *dev)
{
struct usb_hcd *hcd = dev_get_drvdata(dev);
struct xhci_hcd *xhci = hcd_to_xhci(hcd);
+ int ret;
+ pm_runtime_get_sync(dev);
/*
* xhci_suspend() needs `do_wakeup` to know whether host is allowed
* to do wakeup during suspend. Since xhci_plat_suspend is currently
@@ -301,15 +308,23 @@ static int xhci_plat_suspend(struct device *dev)
* reconsider this when xhci_plat_suspend enlarges its scope, e.g.,
* also applies to runtime suspend.
*/
- return xhci_suspend(xhci, device_may_wakeup(dev));
+ ret = xhci_suspend(xhci, device_may_wakeup(dev));
+ pm_runtime_put(dev);
+
+ return ret;
}
static int xhci_plat_resume(struct device *dev)
{
struct usb_hcd *hcd = dev_get_drvdata(dev);
struct xhci_hcd *xhci = hcd_to_xhci(hcd);
+ int ret;
- return xhci_resume(xhci, 0);
+ pm_runtime_get_sync(dev);
+ ret = xhci_resume(xhci, 0);
+ pm_runtime_put(dev);
+
+ return ret;
}
static const struct dev_pm_ops xhci_plat_pm_ops = {
--
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 v6] usb: serial: ftdi_sio Added 0a5c:6422 device ID for WICED USB UART dev board
From: Greg KH [mailto:gre...@linuxfoundation.org]
Sent: Thursday, July 28, 2016 5:09 PM
To: Sheng-Hui J. Chu
Cc: linux-usb@vger.kernel.org; jo...@kernel.org; linux-ker...@vger.kernel.org
Subject: Re: [PATCH v6] usb: serial: ftdi_sio Added 0a5c:6422 device ID for
WICED USB UART dev board
On Thu, Jul 28, 2016 at 05:01:45PM -0400, Sheng-Hui J. Chu wrote:
> BCM20706V2_EVAL is a WICED dev board designed with FT2232H USB 2.0 UART/FIFO
> IC.
>
> To support BCM920706V2_EVAL dev board for WICED development on Linux. Add
> the VID(0a5c) and
> PID(6422) to ftdi_sio driver to allow loading ftdi_sio for this board.
>
> Signed-off-by: Sheng-Hui J. Chu
> ---
> drivers/usb/serial/ftdi_sio.c | 1 +
> drivers/usb/serial/ftdi_sio_ids.h | 6
> 2 files changed, 7 insertions(+)
>
> diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
> index 0082080..ef19af4 100644
> --- a/drivers/usb/serial/ftdi_sio.c
> +++ b/drivers/usb/serial/ftdi_sio.c
> @@ -1008,6 +1008,7 @@ static const struct usb_device_id id_table_combined[] =
> {
> { USB_DEVICE(ICPDAS_VID, ICPDAS_I7560U_PID) },
> { USB_DEVICE(ICPDAS_VID, ICPDAS_I7561U_PID) },
> { USB_DEVICE(ICPDAS_VID, ICPDAS_I7563U_PID) },
> + { USB_DEVICE(WICED_USB_VID, WICED_USB20706V2_PID) },
> { } /* Terminating entry */
> };
>
> diff --git a/drivers/usb/serial/ftdi_sio_ids.h
> b/drivers/usb/serial/ftdi_sio_ids.h
> index c5d6c1e..b29f280 100644
> --- a/drivers/usb/serial/ftdi_sio_ids.h
> +++ b/drivers/usb/serial/ftdi_sio_ids.h
> @@ -1485,3 +1485,11 @@
> #define CHETCO_SEASMART_DISPLAY_PID 0xA5AD /* SeaSmart NMEA2000 Display */
> #define CHETCO_SEASMART_LITE_PID 0xA5AE /* SeaSmart Lite USB Adapter */
> #define CHETCO_SEASMART_ANALOG_PID 0xA5AF /* SeaSmart Analog Adapter */
> +
> +/*
> + * WICED USB UART
> + */
> +#define WICED_USB_VID0x0A5C
> +#define WICED_USB20706V2_PID 0x6422
> --
> 2.1.4
Yeah!!!
I'll let Johan queue this up, and forward it on to my trees in a few
days. Thanks so much for sticking with this.
greg k-h
Thank you very much for your patience and guidance.
-Jeffrey
--
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: [PACTH v1 0/2] usb: xhci: plat: Enable PM, async resume/suspend
This series should be labelled v2 instead of v1. This series enables runtime PM and asynchronous resume/suspend support for xhci-plat devices. Andrew Bresticker (2): usb: xhci: plat: Enable runtime PM usb: xhci: plat: Enable async suspend/resume drivers/usb/host/xhci-plat.c | 20 ++-- 1 file changed, 18 insertions(+), 2 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] usb: phy: generic: get rid of VBUS handling
Hi, Balbi & Robert
Have one question about commit 7acc9973e3c4 ("usb: phy: generic: add
vbus support").
Sorry asking here.
Commit 7acc9973e3c4 ("usb: phy: generic: add vbus support") is adding
GPIO-based VBUS handling for phy-generic.c
And now we are uploading usb phy to drivers/phy/, as Balbi mentioned
drivers/usb/phy/ will not accept new phy driver.
Any suggestion about handling vbus (gpio) for the phy under drivers/phy/
Thanks
On Fri, Jul 1, 2016 at 6:00 PM, Felipe Balbi
wrote:
>
> Hi Robert,
>
> your commit 7acc9973e3c4 ("usb: phy: generic: add vbus support") added
> GPIO-based VBUS handling for phy-generic.c, but that ends up calling
> usb_gadget_vbus_connect() which forces NOP to depend on the gadget API.
>
> I was grepping around and couldn't find any users for that VBUS gpio
> _and_ we have phy-gpio-vbus.c which does the same thing.
>
> I'm wondering if we should drop the usb_gadget_vbus_connect() support so
> other phy-generic users (like ehci-omap) can rely on it without
> depending on the gadget API.
>
> Thoughts?
>
> --
> balbi
--
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 0/6] power: add power sequence library
On Thu, Jul 28, 2016 at 08:56:40AM -0700, Joshua Clayton wrote: > Hi, Peter > > On 07/20/2016 02:40 AM, Peter Chen wrote: > > Hi all, > > > > This is a follow-up for my last power sequence framework patch set [1]. > > According to Rob Herring and Ulf Hansson's comments[2], I use a generic > > power sequence library for parsing the power sequence elements on DT, > > and implement generic power sequence on library. The host driver > > can allocate power sequence instance, and calls pwrseq APIs accordingly. > > > > In future, if there are special power sequence requirements, the special > > power sequence library can be created. > > > > This patch set is tested on i.mx6 sabresx evk using a dts change, I use > > two hot-plug devices to simulate this use case, the related binding > > change is updated at patch [1/6], The udoo board changes were tested > > using my last power sequence patch set.[3] > > > > Except for hard-wired MMC and USB devices, I find the USB ULPI PHY also > > need to power on itself before it can be found by ULPI bus. > > > > [1] http://www.spinics.net/lists/linux-usb/msg142755.html > > [2] http://www.spinics.net/lists/linux-usb/msg143106.html > > [3] http://www.spinics.net/lists/linux-usb/msg142815.html > > > > Changes for v3: > > - Delete "power-sequence" property at binding-doc, and change related code > > at both library and user code. > > - Change binding-doc example node name with Rob's comments > > - of_get_named_gpio_flags only gets the gpio, but without setting gpio > > flags, > > add additional code request gpio with proper gpio flags > > - Add Philipp Zabel's Ack and MAINTAINER's entry > > > > Changes for v2: > > - Delete "pwrseq" prefix and clock-names for properties at dt binding > > - Should use structure not but its pointer for kzalloc > > - Since chipidea core has no of_node, let core's of_node equals glue > > layer's at core's probe > > > > Peter Chen (6): > > binding-doc: power: pwrseq-generic: add binding doc for generic power > > sequence library > > power: add power sequence library > > binding-doc: usb: usb-device: add optional properties for power > > sequencediff --git a/drivers/usb/core/Makefile > > b/drivers/usb/core/Makefile > > index 9780877..da36b78 100644 > > --- a/drivers/usb/core/Makefile > > +++ b/drivers/usb/core/Makefile > > @@ -5,8 +5,9 @@ > > usbcore-y := usb.o hub.o hcd.o urb.o message.o driver.o > > usbcore-y += config.o file.o buffer.o sysfs.o endpoint.o > > usbcore-y += devio.o notify.o generic.o quirks.o devices.o > > -usbcore-y += port.o of.o > > +usbcore-y += port.o > > > > +usbcore-$(CONFIG_OF) += of.o > > usbcore-$(CONFIG_PCI) += hcd-pci.o > > usbcore-$(CONFIG_ACPI) += usb-acpi.o > > > > diff --git a/drivers/usb/core/of.c b/drivers/usb/core/of.c > > index 2289700..3de4f88 100644 > > --- a/drivers/usb/core/of.c > > +++ b/drivers/usb/core/of.c > > @@ -18,6 +18,7 @@ > > */ > > > > #include > > +#include > > usb: core: add power sequence handling for USB devices > > usb: chipidea: let chipidea core device of_node equal's glue layer > > device of_node > > ARM: dts: imx6qdl-udoo.dtsi: fix onboard USB HUB property > > > > .../bindings/power/pwrseq/pwrseq-generic.txt | 48 +++ > > .../devicetree/bindings/usb/usb-device.txt | 10 +- > > MAINTAINERS| 9 ++ > > arch/arm/boot/dts/imx6qdl-udoo.dtsi| 26 ++-- > > drivers/power/Kconfig | 1 + > > drivers/power/Makefile | 1 + > > drivers/power/pwrseq/Kconfig | 20 +++ > > drivers/power/pwrseq/Makefile | 2 + > > drivers/power/pwrseq/core.c| 71 ++ > > drivers/power/pwrseq/pwrseq_generic.c | 151 > > + > > drivers/usb/chipidea/core.c| 10 ++ > > drivers/usb/core/Makefile | 1 + > > drivers/usb/core/hub.c | 12 +- > > drivers/usb/core/hub.h | 12 ++ > > drivers/usb/core/pwrseq.c | 100 ++ > > include/linux/power/pwrseq.h | 50 +++ > > 16 files changed, 507 insertions(+), 17 deletions(-) > > create mode 100644 > > Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt > > create mode 100644 drivers/power/pwrseq/Kconfig > > create mode 100644 drivers/power/pwrseq/Makefile > > create mode 100644 drivers/power/pwrseq/core.c > > create mode 100644 drivers/power/pwrseq/pwrseq_generic.c > > create mode 100644 drivers/usb/core/pwrseq.c > > create mode 100644 include/linux/power/pwrseq.h > > > > With these patches our on-board USB hub, > a Microchip USB2513BI-AEZG, works exactly as it does > with the fake regulator kludge, so... > Tested-by Joshua Clayton > Thanks. > I assume there is a v4
Re: [PATCH v3 1/6] binding-doc: power: pwrseq-generic: add binding doc for generic power sequence library
On Wed, Jul 20, 2016 at 05:40:24PM +0800, Peter Chen wrote:
> Add binding doc for generic power sequence library.
>
> Signed-off-by: Peter Chen
> Acked-by: Philipp Zabel
> ---
> .../bindings/power/pwrseq/pwrseq-generic.txt | 48
> ++
> 1 file changed, 48 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt
>
> diff --git
> a/Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt
> b/Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt
> new file mode 100644
> index 000..48bb3e1
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt
> @@ -0,0 +1,48 @@
> +The generic power sequence library
> +
> +Some hard-wired devices (eg USB/MMC) need to do power sequence before
> +the device can be enumerated on the bus, the typical power sequence
> +like: enable USB PHY clock, toggle reset pin, etc. But current
> +Linux device driver lacks of such code to do it, it may cause some
> +hard-wired devices works abnormal or can't be recognized by
> +controller at all. The power sequence will be done before this device
> +can be found at the bus.
> +
> +The power sequence properties is under the device node.
> +
> +Optional properties:
> +- clocks: the input clock for device.
> +- reset-gpios: Should specify the GPIO for reset.
> +- reset-duration-us: the duration in microsecond for assert reset signal.
> +
> +Below is the example of USB power sequence properties on USB device
> +nodes which have two level USB hubs.
> +
> +&usbotg1 {
> + vbus-supply = <®_usb_otg1_vbus>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_usb_otg1_id>;
> + status = "okay";
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> + genesys: hub@1 {
> + compatible = "usb5e3,608";
> + reg = <1>;
> +
> + clocks = <&clks IMX6SX_CLK_CKO>;
> + reset-gpios = <&gpio4 5 GPIO_ACTIVE_LOW>; /* hub reset pin */
> + reset-duration-us = <10>;
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> + asix: ethernet@1 {
> + compatible = "usbb95,1708";
> + reg = <1>;
> +
> + clocks = <&clks IMX6SX_CLK_IPG>;
> + reset-gpios = <&gpio4 6 GPIO_ACTIVE_LOW>; /*
> ethernet_rst */
> + reset-duration-us = <15>;
> + };
> + };
> +};
> --
> 1.9.1
Rob, would you please help to ack dts changes in this series if you are
ok with them?
--
Best Regards,
Peter Chen
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
