Re: [PATCH] usb: dwc3: core: Disable USB2.0 phy suspend when dwc3 acts as host role
Hi, Baolin Wang writes: >> Baolin Wang writes: >>> When dwc3 controller acts as host role with attaching slow speed device >>> (like mouse or keypad). Then if we plugged out the slow speed device, >>> it will timeout to run the deconfiguration endpoint command to drop the >>> endpoint's resources. Some xHCI command timeout log as below when >>> disconnecting one slow device: >>> >>> [ 99.807739] c0 xhci-hcd.0.auto: Port Status Change Event for port 1 >>> [ 99.814699] c0 xhci-hcd.0.auto: resume root hub >>> [ 99.819992] c0 xhci-hcd.0.auto: handle_port_status: starting port >>> polling. >>> [ 99.827808] c0 xhci-hcd.0.auto: get port status, actual port 0 status >>> = 0x202a0 >>> [ 99.835903] c0 xhci-hcd.0.auto: Get port status returned 0x10100 >>> [ 99.850052] c0 xhci-hcd.0.auto: clear port connect change, actual >>> port 0 status = 0x2a0 >>> [ 99.859313] c0 xhci-hcd.0.auto: Cancel URB ffc01ed6cd00, dev 1, >>> ep 0x81, starting at offset 0xc406d210 >>> [ 99.869645] c0 xhci-hcd.0.auto: // Ding dong! >>> [ 99.874776] c0 xhci-hcd.0.auto: Stopped on Transfer TRB >>> [ 99.880713] c0 xhci-hcd.0.auto: Removing canceled TD starting at >>> 0xc406d210 (dma). >>> [ 99.889012] c0 xhci-hcd.0.auto: Finding endpoint context >>> [ 99.895069] c0 xhci-hcd.0.auto: Cycle state = 0x1 >>> [ 99.900519] c0 xhci-hcd.0.auto: New dequeue segment = >>> ffc1112f0880 (virtual) >>> [ 99.908655] c0 xhci-hcd.0.auto: New dequeue pointer = 0xc406d220 (DMA) >>> [ 99.915927] c0 xhci-hcd.0.auto: Set TR Deq Ptr cmd, new deq seg = >>> ffc1112f0880 (0xc406d000 dma), >>> new deq ptr = ff8002175220 >>> (0xc406d220 dma), new cycle = 1 >>> [ 99.931242] c0 xhci-hcd.0.auto: // Ding dong! >>> [ 99.936360] c0 xhci-hcd.0.auto: Successful Set TR Deq Ptr cmd, >>> deq = @c406d220 >>> [ 99.944458] c0 xhci-hcd.0.auto: xhci_hub_status_data: stopping port >>> polling. >>> [ 100.047619] c0 xhci-hcd.0.auto: xhci_drop_endpoint called for udev >>> ffc01ae08800 >>> [ 100.057002] c0 xhci-hcd.0.auto: drop ep 0x81, slot id 1, new drop >>> flags = 0x8, new add flags = 0x0 >>> [ 100.067878] c0 xhci-hcd.0.auto: xhci_check_bandwidth called for udev >>> ffc01ae08800 >>> [ 100.076868] c0 xhci-hcd.0.auto: New Input Control Context: >>> >>> .. >>> >>> [ 100.427252] c0 xhci-hcd.0.auto: // Ding dong! >>> [ 105.430728] c0 xhci-hcd.0.auto: Command timeout >>> [ 105.436029] c0 xhci-hcd.0.auto: Abort command ring >>> [ 113.558223] c0 xhci-hcd.0.auto: Command completion event does not match >>> command >>> [ 113.569778] c0 xhci-hcd.0.auto: Timeout while waiting for configure >>> endpoint command >>> >>> The reason is it will suspend USB phy to disable phy clock when >>> disconnecting the slow USB decice, that will hang on the xHCI commands >>> executing which depends on the phy clock. >>> >>> Thus we should disable USB2.0 phy suspend feature when dwc3 acts as host >>> role. >>> >>> Signed-off-by: Baolin Wang >>> --- >>> drivers/usb/dwc3/core.c | 14 ++ >>> 1 file changed, 14 insertions(+) >>> >>> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c >>> index 9a4a5e4..0b646cf 100644 >>> --- a/drivers/usb/dwc3/core.c >>> +++ b/drivers/usb/dwc3/core.c >>> @@ -565,6 +565,20 @@ static int dwc3_phy_setup(struct dwc3 *dwc) >>> if (dwc->revision > DWC3_REVISION_194A) >>> reg |= DWC3_GUSB2PHYCFG_SUSPHY; >>> >>> + /* >>> + * When dwc3 controller acts as host role with attaching one slow >>> speed >>> + * device (like mouse or keypad). Then if we plugged out the slow >>> speed >>> + * device, it will timeout to run the deconfiguration endpoint >>> command. >>> + * The reason is it will suspend USB phy to disable phy clock when >>> + * disconnecting slow speed decice, which will affect the xHCI >>> commands >>> + * executing. >>> + * >>> + * Thus we should disable USB 2.0 phy suspend feature when dwc3 acts >>> as >>> + * host role. >>> + */ >>> + if (dwc->dr_mode == USB_DR_MODE_HOST || dwc->dr_mode == >>> USB_DR_MODE_OTG) >>> + reg &= ~DWC3_GUSB2PHYCFG_SUSPHY; >> >> which version of the core you're using? Recent version (since 1.94A, > > My version is 2.80a. > >> IIRC) can manage core suspend automatically. Also, this patch of yours >> will cause a power consumption regression. > > Yes, it can manage core suspend automatically, that is the problem. > When plugging out one mouse or keyp
Re: [v4.4.40] patch backport error
On Wed, Jan 11, 2017 at 09:17:02PM +0100, Greg Kroah-Hartman wrote: > On Wed, Jan 11, 2017 at 07:13:30PM +0200, Felipe Balbi wrote: > > > > hi, > > > > Bin Liu writes: > > > I am unable to figure out what was happening, but there seems to be a > > > patch backport error in v4.4.40. > > > > > > Commit c53af76d5de1 (usb: gadget: composite: always set ep->mult to a > > > sensible value) is backported from upstream > > > eaa496ffaaf19591fe471a36cef366146eeb9153, however c53af76d5de1 has > > > > > > + _ep->mult = usb_endpoint_maxp(_ep->desc) & 0x7ff; > > > > > > but eaa496ffaaf19591fe471a36cef366146eeb9153 has > > > > > > + _ep->mult = usb_endpoint_maxp_mult(_ep->desc); > > > > > > they are not consistant. > > > > > > I haven't checked v4.9 yet, not sure if this happens there too. > > > > oh-oh. you're correct, I sent the wrong patch :-( > > > > I'll send a correct patch tomorrow. Greg, do you want a revert followed > > by correct patch, or just fix-up patch? > > A simple fixup is fine. Hm, no, let me go revert these now, as I'm doing a release in an hour or so. Can you send me the "correct" backported patches, I'll take them for the next round of stable kernels. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: dwc3-exynos Fix dma_mask WARN_ON from xhci_plat_probe()
Hi,
Shuah Khan writes:
> During dwc3_exynos_probe(), WARN_ON(!pdev->dev.dma_mask) is triggered from
> xhci_plat_probe(). dwc3_host_init() doesn't configure DMA prior to adding
> the platform device.
>
> dwc3_host_init() was changed to not configure DMA with the change to use
> bus->sysdev for DMA config.
>
> sysdev_is_parent is not true for dwc3-exynos. This might be the reason why
> there is a need to configure DMA in dwc3_host_init() prior to adding the
> platform device for xhci in this path.
>
> This fix adds the DMA config to dwc3_host_init() without undoing any other
> changes in
> commit d64ff406e51e ("usb: dwc3: use bus->sysdev for DMA configuration")
>
> [3.372356] WARNING: CPU: 2 PID: 108 at drivers/usb/host/xhci-plat.c:168
> xhc0
> [3.381381] Modules linked in:
> [3.384373] CPU: 2 PID: 108 Comm: kworker/2:1 Not tainted
> 4.10.0-rc2-00250-g8
> [3.392783] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
> [3.398854] Workqueue: events deferred_probe_work_func
> [3.403994] [] (unwind_backtrace) from []
> (show_stack+0x)
> [3.411696] [] (show_stack) from []
> (dump_stack+0x78/0x8)
> [3.418877] [] (dump_stack) from [] (__warn+0xe8/0x100)
> [3.425796] [] (__warn) from []
> (warn_slowpath_null+0x20)
> [3.433344] [] (warn_slowpath_null) from []
> (xhci_plat_p)
> [3.441845] [] (xhci_plat_probe) from []
> (platform_drv_p)
> [3.450157] [] (platform_drv_probe) from []
> (driver_prob)
> [3.458994] [] (driver_probe_device) from []
> (bus_for_ea)
> [3.467485] [] (bus_for_each_drv) from []
> (__device_atta)
> [3.475716] [] (__device_attach) from []
> (bus_probe_devi)
> [3.483872] [] (bus_probe_device) from []
> (device_add+0x)
> [3.491741] [] (device_add) from []
> (platform_device_add)
> [3.499892] [] (platform_device_add) from []
> (dwc3_host_)
> [3.508379] [] (dwc3_host_init) from []
> (dwc3_probe+0x94)
> [3.516091] [] (dwc3_probe) from []
> (platform_drv_probe+)
> [3.523975] [] (platform_drv_probe) from []
> (driver_prob)
> [3.532814] [] (driver_probe_device) from []
> (bus_for_ea)
> [3.541306] [] (bus_for_each_drv) from []
> (__device_atta)
> [3.549538] [] (__device_attach) from []
> (bus_probe_devi)
> [3.557684] [] (bus_probe_device) from []
> (device_add+0x)
> [3.565582] [] (device_add) from []
> (of_platform_device_)
> [3.574586] [] (of_platform_device_create_pdata) from
> [])
> [3.584722] [] (of_platform_bus_create) from []
> (of_plat)
> [3.593828] [] (of_platform_populate) from []
> (dwc3_exyn)
> [3.602660] [] (dwc3_exynos_probe) from []
> (platform_drv)
> [3.611150] [] (platform_drv_probe) from []
> (driver_prob)
> [3.619988] [] (driver_probe_device) from []
> (bus_for_ea)
> [3.628480] [] (bus_for_each_drv) from []
> (__device_atta)
> [3.636712] [] (__device_attach) from []
> (bus_probe_devi)
> [3.644857] [] (bus_probe_device) from []
> (deferred_prob)
> [3.653798] [] (deferred_probe_work_func) from []
> (proce)
>
> Signed-off-by: Shuah Khan
> ---
> Arnd! I isolated the smallest change to avoid the WARN_ON. Please let me
> know if this problem could be fixed in another way.
>
> drivers/usb/dwc3/host.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/usb/dwc3/host.c b/drivers/usb/dwc3/host.c
> index 487f0ff..f68f71f 100644
> --- a/drivers/usb/dwc3/host.c
> +++ b/drivers/usb/dwc3/host.c
> @@ -84,7 +84,10 @@ int dwc3_host_init(struct dwc3 *dwc)
> return -ENOMEM;
> }
>
> + dma_set_coherent_mask(&xhci->dev, dwc->dev->coherent_dma_mask);
> xhci->dev.parent= dwc->dev;
> + xhci->dev.dma_mask = dwc->dev->dma_mask;
> + xhci->dev.dma_parms = dwc->dev->dma_parms;
this is the result of a missed patch. Mathias is discussing the proper
fix for this.
--
balbi
signature.asc
Description: PGP signature
Re: [PATCH 0/4 v3] Fixes and workarounds for dwc2 on HiKey board (rebased to synopsys-usb/next)
On 1/11/2017 4:22 PM, John Stultz wrote: > Just wanted to resend my patches for dwc2 controller on the > HiKey board for consideration for the 4.11 merge window. > > This patchset is the same as v2, only rebased against > John's synopsys-usb/next branch. > > This does still exclude my patchset[1] to add extcon support to > dwc2, which John Youn suspects a pending rework of the dwc2 fifo > init logic might make unnecssary. > > thanks > -john > > [1] > https://urldefense.proofpoint.com/v2/url?u=https-3A__lkml.org_lkml_2016_12_6_69&d=DgIBAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=U3o8uKoKhWme5_V9D-eeCkB11BFwt4KvWztBgdE9ZpA&m=6QmpEaovCIrw3iVcLB9lyZ2hPpxb_n6SWfdUDBIINFU&s=JoQtFGWd8y_xhRErt3j8U8uoUw_kq0AStxhqSPwEa3Q&e= > > > v2: > * Reworked goto logic in patch #2, as suggested by Vardan > v3: > * Rebased to synopsys-usb/next > Thanks For this series: Acked-by: John Youn 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
[PATCH] usb: dwc3-exynos Fix dma_mask WARN_ON from xhci_plat_probe()
During dwc3_exynos_probe(), WARN_ON(!pdev->dev.dma_mask) is triggered from
xhci_plat_probe(). dwc3_host_init() doesn't configure DMA prior to adding
the platform device.
dwc3_host_init() was changed to not configure DMA with the change to use
bus->sysdev for DMA config.
sysdev_is_parent is not true for dwc3-exynos. This might be the reason why
there is a need to configure DMA in dwc3_host_init() prior to adding the
platform device for xhci in this path.
This fix adds the DMA config to dwc3_host_init() without undoing any other
changes in
commit d64ff406e51e ("usb: dwc3: use bus->sysdev for DMA configuration")
[3.372356] WARNING: CPU: 2 PID: 108 at drivers/usb/host/xhci-plat.c:168 xhc0
[3.381381] Modules linked in:
[3.384373] CPU: 2 PID: 108 Comm: kworker/2:1 Not tainted 4.10.0-rc2-00250-g8
[3.392783] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[3.398854] Workqueue: events deferred_probe_work_func
[3.403994] [] (unwind_backtrace) from [] (show_stack+0x)
[3.411696] [] (show_stack) from [] (dump_stack+0x78/0x8)
[3.418877] [] (dump_stack) from [] (__warn+0xe8/0x100)
[3.425796] [] (__warn) from [] (warn_slowpath_null+0x20)
[3.433344] [] (warn_slowpath_null) from [] (xhci_plat_p)
[3.441845] [] (xhci_plat_probe) from [] (platform_drv_p)
[3.450157] [] (platform_drv_probe) from [] (driver_prob)
[3.458994] [] (driver_probe_device) from [] (bus_for_ea)
[3.467485] [] (bus_for_each_drv) from [] (__device_atta)
[3.475716] [] (__device_attach) from [] (bus_probe_devi)
[3.483872] [] (bus_probe_device) from [] (device_add+0x)
[3.491741] [] (device_add) from [] (platform_device_add)
[3.499892] [] (platform_device_add) from [] (dwc3_host_)
[3.508379] [] (dwc3_host_init) from [] (dwc3_probe+0x94)
[3.516091] [] (dwc3_probe) from [] (platform_drv_probe+)
[3.523975] [] (platform_drv_probe) from [] (driver_prob)
[3.532814] [] (driver_probe_device) from [] (bus_for_ea)
[3.541306] [] (bus_for_each_drv) from [] (__device_atta)
[3.549538] [] (__device_attach) from [] (bus_probe_devi)
[3.557684] [] (bus_probe_device) from [] (device_add+0x)
[3.565582] [] (device_add) from [] (of_platform_device_)
[3.574586] [] (of_platform_device_create_pdata) from [])
[3.584722] [] (of_platform_bus_create) from [] (of_plat)
[3.593828] [] (of_platform_populate) from [] (dwc3_exyn)
[3.602660] [] (dwc3_exynos_probe) from [] (platform_drv)
[3.611150] [] (platform_drv_probe) from [] (driver_prob)
[3.619988] [] (driver_probe_device) from [] (bus_for_ea)
[3.628480] [] (bus_for_each_drv) from [] (__device_atta)
[3.636712] [] (__device_attach) from [] (bus_probe_devi)
[3.644857] [] (bus_probe_device) from [] (deferred_prob)
[3.653798] [] (deferred_probe_work_func) from [] (proce)
Signed-off-by: Shuah Khan
---
Arnd! I isolated the smallest change to avoid the WARN_ON. Please let me
know if this problem could be fixed in another way.
drivers/usb/dwc3/host.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/usb/dwc3/host.c b/drivers/usb/dwc3/host.c
index 487f0ff..f68f71f 100644
--- a/drivers/usb/dwc3/host.c
+++ b/drivers/usb/dwc3/host.c
@@ -84,7 +84,10 @@ int dwc3_host_init(struct dwc3 *dwc)
return -ENOMEM;
}
+ dma_set_coherent_mask(&xhci->dev, dwc->dev->coherent_dma_mask);
xhci->dev.parent= dwc->dev;
+ xhci->dev.dma_mask = dwc->dev->dma_mask;
+ xhci->dev.dma_parms = dwc->dev->dma_parms;
dwc->xhci = xhci;
--
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 1/4 v3] usb: dwc2: Avoid sleeping while holding hsotg->lock
Basically when plugging in various cables in different orders, I'm
occasionally seeing the following BUG splat:
[ 86.215403] BUG: scheduling while atomic: kworker/u16:2/53/0x0002
[ 86.219164] usb 1-1: USB disconnect, device number 9
[ 86.226845] Preemption disabled at:[ 86.230218]
[] dwc2_conn_id_status_change+0x120/0x250
[ 86.236894] CPU: 0 PID: 53 Comm: kworker/u16:2 Tainted: GW
4.9.0-rc8-00051-gd5a7979-dirty #1702
[ 86.246836] Hardware name: HiKey Development Board (DT)
[ 86.252100] Workqueue: dwc2 dwc2_conn_id_status_change
[ 86.257279] Call trace:
[ 86.259771] [] dump_backtrace+0x0/0x1a0
[ 86.265210] [] show_stack+0x14/0x20
[ 86.270308] [] dump_stack+0x90/0xb0
[ 86.275401] [] __schedule_bug+0x6c/0xb8
[ 86.280841] [] __schedule+0x4f8/0x5b0
[ 86.286099] [] schedule+0x38/0xa0
[ 86.291017] [] schedule_hrtimeout_range_clock+0x8c/0xf0
[ 86.297846] [] schedule_hrtimeout_range+0x10/0x18
[ 86.304150] [] usleep_range+0x50/0x58
[ 86.309418] [] dwc2_wait_for_mode.isra.4+0x54/0xd0
[ 86.315815] [] dwc2_core_reset+0xe0/0x168
[ 86.321431] [] dwc2_hsotg_core_init_disconnected+0x2c/0x310
[ 86.328602] [] dwc2_conn_id_status_change+0x130/0x250
[ 86.335254] [] process_one_work+0x118/0x370
[ 86.341035] [] worker_thread+0x48/0x498
[ 86.346473] [] kthread+0xd0/0xe8
[ 86.351299] [] ret_from_fork+0x10/0x50
This seems to be caused by the dwc2_wait_for_mode() calling
usleep_range() while the hstog->lock spinlock is held, since
we take that before calling dwc2_hsotg_core_init_disconnected().
This patch avoids the issue by adding an extra argument to
dwc2_core_reset(), as suggested by John Youn, which allows us to
skip the waiting, which should be unnecessary when calling from
dwc2_hsotg_core_init_disconnected().
Cc: Wei Xu
Cc: Guodong Xu
Cc: Amit Pundir
Cc: Rob Herring
Cc: John Youn
Cc: Douglas Anderson
Cc: Chen Yu
Cc: Vardan Mikayelyan
Cc: Kishon Vijay Abraham I
Cc: Felipe Balbi
Cc: Greg Kroah-Hartman
Cc: linux-usb@vger.kernel.org
Signed-off-by: John Stultz
---
v3:
* Rebased to synopsys-usb/next branch
drivers/usb/dwc2/core.c | 6 +++---
drivers/usb/dwc2/core.h | 2 +-
drivers/usb/dwc2/gadget.c | 2 +-
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c
index c987547..7195366 100644
--- a/drivers/usb/dwc2/core.c
+++ b/drivers/usb/dwc2/core.c
@@ -313,7 +313,7 @@ static bool dwc2_iddig_filter_enabled(struct dwc2_hsotg
*hsotg)
* Do core a soft reset of the core. Be careful with this because it
* resets all the internal state machines of the core.
*/
-int dwc2_core_reset(struct dwc2_hsotg *hsotg)
+int dwc2_core_reset(struct dwc2_hsotg *hsotg, bool skip_wait)
{
u32 greset;
int count = 0;
@@ -369,7 +369,7 @@ int dwc2_core_reset(struct dwc2_hsotg *hsotg)
}
} while (!(greset & GRSTCTL_AHBIDLE));
- if (wait_for_host_mode)
+ if (wait_for_host_mode && !skip_wait)
dwc2_wait_for_mode(hsotg, true);
return 0;
@@ -500,7 +500,7 @@ int dwc2_core_reset_and_force_dr_mode(struct dwc2_hsotg
*hsotg)
{
int retval;
- retval = dwc2_core_reset(hsotg);
+ retval = dwc2_core_reset(hsotg, false);
if (retval)
return retval;
diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index 013feb9..05ce52c 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -1089,7 +1089,7 @@ static inline bool dwc2_is_hs_iot(struct dwc2_hsotg
*hsotg)
* The following functions support initialization of the core driver component
* and the DWC_otg controller
*/
-int dwc2_core_reset(struct dwc2_hsotg *hsotg);
+int dwc2_core_reset(struct dwc2_hsotg *hsotg, bool skip_wait);
int dwc2_core_reset_and_force_dr_mode(struct dwc2_hsotg *hsotg);
int dwc2_enter_hibernation(struct dwc2_hsotg *hsotg);
int dwc2_exit_hibernation(struct dwc2_hsotg *hsotg, bool restore);
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index 242930e..e9cf162 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -3161,7 +3161,7 @@ void dwc2_hsotg_core_init_disconnected(struct dwc2_hsotg
*hsotg,
kill_all_requests(hsotg, hsotg->eps_out[0], -ECONNRESET);
if (!is_usb_reset)
- if (dwc2_core_reset(hsotg))
+ if (dwc2_core_reset(hsotg, true))
return;
/*
--
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 0/4 v3] Fixes and workarounds for dwc2 on HiKey board (rebased to synopsys-usb/next)
Just wanted to resend my patches for dwc2 controller on the HiKey board for consideration for the 4.11 merge window. This patchset is the same as v2, only rebased against John's synopsys-usb/next branch. This does still exclude my patchset[1] to add extcon support to dwc2, which John Youn suspects a pending rework of the dwc2 fifo init logic might make unnecssary. thanks -john [1] https://lkml.org/lkml/2016/12/6/69 v2: * Reworked goto logic in patch #2, as suggested by Vardan v3: * Rebased to synopsys-usb/next Cc: Wei Xu Cc: Guodong Xu Cc: Amit Pundir Cc: Rob Herring Cc: John Youn Cc: Douglas Anderson Cc: Chen Yu Cc: Vardan Mikayelyan Cc: Kishon Vijay Abraham I Cc: Felipe Balbi Cc: Greg Kroah-Hartman Cc: linux-usb@vger.kernel.org Chen Yu (2): usb: dwc2: Force port resume on switching to device mode usb: dwc2: Add a quirk to allow speed negotiation for Hisilicon Hi6220 John Stultz (2): usb: dwc2: Avoid sleeping while holding hsotg->lock usb: dwc2: Workaround case where GOTGCTL state is wrong drivers/usb/dwc2/core.c | 6 ++-- drivers/usb/dwc2/core.h | 9 +- drivers/usb/dwc2/gadget.c | 2 +- drivers/usb/dwc2/hcd.c| 76 +++ drivers/usb/dwc2/params.c | 1 + 5 files changed, 89 insertions(+), 5 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 2/4 v3] usb: dwc2: Workaround case where GOTGCTL state is wrong
When removing a USB-A to USB-otg adapter cable, we get a change
status irq, and then in dwc2_conn_id_status_change, we
erroniously see the GOTGCTL_CONID_B flag set. This causes us to
get stuck in the "while (!dwc2_is_device_mode(hsotg))" loop,
spitting out "Waiting for Peripheral Mode, Mode=Host" warnings
until it fails out many seconds later.
This patch works around the issue by re-reading the GOTGCTL
state to check if the GOTGCTL_CONID_B is still set and if not
restarting the change status logic.
I suspect this isn't the best solution, but it seems to work
well for me.
Feedback would be greatly appreciated!
Cc: Wei Xu
Cc: Guodong Xu
Cc: Amit Pundir
Cc: Rob Herring
Cc: John Youn
Cc: Douglas Anderson
Cc: Chen Yu
Cc: Vardan Mikayelyan
Cc: Kishon Vijay Abraham I
Cc: Felipe Balbi
Cc: Greg Kroah-Hartman
Cc: linux-usb@vger.kernel.org
Acked-by: John Youn
Reviewed-by: Vardan Mikayelyan
Signed-off-by: John Stultz
---
v2: Rework goto logic suggested by Vardan, and add a comment
v3:
* Rebased to synopsys-usb/next branch
---
drivers/usb/dwc2/hcd.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
index b63b14f..888923c 100644
--- a/drivers/usb/dwc2/hcd.c
+++ b/drivers/usb/dwc2/hcd.c
@@ -3238,6 +3238,14 @@ static void dwc2_conn_id_status_change(struct
work_struct *work)
dwc2_is_host_mode(hsotg) ? "Host" :
"Peripheral");
usleep_range(2, 4);
+ /*
+* Sometimes the initial GOTGCTRL read is wrong, so
+* check it again and jump to host mode if that was
+* the case.
+*/
+ gotgctl = dwc2_readl(hsotg->regs + GOTGCTL);
+ if (!(gotgctl & GOTGCTL_CONID_B))
+ goto host;
if (++count > 250)
break;
}
@@ -3252,6 +3260,7 @@ static void dwc2_conn_id_status_change(struct work_struct
*work)
spin_unlock_irqrestore(&hsotg->lock, flags);
dwc2_hsotg_core_connect(hsotg);
} else {
+host:
/* A-Device connector (Host Mode) */
dev_dbg(hsotg->dev, "connId A\n");
while (!dwc2_is_host_mode(hsotg)) {
--
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 4/4 v3] usb: dwc2: Add a quirk to allow speed negotiation for Hisilicon Hi6220
From: Chen Yu
The Hi6220's usb controller is limited in that it does not
support "Split Transactions", so it does not support communicating
with low-speed and full-speed devices behind a high-speed hub.
Thus it requires a quirk so that we can manually drop the usb
speed when low/full-speed are attached, and bump back to high
speed when they are removed.
Cc: Wei Xu
Cc: Guodong Xu
Cc: Amit Pundir
Cc: Rob Herring
Cc: John Youn
Cc: Douglas Anderson
Cc: Chen Yu
Cc: Vardan Mikayelyan
Cc: Kishon Vijay Abraham I
Cc: Felipe Balbi
Cc: Greg Kroah-Hartman
Cc: linux-usb@vger.kernel.org
Signed-off-by: Chen Yu
[jstultz: Reworked to simplify the patch, and made
commit log to be more specific about the issue]
Signed-off-by: John Stultz
---
v2:
* Fix build issue reported by kbuildbot
* Rework to avoid using new dts entry suggested by RobH
* Further tweaks from Chen Yu to try to address comments from
John Youn
* Further simplified logic
* Reworked to adapt around changes that landed in 4.10-rc
v3:
* Rebased to synopsys-usb/next branch
---
drivers/usb/dwc2/core.h | 7 ++
drivers/usb/dwc2/hcd.c| 60 +++
drivers/usb/dwc2/params.c | 1 +
3 files changed, 68 insertions(+)
diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index 05ce52c..5370e64 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -444,6 +444,11 @@ enum dwc2_ep0_state {
* in DWORDS with possible values from from
* 16-32768 (default: 256, 256, 256, 256, 768,
* 768, 768, 768, 0, 0, 0, 0, 0, 0, 0).
+ * @change_speed_quirk: Change speed configuration to DWC2_SPEED_PARAM_FULL
+ * while full&low speed device connect. And change speed
+ * back to DWC2_SPEED_PARAM_HIGH while device is gone.
+ * 0 - No (default)
+ * 1 - Yes
*
* The following parameters may be specified when starting the module. These
* parameters define how the DWC_otg controller should be configured. A
@@ -501,6 +506,8 @@ struct dwc2_core_params {
u32 g_rx_fifo_size;
u32 g_np_tx_fifo_size;
u32 g_tx_fifo_size[MAX_EPS_CHANNELS];
+
+ bool change_speed_quirk;
};
/**
diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
index cdf0bac..c3a0fd8 100644
--- a/drivers/usb/dwc2/hcd.c
+++ b/drivers/usb/dwc2/hcd.c
@@ -4872,6 +4872,61 @@ static void _dwc2_hcd_clear_tt_buffer_complete(struct
usb_hcd *hcd,
spin_unlock_irqrestore(&hsotg->lock, flags);
}
+/*
+ * HPRT0_SPD_HIGH_SPEED: high speed
+ * HPRT0_SPD_FULL_SPEED: full speed
+ */
+static void dwc2_change_bus_speed(struct usb_hcd *hcd, int speed)
+{
+ struct dwc2_hsotg *hsotg = dwc2_hcd_to_hsotg(hcd);
+
+ if (hsotg->params.speed == speed)
+ return;
+
+ hsotg->params.speed = speed;
+ queue_work(hsotg->wq_otg, &hsotg->wf_otg);
+}
+
+static void dwc2_free_dev(struct usb_hcd *hcd, struct usb_device *udev)
+{
+ struct dwc2_hsotg *hsotg = dwc2_hcd_to_hsotg(hcd);
+
+ if (!hsotg->params.change_speed_quirk)
+ return;
+
+ /*
+* On removal, set speed to default high-speed.
+*/
+ if (udev->parent && udev->parent->speed > USB_SPEED_UNKNOWN &&
+ udev->parent->speed < USB_SPEED_HIGH) {
+ dev_info(hsotg->dev, "Set speed to default high-speed\n");
+ dwc2_change_bus_speed(hcd, HPRT0_SPD_HIGH_SPEED);
+ }
+}
+
+static int dwc2_reset_device(struct usb_hcd *hcd, struct usb_device *udev)
+{
+ struct dwc2_hsotg *hsotg = dwc2_hcd_to_hsotg(hcd);
+
+ if (!hsotg->params.change_speed_quirk)
+ return 0;
+
+ if (udev->speed == USB_SPEED_HIGH) {
+ dev_info(hsotg->dev, "Set speed to high-speed\n");
+ dwc2_change_bus_speed(hcd, HPRT0_SPD_HIGH_SPEED);
+ } else if ((udev->speed == USB_SPEED_FULL ||
+ udev->speed == USB_SPEED_LOW)) {
+ /*
+* Change speed setting to full-speed if there's
+* a full-speed or low-speed device plugged in.
+*/
+ dev_info(hsotg->dev, "Set speed to full-speed\n");
+ dwc2_change_bus_speed(hcd, HPRT0_SPD_FULL_SPEED);
+ }
+
+ return 0;
+}
+
static struct hc_driver dwc2_hc_driver = {
.description = "dwc2_hsotg",
.product_desc = "DWC OTG Controller",
@@ -5027,6 +5082,11 @@ int dwc2_hcd_init(struct dwc2_hsotg *hsotg, int irq)
dev_warn(hsotg->dev, "can't set coherent DMA mask\n");
}
+ if (hsotg->params.change_speed_quirk) {
+ dwc2_hc_driver.free_dev = dwc2_free_dev;
+ dwc2_hc_driver.reset_device = dwc2_reset_device;
+ }
+
hcd = usb_create_hcd(&dwc2_hc_driver, hsotg->dev, dev_name(hsotg->dev));
if (!hcd)
goto error1;
diff --git a/
[PATCH 3/4 v3] usb: dwc2: Force port resume on switching to device mode
From: Chen Yu
We've seen failures when switching between host and gadget mode,
which was diagnosed as being caused due to the bus being
auto-suspended when we switched.
So this patch forces a port resume when switching to device
mode if the bus is suspended.
Cc: Wei Xu
Cc: Guodong Xu
Cc: Amit Pundir
Cc: Rob Herring
Cc: John Youn
Cc: Douglas Anderson
Cc: Chen Yu
Cc: Vardan Mikayelyan
Cc: Kishon Vijay Abraham I
Cc: Felipe Balbi
Cc: Greg Kroah-Hartman
Cc: linux-usb@vger.kernel.org
Signed-off-by: Chen Yu
Signed-off-by: John Stultz
---
v3:
* Rebased to synopsys-usb/next branch
drivers/usb/dwc2/hcd.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
index 888923c..cdf0bac 100644
--- a/drivers/usb/dwc2/hcd.c
+++ b/drivers/usb/dwc2/hcd.c
@@ -54,6 +54,8 @@
#include "core.h"
#include "hcd.h"
+static void dwc2_port_resume(struct dwc2_hsotg *hsotg);
+
/*
* =
* Host Core Layer Functions
@@ -3232,6 +3234,11 @@ static void dwc2_conn_id_status_change(struct
work_struct *work)
if (gotgctl & GOTGCTL_CONID_B) {
/* Wait for switch to device mode */
dev_dbg(hsotg->dev, "connId B\n");
+ if (hsotg->bus_suspended) {
+ dev_info(hsotg->dev,
+"Do port resume before switching to device
mode\n");
+ dwc2_port_resume(hsotg);
+ }
while (!dwc2_is_device_mode(hsotg)) {
dev_info(hsotg->dev,
"Waiting for Peripheral Mode, Mode=%s\n",
--
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 0/5 v2] Fixes and workarounds for dwc2 on HiKey board
On 1/11/2017 3:10 PM, John Stultz wrote: > On Wed, Jan 11, 2017 at 2:58 PM, John Youn wrote: >> On 1/11/2017 2:39 PM, John Stultz wrote: >>> On Wed, Jan 11, 2017 at 2:08 PM, John Youn wrote: On 1/3/2017 11:52 AM, John Stultz wrote: > Hope everyone had a happy new years! > > I just wanted to send out my current queue of patches for dwc2 > controller on the HiKey board for consideration for the 4.11 > merge window. > > This does exclude my patchset[1] to add extcon support to dwc2, > which John Youn suspects a pending rework of the dwc2 fifo init > logic might make unnecssary. > > Any feedback would be greatly appreciated! > Hi John, Do you need these in 4.10-rc or is 4.11 ok? >>> >>> So I was submitting these for 4.11. >>> >>> The only one which was sort of a regression fix (though introduced in >>> 4.9 rather then 4.10) was the "Avoid suspending if we're in gadget >>> mode" one, which you seemed to submit for 4.10-rc already. >>> >>> Let me know if there is anything you need prior to queuing the rest for >>> 4.11. >>> >> >> Ok. The only one that will have a problem will be patch 5 due to my >> recent series [1]. >> >> Can you rebase against that? > > Do you have a git branch for that series to rebase against? > https://github.com/synopsys-usb/linux.git branch 'next' 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 0/5 v2] Fixes and workarounds for dwc2 on HiKey board
On Wed, Jan 11, 2017 at 2:58 PM, John Youn wrote: > On 1/11/2017 2:39 PM, John Stultz wrote: >> On Wed, Jan 11, 2017 at 2:08 PM, John Youn wrote: >>> On 1/3/2017 11:52 AM, John Stultz wrote: Hope everyone had a happy new years! I just wanted to send out my current queue of patches for dwc2 controller on the HiKey board for consideration for the 4.11 merge window. This does exclude my patchset[1] to add extcon support to dwc2, which John Youn suspects a pending rework of the dwc2 fifo init logic might make unnecssary. Any feedback would be greatly appreciated! >>> >>> Hi John, >>> >>> Do you need these in 4.10-rc or is 4.11 ok? >> >> So I was submitting these for 4.11. >> >> The only one which was sort of a regression fix (though introduced in >> 4.9 rather then 4.10) was the "Avoid suspending if we're in gadget >> mode" one, which you seemed to submit for 4.10-rc already. >> >> Let me know if there is anything you need prior to queuing the rest for 4.11. >> > > Ok. The only one that will have a problem will be patch 5 due to my > recent series [1]. > > Can you rebase against that? Do you have a git branch for that series to rebase against? thanks -john -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5 v2] Fixes and workarounds for dwc2 on HiKey board
On 1/11/2017 2:39 PM, John Stultz wrote: > On Wed, Jan 11, 2017 at 2:08 PM, John Youn wrote: >> On 1/3/2017 11:52 AM, John Stultz wrote: >>> Hope everyone had a happy new years! >>> >>> I just wanted to send out my current queue of patches for dwc2 >>> controller on the HiKey board for consideration for the 4.11 >>> merge window. >>> >>> This does exclude my patchset[1] to add extcon support to dwc2, >>> which John Youn suspects a pending rework of the dwc2 fifo init >>> logic might make unnecssary. >>> >>> Any feedback would be greatly appreciated! >>> >> >> Hi John, >> >> Do you need these in 4.10-rc or is 4.11 ok? > > So I was submitting these for 4.11. > > The only one which was sort of a regression fix (though introduced in > 4.9 rather then 4.10) was the "Avoid suspending if we're in gadget > mode" one, which you seemed to submit for 4.10-rc already. > > Let me know if there is anything you need prior to queuing the rest for 4.11. > Ok. The only one that will have a problem will be patch 5 due to my recent series [1]. Can you rebase against that? Patch 1-4 of this series: Acked-by: John Youn I'll also add these to our 4.11 branch locally as there are a lot of interdependent changes. I'll send everything at once to Felipe to make it easier for him. Regards, John [1] https://www.spinics.net/lists/linux-usb/msg151693.html -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5 v2] Fixes and workarounds for dwc2 on HiKey board
On Wed, Jan 11, 2017 at 2:08 PM, John Youn wrote: > On 1/3/2017 11:52 AM, John Stultz wrote: >> Hope everyone had a happy new years! >> >> I just wanted to send out my current queue of patches for dwc2 >> controller on the HiKey board for consideration for the 4.11 >> merge window. >> >> This does exclude my patchset[1] to add extcon support to dwc2, >> which John Youn suspects a pending rework of the dwc2 fifo init >> logic might make unnecssary. >> >> Any feedback would be greatly appreciated! >> > > Hi John, > > Do you need these in 4.10-rc or is 4.11 ok? So I was submitting these for 4.11. The only one which was sort of a regression fix (though introduced in 4.9 rather then 4.10) was the "Avoid suspending if we're in gadget mode" one, which you seemed to submit for 4.10-rc already. Let me know if there is anything you need prior to queuing the rest for 4.11. thanks -john -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5 v2] Fixes and workarounds for dwc2 on HiKey board
On 1/3/2017 11:52 AM, John Stultz wrote: > Hope everyone had a happy new years! > > I just wanted to send out my current queue of patches for dwc2 > controller on the HiKey board for consideration for the 4.11 > merge window. > > This does exclude my patchset[1] to add extcon support to dwc2, > which John Youn suspects a pending rework of the dwc2 fifo init > logic might make unnecssary. > > Any feedback would be greatly appreciated! > Hi John, Do you need these in 4.10-rc or is 4.11 ok? John -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/2] usb: gadget: s3c2410: add device tree support
This series adds support for configuring Samsung's s3c2410 and compatible USB device controller via device tree. Tested on FriendlyARM mini2440, based on s3c2440 SoC. Changes since v1: - change the USB bus clock name to "uclk" to better reflect the name used in the datasheet - improve samsung,vbus-gpio optional property description - specify the active state in the GPIOs properties Sergio Prado (2): dt-bindings: usb: add DT binding for s3c2410 USB device controller usb: gadget: s3c2410: allow probing from device tree .../devicetree/bindings/usb/s3c2410-usb.txt| 28 drivers/usb/gadget/udc/s3c2410_udc.c | 144 + drivers/usb/gadget/udc/s3c2410_udc.h | 4 + 3 files changed, 152 insertions(+), 24 deletions(-) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/2] dt-bindings: usb: add DT binding for s3c2410 USB device controller
Adds the device tree bindings description for Samsung S3C2410 and
compatible USB device controller.
Signed-off-by: Sergio Prado
---
.../devicetree/bindings/usb/s3c2410-usb.txt| 28 ++
1 file changed, 28 insertions(+)
diff --git a/Documentation/devicetree/bindings/usb/s3c2410-usb.txt
b/Documentation/devicetree/bindings/usb/s3c2410-usb.txt
index e45b38ce2986..28353eea31fd 100644
--- a/Documentation/devicetree/bindings/usb/s3c2410-usb.txt
+++ b/Documentation/devicetree/bindings/usb/s3c2410-usb.txt
@@ -20,3 +20,31 @@ usb0: ohci@4900 {
clocks = <&clocks UCLK>, <&clocks HCLK_USBH>;
clock-names = "usb-bus-host", "usb-host";
};
+
+Samsung S3C2410 and compatible USB device controller
+
+Required properties:
+ - compatible: Should be one of the following
+ "samsung,s3c2410-udc"
+ "samsung,s3c2440-udc"
+ - reg: address and length of the controller memory mapped region
+ - interrupts: interrupt number for the USB device controller
+ - clocks: Should reference the bus and host clocks
+ - clock-names: Should contain two strings
+ "uclk" for the USB bus clock
+ "usb-device" for the USB device clock
+
+Optional properties:
+ - samsung,vbus-gpio: specifies a gpio that allows to detect whether
+ vbus is present - USB is connected (active high, input).
+ - samsung,pullup-gpio: If present, specifies a gpio to control the
+ USB D+ pullup (active high, output).
+
+usb1: udc@5200 {
+ compatible = "samsung,s3c2440-udc";
+ reg = <0x5200 0x10>;
+ interrupts = <0 0 25 3>;
+ clocks = <&clocks UCLK>, <&clocks HCLK_USBD>;
+ clock-names = "usb-bus-gadget", "usb-device";
+ samsung,pullup-gpio = <&gpc 5 GPIO_ACTIVE_HIGH>;
+};
--
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 v2 2/2] usb: gadget: s3c2410: allow probing from device tree
Allows configuring Samsung's s3c2410 and compatible USB device
controller using a devicetree.
Signed-off-by: Sergio Prado
---
drivers/usb/gadget/udc/s3c2410_udc.c | 144 +--
drivers/usb/gadget/udc/s3c2410_udc.h | 4 +
2 files changed, 124 insertions(+), 24 deletions(-)
diff --git a/drivers/usb/gadget/udc/s3c2410_udc.c
b/drivers/usb/gadget/udc/s3c2410_udc.c
index 4643a01262b4..165a510b1971 100644
--- a/drivers/usb/gadget/udc/s3c2410_udc.c
+++ b/drivers/usb/gadget/udc/s3c2410_udc.c
@@ -30,6 +30,9 @@
#include
#include
#include
+#include
+#include
+#include
#include
#include
@@ -55,6 +58,18 @@
#define DRIVER_AUTHOR "Herbert Pötzl , " \
"Arnaud Patard "
+struct s3c2410_udc_drv_data {
+ int ep_fifo_size;
+};
+
+static const struct s3c2410_udc_drv_data s3c2410_udc_2410_drv_data = {
+ .ep_fifo_size = EP_FIFO_SIZE,
+};
+
+static const struct s3c2410_udc_drv_data s3c2410_udc_2440_drv_data = {
+ .ep_fifo_size = S3C2440_EP_FIFO_SIZE,
+};
+
static const char gadget_name[] = "s3c2410_udc";
static const char driver_desc[] = DRIVER_DESC;
@@ -62,8 +77,6 @@
static struct clk *udc_clock;
static struct clk *usb_bus_clock;
static void __iomem*base_addr;
-static u64 rsrc_start;
-static u64 rsrc_len;
static struct dentry *s3c2410_udc_debugfs_root;
static inline u32 udc_read(u32 reg)
@@ -997,7 +1010,7 @@ static irqreturn_t s3c2410_udc_irq(int dummy, void *_dev)
}
}
- dprintk(DEBUG_VERBOSE, "irq: %d s3c2410_udc_done.\n", IRQ_USBD);
+ dprintk(DEBUG_VERBOSE, "irq: %d s3c2410_udc_done.\n", dev->irq);
/* Restore old index */
udc_write(idx, S3C2410_UDC_INDEX_REG);
@@ -1757,6 +1770,49 @@ static int s3c2410_udc_stop(struct usb_gadget *g)
};
+static int s3c2410_udc_probe_dt(struct s3c2410_udc *udc)
+{
+ const struct s3c2410_udc_drv_data *drvdata;
+ struct platform_device *pdev = udc->pdev;
+ struct s3c2410_udc_mach_info *pdata;
+ int gpio;
+
+ drvdata = of_device_get_match_data(&pdev->dev);
+
+ if (drvdata)
+ udc->ep_fifo_size = drvdata->ep_fifo_size;
+
+ pdata = devm_kzalloc(&pdev->dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata)
+ return -ENOMEM;
+
+ gpio = of_get_named_gpio(pdev->dev.of_node, "samsung,vbus-gpio", 0);
+ if (gpio_is_valid(gpio))
+ pdata->vbus_pin = gpio;
+
+ gpio = of_get_named_gpio(pdev->dev.of_node, "samsung,pullup-gpio", 0);
+ if (gpio_is_valid(gpio))
+ pdata->pullup_pin = gpio;
+
+ pdev->dev.platform_data = pdata;
+
+ return 0;
+}
+
+static int s3c2410_udc_probe_pdata(struct s3c2410_udc *udc)
+{
+ const struct s3c2410_udc_drv_data *drvdata;
+ struct platform_device *pdev = udc->pdev;
+
+ drvdata = (struct s3c2410_udc_drv_data *)
+ platform_get_device_id(pdev)->driver_data;
+
+ if (drvdata)
+ udc->ep_fifo_size = drvdata->ep_fifo_size;
+
+ return 0;
+}
+
/*
* probe - binds to the platform device
*/
@@ -1769,7 +1825,17 @@ static int s3c2410_udc_probe(struct platform_device
*pdev)
dev_dbg(dev, "%s()\n", __func__);
- usb_bus_clock = clk_get(NULL, "usb-bus-gadget");
+ udc->pdev = pdev;
+
+ if (pdev->dev.of_node)
+ retval = s3c2410_udc_probe_dt(udc);
+ else
+ retval = s3c2410_udc_probe_pdata(udc);
+
+ if (retval)
+ return retval;
+
+ usb_bus_clock = clk_get(NULL, "uclk");
if (IS_ERR(usb_bus_clock)) {
dev_err(dev, "failed to get usb bus clock source\n");
return PTR_ERR(usb_bus_clock);
@@ -1789,24 +1855,27 @@ static int s3c2410_udc_probe(struct platform_device
*pdev)
dev_dbg(dev, "got and enabled clocks\n");
- if (strncmp(pdev->name, "s3c2440", 7) == 0) {
- dev_info(dev, "S3C2440: increasing FIFO to 128 bytes\n");
- memory.ep[1].fifo_size = S3C2440_EP_FIFO_SIZE;
- memory.ep[2].fifo_size = S3C2440_EP_FIFO_SIZE;
- memory.ep[3].fifo_size = S3C2440_EP_FIFO_SIZE;
- memory.ep[4].fifo_size = S3C2440_EP_FIFO_SIZE;
+ if (udc->ep_fifo_size) {
+ dev_info(dev, "setting FIFO to %d bytes\n", udc->ep_fifo_size);
+ memory.ep[1].fifo_size = udc->ep_fifo_size;
+ memory.ep[2].fifo_size = udc->ep_fifo_size;
+ memory.ep[3].fifo_size = udc->ep_fifo_size;
+ memory.ep[4].fifo_size = udc->ep_fifo_size;
}
spin_lock_init(&udc->lock);
udc_info = dev_get_platdata(&pdev->dev);
- rsrc_start = S3C2410_PA_USBDEV;
- rsrc_len = S3C24XX_SZ_USBDEV;
+ udc->mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!udc->mem) {
+
Re: [PATCH v5 0/6] inherit dma configuration from parent dev
[adding Arnd Bergmann who wrote the patches and I noticed was not cc'ed]
Hello,
On Tue, Jan 10, 2017 at 9:11 AM, Roger Quadros wrote:
> On 05/01/17 19:16, Greg KH wrote:
>> On Thu, Jan 05, 2017 at 05:21:09PM +0200, Roger Quadros wrote:
>>> Hi,
>>>
>>> On 17/11/16 13:43, Sriram Dash wrote:
For xhci-hcd platform device, all the DMA parameters are not
configured properly, notably dma ops for dwc3 devices.
The idea here is that you pass in the parent of_node along
with the child device pointer, so it would behave exactly
like the parent already does. The difference is that it also
handles all the other attributes besides the mask.
Arnd Bergmann (6):
usb: separate out sysdev pointer from usb_bus
usb: chipidea: use bus->sysdev for DMA configuration
usb: ehci: fsl: use bus->sysdev for DMA configuration
usb: xhci: use bus->sysdev for DMA configuration
usb: dwc3: use bus->sysdev for DMA configuration
usb: dwc3: Do not set dma coherent mask
>>>
>>> Only the dwc3 patches have been picked up for v4.10 and the rest are still
>>> missing.
>>> Any plans to pick them in the rc cycle?
>>>
>>> DMA configuration is still broken for XHCI on v4.10 and -next.
>>
>> It's always been broken, so it's not a big deal for 4.10 :)
>>
> OK. But I do see the following warning on xhci probe on TI platforms that use
> dwc3 IP. This is new in v4.10.
>
I see a similar warning on an Exynos5800 machine (Peach Pi). This is
new starting from v4.10-rc1.
> [ 11.664835] [ cut here ]
> [ 11.669693] WARNING: CPU: 1 PID: 534 at drivers/usb/host/xhci-plat.c:168
> xhci_plat_probe+0x180/0x450 [xhci_plat_hcd]
> [ 11.680765] Modules linked in: xhci_plat_hcd(+) xhci_hcd usbcore evdev
> dwc3 snd_soc_simple_card snd_soc_tlv320aic3x snd_soc_simple_card_utils
> udc_core m25p80 snd_soc_davinci_mcasp usb_common spi_nor snd_soc_e
> [ 11.726078] CPU: 1 PID: 534 Comm: modprobe Tainted: GW
> 4.10.0-rc3 #1075
> [ 11.734293] Hardware name: Generic DRA74X (Flattened Device Tree)
> [ 11.740695] [] (unwind_backtrace) from []
> (show_stack+0x10/0x14)
> [ 11.748829] [] (show_stack) from []
> (dump_stack+0xac/0xe0)
> [ 11.756413] [] (dump_stack) from [] (__warn+0xd8/0x104)
> [ 11.763722] [] (__warn) from []
> (warn_slowpath_null+0x20/0x28)
> [ 11.771675] [] (warn_slowpath_null) from []
> (xhci_plat_probe+0x180/0x450 [xhci_plat_hcd])
> [ 11.782110] [] (xhci_plat_probe [xhci_plat_hcd]) from
> [] (platform_drv_probe+0x4c/0xb0)
> [ 11.792338] [] (platform_drv_probe) from []
> (driver_probe_device+0x200/0x2d4)
> [ 11.801655] [] (driver_probe_device) from []
> (__driver_attach+0xc0/0xc4)
> [ 11.810518] [] (__driver_attach) from []
> (bus_for_each_dev+0x6c/0xa0)
> [ 11.819095] [] (bus_for_each_dev) from []
> (bus_add_driver+0x18c/0x214)
> [ 11.827767] [] (bus_add_driver) from []
> (driver_register+0x78/0xf8)
> [ 11.836167] [] (driver_register) from []
> (do_one_initcall+0x3c/0x174)
> [ 11.844751] [] (do_one_initcall) from []
> (do_init_module+0x5c/0x1d0)
> [ 11.853247] [] (do_init_module) from []
> (load_module+0x1d48/0x23a8)
> [ 11.861649] [] (load_module) from []
> (SyS_init_module+0x150/0x174)
> [ 11.869961] [] (SyS_init_module) from []
> (ret_fast_syscall+0x0/0x1c)
> [ 11.878494] ---[ end trace a0ca4c6c0c9a9ee9 ]---
> [ 11.883400] xhci-hcd xhci-hcd.0.auto: xHCI Host Controller
>
I tracked down to commit d64ff406e51e ("usb: dwc3: use bus->sysdev for
DMA configuration") which is part of this series. If I revert that
commit, the warning goes away.
Best regards,
Javier
--
To unsubscribe from this list: send the line "unsubscribe 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 4/4] ARM: dts: sun8i: add OTG function to Lichee Pi Zero
On Wed, Jan 11, 2017 at 02:08:11PM -0600, Bin Liu wrote:
> On Thu, Jan 12, 2017 at 03:55:33AM +0800, Icenowy Zheng wrote:
> >
> >
> > 11.01.2017, 04:24, "Bin Liu" :
> > > On Tue, Jan 03, 2017 at 11:25:34PM +0800, Icenowy Zheng wrote:
> > >> Lichee Pi Zero features a USB OTG port.
> > >>
> > >> Add support for it.
> > >>
> > >> Note: in order to use the Host mode, the board must be powered via the
> > >> +5V and GND pins.
> > >>
> > >> Signed-off-by: Icenowy Zheng
> > >> ---
> > >> arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts | 10 ++
> > >> 1 file changed, 10 insertions(+)
> > >>
> > >> diff --git a/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
> > >> b/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
> > >> index 0099affc6ce3..3d9168cbaeca 100644
> > >> --- a/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
> > >> +++ b/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
> > >> @@ -71,3 +71,13 @@
> > >> pinctrl-names = "default";
> > >> status = "okay";
> > >> };
> > >> +
> > >> +&usb_otg {
> > >> + dr_mode = "otg";
> > >
> > > Why not set this default mode in dtsi instead?
> > >
> > > Regards,
> > > -Bin.
> >
> > There's possibly boards which do not have OTG functions.
>
> That is board specific.
Exactly, and this is why it should be done in the board DT.
The controller in the Allwinner SoCs do not handle directly the ID pin
and VBUS, but rather rely on a GPIO to do so.
So boards with OTG will need setup anyway, at least to tell which
GPIOs are used. There's no point in enforcing a default if it doesn't
work by default.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
signature.asc
Description: PGP signature
Re: [PATCH net] r8152: fix the sw rx checksum is unavailable
From: Hayes Wang
Date: Wed, 11 Jan 2017 16:25:34 +0800
> Fix the hw rx checksum is always enabled, and the user couldn't switch
> it to sw rx checksum.
>
> Note that the RTL_VER_01 only support sw rx checksum only. Besides,
> the hw rx checksum for RTL_VER_02 is disabled after
> commit b9a321b48af4 ("r8152: Fix broken RX checksums."). Re-enable it.
>
> Signed-off-by: Hayes Wang
Applied and queued up for -stable, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] ARM: dts: sun8i: add OTG function to Lichee Pi Zero
On Thu, Jan 12, 2017 at 04:13:34AM +0800, Icenowy Zheng wrote:
>
>
> 12.01.2017, 04:08, "Bin Liu" :
> > On Thu, Jan 12, 2017 at 03:55:33AM +0800, Icenowy Zheng wrote:
> >> 11.01.2017, 04:24, "Bin Liu" :
> >> > On Tue, Jan 03, 2017 at 11:25:34PM +0800, Icenowy Zheng wrote:
> >> >> Lichee Pi Zero features a USB OTG port.
> >> >>
> >> >> Add support for it.
> >> >>
> >> >> Note: in order to use the Host mode, the board must be powered via the
> >> >> +5V and GND pins.
> >> >>
> >> >> Signed-off-by: Icenowy Zheng
> >> >> ---
> >> >> arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts | 10 ++
> >> >> 1 file changed, 10 insertions(+)
> >> >>
> >> >> diff --git a/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
> >> b/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
> >> >> index 0099affc6ce3..3d9168cbaeca 100644
> >> >> --- a/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
> >> >> +++ b/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
> >> >> @@ -71,3 +71,13 @@
> >> >> pinctrl-names = "default";
> >> >> status = "okay";
> >> >> };
> >> >> +
> >> >> +&usb_otg {
> >> >> + dr_mode = "otg";
> >> >
> >> > Why not set this default mode in dtsi instead?
> >> >
> >> > Regards,
> >> > -Bin.
> >>
> >> There's possibly boards which do not have OTG functions.
> >
> > That is board specific.
> >
> > You'd better to define the default dr_mode which the musb _controller_
> > supports in the dtsi, and then override it in a specific board dts if
> > necessary.
>
> Is there MUSB controllers which do not support a certain mode?
I am not aware of any. That is why I recommended to set "otg" in dtsi,
then override it in board dts if a port is specically designed to
host-only or device-only mode.
>
> (I remembered my omap3-n900 which do not work under OTG mode...)
I belive it is n900 board specific. omap3 itself doesn't have such
limitation, AFAIK.
Regards,
-Bin.
>
> >
> > Regards,
> > -Bin.
> >
> >> Even the official CDR design of V3s uses the USB controller to
> >> connect a UVC webcam to make the design a dual-cam design
> >> (V3s itself has a CSI).
> >>
> >> >
> >> >> + status = "okay";
> >> >> +};
> >> >> +
> >> >> +&usbphy {
> >> >> + usb0_id_det-gpio = <&pio 5 6 GPIO_ACTIVE_HIGH>;
> >> >> + status = "okay";
> >> >> +};
> >> >> --
> >> >> 2.11.0
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] ARM: dts: sun8i: add OTG function to Lichee Pi Zero
On Thu, Jan 12, 2017 at 03:55:33AM +0800, Icenowy Zheng wrote:
>
>
> 11.01.2017, 04:24, "Bin Liu" :
> > On Tue, Jan 03, 2017 at 11:25:34PM +0800, Icenowy Zheng wrote:
> >> Lichee Pi Zero features a USB OTG port.
> >>
> >> Add support for it.
> >>
> >> Note: in order to use the Host mode, the board must be powered via the
> >> +5V and GND pins.
> >>
> >> Signed-off-by: Icenowy Zheng
> >> ---
> >> arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts | 10 ++
> >> 1 file changed, 10 insertions(+)
> >>
> >> diff --git a/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
> >> b/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
> >> index 0099affc6ce3..3d9168cbaeca 100644
> >> --- a/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
> >> +++ b/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
> >> @@ -71,3 +71,13 @@
> >> pinctrl-names = "default";
> >> status = "okay";
> >> };
> >> +
> >> +&usb_otg {
> >> + dr_mode = "otg";
> >
> > Why not set this default mode in dtsi instead?
> >
> > Regards,
> > -Bin.
>
> There's possibly boards which do not have OTG functions.
That is board specific.
You'd better to define the default dr_mode which the musb _controller_
supports in the dtsi, and then override it in a specific board dts if
necessary.
Regards,
-Bin.
>
> Even the official CDR design of V3s uses the USB controller to
> connect a UVC webcam to make the design a dual-cam design
> (V3s itself has a CSI).
>
> >
> >> + status = "okay";
> >> +};
> >> +
> >> +&usbphy {
> >> + usb0_id_det-gpio = <&pio 5 6 GPIO_ACTIVE_HIGH>;
> >> + status = "okay";
> >> +};
> >> --
> >> 2.11.0
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [v4.4.40] patch backport error
On Wed, Jan 11, 2017 at 07:13:30PM +0200, Felipe Balbi wrote: > > hi, > > Bin Liu writes: > > I am unable to figure out what was happening, but there seems to be a > > patch backport error in v4.4.40. > > > > Commit c53af76d5de1 (usb: gadget: composite: always set ep->mult to a > > sensible value) is backported from upstream > > eaa496ffaaf19591fe471a36cef366146eeb9153, however c53af76d5de1 has > > > > + _ep->mult = usb_endpoint_maxp(_ep->desc) & 0x7ff; > > > > but eaa496ffaaf19591fe471a36cef366146eeb9153 has > > > > + _ep->mult = usb_endpoint_maxp_mult(_ep->desc); > > > > they are not consistant. > > > > I haven't checked v4.9 yet, not sure if this happens there too. > > oh-oh. you're correct, I sent the wrong patch :-( > > I'll send a correct patch tomorrow. Greg, do you want a revert followed > by correct patch, or just fix-up patch? A simple fixup is fine. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH -next] usb: musb: dsps: make dsps_musb_clear_ep_rxintr() static
On Wed, Jan 11, 2017 at 04:44:02PM +, Wei Yongjun wrote:
> From: Wei Yongjun
>
> Fixes the following sparse warning:
>
> drivers/usb/musb/musb_dsps.c:270:6: warning:
> symbol 'dsps_musb_clear_ep_rxintr' was not declared. Should it be static?
>
> Signed-off-by: Wei Yongjun
Applied. Thanks for catching this.
-Bin.
> ---
> drivers/usb/musb/musb_dsps.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
> index 9f125e1..144e7e0 100644
> --- a/drivers/usb/musb/musb_dsps.c
> +++ b/drivers/usb/musb/musb_dsps.c
> @@ -267,7 +267,7 @@ static void otg_timer(unsigned long _musb)
> pm_runtime_put_autosuspend(dev);
> }
>
> -void dsps_musb_clear_ep_rxintr(struct musb *musb, int epnum)
> +static void dsps_musb_clear_ep_rxintr(struct musb *musb, int epnum)
> {
> u32 epintr;
> struct dsps_glue *glue = dev_get_drvdata(musb->controller->parent);
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 1/2] USB: add switch to turn off padding of resume time delays
On Wed, 11 Jan 2017, Felipe Balbi wrote: > Hi, > > Todd Brandt writes: > > On Mon, 2017-01-09 at 09:44 +0100, Oliver Neukum wrote: > >> On Fri, 2017-01-06 at 16:45 -0800, Todd Brandt wrote: > >> > Add a kernel parameter that replaces the USB_RESUME_TIMEOUT > >> > and other hardcoded delay numbers with the USB spec minimums. > >> > >> Hi, > >> > >> the problem with that is that distros cannot use it. It is obviously > >> better than nothing but it seems to me that we can do better than an > >> all or nothing option here. > > > > Well my main purpose in getting this out there is to get the seed > > planted for further optimization. The focus right now is just advanced > > users who want to optimize their personal machines. > > > > But you're right, it wouldn't be responsible to enable this feature by > > default in a distro like android or chromium. > > > >> For example it would be much safer to enable this for hubs of the > >> first level and internal devices. > > I disagree. I think it's only safe to do so for devices known to be > compliant. This would mean, we need to start building a whitelist of > compliant devices and only for such devices should we enforce compliant > behavior. > > > Is there a universal way to reliably determine which USB devices are > > internal? > > not that I know of :-( These devices are enumerated the same way as any > other. We have udev->removable. It's based on information provided by the firmware, so it may not be extremely reliable. Generally, you could assume that if udev->removable is set and udev's parent is the root hub then udev is an internal device. On the other hand, I don't know any reason to assume that internal devices are more compliant as regards reset/resume timing than any other devices. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 1/2] USB: add switch to turn off padding of resume time delays
Hi, Todd Brandt writes: > On Mon, 2017-01-09 at 09:44 +0100, Oliver Neukum wrote: >> On Fri, 2017-01-06 at 16:45 -0800, Todd Brandt wrote: >> > Add a kernel parameter that replaces the USB_RESUME_TIMEOUT >> > and other hardcoded delay numbers with the USB spec minimums. >> >> Hi, >> >> the problem with that is that distros cannot use it. It is obviously >> better than nothing but it seems to me that we can do better than an >> all or nothing option here. > > Well my main purpose in getting this out there is to get the seed > planted for further optimization. The focus right now is just advanced > users who want to optimize their personal machines. > > But you're right, it wouldn't be responsible to enable this feature by > default in a distro like android or chromium. > >> For example it would be much safer to enable this for hubs of the >> first level and internal devices. I disagree. I think it's only safe to do so for devices known to be compliant. This would mean, we need to start building a whitelist of compliant devices and only for such devices should we enforce compliant behavior. > Is there a universal way to reliably determine which USB devices are > internal? not that I know of :-( These devices are enumerated the same way as any other. -- balbi -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 1/2] USB: add switch to turn off padding of resume time delays
On Sat, 2017-01-07 at 11:58 -0500, Alan Stern wrote: > On Fri, 6 Jan 2017, Todd Brandt wrote: > > > Add a kernel parameter that replaces the USB_RESUME_TIMEOUT > > and other hardcoded delay numbers with the USB spec minimums. > > > > The USB subsystem currently uses some padded values for USB spec timing > > delays. This patch keeps the current values by default, but if the kernel > > is booted with usbcore.timing_minimum=1 they are set to the spec minimums > > with no padding. The result is significant performance improvement in usb > > device resume. > > > > - tdrsmdn: resume signal time (min=20ms, cur=40ms) usb2.0 spec 7.1.7.7 > > - trsmrcy: resume recovery time (min=10ms, cur=10ms) usb2.0 spec 7.1.7.7 > > - trstrcy: reset recovery time (min=0ms, cur=50ms) usb2.0 spec 7.1.7.5 > > - tdrstr: root port reset time (min=50ms, cur=50ms) usb2.0 spec 7.1.7.5 > > > > Example analyze_suspend runs are provided here showing the benefits: > > https://01.org/suspendresume/blogs/tebrandt/2016/usb-resume-optimization-using-spec-minimum-delays > > > > Signed-off-by: Todd Brandt > > --- > > v2: > > - moved the core code from hub.c to usb.c > > - param name is now usb_timing_minimum > > - configured isp1362-hcd and ohci-hub to use the new values > > v3: > > - changed param to usbcore.timing_minimum > > v4: > > - moved usb_timing object to usb-common > > v5: > > - added tdrstr and used it in uhci-hub > > You forgot to modify the comments accordingly... > > > --- a/include/linux/usb.h > > +++ b/include/linux/usb.h > > @@ -233,8 +233,32 @@ void usb_put_intf(struct usb_interface *intf); > > * In order to avoid both conditions, we're using a 40 ms resume timeout, > > which > > * should cope with both LPJ calibration errors and devices not following > > every > > * detail of the USB Specification. > > + * > > + * struct _usb_timing_config - USB timing value settings > > + * @tdrsmdn: TDRSMDN resume signal time7.1.7.7 > > + * @trsmrcy; TRSMRCY resume recovery time 7.1.7.7 > > + * @trstrcy; TRSTRCY reset recovery time 7.1.7.5 > > Here. good catch, sorry about that. > > > + * > > + * These timing values are defined in the USB 2.0 spec sec 7.3.2 table 7-13 > > + * Thir default values have been padded for various reasons and this config > > + * allows the system to use different values. > > */ > > -#define USB_RESUME_TIMEOUT 40 /* ms */ > > +#define USB_TIMING_TDRSMDN_MIN 20 > > +#define USB_TIMING_TRSMRCY_MIN 10 > > +#define USB_TIMING_TRSTRCY_MIN 0 > > +#define USB_TIMING_TDRSTR_MIN 50 > > +#define USB_TIMING_TDRSMDN_DEF 40 > > +#define USB_TIMING_TRSMRCY_DEF 10 > > +#define USB_TIMING_TRSTRCY_DEF 50 > > +#define USB_TIMING_TDRSTR_DEF 50 > > Otherwise, the core, uhci, ohci, and ehci parts look good to me. > > Alan Stern > -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 1/2] USB: add switch to turn off padding of resume time delays
On Mon, 2017-01-09 at 09:44 +0100, Oliver Neukum wrote: > On Fri, 2017-01-06 at 16:45 -0800, Todd Brandt wrote: > > Add a kernel parameter that replaces the USB_RESUME_TIMEOUT > > and other hardcoded delay numbers with the USB spec minimums. > > Hi, > > the problem with that is that distros cannot use it. It is obviously > better than nothing but it seems to me that we can do better than an > all or nothing option here. Well my main purpose in getting this out there is to get the seed planted for further optimization. The focus right now is just advanced users who want to optimize their personal machines. But you're right, it wouldn't be responsible to enable this feature by default in a distro like android or chromium. > For example it would be much safer to enable this for hubs of the > first level and internal devices. Is there a universal way to reliably determine which USB devices are internal? > > Regards > Oliver > > -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/4] usb: dwc2: Add binding for AHB burst
On Tuesday, January 10, 2017 3:23:24 PM CET John Youn wrote: > On 1/10/2017 3:03 PM, Christian Lamparter wrote: > > On Tuesday, January 10, 2017 1:46:56 PM CET John Youn wrote: > >> On 12/19/2016 6:49 AM, Christian Lamparter wrote: > >>> (Lot's of old stuff, that doesn't matter anymore) > > > > Hello John, > > > >> This should be fixed against the latest dwc2 param rework series [1] > >> which i hope to get queued for 4.11. If you can give it a test, that > >> would be great. > > > > oh Ok. I see you added it to > > "[PATCH 16/21] usb: dwc2: Remove platform static params" [0]. > > Yes, I think this should work nicely. Thank you very much for > > your time, even though it's just for like "one old board" :-). > > No problem. Sorry for the delay getting the param stuff sorted. > > > > > Do you have a public git tree with your patches that I can > > clone/checkout? If not, I'll take some time on the weekend > > for this and write back on monday. But yeah, this should > > work. > Yes check here on branch 'next' > > https://github.com/synopsys-usb/linux.git Ok thanks. I cloned it and built a new kernel for the thing. >From the (attached) bootlog: GAHBCFG @0xD1210008 : 0x002E 0x2E = Bit 5 | (Bit 3 | Bit 2 | Bit 1) = GAHBCFG_DMA_EN | (GAHBCFG_HBSTLEN_INCR16 << GAHBCFG_HBSTLEN_SHIFT) I've attached an old 1GiB USB-Stick to the dwc2 managed port and it does work as expected. The same goes for a usb-3.0 HDD and a USB 2.0 11n WLAN stick. (All while the DWC SATA is copying data). Tested-by: Christian Lamparter Again, thank you for your work! Regards, Christian --- These are the kernel messages. dwc2 4bff8.usbotg: mapped PA bff8 to VA d121 dwc2 4bff8.usbotg: registering common handler for irq35 dwc2 4bff8.usbotg: Forcing mode to host dwc2 4bff8.usbotg: Core Release: 2.90a (snpsid=4f54290a) dwc2 4bff8.usbotg: Forcing mode to host dwc2 4bff8.usbotg: DWC OTG HCD INIT dwc2 4bff8.usbotg: hcfg=0200 dwc2 4bff8.usbotg: dwc2_core_init(ca890810) dwc2 4bff8.usbotg: HS UTMI+ PHY selected dwc2 4bff8.usbotg: Internal DMA Mode dwc2 4bff8.usbotg: host_dma:1 dma_desc_enable:0 dwc2 4bff8.usbotg: Using Buffer DMA mode dwc2 4bff8.usbotg: Host Mode dwc2 4bff8.usbotg: DWC OTG Controller dwc2 4bff8.usbotg: new USB bus registered, assigned bus number 1 dwc2 4bff8.usbotg: irq 35, io mem 0x dwc2 4bff8.usbotg: DWC OTG HCD START dwc2 4bff8.usbotg: dwc2_core_host_init(ca890810) dwc2 4bff8.usbotg: Initializing HCFG.FSLSPClkSel to dwc2 4bff8.usbotg: initial grxfsiz=0213 dwc2 4bff8.usbotg: new grxfsiz=0213 dwc2 4bff8.usbotg: initial gnptxfsiz=01000213 dwc2 4bff8.usbotg: new gnptxfsiz=01000213 dwc2 4bff8.usbotg: initial hptxfsiz=01000313 dwc2 4bff8.usbotg: new hptxfsiz=01000313 dwc2 4bff8.usbotg: dwc2_core_host_init: Halt channel 0 dwc2 4bff8.usbotg: dwc2_core_host_init: Halt channel 1 dwc2 4bff8.usbotg: dwc2_core_host_init: Halt channel 2 dwc2 4bff8.usbotg: dwc2_core_host_init: Halt channel 3 dwc2 4bff8.usbotg: Init: Port Power? op_state=9 dwc2 4bff8.usbotg: Init: Power Port (0) dwc2 4bff8.usbotg: dwc2_enable_host_interrupts() dwc2 4bff8.usbotg: DWC OTG HCD Has Root Hub dwc2 4bff8.usbotg: DWC OTG HCD EP RESET: bEndpointAddress=0x81 hub 1-0:1.0: USB hub found dwc2 4bff8.usbotg: GetHubDescriptor hub 1-0:1.0: 1 port detected dwc2 4bff8.usbotg: GetHubStatus dwc2 4bff8.usbotg: SetPortFeature dwc2 4bff8.usbotg: dwc2 4bff8.usbotg: dwc2 4bff8.usbotg: HCD State: dwc2 4bff8.usbotg: Num channels: 4 dwc2 4bff8.usbotg: Channel 0: dwc2 4bff8.usbotg: dev_addr: 0, ep_num: 0, ep_is_in: 0 dwc2 4bff8.usbotg: speed: 0 dwc2 4bff8.usbotg: ep_type: 0 dwc2 4bff8.usbotg: max_packet: 0 dwc2 4bff8.usbotg: data_pid_start: 0 dwc2 4bff8.usbotg: multi_count: 0 dwc2 4bff8.usbotg: xfer_started: 0 dwc2 4bff8.usbotg: xfer_buf: (null) dwc2 4bff8.usbotg: xfer_dma: dwc2 4bff8.usbotg: xfer_len: 0 dwc2 4bff8.usbotg: xfer_count: 0 dwc2 4bff8.usbotg: halt_on_queue: 0 dwc2 4bff8.usbotg: halt_pending: 0 dwc2 4bff8.usbotg: halt_status: 0 dwc2 4bff8.usbotg: do_split: 0 dwc2 4bff8.usbotg: complete_split: 0 dwc2 4bff8.usbotg: hub_addr: 0 dwc2 4bff8.usbotg: hub_port: 0 dwc2 4bff8.usbotg: xact_pos: 0 dwc2 4bff8.usbotg: requests: 0 dwc2 4bff8.usbotg: qh: (null) dwc2 4bff8.usbotg: Channel 1: dwc2 4bff8.usbotg: dev_addr: 0, ep_num: 0, ep_is_in: 0 dwc2 4bff8.usbotg: speed: 0 dwc2 4bff8.usbotg: ep_type: 0 dwc2 4bff8.usbotg: max_packet: 0 dwc2 4bff8.usbotg: data_pid_start: 0 dwc2 4bff8.usbotg: multi_count: 0 dwc2 4bff8.usbotg: xfer_started: 0 dwc2 4bff8.usbotg:
Re: [v4.4.40] patch backport error
Hi, Bin Liu writes: > On Wed, Jan 11, 2017 at 07:13:30PM +0200, Felipe Balbi wrote: >> >> hi, >> >> Bin Liu writes: >> > I am unable to figure out what was happening, but there seems to be a >> > patch backport error in v4.4.40. >> > >> > Commit c53af76d5de1 (usb: gadget: composite: always set ep->mult to a >> > sensible value) is backported from upstream >> > eaa496ffaaf19591fe471a36cef366146eeb9153, however c53af76d5de1 has >> > >> > + _ep->mult = usb_endpoint_maxp(_ep->desc) & 0x7ff; >> > >> > but eaa496ffaaf19591fe471a36cef366146eeb9153 has >> > >> > + _ep->mult = usb_endpoint_maxp_mult(_ep->desc); >> > >> > they are not consistant. >> > >> > I haven't checked v4.9 yet, not sure if this happens there too. >> >> oh-oh. you're correct, I sent the wrong patch :-( > > so you sent a separate set to stable? I thought it was directly back > ported from upstream which has the correct version? well, it had to be manually backported to do away with the dependency on usb_endpoint_maxp_mult(), but I ended up reimplementing usb_endpoint_maxp() correctly instead of actually extracting high bits of wMaxPacketSize -- 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: [v4.4.40] patch backport error
On Wed, Jan 11, 2017 at 11:13:05AM -0600, Bin Liu wrote: > Hi, > > I am unable to figure out what was happening, but there seems to be a > patch backport error in v4.4.40. > > Commit c53af76d5de1 (usb: gadget: composite: always set ep->mult to a > sensible value) is backported from upstream > eaa496ffaaf19591fe471a36cef366146eeb9153, however c53af76d5de1 has > > + _ep->mult = usb_endpoint_maxp(_ep->desc) & 0x7ff; > > but eaa496ffaaf19591fe471a36cef366146eeb9153 has > > + _ep->mult = usb_endpoint_maxp_mult(_ep->desc); > > they are not consistant. > > I haven't checked v4.9 yet, not sure if this happens there too. v4.9 seem to have the same issue too. Regards, -Bin. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [v4.4.40] patch backport error
On Wed, Jan 11, 2017 at 07:13:30PM +0200, Felipe Balbi wrote: > > hi, > > Bin Liu writes: > > I am unable to figure out what was happening, but there seems to be a > > patch backport error in v4.4.40. > > > > Commit c53af76d5de1 (usb: gadget: composite: always set ep->mult to a > > sensible value) is backported from upstream > > eaa496ffaaf19591fe471a36cef366146eeb9153, however c53af76d5de1 has > > > > + _ep->mult = usb_endpoint_maxp(_ep->desc) & 0x7ff; > > > > but eaa496ffaaf19591fe471a36cef366146eeb9153 has > > > > + _ep->mult = usb_endpoint_maxp_mult(_ep->desc); > > > > they are not consistant. > > > > I haven't checked v4.9 yet, not sure if this happens there too. > > oh-oh. you're correct, I sent the wrong patch :-( so you sent a separate set to stable? I thought it was directly back ported from upstream which has the correct version? Regards, -Bin. > > I'll send a correct patch tomorrow. Greg, do you want a revert followed > by correct patch, or just fix-up patch? > > -- > 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: [v4.4.40] patch backport error
hi, Bin Liu writes: > I am unable to figure out what was happening, but there seems to be a > patch backport error in v4.4.40. > > Commit c53af76d5de1 (usb: gadget: composite: always set ep->mult to a > sensible value) is backported from upstream > eaa496ffaaf19591fe471a36cef366146eeb9153, however c53af76d5de1 has > > + _ep->mult = usb_endpoint_maxp(_ep->desc) & 0x7ff; > > but eaa496ffaaf19591fe471a36cef366146eeb9153 has > > + _ep->mult = usb_endpoint_maxp_mult(_ep->desc); > > they are not consistant. > > I haven't checked v4.9 yet, not sure if this happens there too. oh-oh. you're correct, I sent the wrong patch :-( I'll send a correct patch tomorrow. Greg, do you want a revert followed by correct patch, or just fix-up patch? -- 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
[v4.4.40] patch backport error
Hi, I am unable to figure out what was happening, but there seems to be a patch backport error in v4.4.40. Commit c53af76d5de1 (usb: gadget: composite: always set ep->mult to a sensible value) is backported from upstream eaa496ffaaf19591fe471a36cef366146eeb9153, however c53af76d5de1 has + _ep->mult = usb_endpoint_maxp(_ep->desc) & 0x7ff; but eaa496ffaaf19591fe471a36cef366146eeb9153 has + _ep->mult = usb_endpoint_maxp_mult(_ep->desc); they are not consistant. I haven't checked v4.9 yet, not sure if this happens there too. Regards, -Bin. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: musb: Add support for optional VBUS irq to dsps glue layer
* Bin Liu [170111 05:42]:
> On Tue, Jan 10, 2017 at 01:53:53PM -0600, Bin Liu wrote:
> > On Thu, Jan 05, 2017 at 11:12:59AM -0800, Tony Lindgren wrote:
> > > We can now configure the PMIC interrupt to provide us VBUS
> > > events. In that case we don't need to constantly poll the
> > > status and can make it optional. This is only wired up
> > > for the mini-B interface on beaglebone.
> >
> > Is it possible someone designed a board which hooks up the vbus of a
> > dual-role/otg port to PMIC? The port wouldn't be able to detect the
> > attach since no polling anymore.
>
> I haven't seen any am335xx design other than the Beaglebone, that routes
> VBUS to PMIC, and I guess the reason that Beaglebone did this way is
> only for supporting bus-powered.
Yeah I guess that remains to be seen. I guess it could also be configured
to use any 5V GPIO in the dts and ideally and work the same way.
> > > +static int dsps_setup_optional_vbus_irq(struct platform_device *pdev,
> > > + struct dsps_glue *glue)
> > > +{
> > > + int error;
> > > +
>
> How about check dr_mode at here, and simply return if dr_mode is not
> "peripheral". So this ensures this VBUS irq is only used for device
> mode, it clear my concern above.
Yeah OK I like your idea of limiting it to peripheral only for now.
Will repost with your other comments addressed also.
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: dwc3 dwc3_exynos_probe() change goto labels to meaningful names
Hello Shuah,
On 01/11/2017 01:45 PM, Shuah Khan wrote:
> Change goto labels to meaningful names from a series of errNs.
>
> Signed-off-by: Shuah Khan
> ---
> drivers/usb/dwc3/dwc3-exynos.c | 22 +++---
> 1 file changed, 11 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c
> index f7421c2..ea50f74 100644
> --- a/drivers/usb/dwc3/dwc3-exynos.c
> +++ b/drivers/usb/dwc3/dwc3-exynos.c
> @@ -147,53 +147,53 @@ static int dwc3_exynos_probe(struct platform_device
> *pdev)
> exynos->vdd33 = devm_regulator_get(dev, "vdd33");
> if (IS_ERR(exynos->vdd33)) {
> ret = PTR_ERR(exynos->vdd33);
> - goto err2;
> + goto vdd33_err;
> }
I think it's better to use as labels what will be done in the error path
rather than what failed. IOW, "disable_axius_clk" or "disable_clks" are
more clear than vdd33_err for me, since can give you an idea of what will
happen in the error path.
But I don't have a strong opinion and your naming is an improvement over
the current one, so:
Reviewed-by: Javier Martinez Canillas
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb: dwc3 dwc3_exynos_probe() change goto labels to meaningful names
Change goto labels to meaningful names from a series of errNs.
Signed-off-by: Shuah Khan
---
drivers/usb/dwc3/dwc3-exynos.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c
index f7421c2..ea50f74 100644
--- a/drivers/usb/dwc3/dwc3-exynos.c
+++ b/drivers/usb/dwc3/dwc3-exynos.c
@@ -147,53 +147,53 @@ static int dwc3_exynos_probe(struct platform_device *pdev)
exynos->vdd33 = devm_regulator_get(dev, "vdd33");
if (IS_ERR(exynos->vdd33)) {
ret = PTR_ERR(exynos->vdd33);
- goto err2;
+ goto vdd33_err;
}
ret = regulator_enable(exynos->vdd33);
if (ret) {
dev_err(dev, "Failed to enable VDD33 supply\n");
- goto err2;
+ goto vdd33_err;
}
exynos->vdd10 = devm_regulator_get(dev, "vdd10");
if (IS_ERR(exynos->vdd10)) {
ret = PTR_ERR(exynos->vdd10);
- goto err3;
+ goto vdd10_err;
}
ret = regulator_enable(exynos->vdd10);
if (ret) {
dev_err(dev, "Failed to enable VDD10 supply\n");
- goto err3;
+ goto vdd10_err;
}
ret = dwc3_exynos_register_phys(exynos);
if (ret) {
dev_err(dev, "couldn't register PHYs\n");
- goto err4;
+ goto phys_err;
}
if (node) {
ret = of_platform_populate(node, NULL, NULL, dev);
if (ret) {
dev_err(dev, "failed to add dwc3 core\n");
- goto err5;
+ goto populate_err;
}
} else {
dev_err(dev, "no device node, failed to add dwc3 core\n");
ret = -ENODEV;
- goto err5;
+ goto populate_err;
}
return 0;
-err5:
+populate_err:
platform_device_unregister(exynos->usb2_phy);
platform_device_unregister(exynos->usb3_phy);
-err4:
+phys_err:
regulator_disable(exynos->vdd10);
-err3:
+vdd10_err:
regulator_disable(exynos->vdd33);
-err2:
+vdd33_err:
clk_disable_unprepare(exynos->axius_clk);
axius_clk_err:
clk_disable_unprepare(exynos->susp_clk);
--
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 -next] usb: musb: dsps: make dsps_musb_clear_ep_rxintr() static
From: Wei Yongjun
Fixes the following sparse warning:
drivers/usb/musb/musb_dsps.c:270:6: warning:
symbol 'dsps_musb_clear_ep_rxintr' was not declared. Should it be static?
Signed-off-by: Wei Yongjun
---
drivers/usb/musb/musb_dsps.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 9f125e1..144e7e0 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -267,7 +267,7 @@ static void otg_timer(unsigned long _musb)
pm_runtime_put_autosuspend(dev);
}
-void dsps_musb_clear_ep_rxintr(struct musb *musb, int epnum)
+static void dsps_musb_clear_ep_rxintr(struct musb *musb, int epnum)
{
u32 epintr;
struct dsps_glue *glue = dev_get_drvdata(musb->controller->parent);
--
To unsubscribe from this list: send the line "unsubscribe 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: dwc3: add support for hardware with multiple ports on USB2 hub enabled
On Mon, Jan 9, 2017 at 2:05 PM, Felipe Balbi wrote: > > Hi, > > Martin Blumenstingl writes: >> On Mon, Jan 9, 2017 at 1:39 PM, Felipe Balbi >> wrote: >>> >>> Hi, >>> >>> Martin Blumenstingl writes: >>> >>> [snip] >>> >>> true. But even so, that PHY handle is only needed for devices which >>> weren't properly configured at coreConsultant time. >> I don't understand that - there are two separate modules involved >> here: 1. the dwc3 IP block 2. Amlogic's own USB2 PHYs (they did not >> choose Synopsys DesignWare PHYs) >> (some background info: the USB2 PHYs are in "reset mode" by default) >> So even if the dwc3 IP block is configured correctly at coreConsultant >> time we still need to configure the PHYs. From "USB controller driver" >> (could be dwc3, or some generic hcd.c code, etc.) this means that >> phy_init() and phy_power_on() needs to be called for each of the three >> "Amlogic USB2 PHYs". the current code however only calls these for the >> first PHY (leaving the others in reset mode = disabled). > > argh, good point. In that case, we need to figure out the best way to > pass all these handles to xHCI-plat OK, I assume that we want to let xHCI-plat manage the PHYs in the future instead of doing this in dwc3 (dwc3 may have to pass these to xHCI-plat, but it should not do the logic on it's own)? >>> >>> perhaps. Maybe that mode check for dwc3 to bail out if mode == Host >>> should be done earlier. >> I guess your idea is to let xHCI-plat handle all phy_* logic when in >> host-mode? > > right. I guess at the end of the day host-only dwc3 instances shouldn't > need dwc3.ko at all. Only peripheral-only and dual-role implementations > should rely on dwc3.ko. interesting thought, I guess that makes sense! > okay, in that case this is less important for you. We should really make > sure we don't cause problems for a future dual-role support. > >> like you mentioned PHY[0] is used for dual-role mode. There is an >> additional USB3 PHY which also does mode-detection (in otg mode). >> when that USB3 PHY/mode-detection block detects that it has to switch >> to device mode it re-configures USB2 PHY[0] accordingly. > > okay > >> however it doesn't stop here: after that it goes ahead and turns on an >> additional dwc2 (yes, dwc2, not dwc3!) IP block which is limited to >> "device" (peripheral) mode only. > > hehe, that's interesting :-) > >> So on Amlogic GXL and GXM SoCs host-mode is handled by dwc3 while >> device-mode is handled by dwc2 > > so you have host-only dwc3 (for all practical reasons, a standard xHCI) > and a peripheral only dwc2. Good to know. I wonder why it was done this > way. Maybe Amlogic didn't pay for dual-role dwc3 license? I don't know any details how this decision was made but licensing costs may have been the reason (it may also be the same reason why they chose to enable multiple USB ports on just one dwc3 instance). Please note that this is just pure speculation and no official information (as I don't have that)! that would result in a few functions (function names are just to illustrate my idea): - devm_get_all_phys_from_of_node() - all_phys_init_and_power_on() (phy_init and phy_power_on always seem to be used together) - all_phys_power_off_and_exit() (phy_power_off and phy_exit always seem to be used together) let me know what you think >>> >>> I like that, specially so if it's done generically and all HCD drivers >>> just use the same piece of code. >> great! >> how should we proceed: should I come up with a first RFC so we can >> then discuss issues/improvements based on that RFC patch? > > yeah, that's usually the way :-) I sent a first draft to the linux-usb list with the subject "[RFC PATCH 0/2] initialize (multiple) PHYs in xhci-plat" (which does not show up in the usual web-archives yet) Regards, Martin -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 0/2] initialize (multiple) PHYs in xhci-plat
This series is the outcome of a discussion with Felipe Balbi, see [0] and [1]. The quick-summary of this is: - dwc3 already takes one USB2 and one USB3 PHY and initializes these correct - some other HCI platform drivers (like ehci-platform.c, xhci-mtk.c and ohci-platform.c) do not have a limitation on the number of PHYs - they support one PHY per actual host port - Amlogic Meson GXL and GXM SoCs come with a dwc3 IP block which has two or three USB2 ports enabled on the internal root-hub. The SoCs also provide separate USB2 PHYs, one per port. All USB2 PHYs (which are internally "connected" to the dwc3 roothub) need to be powered on, otherwise USB devices cannot be enumerated (even if just one PHY is disabled and if the device is plugged into another, enabled port) In my first attempt to get USB supported on the GXL and GXM SoCs I tried to work-around the problem that I could not pass multiple PHYs to the dwc3 controller. This was rejected by Rob Herring (which was definitely the thing to do in my opinion), see [2] This series adds a new "platform-roothub". This can be configured through devicetree by passing a child-node with "reg = <0>" to the USB controller. Additionally there has to be a child-node for each port on the root-hub. Each of the child-nodes takes a "phys" and "phy-names" property. This allows modeling the root-hub in devicetree similar to the USB device binding (documented in devicetree/bindings/usb/usb-device.txt) This avoids and backwards-compatibility problems (which was a concern regardless of the solution, see [3]) since the binding for the root-hub was previously not specified (and we're not using the "phys" property of the controller, which might have served different purposes before, depending on the drivers). Additionally this integrates the new platform-roothub into xhci-plat.c which automatically enables it for the dwc3 driver (in host-mode). [0] http://lists.infradead.org/pipermail/linux-amlogic/2017-January/001945.html [1] http://lists.infradead.org/pipermail/linux-amlogic/2017-January/001947.html [2] http://lists.infradead.org/pipermail/linux-amlogic/2016-November/001818.html [3] http://lists.infradead.org/pipermail/linux-amlogic/2017-January/001948.html Martin Blumenstingl (2): usb: host: add a generic platform USB roothub driver usb: host: xhci: plat: integrate the platform-roothub .../devicetree/bindings/usb/usb-roothub.txt| 41 ++ Documentation/devicetree/bindings/usb/usb-xhci.txt | 7 + drivers/usb/host/Kconfig | 4 + drivers/usb/host/Makefile | 2 + drivers/usb/host/platform-roothub.c| 146 + drivers/usb/host/platform-roothub.h| 14 ++ drivers/usb/host/xhci-plat.c | 37 +- drivers/usb/host/xhci.h| 3 + 8 files changed, 251 insertions(+), 3 deletions(-) create mode 100644 Documentation/devicetree/bindings/usb/usb-roothub.txt create mode 100644 drivers/usb/host/platform-roothub.c create mode 100644 drivers/usb/host/platform-roothub.h -- 2.11.0 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 2/2] usb: host: xhci: plat: integrate the platform-roothub
This enables the platform-roothub for the xhci-plat driver. This allows
specifying a PHY for each port via devicetree. All PHYs will then be
enabled/disabled by the platform-roothub driver.
One example where this is required is the Amlogic GXL and GXM SoCs:
They are using a dwc3 USB controller with up to three ports enabled on
the internal roothub. Using only the top-level "phy" properties does not
work here since one can only specify one "usb2-phy" and one "usb3-phy",
while actually at least two "usb2-phy" have to be specified.
Signed-off-by: Martin Blumenstingl
---
Documentation/devicetree/bindings/usb/usb-xhci.txt | 7
drivers/usb/host/Kconfig | 1 +
drivers/usb/host/xhci-plat.c | 37 --
drivers/usb/host/xhci.h| 3 ++
4 files changed, 45 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/usb-xhci.txt
b/Documentation/devicetree/bindings/usb/usb-xhci.txt
index 0b7d8576001c..f05b2306ae19 100644
--- a/Documentation/devicetree/bindings/usb/usb-xhci.txt
+++ b/Documentation/devicetree/bindings/usb/usb-xhci.txt
@@ -28,6 +28,13 @@ Optional properties:
- clocks: reference to a clock
- usb3-lpm-capable: determines if platform is USB3 LPM capable
+sub-nodes:
+- optionally there can be a node for the root-hub, see usb-roothub.txt in the
+ current directory
+- one or more nodes with reg 1-31 for each port to which a device is connected.
+ See usb-device.txt in the current directory for more information.
+
+
Example:
usb@f0931000 {
compatible = "generic-xhci";
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index eb7009460322..b83b5aa89b76 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -36,6 +36,7 @@ config USB_XHCI_PCI
config USB_XHCI_PLATFORM
tristate "Generic xHCI driver for a platform device"
select USB_XHCI_RCAR if ARCH_RENESAS
+ select USB_PLATFORM_ROOTHUB
---help---
Adds an xHCI host driver for a generic platform device, which
provides a memory space and an irq.
diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index e94bfd07e6c3..a0211cebac71 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -248,6 +248,12 @@ static int xhci_plat_probe(struct platform_device *pdev)
goto disable_clk;
}
+ xhci->platform_roothub = platform_roothub_init(sysdev);
+ if (IS_ERR(xhci->platform_roothub)) {
+ ret = PTR_ERR(xhci->platform_roothub);
+ goto disable_clk;
+ }
+
if (device_property_read_bool(sysdev, "usb3-lpm-capable"))
xhci->quirks |= XHCI_LPM_SUPPORT;
@@ -266,10 +272,14 @@ static int xhci_plat_probe(struct platform_device *pdev)
goto put_usb3_hcd;
}
- ret = usb_add_hcd(hcd, irq, IRQF_SHARED);
+ ret = platform_roothub_power_on(xhci->platform_roothub);
if (ret)
goto disable_usb_phy;
+ ret = usb_add_hcd(hcd, irq, IRQF_SHARED);
+ if (ret)
+ goto disable_platform_roothub;
+
ret = usb_add_hcd(xhci->shared_hcd, irq, IRQF_SHARED);
if (ret)
goto dealloc_usb2_hcd;
@@ -280,6 +290,9 @@ static int xhci_plat_probe(struct platform_device *pdev)
dealloc_usb2_hcd:
usb_remove_hcd(hcd);
+disable_platform_roothub:
+ platform_roothub_power_off(xhci->platform_roothub);
+
disable_usb_phy:
usb_phy_shutdown(hcd->usb_phy);
@@ -305,6 +318,8 @@ static int xhci_plat_remove(struct platform_device *dev)
usb_remove_hcd(xhci->shared_hcd);
usb_phy_shutdown(hcd->usb_phy);
+ platform_roothub_power_off(xhci->platform_roothub);
+
usb_remove_hcd(hcd);
usb_put_hcd(xhci->shared_hcd);
@@ -320,6 +335,7 @@ static int xhci_plat_suspend(struct device *dev)
{
struct usb_hcd *hcd = dev_get_drvdata(dev);
struct xhci_hcd *xhci = hcd_to_xhci(hcd);
+ int ret;
/*
* xhci_suspend() needs `do_wakeup` to know whether host is allowed
@@ -329,15 +345,30 @@ static int xhci_plat_suspend(struct device *dev)
* reconsider this when xhci_plat_suspend enlarges its scope, e.g.,
* also applies to runtime suspend.
*/
- return xhci_suspend(xhci, device_may_wakeup(dev));
+ ret = xhci_suspend(xhci, device_may_wakeup(dev));
+ if (ret)
+ return ret;
+
+ platform_roothub_power_off(xhci->platform_roothub);
+
+ return 0;
}
static int xhci_plat_resume(struct device *dev)
{
struct usb_hcd *hcd = dev_get_drvdata(dev);
struct xhci_hcd *xhci = hcd_to_xhci(hcd);
+ int ret;
- return xhci_resume(xhci, 0);
+ ret = platform_roothub_power_on(xhci->platform_roothub);
+ if (ret)
+ return ret;
+
+ ret = xhci_resume(xhci, 0);
+
[RFC PATCH 1/2] usb: host: add a generic platform USB roothub driver
Many SoC platforms have separate devices for the USB PHY which are
registered through the generic PHY framework. These PHYs have to be
enabled to make the USB controller actually work. They also have to be
disabled again on shutdown/suspend.
Currently (at least) the following HCI platform drivers are using custom
code to obtain all PHYs via devicetree for the roothub/controller and
disable/enable them when required:
- ehci-platform.c has ehci_platform_power_{on,off}
- xhci-mtk.c has xhci_mtk_phy_{init,exit,power_on,power_off}
- ohci-platform.c has ohci_platform_power_{on,off}
These drivers are not using the generic devicetree USB device bindings
yet which were only introduced recently (documentation is available in
devicetree/bindings/usb/usb-device.txt).
With this new driver the usb2-phy and usb3-phy can be specified directly
in the child-node of the corresponding port of the roothub via
devicetree. This can be extended by not just parsing PHYs (some of the
other drivers listed above are for example also parsing a list of clocks
as well) when required.
Signed-off-by: Martin Blumenstingl
---
.../devicetree/bindings/usb/usb-roothub.txt| 41 ++
drivers/usb/host/Kconfig | 3 +
drivers/usb/host/Makefile | 2 +
drivers/usb/host/platform-roothub.c| 146 +
drivers/usb/host/platform-roothub.h| 14 ++
5 files changed, 206 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/usb-roothub.txt
create mode 100644 drivers/usb/host/platform-roothub.c
create mode 100644 drivers/usb/host/platform-roothub.h
diff --git a/Documentation/devicetree/bindings/usb/usb-roothub.txt
b/Documentation/devicetree/bindings/usb/usb-roothub.txt
new file mode 100644
index ..96e152d3901c
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/usb-roothub.txt
@@ -0,0 +1,41 @@
+Generic USB root-hub Properties
+
+similar to the USB device bindings (documented in usb-device.txt from the
+current directory) this provides support for configuring the root-hub.
+
+Required properties:
+- compatible: should be at least one of "usb1d6b,3", "usb1d6b,2"
+- reg: must be 0.
+- address-cells: must be 1
+- size-cells: must be 0
+- a sub-node per port supports the following properties:
+ - reg: the port number on the root-hub (mandatory)
+ - phys: optional, from the *Generic PHY* bindings (mandatory needed when
+phy-names is given)
+ - phy-names: optional, from the *Generic PHY* bindings; supported names
+are "usb2-phy" or "usb3-phy"
+
+Example:
+ &usb1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ roothub@0 {
+ compatible = "usb1d6b,3", "usb1d6b,2";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+
+ port@1 {
+ reg = <1>;
+ usb-phy = <&usb2_phy1>, <&usb3_phy1>;
+ phy-names = "usb2-phy", "usb3-phy";
+ };
+
+ port@2 {
+ reg = <2>;
+ usb-phy = <&usb2_phy2>, <&usb3_phy2>;
+ phy-names = "usb2-phy", "usb3-phy";
+ };
+ };
+ }
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 6361fc739306..eb7009460322 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -797,6 +797,9 @@ config USB_HCD_SSB
If unsure, say N.
+config USB_PLATFORM_ROOTHUB
+ bool
+
config USB_HCD_TEST_MODE
bool "HCD test mode support"
---help---
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index 2644537b7bcf..1f1e19c4a826 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -31,6 +31,8 @@ ifneq ($(CONFIG_USB), )
obj-$(CONFIG_PCI) += pci-quirks.o
endif
+obj-$(CONFIG_USB_PLATFORM_ROOTHUB) += platform-roothub.o
+
obj-$(CONFIG_USB_EHCI_HCD) += ehci-hcd.o
obj-$(CONFIG_USB_EHCI_PCI) += ehci-pci.o
obj-$(CONFIG_USB_EHCI_HCD_PLATFORM)+= ehci-platform.o
diff --git a/drivers/usb/host/platform-roothub.c
b/drivers/usb/host/platform-roothub.c
new file mode 100644
index ..84837e42b006
--- /dev/null
+++ b/drivers/usb/host/platform-roothub.c
@@ -0,0 +1,146 @@
+/*
+ * platform roothub driver - a virtual PHY device which passes all phy_*
+ * function calls to multiple (actual) PHY devices. This is comes handy when
+ * initializing all PHYs on a root-hub (to keep them all in the same state).
+ *
+ * Copyright (C) 2017 Martin Blumenstingl
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * You should have rece
Re: Advanced Format SAT devices show incorrect physical block size
On Tue, 10 Jan 2017, James Bottomley wrote:
> On Tue, 2017-01-10 at 16:00 -0500, Alan Stern wrote:
> > In theory, I suppose we could change the kernel so that it would
> > default to READ CAPACITY(16) for devices that report a SCSI level >=
> > 3, or something along those lines. In general we hesitate to make
> > changes of this sort, because they almost always end up breaking
> > _some_ devices -- and if that happens then the change is reverted,
> > with no exceptions. Linus has a very strict rule about not breaking
> > working systems.
>
> You shouldn't have to change anything: it already does (otherwise how
> else would we detect physical exponent for proper SCSI devices) see
> sd.c:sd_try_rc16_first(). It always returns false for USB because you
> set sdev->try_rc_10_first
In fact, this approach probably won't work. See Bugzilla entries
#43265 and #43391. The devices in those reports claimed to be ANSI
level 4, but they failed anyway.
If you guys want to try the quirk flag, you can apply the patch below.
Then set the usb-storage module parameter quirks=::k where
and are the Vendor and Product ID codes for your device (as 4
hex digits).
In the long run, however, this is not a viable approach. We'd be
better off with an explicit blacklist.
Alan Stern
Index: usb-4.x/drivers/usb/storage/usb.c
===
--- usb-4.x.orig/drivers/usb/storage/usb.c
+++ usb-4.x/drivers/usb/storage/usb.c
@@ -498,7 +498,7 @@ void usb_stor_adjust_quirks(struct usb_d
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_ALWAYS_SYNC);
+ US_FL_ALWAYS_SYNC | US_FL_NEEDS_CAP16);
p = quirks;
while (*p) {
@@ -551,6 +551,9 @@ void usb_stor_adjust_quirks(struct usb_d
case 'j':
f |= US_FL_NO_REPORT_LUNS;
break;
+ case 'k':
+ f |= US_FL_NEEDS_CAP16;
+ break;
case 'l':
f |= US_FL_NOT_LOCKABLE;
break;
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/1] xhci fix for usb-linus
Hi Greg One more fix that would be great to have in 4.10 It fixes a deadlock seen by Richard van der Hoff when unplugging the last USB-C device from a PCI hotluggable xhci controller Mathias Nyman (1): xhci: fix deadlock at host remove by running watchdog correctly drivers/usb/host/xhci-ring.c | 11 --- drivers/usb/host/xhci.c | 13 - 2 files changed, 24 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: [PATCH v5 4/6] usb: xhci: use bus->sysdev for DMA configuration
On Wed, 11 Jan 2017, Mathias Nyman wrote: > On 17.11.2016 13:43, Sriram Dash wrote: > > From: Arnd Bergmann > > > > For xhci-hcd platform device, all the DMA parameters are not > > configured properly, notably dma ops for dwc3 devices. So, set > > the dma for xhci from sysdev. sysdev is pointing to device that > > is known to the system firmware or hardware. > > > > Signed-off-by: Arnd Bergmann > > Signed-off-by: Sriram Dash > > Tested-by: Baolin Wang > > --- > > ... > > > + /* > > +* sysdev must point to a device that is known to the system firmware > > +* or PCI hardware. We handle these three cases here: > > +* 1. xhci_plat comes from firmware > > +* 2. xhci_plat is child of a device from firmware (dwc3-plat) > > +* 3. xhci_plat is grandchild of a pci device (dwc3-pci) > > +*/ > > + sysdev = &pdev->dev; > > + if (sysdev->parent && !sysdev->of_node && sysdev->parent->of_node) > > + sysdev = sysdev->parent; > > +#ifdef CONFIG_PCI > > + else if (sysdev->parent && sysdev->parent->parent && > > +sysdev->parent->parent->bus == &pci_bus_type) > > + sysdev = sysdev->parent->parent; > > +#endif > > + > > Not maybe the the ideal situation here, and looks really tailored to make PCI > dwc3 > controllers with xhci support work. > > Was there some reason child devices can't automatically inherit the dma mask > from the parents, > forcing us to dig it from grandparents? > > Anyway, looks like the dwc3 part is already in 4.10-rc, > If Greg and Alan want to take this series that's fine by me I have no objections. Alan Stern > I haven't tested that it won't break anything on PCI XHCI controllers though > > -Mathias -- To unsubscribe from this list: send the line "unsubscribe 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/1] xhci: fix deadlock at host remove by running watchdog correctly
If a URB is killed while the host is removed we can end up in a situation
where the hub thread takes the roothub device lock, and waits for
the URB to be given back by xhci-hcd, blocking the host remove code.
xhci-hcd tries to stop the endpoint and give back the urb, but can't
as the host is removed from PCI bus at the same time, preventing the normal
way of giving back urb.
Instead we need to rely on the stop command timeout function to give back
the urb. This xhci_stop_endpoint_command_watchdog() timeout function
used a XHCI_STATE_DYING flag to indicate if the timeout function is already
running, but later this flag has been taking into use in other places to
mark that xhci is dying.
Remove checks for XHCI_STATE_DYING in xhci_urb_dequeue. We are still
checking that reading from pci state does not return 0x or that
host is not halted before trying to stop the endpoint.
This whole area of stopping endpoints, giving back URBs, and the wathdog
timeout need rework, this fix focuses on solving a specific deadlock
issue that we can then send to stable before any major rework.
Cc:
Signed-off-by: Mathias Nyman
---
drivers/usb/host/xhci-ring.c | 11 ---
drivers/usb/host/xhci.c | 13 -
2 files changed, 24 deletions(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 25f522b..e32029a 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -913,17 +913,6 @@ void xhci_stop_endpoint_command_watchdog(unsigned long arg)
spin_lock_irqsave(&xhci->lock, flags);
ep->stop_cmds_pending--;
- if (xhci->xhc_state & XHCI_STATE_REMOVING) {
- spin_unlock_irqrestore(&xhci->lock, flags);
- return;
- }
- if (xhci->xhc_state & XHCI_STATE_DYING) {
- xhci_dbg_trace(xhci, trace_xhci_dbg_cancel_urb,
- "Stop EP timer ran, but another timer marked "
- "xHCI as DYING, exiting.");
- spin_unlock_irqrestore(&xhci->lock, flags);
- return;
- }
if (!(ep->stop_cmds_pending == 0 && (ep->ep_state & EP_HALT_PENDING))) {
xhci_dbg_trace(xhci, trace_xhci_dbg_cancel_urb,
"Stop EP timer ran, but no command pending, "
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 0c8deb9..9a0ec11 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -1534,19 +1534,6 @@ int xhci_urb_dequeue(struct usb_hcd *hcd, struct urb
*urb, int status)
xhci_urb_free_priv(urb_priv);
return ret;
}
- if ((xhci->xhc_state & XHCI_STATE_DYING) ||
- (xhci->xhc_state & XHCI_STATE_HALTED)) {
- xhci_dbg_trace(xhci, trace_xhci_dbg_cancel_urb,
- "Ep 0x%x: URB %p to be canceled on "
- "non-responsive xHCI host.",
- urb->ep->desc.bEndpointAddress, urb);
- /* Let the stop endpoint command watchdog timer (which set this
-* state) finish cleaning up the endpoint TD lists. We must
-* have caught it in the middle of dropping a lock and giving
-* back an URB.
-*/
- goto done;
- }
ep_index = xhci_get_endpoint_index(&urb->ep->desc);
ep = &xhci->devs[urb->dev->slot_id]->eps[ep_index];
--
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: Advanced Format SAT devices show incorrect physical block size
On Wed, 11 Jan 2017, Pali Rohár wrote: > On Tuesday 10 January 2017 15:29:23 Alan Stern wrote: > > > Tom Yan wrote that smartctl/hdparm "works" because they use the SCSI ATA > > > PASSTHROUGH command. It is not an option for kernel? > > > > No, because many devices do not implement SCSI ATA PASSTHROUGH. > > (Consider devices whose underlying technology does not use ATA or SATA, > > for example.) And some of the ones that don't implement it will die if > > you try to send them an ATA PASSTHROUGH command. > > It is not possible to detect if underlaying device is ATA? I don't know any reliable way to do it. Besides, even if the device is ATA, you're still out of luck if the USB-SATA bridge doesn't support ATA PASSTHROUGH. > > You have to understand that consumer USB storage really is very > > low quality in many cases. Vendors aim for low cost rather than high > > reliability or correctness. > > Understood. But lot of distributions call hdparm for inserted disks and > also set some APM (or at least check it)... That means there is already > some way how to deal with these problems (in userspace). Maybe. Or maybe users simply don't use hdparm if it causes problems for them. You don't have a similar option with the kernel. 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] Documentation: dt: dwc3: add reference to the usb-xhci properties
dwc3 internally creates a usb-xhci device which means that all
properties documented in usb-xhci.txt are supported as well.
Signed-off-by: Martin Blumenstingl
---
Documentation/devicetree/bindings/usb/dwc3.txt | 4
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt
b/Documentation/devicetree/bindings/usb/dwc3.txt
index e3e6983288e3..f658f394c2d3 100644
--- a/Documentation/devicetree/bindings/usb/dwc3.txt
+++ b/Documentation/devicetree/bindings/usb/dwc3.txt
@@ -56,6 +56,10 @@ Optional properties:
- tx-fifo-resize: determines if the FIFO *has* to be reallocated.
+ - in addition all properties from usb-xhci.txt from the current directory are
+ supported as well
+
+
This is usually a subnode to DWC3 glue to which it is connected.
dwc3@4a03 {
--
2.11.0
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Advanced Format SAT devices show incorrect physical block size
On Tue, 10 Jan 2017, Dainius Masiliūnas wrote: > On Tue, Jan 10, 2017 at 9:00 PM, Alan Stern wrote: > > It is used for preventing the kernel from issuing a READ CAPACITY(16) > > command to the device. Normally the kernel would do this if the reply > > to READ CAPACITY(10) indicated there were more than 2^32 blocks (about > > 2 TB). > > Ah, OK, that makes sense. Though that's still not a proper solution, > and if anything it's confusing for the users: if they plug in a >2 TiB > drive and it breaks, the user will assume that it's the fault of the > drive and not the USB case, or that the case is incapable of handling > such large drives, whereas the true reason is completely different. I'm not sure what you mean. If the quirk flag is set and the user plugs in a >2-TB drive, it won't break. It just won't report the correct size, but at least it will continue to work in a degraded fashion. > > In theory, I suppose we could change the kernel so that it would > > default to READ CAPACITY(16) for devices that report a SCSI level >= 3, > > or something along those lines. In general we hesitate to make changes > > of this sort, because they almost always end up breaking _some_ > > devices -- and if that happens then the change is reverted, with no > > exceptions. Linus has a very strict rule about not breaking working > > systems. > > Well, the problems are 1) we don't really know how many such > misbehaving drives there are, since only those with >2 TiB drives > experience it, thus it's hard to know what effect such change would > have, and 2) there is no way to make the kernel output the true value > even if you know your drive is working fine. We could add that easily enough: a usb-storage quirk to set the NEEDS_CAP16 flag. But it would be better if this wasn't necessary. > And when a drive breaks due to the 16 command, is there a way to > revive it, perhaps by trying to reconnect? That would allow the kernel > to try it first, see that it failed after that command was sent, then > issue a warning in the log saying that this device should have a > quirk, reset and continue with the quirk applied. I'm not sure what you mean by "trying to reconnect". The recovery method most likely to work is to unplug the USB cable and then re-attach it. Issuing a reset might work in some cases and not in others; we have seen examples of devices that crash extremely hard when given something they don't know how to handle. > Also, is `sg_readcap -16` a proper test to determine whether the > device works as expected? You mean, to determine whether the device can handle a READ CAPACITY(16) command? Yes, since that is the command it sends. 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: crash in usb_hc_died+0x16 when unplugging usb-c dock
On 11.01.2017 13:27, Richard van der Hoff wrote: On 14/09/16 15:07, Mathias Nyman wrote: I've been staring at the code for a while and I think xhci might need a bigger rework in this area. For example the XHCI_STATE_DYING flag was originally a flag meaning that a watchdog function for a timed out stop endpoint command is running and all URBs will be given back. Since then this flag has been used when host is no longer responding. The rework will take some time, I think I'll do a quick fix to just prevent the deadlock. That fix could go in quicker and to stable while polishing the rework Just wondering if there were any updates on this. Mathias' test patch fixed my problem (a deadlock when unplugging a USB-C device), but as far as I can see it never made it into git. Found more and more things while trying to rework this whole area, and eventually got stuck. I'll send this to Greg and see if he takes it to 4.10 -Mathias -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 4/6] usb: xhci: use bus->sysdev for DMA configuration
On 17.11.2016 13:43, Sriram Dash wrote: From: Arnd Bergmann For xhci-hcd platform device, all the DMA parameters are not configured properly, notably dma ops for dwc3 devices. So, set the dma for xhci from sysdev. sysdev is pointing to device that is known to the system firmware or hardware. Signed-off-by: Arnd Bergmann Signed-off-by: Sriram Dash Tested-by: Baolin Wang --- ... + /* +* sysdev must point to a device that is known to the system firmware +* or PCI hardware. We handle these three cases here: +* 1. xhci_plat comes from firmware +* 2. xhci_plat is child of a device from firmware (dwc3-plat) +* 3. xhci_plat is grandchild of a pci device (dwc3-pci) +*/ + sysdev = &pdev->dev; + if (sysdev->parent && !sysdev->of_node && sysdev->parent->of_node) + sysdev = sysdev->parent; +#ifdef CONFIG_PCI + else if (sysdev->parent && sysdev->parent->parent && +sysdev->parent->parent->bus == &pci_bus_type) + sysdev = sysdev->parent->parent; +#endif + Not maybe the the ideal situation here, and looks really tailored to make PCI dwc3 controllers with xhci support work. Was there some reason child devices can't automatically inherit the dma mask from the parents, forcing us to dig it from grandparents? Anyway, looks like the dwc3 part is already in 4.10-rc, If Greg and Alan want to take this series that's fine by me I haven't tested that it won't break anything on PCI XHCI controllers though -Mathias -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: musb: Add support for optional VBUS irq to dsps glue layer
On Tue, Jan 10, 2017 at 01:53:53PM -0600, Bin Liu wrote:
> On Thu, Jan 05, 2017 at 11:12:59AM -0800, Tony Lindgren wrote:
> > We can now configure the PMIC interrupt to provide us VBUS
> > events. In that case we don't need to constantly poll the
> > status and can make it optional. This is only wired up
> > for the mini-B interface on beaglebone.
>
> Is it possible someone designed a board which hooks up the vbus of a
> dual-role/otg port to PMIC? The port wouldn't be able to detect the
> attach since no polling anymore.
I haven't seen any am335xx design other than the Beaglebone, that routes
VBUS to PMIC, and I guess the reason that Beaglebone did this way is
only for supporting bus-powered.
>
> >
> > Note that eventually we should get also the connect status
> > for the host interface when the am335x internal PM coprocessor
> > provides us with an IRQ chip. For now, we still need to poll
> > for the host mode status.
> >
> > Signed-off-by: Tony Lindgren
> > ---
> > drivers/usb/musb/musb_dsps.c | 114
> > ++-
> > 1 file changed, 90 insertions(+), 24 deletions(-)
> >
> > diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
> > --- a/drivers/usb/musb/musb_dsps.c
> > +++ b/drivers/usb/musb/musb_dsps.c
> > @@ -118,6 +118,7 @@ struct dsps_glue {
> > struct device *dev;
> > struct platform_device *musb; /* child musb pdev */
> > const struct dsps_musb_wrapper *wrp; /* wrapper register offsets */
> > + int vbus_irq; /* optional vbus irq */
> > struct timer_list timer;/* otg_workaround timer */
> > unsigned long last_timer;/* last timer data for each instance */
> > bool sw_babble_enabled;
> > @@ -145,6 +146,29 @@ static const struct debugfs_reg32 dsps_musb_regs[] = {
> > { "mode", 0xe8 },
> > };
> >
> > +static void dsps_mod_timer(struct dsps_glue *glue, int wait_ms)
> > +{
> > + int wait;
> > +
> > + if (wait_ms < 0)
> > + wait = msecs_to_jiffies(glue->wrp->poll_timeout);
> > + else
> > + wait = msecs_to_jiffies(wait_ms);
> > +
> > + mod_timer(&glue->timer, jiffies + wait);
> > +}
> > +
> > +/*
> > + * If no vbus irq from the PMIC is configured, we need to poll VBUS status.
> > + */
> > +static void dsps_mod_timer_optional(struct dsps_glue *glue)
> > +{
> > + if (glue->vbus_irq)
> > + return;
> > +
> > + dsps_mod_timer(glue, -1);
> > +}
> > +
> > /**
> > * dsps_musb_enable - enable interrupts
> > */
> > @@ -167,8 +191,7 @@ static void dsps_musb_enable(struct musb *musb)
> > /* start polling for ID change in dual-role idle mode */
> > if (musb->xceiv->otg->state == OTG_STATE_B_IDLE &&
> > musb->port_mode == MUSB_PORT_MODE_DUAL_ROLE)
> > - mod_timer(&glue->timer, jiffies +
> > - msecs_to_jiffies(wrp->poll_timeout));
> > + dsps_mod_timer(glue, -1);
> > }
> >
> > /**
> > @@ -199,6 +222,9 @@ static int dsps_check_status(struct musb *musb, void
> > *unused)
> > u8 devctl;
> > int skip_session = 0;
> >
> > + if (glue->vbus_irq)
> > + del_timer(&glue->timer);
> > +
> > /*
> > * We poll because DSPS IP's won't expose several OTG-critical
> > * status change events (from the transceiver) otherwise.
> > @@ -209,8 +235,7 @@ static int dsps_check_status(struct musb *musb, void
> > *unused)
> >
> > switch (musb->xceiv->otg->state) {
> > case OTG_STATE_A_WAIT_VRISE:
> > - mod_timer(&glue->timer, jiffies +
> > - msecs_to_jiffies(wrp->poll_timeout));
> > + dsps_mod_timer_optional(glue);
> > break;
> > case OTG_STATE_A_WAIT_BCON:
> > musb_writeb(musb->mregs, MUSB_DEVCTL, 0);
> > @@ -219,17 +244,18 @@ static int dsps_check_status(struct musb *musb, void
> > *unused)
> >
> > case OTG_STATE_A_IDLE:
> > case OTG_STATE_B_IDLE:
> > - if (devctl & MUSB_DEVCTL_BDEVICE) {
> > - musb->xceiv->otg->state = OTG_STATE_B_IDLE;
> > - MUSB_DEV_MODE(musb);
> > - } else {
> > - musb->xceiv->otg->state = OTG_STATE_A_IDLE;
> > - MUSB_HST_MODE(musb);
> > + if (!glue->vbus_irq) {
> > + if (devctl & MUSB_DEVCTL_BDEVICE) {
> > + musb->xceiv->otg->state = OTG_STATE_B_IDLE;
> > + MUSB_DEV_MODE(musb);
> > + } else {
> > + musb->xceiv->otg->state = OTG_STATE_A_IDLE;
> > + MUSB_HST_MODE(musb);
> > + }
> > + if (!(devctl & MUSB_DEVCTL_SESSION) && !skip_session)
> > + musb_writeb(mregs, MUSB_DEVCTL,
> > MUSB_DEVCTL_SESSION);
>
> Line is more than 80 chars long.
>
> > }
> > - if (!(devctl & MUSB_DEVCTL_SESSION) && !skip_session)
> > -
Re: Advanced Format SAT devices show incorrect physical block size
On Tuesday 10 January 2017 15:29:23 Alan Stern wrote: > > Tom Yan wrote that smartctl/hdparm "works" because they use the SCSI ATA > > PASSTHROUGH command. It is not an option for kernel? > > No, because many devices do not implement SCSI ATA PASSTHROUGH. > (Consider devices whose underlying technology does not use ATA or SATA, > for example.) And some of the ones that don't implement it will die if > you try to send them an ATA PASSTHROUGH command. It is not possible to detect if underlaying device is ATA? > You have to understand that consumer USB storage really is very > low quality in many cases. Vendors aim for low cost rather than high > reliability or correctness. Understood. But lot of distributions call hdparm for inserted disks and also set some APM (or at least check it)... That means there is already some way how to deal with these problems (in userspace). -- Pali Rohár pali.ro...@gmail.com -- To unsubscribe from this list: send the line "unsubscribe 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: Advanced Format SAT devices show incorrect physical block size
On Tuesday 10 January 2017 14:12:25 James Bottomley wrote: > On Tue, 2017-01-10 at 16:00 -0500, Alan Stern wrote: > > In theory, I suppose we could change the kernel so that it would > > default to READ CAPACITY(16) for devices that report a SCSI level >= > > 3, or something along those lines. In general we hesitate to make > > changes of this sort, because they almost always end up breaking > > _some_ devices -- and if that happens then the change is reverted, > > with no exceptions. Linus has a very strict rule about not breaking > > working systems. > > You shouldn't have to change anything: it already does (otherwise how > else would we detect physical exponent for proper SCSI devices) see > sd.c:sd_try_rc16_first(). It always returns false for USB because you > set sdev->try_rc_10_first So.. what does it mean? Can we enable READ CAPACITY(16) for some USB devices? -- Pali Rohár pali.ro...@gmail.com -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fwd: Raw hid gadget
Apologies for the multiple send, I had an inbound mail problem. On Tue, Jan 10, 2017 at 8:53 AM, Greg KH wrote: > On Mon, Jan 09, 2017 at 10:24:42PM +0200, Rogan Dawes wrote: >> Sigh! This got bounced because of HTML parts. >> >> Another question that arises, though: >> >> What sort of performance can I expect writing to and reading from a >> RAW HID gadget, configured using that descriptor? >> >> My understanding is that I should be able to get 64kBps, based on a >> 64-byte packet, and a 1000 packet per second limit. > > Where do you get that per-second limit? > > It's up to the host to pull from the device that fast, perhaps it's not > really doing that? Using usbmon should show you what is going on here > exactly. > > thanks, > > greg k-h I got the idea that the per-second limit was 1000 from the LUFA stack, which has this as part of its descriptors: http://fourwalledcubicle.com/files/LUFA/Doc/151115/html/struct_u_s_b___descriptor___endpoint__t.html#a816d81c288de4e5779df22923e1ac0b7 uint8_t USB_Descriptor_Endpoint_t::PollingIntervalMS Polling interval in milliseconds for the endpoint if it is an INTERRUPT or ISOCHRONOUS type. So, apparently I'm clueless. Nonetheless, I have read reports of people getting 40kBps via raw HID, so it should be possible to do better than I am currently. I'll keep trying, and see if I can get proper packet traces on the bus to clarify what is going on. Regards, Rogan -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb: gadget: udc: atmel: remove memory leak
Commit bbe097f092b0 ("usb: gadget: udc: atmel: fix endpoint name")
introduced a memory leak when unbinding the driver. The endpoint names
would not be freed. Solve that by including the name as a string in struct
usba_ep so it is freed when the endpoint is.
Signed-off-by: Alexandre Belloni
---
drivers/usb/gadget/udc/atmel_usba_udc.c | 3 ++-
drivers/usb/gadget/udc/atmel_usba_udc.h | 1 +
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/udc/atmel_usba_udc.c
b/drivers/usb/gadget/udc/atmel_usba_udc.c
index f3212db9bc37..12c7687216e6 100644
--- a/drivers/usb/gadget/udc/atmel_usba_udc.c
+++ b/drivers/usb/gadget/udc/atmel_usba_udc.c
@@ -1978,7 +1978,8 @@ static struct usba_ep * atmel_udc_of_init(struct
platform_device *pdev,
dev_err(&pdev->dev, "of_probe: name error(%d)\n", ret);
goto err;
}
- ep->ep.name = kasprintf(GFP_KERNEL, "ep%d", ep->index);
+ sprintf(ep->name, "ep%d", ep->index);
+ ep->ep.name = ep->name;
ep->ep_regs = udc->regs + USBA_EPT_BASE(i);
ep->dma_regs = udc->regs + USBA_DMA_BASE(i);
diff --git a/drivers/usb/gadget/udc/atmel_usba_udc.h
b/drivers/usb/gadget/udc/atmel_usba_udc.h
index 3e1c9d589dfa..b03b2ebfc53a 100644
--- a/drivers/usb/gadget/udc/atmel_usba_udc.h
+++ b/drivers/usb/gadget/udc/atmel_usba_udc.h
@@ -280,6 +280,7 @@ struct usba_ep {
void __iomem*ep_regs;
void __iomem*dma_regs;
void __iomem*fifo;
+ charname[8];
struct usb_ep ep;
struct usba_udc *udc;
--
2.11.0
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: crash in usb_hc_died+0x16 when unplugging usb-c dock
On 14/09/16 15:07, Mathias Nyman wrote: I've been staring at the code for a while and I think xhci might need a bigger rework in this area. For example the XHCI_STATE_DYING flag was originally a flag meaning that a watchdog function for a timed out stop endpoint command is running and all URBs will be given back. Since then this flag has been used when host is no longer responding. The rework will take some time, I think I'll do a quick fix to just prevent the deadlock. That fix could go in quicker and to stable while polishing the rework Just wondering if there were any updates on this. Mathias' test patch fixed my problem (a deadlock when unplugging a USB-C device), but as far as I can see it never made it into git. -- To unsubscribe from this list: send the line "unsubscribe 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 09/14] USB: serial: ch341: fix control-message error handling
On Fri, Jan 06, 2017 at 07:15:18PM +0100, Johan Hovold wrote:
> A short control transfer would currently fail to be detected, something
> which could lead to stale buffer data being used as valid input.
>
> Check for short transfers, and make sure to log any transfer errors.
>
> Fixes: 6ce76104781a ("USB: Driver for CH341 USB-serial adaptor")
> Signed-off-by: Johan Hovold
> ---
As this can also lead to bits of uninitialised heap buffers leaking to
user space via the modem-status interface, or to a remote device through
break control, I'll CC stable and add this one for inclusion -rc4 as
well.
Johan
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv14 2/3] usb: USB Type-C connector class
Hi Guenter, On Tue, Jan 10, 2017 at 09:35:42AM -0800, Guenter Roeck wrote: > > I guess we might as well then split the VDO into header, cert stat and > > product parts. What do you think? > > > > If it's OK, then should we change that file to "identity" and dump the > > whole response from Discover Identity command in hex (minus VDM > > Header), separate the parts in the output, or simply provide separate > > attribute files for each part? > > > Makes me wonder what you expect in the vdo attribute today. Right now > I copy the value from the identity header into it. > > Personally I would prefer separate attributes. identity, cert_stat, > product, maybe ? OK. I'm sorry for bringing this up so late, but I'm still a bit concerned about having those attributes because we can't provide a value for them in every system even when USB power delivery is supported. This will be the case with at least with UCSI systems. So what I'll do is, I'll group them into separate directory that will not be visible unless those values can actually be made available. We will have "supports_usb_power_delivery" attribute out side that directory. We can name that directory "identity" or we can call it for example "usb_power_delivery" and have something else usb pd specific in it as well if you like, like attribute for capability. Let me know what you think. I proposed putting the usb pd details into separate directory already at one point, but not everybody liked the idea if I remember correctly. I don't think there were any real arguments against it, so this time I'll add the group unless you disagree. 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 v3] USB: Add uPD78F0730 USB to Serial Adaptor Driver
On Wed, Jan 11, 2017 at 10:49:22AM +0300, Maksim Salau wrote: > Hi Johan, > > Thanks for feedback. > > > > * Dropped inversion of DTR and RTS signals > > > > Did you figure out whether this was needed or not, for example by > > comparing to the hardware flow control levels? > > The current version matches the Windows driver. > > I don't have any other adapters at the moment, but > here is what I get from the adaptor with the current version of the driver: > mcr = TIOCM_RTS; > ioctl(fd, TIOCMBIC, &mcr); /* results in low level (0V) */ > ioctl(fd, TIOCMBIS, &mcr); /* results in high level (5V) */ > > As far as I know, this is not the way other adaptors work. > Please, correct me if I'm wrong. Yes, the control lines are typically active low for TTL-level logic, but I don't think it's standardised (e.g. as it is for RS-232). I think it's right to keep them as in the current version of the patch (i.e. active high) which is accordance with the datasheet, but if possible you should verify the levels when using hardware flow control to be certain that the polarity is not inverted when enabling hardware flow control. > > > The device I have have only one output signal that is toggled by > > > tiocmset(fd, TIOCM_DTR, 0) and tiocmset(fd, TIOCM_RTS, 0). > > > > What do you mean by the above? Does your device only have one of DTR and > > RTS wired? I'd still expect you to only use one of the TIOCM defines to > > set and clear it. > > Sorry, I was wrong in the way I interpret behavior of my test program. > The board I have has only RTS wired. I've just verified with a logic analyzer > that everything is fine with signals (RTS is controlled like mentioned above, > DTR is not wired or disabled in firmware). Sorry for the mess. No, worries. Thanks for clarifying. Johan -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] ARM: dts: da850: Add the cppi41 dma node
On Tuesday 10 January 2017 07:15 PM, Alexandre Bailon wrote: > On 01/09/2017 07:26 PM, Sergei Shtylyov wrote: >>> +0x201000 0x1000 >>> +0x202000 0x1000 >>> +0x204000 0x4000>; >>> +reg-names = "glue", "controller", >>> +"scheduler", "queuemgr"; >>> +interrupts = <58>; >>> +interrupt-names = "glue"; >>> +#dma-cells = <2>; >>> +#dma-channels = <4>; >>> +#dma-requests = <256>; >>> +status = "disabled"; >> >>Why disabled? It doesn't use any external pins... > Will fix it. Please keep it disabled. See the other thread on this. Thanks, Sekhar -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Fwd: Raw hid gadget
For some odd reason, my emails are not getting through to the list.
Even after removing the HTML parts.
Hopefully this makes it.
Rogan
-- Forwarded message --
From: Rogan Dawes
Date: Mon, Jan 9, 2017 at 10:24 PM
Subject: Fwd: Raw hid gadget
To: linux-usb@vger.kernel.org, Alan Stern
Sigh! This got bounced because of HTML parts.
Another question that arises, though:
What sort of performance can I expect writing to and reading from a
RAW HID gadget, configured using that descriptor?
My understanding is that I should be able to get 64kBps, based on a
64-byte packet, and a 1000 packet per second limit.
With my current code, and a Windows host, I am only able to get
approximately 1kBps :-(
Here is the code I am using on the Linux side to "pipe" a socket over
the raw HID device, chunked up into 63-byte packets:
#!/usr/bin/env python3
import selectors
import socket
import os
import fcntl
def set_blocking(fd, blocking):
flag = fcntl.fcntl(fd, fcntl.F_GETFL)
if blocking == False:
fcntl.fcntl(fd, fcntl.F_SETFL, flag | os.O_NONBLOCK)
else:
fcntl.fcntl(fd, fcntl.F_SETFL, flag & ~os.O_NONBLOCK)
def accept(sock, mask):
conn, addr = sock.accept() # Should be ready
print('accepted', conn, 'from', addr)
global connection
connection = conn
conn.setblocking(False)
sel.register(conn, selectors.EVENT_READ, read_socket)
def read_socket(conn, mask):
global connection
data = conn.recv(63) # Should be ready
if data:
print('< ', repr(data))
set_blocking(hidg.fileno(), True)
hidg.write(bytes([len(data)])+data+bytes(64-len(data)-1))
hidg.flush()
set_blocking(hidg.fileno(), False)
else:
print('closing', conn)
sel.unregister(conn)
conn.close()
connection = None
def read_hid(conn, mask):
data = hidg.read(64) # Should be ready
if data:
if data[0:1] != b'\0':
print('> ', repr(data[1:]))
data = data[1:data[0]]
if connection != None:
connection.send(data) # Hope it won't block
else:
print('closing', connection)
sel.unregister(connection)
connection.close()
sel.unregister(hidg)
hidg.close()
sel = selectors.DefaultSelector()
connection = None
hidg = open('/dev/hidg1', 'r+b')
set_blocking(hidg.fileno(), False)
sel.register(hidg, selectors.EVENT_READ, read_hid)
sock = socket.socket()
sock.bind(('localhost', 8089))
sock.listen(1)
sock.setblocking(False)
sel.register(sock, selectors.EVENT_READ, accept)
while True:
events = sel.select()
for key, mask in events:
callback = key.data
callback(key.fileobj, mask)
The Windows side code is at
https://github.com/SensePost/USaBUSe/powershell/, most notably
read_exec.ps1 which is normally "typed out" via the gadget keyboard,
followed by spawn.ps1 which is normally sent over the raw hid
interface.
Any insight you can offer will be much appreciated!
Regards,
Rogan
-- Forwarded message --
From: Rogan Dawes
Date: Mon, Jan 9, 2017 at 7:51 AM
Subject: Re: Raw hid gadget
To: Alan Stern
Cc: linux-usb@vger.kernel.org
Hi Alan,
My responses are inline.
On Sun, Jan 8, 2017 at 12:15 AM, Alan Stern wrote:
> On Sat, 7 Jan 2017, Rogan Dawes wrote:
>
>> Hi Alan,
>>
>> Thanks for the response. I have not read hiddev.txt, so that explains
>> the incorrect expectations. If I may ask, why is the value a 4-byte
>> field? Is that just to round it to 8 bytes?
>
> Probably because the original programmers needed to accomodate the data
> that could appear in any report. Since data fields can be as large as
> 32 bits, that means the field has to be 4 bytes long.
>
Makes sense, I guess ;-)
>> The "English" version of the descriptor is as follows, from the
>> original LUFA source:
>>
>> HID_DESCRIPTOR_VENDOR(0x00, 0x01, 0x02, 0x03, GENERIC_REPORT_SIZE) /*
>> GENERIC_REPORT_SIZE == 64 */
>>
>> And parsed using http://eleccelerator.com/usbdescreqparser/, translates to:
>>
>> 0x06, 0x00, 0xFF, // Usage Page (Vendor Defined 0xFF00)
>> 0x09, 0x01,// Usage (0x01)
>
> Hmmm. Is there any reason for this item?
Not specifically, it is just copy and paste from the sample code ;-)
> So your device produces (and consumes) reports containing 64 8-bit
> values. Presumably in a 64-byte data packet.
Yes, it is my understanding that this is the largest packet size
allowed for a generic hid interface.
>> So I apparently need to extract just the 5th byte from the packet, and
>> discard the rest. Excellent!
>
> (Not from the _packet_, but from the data you receive over the rawhid
> interface.)
>
> Well, that's if you want to read just the first value. If you want to
> read the second value, you have to extract the 13th byte, if you want
> to read the third value, you have to extract the 21st byte, and so on.
Gotcha!
> This raises the question of how many of the values in the report are
> real.
Re: [PATCH 08/11] dmaengine: cppi41: Implement the glue for da8xx
On Tuesday 10 January 2017 09:19 PM, Tony Lindgren wrote: > * Alexandre Bailon [170110 07:23]: >> On 01/10/2017 11:05 AM, Sekhar Nori wrote: >>> On DA8xx, CPPI 4.1 DMAengine is not an independent system resource, but >>> embedded within the USB 2.0 controller. So, I think all that is needed >>> is for MUSB DA8xx glue to trigger probe of CPPI 4.1 dmaengine driver >>> when it is ready. I am not sure all this DA850-specific clock handling >>> is really necessary. >> Actually, we have a circular dependency. >> USB core tries to get DMA channels during the probe, which fails because >> CPPI 4.1 driver is not ready. >> But it will never be ready because the USB clock must be enabled before >> DMA driver probe, what will not happen because USB driver have disabled >> the clock when probe failed. >> >> Someone in the office suggested me to use the component API, >> that could help me to probe the DMA from the USB probe. >> >> Another way to workaround the dependency would be to do defer the >> function calls that access to hardware to avoid to control clock from >> DMA driver. > > Or you really have some wrapper IP block around musb and cppi41 just > like am335x has. > > See drivers/usb/musb/musb_am335x.c and compatible properties for > "ti,am33xx-usb" and it's children in am33xx.dtsi. This looks like what will will need to da850 too. Alexandre, If the wrapper is going to work, can you see if it will end up breaking DT compatibility once introduced? If yes, I suggest reverting the usb1 DT node in da850-lcdk.dts so we don't get into a DT compatibility problem once v4.10 releases. Thanks, Sekhar -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 08/11] dmaengine: cppi41: Implement the glue for da8xx
On 01/10/2017 06:53 PM, Sergei Shtylyov wrote:
> On 01/09/2017 07:06 PM, Alexandre Bailon wrote:
>
>> The da8xx has a cppi41 dma controller.
>
>It's called CPPI 4.1. :-)
>
>> This is add the glue layer required to make it work on da8xx,
>> as well some changes in driver (e.g to manage clock).
>>
>> Signed-off-by: Alexandre Bailon
>> ---
>> drivers/dma/cppi41.c | 95
>>
>> 1 file changed, 95 insertions(+)
>>
>> diff --git a/drivers/dma/cppi41.c b/drivers/dma/cppi41.c
>> index 939398e..4318e53 100644
>> --- a/drivers/dma/cppi41.c
>> +++ b/drivers/dma/cppi41.c
> [...]
>> @@ -86,10 +87,19 @@
>>
>> #define USBSS_IRQ_PD_COMP(1 << 2)
>>
>> +/* USB DA8XX */
>> +#define DA8XX_INTR_SRC_MASKED0x38
>> +#define DA8XX_END_OF_INTR0x3c
>> +
>> +#define DA8XX_QMGR_PENDING_MASK(0xf << 24)
>> +
>> +
>> +
>
>One empty line is enough.
>
>> /* Packet Descriptor */
>> #define PD2_ZERO_LENGTH(1 << 19)
>>
>> #define AM335X_CPPI410
>> +#define DA8XX_CPPI411
>>
>> struct cppi41_channel {
>> struct dma_chan chan;
> [...]
>> @@ -366,6 +393,26 @@ static irqreturn_t am335x_cppi41_irq(int irq,
>> void *data)
>> return cppi41_irq(cdd);
>> }
>>
>> +static irqreturn_t da8xx_cppi41_irq(int irq, void *data)
>> +{
>> +struct cppi41_dd *cdd = data;
>> +u32 status;
>> +u32 usbss_status;
>> +
>> +status = cppi_readl(cdd->qmgr_mem + QMGR_PEND(0));
>> +if (status & DA8XX_QMGR_PENDING_MASK)
>> +cppi41_irq(cdd);
>> +else
>> +return IRQ_NONE;
>
>Seems correct...
>
>> +
>> +/* Re-assert IRQ if there no usb core interrupts pending */
>> +usbss_status = cppi_readl(cdd->usbss_mem + DA8XX_INTR_SRC_MASKED);
>> +if (!usbss_status)
>> +cppi_writel(0, cdd->usbss_mem + DA8XX_END_OF_INTR);
>
>I don't understand this...
Well, it might not be necessary anymore.
I had an issue with teardown. After a teardown, USB were not working
anymore.
It was because an interrupt was fired on teardown completion but
because the completion queue was empty, interrupt was ignored by the
interrupt handler. And in USB driver, because the interrupt was not
fired by USB core, then interrupt was ignored and never re-asserted.
But I guess the change I made in patch 11 should prevent this issue.
>
>> +
>> +return IRQ_HANDLED;
>> +}
>> +
>> static dma_cookie_t cppi41_tx_submit(struct dma_async_tx_descriptor *tx)
>> {
>> dma_cookie_t cookie;
> [...]
>
> 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
Re: [PATCH 08/11] dmaengine: cppi41: Implement the glue for da8xx
On 01/10/2017 04:22 PM, Alexandre Bailon wrote:
> On 01/10/2017 11:05 AM, Sekhar Nori wrote:
>> On Tuesday 10 January 2017 03:08 PM, Alexandre Bailon wrote:
>>> On 01/09/2017 07:08 PM, Grygorii Strashko wrote:
On 01/09/2017 10:06 AM, Alexandre Bailon wrote:
> The da8xx has a cppi41 dma controller.
> This is add the glue layer required to make it work on da8xx,
> as well some changes in driver (e.g to manage clock).
>
> Signed-off-by: Alexandre Bailon
> ---
> drivers/dma/cppi41.c | 95
>
> 1 file changed, 95 insertions(+)
>
> diff --git a/drivers/dma/cppi41.c b/drivers/dma/cppi41.c
> index 939398e..4318e53 100644
> --- a/drivers/dma/cppi41.c
> +++ b/drivers/dma/cppi41.c
> @@ -1,3 +1,4 @@
> +#include
> #include
> #include
> #include
> @@ -86,10 +87,19 @@
>
> #define USBSS_IRQ_PD_COMP(1 << 2)
>
> +/* USB DA8XX */
> +#define DA8XX_INTR_SRC_MASKED0x38
> +#define DA8XX_END_OF_INTR0x3c
> +
> +#define DA8XX_QMGR_PENDING_MASK (0xf << 24)
> +
> +
> +
> /* Packet Descriptor */
> #define PD2_ZERO_LENGTH (1 << 19)
>
> #define AM335X_CPPI410
> +#define DA8XX_CPPI41 1
>
> struct cppi41_channel {
> struct dma_chan chan;
> @@ -158,6 +168,9 @@ struct cppi41_dd {
>
> /* context for suspend/resume */
> unsigned int dma_tdfdq;
> +
> + /* da8xx clock */
> + struct clk *clk;
> };
>
> static struct chan_queues am335x_usb_queues_tx[] = {
> @@ -232,6 +245,20 @@ static const struct chan_queues
> am335x_usb_queues_rx[] = {
> [29] = { .submit = 30, .complete = 155},
> };
>
> +static const struct chan_queues da8xx_usb_queues_tx[] = {
> + [0] = { .submit = 16, .complete = 24},
> + [1] = { .submit = 18, .complete = 24},
> + [2] = { .submit = 20, .complete = 24},
> + [3] = { .submit = 22, .complete = 24},
> +};
> +
> +static const struct chan_queues da8xx_usb_queues_rx[] = {
> + [0] = { .submit = 1, .complete = 26},
> + [1] = { .submit = 3, .complete = 26},
> + [2] = { .submit = 5, .complete = 26},
> + [3] = { .submit = 7, .complete = 26},
> +};
> +
> struct cppi_glue_infos {
> irqreturn_t (*isr)(int irq, void *data);
> const struct chan_queues *queues_rx;
> @@ -366,6 +393,26 @@ static irqreturn_t am335x_cppi41_irq(int irq, void
> *data)
> return cppi41_irq(cdd);
> }
>
> +static irqreturn_t da8xx_cppi41_irq(int irq, void *data)
> +{
> + struct cppi41_dd *cdd = data;
> + u32 status;
> + u32 usbss_status;
> +
> + status = cppi_readl(cdd->qmgr_mem + QMGR_PEND(0));
> + if (status & DA8XX_QMGR_PENDING_MASK)
> + cppi41_irq(cdd);
> + else
> + return IRQ_NONE;
> +
> + /* Re-assert IRQ if there no usb core interrupts pending */
> + usbss_status = cppi_readl(cdd->usbss_mem + DA8XX_INTR_SRC_MASKED);
> + if (!usbss_status)
> + cppi_writel(0, cdd->usbss_mem + DA8XX_END_OF_INTR);
> +
> + return IRQ_HANDLED;
> +}
> +
> static dma_cookie_t cppi41_tx_submit(struct dma_async_tx_descriptor *tx)
> {
> dma_cookie_t cookie;
> @@ -972,8 +1019,19 @@ static const struct cppi_glue_infos
> am335x_usb_infos = {
> .platform = AM335X_CPPI41,
> };
>
> +static const struct cppi_glue_infos da8xx_usb_infos = {
> + .isr = da8xx_cppi41_irq,
> + .queues_rx = da8xx_usb_queues_rx,
> + .queues_tx = da8xx_usb_queues_tx,
> + .td_queue = { .submit = 31, .complete = 0 },
> + .first_completion_queue = 24,
> + .qmgr_num_pend = 2,
> + .platform = DA8XX_CPPI41,
> +};
> +
> static const struct of_device_id cppi41_dma_ids[] = {
> { .compatible = "ti,am3359-cppi41", .data = &am335x_usb_infos},
> + { .compatible = "ti,da8xx-cppi41", .data = &da8xx_usb_infos},
> {},
> };
> MODULE_DEVICE_TABLE(of, cppi41_dma_ids);
> @@ -995,6 +1053,13 @@ static int is_am335x_cppi41(struct device *dev)
> return cdd->platform == AM335X_CPPI41;
> }
>
> +static int is_da8xx_cppi41(struct device *dev)
> +{
> + struct cppi41_dd *cdd = dev_get_drvdata(dev);
> +
> + return cdd->platform == DA8XX_CPPI41;
> +}
> +
> #define CPPI41_DMA_BUSWIDTHS (BIT(DMA_SLAVE_BUSWIDTH_1_BYTE) | \
> BIT(DMA_SLAVE_BUSWIDTH_2_BYTES) | \
> BIT(DMA_SLAVE_BUSWIDTH_3_BYTES) | \
> @@ -1058,6 +1123,21 @@ static int cppi41_dma_probe(struct platform_device
> *pdev)
> cdd->first_completion_queue = glue_info->first_completion_queue;
> cdd->platform = glue_info->platform;
>
> + if (is_da8xx_cppi41(dev)) {
>
Re: [PATCHv14 2/3] usb: USB Type-C connector class
On Wed, 2017-01-11 at 09:57 +0200, Heikki Krogerus wrote: > On Tue, Jan 10, 2017 at 11:08:51AM +0100, Oliver Neukum wrote: > > > And since we are talking about the ABI, can we also change the listing > > > of the accessory mode back to just "audio" and "debug" like I > > > originally had it? I don't remember who and why wanted it to be > > > changed to "Audio Adapter Accessory Mode" and "Debug Accessory Mode", > > > but it differs from the style we list the other details. > > > > Yes, but can we differentiate analog and digital audio? > > I guess we need to have values "analog_audio" and "digital_audio" > instead of just "audio". Is that OK? Perfect. Regards Oliver -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net] r8152: fix the sw rx checksum is unavailable
Fix the hw rx checksum is always enabled, and the user couldn't switch
it to sw rx checksum.
Note that the RTL_VER_01 only support sw rx checksum only. Besides,
the hw rx checksum for RTL_VER_02 is disabled after
commit b9a321b48af4 ("r8152: Fix broken RX checksums."). Re-enable it.
Signed-off-by: Hayes Wang
---
drivers/net/usb/r8152.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index be41856..f3b48ad 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -1730,7 +1730,7 @@ static u8 r8152_rx_csum(struct r8152 *tp, struct rx_desc
*rx_desc)
u8 checksum = CHECKSUM_NONE;
u32 opts2, opts3;
- if (tp->version == RTL_VER_01 || tp->version == RTL_VER_02)
+ if (!(tp->netdev->features & NETIF_F_RXCSUM))
goto return_result;
opts2 = le32_to_cpu(rx_desc->opts2);
@@ -4356,6 +4356,11 @@ static int rtl8152_probe(struct usb_interface *intf,
NETIF_F_HIGHDMA | NETIF_F_FRAGLIST |
NETIF_F_IPV6_CSUM | NETIF_F_TSO6;
+ if (tp->version == RTL_VER_01) {
+ netdev->features &= ~NETIF_F_RXCSUM;
+ netdev->hw_features &= ~NETIF_F_RXCSUM;
+ }
+
netdev->ethtool_ops = &ops;
netif_set_gso_max_size(netdev, RTL_LIMITED_TSO_SIZE);
--
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
