Re: [PATCH] usb: dwc2: Add reset control to dwc2
Hi,
John Youn writes:
> Hi Felipe,
>
> On 8/10/2016 6:53 AM, Dinh Nguyen wrote:
>> From: Dinh Nguyen
>>
>> Allow for platforms that have a reset controller driver in place to bring
>> the USB IP out of reset.
>>
>> Signed-off-by: Dinh Nguyen
>> Acked-by: John Youn
>> Tested-by: Stefan Wahren
>> ---
>> Hi Felipe,
>>
>> Can you please take this patch through your USB tree? This patch was
>> dependent
>> on "168d7c4e8bb2 reset: Return -ENOTSUPP when not configured" and is now in
>> v3.8-rc1.
>>
>> The discussion is highlight here:
>>
>> https://lkml.org/lkml/2016/7/7/291
>>
>> Thanks,
>> Dinh
>> ---
>> v7: Use devm_reset_control_get_optional()
>> v6: fix 80 line checkpatch warning in dev_err print
>> v5: updated error conditions for not finding the reset property
>> v4: use dev_dbg() if not a -EPROBE_DEFER
>> v3: fix compile error
>> v2: move to lowlevel_hw_init()
>> ---
>> drivers/usb/dwc2/core.h | 1 +
>> drivers/usb/dwc2/platform.c | 22 ++
>> 2 files changed, 23 insertions(+)
>>
>> diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
>> index 9fae029..d645512 100644
>> --- a/drivers/usb/dwc2/core.h
>> +++ b/drivers/usb/dwc2/core.h
>> @@ -868,6 +868,7 @@ struct dwc2_hsotg {
>> void *priv;
>> int irq;
>> struct clk *clk;
>> +struct reset_control *reset;
>>
>> unsigned int queuing_high_bandwidth:1;
>> unsigned int srp_success:1;
>> diff --git a/drivers/usb/dwc2/platform.c b/drivers/usb/dwc2/platform.c
>> index fc6f525..530959a 100644
>> --- a/drivers/usb/dwc2/platform.c
>> +++ b/drivers/usb/dwc2/platform.c
>> @@ -45,6 +45,7 @@
>> #include
>> #include
>> #include
>> +#include
>>
>> #include
>>
>> @@ -337,6 +338,24 @@ static int dwc2_lowlevel_hw_init(struct dwc2_hsotg
>> *hsotg)
>> {
>> int i, ret;
>>
>> +hsotg->reset = devm_reset_control_get_optional(hsotg->dev, "dwc2");
>> +if (IS_ERR(hsotg->reset)) {
>> +ret = PTR_ERR(hsotg->reset);
>> +switch (ret) {
>> +case -ENOENT:
>> +case -ENOTSUPP:
>> +hsotg->reset = NULL;
>> +break;
>> +default:
>> +dev_err(hsotg->dev, "error getting reset control %d\n",
>> +ret);
>> +return ret;
>> +}
>> +}
>> +
>> +if (hsotg->reset)
>> +reset_control_deassert(hsotg->reset);
>> +
>> /* Set default UTMI width */
>> hsotg->phyif = GUSBCFG_PHYIF16;
>>
>> @@ -434,6 +453,9 @@ static int dwc2_driver_remove(struct platform_device
>> *dev)
>> if (hsotg->ll_hw_enabled)
>> dwc2_lowlevel_hw_disable(hsotg);
>>
>> +if (hsotg->reset)
>> +reset_control_assert(hsotg->reset);
>> +
>> return 0;
>> }
>>
>>
>
> Can you take this for 4.8-rc? All the dependencies are in place now.
now in testing/fixes, thanks
--
balbi
signature.asc
Description: PGP signature
[PATCH 0/4] xhci fixes for usb-linus
Hi Greg These four patches solve a 4.8-rc1 regression messing up Android ADB usage, fix a bug in xhci pci host removal, and solve a couple other issues. short but important fixes -Mathias Alban Browaeys (1): xhci: really enqueue zero length TRBs. Jim Lin (1): usb: xhci: Fix panic if disconnect Mathias Nyman (2): xhci: always handle "Command Ring Stopped" events xhci: don't dereference a xhci member after removing xhci drivers/usb/host/xhci-hub.c | 3 +++ drivers/usb/host/xhci-pci.c | 3 ++- drivers/usb/host/xhci-ring.c | 16 +--- 3 files changed, 14 insertions(+), 8 deletions(-) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How can I tell who created my usb0 network device?
Hi, Patrick Doyle writes: > On Mon, Aug 15, 2016 at 5:02 PM, Greg KH wrote: >> ls -l /sys/class/net/usb0/device/driver >> >> sysfs is fun :) > Yes it is... I also managed to find > /sys/devices/pci:00/:00:11.0/dwc3-device.1/gadget/net/usb0 > with which machine is this? Is this Edison? > $ find /sys -name usb0 -prune > > Apparently, usb0 gets created because my system loads the g_multi which system is it? > gadget. But when I plug a hub into the USB port, (to which a cdc_eem which usb port? On the system you mention above? Is it a standard-A port or a micro-ab receptacle? > device is attached), the driver configures itself as a host, > enumerates my device, and sets up usb1. Poking around the kernel right, this is all fine. > configuration, I see that "DWC3 Mode selection" is set to "Gadget only > mode". I am guessing that "Gadget only mode" means something I'll just assume this is an Intel platform. They work differently. DWC3 is, indeed, gadget only. There's other logic in the SoC which muxes the port between a gadget-only DWC3 and host-only XHCI. DWC3 *can* be configured (the RTL itself) as a dual-role IP, but Intel's HW engineers decided to use DWC3 as peripheral-only and have proprietary logic to switch roles. > different than I would have expected, which is a good thing, because > I'm not sure I ever would have tracked that down based on the path I > was following previously. what were you tracking previously? usb0 is, indeed, g_multi. But keep in mind that usb0 is unusable until you connect the cable to a host PC. Much like your cdc_eem device sitting in the hub won't do anything until you plug it to a host PC, even if you provide it with external 5V supply ;-) -- balbi signature.asc Description: PGP signature
[PATCH 2/4] xhci: really enqueue zero length TRBs.
From: Alban Browaeys
Enqueue the first TRB even if full_len is zero.
Without this "adb install " freezes the system.
Signed-off-by: Alban Browaeys
Fixes: 86065c2719a5 ("xhci: don't rely on precalculated value of needed trbs in
the enqueue loop")
Signed-off-by: Mathias Nyman
---
drivers/usb/host/xhci-ring.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index fe5b70b..fd9fd12 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -3244,7 +3244,8 @@ int xhci_queue_bulk_tx(struct xhci_hcd *xhci, gfp_t
mem_flags,
send_addr = addr;
/* Queue the TRBs, even if they are zero-length */
- for (enqd_len = 0; enqd_len < full_len; enqd_len += trb_buff_len) {
+ for (enqd_len = 0; first_trb || enqd_len < full_len;
+ enqd_len += trb_buff_len) {
field = TRB_TYPE(TRB_NORMAL);
/* TRB buffer should not cross 64KB boundaries */
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4] usb: xhci: Fix panic if disconnect
From: Jim Lin
After a device is disconnected, xhci_stop_device() will be invoked
in xhci_bus_suspend().
Also the "disconnect" IRQ will have ISR to invoke
xhci_free_virt_device() in this sequence.
xhci_irq -> xhci_handle_event -> handle_cmd_completion ->
xhci_handle_cmd_disable_slot -> xhci_free_virt_device
If xhci->devs[slot_id] has been assigned to NULL in
xhci_free_virt_device(), then virt_dev->eps[i].ring in
xhci_stop_device() may point to an invlid address to cause kernel
panic.
virt_dev = xhci->devs[slot_id];
:
if (virt_dev->eps[i].ring && virt_dev->eps[i].ring->dequeue)
[] Unable to handle kernel paging request at virtual address 1a68
[] pgd=ffc00143
[] [1a68] *pgd=00013c807003, *pud=00013c807003,
*pmd=00013c808003, *pte=
[] Internal error: Oops: 9606 [#1] PREEMPT SMP
[] CPU: 0 PID: 39 Comm: kworker/0:1 Tainted: G U
[] Workqueue: pm pm_runtime_work
[] task: ffc0bc0e0bc0 ti: ffc0bc0ec000 task.ti:
ffc0bc0ec000
[] PC is at xhci_stop_device.constprop.11+0xb4/0x1a4
This issue is found when running with realtek ethernet device
(0bda:8153).
Signed-off-by: Jim Lin
Cc:
Signed-off-by: Mathias Nyman
---
drivers/usb/host/xhci-hub.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
index d61fcc4..730b9fd 100644
--- a/drivers/usb/host/xhci-hub.c
+++ b/drivers/usb/host/xhci-hub.c
@@ -386,6 +386,9 @@ static int xhci_stop_device(struct xhci_hcd *xhci, int
slot_id, int suspend)
ret = 0;
virt_dev = xhci->devs[slot_id];
+ if (!virt_dev)
+ return -ENODEV;
+
cmd = xhci_alloc_command(xhci, false, true, GFP_NOIO);
if (!cmd) {
xhci_dbg(xhci, "Couldn't allocate command structure.\n");
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] xhci: always handle "Command Ring Stopped" events
Fix "Command completion event does not match command" errors by always
handling the command ring stopped events.
The command ring stopped event is generated as a result of aborting
or stopping the command ring with a register write. It is not caused
by a command in the command queue, and thus won't have a matching command
in the comman list.
Solve it by handling the command ring stopped event before checking for a
matching command.
In most command time out cases we abort the command ring, and get
a command ring stopped event. The events command pointer will point at
the current command ring dequeue, which in most cases matches the timed
out command in the command list, and no error messages are seen.
If we instead get a command aborted event before the command ring stopped
event, the abort event will increse the command ring dequeue pointer, and
the following command ring stopped events command pointer will point at the
next, not yet queued command. This case triggered the error message
Signed-off-by: Mathias Nyman
CC:
---
drivers/usb/host/xhci-ring.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 918e0c7..fe5b70b 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -1334,12 +1334,6 @@ static void handle_cmd_completion(struct xhci_hcd *xhci,
cmd = list_entry(xhci->cmd_list.next, struct xhci_command, cmd_list);
- if (cmd->command_trb != xhci->cmd_ring->dequeue) {
- xhci_err(xhci,
-"Command completion event does not match command\n");
- return;
- }
-
del_timer(&xhci->cmd_timer);
trace_xhci_cmd_completion(cmd_trb, (struct xhci_generic_trb *) event);
@@ -1351,6 +1345,13 @@ static void handle_cmd_completion(struct xhci_hcd *xhci,
xhci_handle_stopped_cmd_ring(xhci, cmd);
return;
}
+
+ if (cmd->command_trb != xhci->cmd_ring->dequeue) {
+ xhci_err(xhci,
+"Command completion event does not match command\n");
+ return;
+ }
+
/*
* Host aborted the command ring, check if the current command was
* supposed to be aborted, otherwise continue normally.
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] xhci: don't dereference a xhci member after removing xhci
Remove the hcd after checking for the xhci last quirks, not before. This caused a hang on a Alpine Ridge xhci based maching which remove the whole xhci controller when unplugging the last usb device CC: Signed-off-by: Mathias Nyman --- drivers/usb/host/xhci-pci.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c index 4fd041b..d7b0f97 100644 --- a/drivers/usb/host/xhci-pci.c +++ b/drivers/usb/host/xhci-pci.c @@ -314,11 +314,12 @@ static void xhci_pci_remove(struct pci_dev *dev) usb_remove_hcd(xhci->shared_hcd); usb_put_hcd(xhci->shared_hcd); } - usb_hcd_pci_remove(dev); /* Workaround for spurious wakeups at shutdown with HSW */ if (xhci->quirks & XHCI_SPURIOUS_WAKEUP) pci_set_power_state(dev, PCI_D3hot); + + usb_hcd_pci_remove(dev); } #ifdef CONFIG_PM -- 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: musb: am3358: having problem with high-speed on usb1 at peripheral
Hi, ayaka writes: > On 08/13/2016 01:44 AM, Greg KH wrote: >> On Sat, Aug 13, 2016 at 12:38:46AM +0800, ayaka wrote: >>> >>> On 08/12/2016 03:40 PM, Greg KH wrote: On Fri, Aug 12, 2016 at 10:23:15AM +0800, ayaka wrote: > Hello all: > I recently add a support for customize am3358 board using the branch > processor-sdk-linux-03.00.00 from Ti git. But I meet a problem with musb > at the peripheral mode. Then you are going to have to get support from TI for this, nothing we can do here about random vendor kernel trees, sorry. If you can use the 4.7 tree, or better yet, the 4.8-rc tree, then we >>> I have tried the 4.8-rc1, I meet the same problem. >> What problem is that exactly? > Sorry, the USB1 can't work at high speed gadget mode and have DMA problem. > musb-hdrc musb-hdrc.0.auto: Failed to request rx1. > musb-hdrc musb-hdrc.0.auto: musb_init_controller failed with status -517 -517 is EPROBE_DEFER. Most likely DMA hasn't probed and MUSB is deferring to try later. This does _NOT_ MUSB can't work with DMA. Perhaps you didn't enable support for MUSB's DMA engine. -- balbi signature.asc Description: PGP signature
Re: [PATCH] usb: dwc3: gadget: don't rely on jiffies while holding spinlock
Hi,
Nicolas Saenz Julienne writes:
> __dwc3_gadget_wakeup() is called while holding a spinlock, then depends on
> jiffies in order to timeout while polling the USB core for a link state
> update. In the case the wakeup failed, the timeout will never happen and
> will also cause the cpu to stall until rcu_preempt kicks in.
>
> This switches to a "decrement variable and wait" timeout scheme.
>
> Signed-off-by: Nicolas Saenz Julienne
> ---
> drivers/usb/dwc3/gadget.c | 8 +---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
> index 8f8c215..d0c711f 100644
> --- a/drivers/usb/dwc3/gadget.c
> +++ b/drivers/usb/dwc3/gadget.c
> @@ -1433,7 +1433,7 @@ static int dwc3_gadget_get_frame(struct usb_gadget *g)
>
> static int __dwc3_gadget_wakeup(struct dwc3 *dwc)
> {
> - unsigned long timeout;
> + int retries;
>
> int ret;
> u32 reg;
> @@ -1484,14 +1484,16 @@ static int __dwc3_gadget_wakeup(struct dwc3 *dwc)
> }
>
> /* poll until Link State changes to ON */
> - timeout = jiffies + msecs_to_jiffies(100);
> + retries = 2;
>
> - while (!time_after(jiffies, timeout)) {
> + while (retries--) {
> reg = dwc3_readl(dwc->regs, DWC3_DSTS);
>
> /* in HS, means ON */
> if (DWC3_DSTS_USBLNKST(reg) == DWC3_LINK_STATE_U0)
> break;
> +
> + udelay(5);
let's just drop this udelay() here. It's very likely this will switch
the link state much quicker than 100ms anyway. Other than that, nice
catch :-)
--
balbi
signature.asc
Description: PGP signature
Re: [PATCH v10 5/5] usb: dwc3: add rockchip specific glue layer
Hi,
William Wu writes:
> Add rockchip specific glue layer to support USB3 Peripheral mode
> and Host mode on rockchip platforms (e.g. rk3399).
>
> The DesignWare USB3 integrated in rockchip SoCs is a configurable
> IP Core which can be instantiated as Dual-Role Device (DRD), Host
> Only (XHCI) and Peripheral Only configurations.
>
> We use extcon notifier to manage usb cable detection and mode switch.
> Enable DWC3 PM runtime auto suspend to allow core enter runtime_suspend
> if USB cable is dettached. For host mode, it requires to keep whole
> DWC3 controller in reset state to hold pipe power state in P2 before
> initializing PHY. And it need to reconfigure USB PHY interface of DWC3
> core after deassert DWC3 controller reset.
>
> The current driver supports Host only and Peripheral Only well, for
> now, we will add support for OTG after we have it all stabilized.
>
> Signed-off-by: William Wu
> ---
> Changes in v10:
> - fix building error
>
> Changes in v9:
> - Add a new dwc3-rockchip.c driver for rk3399, rather than use
> dwc3-of-simple.c
>
> drivers/usb/dwc3/Kconfig | 9 +
> drivers/usb/dwc3/Makefile| 1 +
> drivers/usb/dwc3/core.c | 2 +-
> drivers/usb/dwc3/core.h | 1 +
> drivers/usb/dwc3/dwc3-rockchip.c | 441
> +++
William, if you need to touch core dwc3 to introduce a glue layer,
you're doing it wrong.
> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
> index e887b38..3da6215 100644
> --- a/drivers/usb/dwc3/core.c
> +++ b/drivers/usb/dwc3/core.c
> @@ -405,7 +405,7 @@ static void dwc3_cache_hwparams(struct dwc3 *dwc)
> * initialized. The PHY interfaces and the PHYs get initialized together with
> * the core in dwc3_core_init.
> */
> -static int dwc3_phy_setup(struct dwc3 *dwc)
> +int dwc3_phy_setup(struct dwc3 *dwc)
there's no way I'll let this slip through the cracks :-)
> diff --git a/drivers/usb/dwc3/dwc3-rockchip.c
> b/drivers/usb/dwc3/dwc3-rockchip.c
> new file mode 100644
> index 000..eeae1a9
> --- /dev/null
> +++ b/drivers/usb/dwc3/dwc3-rockchip.c
> @@ -0,0 +1,441 @@
[...]
> +static int dwc3_rockchip_probe(struct platform_device *pdev)
> +{
> + struct dwc3_rockchip*rockchip;
> + struct device *dev = &pdev->dev;
> + struct device_node *np = dev->of_node, *child;
> + struct platform_device *child_pdev;
> +
> + unsigned intcount;
> + int ret;
> + int i;
> +
> + rockchip = devm_kzalloc(dev, sizeof(*rockchip), GFP_KERNEL);
> +
> + if (!rockchip)
> + return -ENOMEM;
> +
> + count = of_clk_get_parent_count(np);
> + if (!count)
> + return -ENOENT;
> +
> + rockchip->num_clocks = count;
> +
> + rockchip->clks = devm_kcalloc(dev, rockchip->num_clocks,
> + sizeof(struct clk *), GFP_KERNEL);
> + if (!rockchip->clks)
> + return -ENOMEM;
> +
> + platform_set_drvdata(pdev, rockchip);
> +
> + rockchip->dev = dev;
> + rockchip->edev = NULL;
> +
> + pm_runtime_set_active(dev);
> + pm_runtime_enable(dev);
> + ret = pm_runtime_get_sync(dev);
> + if (ret < 0) {
> + dev_err(dev, "get_sync failed with err %d\n", ret);
> + goto err1;
> + }
> +
> + for (i = 0; i < rockchip->num_clocks; i++) {
> + struct clk *clk;
> +
> + clk = of_clk_get(np, i);
> + if (IS_ERR(clk)) {
> + while (--i >= 0)
> + clk_put(rockchip->clks[i]);
> + ret = PTR_ERR(clk);
> +
> + goto err1;
> + }
> +
> + ret = clk_prepare_enable(clk);
> + if (ret < 0) {
> + while (--i >= 0) {
> + clk_disable_unprepare(rockchip->clks[i]);
> + clk_put(rockchip->clks[i]);
> + }
> + clk_put(clk);
> +
> + goto err1;
> + }
> +
> + rockchip->clks[i] = clk;
> + }
> +
> + rockchip->otg_rst = devm_reset_control_get(dev, "usb3-otg");
> + if (IS_ERR(rockchip->otg_rst)) {
> + dev_err(dev, "could not get reset controller\n");
> + ret = PTR_ERR(rockchip->otg_rst);
> + goto err2;
> + }
> +
> + ret = dwc3_rockchip_extcon_register(rockchip);
> + if (ret < 0)
> + goto err2;
> +
> + child = of_get_child_by_name(np, "dwc3");
> + if (!child) {
> + dev_err(dev, "failed to find dwc3 core node\n");
> + ret = -ENODEV;
> + goto err3;
> + }
> +
> + /* Allocate and initialize the core */
> + ret = of_platform_populate(np, NULL, NULL, dev);
> + if (ret) {
> + dev_err(dev, "failed to create dwc3 core\n");
> + goto err3;
> + }
> +
> + child_pdev =
Re: Gadgetfs - adding support for delegation of setup requests
Hi, Alan Stern writes: >> I'm using GadgetFs for USB host fuzzing (using umap2), >> and part of the fuzzing session is to send invalid descriptors at >> various stages. >> >> However, some requests are not delegated to user-land (see gadgetfs_setup() >> in gadget/legacy/inode.c), >> Specifically - GET_DESCRIPTOR (device/configuration) and SET_CONFIGURATION. that's because they don't have to be. Kernel caches the descriptors you write during gadgetfs initialization and just returns that. >> Does a patch to switch the gadgetfs module to "delegate all" sounds >> reasonable? >> If so - what's the preferred way to do it? I have a few options in mind: > > Why do you need to delegate Get-Descriptor? The contents of the > response are entirely dictated by the descriptors provided by the user > program in the first place. > > Set-Configuration _is_ delegated to the user program, although the > program is not allowed to fail the request. Is that what you want to > do? > >> - module parameter >> - write some command to the ep0 file >> - send an ioctl to the ep0 file >> >> Any other suggestion? > > I suspect this sort of thing would not be accepted. If Felipe agrees, > you might as well just keep your changes out-of-tree. This will just open up a can of worms, I'm afraid. What we have today can even pass all USBCV tests, we're not breaking that, sorry. -- balbi signature.asc Description: PGP signature
Re: [PATCH] usb: remove redundant dependency on USB_SUPPORT
Hi, Masahiro Yamada writes: > The whole Kconfig entries of the USB subsystem are surrounded with > "if USB_SUPPORT" ... "endif", so CONFIG_USB_SUPPORT=y is surely met > when these two Kconfig options are visible. > > Signed-off-by: Masahiro Yamada > --- > > drivers/usb/core/Kconfig | 1 - > drivers/usb/dwc3/Kconfig | 2 +- > 2 files changed, 1 insertion(+), 2 deletions(-) > > diff --git a/drivers/usb/core/Kconfig b/drivers/usb/core/Kconfig > index dd28010..253aac7 100644 > --- a/drivers/usb/core/Kconfig > +++ b/drivers/usb/core/Kconfig > @@ -85,7 +85,6 @@ config USB_OTG_FSM > > config USB_ULPI_BUS > tristate "USB ULPI PHY interface support" > - depends on USB_SUPPORT > help > UTMI+ Low Pin Interface (ULPI) is specification for a commonly used > USB 2.0 PHY interface. The ULPI specification defines a standard set > diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig > index 11864e4..3c6213c 100644 > --- a/drivers/usb/dwc3/Kconfig > +++ b/drivers/usb/dwc3/Kconfig > @@ -1,7 +1,7 @@ > config USB_DWC3 > tristate "DesignWare USB3 DRD Core Support" > depends on (USB || USB_GADGET) && HAS_DMA > - select USB_XHCI_PLATFORM if USB_SUPPORT && USB_XHCI_HCD > + select USB_XHCI_PLATFORM if USB_XHCI_HCD > help > Say Y or M here if your system has a Dual Role SuperSpeed > USB controller based on the DesignWare USB3 IP Core. let's split this patch in two so different maintainers can pick the relevant pieces. Thanks -- balbi signature.asc Description: PGP signature
Re: [PATCH 2/2] usb: Kconfig: move ulpi bus to common
On Tue, Aug 16, 2016 at 09:14:41AM +0800, Peter Chen wrote: > > Once you resend, please re-add the dependency once you move the config > > to drivers/usb/common/Kconfig. > > > > But Greg doesn't agree with move configurations from drivers/usb/Kconfig to > drivers/usb/common/Kconfig, I move it to drivers/usb/Kconfig? That works for me. Thanks, -- heikki -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] usb: gadget: legacy: Add udc module param to all legacy gadgets
Hi, Krzysztof Opasiak writes: > Add new module parameter called "udc" to all legacy gadgets. > By using this parameter user can choose a controller towhich > this gadget should be bound. we've added configfs exactly so we can bind gadgets to specific UDCs. Sorry, I'm not taking this module parameter. What prevents you from using configfs? -- balbi signature.asc Description: PGP signature
Re: [PATCHv4 0/2] USB Type-C Connector class
Hi guys, Sorry for the long silence. I just returned from paternal leave. On Wed, Aug 10, 2016 at 10:19:25AM +0200, Oliver Neukum wrote: > On Tue, 2016-08-09 at 09:23 -0700, Guenter Roeck wrote: > > > I'm not going to take this series until everyone agrees on it, > > sorry. > > > I'll wait for you and Guenter and Oliver to all come up with a > > solution > > > that works for everyone. > > > > > > > I have not heard from Heikko for a while. There have been some > > follow-up > > patches in > > > > https://git.kernel.org/cgit/linux/kernel/git/balbi/usb.git/log/?h=bxt-typec-pd-fixes > > > > but I am not really sure where this is going. I've been wondering if I > > can/should get more actively involved and start driving the series if > > Heikki is busy. Thoughts, anyone ? > > It is not clear to me where we were. It seems to me that we found > the API good but disagreed about locking. Does that sum it up? I'll remove the locks and resend. Thanks, -- heikki -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] usb: gadget: f_ncm: add support for scatter/gather SKB to enable GSO
Hi, Jussi Kivilinna writes: > Enabling SG allows enabling GSO (generic segmentation offload) feature > of linux networking layer. This increases TCP throughput with NCM > on Cortex-A15+USB3380 based device from 300 Mbit/s to 1.1 Gbit/s. > > Signed-off-by: Jussi Kivilinna this is AWESOME!! :-) But here's the thing, any chance we can build this in u_ether.c ? Also, NETIF_F_SG should be conditional on gadget->sg_supported so that we don't break UDCs that don't support sglists. -- balbi signature.asc Description: PGP signature
Re: Gadgetfs - adding support for delegation of setup requests
Hi, On Tue, Aug 16, 2016 at 10:23 AM, Felipe Balbi wrote: > > Hi, > > Alan Stern writes: >>> I'm using GadgetFs for USB host fuzzing (using umap2), >>> and part of the fuzzing session is to send invalid descriptors at >>> various stages. >>> >>> However, some requests are not delegated to user-land (see gadgetfs_setup() >>> in gadget/legacy/inode.c), >>> Specifically - GET_DESCRIPTOR (device/configuration) and SET_CONFIGURATION. > > that's because they don't have to be. Kernel caches the descriptors you > write during gadgetfs initialization and just returns > that. > As I see it, there are at least two issues with that: 1. gadgetfs can't handle complex, valid descriptor, such as Class Specific descriptors, this means that I can't emulate audio devices for example. 2. At least in my case, where I wan't to use gadgetfs for fuzzing other USB hosts, I can't really fuzz various stages of the enumeration phase, specifically in the case of descriptors that are usually requested at least twice (e.g. configuration descriptor) >>> Does a patch to switch the gadgetfs module to "delegate all" sounds >>> reasonable? >>> If so - what's the preferred way to do it? I have a few options in mind: >> >> Why do you need to delegate Get-Descriptor? The contents of the >> response are entirely dictated by the descriptors provided by the user >> program in the first place. >> >> Set-Configuration _is_ delegated to the user program, although the >> program is not allowed to fail the request. Is that what you want to >> do? >> >>> - module parameter >>> - write some command to the ep0 file >>> - send an ioctl to the ep0 file >>> >>> Any other suggestion? >> >> I suspect this sort of thing would not be accepted. If Felipe agrees, >> you might as well just keep your changes out-of-tree. > > This will just open up a can of worms, I'm afraid. What we have today > can even pass all USBCV tests, we're not breaking that, sorry. > I get your point, what I propose is not to change the default behavior of gadgetfs, but allow it to enter to a special mode by the user. I am aware of the issues that it might raise, and understand your concerns. However, I am asking about modifications in a specific, contained context. I would prefer to have it in the mainline kernel, but if you don't think it fits - I will keep those changes as an out-of-tree module. > -- > balbi Thanks, Binyamin -- 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: musb: am3358: having problem with high-speed on usb1 at peripheral
從我的 iPad 傳送 > Felipe Balbi 於 2016年8月16日 下午3:10 寫道： > > > Hi, > > ayaka writes: >>> On 08/13/2016 01:44 AM, Greg KH wrote: On Sat, Aug 13, 2016 at 12:38:46AM +0800, ayaka wrote: > On 08/12/2016 03:40 PM, Greg KH wrote: >> On Fri, Aug 12, 2016 at 10:23:15AM +0800, ayaka wrote: >> Hello all: >>I recently add a support for customize am3358 board using the branch >> processor-sdk-linux-03.00.00 from Ti git. But I meet a problem with musb >> at the peripheral mode. > Then you are going to have to get support from TI for this, nothing we > can do here about random vendor kernel trees, sorry. > > If you can use the 4.7 tree, or better yet, the 4.8-rc tree, then we I have tried the 4.8-rc1, I meet the same problem. >>> What problem is that exactly? >> Sorry, the USB1 can't work at high speed gadget mode and have DMA problem. >> musb-hdrc musb-hdrc.0.auto: Failed to request rx1. >> musb-hdrc musb-hdrc.0.auto: musb_init_controller failed with status -517 > > -517 is EPROBE_DEFER. Most likely DMA hasn't probed and MUSB is > deferring to try later. This does _NOT_ MUSB can't work with > DMA. Perhaps you didn't enable support for MUSB's DMA engine. > I have set the status of cppi41dma to okay in dts. And CONFIG_USB_TI_CPPI41_DMA, CONFIG_TI_CPPI41 and CONFIG_TI_EDMA are enabled with build into kernel. Anything else I should do? > -- > 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: musb: am3358: having problem with high-speed on usb1 at peripheral
Hi, Ayaka writes: >> ayaka writes: On 08/13/2016 01:44 AM, Greg KH wrote: > On Sat, Aug 13, 2016 at 12:38:46AM +0800, ayaka wrote: > >> On 08/12/2016 03:40 PM, Greg KH wrote: >>> On Fri, Aug 12, 2016 at 10:23:15AM +0800, ayaka wrote: >>> Hello all: >>>I recently add a support for customize am3358 board using the branch >>> processor-sdk-linux-03.00.00 from Ti git. But I meet a problem with musb >>> at the peripheral mode. >> Then you are going to have to get support from TI for this, nothing we >> can do here about random vendor kernel trees, sorry. >> >> If you can use the 4.7 tree, or better yet, the 4.8-rc tree, then we > I have tried the 4.8-rc1, I meet the same problem. What problem is that exactly? >>> Sorry, the USB1 can't work at high speed gadget mode and have DMA problem. >>> musb-hdrc musb-hdrc.0.auto: Failed to request rx1. >>> musb-hdrc musb-hdrc.0.auto: musb_init_controller failed with status -517 >> >> -517 is EPROBE_DEFER. Most likely DMA hasn't probed and MUSB is >> deferring to try later. This does _NOT_ MUSB can't work with >> DMA. Perhaps you didn't enable support for MUSB's DMA engine. >> > I have set the status of cppi41dma to okay in dts. And > CONFIG_USB_TI_CPPI41_DMA, > CONFIG_TI_CPPI41 and CONFIG_TI_EDMA are enabled with build into kernel. > > Anything else I should do? no, that should do it. Since musb returned -EPROBE_DEFER, it will retry probing later. Check if musb probed fine. The easiest way is to check if you have anything in /sys/class/udc/ -- balbi signature.asc Description: PGP signature
Re: Gadgetfs - adding support for delegation of setup requests
Hi, Binyamin Sharet writes: >> Alan Stern writes: I'm using GadgetFs for USB host fuzzing (using umap2), and part of the fuzzing session is to send invalid descriptors at various stages. However, some requests are not delegated to user-land (see gadgetfs_setup() in gadget/legacy/inode.c), Specifically - GET_DESCRIPTOR (device/configuration) and SET_CONFIGURATION. >> >> that's because they don't have to be. Kernel caches the descriptors you >> write during gadgetfs initialization and just returns >> that. >> > > As I see it, there are at least two issues with that: > 1. gadgetfs can't handle complex, valid descriptor, such as Class > Specific descriptors, > this means that I can't emulate audio devices for example. why not? The first thing you do when you start out your gadgetfs daemon is write descriptors which kernel will use. Just write *all* descriptors you need. > 2. At least in my case, where I wan't to use gadgetfs for fuzzing > other USB hosts, I > can't really fuzz various stages of the enumeration phase, > specifically in the case of > descriptors that are usually requested at least twice (e.g. > configuration descriptor) you are not allowed to change your descriptors on the fly. Descriptors are static. Configuration descriptor is requested twice for a simple reason: Host doesn't know how big a configuration you have; so it asks only for the first 9 bytes which will contain bLength. Then host uses bLength to figure how big is your configuration and subsequently fetches the entire thing. Does a patch to switch the gadgetfs module to "delegate all" sounds reasonable? If so - what's the preferred way to do it? I have a few options in mind: >>> >>> Why do you need to delegate Get-Descriptor? The contents of the >>> response are entirely dictated by the descriptors provided by the user >>> program in the first place. >>> >>> Set-Configuration _is_ delegated to the user program, although the >>> program is not allowed to fail the request. Is that what you want to >>> do? >>> - module parameter - write some command to the ep0 file - send an ioctl to the ep0 file Any other suggestion? >>> >>> I suspect this sort of thing would not be accepted. If Felipe agrees, >>> you might as well just keep your changes out-of-tree. >> >> This will just open up a can of worms, I'm afraid. What we have today >> can even pass all USBCV tests, we're not breaking that, sorry. >> > > I get your point, what I propose is not to change the default behavior > of gadgetfs, > but allow it to enter to a special mode by the user. I am aware of the > issues that it > might raise, and understand your concerns. However, I am asking about > modifications in a specific, contained context. I would prefer to have it in > the > mainline kernel, but if you don't think it fits - I will keep those > changes as an > out-of-tree module. you're gonna have a really hard time getting anything in mainline without explaining your goal. All you said is: "I wanna do fuzzying", but fuzzying of what exactly? Why do you need to fuzz during enumeration? This makes no sense. Gadgets are _not_ allowed to change their descriptors and kernel doesn't allow userspace to do that. If you wanna change your descriptor, then you _must_ disconnect from the host and write brand new descriptors during gadgetfs initialization. -- balbi signature.asc Description: PGP signature
RE: [PATCH v5] usb: ohci-at91: Forcibly suspend ports while USB suspend
Hi Alan,
As you saw, I think the version 4 is better than this, can we take the version
4?
Best Regards,
Wenyou Yang
> -Original Message-
> From: wenyou.y...@microchip.com [mailto:wenyou.y...@microchip.com]
> Sent: 2016年8月5日 11:46
> To: st...@rowland.harvard.edu; wenyou.y...@atmel.com
> Cc: gre...@linuxfoundation.org; nicolas.fe...@atmel.com;
> alexandre.bell...@free-electrons.com; linux-ker...@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org; linux-usb@vger.kernel.org
> Subject: RE: [PATCH v5] usb: ohci-at91: Forcibly suspend ports while USB
> suspend
>
> Hi Alan,
>
> > -Original Message-
> > From: Alan Stern [mailto:st...@rowland.harvard.edu]
> > Sent: 2016年8月4日 23:02
> > To: Wenyou Yang
> > Cc: Greg Kroah-Hartman ; Nicolas Ferre
> > ; Alexandre Belloni > electrons.com>; linux-ker...@vger.kernel.org; linux-arm-
> > ker...@lists.infradead.org; linux-usb@vger.kernel.org
> > Subject: Re: [PATCH v5] usb: ohci-at91: Forcibly suspend ports while
> > USB suspend
> >
> > On Thu, 4 Aug 2016, Wenyou Yang wrote:
> >
> > > The usb controller does not managed correctly the suspend mode for
> > > the ehci. In echi mode, there is no way to have utmi_suspend_o_n[1]
> > > suspend without any device connected to it. This is why this
> > > specific control is added to fix this issue. The suspend mode works
> > > in ohci mode.
> >
> > Why are you talking about EHCI mode? This patch is only for the
> > ohci-at91 driver.
>
> Actually I described the issue according to the documents from our IP, and
> this
> specific control is recommended to do in ohci mode.
>
> >
> > > This specific control is by setting the SUSPEND_A/B/C fields of
> > > SFR_OHCIICR(OHCI Interrupt Configuration Register) in the SFR while
> > > OHCI USB suspend.
> > >
> > > This setting operation must be done before the USB clock disabled,
> > > clear them after the USB clock enabled.
> > >
> > > Signed-off-by: Wenyou Yang
> > > Reviewed-by: Alexandre Belloni
> > >
> > > Acked-by: Nicolas Ferre
> >
> > I don't know if this is any better than before! See the comments below.
>
> Yes, I think so.
>
> What else advice?
>
> >
> > > ---
> > >
> > > Changes in v5:
> > > - Use the USB_PORT_FEAT_SUSPEND subcase of the SetPortFeature case
> > >to take care it.
> > > - Update the commit log.
> > >
> > > Changes in v4:
> > > - To check whether the SFR node with "atmel,sama5d2-sfr" compatible
> > >is present or not to decide if this feature is applied or not
> > >when USB OHCI suspend/resume, instead of new compatible.
> > > - Drop the compatible "atmel,sama5d2-ohci".
> > > - Drop [PATCH 2/2] ARM: at91/dt: sama5d2: Use new compatible for
> > >ohci node.
> > > - Drop include/soc/at91/at91_sfr.h, move the macro definitions to
> > >atmel-sfr.h which already exists.
> > > - Change the defines to align the exists.
> > >
> > > Changes in v3:
> > > - Change the compatible description for more precise.
> > >
> > > Changes in v2:
> > > - Add compatible to support forcibly suspend the ports.
> > > - Add soc/at91/at91_sfr.h to accommodate the defines.
> > > - Add error checking for .sfr_regmap.
> > > - Remove unnecessary regmap_read() statement.
> >
> >
> > > @@ -282,6 +301,28 @@ static int ohci_at91_hub_status_data(struct
> > > usb_hcd
> > *hcd, char *buf)
> > > return length;
> > > }
> > >
> > > +static int ohci_at91_port_ctrl(struct regmap *regmap, u16 port, u8
> > > +set) {
> > > + u32 regval;
> > > + int ret;
> > > +
> > > + if (!regmap)
> > > + return 0;
> > > +
> > > + ret = regmap_read(regmap, AT91_SFR_OHCIICR, ®val);
> > > + if (ret)
> > > + return ret;
> > > +
> > > + if (set)
> > > + regval |= AT91_OHCIICR_SUSPEND(port);
> > > + else
> > > + regval &= ~AT91_OHCIICR_SUSPEND(port);
> >
> > In the earlier versions of this patch, you did not use the port number.
> > Why has this changed?
>
> This function is called by ohci_at91_hub_control(), which is invoked on basis
> of
> port number.
>
> So, I think it is more reasonable of adding the port argument.
>
> >
> > How many ports does this controller have?
>
> This controller has three ports.
>
> >
> > > +
> > > + regmap_write(regmap, AT91_SFR_OHCIICR, regval);
> > > +
> > > + return 0;
> > > +}
> > > +
> > > /*
> > > * Look at the control requests to the root hub and see if we need to
> > > override.
> > > */
> > > @@ -289,6 +330,7 @@ static int ohci_at91_hub_control(struct usb_hcd
> > > *hcd,
> > u16 typeReq, u16 wValue,
> > >u16 wIndex, char *buf, u16 wLength) {
> > > struct at91_usbh_data *pdata =
> > > dev_get_platdata(hcd->self.controller);
> > > + struct ohci_at91_priv *ohci_at91 = hcd_to_ohci_at91_priv(hcd);
> > > struct usb_hub_descriptor *desc;
> > > int ret = -EINVAL;
> > > u32 *data = (u32 *)buf;
> > > @@ -301,7 +343,8 @@ static int ohci_at91_hub_control(struct usb_hcd
> > > *hcd, u16 typeReq, u16 wValue,
> > >
> > > switch (typeReq) {
> > > case SetPortF
[PATCH v2] usb: dwc3: gadget: don't rely on jiffies while holding spinlock
From: Nicolas Saenz Julienne
__dwc3_gadget_wakeup() is called while holding a spinlock, then depends on
jiffies in order to timeout while polling the USB core for a link state
update. In the case the wakeup failed, the timeout will never happen and
will also cause the cpu to stall until rcu_preempt kicks in.
This switches to a "decrement variable and wait" timeout scheme.
Signed-off-by: Nicolas Saenz Julienne
---
v2. removed udelay()
drivers/usb/dwc3/gadget.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 8f8c215..c9451c2 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -1433,7 +1433,7 @@ static int dwc3_gadget_get_frame(struct usb_gadget *g)
static int __dwc3_gadget_wakeup(struct dwc3 *dwc)
{
- unsigned long timeout;
+ int retries;
int ret;
u32 reg;
@@ -1484,9 +1484,9 @@ static int __dwc3_gadget_wakeup(struct dwc3 *dwc)
}
/* poll until Link State changes to ON */
- timeout = jiffies + msecs_to_jiffies(100);
+ retries = 2;
- while (!time_after(jiffies, timeout)) {
+ while (retries--) {
reg = dwc3_readl(dwc->regs, DWC3_DSTS);
/* in HS, means ON */
--
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 0/3] USB Audio Gadget refactoring
On Sun, Aug 14, 2016 at 01:21:21AM +0300, Ruslan Bilovol wrote: > I came to this patch series when wanted to do two things: > - use UAC1 as virtual ALSA sound card on gadget side, >just like UAC2 is used so it's possible to do rate >resampling > - have both playback/capture support in UAC1 > > Since I wanted to have same behavior for both UAC1/UAC2, > obviously I've got an utility part (u_audio.c) for > virtual ALSA sound card handling like we have > for ethernet(u_ether) or serial(u_serial) functions. > Function-specific parts (f_uac1/f_uac2) became almost > as storage for class-specific USB descriptors, some > boilerplate for configfs, binding and few USB > config request handling. > > Originally in RFC [1] I've posted before, there was > major change to f_uac1 after that it couldn't do > direct play to existing ALSA sound card anymore, > representing audio on gadget side as virtual > ALSA sound card where audio streams are simply > sinked to and sourced from it, so it may break > current usecase for some people (and that's why > it was RFC). > > During RFC discussion, it was agreed to not touch > existing f_uac1 implementation and create new one > instead. This patchset (v2) introduced new function > named f_uac1_newapi and doesn't touch current f_uac1 > implementation, so people still can use old behavior > > Now, it's possible to use existing user-space > applications for audio routing between Audio Gadget > and real sound card. I personally use alsaloop tool > from alsautils and have ability to create PCM > loopback between two different ALSA cards using > rate resampling, which was not possible with previous > "direct play to ALSA card" approach in f_uac1. > > While here, also dropped redundant platform > driver/device creation in f_uac2 driver (as well as > didn't add "never implemented" volume/mute functionality > in f_uac1 to f_uac1_newapi) that made this work even > easier to do. > > This series is tested with both legacy g_audio.ko and > modern configfs approaches under Ubuntu 14.04 (UAC1 and > UAC2) and under Windows7 x64 (UAC1 only) having > perfect results in all cases. > I find UAC2 (UAC1 is ok) support is not well with the latest mainline kernel w/o your patch set. The windows7 can't install the driver successfully and the playback shows underrun (using local codec) using Linux host. Do you use the unchanged mainline kernel? My configfs parameters like below: echo 2 > functions/uac2.1/c_ssize echo 48000 > functions/uac2.1/c_srate echo 3 > functions/uac2.1/c_chmask echo 2 > functions/uac2.1/p_ssize echo 48000 > functions/uac2.1/p_srate echo 3 > functions/uac2.1/p_chmask Console output: root@imx6qdlsolo:~# arecord -f dat -t wav -D hw:1,0 | aplay -D hw:0,0 & [1] 859 root@imx6qdlsolo:~# root@imx6qdlsolo:~# Recording WAVE 'stdin' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo Playing WAVE 'stdin' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo underrun!!! (at least 36.634 ms long) underrun!!! (at least 36.117 ms long) underrun!!! (at least 42.132 ms long) underrun!!! (at least 40.157 ms long) underrun!!! (at least 36.207 ms long) underrun!!! (at least 39.173 ms long) underrun!!! (at least 36.119 ms long) underrun!!! (at least 36.164 ms long) -- Best Regards, Peter Chen -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: remove redundant dependency on USB_SUPPORT
2016-08-16 16:29 GMT+09:00 Felipe Balbi : > > Hi, > > Masahiro Yamada writes: >> The whole Kconfig entries of the USB subsystem are surrounded with >> "if USB_SUPPORT" ... "endif", so CONFIG_USB_SUPPORT=y is surely met >> when these two Kconfig options are visible. >> >> Signed-off-by: Masahiro Yamada >> --- >> >> drivers/usb/core/Kconfig | 1 - >> drivers/usb/dwc3/Kconfig | 2 +- >> 2 files changed, 1 insertion(+), 2 deletions(-) >> >> diff --git a/drivers/usb/core/Kconfig b/drivers/usb/core/Kconfig >> index dd28010..253aac7 100644 >> --- a/drivers/usb/core/Kconfig >> +++ b/drivers/usb/core/Kconfig >> @@ -85,7 +85,6 @@ config USB_OTG_FSM >> >> config USB_ULPI_BUS >> tristate "USB ULPI PHY interface support" >> - depends on USB_SUPPORT >> help >> UTMI+ Low Pin Interface (ULPI) is specification for a commonly used >> USB 2.0 PHY interface. The ULPI specification defines a standard set >> diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig >> index 11864e4..3c6213c 100644 >> --- a/drivers/usb/dwc3/Kconfig >> +++ b/drivers/usb/dwc3/Kconfig >> @@ -1,7 +1,7 @@ >> config USB_DWC3 >> tristate "DesignWare USB3 DRD Core Support" >> depends on (USB || USB_GADGET) && HAS_DMA >> - select USB_XHCI_PLATFORM if USB_SUPPORT && USB_XHCI_HCD >> + select USB_XHCI_PLATFORM if USB_XHCI_HCD >> help >> Say Y or M here if your system has a Dual Role SuperSpeed >> USB controller based on the DesignWare USB3 IP Core. > > let's split this patch in two so different maintainers can pick the > relevant pieces. Thanks Greg picked up this patch already. I see it in linux-next now. -- Best Regards Masahiro Yamada -- 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 0/3] USB Audio Gadget refactoring
Peter Chen wrote: > I find UAC2 (UAC1 is ok) support is not well with the latest mainline > kernel w/o your patch set. The windows7 can't install the driver > successfully Windows does not have UAC2 support. > and the playback shows underrun (using local codec) > using Linux host. > # arecord -f dat -t wav -D hw:1,0 | aplay -D hw:0,0 & The clocks of the two devices are not synchronized. In the ALSA API, a PCM device is assumed to have its own clock, so it is not possible to synchronize the USB gadget to the actual sound device without some separate mechanism (like the old uac1 gadget probably has). Regards, Clemens -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] usb: Kconfig: move ulpi bus to common
On Mon, Aug 15, 2016 at 04:07:14PM +0300, Heikki Krogerus wrote: > Hi, > > On Fri, Jul 08, 2016 at 04:15:23PM +0800, Peter Chen wrote: > > The ULPI bus is not only for host, but for device mode too, so move > > it out from host's Kconfig. > > > > Cc: Heikki Krogerus > > Signed-off-by: Peter Chen > > --- > > drivers/usb/common/Kconfig | 21 + > > drivers/usb/core/Kconfig | 21 - > > 2 files changed, 21 insertions(+), 21 deletions(-) > > > > diff --git a/drivers/usb/common/Kconfig b/drivers/usb/common/Kconfig > > index 951b1d0..e251aec 100644 > > --- a/drivers/usb/common/Kconfig > > +++ b/drivers/usb/common/Kconfig > > @@ -7,3 +7,24 @@ config USB_LED_TRIG > > Say Y here if you are working on a system with led-class supported > > LEDs and you want to use them as activity indicators for USB host or > > gadget. > > + > > +config USB_ULPI_BUS > > + tristate "USB ULPI PHY interface support" > > + depends on USB_SUPPORT > > + help > > + UTMI+ Low Pin Interface (ULPI) is specification for a commonly used > > + USB 2.0 PHY interface. The ULPI specification defines a standard set > > + of registers that can be used to detect the vendor and product which > > + allows ULPI to be handled as a bus. This module is the driver for that > > + bus. > > + > > + The ULPI interfaces (the buses) are registered by the drivers for USB > > + controllers which support ULPI register access and have ULPI PHY > > + attached to them. The ULPI PHY drivers themselves are normal PHY > > + drivers. > > + > > + ULPI PHYs provide often functions such as ADP sensing/probing (OTG > > + protocol) and USB charger detection. > > + > > + To compile this driver as a module, choose M here: the module will > > + be called ulpi. > > diff --git a/drivers/usb/core/Kconfig b/drivers/usb/core/Kconfig > > index dd28010..d6e43ce 100644 > > --- a/drivers/usb/core/Kconfig > > +++ b/drivers/usb/core/Kconfig > > @@ -82,24 +82,3 @@ config USB_OTG_FSM > > help > > Implements OTG Finite State Machine as specified in On-The-Go > > and Embedded Host Supplement to the USB Revision 2.0 Specification. > > - > > -config USB_ULPI_BUS > > - tristate "USB ULPI PHY interface support" > > - depends on USB_SUPPORT > > This patch does not apply. The above line has been removed at one > point. > > Once you resend, please re-add the dependency once you move the config > to drivers/usb/common/Kconfig. > I don't need to add "USB_SUPPORT" since all USB Kconfig is under USB_SUPPORT, you can check drivers/usb/Kconfig. -- Best Regards, Peter Chen -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Gadgetfs - adding support for delegation of setup requests
Hi, On Tue, Aug 16, 2016 at 11:36 AM, Felipe Balbi wrote: > > Hi, > > Binyamin Sharet writes: >>> Alan Stern writes: > I'm using GadgetFs for USB host fuzzing (using umap2), > and part of the fuzzing session is to send invalid descriptors at > various stages. > > However, some requests are not delegated to user-land (see > gadgetfs_setup() > in gadget/legacy/inode.c), > Specifically - GET_DESCRIPTOR (device/configuration) and > SET_CONFIGURATION. >>> >>> that's because they don't have to be. Kernel caches the descriptors you >>> write during gadgetfs initialization and just returns >>> that. >>> >> >> As I see it, there are at least two issues with that: >> 1. gadgetfs can't handle complex, valid descriptor, such as Class >> Specific descriptors, >> this means that I can't emulate audio devices for example. > > why not? The first thing you do when you start out your gadgetfs daemon > is write descriptors which kernel will use. Just write *all* descriptors > you need. > Seems like I was wrong about this one. >> 2. At least in my case, where I wan't to use gadgetfs for fuzzing >> other USB hosts, I >> can't really fuzz various stages of the enumeration phase, >> specifically in the case of >> descriptors that are usually requested at least twice (e.g. >> configuration descriptor) > > you are not allowed to change your descriptors on the fly. Descriptors > are static. Configuration descriptor is requested twice for a simple > reason: Host doesn't know how big a configuration you have; so it asks > only for the first 9 bytes which will contain bLength. Then host uses > bLength to figure how big is your configuration and subsequently fetches > the entire thing. > I agree that in normal operation I am not allowed to change the descriptors on the fly, and as to why the configuration descriptor is requested twice. However, this is the exact point of fuzzing, looking for issues with descriptor parsing and ToC/ToU issues related to the assumptions made based on the first descriptor (e.g. first 9 bytes of the configuration descriptor). > Does a patch to switch the gadgetfs module to "delegate all" sounds > reasonable? > If so - what's the preferred way to do it? I have a few options in mind: Why do you need to delegate Get-Descriptor? The contents of the response are entirely dictated by the descriptors provided by the user program in the first place. Set-Configuration _is_ delegated to the user program, although the program is not allowed to fail the request. Is that what you want to do? > - module parameter > - write some command to the ep0 file > - send an ioctl to the ep0 file > > Any other suggestion? I suspect this sort of thing would not be accepted. If Felipe agrees, you might as well just keep your changes out-of-tree. >>> >>> This will just open up a can of worms, I'm afraid. What we have today >>> can even pass all USBCV tests, we're not breaking that, sorry. >>> >> >> I get your point, what I propose is not to change the default behavior >> of gadgetfs, >> but allow it to enter to a special mode by the user. I am aware of the >> issues that it >> might raise, and understand your concerns. However, I am asking about >> modifications in a specific, contained context. I would prefer to have it in >> the >> mainline kernel, but if you don't think it fits - I will keep those >> changes as an >> out-of-tree module. > > you're gonna have a really hard time getting anything in mainline > without explaining your goal. All you said is: "I wanna do fuzzying", > but fuzzying of what exactly? Why do you need to fuzz during > enumeration? This makes no sense. Gadgets are _not_ allowed to change > their descriptors and kernel doesn't allow userspace to do that. If you > wanna change your descriptor, then you _must_ disconnect from the host > and write brand new descriptors during gadgetfs initialization. > Sorry if I wasn't clear enough. We maintain a tool called Umap2, its goal is to perform security assessment of USB hosts. It does so in multiple ways, and one of them is fuzzing the USB host by sending invalid/unexpected packets over USB, including packets in the enumeration phase. There could be multiple issues with USB host stack during enumeration, and the fuzzing umap2 performs target those issues. However, this kind of operation requires a very low level control over the traffic, and until now it was done using Facedancer, which is a designated HW. gadgetfs looked to me like the USB equivalent for "raw socket" as a USB device, so I thought we could use it to enable umap2 on beaglebone black and similar boards that run Linux instead of Facedancer. I hope this is clearer. If you think that there is some other kernel module that is better suited to this task, I would be happy to hear about it. > -- > balbi -- To unsubscribe from this list: send the line "unsubscribe linu
[PATCH 1/1] usb: Kconfig: move ulpi bus support out of host
The ULPI bus is not only for host, but for device mode too, so move it out from host's Kconfig. Cc: Heikki Krogerus Signed-off-by: Peter Chen --- drivers/usb/Kconfig | 20 drivers/usb/core/Kconfig | 20 2 files changed, 20 insertions(+), 20 deletions(-) diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig index 8689dcb..6dfa10a 100644 --- a/drivers/usb/Kconfig +++ b/drivers/usb/Kconfig @@ -160,4 +160,24 @@ config USB_LED_TRIG LEDs and you want to use them as activity indicators for USB host or gadget. +config USB_ULPI_BUS + tristate "USB ULPI PHY interface support" + help + UTMI+ Low Pin Interface (ULPI) is specification for a commonly used + USB 2.0 PHY interface. The ULPI specification defines a standard set + of registers that can be used to detect the vendor and product which + allows ULPI to be handled as a bus. This module is the driver for that + bus. + + The ULPI interfaces (the buses) are registered by the drivers for USB + controllers which support ULPI register access and have ULPI PHY + attached to them. The ULPI PHY drivers themselves are normal PHY + drivers. + + ULPI PHYs provide often functions such as ADP sensing/probing (OTG + protocol) and USB charger detection. + + To compile this driver as a module, choose M here: the module will + be called ulpi. + endif # USB_SUPPORT diff --git a/drivers/usb/core/Kconfig b/drivers/usb/core/Kconfig index 253aac7..d6e43ce 100644 --- a/drivers/usb/core/Kconfig +++ b/drivers/usb/core/Kconfig @@ -82,23 +82,3 @@ config USB_OTG_FSM help Implements OTG Finite State Machine as specified in On-The-Go and Embedded Host Supplement to the USB Revision 2.0 Specification. - -config USB_ULPI_BUS - tristate "USB ULPI PHY interface support" - help - UTMI+ Low Pin Interface (ULPI) is specification for a commonly used - USB 2.0 PHY interface. The ULPI specification defines a standard set - of registers that can be used to detect the vendor and product which - allows ULPI to be handled as a bus. This module is the driver for that - bus. - - The ULPI interfaces (the buses) are registered by the drivers for USB - controllers which support ULPI register access and have ULPI PHY - attached to them. The ULPI PHY drivers themselves are normal PHY - drivers. - - ULPI PHYs provide often functions such as ADP sensing/probing (OTG - protocol) and USB charger detection. - - To compile this driver as a module, choose M here: the module will - be called ulpi. -- 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 v2 0/3] USB Audio Gadget refactoring
On Tue, Aug 16, 2016 at 11:32:55AM +0200, Clemens Ladisch wrote: > Peter Chen wrote: > > I find UAC2 (UAC1 is ok) support is not well with the latest mainline > > kernel w/o your patch set. The windows7 can't install the driver > > successfully > > Windows does not have UAC2 support. > Thanks, before windows7 or all windows versions have no UAC2 support? > > and the playback shows underrun (using local codec) > > using Linux host. > > > # arecord -f dat -t wav -D hw:1,0 | aplay -D hw:0,0 & > > The clocks of the two devices are not synchronized. > > In the ALSA API, a PCM device is assumed to have its own clock, so it is > not possible to synchronize the USB gadget to the actual sound device > without some separate mechanism (like the old uac1 gadget probably has). > The reason for immediate underrun is the small USB request number. The default request number of USB is 2 for UAC2, but 256 for UAC1. I have a internal 4.1.y version which works fine for UAC2 with only two requests, maybe ALSA has changed some recently. Yes, we need feedback endpoint to adjust sample rate for mismatch clocks between USB and codec. -- Best Regards, Peter Chen -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/3] USB Audio Gadget refactoring
Peter Chen wrote: > On Tue, Aug 16, 2016 at 11:32:55AM +0200, Clemens Ladisch wrote: >> Windows does not have UAC2 support. > > Thanks, before windows7 or all windows versions have no UAC2 support? So far, no version has it. Regards, Clemens -- 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 v10 5/5] usb: dwc3: add rockchip specific glue layer
Dear Balbi，
On 2016/8/16 15:19, Felipe Balbi wrote:
Hi,
William Wu writes:
Add rockchip specific glue layer to support USB3 Peripheral mode
and Host mode on rockchip platforms (e.g. rk3399).
The DesignWare USB3 integrated in rockchip SoCs is a configurable
IP Core which can be instantiated as Dual-Role Device (DRD), Host
Only (XHCI) and Peripheral Only configurations.
We use extcon notifier to manage usb cable detection and mode switch.
Enable DWC3 PM runtime auto suspend to allow core enter runtime_suspend
if USB cable is dettached. For host mode, it requires to keep whole
DWC3 controller in reset state to hold pipe power state in P2 before
initializing PHY. And it need to reconfigure USB PHY interface of DWC3
core after deassert DWC3 controller reset.
The current driver supports Host only and Peripheral Only well, for
now, we will add support for OTG after we have it all stabilized.
Signed-off-by: William Wu
---
Changes in v10:
- fix building error
Changes in v9:
- Add a new dwc3-rockchip.c driver for rk3399, rather than use dwc3-of-simple.c
drivers/usb/dwc3/Kconfig | 9 +
drivers/usb/dwc3/Makefile| 1 +
drivers/usb/dwc3/core.c | 2 +-
drivers/usb/dwc3/core.h | 1 +
drivers/usb/dwc3/dwc3-rockchip.c | 441 +++
William, if you need to touch core dwc3 to introduce a glue layer,
you're doing it wrong.
Sorry， I realized that it's not better to touch core dwc3 in a specific
glue layer.
I touched dwc3 in glue layer, because I want to support dual-role mode， and
according to our dwc3 IP and usb3 PHY IP design， it need to reinit dwc3
core
whenever usb cable attached.
Anyway, it's wrong to do that.:-[
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index e887b38..3da6215 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -405,7 +405,7 @@ static void dwc3_cache_hwparams(struct dwc3 *dwc)
* initialized. The PHY interfaces and the PHYs get initialized together with
* the core in dwc3_core_init.
*/
-static int dwc3_phy_setup(struct dwc3 *dwc)
+int dwc3_phy_setup(struct dwc3 *dwc)
there's no way I'll let this slip through the cracks :-)
Why I need dwc3_phy_setup in glue layer is because usb3 IP design
in rockchip platform. If dwc3 works on host mode, it requires to put
dwc3 controller in reset state before usb3 phy initializing，and after
deassert reset, we need to reconfigure UTMI+ PHY interface because
our dwc3 core can't configure PHY interface correctly.
Thank you for give me a chance to explain it.:-)
diff --git a/drivers/usb/dwc3/dwc3-rockchip.c b/drivers/usb/dwc3/dwc3-rockchip.c
new file mode 100644
index 000..eeae1a9
--- /dev/null
+++ b/drivers/usb/dwc3/dwc3-rockchip.c
@@ -0,0 +1,441 @@
[...]
+static int dwc3_rockchip_probe(struct platform_device *pdev)
+{
+ struct dwc3_rockchip*rockchip;
+ struct device *dev = &pdev->dev;
+ struct device_node *np = dev->of_node, *child;
+ struct platform_device *child_pdev;
+
+ unsigned intcount;
+ int ret;
+ int i;
+
+ rockchip = devm_kzalloc(dev, sizeof(*rockchip), GFP_KERNEL);
+
+ if (!rockchip)
+ return -ENOMEM;
+
+ count = of_clk_get_parent_count(np);
+ if (!count)
+ return -ENOENT;
+
+ rockchip->num_clocks = count;
+
+ rockchip->clks = devm_kcalloc(dev, rockchip->num_clocks,
+ sizeof(struct clk *), GFP_KERNEL);
+ if (!rockchip->clks)
+ return -ENOMEM;
+
+ platform_set_drvdata(pdev, rockchip);
+
+ rockchip->dev = dev;
+ rockchip->edev = NULL;
+
+ pm_runtime_set_active(dev);
+ pm_runtime_enable(dev);
+ ret = pm_runtime_get_sync(dev);
+ if (ret < 0) {
+ dev_err(dev, "get_sync failed with err %d\n", ret);
+ goto err1;
+ }
+
+ for (i = 0; i < rockchip->num_clocks; i++) {
+ struct clk *clk;
+
+ clk = of_clk_get(np, i);
+ if (IS_ERR(clk)) {
+ while (--i >= 0)
+ clk_put(rockchip->clks[i]);
+ ret = PTR_ERR(clk);
+
+ goto err1;
+ }
+
+ ret = clk_prepare_enable(clk);
+ if (ret < 0) {
+ while (--i >= 0) {
+ clk_disable_unprepare(rockchip->clks[i]);
+ clk_put(rockchip->clks[i]);
+ }
+ clk_put(clk);
+
+ goto err1;
+ }
+
+ rockchip->clks[i] = clk;
+ }
+
+ rockchip->otg_rst = devm_reset_control_get(dev, "usb3-otg");
+ if (IS_ERR(rockchip->otg_rst)) {
+ dev_err(dev, "could not get reset controller\n");
+ ret = PTR
Re: [PATCH] scsi: introduce a quirk for false cache reporting
On Tue, 2016-08-16 at 00:44 -0400, Martin K. Petersen wrote:
> > "Oliver" == Oliver Neukum writes:
>
> Oliver,
>
> Oliver> wce_default_on controls the default if the device provides no
> Oliver> indication. The problem here is that the indication the device
> Oliver> provides must be overridden, as they are false.
>
> Can't you just blacklist the mode select on the device in question?
>
> Something like:
>
> if (us->fflags & US_FL_ALWAYS_SYNC) {
> sdev->skip_ms_page_3f = 1;
> sdev->skip_ms_page_8 = 1;
> sdev->wce_default_on = 1;
> }
>
> ?
Hi,
this looks like a workable option. I am preparing a patch.
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: Gadgetfs - adding support for delegation of setup requests
On Tue, Aug 16, 2016 at 12:37:07PM +0300, Binyamin Sharet wrote: > Hi, > > On Tue, Aug 16, 2016 at 11:36 AM, Felipe Balbi > wrote: > > > > Hi, > > > > Binyamin Sharet writes: > >>> Alan Stern writes: > > I'm using GadgetFs for USB host fuzzing (using umap2), > > and part of the fuzzing session is to send invalid descriptors at > > various stages. > > > > However, some requests are not delegated to user-land (see > > gadgetfs_setup() > > in gadget/legacy/inode.c), > > Specifically - GET_DESCRIPTOR (device/configuration) and > > SET_CONFIGURATION. > >>> > >>> that's because they don't have to be. Kernel caches the descriptors you > >>> write during gadgetfs initialization and just returns > >>> that. > >>> > >> > >> As I see it, there are at least two issues with that: > >> 1. gadgetfs can't handle complex, valid descriptor, such as Class > >> Specific descriptors, > >> this means that I can't emulate audio devices for example. > > > > why not? The first thing you do when you start out your gadgetfs daemon > > is write descriptors which kernel will use. Just write *all* descriptors > > you need. > > > > Seems like I was wrong about this one. > > >> 2. At least in my case, where I wan't to use gadgetfs for fuzzing > >> other USB hosts, I > >> can't really fuzz various stages of the enumeration phase, > >> specifically in the case of > >> descriptors that are usually requested at least twice (e.g. > >> configuration descriptor) > > > > you are not allowed to change your descriptors on the fly. Descriptors > > are static. Configuration descriptor is requested twice for a simple > > reason: Host doesn't know how big a configuration you have; so it asks > > only for the first 9 bytes which will contain bLength. Then host uses > > bLength to figure how big is your configuration and subsequently fetches > > the entire thing. > > > > I agree that in normal operation I am not allowed to change the descriptors > on the fly, and as to why the configuration descriptor is requested twice. > > However, this is the exact point of fuzzing, looking for issues with > descriptor > parsing and ToC/ToU issues related to the assumptions made based on the > first descriptor (e.g. first 9 bytes of the configuration descriptor). Ah, hahaha, this is going to be "fun"... The reason all USB stacks do a two-step-read of the config is to do the first read to see how big the structure is, and the second one to read the "whole" thing. Now, if you change the size in-between, two things would happen: - second structure is bigger than what you originally said: - nothing bad happens as you only read the original value's size. - second structure is smaller than what you said: - nothing bad happens as you return a smaller configuration size. Try it and see, if the above is not correct, we should fix our configuration parser in the kernel. It will be fun to see what other operating systems do at this level as well, odds are it will be the same. > Sorry if I wasn't clear enough. We maintain a tool called Umap2, its goal is > to perform security assessment of USB hosts. It does so in multiple ways, > and one of them is fuzzing the USB host by sending invalid/unexpected > packets over USB, including packets in the enumeration phase. There could > be multiple issues with USB host stack during enumeration, and the fuzzing > umap2 performs target those issues. Have you found any Linux kernel issues that we have not fixed yet? I know of a number of other people doing this work right now, so hopefully we have caught most of these issues (although I do want to move some of the checks into the USB core, instead of forcing each individual driver to do them, I would _love_ patches to do that...) I like this work happening, and if we can use the gadget code in some way to help this out, that's great, it should allow us to automate a lot of this work much better and be able to add it to our regression and build tests. 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 v10 5/5] usb: dwc3: add rockchip specific glue layer
Hi,
"William.wu" writes:
>> William Wu writes:
>>> Add rockchip specific glue layer to support USB3 Peripheral mode
>>> and Host mode on rockchip platforms (e.g. rk3399).
>>>
>>> The DesignWare USB3 integrated in rockchip SoCs is a configurable
>>> IP Core which can be instantiated as Dual-Role Device (DRD), Host
>>> Only (XHCI) and Peripheral Only configurations.
>>>
>>> We use extcon notifier to manage usb cable detection and mode switch.
>>> Enable DWC3 PM runtime auto suspend to allow core enter runtime_suspend
>>> if USB cable is dettached. For host mode, it requires to keep whole
>>> DWC3 controller in reset state to hold pipe power state in P2 before
>>> initializing PHY. And it need to reconfigure USB PHY interface of DWC3
>>> core after deassert DWC3 controller reset.
>>>
>>> The current driver supports Host only and Peripheral Only well, for
>>> now, we will add support for OTG after we have it all stabilized.
>>>
>>> Signed-off-by: William Wu
>>> ---
>>> Changes in v10:
>>> - fix building error
>>>
>>> Changes in v9:
>>> - Add a new dwc3-rockchip.c driver for rk3399, rather than use
>>> dwc3-of-simple.c
>>>
>>> drivers/usb/dwc3/Kconfig | 9 +
>>> drivers/usb/dwc3/Makefile| 1 +
>>> drivers/usb/dwc3/core.c | 2 +-
>>> drivers/usb/dwc3/core.h | 1 +
>>> drivers/usb/dwc3/dwc3-rockchip.c | 441
>>> +++
>> William, if you need to touch core dwc3 to introduce a glue layer,
>> you're doing it wrong.
>
> Sorry， I realized that it's not better to touch core dwc3 in a specific
> glue layer.
> I touched dwc3 in glue layer, because I want to support dual-role mode， and
> according to our dwc3 IP and usb3 PHY IP design， it need to reinit dwc3
> core
> whenever usb cable attached.
>
> Anyway, it's wrong to do that.:-[
>
>>> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
>>> index e887b38..3da6215 100644
>>> --- a/drivers/usb/dwc3/core.c
>>> +++ b/drivers/usb/dwc3/core.c
>>> @@ -405,7 +405,7 @@ static void dwc3_cache_hwparams(struct dwc3 *dwc)
>>>* initialized. The PHY interfaces and the PHYs get initialized together
>>> with
>>>* the core in dwc3_core_init.
>>>*/
>>> -static int dwc3_phy_setup(struct dwc3 *dwc)
>>> +int dwc3_phy_setup(struct dwc3 *dwc)
>> there's no way I'll let this slip through the cracks :-)
>
> Why I need dwc3_phy_setup in glue layer is because usb3 IP design
> in rockchip platform. If dwc3 works on host mode, it requires to put
> dwc3 controller in reset state before usb3 phy initializing，and after
> deassert reset, we need to reconfigure UTMI+ PHY interface because
> our dwc3 core can't configure PHY interface correctly.
>
> Thank you for give me a chance to explain it.:-)
>
>>
>>> diff --git a/drivers/usb/dwc3/dwc3-rockchip.c
>>> b/drivers/usb/dwc3/dwc3-rockchip.c
>>> new file mode 100644
>>> index 000..eeae1a9
>>> --- /dev/null
>>> +++ b/drivers/usb/dwc3/dwc3-rockchip.c
>>> @@ -0,0 +1,441 @@
>> [...]
>>
>>> +static int dwc3_rockchip_probe(struct platform_device *pdev)
>>> +{
>>> + struct dwc3_rockchip*rockchip;
>>> + struct device *dev = &pdev->dev;
>>> + struct device_node *np = dev->of_node, *child;
>>> + struct platform_device *child_pdev;
>>> +
>>> + unsigned intcount;
>>> + int ret;
>>> + int i;
>>> +
>>> + rockchip = devm_kzalloc(dev, sizeof(*rockchip), GFP_KERNEL);
>>> +
>>> + if (!rockchip)
>>> + return -ENOMEM;
>>> +
>>> + count = of_clk_get_parent_count(np);
>>> + if (!count)
>>> + return -ENOENT;
>>> +
>>> + rockchip->num_clocks = count;
>>> +
>>> + rockchip->clks = devm_kcalloc(dev, rockchip->num_clocks,
>>> + sizeof(struct clk *), GFP_KERNEL);
>>> + if (!rockchip->clks)
>>> + return -ENOMEM;
>>> +
>>> + platform_set_drvdata(pdev, rockchip);
>>> +
>>> + rockchip->dev = dev;
>>> + rockchip->edev = NULL;
>>> +
>>> + pm_runtime_set_active(dev);
>>> + pm_runtime_enable(dev);
>>> + ret = pm_runtime_get_sync(dev);
>>> + if (ret < 0) {
>>> + dev_err(dev, "get_sync failed with err %d\n", ret);
>>> + goto err1;
>>> + }
>>> +
>>> + for (i = 0; i < rockchip->num_clocks; i++) {
>>> + struct clk *clk;
>>> +
>>> + clk = of_clk_get(np, i);
>>> + if (IS_ERR(clk)) {
>>> + while (--i >= 0)
>>> + clk_put(rockchip->clks[i]);
>>> + ret = PTR_ERR(clk);
>>> +
>>> + goto err1;
>>> + }
>>> +
>>> + ret = clk_prepare_enable(clk);
>>> + if (ret < 0) {
>>> + while (--i >= 0) {
>>> + clk_disable_unprepare(rockchip->clks[i]);
>>> + clk_put(rockchip->clks[i]);
>>> + }
>>> + clk_put(clk);
>>> +
>>> + goto err1;
>>> +
Re: [PATCH 2/2] usb: gadget: f_ncm: add support for scatter/gather SKB to enable GSO
Hello, 16.08.2016, 10:41, Felipe Balbi kirjoitti: > > Hi, > > Jussi Kivilinna writes: >> Enabling SG allows enabling GSO (generic segmentation offload) feature >> of linux networking layer. This increases TCP throughput with NCM >> on Cortex-A15+USB3380 based device from 300 Mbit/s to 1.1 Gbit/s. >> >> Signed-off-by: Jussi Kivilinna > > this is AWESOME!! :-) But here's the thing, any chance we can build this > in u_ether.c ? Also, NETIF_F_SG should be conditional on > gadget->sg_supported so that we don't break UDCs that don't support > sglists. > Actually, no sglists are passed to UDC. Reason why this work with minimal changes for NCM is that NCM does tx buffering in its wrap function.. 'ncm_wrap_ntb' copies input skbuffs to larger skbuff, so enabling SG is only matter of changing that skbuff data copy from 'memcpy' to 'skb_copy_bits' (and changing CRC calculation work with skbuff fragments). Since NCM already does copying, SG can be enabled for NCM without extra overhead. To see if NETIF_F_SG with skbuff copying made difference with other networking gadgets, I made quick test for RNDIS gadget to enable NETIF_F_SG by adding skb_linearize_cow call to 'rndis_add_header' wrap function. TCP transfer from device to host: without SG: 265 Mbit/s with SG:326 Mbit/s So, adding NETIF_F_SG with skbuff linearization in u_ether could improve performance little bit. For higher speeds with USB3380/SuperSpeed, either larger MTU or NCM (with its tx buffering) is needed. Here's earlier CDC EEM results on different MTUs, without NETIF_F_SG change, on same hw: MTU=1500: 169 Mbit/s MTU=15000: 1.23 Gbit/s and on Intel PC + USB3380: MTU=1500: 259 Mbit/s MTU=3000: 452 Mbit/s MTU=4500: 575 Mbit/s MTU=9000: 823 Mbit/s MTU=12000: 934 Mbit/s MTU=15000: 1000 Mbit/s -Jussi -- 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: Gadgetfs - adding support for delegation of setup requests
Hi, Binyamin Sharet writes: >>> 2. At least in my case, where I wan't to use gadgetfs for fuzzing >>> other USB hosts, I >>> can't really fuzz various stages of the enumeration phase, >>> specifically in the case of >>> descriptors that are usually requested at least twice (e.g. >>> configuration descriptor) >> >> you are not allowed to change your descriptors on the fly. Descriptors >> are static. Configuration descriptor is requested twice for a simple >> reason: Host doesn't know how big a configuration you have; so it asks >> only for the first 9 bytes which will contain bLength. Then host uses >> bLength to figure how big is your configuration and subsequently fetches >> the entire thing. >> > > I agree that in normal operation I am not allowed to change the descriptors > on the fly, and as to why the configuration descriptor is requested twice. > > However, this is the exact point of fuzzing, looking for issues with > descriptor > parsing and ToC/ToU issues related to the assumptions made based on the > first descriptor (e.g. first 9 bytes of the configuration descriptor). That's an assumption mandated by the spec, though. I wouldn't be surprised if some implementations fail this. Have you found any bug so far? >> Does a patch to switch the gadgetfs module to "delegate all" sounds >> reasonable? >> If so - what's the preferred way to do it? I have a few options in mind: > > Why do you need to delegate Get-Descriptor? The contents of the > response are entirely dictated by the descriptors provided by the user > program in the first place. > > Set-Configuration _is_ delegated to the user program, although the > program is not allowed to fail the request. Is that what you want to > do? > >> - module parameter >> - write some command to the ep0 file >> - send an ioctl to the ep0 file >> >> Any other suggestion? > > I suspect this sort of thing would not be accepted. If Felipe agrees, > you might as well just keep your changes out-of-tree. This will just open up a can of worms, I'm afraid. What we have today can even pass all USBCV tests, we're not breaking that, sorry. >>> >>> I get your point, what I propose is not to change the default behavior >>> of gadgetfs, >>> but allow it to enter to a special mode by the user. I am aware of the >>> issues that it >>> might raise, and understand your concerns. However, I am asking about >>> modifications in a specific, contained context. I would prefer to have it >>> in the >>> mainline kernel, but if you don't think it fits - I will keep those >>> changes as an >>> out-of-tree module. >> >> you're gonna have a really hard time getting anything in mainline >> without explaining your goal. All you said is: "I wanna do fuzzying", >> but fuzzying of what exactly? Why do you need to fuzz during >> enumeration? This makes no sense. Gadgets are _not_ allowed to change >> their descriptors and kernel doesn't allow userspace to do that. If you >> wanna change your descriptor, then you _must_ disconnect from the host >> and write brand new descriptors during gadgetfs initialization. >> > > Sorry if I wasn't clear enough. We maintain a tool called Umap2, its goal is > to perform security assessment of USB hosts. It does so in multiple ways, > and one of them is fuzzing the USB host by sending invalid/unexpected > packets over USB, including packets in the enumeration phase. There could > be multiple issues with USB host stack during enumeration, and the fuzzing > umap2 performs target those issues. have you found any bugs yet? > However, this kind of operation requires a very low level control over the > traffic, and until now it was done using Facedancer, which is a designated > HW. gadgetfs looked to me like the USB equivalent for "raw socket" as a > USB device, so I thought we could use it to enable umap2 on beaglebone > black and similar boards that run Linux instead of Facedancer. > > I hope this is clearer. If you think that there is some other kernel module > that is better suited to this task, I would be happy to hear about it. The kernel is not exactly meant for pentesting USB host stacks :-) Here's what we can do, for now keep an out-of-tree patch. If/when you find actual bugs, then we can reconsider adding this support if, and only if, it's really difficult to enable (for example, it should depend on EXPERT or something along those lines). We don't want this to ever leak to production systems, so we need to make it really annoying to get enabled. Anyway, first things first, let us know if/when you trigger any bugs with this. -- balbi signature.asc Description: PGP signature
Re: [PATCH v2 03/10] usb: ulpi: use new api functions if available
Hi,
On Mon, Aug 01, 2016 at 09:15:51PM +0300, Tal Shorer wrote:
> If the registered has the new api callbacks {read|write}_dev, call
> these instead of the deprecated read, write functions. If the
> registered does not support the new callbacks, revert to calling the
> old ones as before.
>
> Signed-off-by: Tal Shorer
> ---
> drivers/usb/common/ulpi.c | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/usb/common/ulpi.c b/drivers/usb/common/ulpi.c
> index d1f419c..a877ddb 100644
> --- a/drivers/usb/common/ulpi.c
> +++ b/drivers/usb/common/ulpi.c
> @@ -21,13 +21,17 @@
>
> int ulpi_read(struct ulpi *ulpi, u8 addr)
> {
> - return ulpi->ops->read(ulpi->ops, addr);
> + if (!ulpi->ops->read_dev)
> + return ulpi->ops->read(ulpi->ops, addr);
> + return ulpi->ops->read_dev(ulpi->dev.parent, addr);
> }
> EXPORT_SYMBOL_GPL(ulpi_read);
>
> int ulpi_write(struct ulpi *ulpi, u8 addr, u8 val)
> {
> - return ulpi->ops->write(ulpi->ops, addr, val);
> + if (!ulpi->ops->write_dev)
> + return ulpi->ops->write(ulpi->ops, addr, val);
> + return ulpi->ops->write_dev(ulpi->dev.parent, addr, val);
> }
> EXPORT_SYMBOL_GPL(ulpi_write);
>
> --
> 2.7.4
Squash patches 2-3 into one patch.
Thanks,
--
heikki
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 06/10] usb: ulpi: remove old api callbacks from struct ulpi_ops
On Mon, Aug 01, 2016 at 09:15:54PM +0300, Tal Shorer wrote:
> The old api callbacks, read() and write(), are not referenced anywhere.
> Remove them.
>
> Signed-off-by: Tal Shorer
> ---
> include/linux/ulpi/interface.h | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/include/linux/ulpi/interface.h b/include/linux/ulpi/interface.h
> index d8189d0..71f3c99 100644
> --- a/include/linux/ulpi/interface.h
> +++ b/include/linux/ulpi/interface.h
> @@ -13,8 +13,6 @@ struct ulpi;
> */
> struct ulpi_ops {
> struct device *dev;
> - int (*read)(struct ulpi_ops *ops, u8 addr);
> - int (*write)(struct ulpi_ops *ops, u8 addr, u8 val);
> int (*read_dev)(struct device *dev, u8 addr);
> int (*write_dev)(struct device *dev, u8 addr, u8 val);
> };
> --
> 2.7.4
Squash patches 5-6 into one patch.
Thanks,
--
heikki
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] usb: gadget: f_ncm: add support for scatter/gather SKB to enable GSO
Hi Jussi, Jussi Kivilinna writes: >> Jussi Kivilinna writes: >>> Enabling SG allows enabling GSO (generic segmentation offload) feature >>> of linux networking layer. This increases TCP throughput with NCM >>> on Cortex-A15+USB3380 based device from 300 Mbit/s to 1.1 Gbit/s. >>> >>> Signed-off-by: Jussi Kivilinna >> >> this is AWESOME!! :-) But here's the thing, any chance we can build this >> in u_ether.c ? Also, NETIF_F_SG should be conditional on >> gadget->sg_supported so that we don't break UDCs that don't support >> sglists. >> > > Actually, no sglists are passed to UDC. Reason why this work > with minimal changes for NCM is that NCM does tx buffering > in its wrap function.. 'ncm_wrap_ntb' copies input skbuffs to > larger skbuff, so enabling SG is only matter of changing that > skbuff data copy from 'memcpy' to 'skb_copy_bits' (and changing > CRC calculation work with skbuff fragments). Since NCM already > does copying, SG can be enabled for NCM without extra overhead. aha, understood. Now what if we skip copying altogether? If we have an sg and a UDC that supports sg (gadget->sg_supported = 1), then we can avoid copying, right? > To see if NETIF_F_SG with skbuff copying made difference with > other networking gadgets, I made quick test for RNDIS gadget to > enable NETIF_F_SG by adding skb_linearize_cow call to > 'rndis_add_header' wrap function. TCP transfer from device to > host: > without SG: 265 Mbit/s > with SG:326 Mbit/s > > So, adding NETIF_F_SG with skbuff linearization in u_ether > could improve performance little bit. interesting. Does USB3380 support sglists? We could check how much more we get if we skip copying altogether. > For higher speeds with USB3380/SuperSpeed, either larger MTU or > NCM (with its tx buffering) is needed. Here's earlier CDC EEM > results on different MTUs, without NETIF_F_SG change, on same hw: > MTU=1500: 169 Mbit/s > MTU=15000: 1.23 Gbit/s > > and on Intel PC + USB3380: > MTU=1500: 259 Mbit/s > MTU=3000: 452 Mbit/s > MTU=4500: 575 Mbit/s > MTU=9000: 823 Mbit/s > MTU=12000: 934 Mbit/s > MTU=15000: 1000 Mbit/s cool, thanks for these numbers. This is very interesting, indeed. -- balbi signature.asc Description: PGP signature
Re: [PATCH v2 08/10] usb: ulpi: remove "dev" field from struct ulpi_ops
On Mon, Aug 01, 2016 at 09:15:56PM +0300, Tal Shorer wrote:
> /**
> * struct ulpi_ops - ULPI register access
> @@ -12,7 +13,6 @@ struct ulpi;
> * @write: write operation for ULPI register access
> */
> struct ulpi_ops {
> - struct device *dev;
Fix also the comment above (remove the line describing @dev).
Thanks,
--
heikki
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] usb: Kconfig: move ulpi bus support out of host
On Tue, Aug 16, 2016 at 05:33:25PM +0800, Peter Chen wrote: > The ULPI bus is not only for host, but for device mode too, so move > it out from host's Kconfig. > > Cc: Heikki Krogerus Acked-by: Heikki Krogerus Thanks, -- heikki -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] usb: gadget: f_ncm: add support for scatter/gather SKB to enable GSO
Hi again, Felipe Balbi writes: Enabling SG allows enabling GSO (generic segmentation offload) feature of linux networking layer. This increases TCP throughput with NCM on Cortex-A15+USB3380 based device from 300 Mbit/s to 1.1 Gbit/s. Signed-off-by: Jussi Kivilinna >>> >>> this is AWESOME!! :-) But here's the thing, any chance we can build this >>> in u_ether.c ? Also, NETIF_F_SG should be conditional on >>> gadget->sg_supported so that we don't break UDCs that don't support >>> sglists. >>> >> >> Actually, no sglists are passed to UDC. Reason why this work >> with minimal changes for NCM is that NCM does tx buffering >> in its wrap function.. 'ncm_wrap_ntb' copies input skbuffs to >> larger skbuff, so enabling SG is only matter of changing that >> skbuff data copy from 'memcpy' to 'skb_copy_bits' (and changing >> CRC calculation work with skbuff fragments). Since NCM already >> does copying, SG can be enabled for NCM without extra overhead. > > aha, understood. Now what if we skip copying altogether? If we have an > sg and a UDC that supports sg (gadget->sg_supported = 1), then we can > avoid copying, right? perhaps this is the crud of the change (still need to check for sg_supported)? diff --git a/drivers/usb/gadget/function/u_ether.c b/drivers/usb/gadget/function/u_ether.c index 5f562c1ec795..f3497cba32ec 100644 --- a/drivers/usb/gadget/function/u_ether.c +++ b/drivers/usb/gadget/function/u_ether.c @@ -235,7 +235,7 @@ rx_submit(struct eth_dev *dev, struct usb_request *req, gfp_t gfp_flags) */ skb_reserve(skb, NET_IP_ALIGN); - req->buf = skb->data; + req->num_sgs = skb_to_sgvec(skb, req->sg, 0, skb->len); req->length = size; req->complete = rx_complete; req->context = skb; -- balbi signature.asc Description: PGP signature
[PATCH v2] usb: chipidea: udc: don't touch DP when controller is in host mode
When the controller is configured to be dual role and it's in host mode,
if bind udc and gadgt driver, those gadget operations will do gadget
disconnect and finally pull down DP line, which will break host function.
Cc: # 4.1+
Signed-off-by: Li Jun
---
drivers/usb/chipidea/udc.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
index 761b804..846b77bc 100644
--- a/drivers/usb/chipidea/udc.c
+++ b/drivers/usb/chipidea/udc.c
@@ -1593,8 +1593,11 @@ static int ci_udc_pullup(struct usb_gadget *_gadget, int
is_on)
{
struct ci_hdrc *ci = container_of(_gadget, struct ci_hdrc, gadget);
- /* Data+ pullup controlled by OTG state machine in OTG fsm mode */
- if (ci_otg_is_fsm_mode(ci))
+ /*
+* Data+ pullup controlled by OTG state machine in OTG fsm mode;
+* and don't touch Data+ in host mode for dual role config.
+*/
+ if (ci_otg_is_fsm_mode(ci) || ci->role == CI_ROLE_HOST)
return 0;
pm_runtime_get_sync(&ci->gadget.dev);
--
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 v10 5/5] usb: dwc3: add rockchip specific glue layer
Dear Balbi,
On 2016/8/16 18:43, Felipe Balbi wrote:
Hi,
"William.wu" writes:
William Wu writes:
Add rockchip specific glue layer to support USB3 Peripheral mode
and Host mode on rockchip platforms (e.g. rk3399).
The DesignWare USB3 integrated in rockchip SoCs is a configurable
IP Core which can be instantiated as Dual-Role Device (DRD), Host
Only (XHCI) and Peripheral Only configurations.
We use extcon notifier to manage usb cable detection and mode switch.
Enable DWC3 PM runtime auto suspend to allow core enter runtime_suspend
if USB cable is dettached. For host mode, it requires to keep whole
DWC3 controller in reset state to hold pipe power state in P2 before
initializing PHY. And it need to reconfigure USB PHY interface of DWC3
core after deassert DWC3 controller reset.
The current driver supports Host only and Peripheral Only well, for
now, we will add support for OTG after we have it all stabilized.
Signed-off-by: William Wu
---
Changes in v10:
- fix building error
Changes in v9:
- Add a new dwc3-rockchip.c driver for rk3399, rather than use dwc3-of-simple.c
drivers/usb/dwc3/Kconfig | 9 +
drivers/usb/dwc3/Makefile| 1 +
drivers/usb/dwc3/core.c | 2 +-
drivers/usb/dwc3/core.h | 1 +
drivers/usb/dwc3/dwc3-rockchip.c | 441
+++
William, if you need to touch core dwc3 to introduce a glue layer,
you're doing it wrong.
Sorry， I realized that it's not better to touch core dwc3 in a specific
glue layer.
I touched dwc3 in glue layer, because I want to support dual-role mode， and
according to our dwc3 IP and usb3 PHY IP design， it need to reinit dwc3
core
whenever usb cable attached.
Anyway, it's wrong to do that.:-[
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index e887b38..3da6215 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -405,7 +405,7 @@ static void dwc3_cache_hwparams(struct dwc3 *dwc)
* initialized. The PHY interfaces and the PHYs get initialized together with
* the core in dwc3_core_init.
*/
-static int dwc3_phy_setup(struct dwc3 *dwc)
+int dwc3_phy_setup(struct dwc3 *dwc)
there's no way I'll let this slip through the cracks :-)
Why I need dwc3_phy_setup in glue layer is because usb3 IP design
in rockchip platform. If dwc3 works on host mode, it requires to put
dwc3 controller in reset state before usb3 phy initializing，and after
deassert reset, we need to reconfigure UTMI+ PHY interface because
our dwc3 core can't configure PHY interface correctly.
Thank you for give me a chance to explain it.:-)
diff --git a/drivers/usb/dwc3/dwc3-rockchip.c b/drivers/usb/dwc3/dwc3-rockchip.c
new file mode 100644
index 000..eeae1a9
--- /dev/null
+++ b/drivers/usb/dwc3/dwc3-rockchip.c
@@ -0,0 +1,441 @@
[...]
+static int dwc3_rockchip_probe(struct platform_device *pdev)
+{
+ struct dwc3_rockchip*rockchip;
+ struct device *dev = &pdev->dev;
+ struct device_node *np = dev->of_node, *child;
+ struct platform_device *child_pdev;
+
+ unsigned intcount;
+ int ret;
+ int i;
+
+ rockchip = devm_kzalloc(dev, sizeof(*rockchip), GFP_KERNEL);
+
+ if (!rockchip)
+ return -ENOMEM;
+
+ count = of_clk_get_parent_count(np);
+ if (!count)
+ return -ENOENT;
+
+ rockchip->num_clocks = count;
+
+ rockchip->clks = devm_kcalloc(dev, rockchip->num_clocks,
+ sizeof(struct clk *), GFP_KERNEL);
+ if (!rockchip->clks)
+ return -ENOMEM;
+
+ platform_set_drvdata(pdev, rockchip);
+
+ rockchip->dev = dev;
+ rockchip->edev = NULL;
+
+ pm_runtime_set_active(dev);
+ pm_runtime_enable(dev);
+ ret = pm_runtime_get_sync(dev);
+ if (ret < 0) {
+ dev_err(dev, "get_sync failed with err %d\n", ret);
+ goto err1;
+ }
+
+ for (i = 0; i < rockchip->num_clocks; i++) {
+ struct clk *clk;
+
+ clk = of_clk_get(np, i);
+ if (IS_ERR(clk)) {
+ while (--i >= 0)
+ clk_put(rockchip->clks[i]);
+ ret = PTR_ERR(clk);
+
+ goto err1;
+ }
+
+ ret = clk_prepare_enable(clk);
+ if (ret < 0) {
+ while (--i >= 0) {
+ clk_disable_unprepare(rockchip->clks[i]);
+ clk_put(rockchip->clks[i]);
+ }
+ clk_put(clk);
+
+ goto err1;
+ }
+
+ rockchip->clks[i] = clk;
+ }
+
+ rockchip->otg_rst = devm_reset_control_get(dev, "usb3-otg");
+ if (IS_ERR(rockchip->otg_rst)) {
+ dev_err(dev, "could not get reset controller\n");
+
Re: [PATCH v10 5/5] usb: dwc3: add rockchip specific glue layer
Hi,
"William.wu" writes:
>> "William.wu" writes:
William Wu writes:
> Add rockchip specific glue layer to support USB3 Peripheral mode
> and Host mode on rockchip platforms (e.g. rk3399).
>
> The DesignWare USB3 integrated in rockchip SoCs is a configurable
> IP Core which can be instantiated as Dual-Role Device (DRD), Host
> Only (XHCI) and Peripheral Only configurations.
>
> We use extcon notifier to manage usb cable detection and mode switch.
> Enable DWC3 PM runtime auto suspend to allow core enter runtime_suspend
> if USB cable is dettached. For host mode, it requires to keep whole
> DWC3 controller in reset state to hold pipe power state in P2 before
> initializing PHY. And it need to reconfigure USB PHY interface of DWC3
> core after deassert DWC3 controller reset.
>
> The current driver supports Host only and Peripheral Only well, for
> now, we will add support for OTG after we have it all stabilized.
>
> Signed-off-by: William Wu
> ---
> Changes in v10:
> - fix building error
>
> Changes in v9:
> - Add a new dwc3-rockchip.c driver for rk3399, rather than use
> dwc3-of-simple.c
>
>drivers/usb/dwc3/Kconfig | 9 +
>drivers/usb/dwc3/Makefile| 1 +
>drivers/usb/dwc3/core.c | 2 +-
>drivers/usb/dwc3/core.h | 1 +
>drivers/usb/dwc3/dwc3-rockchip.c | 441
> +++
William, if you need to touch core dwc3 to introduce a glue layer,
you're doing it wrong.
>>> Sorry， I realized that it's not better to touch core dwc3 in a specific
>>> glue layer.
>>> I touched dwc3 in glue layer, because I want to support dual-role mode， and
>>> according to our dwc3 IP and usb3 PHY IP design， it need to reinit dwc3
>>> core
>>> whenever usb cable attached.
>>>
>>> Anyway, it's wrong to do that.:-[
>>>
> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
> index e887b38..3da6215 100644
> --- a/drivers/usb/dwc3/core.c
> +++ b/drivers/usb/dwc3/core.c
> @@ -405,7 +405,7 @@ static void dwc3_cache_hwparams(struct dwc3 *dwc)
> * initialized. The PHY interfaces and the PHYs get initialized
> together with
> * the core in dwc3_core_init.
> */
> -static int dwc3_phy_setup(struct dwc3 *dwc)
> +int dwc3_phy_setup(struct dwc3 *dwc)
there's no way I'll let this slip through the cracks :-)
>>> Why I need dwc3_phy_setup in glue layer is because usb3 IP design
>>> in rockchip platform. If dwc3 works on host mode, it requires to put
>>> dwc3 controller in reset state before usb3 phy initializing，and after
>>> deassert reset, we need to reconfigure UTMI+ PHY interface because
>>> our dwc3 core can't configure PHY interface correctly.
>>>
>>> Thank you for give me a chance to explain it.:-)
>>>
> diff --git a/drivers/usb/dwc3/dwc3-rockchip.c
> b/drivers/usb/dwc3/dwc3-rockchip.c
> new file mode 100644
> index 000..eeae1a9
> --- /dev/null
> +++ b/drivers/usb/dwc3/dwc3-rockchip.c
> @@ -0,0 +1,441 @@
[...]
> +static int dwc3_rockchip_probe(struct platform_device *pdev)
> +{
> + struct dwc3_rockchip*rockchip;
> + struct device *dev = &pdev->dev;
> + struct device_node *np = dev->of_node, *child;
> + struct platform_device *child_pdev;
> +
> + unsigned intcount;
> + int ret;
> + int i;
> +
> + rockchip = devm_kzalloc(dev, sizeof(*rockchip), GFP_KERNEL);
> +
> + if (!rockchip)
> + return -ENOMEM;
> +
> + count = of_clk_get_parent_count(np);
> + if (!count)
> + return -ENOENT;
> +
> + rockchip->num_clocks = count;
> +
> + rockchip->clks = devm_kcalloc(dev, rockchip->num_clocks,
> + sizeof(struct clk *), GFP_KERNEL);
> + if (!rockchip->clks)
> + return -ENOMEM;
> +
> + platform_set_drvdata(pdev, rockchip);
> +
> + rockchip->dev = dev;
> + rockchip->edev = NULL;
> +
> + pm_runtime_set_active(dev);
> + pm_runtime_enable(dev);
> + ret = pm_runtime_get_sync(dev);
> + if (ret < 0) {
> + dev_err(dev, "get_sync failed with err %d\n", ret);
> + goto err1;
> + }
> +
> + for (i = 0; i < rockchip->num_clocks; i++) {
> + struct clk *clk;
> +
> + clk = of_clk_get(np, i);
> + if (IS_ERR(clk)) {
> + while (--i >= 0)
> + clk_put(rockchip->clks[i]);
> + ret = PTR_ERR(clk);
> +
> + goto err1;
> + }
> +
> + ret = clk_prepare_enable(clk);
> + if (ret < 0) {
> + while (--i >= 0) {
> + clk_disable_u
[PATCH] scsi: introduce a quirk for false cache reporting
Some SATA to USB bridges fail to cooperate with some
drives resulting in no cache being present being reported
to the host. That causes the host to skip sending
a command to synchronize caches. That causes data loss
when the drive is powered down.
Signed-off-by: Oliver Neukum
---
Documentation/kernel-parameters.txt | 2 ++
drivers/usb/storage/scsiglue.c | 8
drivers/usb/storage/unusual_devs.h | 7 +++
drivers/usb/storage/usb.c | 6 +-
include/linux/usb_usual.h | 2 ++
5 files changed, 24 insertions(+), 1 deletion(-)
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index 82b42c9..c8c682e 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -4182,6 +4182,8 @@ bytes respectively. Such letter suffixes can also be
entirely omitted.
u = IGNORE_UAS (don't bind to the uas driver);
w = NO_WP_DETECT (don't test whether the
medium is write-protected).
+ y = ALWAYS_SYNC (issue a SYNCHRONIZE_CACHE
+ even if the device claims no cache)
Example: quirks=0419:aaf5:rl,0421:0433:rc
user_debug= [KNL,ARM]
diff --git a/drivers/usb/storage/scsiglue.c b/drivers/usb/storage/scsiglue.c
index 33eb923..8cd2926 100644
--- a/drivers/usb/storage/scsiglue.c
+++ b/drivers/usb/storage/scsiglue.c
@@ -296,6 +296,14 @@ static int slave_configure(struct scsi_device *sdev)
if (us->fflags & US_FL_BROKEN_FUA)
sdev->broken_fua = 1;
+ /* Some even totally fail to indicate a cache */
+ if (us->fflags & US_FL_ALWAYS_SYNC) {
+ /* don't read caching information */
+ sdev->skip_ms_page_8 = 1;
+ sdev->skip_ms_page_3f = 1;
+ /* assume sync is needed */
+ sdev->wce_default_on = 1;
+ }
} else {
/*
diff --git a/drivers/usb/storage/unusual_devs.h
b/drivers/usb/storage/unusual_devs.h
index aa35392..af3c7ee 100644
--- a/drivers/usb/storage/unusual_devs.h
+++ b/drivers/usb/storage/unusual_devs.h
@@ -338,6 +338,13 @@ UNUSUAL_DEV( 0x046b, 0xff40, 0x0100, 0x0100,
USB_SC_DEVICE, USB_PR_DEVICE, NULL,
US_FL_NO_WP_DETECT),
+/* Reported by Egbert Eich */
+UNUSUAL_DEV( 0x0480, 0xd010, 0x0100, 0x,
+ "Toshiba",
+ "External USB 3.0",
+ USB_SC_DEVICE, USB_PR_DEVICE, NULL,
+ US_FL_ALWAYS_SYNC),
+
/* Patch submitted by Philipp Friedrich */
UNUSUAL_DEV( 0x0482, 0x0100, 0x0100, 0x0100,
"Kyocera",
diff --git a/drivers/usb/storage/usb.c b/drivers/usb/storage/usb.c
index ef2d8cd..19255f1 100644
--- a/drivers/usb/storage/usb.c
+++ b/drivers/usb/storage/usb.c
@@ -498,7 +498,8 @@ void usb_stor_adjust_quirks(struct usb_device *udev,
unsigned long *fflags)
US_FL_NO_READ_DISC_INFO | US_FL_NO_READ_CAPACITY_16 |
US_FL_INITIAL_READ10 | US_FL_WRITE_CACHE |
US_FL_NO_ATA_1X | US_FL_NO_REPORT_OPCODES |
- US_FL_MAX_SECTORS_240 | US_FL_NO_REPORT_LUNS);
+ US_FL_MAX_SECTORS_240 | US_FL_NO_REPORT_LUNS |
+ US_FL_ALWAYS_SYNC);
p = quirks;
while (*p) {
@@ -581,6 +582,9 @@ void usb_stor_adjust_quirks(struct usb_device *udev,
unsigned long *fflags)
case 'w':
f |= US_FL_NO_WP_DETECT;
break;
+ case 'y':
+ f |= US_FL_ALWAYS_SYNC;
+ break;
/* Ignore unrecognized flag characters */
}
}
diff --git a/include/linux/usb_usual.h b/include/linux/usb_usual.h
index 245f57d..0aae1b2 100644
--- a/include/linux/usb_usual.h
+++ b/include/linux/usb_usual.h
@@ -81,6 +81,8 @@
/* Sets max_sectors to 240 */ \
US_FLAG(NO_REPORT_LUNS, 0x1000) \
/* Cannot handle REPORT_LUNS */ \
+ US_FLAG(ALWAYS_SYNC, 0x2000)\
+ /* lies about caching, so always sync */\
#define US_FLAG(name, value) US_FL_##name = value ,
enum { US_DO_ALL_FLAGS };
--
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: Gadgetfs - adding support for delegation of setup requests
Felipe, Greg, You wrote pretty much the same things on two separate threads, so I will answer only here... On Tue, Aug 16, 2016 at 1:51 PM, Felipe Balbi wrote: > > Hi, > > Binyamin Sharet writes: 2. At least in my case, where I wan't to use gadgetfs for fuzzing other USB hosts, I can't really fuzz various stages of the enumeration phase, specifically in the case of descriptors that are usually requested at least twice (e.g. configuration descriptor) >>> >>> you are not allowed to change your descriptors on the fly. Descriptors >>> are static. Configuration descriptor is requested twice for a simple >>> reason: Host doesn't know how big a configuration you have; so it asks >>> only for the first 9 bytes which will contain bLength. Then host uses >>> bLength to figure how big is your configuration and subsequently fetches >>> the entire thing. >>> >> >> I agree that in normal operation I am not allowed to change the descriptors >> on the fly, and as to why the configuration descriptor is requested twice. >> >> However, this is the exact point of fuzzing, looking for issues with >> descriptor >> parsing and ToC/ToU issues related to the assumptions made based on the >> first descriptor (e.g. first 9 bytes of the configuration descriptor). > > That's an assumption mandated by the spec, though. I wouldn't be > surprised if some implementations fail this. Have you found any bug so far? > >>> Does a patch to switch the gadgetfs module to "delegate all" sounds >>> reasonable? >>> If so - what's the preferred way to do it? I have a few options in mind: >> >> Why do you need to delegate Get-Descriptor? The contents of the >> response are entirely dictated by the descriptors provided by the user >> program in the first place. >> >> Set-Configuration _is_ delegated to the user program, although the >> program is not allowed to fail the request. Is that what you want to >> do? >> >>> - module parameter >>> - write some command to the ep0 file >>> - send an ioctl to the ep0 file >>> >>> Any other suggestion? >> >> I suspect this sort of thing would not be accepted. If Felipe agrees, >> you might as well just keep your changes out-of-tree. > > This will just open up a can of worms, I'm afraid. What we have today > can even pass all USBCV tests, we're not breaking that, sorry. > I get your point, what I propose is not to change the default behavior of gadgetfs, but allow it to enter to a special mode by the user. I am aware of the issues that it might raise, and understand your concerns. However, I am asking about modifications in a specific, contained context. I would prefer to have it in the mainline kernel, but if you don't think it fits - I will keep those changes as an out-of-tree module. >>> >>> you're gonna have a really hard time getting anything in mainline >>> without explaining your goal. All you said is: "I wanna do fuzzying", >>> but fuzzying of what exactly? Why do you need to fuzz during >>> enumeration? This makes no sense. Gadgets are _not_ allowed to change >>> their descriptors and kernel doesn't allow userspace to do that. If you >>> wanna change your descriptor, then you _must_ disconnect from the host >>> and write brand new descriptors during gadgetfs initialization. >>> >> >> Sorry if I wasn't clear enough. We maintain a tool called Umap2, its goal is >> to perform security assessment of USB hosts. It does so in multiple ways, >> and one of them is fuzzing the USB host by sending invalid/unexpected >> packets over USB, including packets in the enumeration phase. There could >> be multiple issues with USB host stack during enumeration, and the fuzzing >> umap2 performs target those issues. > > have you found any bugs yet? > >> However, this kind of operation requires a very low level control over the >> traffic, and until now it was done using Facedancer, which is a designated >> HW. gadgetfs looked to me like the USB equivalent for "raw socket" as a >> USB device, so I thought we could use it to enable umap2 on beaglebone >> black and similar boards that run Linux instead of Facedancer. >> >> I hope this is clearer. If you think that there is some other kernel module >> that is better suited to this task, I would be happy to hear about it. > > The kernel is not exactly meant for pentesting USB host stacks :-) > > Here's what we can do, for now keep an out-of-tree patch. If/when you > find actual bugs, then we can reconsider adding this support if, and > only if, it's really difficult to enable (for example, it should depend > on EXPERT or something along those lines). We don't want this to ever > leak to production systems, so we need to make it really annoying to get > enabled. > > Anyway, first things first, let us know if/when you trigger any bugs > with this. > > -- > balbi Many USB host implementations, i
Re: How can I tell who created my usb0 network device?
Hello balbi ,
Thank you for your reply.
Yes, my system is an Edison board. It is embedded in a larger system
and is hardwired to a hub which is hardwired to another (custom)
embedded board based on an Atmel SAMA5 device. I had been trying (and
finally succeeded) to convince the two boards to communicate with each
other via ethernet-over-usb, and was getting confused by my lack of
knowledge of vocabulary terms such as CDC, EEM, NCM, RNDIS, etc...
Yes, I know that the Google and, in a lot of cases, the KConfig files
can define all of these terms for me, but none of that helped explain
why, when I thought I had configured both ends equivalently, they
still wouldn't talk to each other. It was only very late in the game
where I realized that the kernel on the Edison board was creating a
usb0 and a usb1 device and that made me wonder how one got associated
with the working connection and one did not.
Your explanation of the architecture on the Edison board and the
operation of the DWC3 device is much appreciated, and provides a much
more palatable explanation of the use of the "Gadget only mode"
selection in my Edison kernel than the explanation I invented. Thank
you very much.
I remain confused by the fact that the Edison does not switch to
host-mode until/unless I load the g_multi module. ("lsusb" won't even
work until I load that module.) I expect that when I load that
module, it kicks off enough other things that realize that the Edison
is plugged into a hub and it should switch over to "host-only XHCI"
and therefore things start to work. Perhaps, based on your
explanation, I should just disable the DWC3 driver completely and that
would enable the XHCI driver to work. I'll give that a try.
Thank you again.
--wpd
--
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: Gadgetfs - adding support for delegation of setup requests
On Tue, Aug 16, 2016 at 03:20:41PM +0300, Binyamin Sharet wrote: > Many USB host implementations, including at least older versions of Linux, We can't go back in time and fix code, sorry :) > have bugs in the enumeration phase. While I cannot pinpoint a ToC/ToU > vulnerability in the configuration descriptor at the moment, I found more than > a couple of issues with configuration descriptor parsing. I will post them > here > soon, hopefully today. Great! > However, just over the last year multiple USB related CVEs in the Linux kernel > were published (not by me). Yes, we know this well :) Most of these were found using some small embedded systems (like a teensy), which is pretty simple to use, but if we could get this into the gadget interface, and use the virtual gadget controller, we can automate tests to ensure that we have fixed problems, and that when we do, they don't come back by adding them to our regression tests.) > Also, while there might not be a specific ToC/ToU bug in configuration > descriptor parsing in Linux at the moment, there might still be in the > future, or in a different operating system, or in a user application > that queries those descriptor. My goal is to test all those cases, > not just the current Linux kernel. A good goal, I like it :) 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] cdc-wdm: add terminating newline
Debug messages should be properly terminated.
Signed-off-by: Oliver Neukum
---
drivers/usb/class/cdc-wdm.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/usb/class/cdc-wdm.c b/drivers/usb/class/cdc-wdm.c
index bf4bb58..0a63695 100644
--- a/drivers/usb/class/cdc-wdm.c
+++ b/drivers/usb/class/cdc-wdm.c
@@ -171,15 +171,15 @@ static void wdm_in_callback(struct urb *urb)
switch (status) {
case -ENOENT:
dev_dbg(&desc->intf->dev,
- "nonzero urb status received: -ENOENT");
+ "nonzero urb status received: -ENOENT\n");
goto skip_error;
case -ECONNRESET:
dev_dbg(&desc->intf->dev,
- "nonzero urb status received: -ECONNRESET");
+ "nonzero urb status received: -ECONNRESET\n");
goto skip_error;
case -ESHUTDOWN:
dev_dbg(&desc->intf->dev,
- "nonzero urb status received: -ESHUTDOWN");
+ "nonzero urb status received: -ESHUTDOWN\n");
goto skip_error;
case -EPIPE:
dev_dbg(&desc->intf->dev,
@@ -284,18 +284,18 @@ static void wdm_int_callback(struct urb *urb)
switch (dr->bNotificationType) {
case USB_CDC_NOTIFY_RESPONSE_AVAILABLE:
dev_dbg(&desc->intf->dev,
- "NOTIFY_RESPONSE_AVAILABLE received: index %d len %d",
+ "NOTIFY_RESPONSE_AVAILABLE received: index %d len %d\n",
le16_to_cpu(dr->wIndex), le16_to_cpu(dr->wLength));
break;
case USB_CDC_NOTIFY_NETWORK_CONNECTION:
dev_dbg(&desc->intf->dev,
- "NOTIFY_NETWORK_CONNECTION %s network",
+ "NOTIFY_NETWORK_CONNECTION %s network\n",
dr->wValue ? "connected to" : "disconnected from");
goto exit;
case USB_CDC_NOTIFY_SPEED_CHANGE:
- dev_dbg(&desc->intf->dev, "SPEED_CHANGE received (len %u)",
+ dev_dbg(&desc->intf->dev, "SPEED_CHANGE received (len %u)\n",
urb->actual_length);
goto exit;
default:
@@ -314,7 +314,7 @@ static void wdm_int_callback(struct urb *urb)
&& !test_bit(WDM_DISCONNECTING, &desc->flags)
&& !test_bit(WDM_SUSPENDING, &desc->flags)) {
rv = usb_submit_urb(desc->response, GFP_ATOMIC);
- dev_dbg(&desc->intf->dev, "submit response URB %d", rv);
+ dev_dbg(&desc->intf->dev, "submit response URB %d\n", rv);
}
spin_unlock(&desc->iuspin);
if (rv < 0) {
@@ -456,7 +456,7 @@ static ssize_t wdm_write
rv = usb_translate_errors(rv);
goto out_free_mem_pm;
} else {
- dev_dbg(&desc->intf->dev, "Tx URB has been submitted index=%d",
+ dev_dbg(&desc->intf->dev, "Tx URB has been submitted
index=%d\n",
le16_to_cpu(req->wIndex));
}
@@ -573,7 +573,7 @@ retry:
}
if (!desc->reslength) { /* zero length read */
- dev_dbg(&desc->intf->dev, "zero length - clearing
WDM_READ");
+ dev_dbg(&desc->intf->dev, "zero length - clearing
WDM_READ\n");
clear_bit(WDM_READ, &desc->flags);
rv = service_outstanding_interrupt(desc);
spin_unlock_irq(&desc->iuspin);
@@ -723,7 +723,7 @@ static int wdm_release(struct inode *inode, struct file
*file)
if (!desc->count) {
if (!test_bit(WDM_DISCONNECTING, &desc->flags)) {
- dev_dbg(&desc->intf->dev, "wdm_release: cleanup");
+ dev_dbg(&desc->intf->dev, "wdm_release: cleanup\n");
kill_urbs(desc);
spin_lock_irq(&desc->iuspin);
desc->resp_count = 0;
--
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
[Umap2][5/11][22b8:2d93] NULL pointer dereference
Kernel version: raspberrypi 4.4.6-v7+ #871 Driver source file: drivers/usb/class/cdc-acm.c Umap2 command line: umap2vsscan -P -s 22b8:2d93 After connecting such a device, NULL pointer dereference in the kernel and USB stops responding. Binyamin Sharet Cisco, STARE-C << Attached: 22b8_2d93_dmesg.log >> [ 86.923158] usb 1-1.5: new high-speed USB device number 9 using dwc_otg [ 87.037425] usb 1-1.5: New USB device found, idVendor=0cf2, idProduct=6230 [ 87.037452] usb 1-1.5: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 87.037469] usb 1-1.5: Product: UMAP2. PID:0x6230 [ 87.037484] usb 1-1.5: Manufacturer: UMAP2. VID:0x0cf2 [ 87.037499] usb 1-1.5: SerialNumber: 123456 [ 89.501681] usb 1-1.5: USB disconnect, device number 9 [ 95.113212] usb 1-1.5: new high-speed USB device number 10 using dwc_otg [ 95.228033] usb 1-1.5: New USB device found, idVendor=22b8, idProduct=2d93 [ 95.228061] usb 1-1.5: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 95.228078] usb 1-1.5: Product: UMAP2. PID:0x2d93 [ 95.228093] usb 1-1.5: Manufacturer: UMAP2. VID:0x22b8 [ 95.228108] usb 1-1.5: SerialNumber: 123456 [ 96.320953] Unable to handle kernel NULL pointer dereference at virtual address 0004 [ 96.329120] pgd = af938000 [ 96.331833] [0004] *pgd= [ 96.32095[ 96.335504] Internal error: Oops: 5 [#1] SMP ARM 3] Unable to handle kernel NULL pointer dereference at virtual address 0004 [ 96.329120] pgd = af938000 [ 96.331833] [0004] *pgd= [ 96.335504] Internal error: Oops: 5 [#1] SMP ARM [ 96.366274] Modules linked in: cdc_acm(+) gspca_vc032x gspca_vicam gspca_sonixj gspca_ov534_9 gspca_main v4l2_common videodev media bnep bluetooth cfg80211 rfkill snd_bcm2835 snd_pcm snd_timer snd bcm2835_gpiomem bcm2835_wdt uio_pdrv_genirq uio i2c_dev fuse [ 96.389200] CPU: 2 PID: 794 Comm: systemd-udevd Not tainted 4.4.6-v7+ #871 [ 96.396063] Hardware name: BCM2709 [ 96.399461] task: b8056d40 ti: af936000 task.ti: af936000 [ 96.404888] PC is at acm_probe+0x17c/0xd98 [cdc_acm] [ 96.409846] LR is at 0x1 [ 96.412379] pc : [<7f20be28>]lr : [<0001>]psr: 6013 [ 96.412379] sp : af937c30 ip : af937c30 fp : af937cac [ 96.423839] r10: b5fd8600 r9 : r8 : b5fd8600 [ 96.429056] r7 : 7f20e6dc r6 : b8f4a000 r5 : r4 : b8f4a000 [ 96.435573] r3 : 0010 r2 : b5fd9c00 r1 : r0 : b5fd8600 [ 96.442092] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user [ 96.449217] Control: 10c5387d Table: 2f93806a DAC: 0055 [ 96.454953] Process systemd-udevd (pid: 794, stack limit = 0xaf936210) [ 96.461468] Stack: (0xaf937c30 to 0xaf938000) [ 96.465816] 7c20: af89aeb0 801c97f4 8001 af89aeb0 [ 96.473980] 7c40: af937c64 801cc13c 801c97f4 af90a370 af90a2d0 af89aeb0 af937c84 af90a2d0 [ 96.482143] 7c60: af90a370 b8f4a068 af937c94 b5fd8600 b8f4a000 0001 0010 [ 96.490306] 7c80: b5fd8600 b5fd8620 b8f4a068 b8f4a000 7f20e6dc b5fd8600 7f20db74 [ 96.498470] 7ca0: af937cdc af937cb0 8040af88 7f20bcb8 8040aea0 8099d880 b5fd8620 [ 96.506633] 7cc0: 7f20e6dc 0010 7f20e740 af937d04 af937ce0 803a5e20 8040aeac [ 96.514796] 7ce0: 0007 b5fd8620 7f20e6dc b5fd8654 7f20e560 af937d24 af937d08 [ 96.522959] 7d00: 803a5fac 803a5c64 b958a45c 7f20e6dc 803a5f04 af937d4c af937d28 [ 96.531122] 7d20: 803a3fec 803a5f10 b958a45c b5f79fb4 b958a470 7f20e6dc b5e76d80 808ec0b4 [ 96.539285] 7d40: af937d5c af937d50 803a58e8 803a3f7c af937d84 af937d60 803a552c 803a58c8 [ 96.547448] 7d60: 7f20e560 af937d70 7f20e6dc 808ec0b4 7f20e6dc af937d9c af937d88 [ 96.555611] 7d80: 803a66e8 803a5384 7f20e6a8 af937dc4 af937da0 8040a8f4 803a666c [ 96.563774] 7da0: 7f20e940 0cbd 000c 0001 47caea1c af937de4 af937dc8 [ 96.571937] 7dc0: 7f2100e0 8040a880 808a2398 808a2398 b8351700 7f21 af937e64 af937de8 [ 96.580100] 7de0: 80009764 7f21000c 3a72e000 af937e3c af937e00 80105288 3ac9 [ 96.588263] 7e00: 801394d8 b5fd4ac0 3a72e000 0001 47caea1c 80147e40 af937e64 af937e28 [ 96.596426] 7e20: 80147e40 805e93d4 0001 801394d8 000b 3ac9 bc11 7f20e740 [ 96.604589] 7e40: 0001 b83516c0 7f20e740 0001 47caea1c b8351608 af937e8c af937e68 [ 96.612753] 7e60: 800fccc8 800096d0 af937e8c af937e78 801395d4 af937f44 0001 b8351600 [ 96.620916] 7e80: af937f3c af937e90 8009ec68 800fcc60 7f20e74c 7fff 7f20e740 8009c34c [ 96.629079] 7ea0: 015e 7f20e74c 7f20e74c 7f20e960 7f20e924 7f20e858 7f20e788 [ 96.637242] 7ec0: bc11 a230 0004169a 0b32 [ 96.645404] 7ee0: [ 96.653567] 7f00: 0058 0007 76cd0004 [ 96.661730] 7f20: 017b 8000fd08 af936000
[Umap2][4/11][0557:2002] NULL pointer dereference
Kernel version: raspberrypi 4.4.6-v7+ #871 Driver source file: drivers/net/usb/kaweth.c Umap2 command line: umap2vsscan -P -s 0557:2002 After connecting such a device, NULL pointer dereference in the kernel and USB stops responding. This issue was reproduced with other VID/PIDs that use this driver. Binyamin Sharet Cisco, STARE-C << Attached: 0557_2002_dmesg.log >> [ 266.644327] usb 1-1.5: new high-speed USB device number 35 using dwc_otg [ 266.758503] usb 1-1.5: New USB device found, idVendor=0557, idProduct=2002 [ 266.758530] usb 1-1.5: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 266.758548] usb 1-1.5: Product: UMAP2. PID:0x2002 [ 266.758564] usb 1-1.5: Manufacturer: UMAP2. VID:0x0557 [ 266.758579] usb 1-1.5: SerialNumber: 123456 [ 267.866048] Unable to handle kernel NULL pointer dereference at virtual address 0070 [ 267.874134] pgd = afa2 [ 267.876926] [0070] *pgd= [ 267.865838] kaweth 1-1.5:1.0: Downloading firmware... [ 267.865994] usb 1-1.5: Direct firmware load for kaweth/new_code.bin failed with error -2 [ 267.866048] Unable to handle kernel NULL pointer dereference at virtual address 0070 [ 267.874134] pgd = afa2 [ 267.876926] [0070] *pgd= [ 267.917546] Internal error: Oops: 5 [#1] SMP ARM [ 267.922166] Modules linked in: kaweth(+) ch341 ath3k btusb btrtl btintel gspca_stv0680 gspca_sonixb hso gspca_pac7302 ath6kl_usb ath6kl_core ttusbir rc_core stk1160 snd_ac97_codec ac97_bus zd1201 gl620a bpa10x hci_uart btbcm gspca_se401 joydev xpad ff_memless gspca_spca561 evdev pwc videobuf2_vmalloc[ 267.947756] usb 1-1.5: USB disconnect, device number 35 [ 267.953980] videobuf2_memops videobuf2_v4l2 videobuf2_core r8188eu(C) gspca_stk1135 gspca_finepix microtek usbtest cp210x usbserial gspca_ov519 gspca_main v4l2_common videodev media dm9601 bnep bluetooth cfg80211 rfkill snd_bcm2835 snd_pcm snd_timer bcm2835_wdt bcm2835_gpiomem snd uio_pdrv_genirq uio i2c_dev fuse [ 267.982162] CPU: 2 PID: 1302 Comm: systemd-udevd Tainted: GWC 4.4.6-v7+ #871 [ 267.990324] Hardware name: BCM2709 [ 267.993721] task: afa56d40 ti: afafe000 task.ti: afafe000 [ 267.999123] PC is at __dev_printk+0x28/0x98 [ 268.003303] LR is at dev_err+0x48/0x50 [ 268.007050] pc : [<803a2390>]lr : [<803a257c>]psr: 2013 [ 268.007050] sp : afaffbe0 ip : 80717928 fp : afaffc04 [ 268.018510] r10: 808df344 r9 : r8 : 0002 [ 268.023723] r7 : 0064 r6 : fffe r5 : afaffc10 r4 : b5fd6440 [ 268.030235] r3 : afaffc0c r2 : afaffc10 r1 : 0020 r0 : 80717928 [ 268.036749] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user [ 268.043868] Control: 10c5387d Table: 2fa2006a DAC: 0055 [ 268.049601] Process systemd-udevd (pid: 1302, stack limit = 0xafafe210) [ 268.056200] Stack: (0xafaffbe0 to 0xafb0) [ 268.060551] fbe0: afaffc4c 0001 0040 803ad7c8 b5fd6440 b5fd6440 afaffc28 afaffc08 [ 268.068715] fc00: 803a257c 803a2374 afaffc34 afaffc30 7f3daa84 afaffc0c 0002 afaffc74 [ 268.076879] fc20: afaffc38 7f3d9b58 803a2544 7f3daa84 0002 afaffc68 b5fd6000 [ 268.085042] fc40: b5fd6440 b5db9220 b5db9200 b5fd6000 b5fd6440 b5db9220 [ 268.093205] fc60: b5db9200 b7962c68 afaffcbc afaffc78 7f3d9fd4 7f3d9a88 afaffca4 afaffc88 [ 268.101368] fc80: 8040ad70 8040ac7c 0557 b5db9200 b5db9220 b7962c68 b7962c00 [ 268.109531] fca0: 7f3dae64 b5db9200 7f3daf0c afaffcec afaffcc0 8040af88 7f3d9b98 [ 268.117695] fcc0: 8040aea0 8099d880 b5db9220 7f3dae64 0037 7f3db240 [ 268.125858] fce0: afaffd14 afaffcf0 803a5e20 8040aeac 0007 b5db9220 7f3dae64 b5db9254 [ 268.134021] fd00: 7f3dadd0 afaffd34 afaffd18 803a5fac 803a5c64 b958a45c [ 268.142185] fd20: 7f3dae64 803a5f04 afaffd5c afaffd38 803a3fec 803a5f10 b958a45c b5e0ff34 [ 268.150348] fd40: b958a470 7f3dae64 b5f1fe80 808ec0b4 afaffd6c afaffd60 803a58e8 803a3f7c [ 268.158512] fd60: afaffd94 afaffd70 803a552c 803a58c8 7f3da920 afaffd80 7f3dae64 [ 268.166675] fd80: 808ec0b4 7f3dae64 afaffdac afaffd98 803a66e8 803a5384 7f3dae30 [ 268.174839] fda0: afaffdd4 afaffdb0 8040a8f4 803a666c 808a2398 808a2398 afad5ac0 7f3dd000 [ 268.183002] fdc0: 0001 5052a49c afaffde4 afaffdd8 7f3dd028 8040a880 afaffe64 afaffde8 [ 268.191165] fde0: 80009764 7f3dd00c 3a72e000 afaffe3c afaffe00 80105288 00011e0c [ 268.199329] fe00: 801394d8 af9864c0 3a72e000 0001 5052a49c 80147e40 afaffe64 afaffe28 [ 268.207492] fe20: 80147e40 805e93d4 0001 801394d8 0007 00011e0c bc351000 7f3db240 [ 268.215655] fe40: 0001 afad5d40 7f3db240 0001 5052a49c afad5b88 afaffe8c afaffe68 [ 268.223818] fe60: 800fccc8 800096d0 afaffe8c afaffe78 801395d4 afafff44 0001 afad5b80 [ 268.231982] fe80: afafff3c afaffe90 8009ec68 800fcc60 7f3db24c 7fff 7f3db240 8009c34c [ 268.240146] fea0: 00e9 7f3db24c 7f3db24c 7f3db440 7f3db424 7f3db358 7f3d
Potential vulnerabilities in USB host stack/drivers
Hi, We are using Umap2 to scan USB hosts for vendor-specific device support. e.g. whether appropriate drivers are loaded when a device with a specific VID/PID is inserted. In our configuration, we connect multiple times to the host, each time providing different VID/PID in the device descriptor, and then we provide a single configuration with a single interface that has multiple (10) endpoints of different types. Umap2 can be downloaded from https://github.com/nccgroup/umap2, and requires either a Facedancer board or a beaglebone black with a modified gadgetfs module (source and instructions in umap2 repository) to be used. During this scan we have found multiple issues in the kernel. Some issues cause the the USB stack to hang, while others cause an oops. Some of the issues seem similar and might originate from the same source, however, due to my lack of knowledge in the Linux USB subsystem, I did not perform an in-depth analysis of the root causes. In total, there are 11 issues: 2 hangs, 8 NULL pointer dereference and 1 oops caused by kernel unable to handle paging address. To keep some order, I will send a separate mail for each issue, titled '[Umap2][x/11][$VID:$PID] $result'. -- Binyamin -- 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
[Umap2][1/11][0aa8:8001] USB stack hang
Kernel version: raspberrypi 4.4.6-v7+ #871 Kernel version: 4.4.0-24-generic #43-Ubuntu SMP Driver source file: drivers/staging/media/lirc/lirc_imon.c Umap2 command line: umap2vsscan -P -s 0aa8:8001 After connecting such a device, the host usb stack became unresponsive. Please see attached dmesg log. Binyamin Sharet Cisco, STARE-C [ 1206.083207] usb 3-2: new high-speed USB device number 2 using xhci_hcd [ 1206.504969] usb 3-2: New USB device found, idVendor=0aa8, idProduct=8001 [ 1206.504978] usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 1206.504982] usb 3-2: Product: UMAP2. PID:0x8001 [ 1206.504985] usb 3-2: Manufacturer: UMAP2. VID:0x0aa8 [ 1206.504988] usb 3-2: SerialNumber: 123456 [ 1207.732370] lirc_dev: IR Remote Control driver registered, major 244 [ 1207.735697] lirc_imon: module is from the staging directory, the quality is unknown, you have been warned. [ 1207.736244] lirc_imon 3-2:1.0: lirc_dev: driver lirc_imon registered at minor = 0 [ 1207.736251] lirc_imon 3-2:1.0: Registered iMON driver (lirc minor: 0) [ 1207.736268] lirc_imon 3-2:1.0: iMON device (0aa8:8001, intf0) on usb<3:2> initialized [ 1207.736320] usbcore: registered new interface driver lirc_imon [ 1210.702280] lirc_imon 3-2:1.0: imon usb_rx_callback: status(-71): ignored [ 1210.702356] usb 3-2: USB disconnect, device number 2 [ 1210.702503] lirc_imon 3-2:1.0: imon usb_rx_callback: status(-71): ignored [ 1440.146097] INFO: task kworker/1:0:14 blocked for more than 120 seconds. [ 1440.146107] Tainted: G C OE 4.4.0-24-generic #43-Ubuntu [ 1440.146110] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 1440.146113] kworker/1:0 D 8802149bfa68 014 2 0x [ 1440.146126] Workqueue: usb_hub_wq hub_event [ 1440.146129] 8802149bfa68 76b5ce45 8800c83fe040 8802149b1b80 [ 1440.146134] 8802149c 8800aaca261c 8802149b1b80 [ 1440.146137] 8800aaca2620 8802149bfa80 81821b15 8800aaca2618 [ 1440.146141] Call Trace: [ 1440.146152] [] schedule+0x35/0x80 [ 1440.146157] [] schedule_preempt_disabled+0xe/0x10 [ 1440.146162] [] __mutex_lock_slowpath+0xb9/0x130 [ 1440.146167] [] mutex_lock+0x1f/0x30 [ 1440.146177] [] imon_disconnect+0x3d/0x110 [lirc_imon] [ 1440.146183] [] usb_unbind_interface+0x83/0x260 [ 1440.146190] [] __device_release_driver+0xa1/0x150 [ 1440.146194] [] device_release_driver+0x23/0x30 [ 1440.146197] [] bus_remove_device+0x101/0x170 [ 1440.146202] [] device_del+0x139/0x260 [ 1440.146207] [] ? usb_remove_ep_devs+0x1f/0x30 [ 1440.146212] [] usb_disable_device+0x89/0x270 [ 1440.146216] [] usb_disconnect+0x92/0x280 [ 1440.146220] [] hub_port_connect+0x82/0x9c0 [ 1440.146223] [] hub_event+0x6d1/0xb10 [ 1440.146229] [] ? put_prev_entity+0x35/0x7d0 [ 1440.146235] [] process_one_work+0x165/0x480 [ 1440.146240] [] worker_thread+0x4b/0x4c0 [ 1440.146244] [] ? process_one_work+0x480/0x480 [ 1440.146248] [] kthread+0xd8/0xf0 [ 1440.146252] [] ? kthread_create_on_node+0x1e0/0x1e0 [ 1440.146256] [] ret_from_fork+0x3f/0x70 [ 1440.146260] [] ? kthread_create_on_node+0x1e0/0x1e0 [ 1440.146329] INFO: task colord-sane:4439 blocked for more than 120 seconds. [ 1440.146332] Tainted: G C OE 4.4.0-24-generic #43-Ubuntu [ 1440.146334] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 1440.146336] colord-sane D 8801d8123d78 0 4439 1163 0x [ 1440.146341] 8801d8123d78 81e11500 8800c83fe040 [ 1440.146345] 8801d8124000 8802107b68fc 8800c83fe040 [ 1440.146349] 8802107b6900 8801d8123d90 81821b15 8802107b68f8 [ 1440.146353] Call Trace: [ 1440.146358] [] schedule+0x35/0x80 [ 1440.146362] [] schedule_preempt_disabled+0xe/0x10 [ 1440.146367] [] __mutex_lock_slowpath+0xb9/0x130 [ 1440.146371] [] mutex_lock+0x1f/0x30 [ 1440.146375] [] read_descriptors+0x37/0x100 [ 1440.146382] [] sysfs_kf_bin_read+0x4a/0x70 [ 1440.146387] [] kernfs_fop_read+0xab/0x160 [ 1440.146393] [] __vfs_read+0x18/0x40 [ 1440.146398] [] vfs_read+0x86/0x130 [ 1440.146402] [] SyS_read+0x55/0xc0 [ 1440.146409] [] entry_SYSCALL_64_fastpath+0x16/0x71
[Umap2][3/11][0471:0602] NULL pointer dereference
Kernel version: raspberrypi 4.4.6-v7+ #871 Driver source file: drivers/input/misc/ati_remote2.c Umap2 command line: umap2vsscan -P -s 0471:0602 After connecting such a device, NULL pointer dereference in the kernel and USB stops responding. Binyamin Sharet Cisco, STARE-C << Attached: 0471_0602_dmesg.log >> [ 508.866035] usb 1-1.5: new high-speed USB device number 48 using dwc_otg [ 508.980538] usb 1-1.5: New USB device found, idVendor=0471, idProduct=0602 [ 508.980565] usb 1-1.5: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 508.980582] usb 1-1.5: Product: UMAP2. PID:0x0602 [ 508.980598] usb 1-1.5: Manufacturer: UMAP2. VID:0x0471 [ 508.980614] usb 1-1.5: SerialNumber: 123456 [ 510.072098] Unable to handle kernel NULL pointer dereference at virtual address 0070 [ 510.080281] pgd = af588000 [ 510.082994] [0070] *pgd= [ 510.07209[ 510.086655] Internal error: Oops: 5 [#1] SMP ARM ] Unable to handle kernel NULL pointer dereference at virtual address 0070 [ 510.080281] pgd = af588000 [ 510.082994] [0070] *pgd= [ 510.086655] Internal error: Oops: 5 [#1] SMP ARM Message from syslogd@raspberrypi at Jun 20 09:25:26 ... kernel:[ 510.086655] Internal error: Oops: 5 [#1] SMP ARM [ 510.128098] Modules linked in: ati_remote2(+) gspca_jeilinj cxacru smsdvb smsusb crc_ccitt rio500 gspca_t613 gspca_main[ 510.12809 v4l2_common8] Modul videodeves linked in media[1m: ati_remote2( sg+) gspca_jeilinj bnep cxacru smsdvb sm bluetoothsusb smsmdtv gspc cfg80211a_benq tm6000 vid rfkilleobuf_vmalloc vid snd_bcm2835eobuf_core go7007 bcm2835_gpiomem_loader cypress_f snd_pcmirmware gspca_sun bcm2835_wdtplus gspca_nw80x snd_timergspca_jl2005bcd c sndatc ark3116 at76c uio_pdrv_genirq50x_usb gspca_mr9 uio7310a pegasus gsp i2c_devca_spca505 speedt fusech usbatm atm usblp i2400m_usb i240 0m wimax gspca_m[ 510.128392] CPU: 2 PID: 1272 Comm: systemd-udevd Tainted: G C 4.4.6-v7+ #871 5602 gspca_gl860[ 510.128396] Hardware name: BCM2709 joydev usbtouch[ 510.128403] task: b8f678c0 ti: a9de4000 task.ti: a9de4000 screen gspca_kin[ 510.128424] PC is at usb_driver_claim_interface+0x18/0x120 ect em28xx usb_d[ 510.128456] LR is at ati_remote2_probe+0x88/0x4a8 [ati_remote2] ebug usbserial g[ 510.128466] pc : [<8040a400>]lr : [<7f514880>]psr: 6013 [ 510.128466] sp : a9de5c58 ip : a9de5c78 fp : a9de5c74 spca_mars ir_mce[ 510.128471] r10: r9 : a900 r8 : a900 _kbd_decoder ir_[ 510.128478] r7 : af53e468 r6 : af53e400 r5 : b8ef43c8 r4 : xmp_decoder ir_s[ 510.128485] r3 : 0001 r2 : b5a54400 r1 : r0 : 7f515914 harp_decoder ir_[ 510.128494] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user lirc_codec lirc_[ 510.128501] Control: 10c5387d Table: 2f58806a DAC: 0055 dev ir_sanyo_dec[ 510.128508] Process systemd-udevd (pid: 1272, stack limit = 0xa9de4210) oder ir_jvc_deco[ 510.128515] Stack: (0xa9de5c58 to 0xa9de6000) der ir_sony_deco[ 510.128524] 5c40: b5a54400 b8ef43c8 der ir_rc6_decod[ 510.128537] 5c60: af53e400 af53e468 a9de5cbc a9de5c78 7f514880 8040a3f4 a9de5ca4 a9de5c88 er ir_rc5_decode[ 510.128550] 5c80: 8040ad70 8040ac7c 0471 7f5159d8 a900 a920 af53e468 af53e400 r ir_nec_decoder[ 510.128563] 5ca0: 7f515948 a900 7f5159d8 a9de5cec a9de5cc0 8040af88 7f514804 evdev rc_hauppa[ 510.128577] 5cc0: 8040aea0 8099d880 a920 7f515948 004d 7f515a40 uge xc5000 au852[ 510.128590] 5ce0: a9de5d14 a9de5cf0 803a5e20 8040aeac 0007 a920 7f515948 a954 2_dig au8522_dec[ 510.128603] 5d00: 7f515848 a9de5d34 a9de5d18 803a5fac 803a5c64 b958a45c oder au8522_comm[ 510.128616] 5d20: 7f515948 803a5f04 a9de5d5c a9de5d38 803a3fec 803a5f10 b958a45c a9f27e34 on au0828 tveepr[ 510.128629] 5d40: b958a470 7f515948 a995af00 808ec0b4 a9de5d6c a9de5d60 803a58e8 803a3f7c om videobuf2_vma[ 510.128642] 5d60: a9de5d94 a9de5d70 803a552c 803a58c8 7f515848 a9de5d80 7f515948 lloc videobuf2_m[ 510.128656] 5d80: 808ec0b4 7f515948 a9de5dac a9de5d98 803a66e8 803a5384 7f515914 emops videobuf2_[ 510.128669] 5da0: a9de5dd4 a9de5db0 8040a8f4 803a666c 808a2398 808a2398 b5a3a500 7f518000 v4l2 videobuf2_c[ 510.128682] 5dc0: 0001 4a5c5c1c a9de5de4 a9de5dd8 7f518024 8040a880 a9de5e64 a9de5de8 ore dvb_core rc_[ 510.128695] 5de0: 80009764 7f51800c 3a72e000 a9de5e3c a9de5e00 80105288 6b2d core zd1211rw r8[ 510.128708] 5e00: 801394d8 a9ef6dc0 3a72e000 0001 4a5c5c1c 80147e40 a9de5e64 a9de5e28 712u(C) gspca_ko[ 510.128721] 5e20: 80147e40 805e93d4 0001 801394d8 0005 6b2d bc592000 7f515a40 nica p54usb p54c[ 510.128734] 5e40: 0001 b5a3a4c0 7f515a40 0001 4a5c5c1c b5a3a408 a9de5e8c a9de5e68 ommon mac80211[[ 510.128748] 5e60: 800fccc8 800096d0 a9de5e8c a9de5e78 801395d4 a9de5f44 0001 b5a3a400 0m [ 510.[ 510.128761] 5e80: a9de5f3c a9de5e9
[Umap2][7/11][160a:3184] NULL pointer dereference
Kernel version: raspberrypi 4.4.6-v7+ #871 Driver source file: drivers/staging/vt6656/main_usb.c Related file: drivers/staging/comedi/drivers/usbduxsigma.c Umap2 command line: umap2vsscan -P -s 160a:3184 After connecting such a device, NULL pointer dereference in the kernel. You may need to connect another device or two after this one to trigger the oops. Binyamin Sharet Cisco, STARE-C << Attached: 160a_3184_dmesg_1.log >> << Attached: 160a_3184_dmesg_2.log >> [ 291.754550] usb 1-1.4: new high-speed USB device number 17 using dwc_otg [ 291.869191] usb 1-1.4: New USB device found, idVendor=160a, idProduct=3184 [ 291.869211] usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 291.869222] usb 1-1.4: Product: UMAP2. PID:0x3184 [ 291.869233] usb 1-1.4: Manufacturer: UMAP2. VID:0x160a [ 291.869243] usb 1-1.4: SerialNumber: 123456 [ 293.016056] vt6656_stage: module is from the staging directory, the quality is unknown, you have been warned. [ 293.018042] usb 1-1.4: VIA Networking Wireless LAN USB Driver Ver. mac80211 [ 293.018068] usb 1-1.4: Copyright (c) 2004 VIA Networking Technologies, Inc. [ 293.094648] usb 1-1.4: reset high-speed USB device number 17 using dwc_otg [ 293.204645] usb 1-1.4: Starting mac80211 [ 293.204928] usbcore: registered new interface driver vt6656 [ 293.210276] usb 1-1.4: Direct firmware load for vntwusb.fw failed with error -2 [ 293.210308] usb 1-1.4: firmware file vntwusb.fw request failed (-2) [ 293.210325] usb 1-1.4: failed to start [ 293.314884] usb 1-1.4: USB disconnect, device number 17 [ 296.624625] usb 1-1.4: new high-speed USB device number 18 using dwc_otg [ 296.743301] Unable to handle kernel NULL pointer dereference at virtual address 0002 [ 296.751396] pgd = 80004000 [ 296.754100] [0002] *pgd= [ 296.757686] Internal error: Oops: 17 [#1] SMP ARM [ 296.762383] Modules linked in: vt6656_stage(C) mac80211 r8188eu(C) bnep bluetooth cfg80211 rfkill bcm2835_gpiomem snd_bcm2835 bcm2835_wdt snd_pcm snd_timer snd uio_pdrv_genirq uio i2c_dev fuse [ 296.779626] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G C 4.4.6-v7+ #871 [ 296.787181] Hardware name: BCM2709 [ 296.790579] task: 808a2568 ti: 8089c000 task.ti: 8089c000 [ 296.795980] PC is at __kmalloc+0x90/0x238 [ 296.799986] LR is at __kmalloc+0x30/0x238 [ 296.803992] pc : [<80147b24>]lr : [<80147ac4>]psr: 2193 [ 296.803992] sp : 8089dc88 ip : 8089dc88 fp : 8089dcc4 [ 296.815452] r10: b8c9c000 r9 : af9c2a00 r8 : 8043ab50 [ 296.820669] r7 : 02088020 r6 : 000c r5 : b9401f00 r4 : 0002 [ 296.827187] r3 : r2 : 8089dc88 r1 : 8089c820 r0 : 3a714000 [ 296.833706] Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel [ 296.841091] Control: 10c5387d Table: 35c9c06a DAC: 0055 [ 296.846828] Process swapper/0 (pid: 0, stack limit = 0x8089c210) [ 296.852825] Stack: (0x8089dc88 to 0x8089e000) [ 296.857181] dc80: 8089dcbc 8089dc98 80431314 000149a7 805ecfa4 af9c2980 [ 296.865353] dca0: b5fa0680 f3980500 af9c2a00 af9c2a00 b8c9c000 8089dcd4 8089dcc8 [ 296.873524] dcc0: 8043ab50 80147aa0 8089dd04 8089dcd8 804307fc 8043ab38 af9c2980 [ 296.881695] dce0: b8c9a200 f3980500 b8c9c000 0002 af9c2a00 af9c2980 8089dd44 8089dd08 [ 296.889865] dd00: 804325e4 804307d8 0001 8089dd18 804328f0 8043a588 8089dd3c [ 296.898036] dd20: 0002 0002 b8c9c000 f3980500 b8c9a200 af9c2980 8089dd94 8089dd48 [ 296.906207] dd40: 804339f4 80432310 b8c9c000 b8c9c01c 8089dd9c 8089dd60 0001 f398050c [ 296.914378] dd60: 0023 0002 0001 b8c9c000 0208 [ 296.922549] dd80: f301080e 0002 8089ddb4 8089dd98 80433dc0 80433668 b8c9c000 b9651000 [ 296.930719] dda0: 808ec7d8 0001 8089dde4 8089ddb8 80434098 80433d18 80430564 b8c98900 [ 296.938890] ddc0: b9480f5c 003e 805f1e54 8089ddf4 8089dde8 [ 296.947061] dde0: 80430580 80433e0c 8089de04 8089ddf8 804038f4 80430570 8089de4c 8089de08 [ 296.955232] de00: 80071748 804038cc edeeb793 2193 80902f78 80902f94 b9480f00 8089c008 [ 296.963403] de20: 8089de3c b9480f00 b9480f5c 80903758 bafff740 [ 296.971573] de40: 8089de6c 8089de50 80071938 80071694 0002 b9480f00 b9480f10 [ 296.979744] de60: 8089de84 8089de70 80074d78 800718f0 8089faf0 8089de94 8089de88 [ 296.987915] de80: 80070cc4 80074cd4 8089deac 8089de98 80344ae4 80070c9c 80344aa8 808973ec [ 296.996086] dea0: 8089debc 8089deb0 80070cc4 80344ab4 8089dee4 8089dec0 80070fd0 80070c9c [ 297.004256] dec0: 8089df08 80010b38 6013 8089df3c 805f1e54 8089def4 8089dee8 [ 297.012422] dee0: 80010a74 80070f70 8089df04 8089def8 8000951c 80010a54 8089df64 8089df08 [ 297.020585] df00: 805ed3c4 80009470 bafa9348 8089c000 8089e5dc [ 297.028748] df20: 8089e500 8089e580 805f1e54 80903758 bafff740 8089df64 8089f4f8 8089df58 [ 297.0369
Re: [PATCH v2 4/7] phy-sun4i-usb: Add support for phy_set_mode
Hello.
On 08/15/2016 10:21 PM, Hans de Goede wrote:
Together with some musb sunxi glue changes this allows run-time dr_mode
switching support via the "mode" musb sysfs attribute.
Signed-off-by: Hans de Goede
---
drivers/phy/phy-sun4i-usb.c | 24
1 file changed, 24 insertions(+)
diff --git a/drivers/phy/phy-sun4i-usb.c b/drivers/phy/phy-sun4i-usb.c
index fb2d4f3..d369081 100644
--- a/drivers/phy/phy-sun4i-usb.c
+++ b/drivers/phy/phy-sun4i-usb.c
@@ -427,6 +427,29 @@ static int sun4i_usb_phy_power_off(struct phy *_phy)
return 0;
}
+static int sun4i_usb_phy_set_mode(struct phy *_phy, enum phy_mode mode)
+{
+ struct sun4i_usb_phy *phy = phy_get_drvdata(_phy);
+ struct sun4i_usb_phy_data *data = to_sun4i_usb_phy_data(phy);
+
+ if (phy->index != 0)
+ return -EINVAL;
+
+ switch (mode) {
+ case PHY_MODE_USB_HOST: data->dr_mode = USB_DR_MODE_HOST; break;
+ case PHY_MODE_USB_DEVICE: data->dr_mode = USB_DR_MODE_PERIPHERAL; break;
+ case PHY_MODE_USB_OTG:data->dr_mode = USB_DR_MODE_OTG; break;
+ default:
+ return -EINVAL;
+ }
+
+ dev_info(&_phy->dev, "Changing dr_mode to %d\n", (int)data->dr_mode);
+ data->force_session_end = true;
+ queue_delayed_work(system_wq, &data->detect, 0);
+
+ return 0;
+}
+
void sun4i_usb_phy_set_squelch_detect(struct phy *_phy, bool enabled)
{
struct sun4i_usb_phy *phy = phy_get_drvdata(_phy);
[...]
$ scripts/checkpatch.pl
~/patches/phy-sun4i-usb-Add-support-for-phy_set_mode.patch
ERROR: trailing statements should be on next line
#29: FILE: drivers/phy/phy-sun4i-usb.c:439:
+ case PHY_MODE_USB_HOST: data->dr_mode = USB_DR_MODE_HOST; break;
ERROR: trailing statements should be on next line
#30: FILE: drivers/phy/phy-sun4i-usb.c:440:
+ case PHY_MODE_USB_DEVICE: data->dr_mode = USB_DR_MODE_PERIPHERAL; break;
ERROR: trailing statements should be on next line
#31: FILE: drivers/phy/phy-sun4i-usb.c:441:
+ case PHY_MODE_USB_OTG:data->dr_mode = USB_DR_MODE_OTG; break;
total: 3 errors, 0 warnings, 36 lines checked
NOTE: For some of the reported defects, checkpatch may be able to
mechanically convert to the typical style using --fix or --fix-inplace.
/home/headless/patches/phy-sun4i-usb-Add-support-for-phy_set_mode.patch has
style problems, please review.
NOTE: If any of the errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.
MBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[Umap2][8/11][076d:0006] NULL pointer dereference
Kernel version: raspberrypi 4.4.6-v7+ #871 Driver source file: drivers/staging/vt6656/main_usb.c Umap2 command line: umap2vsscan -P -s 076d:0006 After connecting such a device, NULL pointer dereference in the kernel. Binyamin Sharet Cisco, STARE-C << Attached: 076d_0006_dmesg.log >> [ 4039.069359] usb 1-1.4: new high-speed USB device number 105 using dwc_otg [ 4039.183943] usb 1-1.4: New USB device found, idVendor=076d, idProduct=0006 [ 4039.183970] usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 4039.183987] usb 1-1.4: Product: UMAP2. PID:0x0006 [ 4039.184003] usb 1-1.4: Manufacturer: UMAP2. VID:0x076d [ 4039.184018] usb 1-1.4: SerialNumber: 123456 [ 4040.277845] Unable to handle kernel NULL pointer dereference at virtual address 0004 [ 4040.286041] pgd = afbc8000 [ 4040.288753] [0004] *pgd= [ 4040.292405] Internal error: Oops: 5 [#1] SMP ARM [ 4040.277[84040.297021] Modules linked in:5] Unable to handle kernel NULL pointer dereference at virtual address 0004 [ 4040.286041] pgd = afbc8000 [ 4040.288753] [0004] *pgd= [ 4040.292405] Internal error: Oops: 5 [#1] SMP ARM Message from syslogd@raspberrypi at Jun 27 13:24:16 ... kernel:[ 4040.292405] Internal error: Oops: 5 [#1] SMP ARM cdc_acm(+) usblp bfusb bpa10x hci_uart ath3k bcm203x ds2490[ 4040.336799] CPU: 1 PID: 19836 Comm: systemd-udevd Tainted: G C 4.4.6-v7+ #871 [ 4040.336803] Hardware name: BCM2709 [[3 24m0[4 04.0336814] task: af926780 ti: afba8000 task.ti: afba8000 0.297021] Modules linked in: cdc_acm(+) usblp bfusb bpa10x hci_uart ath3k bcm203x ds2490 wire cn adutux xpad ff_memless ldusb powermate evdev joydev usbtouchscreen usbled cypress_m8 pl2303 aircable usbserial prism2_usb(C) rt2800usb rt2800lib rt2x00usb rt2x00lib mac80211 crc_ccitt r8712u(C) btusb btrtl btintel btbcm bnep bluetooth cfg80211 rfkill snd_bcm2835 snd_pcm bcm2835_gpiomem snd_timer bcm2835_wdt snd uio_pdrv_genirq uio i2c_dev fuse [ 4040.336799] CPU: 1 PID: 19836 Comm: systemd-udevd Tainted: G C 4.4.6-v7+ #871 [ 4040.336803] Hardware name: BCM2709 [ 4040.336811] task: af926780 ti: afba8000 task.ti: afba8000 [ 4040.336860] PC is at acm_probe+0x17c/0xd98 [cdc_acm] [ 4040.336865] LR is at 0x1 [ 4040.336875] pc : [<7f39be28>]lr : [<0001>]psr: 6013 sp : afba9c30 ip : afba9c30 fp : afba9cac [ 4040.336880] r10: af873200 r9 : r8 : af873200 [ 4040.336887] r7 : 7f39e6dc r6 : afb7e800 r5 : r4 : afb7e800 [ 4040.336894] r3 : 0010 r2 : af872800 r1 : r0 : af873200 [ 4040.336903] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user [ 4040.336911] Control: 10c5387d Table: 2fbc806a DAC: 0055 [ 4040.336917] Process systemd-udevd (pid: 19836, stack limit = 0xafba8210) [ 4040.336924] Stack: (0xafba9c30 to 0xafbaa000) [ 4040.336935] 9c20: afb20280 801c97f4 8001 afb20280 [ 4040.336948] 9c40: afba9c64 801cc13c 801c97f4 af9c0370 af878f00 afb20280 afba9c84 af878f00 [ 4040.336962] 9c60: af9c0370 afb7e868 afba9c94 af873200 afb7e800 0001 0010 [ 4040.336975] 9c80: af873200 af873220 afb7e868 afb7e800 7f39e6dc af873200 7f39d994 [ 4040.336989] 9ca0: afba9cdc afba9cb0 8040af88 7f39bcb8 8040aea0 8099d880 af873220 [ 4040.337002] 9cc0: 7f39e6dc 04ca 7f39e740 afba9d04 afba9ce0 803a5e20 8040aeac [ 4040.337016] 9ce0: 0007 af873220 7f39e6dc af873254 7f39e560 afba9d24 afba9d08 [ 4040.337029] 9d00: 803a5fac 803a5c64 b958a45c 7f39e6dc 803a5f04 afba9d4c afba9d28 [ 4040.337042] 9d20: 803a3fec 803a5f10 b958a45c afbe7a34 b958a470 7f39e6dc afaf9480 808ec0b4 [ 4040.337055] 9d40: afba9d5c afba9d50 803a58e8 803a3f7c afba9d84 afba9d60 803a552c 803a58c8 [ 4040.337068] 9d60: 7f39e560 afba9d70 7f39e6dc 808ec0b4 7f39e6dc afba9d9c afba9d88 [ 4040.337082] 9d80: 803a66e8 803a5384 7f39e6a8 afba9dc4 afba9da0 8040a8f4 803a666c [ 4040.337094] 9da0: 7f39e940 0cbd 000c 0001 505335dc afba9de4 afba9dc8 [ 4040.337109] 9dc0: 7f3a00e0 8040a880 808a2398 808a2398 afb3b740 7f3a afba9e64 afba9de8 [ 4040.337122] 9de0: 80009764 7f3a000c 3a721000 afba9e3c afba9e00 80105288 00029f4c [ 4040.337135] 9e00: 801394d8 b7855b40 3a721000 0001 505335dc 80147e40 afba9e64 afba9e28 [ 4040.337148] 9e20: 80147e40 805e93d4 0001 801394d8 000b 00029f4c bc401000 7f39e740 [ 4040.337161] 9e40: 0001 afb3bcc0 7f39e740 0001 505335dc afacca48 afba9e8c afba9e68 [ 4040.337174] 9e60: 800fccc8 800096d0 afba9e8c afba9e78 801395d4 afba9f44 0001 afacca40 [ 4040.337187] 9e80: afba9f3c afba9e90 8009ec68 800fcc60 7f39e74c 7fff 7f39e740 8009c34c [ 4040.337200] 9ea0: 015e 7f39e74c 7f39e74c 7f39e960 7f39e924 7f39e858 7f39e788 [ 4040.337213] 9ec0: bc401000 a230 0004169a 0b32 [ 4040.337225] 9ee0: [ 4040.337238] 9f00: 000
[Umap2][2/11][10cf:5500] NULL pointer dereference
Kernel version: 4.4.0-24-generic #43-Ubuntu SMP Driver source file: drivers/staging/comedi/drivers/vmk80xx.c Umap2 command line: umap2vsscan -P -s 10cf:5500 After connecting such a device, there's oops due to NULL pointer dereference. Binyamin Sharet Cisco, STARE-C << Attached: 10cf_5500_dmesg.log >> [0.00] microcode: CPU0 microcode updated early to revision 0x1c, date = 2015-02-26 [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Initializing cgroup subsys cpuacct [0.00] Linux version 4.4.0-24-generic (buildd@lgw01-12) (gcc version 5.3.1 20160413 (Ubuntu 5.3.1-14ubuntu2.1) ) #43-Ubuntu SMP Wed Jun 8 19:27:37 UTC 2016 (Ubuntu 4.4.0-24.43-generic 4.4.10) [0.00] Command line: BOOT_IMAGE=/vmlinuz-4.4.0-24-generic root=/dev/mapper/ubuntu--vg-root ro quiet splash crashkernel=384M-:128M vt.handoff=7 [0.00] KERNEL supported cpus: [0.00] Intel GenuineIntel [0.00] AMD AuthenticAMD [0.00] Centaur CentaurHauls [0.00] x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256 [0.00] x86/fpu: Supporting XSAVE feature 0x01: 'x87 floating point registers' [0.00] x86/fpu: Supporting XSAVE feature 0x02: 'SSE registers' [0.00] x86/fpu: Supporting XSAVE feature 0x04: 'AVX registers' [0.00] x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 'standard' format. [0.00] x86/fpu: Using 'eager' FPU context switches. [0.00] e820: BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x0009d7ff] usable [0.00] BIOS-e820: [mem 0x0009d800-0x0009] reserved [0.00] BIOS-e820: [mem 0x000e-0x000f] reserved [0.00] BIOS-e820: [mem 0x0010-0x1fff] usable [0.00] BIOS-e820: [mem 0x2000-0x201f] reserved [0.00] BIOS-e820: [mem 0x2020-0x40003fff] usable [0.00] BIOS-e820: [mem 0x40004000-0x40004fff] reserved [0.00] BIOS-e820: [mem 0x40005000-0xcec30fff] usable [0.00] BIOS-e820: [mem 0xcec31000-0xdae9efff] reserved [0.00] BIOS-e820: [mem 0xdae9f000-0xdaf9efff] ACPI NVS [0.00] BIOS-e820: [mem 0xdaf9f000-0xdaffefff] ACPI data [0.00] BIOS-e820: [mem 0xdafff000-0xdf9f] reserved [0.00] BIOS-e820: [mem 0xf800-0xfbff] reserved [0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved [0.00] BIOS-e820: [mem 0xfed08000-0xfed08fff] reserved [0.00] BIOS-e820: [mem 0xfed1-0xfed19fff] reserved [0.00] BIOS-e820: [mem 0xfed1c000-0xfed1] reserved [0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved [0.00] BIOS-e820: [mem 0xffc0-0x] reserved [0.00] BIOS-e820: [mem 0x0001-0x00021e5f] usable [0.00] BIOS-e820: [mem 0x00021e60-0x00021e7f] reserved [0.00] NX (Execute Disable) protection: active [0.00] SMBIOS 2.7 present. [0.00] DMI: LENOVO 2333A11/2333A11, BIOS G2ET90WW (2.50 ) 12/20/2012 [0.00] e820: update [mem 0x-0x0fff] usable ==> reserved [0.00] e820: remove [mem 0x000a-0x000f] usable [0.00] e820: last_pfn = 0x21e600 max_arch_pfn = 0x4 [0.00] MTRR default type: uncachable [0.00] MTRR fixed ranges enabled: [0.00] 0-9 write-back [0.00] A-B uncachable [0.00] C-F write-protect [0.00] MTRR variable ranges enabled: [0.00] 0 base 0FFC0 mask FFFC0 write-protect [0.00] 1 base 0 mask F8000 write-back [0.00] 2 base 08000 mask FC000 write-back [0.00] 3 base 0C000 mask FE000 write-back [0.00] 4 base 0DC00 mask FFC00 uncachable [0.00] 5 base 0DB00 mask FFF00 uncachable [0.00] 6 base 1 mask F write-back [0.00] 7 base 2 mask FE000 write-back [0.00] 8 base 21F00 mask FFF00 uncachable [0.00] 9 base 21E80 mask FFF80 uncachable [0.00] x86/PAT: Configuration [0-7]: WB WC UC- UC WB WC UC- WT [0.00] e820: last_pfn = 0xcec31 max_arch_pfn = 0x4 [0.00] found SMP MP-table at [mem 0x000f0100-0x000f010f] mapped at [880f0100] [0.00] Scanning 1 areas for low memory corruption [0.00] Base memory trampoline at [88097000] 97000 size 24576 [0.00] BRK [0x021ff000, 0x021f] PGTABLE [0.00] BRK [0x0220, 0x02200fff] PGTABLE [0.00] BRK [0x02201000, 0x02201fff] PGTABLE [0.00] BRK [0x02202000,
[Umap2][9/11][05c5:0002] NULL pointer dereference
Kernel version: raspberrypi 4.4.6-v7+ #871 Driver source file: drivers/usb/serial/digi_acceleport.c Umap2 command line: umap2vsscan -P -s 05c5:0002 After connecting such a device, NULL pointer dereference in the kernel. Binyamin Sharet Cisco, STARE-C << Attached: 05c5_0002_dmesg.log >> [ 276.364478] usb 1-1.4: new high-speed USB device number 38 using dwc_otg [ 276.485399] usb 1-1.4: New USB device found, idVendor=05c5, idProduct=0002 [ 276.485426] usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 276.485443] usb 1-1.4: Product: UMAP2. PID:0x0002 [ 276.485458] usb 1-1.4: Manufacturer: UMAP2. VID:0x05c5 [ 276.485474] usb 1-1.4: SerialNumber: 123456 [ 277.580126] Unable to handle kernel NULL pointer dereference at virtual address 0190 [ 277.588386] pgd = af80 [ 277.57963[ 277.591116] [0190] *pgd=1] usbcore: registered new interface driver digi_acceleport [ 277.579812] usbserial: USB Serial support registered for Digi 2 port USB adapter [ 277.579951] usbserial: USB Serial support registered for Digi 4 port USB adapter [ 277.580056] digi_acceleport 1-1.4:1.0: Digi 2 port USB adapter converter detected [ 277.580126] Unable to handle kernel NULL pointer dereference at virtual address 0190 [ 277.588386] pgd = af80 [ 277.644118] Internal error: Oops: 805 [#1] SMP ARM [ 277.648908] Modules linked in: digi_acceleport(+) xsens_mt kobil_sct mos7720 ti_usb_3410_5052 usbserial bnep bluetooth cfg80211 rfkill snd_bcm2835 snd_pcm bcm2835_wdt bcm2835_gpiomem snd_timer snd uio_pdrv_genirq uio i2c_dev fuse [ 277.669388] CPU: 1 PID: 1064 Comm: systemd-udevd Not tainted 4.4.6-v7+ #871 [ 277.676337] Hardware name: BCM2709 [ 277.679736] task: b5dc2840 ti: af86a000 task.ti: af86a000 [ 277.685140] PC is at __init_waitqueue_head+0x1c/0x2c [ 277.690122] LR is at digi_port_init+0xc0/0xd8 [digi_acceleport] [ 277.696038] pc : [<800631e0>]lr : [<7f1bfb24>]psr: a013 [ 277.696038] sp : af86bba8 ip : af86bbb8 fp : af86bbb4 [ 277.707498] r10: 7f1c1308 r9 : b8fdcc80 r8 : b5f55c00 [ 277.712716] r7 : 0003 r6 : r5 : r4 : b8fc0c00 [ 277.719234] r3 : 0190 r2 : r1 : 7f1c1124 r0 : 0190 [ 277.725753] Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user [ 277.732880] Control: 10c5387d Table: 2f80006a DAC: 0055 [ 277.738618] Process systemd-udevd (pid: 1064, stack limit = 0xaf86a210) [ 277.745222] Stack: (0xaf86bba8 to 0xaf86c000) [ 277.749579] bba0: af86bbd4 af86bbb8 7f1bfb24 800631d0 b8fdcc8c b5eb2e00 [ 277.757751] bbc0: 0001 b8fdcc80 af86bbf4 af86bbd8 7f1bfbbc 7f1bfa70 7f1bfb5c 0200 [ 277.765922] bbe0: 0001 b8fa57b0 af86bce4 af86bbf8 7f19db5c 7f1bfb68 8000 b9487248 [ 277.774093] bc00: 0001 7f1c1308 0001 0003 0001 0003 b8fa4a00 7f1c1308 [ 277.782265] bc20: b8044068 0002 b8fdcc9c b8fa4a20 b8044000 b5f55d54 b8fa5600 af86bc48 [ 277.790436] bc40: 801c98d8 805eaa18 0002 b5fc3dc0 b5ea91e0 b8fa5630 af86bc68 [ 277.798607] bc60: 801c9a14 801c980c b5ea91e0 801c97f4 8001 b5ea91e0 b8fa5660 b8fa5720 [ 277.806780] bc80: 801c97f4 b5fc3dc0 af8531e0 b5ea91e0 af86bcbc af8531e0 b8fa5690 b8fa5750 [ 277.814951] bca0: b8fa57b0 af86bcb0 8040ad70 8040ac7c 05c5 7f1c0e6c b8fa4a00 b8fa4a20 [ 277.823122] bcc0: b8044068 b8044000 b8fdce34 b8fa4a00 7f1c0e6c af86bd14 af86bce8 [ 277.831294] bce0: 8040af88 7f19d078 8040aea0 8099d880 b8fa4a20 b8fdce34 0038 [ 277.839465] bd00: 7f19ecd0 7f1c1210 af86bd3c af86bd18 803a5e20 8040aeac 0007 b8fa4a20 [ 277.847636] bd20: b8fdce34 b8fa4a54 7f19ebcc 7f19ec40 af86bd5c af86bd40 803a5fac 803a5c64 [ 277.855807] bd40: b958a45c b8fdce34 803a5f04 af86bd84 af86bd60 803a3fec 803a5f10 [ 277.863978] bd60: b958a45c b8fd9234 800fcb94 7f1a0488 7f1c0e68 b8fdce00 af86bd94 af86bd88 [ 277.872149] bd80: 803a58e8 803a3f7c af86bdd4 af86bd98 7f19cd6c 803a58c8 8040003e 7f1c0e6c [ 277.880322] bda0: 7f1c0e60 b8f8b440 808a2398 808a2398 b8f8b7c0 7f1c3000 0001 [ 277.888493] bdc0: 4a0d6f1c af86bde4 af86bdd8 7f1c3028 7f19ca98 af86be64 af86bde8 [ 277.89] bde0: 80009764 7f1c300c 3a721000 af86be3c af86be00 80105288 00010dbe [ 277.904837] be00: 801394d8 b5f29b00 3a721000 0001 4a0d6f1c 80147e40 af86be64 af86be28 [ 277.913008] be20: 80147e40 805e93d4 0001 801394d8 0006 00010dbe bc0ad000 7f1c1400 [ 277.921179] be40: 0001 b8f8b440 7f1c1400 0001 4a0d6f1c b5f29108 af86be8c af86be68 [ 277.929351] be60: 800fccc8 800096d0 af86be8c af86be78 801395d4 af86bf44 0001 b5f29100 [ 277.937522] be80: af86bf3c af86be90 8009ec68 800fcc60 7f1c140c 7fff 7f1c1400 8009c34c [ 277.945693] bea0: 00c0 7f1c140c 7f1c140c 7f1c1604 7f1c15e4 7f1c1518 7f1c1448 [ 277.953865] bec0: bc0ad000 577c 000416bf 0b32 [ 277.962034] bee0: 00
[Umap2][10/11][1a0a:0102] USB host stops communicating
Kernel version: raspberrypi 4.4.6-v7+ #871 Umap2 command line: umap2vsscan -P -s 1a0a:0102 After connecting such a device, the USB host stops communicating. >From dmesg: [ 5924.751650] usb 1-1.4: new high-speed USB device number 103 using dwc_otg [ 5924.866112] usb 1-1.4: New USB device found, idVendor=1a0a, idProduct=0101 [ 5924.866143] usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 5924.866160] usb 1-1.4: Product: UMAP2. PID:0x0101 [ 5924.866175] usb 1-1.4: Manufacturer: UMAP2. VID:0x1a0a [ 5924.866191] usb 1-1.4: SerialNumber: 123456 [ 5924.892698] usb 1-1.4: VID from HSOTG Electrical Test Fixture [ 5924.892725] usb 1-1.4: Got PID 0x101 [ 5924.892741] usb 1-1.4: TEST_SE0_NAK [ 5924.892770] WARN::dwc_otg_hcd_hub_control:3471: USB_PORT_FEAT_TEST 3 Binyamin Sharet Cisco, STARE-C -- 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
[Umap2][11/11][9022:d483] kernel is unable to handle paging address
Kernel version: raspberrypi 4.4.6-v7+ #871 Driver source file: drivers/media/usb/dvb-usb/dw2102.c Umap2 command line: umap2vsscan -P -s 9022:d483 After connecting such a device, kernel oops: kernel is unable to handle paging address. Also happens with 9022:d484. Binyamin Sharet Cisco, STARE-C << Attached: 9022_d483_dmesg_1.log >> << Attached: 9022_d483_dmesg_2.log >> << Attached: 9022_d483_kernel.log >> [ 7490.401887] usb 1-1.4: new high-speed USB device number 81 using dwc_otg [ 7490.541759] usb 1-1.4: New USB device found, idVendor=9022, idProduct=d483 [ 7490.541788] usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 7490.541882] usb 1-1.4: Product: UMAP2. PID:0xd483 [ 7490.541902] usb 1-1.4: Manufacturer: UMAP2. VID:0x9022 [ 7490.541927] usb 1-1.4: SerialNumber: 123456 [ 7490.579770] dw2102: su3000_identify_state [ 7490.579803] dvb-usb: found a 'TeVii S482 (tuner 1)' in warm state. [ 7490.579830] dw2102: su3000_power_ctrl: 1, initialized 0 [ 7490.581658] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. [ 7490.582248] DVB: registering new adapter (TeVii S482 (tuner 1)) [ 7490.586439] dvb-usb: recv bulk message failed: -71 [ 7490.586456] dw2102: i2c transfer failed. [ 7490.586926] dvb-usb: bulk message failed: -71 (6/0) [ 7490.586940] dw2102: i2c transfer failed. [ 7490.587425] dvb-usb: bulk message failed: -71 (6/0) [ 7490.587437] dw2102: i2c transfer failed. [ 7490.588425] dvb-usb: bulk message failed: -71 (6/0) [ 7490.588437] dw2102: i2c transfer failed. [ 7490.589431] dvb-usb: bulk message failed: -71 (6/0) [ 7490.589443] dw2102: i2c transfer failed. [ 7490.590424] dvb-usb: bulk message failed: -71 (6/0) [ 7490.590436] dw2102: i2c transfer failed. [ 7490.590451] dvb-usb: MAC address: 00:00:00:00:00:00 [ 7490.593216] dvb-usb: bulk message failed: -71 (3/0) [ 7490.593238] dw2102: command 0x0e transfer failed. [ 7490.594437] dvb-usb: bulk message failed: -71 (3/0) [ 7490.594450] dw2102: command 0x0e transfer failed. [ 7490.902357] dvb-usb: bulk message failed: -71 (3/0) [ 7490.902375] dw2102[ 7490.921202] Unable to handle kernel paging request at virtual address af8739b0 [ 7490.929497] pgd = b8dfc000 [ 7490.932206] [af8739b0] *pgd=2f81141e(bad) [ 7490.936234] Internal error: Oops: 800d [#1] SMP ARM [ 7490.941451] Modules linked in: m88ds3103 cxd2820r ts2020 regmap_i2c m88rs2000 rc_su3000 ds3000 dvb_usb_dw2102 pvrusb2 smsdvb smsusb smsmdtv gspca_spca506 gspca_spca500 gspca_nw80x gspca_jl2005bcd gspca_spca1528 gspca_dtcs033 gspca_spca505 gspca_kinect gspca_topro gspca_benq gspca_sq905 gspca_etoms gspca_sq905c sg gspca_ov519 gspca_stv0680 gspca_zc3xx gspca_konica gspca_vicam gspca_sn9c2028 gspca_sn9c20x gspca_pac207 gspca_finepix gspca_se401 gspca_xirlink_cit gspca_pac7302 gspca_stk1135 gspca_conex gspca_tv8532 gspca_stk014 gspca_mars gspca_ov534_9 gspca_cpia1 gspca_ov534 gspca_mr97310a gspca_spca501 gspca_spca561 gspca_pac7311 gspca_jeilinj gspca_spca508 gspca_t613 gspca_stv06xx gspca_m5602 gspca_gl860 gspca_main tm6000 s2255drv tda18271 mxl5007t xc5000 au8522_dig au8522_decoder au8522_common au0828 videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_core zr364xx dvb_usb_dib0700 dib9000 dib7000m dib0090 dib0070 dib3000mc dibx000_common dvb_usb dvb_core rc_pinnacle_pctv_hd rc_hauppauge evdev ir_xmp_decoder ir_lirc_codec lirc_dev ir_sony_decoder ir_mce_kbd_decoder ir_sharp_decoder ir_sanyo_decoder ir_rc6_decoder ir_jvc_decoder ir_nec_decoder ir_rc5_decoder rc_rc6_mce mceusb cx231xx cx2341x videobuf_vmalloc videobuf_core tveeprom rc_core v4l2_common i2c_mux dsbr100 videodev media microtek mdc800 speedtch ueagle_atm usbatm atm btusb btrtl btintel btbcm snd_usb_audio snd_usbmidi_lib snd_hwdep snd_rawmidi snd_seq_device ftdi_elan yurex emi26 bnep bluetooth cfg80211 rfkill snd_bcm2835 bcm2835_gpiomem snd_pcm bcm2835_wdt snd_timer snd uio_pdrv_genirq uio i2c_dev fuse [ 7491.081186] CPU: 0 PID: 1846 Comm: kworker/0:2 Tainted: GW 4.4.6-v7+ #871 [ 7491.089175] Hardware name: BCM2709 [ 7491.092587] Workqueue: usb_hub_wq hub_event [ 7491.096770] task: b5dc3f40 ti: af872000 task.ti: af872000 [ 7491.102161] PC is at 0xaf8739b0 [ 7491.105312] LR is at m88ds3103_attach+0x100/0x128 [m88ds3103] [ 7491.111053] pc : []lr : [<7f5e81d0>]psr: 2013 [ 7491.111053] sp : af873990 ip : fp : af873a04 [ 7491.122513] r10: 00a1 r9 : 0003 r8 : 019bfcc0 [ 7491.127731] r7 : af873a18 r6 : 0021 r5 : b80f47f8 r4 : adc57000 [ 7491.134248] r3 : af8739b0 r2 : r1 : b8e86084 r0 : adc57000 [ 7491.140768] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel [ 7491.148066] Control: 10c5387d Table: 38dfc06a DAC: 0055 [ 7491.153803] Process kworker/0:2 (pid: 1846, stack limit = 0xaf872210) [ 7491.160234] Stack: (0xaf873990 to 0xaf874000) [ 7491.164588] 3980: 019bfcc0 00030021 3e80 7f12999c [ 7491.172759] 39a0: af8739dc af8739b0 8009c2a1 6438386d 30313373 003
Re: musb: am3358: having problem with high-speed on usb1 at peripheral
On 08/16/2016 04:31 PM, Felipe Balbi wrote: Hi, Ayaka writes: ayaka writes: On 08/13/2016 01:44 AM, Greg KH wrote: On Sat, Aug 13, 2016 at 12:38:46AM +0800, ayaka wrote: On 08/12/2016 03:40 PM, Greg KH wrote: On Fri, Aug 12, 2016 at 10:23:15AM +0800, ayaka wrote: Hello all: I recently add a support for customize am3358 board using the branch processor-sdk-linux-03.00.00 from Ti git. But I meet a problem with musb at the peripheral mode. Then you are going to have to get support from TI for this, nothing we can do here about random vendor kernel trees, sorry. If you can use the 4.7 tree, or better yet, the 4.8-rc tree, then we I have tried the 4.8-rc1, I meet the same problem. What problem is that exactly? Sorry, the USB1 can't work at high speed gadget mode and have DMA problem. musb-hdrc musb-hdrc.0.auto: Failed to request rx1. musb-hdrc musb-hdrc.0.auto: musb_init_controller failed with status -517 -517 is EPROBE_DEFER. Most likely DMA hasn't probed and MUSB is deferring to try later. This does _NOT_ MUSB can't work with DMA. Perhaps you didn't enable support for MUSB's DMA engine. I have set the status of cppi41dma to okay in dts. And CONFIG_USB_TI_CPPI41_DMA, CONFIG_TI_CPPI41 and CONFIG_TI_EDMA are enabled with build into kernel. Anything else I should do? no, that should do it. Since musb returned -EPROBE_DEFER, it will retry probing later. Check if musb probed fine. The easiest way is to check if you have anything in /sys/class/udc/ Yes, it has musb-hdrc.0.auto. But it doesn't mean that it fallback PIO mode? Actually I don't care whether it use PIO or DMA, I just can't bear it work in USB 2.0 Full Speed mode, too slow. -- 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: [Umap2][1/11][0aa8:8001] USB stack hang
On Tue, Aug 16, 2016 at 04:42:23PM +0300, Binyamin Sharet wrote: > Kernel version: raspberrypi 4.4.6-v7+ #871 > Kernel version: 4.4.0-24-generic #43-Ubuntu SMP That's really old (like 30,000+ patches ago.) And we have no idea what's in a ubuntu kernel image, do you ? Can you test these on 4.7-rc2? If you can, we will be glad to help, otherwise there's not much we can do as you could imagine (i.e. we can't go back in time to fix 4.4.6...) thnaks, 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: [Umap2][3/11][0471:0602] NULL pointer dereference
On Tue, 16 Aug 2016, Binyamin Sharet wrote:
> Kernel version: raspberrypi 4.4.6-v7+ #871
> Driver source file: drivers/input/misc/ati_remote2.c
> Umap2 command line: umap2vsscan -P -s 0471:0602
>
> After connecting such a device, NULL pointer dereference in the kernel
> and USB stops responding.
>
> Binyamin Sharet
> Cisco, STARE-C
>
> << Attached: 0471_0602_dmesg.log >>
This bug was fixed by commit 950336ba3e4a ("Input: ati_remote2 - fix
crashes on detecting device with invalid descriptor") in the 4.6
kernel. The commit was marked for inclusion in the stable kernel
series, but it might not be included in 4.4.6.
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 v11 1/5] usb: dwc3: of-simple: add compatible for rockchip rk3399
Rockchip platform merely enable usb3 clocks and
populate its children. So we can use this generic
glue layer to support Rockchip dwc3.
Signed-off-by: William Wu
---
Changes in v11:
- add compatible in dwc3-of-simple.c, and remove dwc3-rockchip.c (balbi)
Changes in v10:
- None
Changes in v9:
- remove compatible from dwc3-of-simple.c, and add a new glue layer
dwc3-rockchip.c
Changes in v8:
- None
Changes in v7:
- None
Changes in v6:
- None
Changes in v5:
- change compatible from "rockchip,dwc3" to "rockchip,rk3399-dwc3" (Heiko)
Changes in v4:
- None
Changes in v3:
- None
Changes in v2:
- sort the list of_dwc3_simple_match (Doug)
drivers/usb/dwc3/dwc3-of-simple.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/dwc3/dwc3-of-simple.c
b/drivers/usb/dwc3/dwc3-of-simple.c
index e56d59b..283f998 100644
--- a/drivers/usb/dwc3/dwc3-of-simple.c
+++ b/drivers/usb/dwc3/dwc3-of-simple.c
@@ -162,6 +162,7 @@ static const struct dev_pm_ops dwc3_of_simple_dev_pm_ops = {
static const struct of_device_id of_dwc3_simple_match[] = {
{ .compatible = "qcom,dwc3" },
+ { .compatible = "rockchip,rk3399-dwc3" },
{ .compatible = "xlnx,zynqmp-dwc3" },
{ /* Sentinel */ }
};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v11 3/5] usb: dwc3: make usb2 phy utmi interface configurable
Support to configure the UTMI+ PHY with an 8- or 16-bit
interface via DT. The UTMI+ PHY interface is a hardware
capability, and it's platform dependent. Normally, the
PHYIF can be configured during coreconsultant.
But for some specific USB cores(e.g. rk3399 SoC DWC3),
the default PHYIF configuration value is false, so we
need to reconfigure it by software.
Signed-off-by: William Wu
Acked-by: Rob Herring
---
Changes in v11:
- None
Changes in v10:
- None
Changes in v9:
- None
Changes in v8:
- configure utmi interface via phy_type property in DT (Heiko, Rob Herring)
- add Acked-by (Rob Herring)
- modify commit message (Rob Herring)
Changes in v7:
- remove quirk and use only one property to configure utmi (Heiko, Rob Herring)
Changes in v6:
- use '-' instead of '_' in dts (Rob Herring)
Changes in v5:
- None
Changes in v4:
- rebase on top of balbi testing/next, remove pdata (balbi)
Changes in v3:
- None
Changes in v2:
- add a quirk for phyif_utmi (balbi)
Documentation/devicetree/bindings/usb/generic.txt | 6 ++
drivers/usb/dwc3/core.c | 18 ++
drivers/usb/dwc3/core.h | 12
3 files changed, 36 insertions(+)
diff --git a/Documentation/devicetree/bindings/usb/generic.txt
b/Documentation/devicetree/bindings/usb/generic.txt
index bba8257..bfadeb1 100644
--- a/Documentation/devicetree/bindings/usb/generic.txt
+++ b/Documentation/devicetree/bindings/usb/generic.txt
@@ -11,6 +11,11 @@ Optional properties:
"peripheral" and "otg". In case this attribute isn't
passed via DT, USB DRD controllers should default to
OTG.
+ - phy_type: tells USB controllers that we want to configure the core to
support
+ a UTMI+ PHY with an 8- or 16-bit interface if UTMI+ is
+ selected. Valid arguments are "utmi" and "utmi_wide".
+ In case this isn't passed via DT, USB controllers should
+ default to HW capability.
- otg-rev: tells usb driver the release number of the OTG and EH supplement
with which the device and its descriptors are compliant,
in binary-coded decimal (i.e. 2.0 is 0200H). This
@@ -34,6 +39,7 @@ dwc3@4a03 {
usb-phy = <&usb2_phy>, <&usb3,phy>;
maximum-speed = "super-speed";
dr_mode = "otg";
+ phy_type = "utmi_wide";
otg-rev = <0x0200>;
adp-disable;
};
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 14316e5..cdac019 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -485,6 +485,23 @@ static int dwc3_phy_setup(struct dwc3 *dwc)
break;
}
+ switch (dwc->hsphy_mode) {
+ case USBPHY_INTERFACE_MODE_UTMI:
+ reg &= ~(DWC3_GUSB2PHYCFG_PHYIF_MASK |
+ DWC3_GUSB2PHYCFG_USBTRDTIM_MASK);
+ reg |= DWC3_GUSB2PHYCFG_PHYIF(UTMI_PHYIF_8_BIT) |
+ DWC3_GUSB2PHYCFG_USBTRDTIM(USBTRDTIM_UTMI_8_BIT);
+ break;
+ case USBPHY_INTERFACE_MODE_UTMIW:
+ reg &= ~(DWC3_GUSB2PHYCFG_PHYIF_MASK |
+ DWC3_GUSB2PHYCFG_USBTRDTIM_MASK);
+ reg |= DWC3_GUSB2PHYCFG_PHYIF(UTMI_PHYIF_16_BIT) |
+ DWC3_GUSB2PHYCFG_USBTRDTIM(USBTRDTIM_UTMI_16_BIT);
+ break;
+ default:
+ break;
+ }
+
/*
* Above 1.94a, it is recommended to set DWC3_GUSB2PHYCFG_SUSPHY to
* '0' during coreConsultant configuration. So default value will
@@ -891,6 +908,7 @@ static int dwc3_probe(struct platform_device *pdev)
dwc->maximum_speed = usb_get_maximum_speed(dev);
dwc->dr_mode = usb_get_dr_mode(dev);
+ dwc->hsphy_mode = of_usb_get_phy_mode(dev->of_node);
dwc->has_lpm_erratum = device_property_read_bool(dev,
"snps,has-lpm-erratum");
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 08ed9e0..cc4f551 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -203,6 +203,14 @@
#define DWC3_GUSB2PHYCFG_SUSPHY(1 << 6)
#define DWC3_GUSB2PHYCFG_ULPI_UTMI (1 << 4)
#define DWC3_GUSB2PHYCFG_ENBLSLPM (1 << 8)
+#define DWC3_GUSB2PHYCFG_PHYIF(n) (n << 3)
+#define DWC3_GUSB2PHYCFG_PHYIF_MASKDWC3_GUSB2PHYCFG_PHYIF(1)
+#define DWC3_GUSB2PHYCFG_USBTRDTIM(n) (n << 10)
+#define DWC3_GUSB2PHYCFG_USBTRDTIM_MASKDWC3_GUSB2PHYCFG_USBTRDTIM(0xf)
+#define USBTRDTIM_UTMI_8_BIT 9
+#define USBTRDTIM_UTMI_16_BIT 5
+#define UTMI_PHYIF_16_BIT 1
+#define UTMI_PHYIF_8_BIT 0
/* Global USB2 PHY Vendor Control Register */
#define DWC3_GUSB2PHYACC_NEWREGREQ (1 << 25)
@@ -748,6 +756,9 @@ struct dwc3_scratchpad_array {
* @maximum_speed: maximum speed requested (mainly for testing purposes)
* @rev
[PATCH v11 0/5] support rockchip dwc3 driver
This series add support for rockchip DWC3 driver, and add additional optional properties for specific platforms (e.g., rockchip rk3399 platform). The DesignWare USB3 integrated in rockchip SoCs is a configurable IP Core which can be instantiated as Dual-Role Device (DRD), Host Only (XHCI) and Peripheral Only configurations. The current driver supports Host only and Peripheral Only, for now, and we can add support for DRD after dwc3 driver adds generic handling of DRD. William Wu (5): usb: dwc3: of-simple: add compatible for rockchip rk3399 usb: dwc3: add dis_u2_freeclk_exists_quirk usb: dwc3: make usb2 phy utmi interface configurable usb: dwc3: add dis_del_phy_power_chg_quirk usb: dwc3: rockchip: add devicetree bindings documentation Documentation/devicetree/bindings/usb/dwc3.txt | 5 ++ Documentation/devicetree/bindings/usb/generic.txt | 6 +++ .../devicetree/bindings/usb/rockchip,dwc3.txt | 59 ++ drivers/usb/dwc3/core.c| 28 ++ drivers/usb/dwc3/core.h| 20 drivers/usb/dwc3/dwc3-of-simple.c | 1 + 6 files changed, 119 insertions(+) create mode 100644 Documentation/devicetree/bindings/usb/rockchip,dwc3.txt -- 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: [Umap2][9/11][05c5:0002] NULL pointer dereference
On Tue, 16 Aug 2016, Binyamin Sharet wrote: > Kernel version: raspberrypi 4.4.6-v7+ #871 > Driver source file: drivers/usb/serial/digi_acceleport.c > Umap2 command line: umap2vsscan -P -s 05c5:0002 > > After connecting such a device, NULL pointer dereference in the kernel. > > Binyamin Sharet > Cisco, STARE-C > > << Attached: 05c5_0002_dmesg.log >> This looks like a bug in the digi_acceleport driver. digi_startup() does this: serial_priv->ds_oob_port_num = serial->type->num_ports; serial_priv->ds_oob_port = serial->port[serial_priv->ds_oob_port_num]; Even without knowing exactly what this is supposed to be doing, one gets the definite impression that the first line should be: serial_priv->ds_oob_port_num = serial->type->num_ports - 1; Johan? 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 v11 5/5] usb: dwc3: rockchip: add devicetree bindings documentation
This patch adds the devicetree documentation required for Rockchip
USB3.0 core wrapper consisting of USB3.0 IP from Synopsys.
It supports DRD mode, and could operate in device mode (SS, HS, FS)
and host mode (SS, HS, FS, LS).
Signed-off-by: William Wu
Acked-by: Rob Herring
---
Changes in v11:
- remove required properties "resets" and "reset-names"
- remove optional property "extcon"
Changes in v10:
- None
Changes in v9:
- add required properties "resets" and "reset-names"
- add optional property "extcon"
Changes in v8:
- None
Changes in v7:
- add Acked-by (Rob Herring)
Changes in v6:
- rename bus_clk, and add usbdrd3_1 node as an example (Heiko)
Changes in v5:
- rename clock-names, and remove unnecessary clocks (Heiko)
Changes in v4:
- modify commit log, and add phy documentation location (Sergei)
Changes in v3:
- add dwc3 address (balbi)
Changes in v2:
- add rockchip,dwc3.txt to Documentation/devicetree/bindings/ (balbi, Brian)
.../devicetree/bindings/usb/rockchip,dwc3.txt | 59 ++
1 file changed, 59 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/rockchip,dwc3.txt
diff --git a/Documentation/devicetree/bindings/usb/rockchip,dwc3.txt
b/Documentation/devicetree/bindings/usb/rockchip,dwc3.txt
new file mode 100644
index 000..0536a93
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/rockchip,dwc3.txt
@@ -0,0 +1,59 @@
+Rockchip SuperSpeed DWC3 USB SoC controller
+
+Required properties:
+- compatible: should contain "rockchip,rk3399-dwc3" for rk3399 SoC
+- clocks: A list of phandle + clock-specifier pairs for the
+ clocks listed in clock-names
+- clock-names: Should contain the following:
+ "ref_clk"Controller reference clk, have to be 24 MHz
+ "suspend_clk"Controller suspend clk, have to be 24 MHz or 32 KHz
+ "bus_clk"Master/Core clock, have to be >= 62.5 MHz for SS
+ operation and >= 30MHz for HS operation
+ "grf_clk"Controller grf clk
+
+Required child node:
+A child node must exist to represent the core DWC3 IP block. The name of
+the node is not important. The content of the node is defined in dwc3.txt.
+
+Phy documentation is provided in the following places:
+Documentation/devicetree/bindings/phy/rockchip,dwc3-usb-phy.txt
+
+Example device nodes:
+
+ usbdrd3_0: usb@fe80 {
+ compatible = "rockchip,rk3399-dwc3";
+ clocks = <&cru SCLK_USB3OTG0_REF>, <&cru SCLK_USB3OTG0_SUSPEND>,
+<&cru ACLK_USB3OTG0>, <&cru ACLK_USB3_GRF>;
+ clock-names = "ref_clk", "suspend_clk",
+ "bus_clk", "grf_clk";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+ status = "disabled";
+ usbdrd_dwc3_0: dwc3@fe80 {
+ compatible = "snps,dwc3";
+ reg = <0x0 0xfe80 0x0 0x10>;
+ interrupts = ;
+ dr_mode = "otg";
+ status = "disabled";
+ };
+ };
+
+ usbdrd3_1: usb@fe90 {
+ compatible = "rockchip,rk3399-dwc3";
+ clocks = <&cru SCLK_USB3OTG1_REF>, <&cru SCLK_USB3OTG1_SUSPEND>,
+<&cru ACLK_USB3OTG1>, <&cru ACLK_USB3_GRF>;
+ clock-names = "ref_clk", "suspend_clk",
+ "bus_clk", "grf_clk";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+ status = "disabled";
+ usbdrd_dwc3_1: dwc3@fe90 {
+ compatible = "snps,dwc3";
+ reg = <0x0 0xfe90 0x0 0x10>;
+ interrupts = ;
+ dr_mode = "otg";
+ status = "disabled";
+ };
+ };
--
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: [Umap2][1/11][0aa8:8001] USB stack hang
On Tue, Aug 16, 2016 at 04:42:23PM +0300, Binyamin Sharet wrote: > Kernel version: raspberrypi 4.4.6-v7+ #871 > Kernel version: 4.4.0-24-generic #43-Ubuntu SMP > Driver source file: drivers/staging/media/lirc/lirc_imon.c > Umap2 command line: umap2vsscan -P -s 0aa8:8001 > > After connecting such a device, the host usb stack became unresponsive. > Please see attached dmesg log. > > Binyamin Sharet > Cisco, STARE-C > [ 1206.083207] usb 3-2: new high-speed USB device number 2 using xhci_hcd > [ 1206.504969] usb 3-2: New USB device found, idVendor=0aa8, idProduct=8001 > [ 1206.504978] usb 3-2: New USB device strings: Mfr=1, Product=2, > SerialNumber=3 > [ 1206.504982] usb 3-2: Product: UMAP2. PID:0x8001 > [ 1206.504985] usb 3-2: Manufacturer: UMAP2. VID:0x0aa8 > [ 1206.504988] usb 3-2: SerialNumber: 123456 > [ 1207.732370] lirc_dev: IR Remote Control driver registered, major 244 > [ 1207.735697] lirc_imon: module is from the staging directory, the quality > is unknown, you have been warned. > [ 1207.736244] lirc_imon 3-2:1.0: lirc_dev: driver lirc_imon registered at > minor = 0 > [ 1207.736251] lirc_imon 3-2:1.0: Registered iMON driver (lirc minor: 0) > [ 1207.736268] lirc_imon 3-2:1.0: iMON device (0aa8:8001, intf0) on usb<3:2> > initialized > [ 1207.736320] usbcore: registered new interface driver lirc_imon > [ 1210.702280] lirc_imon 3-2:1.0: imon usb_rx_callback: status(-71): ignored > [ 1210.702356] usb 3-2: USB disconnect, device number 2 > [ 1210.702503] lirc_imon 3-2:1.0: imon usb_rx_callback: status(-71): ignored > > > > > [ 1440.146097] INFO: task kworker/1:0:14 blocked for more than 120 seconds. > [ 1440.146107] Tainted: G C OE 4.4.0-24-generic #43-Ubuntu > [ 1440.146110] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables > this message. > [ 1440.146113] kworker/1:0 D 8802149bfa68 014 2 > 0x > [ 1440.146126] Workqueue: usb_hub_wq hub_event > [ 1440.146129] 8802149bfa68 76b5ce45 8800c83fe040 > 8802149b1b80 > [ 1440.146134] 8802149c 8800aaca261c 8802149b1b80 > > [ 1440.146137] 8800aaca2620 8802149bfa80 81821b15 > 8800aaca2618 > [ 1440.146141] Call Trace: > [ 1440.146152] [] schedule+0x35/0x80 > [ 1440.146157] [] schedule_preempt_disabled+0xe/0x10 > [ 1440.146162] [] __mutex_lock_slowpath+0xb9/0x130 > [ 1440.146167] [] mutex_lock+0x1f/0x30 > [ 1440.146177] [] imon_disconnect+0x3d/0x110 [lirc_imon] > [ 1440.146183] [] usb_unbind_interface+0x83/0x260 > [ 1440.146190] [] __device_release_driver+0xa1/0x150 > [ 1440.146194] [] device_release_driver+0x23/0x30 > [ 1440.146197] [] bus_remove_device+0x101/0x170 > [ 1440.146202] [] device_del+0x139/0x260 > [ 1440.146207] [] ? usb_remove_ep_devs+0x1f/0x30 > [ 1440.146212] [] usb_disable_device+0x89/0x270 > [ 1440.146216] [] usb_disconnect+0x92/0x280 > [ 1440.146220] [] hub_port_connect+0x82/0x9c0 > [ 1440.146223] [] hub_event+0x6d1/0xb10 > [ 1440.146229] [] ? put_prev_entity+0x35/0x7d0 > [ 1440.146235] [] process_one_work+0x165/0x480 > [ 1440.146240] [] worker_thread+0x4b/0x4c0 > [ 1440.146244] [] ? process_one_work+0x480/0x480 > [ 1440.146248] [] kthread+0xd8/0xf0 > [ 1440.146252] [] ? kthread_create_on_node+0x1e0/0x1e0 > [ 1440.146256] [] ret_from_fork+0x3f/0x70 > [ 1440.146260] [] ? kthread_create_on_node+0x1e0/0x1e0 > [ 1440.146329] INFO: task colord-sane:4439 blocked for more than 120 seconds. > [ 1440.146332] Tainted: G C OE 4.4.0-24-generic #43-Ubuntu > [ 1440.146334] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables > this message. > [ 1440.146336] colord-sane D 8801d8123d78 0 4439 1163 > 0x > [ 1440.146341] 8801d8123d78 81e11500 > 8800c83fe040 > [ 1440.146345] 8801d8124000 8802107b68fc 8800c83fe040 > > [ 1440.146349] 8802107b6900 8801d8123d90 81821b15 > 8802107b68f8 > [ 1440.146353] Call Trace: > [ 1440.146358] [] schedule+0x35/0x80 > [ 1440.146362] [] schedule_preempt_disabled+0xe/0x10 > [ 1440.146367] [] __mutex_lock_slowpath+0xb9/0x130 > [ 1440.146371] [] mutex_lock+0x1f/0x30 > [ 1440.146375] [] read_descriptors+0x37/0x100 > [ 1440.146382] [] sysfs_kf_bin_read+0x4a/0x70 > [ 1440.146387] [] kernfs_fop_read+0xab/0x160 > [ 1440.146393] [] __vfs_read+0x18/0x40 > [ 1440.146398] [] vfs_read+0x86/0x130 > [ 1440.146402] [] SyS_read+0x55/0xc0 > [ 1440.146409] [] entry_SYSCALL_64_fastpath+0x16/0x71 Just an idea, can you provide the descriptors that you are using to fuzz these drivers with? Without that, it's a tough slog through the code to try to figure out what went wrong... 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: Potential vulnerabilities in USB host stack/drivers
On Tue, Aug 16, 2016 at 04:40:43PM +0300, Binyamin Sharet wrote: > Hi, > > We are using Umap2 to scan USB hosts for vendor-specific device support. > e.g. whether appropriate drivers are loaded when a device with a specific > VID/PID is inserted. > > In our configuration, we connect multiple times to the host, each time > providing different VID/PID in the device descriptor, and then we provide > a single configuration with a single interface that has multiple (10) > endpoints of different types. > > Umap2 can be downloaded from https://github.com/nccgroup/umap2, > and requires either a Facedancer board or a beaglebone black with a > modified gadgetfs module (source and instructions in umap2 repository) to > be used. > > During this scan we have found multiple issues in the kernel. > Some issues cause the the USB stack to hang, while others cause an oops. > Some of the issues seem similar and might originate from the same source, > however, due to my lack of knowledge in the Linux USB subsystem, I did not > perform an in-depth analysis of the root causes. > > In total, there are 11 issues: 2 hangs, 8 NULL pointer dereference and > 1 oops caused by kernel unable to handle paging address. > > To keep some order, I will send a separate mail for each issue, titled > '[Umap2][x/11][$VID:$PID] $result'. Another minor nit, try a leading 0 on your 1-9 emails so they sort properly :) 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: [Umap2][4/11][0557:2002] NULL pointer dereference
On Tue, 16 Aug 2016, Binyamin Sharet wrote: > Kernel version: raspberrypi 4.4.6-v7+ #871 > Driver source file: drivers/net/usb/kaweth.c > Umap2 command line: umap2vsscan -P -s 0557:2002 > > After connecting such a device, NULL pointer dereference in the kernel > and USB stops responding. > > This issue was reproduced with other VID/PIDs that use this driver. > > Binyamin Sharet > Cisco, STARE-C > > << Attached: 0557_2002_dmesg.log >> This looks like a bug in the kaweth driver. kaweth_probe() assigns kaweth->intf = intf; but it needs to happen much earlier in the routine, probably along with the initializations of kaweth->dev and kaweth->net. 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: [Umap2][9/11][05c5:0002] NULL pointer dereference
On Tue, Aug 16, 2016 at 10:47:44AM -0400, Alan Stern wrote:
> On Tue, 16 Aug 2016, Binyamin Sharet wrote:
>
> > Kernel version: raspberrypi 4.4.6-v7+ #871
> > Driver source file: drivers/usb/serial/digi_acceleport.c
> > Umap2 command line: umap2vsscan -P -s 05c5:0002
> >
> > After connecting such a device, NULL pointer dereference in the kernel.
> >
> > Binyamin Sharet
> > Cisco, STARE-C
> >
> > << Attached: 05c5_0002_dmesg.log >>
>
> This looks like a bug in the digi_acceleport driver. digi_startup()
> does this:
>
> serial_priv->ds_oob_port_num = serial->type->num_ports;
> serial_priv->ds_oob_port = serial->port[serial_priv->ds_oob_port_num];
>
> Even without knowing exactly what this is supposed to be doing, one
> gets the definite impression that the first line should be:
>
> serial_priv->ds_oob_port_num = serial->type->num_ports - 1;
>
> Johan?
The out-of-band port is not included in num_ports so that should not be
the issue here. The missing sanity checks for the endpoint layout were
only recently added by
5a07975ad0a3 ("USB: digi_acceleport: do sanity checking for the
number of ports")
however, even if it has been included in 4.4-stable since 4.4.7.
Binyamin, could you rerun your tests on the latest 4.4-stable kernel to
make sure you're not reporting already fixed issues?
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
[PATCH v11 2/5] usb: dwc3: add dis_u2_freeclk_exists_quirk
Add a quirk to clear the GUSB2PHYCFG.U2_FREECLK_EXISTS bit,
which specifies whether the USB2.0 PHY provides a free-running
PHY clock, which is active when the clock control input is active.
Signed-off-by: William Wu
Acked-by: Rob Herring
---
Changes in v11:
- None
Changes in v10:
- None
Changes in v9:
- None
Changes in v8:
- add Acked-by (Rob Herring)
Changes in v7:
- None
Changes in v6:
- use '-' instead of '_' in dts (Rob Herring)
Changes in v5:
- None
Changes in v4:
- rebase on top of balbi testing/next, remove pdata (balbi)
Changes in v3:
- None
Changes in v2:
- None
Documentation/devicetree/bindings/usb/dwc3.txt | 3 +++
drivers/usb/dwc3/core.c| 5 +
drivers/usb/dwc3/core.h| 5 +
3 files changed, 13 insertions(+)
diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt
b/Documentation/devicetree/bindings/usb/dwc3.txt
index 7d7ce08..020b0e9 100644
--- a/Documentation/devicetree/bindings/usb/dwc3.txt
+++ b/Documentation/devicetree/bindings/usb/dwc3.txt
@@ -39,6 +39,9 @@ Optional properties:
disabling the suspend signal to the PHY.
- snps,dis_rxdet_inp3_quirk: when set core will disable receiver detection
in PHY P3 power state.
+ - snps,dis-u2-freeclk-exists-quirk: when set, clear the u2_freeclk_exists
+ in GUSB2PHYCFG, specify that USB2 PHY doesn't provide
+ a free-running PHY clock.
- snps,is-utmi-l1-suspend: true when DWC3 asserts output signal
utmi_l1_suspend_n, false when asserts utmi_sleep_n
- snps,hird-threshold: HIRD threshold
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 35d0924..14316e5 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -500,6 +500,9 @@ static int dwc3_phy_setup(struct dwc3 *dwc)
if (dwc->dis_enblslpm_quirk)
reg &= ~DWC3_GUSB2PHYCFG_ENBLSLPM;
+ if (dwc->dis_u2_freeclk_exists_quirk)
+ reg &= ~DWC3_GUSB2PHYCFG_U2_FREECLK_EXISTS;
+
dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), reg);
return 0;
@@ -924,6 +927,8 @@ static int dwc3_probe(struct platform_device *pdev)
"snps,dis_enblslpm_quirk");
dwc->dis_rxdet_inp3_quirk = device_property_read_bool(dev,
"snps,dis_rxdet_inp3_quirk");
+ dwc->dis_u2_freeclk_exists_quirk = device_property_read_bool(dev,
+ "snps,dis-u2-freeclk-exists-quirk");
dwc->tx_de_emphasis_quirk = device_property_read_bool(dev,
"snps,tx_de_emphasis_quirk");
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 1a6cc48..08ed9e0 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -199,6 +199,7 @@
/* Global USB2 PHY Configuration Register */
#define DWC3_GUSB2PHYCFG_PHYSOFTRST(1 << 31)
+#define DWC3_GUSB2PHYCFG_U2_FREECLK_EXISTS (1 << 30)
#define DWC3_GUSB2PHYCFG_SUSPHY(1 << 6)
#define DWC3_GUSB2PHYCFG_ULPI_UTMI (1 << 4)
#define DWC3_GUSB2PHYCFG_ENBLSLPM (1 << 8)
@@ -803,6 +804,9 @@ struct dwc3_scratchpad_array {
* @dis_u2_susphy_quirk: set if we disable usb2 suspend phy
* @dis_enblslpm_quirk: set if we clear enblslpm in GUSB2PHYCFG,
* disabling the suspend signal to the PHY.
+ * @dis_u2_freeclk_exists_quirk : set if we clear u2_freeclk_exists
+ * in GUSB2PHYCFG, specify that USB2 PHY doesn't
+ * provide a free-running PHY clock.
* @tx_de_emphasis_quirk: set if we enable Tx de-emphasis quirk
* @tx_de_emphasis: Tx de-emphasis value
* 0 - -6dB de-emphasis
@@ -946,6 +950,7 @@ struct dwc3 {
unsigneddis_u2_susphy_quirk:1;
unsigneddis_enblslpm_quirk:1;
unsigneddis_rxdet_inp3_quirk:1;
+ unsigneddis_u2_freeclk_exists_quirk:1;
unsignedtx_de_emphasis_quirk:1;
unsignedtx_de_emphasis:2;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v11 4/5] usb: dwc3: add dis_del_phy_power_chg_quirk
Add a quirk to clear the GUSB3PIPECTL.DELAYP1TRANS bit,
which specifies whether disable delay PHY power change
from P0 to P1/P2/P3 when link state changing from U0
to U1/U2/U3 respectively.
Signed-off-by: William Wu
Acked-by: Rob Herring
---
Changes in v11:
- None
Changes in v10:
- None
Changes in v9:
- None
Changes in v8:
- add Acked-by (Rob Herring)
Changes in v7:
- None
Changes in v6:
- use '-' instead of '_' in dts (Rob Herring)
Changes in v5:
- None
Changes in v4:
- rebase on top of balbi testing/next, remove pdata (balbi)
Changes in v3:
- None
Changes in v2:
- None
Documentation/devicetree/bindings/usb/dwc3.txt | 2 ++
drivers/usb/dwc3/core.c| 5 +
drivers/usb/dwc3/core.h| 3 +++
3 files changed, 10 insertions(+)
diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt
b/Documentation/devicetree/bindings/usb/dwc3.txt
index 020b0e9..e96bfc2 100644
--- a/Documentation/devicetree/bindings/usb/dwc3.txt
+++ b/Documentation/devicetree/bindings/usb/dwc3.txt
@@ -42,6 +42,8 @@ Optional properties:
- snps,dis-u2-freeclk-exists-quirk: when set, clear the u2_freeclk_exists
in GUSB2PHYCFG, specify that USB2 PHY doesn't provide
a free-running PHY clock.
+ - snps,dis-del-phy-power-chg-quirk: when set core will change PHY power
+ from P0 to P1/P2/P3 without delay.
- snps,is-utmi-l1-suspend: true when DWC3 asserts output signal
utmi_l1_suspend_n, false when asserts utmi_sleep_n
- snps,hird-threshold: HIRD threshold
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index cdac019..e887b38 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -448,6 +448,9 @@ static int dwc3_phy_setup(struct dwc3 *dwc)
if (dwc->dis_u3_susphy_quirk)
reg &= ~DWC3_GUSB3PIPECTL_SUSPHY;
+ if (dwc->dis_del_phy_power_chg_quirk)
+ reg &= ~DWC3_GUSB3PIPECTL_DEPOCHANGE;
+
dwc3_writel(dwc->regs, DWC3_GUSB3PIPECTL(0), reg);
reg = dwc3_readl(dwc->regs, DWC3_GUSB2PHYCFG(0));
@@ -947,6 +950,8 @@ static int dwc3_probe(struct platform_device *pdev)
"snps,dis_rxdet_inp3_quirk");
dwc->dis_u2_freeclk_exists_quirk = device_property_read_bool(dev,
"snps,dis-u2-freeclk-exists-quirk");
+ dwc->dis_del_phy_power_chg_quirk = device_property_read_bool(dev,
+ "snps,dis-del-phy-power-chg-quirk");
dwc->tx_de_emphasis_quirk = device_property_read_bool(dev,
"snps,tx_de_emphasis_quirk");
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index cc4f551..3d94acd 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -818,6 +818,8 @@ struct dwc3_scratchpad_array {
* @dis_u2_freeclk_exists_quirk : set if we clear u2_freeclk_exists
* in GUSB2PHYCFG, specify that USB2 PHY doesn't
* provide a free-running PHY clock.
+ * @dis_del_phy_power_chg_quirk: set if we disable delay phy power
+ * change quirk.
* @tx_de_emphasis_quirk: set if we enable Tx de-emphasis quirk
* @tx_de_emphasis: Tx de-emphasis value
* 0 - -6dB de-emphasis
@@ -963,6 +965,7 @@ struct dwc3 {
unsigneddis_enblslpm_quirk:1;
unsigneddis_rxdet_inp3_quirk:1;
unsigneddis_u2_freeclk_exists_quirk:1;
+ unsigneddis_del_phy_power_chg_quirk:1;
unsignedtx_de_emphasis_quirk:1;
unsignedtx_de_emphasis:2;
--
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: [Umap2][1/11][0aa8:8001] USB stack hang
On 08/16/2016 05:49 PM, Greg KH wrote: > On Tue, Aug 16, 2016 at 04:42:23PM +0300, Binyamin Sharet wrote: >> Kernel version: raspberrypi 4.4.6-v7+ #871 >> Kernel version: 4.4.0-24-generic #43-Ubuntu SMP >> Driver source file: drivers/staging/media/lirc/lirc_imon.c >> Umap2 command line: umap2vsscan -P -s 0aa8:8001 >> >> After connecting such a device, the host usb stack became unresponsive. >> Please see attached dmesg log. >> >> Binyamin Sharet >> Cisco, STARE-C >> [ 1206.083207] usb 3-2: new high-speed USB device number 2 using xhci_hcd >> [ 1206.504969] usb 3-2: New USB device found, idVendor=0aa8, idProduct=8001 >> [ 1206.504978] usb 3-2: New USB device strings: Mfr=1, Product=2, >> SerialNumber=3 >> [ 1206.504982] usb 3-2: Product: UMAP2. PID:0x8001 >> [ 1206.504985] usb 3-2: Manufacturer: UMAP2. VID:0x0aa8 >> [ 1206.504988] usb 3-2: SerialNumber: 123456 >> [ 1207.732370] lirc_dev: IR Remote Control driver registered, major 244 >> [ 1207.735697] lirc_imon: module is from the staging directory, the quality >> is unknown, you have been warned. >> [ 1207.736244] lirc_imon 3-2:1.0: lirc_dev: driver lirc_imon registered at >> minor = 0 >> [ 1207.736251] lirc_imon 3-2:1.0: Registered iMON driver (lirc minor: 0) >> [ 1207.736268] lirc_imon 3-2:1.0: iMON device (0aa8:8001, intf0) on usb<3:2> >> initialized >> [ 1207.736320] usbcore: registered new interface driver lirc_imon >> [ 1210.702280] lirc_imon 3-2:1.0: imon usb_rx_callback: status(-71): ignored >> [ 1210.702356] usb 3-2: USB disconnect, device number 2 >> [ 1210.702503] lirc_imon 3-2:1.0: imon usb_rx_callback: status(-71): ignored >> >> >> >> >> [ 1440.146097] INFO: task kworker/1:0:14 blocked for more than 120 seconds. >> [ 1440.146107] Tainted: G C OE 4.4.0-24-generic #43-Ubuntu >> [ 1440.146110] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables >> this message. >> [ 1440.146113] kworker/1:0 D 8802149bfa68 014 2 >> 0x >> [ 1440.146126] Workqueue: usb_hub_wq hub_event >> [ 1440.146129] 8802149bfa68 76b5ce45 8800c83fe040 >> 8802149b1b80 >> [ 1440.146134] 8802149c 8800aaca261c 8802149b1b80 >> >> [ 1440.146137] 8800aaca2620 8802149bfa80 81821b15 >> 8800aaca2618 >> [ 1440.146141] Call Trace: >> [ 1440.146152] [] schedule+0x35/0x80 >> [ 1440.146157] [] schedule_preempt_disabled+0xe/0x10 >> [ 1440.146162] [] __mutex_lock_slowpath+0xb9/0x130 >> [ 1440.146167] [] mutex_lock+0x1f/0x30 >> [ 1440.146177] [] imon_disconnect+0x3d/0x110 [lirc_imon] >> [ 1440.146183] [] usb_unbind_interface+0x83/0x260 >> [ 1440.146190] [] __device_release_driver+0xa1/0x150 >> [ 1440.146194] [] device_release_driver+0x23/0x30 >> [ 1440.146197] [] bus_remove_device+0x101/0x170 >> [ 1440.146202] [] device_del+0x139/0x260 >> [ 1440.146207] [] ? usb_remove_ep_devs+0x1f/0x30 >> [ 1440.146212] [] usb_disable_device+0x89/0x270 >> [ 1440.146216] [] usb_disconnect+0x92/0x280 >> [ 1440.146220] [] hub_port_connect+0x82/0x9c0 >> [ 1440.146223] [] hub_event+0x6d1/0xb10 >> [ 1440.146229] [] ? put_prev_entity+0x35/0x7d0 >> [ 1440.146235] [] process_one_work+0x165/0x480 >> [ 1440.146240] [] worker_thread+0x4b/0x4c0 >> [ 1440.146244] [] ? process_one_work+0x480/0x480 >> [ 1440.146248] [] kthread+0xd8/0xf0 >> [ 1440.146252] [] ? kthread_create_on_node+0x1e0/0x1e0 >> [ 1440.146256] [] ret_from_fork+0x3f/0x70 >> [ 1440.146260] [] ? kthread_create_on_node+0x1e0/0x1e0 >> [ 1440.146329] INFO: task colord-sane:4439 blocked for more than 120 seconds. >> [ 1440.146332] Tainted: G C OE 4.4.0-24-generic #43-Ubuntu >> [ 1440.146334] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables >> this message. >> [ 1440.146336] colord-sane D 8801d8123d78 0 4439 1163 >> 0x >> [ 1440.146341] 8801d8123d78 81e11500 >> 8800c83fe040 >> [ 1440.146345] 8801d8124000 8802107b68fc 8800c83fe040 >> >> [ 1440.146349] 8802107b6900 8801d8123d90 81821b15 >> 8802107b68f8 >> [ 1440.146353] Call Trace: >> [ 1440.146358] [] schedule+0x35/0x80 >> [ 1440.146362] [] schedule_preempt_disabled+0xe/0x10 >> [ 1440.146367] [] __mutex_lock_slowpath+0xb9/0x130 >> [ 1440.146371] [] mutex_lock+0x1f/0x30 >> [ 1440.146375] [] read_descriptors+0x37/0x100 >> [ 1440.146382] [] sysfs_kf_bin_read+0x4a/0x70 >> [ 1440.146387] [] kernfs_fop_read+0xab/0x160 >> [ 1440.146393] [] __vfs_read+0x18/0x40 >> [ 1440.146398] [] vfs_read+0x86/0x130 >> [ 1440.146402] [] SyS_read+0x55/0xc0 >> [ 1440.146409] [] entry_SYSCALL_64_fastpath+0x16/0x71 > > Just an idea, can you provide the descriptors that you are using to fuzz > these drivers with? Without that, it's a tough slog through the code to > try to figure out what went wrong... > > thanks, > > greg k-h Sure, I will send the descriptors that I used as a reply to the first mail, as they are all the same (except for
Re: Potential vulnerabilities in USB host stack/drivers
On 08/16/2016 05:51 PM, Greg KH wrote: > On Tue, Aug 16, 2016 at 04:40:43PM +0300, Binyamin Sharet wrote: >> Hi, >> >> We are using Umap2 to scan USB hosts for vendor-specific device support. >> e.g. whether appropriate drivers are loaded when a device with a specific >> VID/PID is inserted. >> >> In our configuration, we connect multiple times to the host, each time >> providing different VID/PID in the device descriptor, and then we provide >> a single configuration with a single interface that has multiple (10) >> endpoints of different types. >> >> Umap2 can be downloaded from https://github.com/nccgroup/umap2, >> and requires either a Facedancer board or a beaglebone black with a >> modified gadgetfs module (source and instructions in umap2 repository) to >> be used. >> >> During this scan we have found multiple issues in the kernel. >> Some issues cause the the USB stack to hang, while others cause an oops. >> Some of the issues seem similar and might originate from the same source, >> however, due to my lack of knowledge in the Linux USB subsystem, I did not >> perform an in-depth analysis of the root causes. >> >> In total, there are 11 issues: 2 hangs, 8 NULL pointer dereference and >> 1 oops caused by kernel unable to handle paging address. >> >> To keep some order, I will send a separate mail for each issue, titled >> '[Umap2][x/11][$VID:$PID] $result'. > Another minor nit, try a leading 0 on your 1-9 emails so they sort > properly :) > > greg k-h Below are the descriptors sent to the host during the scan. It is always the same (for all 11 issues) except for VID/PID. in the device descriptor, is a placeholder for VID (little endian) and is a placeholder for PID. Device descriptor: 12010200ff010140010001020301 1st Configuration descriptor: 09025800010104c032 2nd Configuration descriptor (3 next lines are a single descriptor): 09025800010104c03209040aff01010007058103410705010341070582 02000201070502020002010705830141070503014107058402000201070504 02000201070585011107050502000201 Binyamin Sharet Cisco, STARE-C -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] usb: gadget: f_ncm: add support for scatter/gather SKB to enable GSO
Hello, 16.08.2016, 13:56, Felipe Balbi kirjoitti: > Jussi Kivilinna writes: >>> Jussi Kivilinna writes: Enabling SG allows enabling GSO (generic segmentation offload) feature of linux networking layer. This increases TCP throughput with NCM on Cortex-A15+USB3380 based device from 300 Mbit/s to 1.1 Gbit/s. Signed-off-by: Jussi Kivilinna >>> >>> this is AWESOME!! :-) But here's the thing, any chance we can build this >>> in u_ether.c ? Also, NETIF_F_SG should be conditional on >>> gadget->sg_supported so that we don't break UDCs that don't support >>> sglists. >>> >> >> Actually, no sglists are passed to UDC. Reason why this work >> with minimal changes for NCM is that NCM does tx buffering >> in its wrap function.. 'ncm_wrap_ntb' copies input skbuffs to >> larger skbuff, so enabling SG is only matter of changing that >> skbuff data copy from 'memcpy' to 'skb_copy_bits' (and changing >> CRC calculation work with skbuff fragments). Since NCM already >> does copying, SG can be enabled for NCM without extra overhead. > > aha, understood. Now what if we skip copying altogether? If we have an > sg and a UDC that supports sg (gadget->sg_supported = 1), then we can > avoid copying, right? Skip copying might difficult for NCM because buffering, but might work for other networking gadgets. > >> To see if NETIF_F_SG with skbuff copying made difference with >> other networking gadgets, I made quick test for RNDIS gadget to >> enable NETIF_F_SG by adding skb_linearize_cow call to >> 'rndis_add_header' wrap function. TCP transfer from device to >> host: >> without SG: 265 Mbit/s >> with SG:326 Mbit/s >> >> So, adding NETIF_F_SG with skbuff linearization in u_ether >> could improve performance little bit. > > interesting. Does USB3380 support sglists? We could check how much more > we get if we skip copying altogether. SG support net2280.c does not appear to be complete, for example PIO-mode 'write_fifo' accesses (struct usb_request).buf directly. Data book reads that USB3380 has Scatter/Gather DMA mode support. However errata list has two "DMA channel may hang under specific conditions" problems for rev.AA with workaround: use single DMA mode instead. -Jussi -- 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: [Umap2][9/11][05c5:0002] NULL pointer dereference
On 08/16/2016 06:04 PM, Johan Hovold wrote:
> On Tue, Aug 16, 2016 at 10:47:44AM -0400, Alan Stern wrote:
>> On Tue, 16 Aug 2016, Binyamin Sharet wrote:
>>
>>> Kernel version: raspberrypi 4.4.6-v7+ #871
>>> Driver source file: drivers/usb/serial/digi_acceleport.c
>>> Umap2 command line: umap2vsscan -P -s 05c5:0002
>>>
>>> After connecting such a device, NULL pointer dereference in the kernel.
>>>
>>> Binyamin Sharet
>>> Cisco, STARE-C
>>>
>>> << Attached: 05c5_0002_dmesg.log >>
>> This looks like a bug in the digi_acceleport driver. digi_startup()
>> does this:
>>
>> serial_priv->ds_oob_port_num = serial->type->num_ports;
>> serial_priv->ds_oob_port = serial->port[serial_priv->ds_oob_port_num];
>>
>> Even without knowing exactly what this is supposed to be doing, one
>> gets the definite impression that the first line should be:
>>
>> serial_priv->ds_oob_port_num = serial->type->num_ports - 1;
>>
>> Johan?
> The out-of-band port is not included in num_ports so that should not be
> the issue here. The missing sanity checks for the endpoint layout were
> only recently added by
>
> 5a07975ad0a3 ("USB: digi_acceleport: do sanity checking for the
> number of ports")
>
> however, even if it has been included in 4.4-stable since 4.4.7.
>
> Binyamin, could you rerun your tests on the latest 4.4-stable kernel to
> make sure you're not reporting already fixed issues?
>
> Thanks,
> Johan
I will do that, but it will take some time. I'm setting up a machine
to use with an up to date kernel.
Binyamin Sharet
Cisco, STARE-C
--
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 1/8] usb: ulpi: move setting of ulpi->dev parent up in ulpi_register()
Once ulpi operations use the parent device directly, this will be
needed during the operations used in ulpi_register() itself, so set
the parent field before calling any ulpi operations.
Signed-off-by: Tal Shorer
---
drivers/usb/common/ulpi.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/common/ulpi.c b/drivers/usb/common/ulpi.c
index e04a34e..c6ce92b 100644
--- a/drivers/usb/common/ulpi.c
+++ b/drivers/usb/common/ulpi.c
@@ -157,6 +157,8 @@ static int ulpi_register(struct device *dev, struct ulpi
*ulpi)
{
int ret;
+ ulpi->dev.parent = dev; /* needed early for ops */
+
/* Test the interface */
ret = ulpi_write(ulpi, ULPI_SCRATCH, 0xaa);
if (ret < 0)
@@ -175,7 +177,6 @@ static int ulpi_register(struct device *dev, struct ulpi
*ulpi)
ulpi->id.product = ulpi_read(ulpi, ULPI_PRODUCT_ID_LOW);
ulpi->id.product |= ulpi_read(ulpi, ULPI_PRODUCT_ID_HIGH) << 8;
- ulpi->dev.parent = dev;
ulpi->dev.bus = &ulpi_bus;
ulpi->dev.type = &ulpi_dev_type;
dev_set_name(&ulpi->dev, "%s.ulpi", dev_name(dev));
--
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 v3 6/8] usb: ulpi: remove "dev" field from struct ulpi_ops
Operations now use ulpi->dev.parent directly instead of via the
ulpi_ops struct, making this field unused. Remove it.
Signed-off-by: Tal Shorer
---
drivers/usb/common/ulpi.c | 1 -
include/linux/ulpi/interface.h | 3 +--
2 files changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/usb/common/ulpi.c b/drivers/usb/common/ulpi.c
index da17a74..d005c15 100644
--- a/drivers/usb/common/ulpi.c
+++ b/drivers/usb/common/ulpi.c
@@ -213,7 +213,6 @@ struct ulpi *ulpi_register_interface(struct device *dev,
struct ulpi_ops *ops)
return ERR_PTR(-ENOMEM);
ulpi->ops = ops;
- ops->dev = dev;
ret = ulpi_register(dev, ulpi);
if (ret) {
diff --git a/include/linux/ulpi/interface.h b/include/linux/ulpi/interface.h
index ac3cd80..cdedac8 100644
--- a/include/linux/ulpi/interface.h
+++ b/include/linux/ulpi/interface.h
@@ -4,15 +4,14 @@
#include
struct ulpi;
+struct device;
/**
* struct ulpi_ops - ULPI register access
- * @dev: the interface provider
* @read: read operation for ULPI register access
* @write: write operation for ULPI register access
*/
struct ulpi_ops {
- struct device *dev;
int (*read)(struct device *dev, u8 addr);
int (*write)(struct device *dev, u8 addr, u8 val);
};
--
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 v3 7/8] usb: ulpi: make ops struct constant
None of the core ulpi functions perform any changes to the operations
struct, and logically as a struct that contains function pointers
there's no reason it shouldn't be constant.
Signed-off-by: Tal Shorer
---
drivers/usb/common/ulpi.c | 3 ++-
include/linux/ulpi/driver.h| 2 +-
include/linux/ulpi/interface.h | 2 +-
3 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/common/ulpi.c b/drivers/usb/common/ulpi.c
index d005c15..8b31770 100644
--- a/drivers/usb/common/ulpi.c
+++ b/drivers/usb/common/ulpi.c
@@ -203,7 +203,8 @@ static int ulpi_register(struct device *dev, struct ulpi
*ulpi)
* Allocates and registers a ULPI device and an interface for it. Called from
* the USB controller that provides the ULPI interface.
*/
-struct ulpi *ulpi_register_interface(struct device *dev, struct ulpi_ops *ops)
+struct ulpi *ulpi_register_interface(struct device *dev,
+const struct ulpi_ops *ops)
{
struct ulpi *ulpi;
int ret;
diff --git a/include/linux/ulpi/driver.h b/include/linux/ulpi/driver.h
index 80b36ca..a7af21a 100644
--- a/include/linux/ulpi/driver.h
+++ b/include/linux/ulpi/driver.h
@@ -15,7 +15,7 @@ struct ulpi_ops;
*/
struct ulpi {
struct ulpi_device_id id;
- struct ulpi_ops *ops;
+ const struct ulpi_ops *ops;
struct device dev;
};
diff --git a/include/linux/ulpi/interface.h b/include/linux/ulpi/interface.h
index cdedac8..a2011a9 100644
--- a/include/linux/ulpi/interface.h
+++ b/include/linux/ulpi/interface.h
@@ -16,7 +16,7 @@ struct ulpi_ops {
int (*write)(struct device *dev, u8 addr, u8 val);
};
-struct ulpi *ulpi_register_interface(struct device *, struct ulpi_ops *);
+struct ulpi *ulpi_register_interface(struct device *, const struct ulpi_ops *);
void ulpi_unregister_interface(struct ulpi *);
#endif /* __LINUX_ULPI_INTERFACE_H */
--
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 v3 5/8] usb: ulpi: rename operations {read|write}_dev to simply {read|write}
With the removal of the old {read|write} operations, we can now safely
rename the new api operations {read|write}_dev to use the shorter and
clearer names {read|write}, respectively.
Signed-off-by: Tal Shorer
---
drivers/usb/common/ulpi.c | 4 ++--
drivers/usb/dwc3/ulpi.c| 4 ++--
include/linux/ulpi/interface.h | 4 ++--
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/common/ulpi.c b/drivers/usb/common/ulpi.c
index d682cf2..da17a74 100644
--- a/drivers/usb/common/ulpi.c
+++ b/drivers/usb/common/ulpi.c
@@ -21,13 +21,13 @@
int ulpi_read(struct ulpi *ulpi, u8 addr)
{
- return ulpi->ops->read_dev(ulpi->dev.parent, addr);
+ return ulpi->ops->read(ulpi->dev.parent, addr);
}
EXPORT_SYMBOL_GPL(ulpi_read);
int ulpi_write(struct ulpi *ulpi, u8 addr, u8 val)
{
- return ulpi->ops->write_dev(ulpi->dev.parent, addr, val);
+ return ulpi->ops->write(ulpi->dev.parent, addr, val);
}
EXPORT_SYMBOL_GPL(ulpi_write);
diff --git a/drivers/usb/dwc3/ulpi.c b/drivers/usb/dwc3/ulpi.c
index 94eeb7a..51ac939 100644
--- a/drivers/usb/dwc3/ulpi.c
+++ b/drivers/usb/dwc3/ulpi.c
@@ -66,8 +66,8 @@ static int dwc3_ulpi_write(struct device *dev, u8 addr, u8
val)
}
static struct ulpi_ops dwc3_ulpi_ops = {
- .read_dev = dwc3_ulpi_read,
- .write_dev = dwc3_ulpi_write,
+ .read = dwc3_ulpi_read,
+ .write = dwc3_ulpi_write,
};
int dwc3_ulpi_init(struct dwc3 *dwc)
diff --git a/include/linux/ulpi/interface.h b/include/linux/ulpi/interface.h
index 71f3c99..ac3cd80 100644
--- a/include/linux/ulpi/interface.h
+++ b/include/linux/ulpi/interface.h
@@ -13,8 +13,8 @@ struct ulpi;
*/
struct ulpi_ops {
struct device *dev;
- int (*read_dev)(struct device *dev, u8 addr);
- int (*write_dev)(struct device *dev, u8 addr, u8 val);
+ int (*read)(struct device *dev, u8 addr);
+ int (*write)(struct device *dev, u8 addr, u8 val);
};
struct ulpi *ulpi_register_interface(struct device *, struct ulpi_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
[PATCH v3 4/8] usb: ulpi: remove calls to old api callbacks
Now that all users use the new api callbacks, remove the old api
callbacks and force new interface drivers to use the new api.
Signed-off-by: Tal Shorer
---
drivers/usb/common/ulpi.c | 4
include/linux/ulpi/interface.h | 2 --
2 files changed, 6 deletions(-)
diff --git a/drivers/usb/common/ulpi.c b/drivers/usb/common/ulpi.c
index 15e4a14..d682cf2 100644
--- a/drivers/usb/common/ulpi.c
+++ b/drivers/usb/common/ulpi.c
@@ -21,16 +21,12 @@
int ulpi_read(struct ulpi *ulpi, u8 addr)
{
- if (!ulpi->ops->read_dev)
- return ulpi->ops->read(ulpi->ops, addr);
return ulpi->ops->read_dev(ulpi->dev.parent, addr);
}
EXPORT_SYMBOL_GPL(ulpi_read);
int ulpi_write(struct ulpi *ulpi, u8 addr, u8 val)
{
- if (!ulpi->ops->write_dev)
- return ulpi->ops->write(ulpi->ops, addr, val);
return ulpi->ops->write_dev(ulpi->dev.parent, addr, val);
}
EXPORT_SYMBOL_GPL(ulpi_write);
diff --git a/include/linux/ulpi/interface.h b/include/linux/ulpi/interface.h
index d8189d0..71f3c99 100644
--- a/include/linux/ulpi/interface.h
+++ b/include/linux/ulpi/interface.h
@@ -13,8 +13,6 @@ struct ulpi;
*/
struct ulpi_ops {
struct device *dev;
- int (*read)(struct ulpi_ops *ops, u8 addr);
- int (*write)(struct ulpi_ops *ops, u8 addr, u8 val);
int (*read_dev)(struct device *dev, u8 addr);
int (*write_dev)(struct device *dev, u8 addr, u8 val);
};
--
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 v3 8/8] usb: dwc3: ulpi: make dwc3_ulpi_ops constant
ulpi_register_interface() accepts a const struct ulpi_ops and dwc3
doesn't perform any changes to this struct at runtime, so there's no
reason it shouldn't be constant.
Signed-off-by: Tal Shorer
---
drivers/usb/dwc3/ulpi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/dwc3/ulpi.c b/drivers/usb/dwc3/ulpi.c
index 51ac939..bd86f84 100644
--- a/drivers/usb/dwc3/ulpi.c
+++ b/drivers/usb/dwc3/ulpi.c
@@ -65,7 +65,7 @@ static int dwc3_ulpi_write(struct device *dev, u8 addr, u8
val)
return dwc3_ulpi_busyloop(dwc);
}
-static struct ulpi_ops dwc3_ulpi_ops = {
+static const struct ulpi_ops dwc3_ulpi_ops = {
.read = dwc3_ulpi_read,
.write = dwc3_ulpi_write,
};
--
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 v3 3/8] usb: dwc3: ulpi: use new api
The old read, write callbacks in struct ulpi_ops have been deprecated
in favor of new callbacks that pass the parent device directly.
Replace the used callbacks in dwc3's ulpi component with the new api.
Signed-off-by: Tal Shorer
---
drivers/usb/dwc3/ulpi.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/dwc3/ulpi.c b/drivers/usb/dwc3/ulpi.c
index ec004c6..94eeb7a 100644
--- a/drivers/usb/dwc3/ulpi.c
+++ b/drivers/usb/dwc3/ulpi.c
@@ -35,9 +35,9 @@ static int dwc3_ulpi_busyloop(struct dwc3 *dwc)
return -ETIMEDOUT;
}
-static int dwc3_ulpi_read(struct ulpi_ops *ops, u8 addr)
+static int dwc3_ulpi_read(struct device *dev, u8 addr)
{
- struct dwc3 *dwc = dev_get_drvdata(ops->dev);
+ struct dwc3 *dwc = dev_get_drvdata(dev);
u32 reg;
int ret;
@@ -53,9 +53,9 @@ static int dwc3_ulpi_read(struct ulpi_ops *ops, u8 addr)
return DWC3_GUSB2PHYACC_DATA(reg);
}
-static int dwc3_ulpi_write(struct ulpi_ops *ops, u8 addr, u8 val)
+static int dwc3_ulpi_write(struct device *dev, u8 addr, u8 val)
{
- struct dwc3 *dwc = dev_get_drvdata(ops->dev);
+ struct dwc3 *dwc = dev_get_drvdata(dev);
u32 reg;
reg = DWC3_GUSB2PHYACC_NEWREGREQ | DWC3_ULPI_ADDR(addr);
@@ -66,8 +66,8 @@ static int dwc3_ulpi_write(struct ulpi_ops *ops, u8 addr, u8
val)
}
static struct ulpi_ops dwc3_ulpi_ops = {
- .read = dwc3_ulpi_read,
- .write = dwc3_ulpi_write,
+ .read_dev = dwc3_ulpi_read,
+ .write_dev = dwc3_ulpi_write,
};
int dwc3_ulpi_init(struct dwc3 *dwc)
--
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 v3 0/8] usb: ulpi: remove "dev" field from struct ulpi_ops
struct ulpi_ops is defined as follows:
struct ulpi_ops {
struct device *dev;
int (*read)(struct ulpi_ops *ops, u8 addr);
int (*write)(struct ulpi_ops *ops, u8 addr, u8 val);
};
Upon calling ulpi_register_interface(), the struct device argument is
put inside the struct ulpi_ops argument's dev field. Later, when
calling the actual read()/write() operations, the struct ulpi_ops is
passed to them and they use the stored device to access whatever
private data they need.
This means that if one wishes to reuse the same oprations for multiple
interfaces (e.g if we have multiple instances of the same controller),
any but the last interface registered will not operate properly (and
the one that does work will be at the mercy of the others to not mess
it up).
I understand that barely any driver uses this bus right now, but I
suppose it's there to be used at some point. We might as well fix the
design here before we hit this bug.
This series fixes this by passing the given struct device directly to
the operation functions via ulpi->dev.parent in ulpi_read() and
ulpi_write(). It also changes the operations struct to be constant
since now nobody has a reason to modify it.
Changes from v1:
* Split the actual api change into multiple patch as per Felipe Balbi's
suggestion. The series now first adds the new api, then migrates
everything to use and only then removes the old api.
Changes from v2:
* Merge patches 2 and 3 (now patch 2)
* Merge patches 5 and 6 (now patch 4)
* Remove comment documenting the removed dev field in struct ulpi_ops
Tal Shorer (8):
usb: ulpi: move setting of ulpi->dev parent up in ulpi_register()
usb: ulpi: add new api functions, {read|write}_dev()
usb: dwc3: ulpi: use new api
usb: ulpi: remove calls to old api callbacks
usb: ulpi: rename operations {read|write}_dev to simply {read|write}
usb: ulpi: remove "dev" field from struct ulpi_ops
usb: ulpi: make ops struct constant
usb: dwc3: ulpi: make dwc3_ulpi_ops constant
drivers/usb/common/ulpi.c | 11 ++-
drivers/usb/dwc3/ulpi.c| 10 +-
include/linux/ulpi/driver.h| 2 +-
include/linux/ulpi/interface.h | 9 -
4 files changed, 16 insertions(+), 16 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 v3 2/8] usb: ulpi: add new api functions, {read|write}_dev()
Add these two new api callbacks to struct ulpi_ops. These are different
than read, write in that they pass the parent device directly instead
of via the ops argument.
They are intended to replace the old api functions.
If the new api callbacks are missing, revert to calling the old ones
as before.
Signed-off-by: Tal Shorer
---
drivers/usb/common/ulpi.c | 8 ++--
include/linux/ulpi/interface.h | 2 ++
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/common/ulpi.c b/drivers/usb/common/ulpi.c
index c6ce92b..15e4a14 100644
--- a/drivers/usb/common/ulpi.c
+++ b/drivers/usb/common/ulpi.c
@@ -21,13 +21,17 @@
int ulpi_read(struct ulpi *ulpi, u8 addr)
{
- return ulpi->ops->read(ulpi->ops, addr);
+ if (!ulpi->ops->read_dev)
+ return ulpi->ops->read(ulpi->ops, addr);
+ return ulpi->ops->read_dev(ulpi->dev.parent, addr);
}
EXPORT_SYMBOL_GPL(ulpi_read);
int ulpi_write(struct ulpi *ulpi, u8 addr, u8 val)
{
- return ulpi->ops->write(ulpi->ops, addr, val);
+ if (!ulpi->ops->write_dev)
+ return ulpi->ops->write(ulpi->ops, addr, val);
+ return ulpi->ops->write_dev(ulpi->dev.parent, addr, val);
}
EXPORT_SYMBOL_GPL(ulpi_write);
diff --git a/include/linux/ulpi/interface.h b/include/linux/ulpi/interface.h
index 4de8ab4..d8189d0 100644
--- a/include/linux/ulpi/interface.h
+++ b/include/linux/ulpi/interface.h
@@ -15,6 +15,8 @@ struct ulpi_ops {
struct device *dev;
int (*read)(struct ulpi_ops *ops, u8 addr);
int (*write)(struct ulpi_ops *ops, u8 addr, u8 val);
+ int (*read_dev)(struct device *dev, u8 addr);
+ int (*write_dev)(struct device *dev, u8 addr, u8 val);
};
struct ulpi *ulpi_register_interface(struct device *, struct ulpi_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 V2 RFC 1/6] usb: dwc2: core: Avoid nonsense error in gadget mode
John Youn writes: > On 7/26/2016 11:54 AM, Stefan Wahren wrote: >> In gadget mode On bcm2835 platform the host tx fifo size could be zero. >> So add zero to range and avoid such nonsense errors: >> >> dwc2 2098.usb: 0 invalid for host_nperio_tx_fifo_size. >> dwc2 2098.usb: Setting host_nperio_tx_fifo_size to 0 >> dwc2 2098.usb: 0 invalid for host_perio_tx_fifo_size. >> dwc2 2098.usb: Setting host_perio_tx_fifo_size to 0 > > Hi Stefan, > > Are those the power on reset values of GNPTXFSIZ and HPTXFSIZ? > > If these values can be 0, I think the patch is ok. But I'm not sure > about that. I can check with some hardware engineers to see under what > conditions this is possible. FWIW, I don't see the firmware software doing any conditional setting of these registers. signature.asc Description: PGP signature
Re: [PATCH] phy: rockchip-inno-usb2: add COMMON_CLK dependency
On Tue, Aug 16, 2016 at 02:02:00PM +0800, Frank Wang wrote: > On kernel builds without COMMON_CLK, the newly added rockchip-inno-usb2 > driver fails to build: > > drivers/phy/phy-rockchip-inno-usb2.c:124:16: error: field 'clk480m_hw' > has incomplete type >struct clk_hw clk480m_hw; > > In file included from include/linux/clk.h:16:0 > from drivers/phy/phy-rockchip-inno-usb2.c:17: > include/linux/kernel.h:831:48: error: initialization from incompatible > pointer type [-Werror=incompatible-pointer-types] >const typeof( ((type *)0)->member ) *__mptr = (ptr); \ > > ... ... > > Signed-off-by: Frank Wang > --- > drivers/phy/Kconfig |1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig > index f9bf981..c6d57e5 100644 > --- a/drivers/phy/Kconfig > +++ b/drivers/phy/Kconfig > @@ -370,6 +370,7 @@ config PHY_ROCKCHIP_USB > config PHY_ROCKCHIP_INNO_USB2 > tristate "Rockchip INNO USB2PHY Driver" > depends on (ARCH_ROCKCHIP || COMPILE_TEST) && OF > + depends on COMMON_CLK Wonder what is preferred here. I find 33 "select COMMON_CLK" and 18 "depends on COMMON_CLK". Either case Reviewed-by: Guenter Roeck > select GENERIC_PHY > help > Support for Rockchip USB2.0 PHY with Innosilicon IP block. > -- > 1.7.9.5 > > -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv4 0/2] USB Type-C Connector class
On Tue, Aug 16, 2016 at 10:38:26AM +0300, Heikki Krogerus wrote: > Hi guys, > > Sorry for the long silence. I just returned from paternal leave. > > On Wed, Aug 10, 2016 at 10:19:25AM +0200, Oliver Neukum wrote: > > On Tue, 2016-08-09 at 09:23 -0700, Guenter Roeck wrote: > > > > I'm not going to take this series until everyone agrees on it, > > > sorry. > > > > I'll wait for you and Guenter and Oliver to all come up with a > > > solution > > > > that works for everyone. > > > > > > > > > > I have not heard from Heikko for a while. There have been some > > > follow-up > > > patches in > > > > > > https://git.kernel.org/cgit/linux/kernel/git/balbi/usb.git/log/?h=bxt-typec-pd-fixes > > > > > > but I am not really sure where this is going. I've been wondering if I > > > can/should get more actively involved and start driving the series if > > > Heikki is busy. Thoughts, anyone ? > > > > It is not clear to me where we were. It seems to me that we found > > the API good but disagreed about locking. Does that sum it up? > > I'll remove the locks and resend. > I have a new version of my patch set ready. Should I wait for your update or send it now ? Thanks, 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 v4 1/2] mfd: ti-smusbdig: Add support for the TI SM-USB-DIG
On 08/09/2016 10:27 AM, Lee Jones wrote: > On Tue, 09 Aug 2016, Andrew F. Davis wrote: > >> The TI SM-USB-DIG is a USB to SPI/I2C/1Wire/GPIO adapter. >> Add MFD core support. >> >> Signed-off-by: Andrew F. Davis >> --- >> drivers/mfd/Kconfig | 9 +++ >> drivers/mfd/Makefile| 2 + >> drivers/mfd/ti-smusbdig.c | 138 >> >> include/linux/mfd/ti-smusbdig.h | 75 ++ >> 4 files changed, 224 insertions(+) >> create mode 100644 drivers/mfd/ti-smusbdig.c >> create mode 100644 include/linux/mfd/ti-smusbdig.h > > Still requires a DT Ack. > > Please ping the relevant guys. > This driver doesn't touch DT. If you meant USB, could you give me a hint as to who needs to ack drivers that communicate over USB? -- 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 RFC 1/6] usb: dwc2: core: Avoid nonsense error in gadget mode
Hi John, > John Youn hat am 16. August 2016 um 03:30 > geschrieben: > > > On 7/26/2016 11:54 AM, Stefan Wahren wrote: > > In gadget mode On bcm2835 platform the host tx fifo size could be zero. > > So add zero to range and avoid such nonsense errors: > > > > dwc2 2098.usb: 0 invalid for host_nperio_tx_fifo_size. > > dwc2 2098.usb: Setting host_nperio_tx_fifo_size to 0 > > dwc2 2098.usb: 0 invalid for host_perio_tx_fifo_size. > > dwc2 2098.usb: Setting host_perio_tx_fifo_size to 0 > > Hi Stefan, > > Are those the power on reset values of GNPTXFSIZ and HPTXFSIZ? > > If these values can be 0, I think the patch is ok. But I'm not sure > about that. I can check with some hardware engineers to see under what > conditions this is possible. i'm not sure that i can answer your question correctly. Let me send you some logs and i hope these answer your question. Since the Raspberry Pi Zero with bcm2835 could handle all three dr_mode set in DT ( otg, host, peripherial ), i made 3 logs before this patch is applied: Raspberry Pi Zero dr_mode = "host" Linux raspberrypi 4.7.0-rc7-next-20160719+ #3 Thu Jul 21 17:12:23 UTC 2016 armv6l GNU/Linux [2.300866] dwc2_lowlevel_hw_init() [2.317961] dwc2 2098.usb: dwc2: cannot get otg clock [2.327328] dwc2_lowlevel_hw_enable() [2.334868] dwc2_get_dr_mode() [2.341742] dwc2 2098.usb: Forcing mode to host [2.459227] dwc2_get_hwparams() [2.466013] dwc2 2098.usb: Core Release: 2.80a (snpsid=4f54280a) [2.466028] dwc2 2098.usb: hwcfg1= [2.466040] dwc2 2098.usb: hwcfg2=228ddd50 [2.466051] dwc2 2098.usb: hwcfg3=0ff000e8 [2.466061] dwc2 2098.usb: hwcfg4=1ff00020 [2.466071] dwc2 2098.usb: grxfsiz=1000 [2.466083] dwc2 2098.usb: gnptxfsiz=01001000 [2.466093] dwc2 2098.usb: hptxfsiz=02002000 [2.466106] dwc2 2098.usb: Detected values from hardware: [2.466116] dwc2 2098.usb: op_mode=0 [2.466126] dwc2 2098.usb: arch=2 [2.466136] dwc2 2098.usb: dma_desc_enable=0 [2.466146] dwc2 2098.usb: power_optimized=0 [2.466156] dwc2 2098.usb: i2c_enable=0 [2.466165] dwc2 2098.usb: hs_phy_type=1 [2.466175] dwc2 2098.usb: fs_phy_type=1 [2.466185] dwc2 2098.usb: utmi_phy_data_width=0 [2.466194] dwc2 2098.usb: num_dev_ep=7 [2.466204] dwc2 2098.usb: num_dev_perio_in_ep=0 [2.466213] dwc2 2098.usb: host_channels=8 [2.466223] dwc2 2098.usb: max_transfer_size=524287 [2.466233] dwc2 2098.usb: max_packet_count=1023 [2.466243] dwc2 2098.usb: nperio_tx_q_depth=0x4 [2.466253] dwc2 2098.usb: host_perio_tx_q_depth=0x4 [2.466263] dwc2 2098.usb: dev_token_q_depth=0x8 [2.466273] dwc2 2098.usb: enable_dynamic_fifo=1 [2.466283] dwc2 2098.usb: en_multiple_tx_fifo=1 [2.466293] dwc2 2098.usb: total_fifo_size=4080 [2.466303] dwc2 2098.usb: host_rx_fifo_size=4096 [2.466314] dwc2 2098.usb: host_nperio_tx_fifo_size=256 [2.466324] dwc2 2098.usb: host_perio_tx_fifo_size=512 [2.466332] dwc2 2098.usb: [2.466342] dwc2 2098.usb: dwc2_set_parameters() [2.466356] dwc2 2098.usb: Setting dma_desc_fs_enable to 0 [2.466384] dwc2 2098.usb: Setting external_id_pin_ctl to 0 [2.466395] dwc2 2098.usb: Setting hibernation to 0 [2.466399] dwc2_force_dr_mode() [2.473127] dwc2 2098.usb: Forcing mode to host [2.589175] dwc2_hcd_init() [2.595685] dwc2 2098.usb: DWC OTG Controller [2.604051] dwc2 2098.usb: new USB bus registered, assigned bus number 1 [2.614688] dwc2 2098.usb: irq 33, io mem 0x Raspberry Pi Zero dr_mode = "otg" Linux raspberrypi 4.7.0-rc7-next-20160719+ #3 Thu Jul 21 17:12:23 UTC 2016 armv6l GNU/Linux [2.310924] dwc2_lowlevel_hw_init() [2.328029] dwc2 2098.usb: dwc2: cannot get otg clock [2.337385] dwc2_lowlevel_hw_enable() [2.344917] dwc2_get_dr_mode() [2.469263] dwc2_get_hwparams() [2.476042] dwc2 2098.usb: Core Release: 2.80a (snpsid=4f54280a) [2.476059] dwc2 2098.usb: hwcfg1= [2.476072] dwc2 2098.usb: hwcfg2=228ddd50 [2.476082] dwc2 2098.usb: hwcfg3=0ff000e8 [2.476093] dwc2 2098.usb: hwcfg4=1ff00020 [2.476104] dwc2 2098.usb: grxfsiz=1000 [2.476115] dwc2 2098.usb: Forcing mode to host [2.519251] dwc2 2098.usb: gnptxfsiz=00201000 [2.519267] dwc2 2098.usb: hptxfsiz= [2.569237] dwc2 2098.usb: gnptxfsiz=00201000 [2.569255] dwc2 2098.usb: Detected values from hardware: [2.569266] dwc2 2098.usb: op_mode=0 [2.569276] dwc2 2098.usb: arch=2 [2.569286] dwc2 2098.usb: dma_desc_enable=0 [2.569296] dwc2 2098.usb: power_optimized=0 [2.569306] dwc2 2098.us
Re: [PATCH v2 2/3] usb: gadget: f_uac2: split out audio core
Hi Ruslan, [auto build test ERROR on balbi-usb/next] [also build test ERROR on v4.8-rc2 next-20160816] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Ruslan-Bilovol/USB-Audio-Gadget-refactoring/20160814-185318 base: https://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git next config: x86_64-randconfig-a0-08162223 (attached as .config) compiler: gcc-4.4 (Debian 4.4.7-8) 4.4.7 reproduce: # save the attached .config to linux build tree make ARCH=x86_64 All errors (new ones prefixed by >>): drivers/usb/gadget/function/usb_f_uac1.o: In function `gaudio_setup': >> (.text+0x16ce): multiple definition of `gaudio_setup' drivers/usb/gadget/function/u_audio.o:u_audio.c:(.text+0x937): first defined here drivers/usb/gadget/function/usb_f_uac1.o: In function `gaudio_cleanup': >> (.text+0x1147): multiple definition of `gaudio_cleanup' drivers/usb/gadget/function/u_audio.o:u_audio.c:(.text+0x3f): first defined here --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: Binary data
Re: [PATCH V2 RFC 1/6] usb: dwc2: core: Avoid nonsense error in gadget mode
On 8/16/2016 9:44 AM, Stefan Wahren wrote: > Hi John, > >> John Youn hat am 16. August 2016 um 03:30 >> geschrieben: >> >> >> On 7/26/2016 11:54 AM, Stefan Wahren wrote: >>> In gadget mode On bcm2835 platform the host tx fifo size could be zero. >>> So add zero to range and avoid such nonsense errors: >>> >>> dwc2 2098.usb: 0 invalid for host_nperio_tx_fifo_size. >>> dwc2 2098.usb: Setting host_nperio_tx_fifo_size to 0 >>> dwc2 2098.usb: 0 invalid for host_perio_tx_fifo_size. >>> dwc2 2098.usb: Setting host_perio_tx_fifo_size to 0 >> >> Hi Stefan, >> >> Are those the power on reset values of GNPTXFSIZ and HPTXFSIZ? >> >> If these values can be 0, I think the patch is ok. But I'm not sure >> about that. I can check with some hardware engineers to see under what >> conditions this is possible. > > i'm not sure that i can answer your question correctly. Let me send you some > logs and i hope these answer your question. > > Since the Raspberry Pi Zero with bcm2835 could handle all three dr_mode set in > DT ( otg, host, peripherial ), i made 3 logs before this patch is applied: > ... > > Raspberry Pi Zero > dr_mode = "peripheral" > > Linux raspberrypi 4.7.0-rc7-next-20160719+ #3 Thu Jul 21 17:12:23 UTC 2016 > armv6l GNU/Linux > > [2.310942] dwc2_lowlevel_hw_init() > [2.328044] dwc2 2098.usb: dwc2: cannot get otg clock > [2.337405] dwc2_lowlevel_hw_enable() > [2.344937] dwc2_get_dr_mode() > [2.351820] dwc2 2098.usb: Forcing mode to device > [2.469267] dwc2_get_hwparams() > [2.476052] dwc2 2098.usb: Core Release: 2.80a (snpsid=4f54280a) > [2.476067] dwc2 2098.usb: hwcfg1= > [2.476078] dwc2 2098.usb: hwcfg2=228ddd50 > [2.476089] dwc2 2098.usb: hwcfg3=0ff000e8 > [2.476100] dwc2 2098.usb: hwcfg4=1ff00020 > [2.476110] dwc2 2098.usb: grxfsiz=1000 > [2.476123] dwc2 2098.usb: gnptxfsiz=00201000 > [2.476135] dwc2 2098.usb: Detected values from hardware: > [2.476146] dwc2 2098.usb: op_mode=0 > [2.476156] dwc2 2098.usb: arch=2 > [2.476166] dwc2 2098.usb: dma_desc_enable=0 > [2.476176] dwc2 2098.usb: power_optimized=0 > [2.476186] dwc2 2098.usb: i2c_enable=0 > [2.476196] dwc2 2098.usb: hs_phy_type=1 > [2.476206] dwc2 2098.usb: fs_phy_type=1 > [2.476216] dwc2 2098.usb: utmi_phy_data_width=0 > [2.476225] dwc2 2098.usb: num_dev_ep=7 > [2.476235] dwc2 2098.usb: num_dev_perio_in_ep=0 > [2.476245] dwc2 2098.usb: host_channels=8 > [2.476256] dwc2 2098.usb: max_transfer_size=524287 > [2.476266] dwc2 2098.usb: max_packet_count=1023 > [2.476277] dwc2 2098.usb: nperio_tx_q_depth=0x4 > [2.476288] dwc2 2098.usb: host_perio_tx_q_depth=0x4 > [2.476297] dwc2 2098.usb: dev_token_q_depth=0x8 > [2.476308] dwc2 2098.usb: enable_dynamic_fifo=1 > [2.476318] dwc2 2098.usb: en_multiple_tx_fifo=1 > [2.476328] dwc2 2098.usb: total_fifo_size=4080 > [2.476338] dwc2 2098.usb: host_rx_fifo_size=4096 > [2.476349] dwc2 2098.usb: host_nperio_tx_fifo_size=0 > [2.476359] dwc2 2098.usb: host_perio_tx_fifo_size=0 > [2.476368] dwc2 2098.usb: > [2.476378] dwc2 2098.usb: dwc2_set_parameters() > [2.476391] dwc2 2098.usb: Setting dma_desc_fs_enable to 0 > [2.476418] dwc2 2098.usb: Setting external_id_pin_ctl to 0 > [2.476429] dwc2 2098.usb: Setting hibernation to 0 > [2.476449] dwc2 2098.usb: 0 invalid for host_rx_fifo_size. Check HW > configuration. > [2.491704] dwc2 2098.usb: Setting host_rx_fifo_size to 4096 > [2.491727] dwc2 2098.usb: 0 invalid for host_nperio_tx_fifo_size. > Check > HW configuration. > [2.507853] dwc2 2098.usb: Setting host_nperio_tx_fifo_size to 0 > [2.507875] dwc2 2098.usb: 0 invalid for host_perio_tx_fifo_size. Check > HW configuration. > [2.524246] dwc2 2098.usb: Setting host_perio_tx_fifo_size to 0 Thanks for the logs. It looks like if dr_mode == peripheral, dwc2 doesn't populate the following host-only values from the reset values of the registers. * hw_params->host_nperio_tx_fifo_size * hw_params->host_perio_tx_fifo_size Thus when it goes to set the core_params based on the hw_params you get the error. As peripheral-only, they are never used so it's fine. To get rid of the error we can skip setting the host-only parameters if dr_mode == peripheral. 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 RFC 6/6] ARM: dts: bcm2835: Add Raspberry Pi Zero
On 7/26/2016 11:54 AM, Stefan Wahren wrote:
> The Raspberry Pi Zero is a minified version of model A+. It's
> notable there is no PWR LED and the ACT LED is inverted.
>
> Signed-off-by: Stefan Wahren
> ---
> arch/arm/boot/dts/Makefile |3 +-
> arch/arm/boot/dts/bcm2835-rpi-zero.dts | 57
>
> 2 files changed, 59 insertions(+), 1 deletion(-)
> create mode 100644 arch/arm/boot/dts/bcm2835-rpi-zero.dts
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index e38e7c9..cafa3b1 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -69,7 +69,8 @@ dtb-$(CONFIG_ARCH_BCM2835) += \
> bcm2835-rpi-b-rev2.dtb \
> bcm2835-rpi-b-plus.dtb \
> bcm2835-rpi-a-plus.dtb \
> - bcm2836-rpi-2-b.dtb
> + bcm2836-rpi-2-b.dtb \
> + bcm2835-rpi-zero.dtb
> dtb-$(CONFIG_ARCH_BCM_5301X) += \
> bcm4708-asus-rt-ac56u.dtb \
> bcm4708-asus-rt-ac68u.dtb \
> diff --git a/arch/arm/boot/dts/bcm2835-rpi-zero.dts
> b/arch/arm/boot/dts/bcm2835-rpi-zero.dts
> new file mode 100644
> index 000..12bc82d
> --- /dev/null
> +++ b/arch/arm/boot/dts/bcm2835-rpi-zero.dts
> @@ -0,0 +1,57 @@
> +/dts-v1/;
> +#include "bcm2835.dtsi"
> +#include "bcm2835-rpi.dtsi"
> +
> +/ {
> + compatible = "raspberrypi,model-zero", "brcm,bcm2835";
> + model = "Raspberry Pi Zero";
> +
> + leds {
> + act {
> + gpios = <&gpio 47 GPIO_ACTIVE_HIGH>;
> + };
> + };
> +};
> +
> +
> +&usb {
> + dr_mode = "host";
> + h-rx-fifo-size = <774>;
> + h-np-tx-fifo-size = <256>;
> + h-tx-fifo-size = <512>;
It seems like these last two are the same as the default values
reported in the registers. So they should already be set that way
without needing to specify them. If not, there may be some problem in
the driver.
> +/*
> + * Settings for otg
> + *
> + dr_mode = "otg";
> + h-rx-fifo-size = <774>;
> + h-np-tx-fifo-size = <32>;
> + h-tx-fifo-size = <0>;
This seems odd. It should be non-zero for use when operating as host.
> + g-np-tx-fifo-size = <16>;
> + g-rx-fifo-size = <256>;
> + g-tx-fifo-size = <256 128 128 64 64 64 32>;
> + *
> + * Settings for peripheral
> + *
> + dr_mode = "peripheral";
> + h-rx-fifo-size = <774>;
> + h-np-tx-fifo-size = <0>;
> + h-tx-fifo-size = <0>;
You should be able to omit the host params if dr_mode == peripheral.
> + g-np-tx-fifo-size = <16>;
> + g-rx-fifo-size = <256>;
> + g-tx-fifo-size = <256 128 128 64 64 64 32>;
> + */
> +};
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 RFC 6/6] ARM: dts: bcm2835: Add Raspberry Pi Zero
Hi John, > John Youn hat am 16. August 2016 um 21:30 > geschrieben: > > > On 7/26/2016 11:54 AM, Stefan Wahren wrote: > ... > > +/* > > + * Settings for otg > > + * > > + dr_mode = "otg"; > > + h-rx-fifo-size = <774>; > > + h-np-tx-fifo-size = <32>; > > + h-tx-fifo-size = <0>; > > This seems odd. It should be non-zero for use when operating as host. > like in host mode i took the default values in otg mode for the last two here (please refer to the logs). The BCM2835 datasheet isn't very helpful. Do you have any suggestions for valid values or how to get them? -- 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 RFC 1/6] usb: dwc2: core: Avoid nonsense error in gadget mode
Hi John, > John Youn hat am 16. August 2016 um 21:20 > geschrieben: > > > On 8/16/2016 9:44 AM, Stefan Wahren wrote: > > Hi John, > > > >> John Youn hat am 16. August 2016 um 03:30 > ... > > [2.476378] dwc2 2098.usb: dwc2_set_parameters() > > [2.476391] dwc2 2098.usb: Setting dma_desc_fs_enable to 0 > > [2.476418] dwc2 2098.usb: Setting external_id_pin_ctl to 0 > > [2.476429] dwc2 2098.usb: Setting hibernation to 0 > > [2.476449] dwc2 2098.usb: 0 invalid for host_rx_fifo_size. Check HW > > configuration. > > [2.491704] dwc2 2098.usb: Setting host_rx_fifo_size to 4096 > > [2.491727] dwc2 2098.usb: 0 invalid for host_nperio_tx_fifo_size. > > Check > > HW configuration. > > [2.507853] dwc2 2098.usb: Setting host_nperio_tx_fifo_size to 0 > > [2.507875] dwc2 2098.usb: 0 invalid for host_perio_tx_fifo_size. > > Check > > HW configuration. > > [2.524246] dwc2 2098.usb: Setting host_perio_tx_fifo_size to 0 > > Thanks for the logs. > > It looks like if dr_mode == peripheral, dwc2 doesn't populate the > following host-only values from the reset values of the registers. > > * hw_params->host_nperio_tx_fifo_size > * hw_params->host_perio_tx_fifo_size > > Thus when it goes to set the core_params based on the hw_params you > get the error. As peripheral-only, they are never used so it's fine. > > To get rid of the error we can skip setting the host-only parameters > if dr_mode == peripheral. sorry the subject is imprecise. According to the logs if dr_mode == otg we also get [2.569573] dwc2 2098.usb: 0 invalid for host_perio_tx_fifo_size. Check HW configuration. [2.585354] dwc2 2098.usb: Setting host_perio_tx_fifo_size to 0 You already said in 6/6 that's faulty, but i only want to point it out. Stefan -- 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 4/7] phy-sun4i-usb: Add support for phy_set_mode
Hi,
On 08/16/2016 03:48 PM, Sergei Shtylyov wrote:
Hello.
On 08/15/2016 10:21 PM, Hans de Goede wrote:
Together with some musb sunxi glue changes this allows run-time dr_mode
switching support via the "mode" musb sysfs attribute.
Signed-off-by: Hans de Goede
---
drivers/phy/phy-sun4i-usb.c | 24
1 file changed, 24 insertions(+)
diff --git a/drivers/phy/phy-sun4i-usb.c b/drivers/phy/phy-sun4i-usb.c
index fb2d4f3..d369081 100644
--- a/drivers/phy/phy-sun4i-usb.c
+++ b/drivers/phy/phy-sun4i-usb.c
@@ -427,6 +427,29 @@ static int sun4i_usb_phy_power_off(struct phy *_phy)
return 0;
}
+static int sun4i_usb_phy_set_mode(struct phy *_phy, enum phy_mode mode)
+{
+struct sun4i_usb_phy *phy = phy_get_drvdata(_phy);
+struct sun4i_usb_phy_data *data = to_sun4i_usb_phy_data(phy);
+
+if (phy->index != 0)
+return -EINVAL;
+
+switch (mode) {
+case PHY_MODE_USB_HOST: data->dr_mode = USB_DR_MODE_HOST; break;
+case PHY_MODE_USB_DEVICE: data->dr_mode = USB_DR_MODE_PERIPHERAL; break;
+case PHY_MODE_USB_OTG:data->dr_mode = USB_DR_MODE_OTG; break;
+default:
+return -EINVAL;
+}
+
+dev_info(&_phy->dev, "Changing dr_mode to %d\n", (int)data->dr_mode);
+data->force_session_end = true;
+queue_delayed_work(system_wq, &data->detect, 0);
+
+return 0;
+}
+
void sun4i_usb_phy_set_squelch_detect(struct phy *_phy, bool enabled)
{
struct sun4i_usb_phy *phy = phy_get_drvdata(_phy);
[...]
$ scripts/checkpatch.pl
~/patches/phy-sun4i-usb-Add-support-for-phy_set_mode.patch
ERROR: trailing statements should be on next line
#29: FILE: drivers/phy/phy-sun4i-usb.c:439:
+case PHY_MODE_USB_HOST: data->dr_mode = USB_DR_MODE_HOST; break;
ERROR: trailing statements should be on next line
#30: FILE: drivers/phy/phy-sun4i-usb.c:440:
+case PHY_MODE_USB_DEVICE: data->dr_mode = USB_DR_MODE_PERIPHERAL; break;
ERROR: trailing statements should be on next line
#31: FILE: drivers/phy/phy-sun4i-usb.c:441:
+case PHY_MODE_USB_OTG:data->dr_mode = USB_DR_MODE_OTG; break;
This is normal codeing style for a switch-case assigning a single value per
case,
but checkpatch does not know this.
Regaards,
Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
