Re: [PATCH v2] usb: chipidea: Hook into mux framework to toggle usb switch

[yossim]

On 2018-04-17 17:11, Peter Rosin wrote:

On 2018-04-17 15:52, Yossi Mansharoff wrote:

On the db410c 96boards platform we have a TC7USB40MU on the board
to mux the D+/D- lines coming from the controller between a micro
usb "device" port and a USB hub for "host" roles[1]. During a
role switch, we need to toggle this mux to forward the D+/D-
lines to either the port or the hub. Add the necessary code to do
the role switch in chipidea core via the generic mux framework.
Board configurations like on db410c are expected to change roles
via the sysfs API described in
Documentation/ABI/testing/sysfs-platform-chipidea-usb2.


Ok, so this is v2. Please describe what is different from v1.
I have told you before that this information helps.

[1] 
https://github.com/96boards/documentation/raw/master/ConsumerEdition/DragonBoard-410c/HardwareDocs/Schematics_DragonBoard.pdf


This link returns 404 for me.

Cheers,
Peter



Hi,
This patch was split apart from the original patch into two patches
one for chipidea and the other for bindings.
this patch has no other changes two the code.

I will update the link.

thanks
Yossi
--
To unsubscribe from this list: send the line "unsubscribe 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: refine xhci-plat-Fix-xhci_plat-shutdown-sequence

[leiwan]

On 2018-04-17 18:32, Greg KH wrote:

On Tue, Apr 17, 2018 at 11:32:42AM +0800, lei...@codeaurora.org wrote:


xhci-plat Shutdown callback should check HCD_FLAG_HW_ACCESSIBLE
before accessing any register. This should avoid hung with access
controllers which support runtime suspend

This can fix for issue of https://patchwork.kernel.org/patch/10339317/
corresponding upload in CAF:
https://source.codeaurora.org/quic/la/kernel/msm-4.4/commit/?h=LV.HB.1.1.5-03810-8x96.0=a7a5307ee04ad349d365ad50f304605a9cd9bd0a

full patch refer attachment.
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 9b27798..bdf914d 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -702,6 +702,10 @@ static void xhci_shutdown(struct usb_hcd *hcd)
usb_disable_xhci_ports(to_pci_dev(hcd->self.sysdev));

spin_lock_irq(>lock);
+   if (!HCD_HW_ACCESSIBLE(hcd)) {
+   spin_unlock_irq(>lock);
+   return;
+   }
xhci_halt(xhci);


A blank line after the if statement?
[lei]I checked other code in this file, seems we do not neeed a blank 
line after if here.


What about all of the other places in this driver that you should also
check for this?  Look at the other host controllers, shouldn't you
mirror what they are doing?
[lei] The issue here is when shutdown called, xhci-host driver will 
try to access
usb register which may be in runtime suspend state, this lead to a 
hang up.
Similar as what xhci-host suspend workflow has done, we need check 
HW_ACCESS.

And this needs a Fixes: tag, along with a cc: stable so as to properly
get backported as this is broken in some stable kernels right now.

[lei] Added Cc and Fixes part in commit message


thanks,

greg k-h



From c03697fa259ab38d1002598ec2ccfac37607ca0b Mon Sep 17 00:00:00 2001
From: Lei wang 
Date: Tue, 17 Apr 2018 10:55:35 +0800
Subject: [PATCH v2] xhci: plat: Fix xhci_plat shutdown hung

xhci-plat Shutdown callback should check HCD_FLAG_HW_ACCESSIBLE
before accessing any register. This should avoid hung with access
controllers which support runtime suspend

Fixes: b07c12517f2a ("xhci: plat: Register shutdown for xhci_plat")
Cc: 
Signed-off-by: Lei wang 
---
 drivers/usb/host/xhci.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 9b27798..bdf914d 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -702,6 +702,10 @@ static void xhci_shutdown(struct usb_hcd *hcd)
usb_disable_xhci_ports(to_pci_dev(hcd->self.sysdev));

spin_lock_irq(>lock);
+   if (!HCD_HW_ACCESSIBLE(hcd)) {
+   spin_unlock_irq(>lock);
+   return;
+   }
xhci_halt(xhci);
/* Workaround for spurious wakeups at shutdown with HSW */
if (xhci->quirks & XHCI_SPURIOUS_WAKEUP)
--
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: [RFT/PATCH 00/38] usb: dwc3: gadget: Rework & Refactoring

[Felipe Balbi]

Hi Bin,

Bin Liu  writes:
> On Mon, Apr 09, 2018 at 02:26:14PM +0300, Felipe Balbi wrote:
>> Hi guys,
>> 
>> I've been working on this series for a while now. I feels like after
>> this series the transfer management code is far easier to read and
>> understand.
>> 
>> Based on my tests, I have no regressions. Tested g_mass_storage and all
>> of testusb's tests (including ISOC).
>> 
>> Patches are also available on dwc3-improve-isoc-endpoints in my k.org
>> tree. Test reports would be VERY, VERY, VERY welcome. Please give this a
>> go so we avoid regressions on v4.18.
>
> Have you tested g_webcam? I just tested your dwc3-improve-isoc-endpoints

for isoc I only tested g_zero.

> branch on TI VAYU evm, it has issues in both high-speed and super-speed
> connections. It works fine with v4.17-rc1.
>
> If it suppose to work with g-webcam, please let me know if you want
> the details of the problems I see - the log is very long in super-speed
> failure.

Sure, give me some details of what's going on. Some bisection would be
great too, then I'll know which patch to blame and where to focus fixes.

Cheers

-- 
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 5/6] USB: renesas_usbhs: drop support for legacy phys

[Yoshihiro Shimoda]

Hi,

> From: Johan Hovold, Sent: Saturday, April 14, 2018 10:06 PM
> 
> Drop support for legacy phys which hasn't been used with a mainline
> kernel since commit 9080b8dc761a ("ARM: OMAP2+: Remove legacy usb-host.c
> platform init code"). Specifically, since that commit usb_get_phy_dev()
> have always returned -ENODEV and consequently this code has not been
> used.
> 
> Signed-off-by: Johan Hovold 
> ---
>  drivers/usb/renesas_usbhs/common.h |  1 -
>  drivers/usb/renesas_usbhs/rcar2.c  | 29 -
>  2 files changed, 30 deletions(-)

Thank you for the patch!
The drivers/usb/renesas_usbhs/mod_gadget.c still uses the legacy phy API 
(usb_get_phy()).
Also this patch set doesn't drop the API. So, I think this subject should be 
changed.
What do you think?

Dropping usb_get_phy_dev() from this driver is good to me.

Best regards,
Yoshihiro Shimoda

--
To unsubscribe from this list: send the line "unsubscribe 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] usb: gadget: uvc: fix racing between

[Paul Elder]

Also forgot to mention that I did this against 4.16. From what I can
tell, only drivers/usb/gadget/composite.c has changed between then and
4.17-rc1 :/

On Tue, Apr 17, 2018 at 11:18:12PM -0400, Paul Elder wrote:
> Down the call stack from the ioctl handler for VIDIOC_STREAMON,
> uvc_video_alloc_requests contains a BUG_ON, which in the high level,
> triggers when VIDIOC_STREAMON ioctl is issued without VIDIOC_STREAMOFF
> being issued previously.
> 
> This can happen in a few ways, such as if the userspace uvc gadget
> application simply doesn't issue VIDIOC_STREAMOFF. Another way is if
> uvc_function_set_alt with alt 0 is called after it is called with 1 but
> before VIDIOC_STREAMON is called; in this case, UVC_EVENT_STREAMON will
> not be queued to userspace, and therefore userspace will never call
> VIDIOC_STREAMOFF.
> 
> To fix this, add two more uvc states: starting and stopping. The
> starting state starts when uvc_function_set_alt 1 is called, and ends
> in uvc_v4l2_streamon, when the state is changed to streaming. The
> stopping state starts when uvc_function_set_alt 0 is called, and ends
> in uvc_v4l2_streamoff, when the state is changed to connected.
> 
> Along with this fix, the completion of the usb status phase needs to be
> delayed until uvc_v4l2_streamon/off. This is already the case for
> uvc_function_set_alt 1, so add this to when alt is 0. However, the
> delayed_status is only incremented when this function returns, so if
> uvc_v4l2_streamon/off is called in between returning and incrementing,
> then uvc_function_setup_continue will WARN that delayed_status is zero.
> 
> To fix this, add and use usb_composite_setup_delay,
> which increments the delayed_status. Then, uvc_function_set_alt
> returns 0 instead of USB_GADGET_DELAYED_STATUS.
> 
> Finally, there is another way to trigger the aforementioned BUG: start
> streaming and (physically) disconnect usb. To fix this, call
> uvcg_video_enable 0 in uvc_function_disable.
> 
> Paul Elder (4):
>   usb: gadget: uvc: synchronize streamon/off with uvc_function_set_alt
>   usb: gadget: composite: add function to increment delayed_status
>   usb: gadget: uvc: synchronize usb status phase delay for
> uvc_function_set_alt
>   usb: gadget: uvc: disable stream when disconnected
> 
>  drivers/usb/gadget/composite.c |  6 ++
>  drivers/usb/gadget/function/f_uvc.c| 24 +---
>  drivers/usb/gadget/function/uvc.h  |  2 ++
>  drivers/usb/gadget/function/uvc_v4l2.c | 21 +++--
>  include/linux/usb/composite.h  |  2 ++
>  5 files changed, 50 insertions(+), 5 deletions(-)
> 
> -- 
> 2.17.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 0/5] usb: gadget: uvc: fix racing between uvc_function_set_alt and streamon/off

[Paul Elder]

I'm sorry; I sent this one again only because I realized I accidentally
truncated the subject line on the original cover letter.

On Tue, Apr 17, 2018 at 11:20:15PM -0400, Paul Elder wrote:
> Down the call stack from the ioctl handler for VIDIOC_STREAMON,
> uvc_video_alloc_requests contains a BUG_ON, which in the high level,
> triggers when VIDIOC_STREAMON ioctl is issued without VIDIOC_STREAMOFF
> being issued previously.
> 
> This can happen in a few ways, such as if the userspace uvc gadget
> application simply doesn't issue VIDIOC_STREAMOFF. Another way is if
> uvc_function_set_alt with alt 0 is called after it is called with 1 but
> before VIDIOC_STREAMON is called; in this case, UVC_EVENT_STREAMON will
> not be queued to userspace, and therefore userspace will never call
> VIDIOC_STREAMOFF.
> 
> To fix this, add two more uvc states: starting and stopping. The
> starting state starts when uvc_function_set_alt 1 is called, and ends
> in uvc_v4l2_streamon, when the state is changed to streaming. The
> stopping state starts when uvc_function_set_alt 0 is called, and ends
> in uvc_v4l2_streamoff, when the state is changed to connected.
> 
> Along with this fix, the completion of the usb status phase needs to be
> delayed until uvc_v4l2_streamon/off. This is already the case for
> uvc_function_set_alt 1, so add this to when alt is 0. However, the
> delayed_status is only incremented when this function returns, so if
> uvc_v4l2_streamon/off is called in between returning and incrementing,
> then uvc_function_setup_continue will WARN that delayed_status is zero.
> 
> To fix this, add and use usb_composite_setup_delay,
> which increments the delayed_status. Then, uvc_function_set_alt
> returns 0 instead of USB_GADGET_DELAYED_STATUS.
> 
> Finally, there is another way to trigger the aforementioned BUG: start
> streaming and (physically) disconnect usb. To fix this, call
> uvcg_video_enable 0 in uvc_function_disable.
> 
> Paul Elder (4):
>   usb: gadget: uvc: synchronize streamon/off with uvc_function_set_alt
>   usb: gadget: composite: add function to increment delayed_status
>   usb: gadget: uvc: synchronize usb status phase delay for
> uvc_function_set_alt
>   usb: gadget: uvc: disable stream when disconnected
> 
>  drivers/usb/gadget/composite.c |  6 ++
>  drivers/usb/gadget/function/f_uvc.c| 24 +---
>  drivers/usb/gadget/function/uvc.h  |  2 ++
>  drivers/usb/gadget/function/uvc_v4l2.c | 21 +++--
>  include/linux/usb/composite.h  |  2 ++
>  5 files changed, 50 insertions(+), 5 deletions(-)
> 
> -- 
> 2.17.0
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 4/4] usb: gadget: uvc: disable stream when disconnected

[Paul Elder]

Down the call stack from the ioctl handler for VIDIOC_STREAMON,
uvc_video_alloc_requests contains a BUG_ON, which in the high level,
triggers when VIDIOC_STREAMON ioctl is issued without VIDIOC_STREAMOFF
being issued previously.

This can also be triggered by starting the stream and then physically
disconnecting usb. To fix this, do the streamoff procedures on usb
disconnect.

Signed-off-by: Paul Elder 
---
 drivers/usb/gadget/function/f_uvc.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/usb/gadget/function/f_uvc.c 
b/drivers/usb/gadget/function/f_uvc.c
index 3324d36e809c..e67f42ee2342 100644
--- a/drivers/usb/gadget/function/f_uvc.c
+++ b/drivers/usb/gadget/function/f_uvc.c
@@ -384,9 +384,12 @@ uvc_function_disable(struct usb_function *f)
 {
struct uvc_device *uvc = to_uvc(f);
struct v4l2_event v4l2_event;
+   struct uvc_video *video = >video;
 
INFO(f->config->cdev, "uvc_function_disable\n");
 
+   uvcg_video_enable(video, 0);
+
memset(_event, 0, sizeof(v4l2_event));
v4l2_event.type = UVC_EVENT_DISCONNECT;
v4l2_event_queue(>vdev, _event);
-- 
2.17.0

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

[PATCH 3/4] usb: gadget: uvc: synchronize usb status phase delay for uvc_function_set_alt

[Paul Elder]

This patch depends on the previous patch in this series:
[PATCH 2/4] usb: gadget: composite: add function to increment
delayed_status

The completion of the usb status phase from uvc_function_set_alt needs
to be delayed until uvc_v4l2_streamon/off. This is currently done by
uvc_function_set_alt returning USB_GADGET_DELAYED_STATUS and
composite_setup detecting this to increment cdev->delayed_status.
However, if uvc_v4l2_streamon/off is called in between this return and
increment, uvc_function_setup_continue within uvc_v4l2_streamon/off will
WARN that cdev->delayed_status is zero.

To fix this, use usb_composite_setup_delay to increment
cdev->delayed_status, and then return 0 so that composite_setup doesn't
increment cdev->delayed_status again.

Signed-off-by: Paul Elder 
---
 drivers/usb/gadget/function/f_uvc.c| 13 -
 drivers/usb/gadget/function/uvc_v4l2.c |  2 ++
 2 files changed, 14 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/gadget/function/f_uvc.c 
b/drivers/usb/gadget/function/f_uvc.c
index 9b63b28a1ee3..3324d36e809c 100644
--- a/drivers/usb/gadget/function/f_uvc.c
+++ b/drivers/usb/gadget/function/f_uvc.c
@@ -334,6 +334,8 @@ uvc_function_set_alt(struct usb_function *f, unsigned 
interface, unsigned alt)
 
uvc->state = UVC_STATE_STOPPING;
 
+   usb_composite_setup_delay(cdev);
+
memset(_event, 0, sizeof(v4l2_event));
v4l2_event.type = UVC_EVENT_STREAMOFF;
v4l2_event_queue(>vdev, _event);
@@ -358,10 +360,19 @@ uvc_function_set_alt(struct usb_function *f, unsigned 
interface, unsigned alt)
 
uvc->state = UVC_STATE_STARTING;
 
+   usb_composite_setup_delay(cdev);
+
memset(_event, 0, sizeof(v4l2_event));
v4l2_event.type = UVC_EVENT_STREAMON;
v4l2_event_queue(>vdev, _event);
-   return USB_GADGET_DELAYED_STATUS;
+
+   /*
+* Normally we would return USB_GADGET_DELAYED_STATUS
+* but status phase might try to continue in between
+* this function returning and the delayed status
+* actually being set
+*/
+   return 0;
 
default:
return -EINVAL;
diff --git a/drivers/usb/gadget/function/uvc_v4l2.c 
b/drivers/usb/gadget/function/uvc_v4l2.c
index fdf02b6987c0..0592e13d861c 100644
--- a/drivers/usb/gadget/function/uvc_v4l2.c
+++ b/drivers/usb/gadget/function/uvc_v4l2.c
@@ -235,6 +235,8 @@ uvc_v4l2_streamoff(struct file *file, void *fh, enum 
v4l2_buf_type type)
 
uvc->state = UVC_STATE_CONNECTED;
 
+   uvc_function_setup_continue(uvc);
+
return 0;
 
 }
-- 
2.17.0

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

[PATCH 0/5] usb: gadget: uvc: fix racing between

[Paul Elder]

Down the call stack from the ioctl handler for VIDIOC_STREAMON,
uvc_video_alloc_requests contains a BUG_ON, which in the high level,
triggers when VIDIOC_STREAMON ioctl is issued without VIDIOC_STREAMOFF
being issued previously.

This can happen in a few ways, such as if the userspace uvc gadget
application simply doesn't issue VIDIOC_STREAMOFF. Another way is if
uvc_function_set_alt with alt 0 is called after it is called with 1 but
before VIDIOC_STREAMON is called; in this case, UVC_EVENT_STREAMON will
not be queued to userspace, and therefore userspace will never call
VIDIOC_STREAMOFF.

To fix this, add two more uvc states: starting and stopping. The
starting state starts when uvc_function_set_alt 1 is called, and ends
in uvc_v4l2_streamon, when the state is changed to streaming. The
stopping state starts when uvc_function_set_alt 0 is called, and ends
in uvc_v4l2_streamoff, when the state is changed to connected.

Along with this fix, the completion of the usb status phase needs to be
delayed until uvc_v4l2_streamon/off. This is already the case for
uvc_function_set_alt 1, so add this to when alt is 0. However, the
delayed_status is only incremented when this function returns, so if
uvc_v4l2_streamon/off is called in between returning and incrementing,
then uvc_function_setup_continue will WARN that delayed_status is zero.

To fix this, add and use usb_composite_setup_delay,
which increments the delayed_status. Then, uvc_function_set_alt
returns 0 instead of USB_GADGET_DELAYED_STATUS.

Finally, there is another way to trigger the aforementioned BUG: start
streaming and (physically) disconnect usb. To fix this, call
uvcg_video_enable 0 in uvc_function_disable.

Paul Elder (4):
  usb: gadget: uvc: synchronize streamon/off with uvc_function_set_alt
  usb: gadget: composite: add function to increment delayed_status
  usb: gadget: uvc: synchronize usb status phase delay for
uvc_function_set_alt
  usb: gadget: uvc: disable stream when disconnected

 drivers/usb/gadget/composite.c |  6 ++
 drivers/usb/gadget/function/f_uvc.c| 24 +---
 drivers/usb/gadget/function/uvc.h  |  2 ++
 drivers/usb/gadget/function/uvc_v4l2.c | 21 +++--
 include/linux/usb/composite.h  |  2 ++
 5 files changed, 50 insertions(+), 5 deletions(-)

-- 
2.17.0

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

[PATCH 2/4] usb: gadget: composite: add function to increment delayed_status

[Paul Elder]

The completion of the usb status phase from uvc_function_set_alt needs
to be delayed until uvc_v4l2_streamon/off. This is currently done by
uvc_function_set_alt returning USB_GADGET_DELAYED_STATUS and
composite_setup detecting this to increment cdev->delayed_status.
However, if uvc_v4l2_streamon/off is called in between this return and
increment, uvc_function_setup_continue within uvc_v4l2_streamon/off will
WARN that cdev->delayed_status is zero.

To fix situations like this, add a function to increment
cdev->delayed_status.

Signed-off-by: Paul Elder 
---
 drivers/usb/gadget/composite.c | 6 ++
 include/linux/usb/composite.h  | 2 ++
 2 files changed, 8 insertions(+)

diff --git a/drivers/usb/gadget/composite.c b/drivers/usb/gadget/composite.c
index 77c7ecca816a..c02ab640a7ae 100644
--- a/drivers/usb/gadget/composite.c
+++ b/drivers/usb/gadget/composite.c
@@ -1548,6 +1548,12 @@ static int fill_ext_prop(struct usb_configuration *c, 
int interface, u8 *buf)
return 0;
 }
 
+void usb_composite_setup_delay(struct usb_composite_dev *cdev)
+{
+   cdev->delayed_status++;
+}
+EXPORT_SYMBOL(usb_composite_setup_delay);
+
 /*
  * The setup() callback implements all the ep0 functionality that's
  * not handled lower down, in hardware or the hardware driver(like
diff --git a/include/linux/usb/composite.h b/include/linux/usb/composite.h
index cef0e44601f8..049f77a4d42b 100644
--- a/include/linux/usb/composite.h
+++ b/include/linux/usb/composite.h
@@ -524,6 +524,8 @@ extern int composite_setup(struct usb_gadget *gadget,
 extern void composite_suspend(struct usb_gadget *gadget);
 extern void composite_resume(struct usb_gadget *gadget);
 
+extern void usb_composite_setup_delay(struct usb_composite_dev *c);
+
 /*
  * Some systems will need runtime overrides for the  product identifiers
  * published in the device descriptor, either numbers or strings or both.
-- 
2.17.0

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

[PATCH 1/4] usb: gadget: uvc: synchronize streamon/off with uvc_function_set_alt

[Paul Elder]

Down the call stack from the ioctl handler for VIDIOC_STREAMON,
uvc_video_alloc_requests contains a BUG_ON, which in the high level,
triggers when VIDIOC_STREAMON ioctl is issued without VIDIOC_STREAMOFF
being issued previously.

This could be triggered by uvc_function_set_alt 0 racing and
winning against uvc_v4l2_streamon, or by userspace neglecting to issue
the VIDIOC_STREAMOFF ioctl.

To fix this, add two more uvc states: starting and stopping. Use these
to prevent the racing, and to detect when VIDIOC_STREAMON is issued
without previously issuing VIDIOC_STREAMOFF.

Signed-off-by: Paul Elder 
---
 drivers/usb/gadget/function/f_uvc.c|  8 ++--
 drivers/usb/gadget/function/uvc.h  |  2 ++
 drivers/usb/gadget/function/uvc_v4l2.c | 19 +--
 3 files changed, 25 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/gadget/function/f_uvc.c 
b/drivers/usb/gadget/function/f_uvc.c
index 439eba660e95..9b63b28a1ee3 100644
--- a/drivers/usb/gadget/function/f_uvc.c
+++ b/drivers/usb/gadget/function/f_uvc.c
@@ -325,17 +325,19 @@ uvc_function_set_alt(struct usb_function *f, unsigned 
interface, unsigned alt)
 
switch (alt) {
case 0:
-   if (uvc->state != UVC_STATE_STREAMING)
+   if (uvc->state != UVC_STATE_STREAMING &&
+   uvc->state != UVC_STATE_STARTING)
return 0;
 
if (uvc->video.ep)
usb_ep_disable(uvc->video.ep);
 
+   uvc->state = UVC_STATE_STOPPING;
+
memset(_event, 0, sizeof(v4l2_event));
v4l2_event.type = UVC_EVENT_STREAMOFF;
v4l2_event_queue(>vdev, _event);
 
-   uvc->state = UVC_STATE_CONNECTED;
return 0;
 
case 1:
@@ -354,6 +356,8 @@ uvc_function_set_alt(struct usb_function *f, unsigned 
interface, unsigned alt)
return ret;
usb_ep_enable(uvc->video.ep);
 
+   uvc->state = UVC_STATE_STARTING;
+
memset(_event, 0, sizeof(v4l2_event));
v4l2_event.type = UVC_EVENT_STREAMON;
v4l2_event_queue(>vdev, _event);
diff --git a/drivers/usb/gadget/function/uvc.h 
b/drivers/usb/gadget/function/uvc.h
index a64e07e61f8c..afb2eac1f337 100644
--- a/drivers/usb/gadget/function/uvc.h
+++ b/drivers/usb/gadget/function/uvc.h
@@ -131,6 +131,8 @@ enum uvc_state {
UVC_STATE_DISCONNECTED,
UVC_STATE_CONNECTED,
UVC_STATE_STREAMING,
+   UVC_STATE_STARTING,
+   UVC_STATE_STOPPING,
 };
 
 struct uvc_device {
diff --git a/drivers/usb/gadget/function/uvc_v4l2.c 
b/drivers/usb/gadget/function/uvc_v4l2.c
index 9a9019625496..fdf02b6987c0 100644
--- a/drivers/usb/gadget/function/uvc_v4l2.c
+++ b/drivers/usb/gadget/function/uvc_v4l2.c
@@ -193,6 +193,9 @@ uvc_v4l2_streamon(struct file *file, void *fh, enum 
v4l2_buf_type type)
struct uvc_video *video = >video;
int ret;
 
+   if (uvc->state != UVC_STATE_STARTING)
+   return 0;
+
if (type != video->queue.queue.type)
return -EINVAL;
 
@@ -201,12 +204,13 @@ uvc_v4l2_streamon(struct file *file, void *fh, enum 
v4l2_buf_type type)
if (ret < 0)
return ret;
 
+   uvc->state = UVC_STATE_STREAMING;
+
/*
 * Complete the alternate setting selection setup phase now that
 * userspace is ready to provide video frames.
 */
uvc_function_setup_continue(uvc);
-   uvc->state = UVC_STATE_STREAMING;
 
return 0;
 }
@@ -217,11 +221,22 @@ uvc_v4l2_streamoff(struct file *file, void *fh, enum 
v4l2_buf_type type)
struct video_device *vdev = video_devdata(file);
struct uvc_device *uvc = video_get_drvdata(vdev);
struct uvc_video *video = >video;
+   int ret;
+
+   if (uvc->state != UVC_STATE_STOPPING)
+   return 0;
 
if (type != video->queue.queue.type)
return -EINVAL;
 
-   return uvcg_video_enable(video, 0);
+   ret = uvcg_video_enable(video, 0);
+   if (ret < 0)
+   return ret;
+
+   uvc->state = UVC_STATE_CONNECTED;
+
+   return 0;
+
 }
 
 static int
-- 
2.17.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: dwc2 ff540000.usb: dwc2_hc_chhltd_intr_dma: Channel 11 - ChHltd set, but reason is unknown

[Rodrigo Stuffs]

Hi there Minas,

On Tue, Apr 17, 2018 at 8:10 AM, Rodrigo Stuffs  wrote:
> Hello Minas,

[...]

> Will monitor it and will let the list know about the results. Thank
> you very much again!
>
> - RF.

Well, the problem happened again. And I'm damn sure it is a bug in the
UPS hardware.

However, there were no printk() this time (running patched kernel).

But it's ok. I have hacked it by:

1. Detect more than a hour with the same voltage
2. When voltage is stable; stop the UPS monitor daemon
3. Run a usb reset program that I found in
http://www.roman10.net/2011/05/04/how-to-reset-usb-device-in-linux/
4. Start the UPS monitor daemon again

Thanks for your help and attention man! o/

My best regards,

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

Re: [PATCH 2/3] usb: gadget: configfs: Create control_config group

[Jerry Zhang]

> >> @@ -1461,6 +1499,18 @@ static struct config_group *gadgets_make(
> >>  if (!gi->composite.gadget_driver.function)
> >>  goto err;
> >>
> >> +gi->control_config.c.label = "control_config";
> >> +/* composite requires some value, but it doesn't matter */
> >> +gi->control_config.c.bConfigurationValue = 42;
> >
> > If I understand correctly this is never exposed to the host, is it?
That's right. It won't be in cdev so it doesn't show up in the actual
descriptors and as such can't be enabled.

> >
> >> +INIT_LIST_HEAD(>control_config.func_list);
> >> +config_group_init_type_name(>control_config.group,
> >> +"control_config", _config_type);
> >> +configfs_add_default_group(>control_config.group, >group);
> >
> > Since it is a config I'd rather this be put inside the "configs" group.
> > Configs created by the user must be named following the
> > . pattern, so there will be no
conflict
> > with any other conf. The name can be "control" then.
> >

> Answering my own doubts: this could be ok from the kernel point of view,
> but existing userspace (libusbgx) already assumes that in the configs
directory
> there are only entries of the form . and anything other
than that
> will cause it to report error.
Makes sense. I would be fine either way but it sounds like we're stuck
because of that library.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] usb: dwc2: gadget: Fix memory leak in dwc2_gadget_init()

[Stefan Wahren]

Hi Grigor,

> Grigor Tovmasyan  hat am 16. April 2018 um 
> 12:16 geschrieben:
> 
> 
> In dwc2_gadget_init() we allocate EP0 request via
> dwc2_hsotg_ep_alloc_request(). After that there are
> usb_add_gadget_udc() call and if it failed, then
> ctrl_req will not be freed and will cause memory leak.
> 
> Reordered function calls in gadget_init: moved up usb_add_gadget_udc()
> before dwc2_hsotg_ep_alloc_request().

i'm not sure, but doesn't this change introduce a race condition before EP0 
request has been allocated?

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

[PATCH v3 18/20] spi: Remove depends on HAS_DMA in case of platform dependency

[Geert Uytterhoeven]

Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.

Generic symbols and drivers without platform dependencies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.

This simplifies the dependencies, and allows to improve compile-testing.

Signed-off-by: Geert Uytterhoeven 
Reviewed-by: Mark Brown 
Acked-by: Robin Murphy 
Acked-by: Mark Brown 
---
v3:
  - Add Acked-by,
  - Rebase to v4.17-rc1,

v2:
  - Add Reviewed-by, Acked-by,
  - Drop RFC state,
  - Split per subsystem.
---
 drivers/spi/Kconfig | 12 +++-
 1 file changed, 3 insertions(+), 9 deletions(-)

diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 2d4146ce2f1be49d..5a8524a3bc13f92d 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -71,7 +71,6 @@ config SPI_ARMADA_3700
 
 config SPI_ATMEL
tristate "Atmel SPI Controller"
-   depends on HAS_DMA
depends on ARCH_AT91 || COMPILE_TEST
help
  This selects a driver for the Atmel SPI Controller, present on
@@ -233,7 +232,6 @@ config SPI_EFM32
 
 config SPI_EP93XX
tristate "Cirrus Logic EP93xx SPI controller"
-   depends on HAS_DMA
depends on ARCH_EP93XX || COMPILE_TEST
help
  This enables using the Cirrus EP93xx SPI controller in master
@@ -355,7 +353,6 @@ config SPI_FSL_SPI
 config SPI_FSL_DSPI
tristate "Freescale DSPI controller"
select REGMAP_MMIO
-   depends on HAS_DMA
depends on SOC_VF610 || SOC_LS1021A || ARCH_LAYERSCAPE || M5441x || 
COMPILE_TEST
help
  This enables support for the Freescale DSPI controller in master
@@ -431,7 +428,6 @@ config SPI_OMAP_UWIRE
 
 config SPI_OMAP24XX
tristate "McSPI driver for OMAP"
-   depends on HAS_DMA
depends on ARCH_OMAP2PLUS || COMPILE_TEST
select SG_SPLIT
help
@@ -440,7 +436,6 @@ config SPI_OMAP24XX
 
 config SPI_TI_QSPI
tristate "DRA7xxx QSPI controller support"
-   depends on HAS_DMA
depends on ARCH_OMAP2PLUS || COMPILE_TEST
help
  QSPI master controller for DRA7xxx used for flash devices.
@@ -469,7 +464,6 @@ config SPI_PIC32
 config SPI_PIC32_SQI
tristate "Microchip PIC32 Quad SPI driver"
depends on MACH_PIC32 || COMPILE_TEST
-   depends on HAS_DMA
help
  SPI driver for PIC32 Quad SPI controller.
 
@@ -572,7 +566,7 @@ config SPI_SC18IS602
 
 config SPI_SH_MSIOF
tristate "SuperH MSIOF SPI controller"
-   depends on HAVE_CLK && HAS_DMA
+   depends on HAVE_CLK
depends on ARCH_SHMOBILE || ARCH_RENESAS || COMPILE_TEST
help
  SPI driver for SuperH and SH Mobile MSIOF blocks.
@@ -650,7 +644,7 @@ config SPI_MXS
 config SPI_TEGRA114
tristate "NVIDIA Tegra114 SPI Controller"
depends on (ARCH_TEGRA && TEGRA20_APB_DMA) || COMPILE_TEST
-   depends on RESET_CONTROLLER && HAS_DMA
+   depends on RESET_CONTROLLER
help
  SPI driver for NVIDIA Tegra114 SPI Controller interface. This 
controller
  is different than the older SoCs SPI controller and also register 
interface
@@ -668,7 +662,7 @@ config SPI_TEGRA20_SFLASH
 config SPI_TEGRA20_SLINK
tristate "Nvidia Tegra20/Tegra30 SLINK Controller"
depends on (ARCH_TEGRA && TEGRA20_APB_DMA) || COMPILE_TEST
-   depends on RESET_CONTROLLER && HAS_DMA
+   depends on RESET_CONTROLLER
help
  SPI driver for Nvidia Tegra20/Tegra30 SLINK Controller interface.
 
-- 
2.7.4

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

[PATCH v3 17/20] serial: Remove depends on HAS_DMA in case of platform dependency

[Geert Uytterhoeven]

Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.

Generic symbols and drivers without platform dependencies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.

This simplifies the dependencies, and allows to improve compile-testing.

Signed-off-by: Geert Uytterhoeven 
Reviewed-by: Mark Brown 
Acked-by: Robin Murphy 
Acked-by: Greg Kroah-Hartman 
---
v3:
  - Add Acked-by,
  - Rebase to v4.17-rc1,

v2:
  - Add Reviewed-by, Acked-by,
  - Drop RFC state,
  - Split per subsystem.
---
 drivers/tty/serial/Kconfig | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
index 0f058df0b0701fe2..25b8c0a8a50397d6 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
@@ -115,7 +115,6 @@ config SERIAL_SB1250_DUART_CONSOLE
 
 config SERIAL_ATMEL
bool "AT91 on-chip serial port support"
-   depends on HAS_DMA
depends on ARCH_AT91 || COMPILE_TEST
select SERIAL_CORE
select SERIAL_MCTRL_GPIO if GPIOLIB
@@ -500,7 +499,6 @@ config SERIAL_SA1100_CONSOLE
 
 config SERIAL_IMX
tristate "IMX serial port support"
-   depends on HAS_DMA
depends on ARCH_MXC || COMPILE_TEST
select SERIAL_CORE
select RATIONAL
@@ -1262,7 +1260,6 @@ config SERIAL_PCH_UART_CONSOLE
 
 config SERIAL_MXS_AUART
tristate "MXS AUART support"
-   depends on HAS_DMA
depends on ARCH_MXS || MACH_ASM9260 || COMPILE_TEST
select SERIAL_CORE
select SERIAL_MCTRL_GPIO if GPIOLIB
@@ -1473,7 +1470,6 @@ config SERIAL_SPRD_CONSOLE
 config SERIAL_STM32
tristate "STMicroelectronics STM32 serial port support"
select SERIAL_CORE
-   depends on HAS_DMA
depends on ARCH_STM32 || COMPILE_TEST
help
  This driver is for the on-chip Serial Controller on
-- 
2.7.4

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

[PATCH v3 19/20] staging: vc04_services: Remove depends on HAS_DMA in case of platform dependency

[Geert Uytterhoeven]

Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.

Generic symbols and drivers without platform dependencies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.

This simplifies the dependencies, and allows to improve compile-testing.

Signed-off-by: Geert Uytterhoeven 
Reviewed-by: Mark Brown 
Acked-by: Robin Murphy 
Acked-by: Greg Kroah-Hartman 
---
v3:
  - Add Acked-by,
  - Rebase to v4.17-rc1,

v2:
  - Add Reviewed-by, Acked-by,
  - Drop RFC state,
  - Split per subsystem.
---
 drivers/staging/vc04_services/Kconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/staging/vc04_services/Kconfig 
b/drivers/staging/vc04_services/Kconfig
index f5aaf7d629f0fae9..98064ce2c2b47c7f 100644
--- a/drivers/staging/vc04_services/Kconfig
+++ b/drivers/staging/vc04_services/Kconfig
@@ -1,6 +1,5 @@
 menuconfig BCM_VIDEOCORE
tristate "Broadcom VideoCore support"
-   depends on HAS_DMA
depends on OF
depends on RASPBERRYPI_FIRMWARE || (COMPILE_TEST && 
!RASPBERRYPI_FIRMWARE)
default y
-- 
2.7.4

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

[PATCH v3 13/20] mmc: Remove depends on HAS_DMA in case of platform dependency

[Geert Uytterhoeven]

Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.

Generic symbols and drivers without platform dependencies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.

This simplifies the dependencies, and allows to improve compile-testing.

Signed-off-by: Geert Uytterhoeven 
Reviewed-by: Mark Brown 
Acked-by: Robin Murphy 
Acked-by: Ulf Hansson 
---
v3:
  - Add Acked-by,
  - Rebase to v4.17-rc1,

v2:
  - Add Reviewed-by, Acked-by,
  - Drop RFC state,
  - Split per subsystem.
---
 drivers/mmc/host/Kconfig | 10 ++
 1 file changed, 2 insertions(+), 8 deletions(-)

diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index 9589f9c9046f14b1..3978d0418958bf6b 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -358,7 +358,6 @@ config MMC_MESON_MX_SDIO
tristate "Amlogic Meson6/Meson8/Meson8b SD/MMC Host Controller support"
depends on ARCH_MESON || COMPILE_TEST
depends on COMMON_CLK
-   depends on HAS_DMA
depends on OF
help
  This selects support for the SD/MMC Host Controller on
@@ -401,7 +400,6 @@ config MMC_OMAP
 
 config MMC_OMAP_HS
tristate "TI OMAP High Speed Multimedia Card Interface support"
-   depends on HAS_DMA
depends on ARCH_OMAP2PLUS || ARCH_KEYSTONE || COMPILE_TEST
help
  This selects the TI OMAP High Speed Multimedia card Interface.
@@ -511,7 +509,6 @@ config MMC_DAVINCI
 
 config MMC_GOLDFISH
tristate "goldfish qemu Multimedia Card Interface support"
-   depends on HAS_DMA
depends on GOLDFISH || COMPILE_TEST
help
  This selects the Goldfish Multimedia card Interface emulation
@@ -605,7 +602,7 @@ config MMC_SDHI
 
 config MMC_SDHI_SYS_DMAC
tristate "DMA for SDHI SD/SDIO controllers using SYS-DMAC"
-   depends on MMC_SDHI && HAS_DMA
+   depends on MMC_SDHI
default MMC_SDHI if (SUPERH || ARM)
help
  This provides DMA support for SDHI SD/SDIO controllers
@@ -615,7 +612,7 @@ config MMC_SDHI_SYS_DMAC
 config MMC_SDHI_INTERNAL_DMAC
tristate "DMA for SDHI SD/SDIO controllers using on-chip bus mastering"
depends on ARM64 || COMPILE_TEST
-   depends on MMC_SDHI && HAS_DMA
+   depends on MMC_SDHI
default MMC_SDHI if ARM64
help
  This provides DMA support for SDHI SD/SDIO controllers
@@ -669,7 +666,6 @@ config MMC_CAVIUM_THUNDERX
 
 config MMC_DW
tristate "Synopsys DesignWare Memory Card Interface"
-   depends on HAS_DMA
depends on ARC || ARM || ARM64 || MIPS || COMPILE_TEST
help
  This selects support for the Synopsys DesignWare Mobile Storage IP
@@ -748,7 +744,6 @@ config MMC_DW_ZX
 
 config MMC_SH_MMCIF
tristate "SuperH Internal MMCIF support"
-   depends on HAS_DMA
depends on SUPERH || ARCH_RENESAS || COMPILE_TEST
help
  This selects the MMC Host Interface controller (MMCIF) found in 
various
@@ -868,7 +863,6 @@ config MMC_TOSHIBA_PCI
 config MMC_BCM2835
tristate "Broadcom BCM2835 SDHOST MMC Controller support"
depends on ARCH_BCM2835 || COMPILE_TEST
-   depends on HAS_DMA
help
  This selects the BCM2835 SDHOST MMC controller. If you have
  a BCM2835 platform with SD or MMC devices, say Y or M here.
-- 
2.7.4

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

[PATCH v3 12/20] media: Remove depends on HAS_DMA in case of platform dependency

[Geert Uytterhoeven]

Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.

Generic symbols and drivers without platform dependencies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.

This simplifies the dependencies, and allows to improve compile-testing.

Note:
  - The various VIDEOBUF*DMA* symbols had to loose their dependencies on
HAS_DMA, as they are selected by several individual drivers.

Signed-off-by: Geert Uytterhoeven 
Reviewed-by: Mark Brown 
Acked-by: Robin Murphy 
---
v3:
  - Rebase to v4.17-rc1,
  - Handle new VIDEO_RENESAS_CEU symbol,

v2:
  - Add Reviewed-by, Acked-by,
  - Drop RFC state,
  - Drop dependency of VIDEOBUF{,2}_DMA_{CONTIG,SG} on HAS_DMA,
  - Drop new dependencies of VIDEO_IPU3_CIO2 and DVB_C8SECTPFE on
HAS_DMA,
  - Split per subsystem.
---
 drivers/media/common/videobuf2/Kconfig   |  2 --
 drivers/media/pci/dt3155/Kconfig |  1 -
 drivers/media/pci/intel/ipu3/Kconfig |  1 -
 drivers/media/pci/solo6x10/Kconfig   |  1 -
 drivers/media/pci/sta2x11/Kconfig|  1 -
 drivers/media/pci/tw5864/Kconfig |  1 -
 drivers/media/pci/tw686x/Kconfig |  1 -
 drivers/media/platform/Kconfig   | 42 ++--
 drivers/media/platform/am437x/Kconfig|  2 +-
 drivers/media/platform/atmel/Kconfig |  4 +--
 drivers/media/platform/davinci/Kconfig   |  6 
 drivers/media/platform/marvell-ccic/Kconfig  |  3 +-
 drivers/media/platform/rcar-vin/Kconfig  |  2 +-
 drivers/media/platform/soc_camera/Kconfig|  3 +-
 drivers/media/platform/sti/c8sectpfe/Kconfig |  2 +-
 drivers/media/v4l2-core/Kconfig  |  2 --
 drivers/staging/media/davinci_vpfe/Kconfig   |  1 -
 drivers/staging/media/omap4iss/Kconfig   |  1 -
 18 files changed, 21 insertions(+), 55 deletions(-)

diff --git a/drivers/media/common/videobuf2/Kconfig 
b/drivers/media/common/videobuf2/Kconfig
index 17c32ea58395d78f..4ed11b46676ac4d0 100644
--- a/drivers/media/common/videobuf2/Kconfig
+++ b/drivers/media/common/videobuf2/Kconfig
@@ -12,7 +12,6 @@ config VIDEOBUF2_MEMOPS
 
 config VIDEOBUF2_DMA_CONTIG
tristate
-   depends on HAS_DMA
select VIDEOBUF2_CORE
select VIDEOBUF2_MEMOPS
select DMA_SHARED_BUFFER
@@ -25,7 +24,6 @@ config VIDEOBUF2_VMALLOC
 
 config VIDEOBUF2_DMA_SG
tristate
-   depends on HAS_DMA
select VIDEOBUF2_CORE
select VIDEOBUF2_MEMOPS
 
diff --git a/drivers/media/pci/dt3155/Kconfig b/drivers/media/pci/dt3155/Kconfig
index 5145e0dfa2aa9e12..858b0f2f15bef9c8 100644
--- a/drivers/media/pci/dt3155/Kconfig
+++ b/drivers/media/pci/dt3155/Kconfig
@@ -1,7 +1,6 @@
 config VIDEO_DT3155
tristate "DT3155 frame grabber"
depends on PCI && VIDEO_DEV && VIDEO_V4L2
-   depends on HAS_DMA
select VIDEOBUF2_DMA_CONTIG
default n
---help---
diff --git a/drivers/media/pci/intel/ipu3/Kconfig 
b/drivers/media/pci/intel/ipu3/Kconfig
index a82d3fe277d2cdec..2533ec1cb1177715 100644
--- a/drivers/media/pci/intel/ipu3/Kconfig
+++ b/drivers/media/pci/intel/ipu3/Kconfig
@@ -4,7 +4,6 @@ config VIDEO_IPU3_CIO2
depends on VIDEO_V4L2_SUBDEV_API
depends on X86 || COMPILE_TEST
depends on MEDIA_CONTROLLER
-   depends on HAS_DMA
depends on ACPI
select V4L2_FWNODE
select VIDEOBUF2_DMA_SG
diff --git a/drivers/media/pci/solo6x10/Kconfig 
b/drivers/media/pci/solo6x10/Kconfig
index 0fb91dc7ca73529e..d9e06a6bf1ebc1a7 100644
--- a/drivers/media/pci/solo6x10/Kconfig
+++ b/drivers/media/pci/solo6x10/Kconfig
@@ -1,7 +1,6 @@
 config VIDEO_SOLO6X10
tristate "Bluecherry / Softlogic 6x10 capture cards (MPEG-4/H.264)"
depends on PCI && VIDEO_DEV && SND && I2C
-   depends on HAS_DMA
select BITREVERSE
select FONT_SUPPORT
select FONT_8x16
diff --git a/drivers/media/pci/sta2x11/Kconfig 
b/drivers/media/pci/sta2x11/Kconfig
index e03587b1af714199..7b856395ede9295c 100644
--- a/drivers/media/pci/sta2x11/Kconfig
+++ b/drivers/media/pci/sta2x11/Kconfig
@@ -1,7 +1,6 @@
 config STA2X11_VIP
tristate "STA2X11 VIP Video For Linux"
depends on STA2X11
-   depends on HAS_DMA
select VIDEO_ADV7180 if MEDIA_SUBDRV_AUTOSELECT
select VIDEOBUF2_DMA_CONTIG
depends on PCI && VIDEO_V4L2 && VIRT_TO_BUS
diff --git a/drivers/media/pci/tw5864/Kconfig b/drivers/media/pci/tw5864/Kconfig
index 87c8f327e2d49dfa..760fb11dfeaef47b 100644
--- a/drivers/media/pci/tw5864/Kconfig
+++ b/drivers/media/pci/tw5864/Kconfig
@@ -1,7 +1,6 @@
 config VIDEO_TW5864
tristate "Techwell TW5864 video/audio grabber and encoder"
depends on VIDEO_DEV && PCI && VIDEO_V4L2
-   

[PATCH v3 05/20] firewire: Remove depends on HAS_DMA in case of platform dependency

[Geert Uytterhoeven]

Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.

Generic symbols and drivers without platform dependencies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.

This simplifies the dependencies, and allows to improve compile-testing.

Signed-off-by: Geert Uytterhoeven 
Reviewed-by: Mark Brown 
Acked-by: Robin Murphy 
---
v3:
  - Rebase to v4.17-rc1,

v2:
  - Add Reviewed-by, Acked-by,
  - Drop RFC state,
  - Split per subsystem.
---
 drivers/firewire/Kconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/firewire/Kconfig b/drivers/firewire/Kconfig
index 145974f9662b63e6..4199849e37585181 100644
--- a/drivers/firewire/Kconfig
+++ b/drivers/firewire/Kconfig
@@ -1,5 +1,4 @@
 menu "IEEE 1394 (FireWire) support"
-   depends on HAS_DMA
depends on PCI || COMPILE_TEST
# firewire-core does not depend on PCI but is
# not useful without PCI controller driver
-- 
2.7.4

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

[PATCH v3 07/20] i2c: Remove depends on HAS_DMA in case of platform dependency

[Geert Uytterhoeven]

Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.

Generic symbols and drivers without platform dependencies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.

This simplifies the dependencies, and allows to improve compile-testing.

Signed-off-by: Geert Uytterhoeven 
Reviewed-by: Mark Brown 
Acked-by: Robin Murphy 
---
v3:
  - Rebase to v4.17-rc1,

v2:
  - Add Reviewed-by, Acked-by,
  - Drop RFC state,
  - Split per subsystem.
---
 drivers/i2c/busses/Kconfig | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index c4865b08d7fb9e3b..8d21b9825d71764d 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -707,7 +707,6 @@ config I2C_MPC
 config I2C_MT65XX
tristate "MediaTek I2C adapter"
depends on ARCH_MEDIATEK || COMPILE_TEST
-   depends on HAS_DMA
help
  This selects the MediaTek(R) Integrated Inter Circuit bus driver
  for MT65xx and MT81xx.
@@ -885,7 +884,6 @@ config I2C_SH7760
 
 config I2C_SH_MOBILE
tristate "SuperH Mobile I2C Controller"
-   depends on HAS_DMA
depends on ARCH_SHMOBILE || ARCH_RENESAS || COMPILE_TEST
help
  If you say yes to this option, support will be included for the
@@ -1098,7 +1096,6 @@ config I2C_XLP9XX
 
 config I2C_RCAR
tristate "Renesas R-Car I2C Controller"
-   depends on HAS_DMA
depends on ARCH_RENESAS || COMPILE_TEST
select I2C_SLAVE
help
-- 
2.7.4

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

[PATCH v3 14/20] mtd: Remove depends on HAS_DMA in case of platform dependency

[Geert Uytterhoeven]

Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.

Generic symbols and drivers without platform dependencies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.

This simplifies the dependencies, and allows to improve compile-testing.

Signed-off-by: Geert Uytterhoeven 
Reviewed-by: Mark Brown 
Acked-by: Robin Murphy 
---
v3:
  - Rebase to v4.17-rc1,

v2:
  - Add Reviewed-by, Acked-by,
  - Drop RFC state,
  - Drop new dependency of MTD_NAND_MARVELL on HAS_DMA,
  - Split per subsystem.
---
 drivers/mtd/nand/raw/Kconfig | 8 ++--
 drivers/mtd/spi-nor/Kconfig  | 2 +-
 2 files changed, 3 insertions(+), 7 deletions(-)

diff --git a/drivers/mtd/nand/raw/Kconfig b/drivers/mtd/nand/raw/Kconfig
index 19a2b283fbbe627e..6871ff0fd300bb81 100644
--- a/drivers/mtd/nand/raw/Kconfig
+++ b/drivers/mtd/nand/raw/Kconfig
@@ -46,7 +46,7 @@ config MTD_NAND_DENALI
 config MTD_NAND_DENALI_PCI
 tristate "Support Denali NAND controller on Intel Moorestown"
select MTD_NAND_DENALI
-   depends on HAS_DMA && PCI
+   depends on PCI
 help
   Enable the driver for NAND flash on Intel Moorestown, using the
   Denali NAND controller core.
@@ -152,7 +152,6 @@ config MTD_NAND_S3C2410_CLKSTOP
 config MTD_NAND_TANGO
tristate "NAND Flash support for Tango chips"
depends on ARCH_TANGO || COMPILE_TEST
-   depends on HAS_DMA
help
  Enables the NAND Flash controller on Tango chips.
 
@@ -285,7 +284,7 @@ config MTD_NAND_MARVELL
tristate "NAND controller support on Marvell boards"
depends on PXA3xx || ARCH_MMP || PLAT_ORION || ARCH_MVEBU || \
   COMPILE_TEST
-   depends on HAS_IOMEM && HAS_DMA
+   depends on HAS_IOMEM
help
  This enables the NAND flash controller driver for Marvell boards,
  including:
@@ -447,7 +446,6 @@ config MTD_NAND_SH_FLCTL
tristate "Support for NAND on Renesas SuperH FLCTL"
depends on SUPERH || COMPILE_TEST
depends on HAS_IOMEM
-   depends on HAS_DMA
help
  Several Renesas SuperH CPU has FLCTL. This option enables support
  for NAND Flash using FLCTL.
@@ -515,7 +513,6 @@ config MTD_NAND_SUNXI
 config MTD_NAND_HISI504
tristate "Support for NAND controller on Hisilicon SoC Hip04"
depends on ARCH_HISI || COMPILE_TEST
-   depends on HAS_DMA
help
  Enables support for NAND controller on Hisilicon SoC Hip04.
 
@@ -529,7 +526,6 @@ config MTD_NAND_QCOM
 config MTD_NAND_MTK
tristate "Support for NAND controller on MTK SoCs"
depends on ARCH_MEDIATEK || COMPILE_TEST
-   depends on HAS_DMA
help
  Enables support for NAND controller on MTK SoCs.
  This controller is found on mt27xx, mt81xx, mt65xx SoCs.
diff --git a/drivers/mtd/spi-nor/Kconfig b/drivers/mtd/spi-nor/Kconfig
index 89da88e591215db1..c493b8230a38c059 100644
--- a/drivers/mtd/spi-nor/Kconfig
+++ b/drivers/mtd/spi-nor/Kconfig
@@ -71,7 +71,7 @@ config SPI_FSL_QUADSPI
 config SPI_HISI_SFC
tristate "Hisilicon SPI-NOR Flash Controller(SFC)"
depends on ARCH_HISI || COMPILE_TEST
-   depends on HAS_IOMEM && HAS_DMA
+   depends on HAS_IOMEM
help
  This enables support for hisilicon SPI-NOR flash controller.
 
-- 
2.7.4

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

[PATCH v3 06/20] fpga: Remove depends on HAS_DMA in case of platform dependency

[Geert Uytterhoeven]

Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.

Generic symbols and drivers without platform dependencies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.

This simplifies the dependencies, and allows to improve compile-testing.

Signed-off-by: Geert Uytterhoeven 
Reviewed-by: Mark Brown 
Acked-by: Robin Murphy 
Acked-by: Alan Tull 
---
v3:
  - Add Acked-by,
  - Rebase to v4.17-rc1,

v2:
  - Add Reviewed-by, Acked-by,
  - Drop RFC state,
  - Split per subsystem.
---
 drivers/fpga/Kconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
index f47ef848bcd056d5..fd539132542e30ee 100644
--- a/drivers/fpga/Kconfig
+++ b/drivers/fpga/Kconfig
@@ -53,7 +53,6 @@ config FPGA_MGR_ALTERA_CVP
 config FPGA_MGR_ZYNQ_FPGA
tristate "Xilinx Zynq FPGA"
depends on ARCH_ZYNQ || COMPILE_TEST
-   depends on HAS_DMA
help
  FPGA manager driver support for Xilinx Zynq FPGAs.
 
-- 
2.7.4

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

[PATCH v3 16/20] remoteproc: Remove depends on HAS_DMA in case of platform dependency

[Geert Uytterhoeven]

Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.

Generic symbols and drivers without platform dependencies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.

This simplifies the dependencies, and allows to improve compile-testing.

Signed-off-by: Geert Uytterhoeven 
Reviewed-by: Mark Brown 
Acked-by: Robin Murphy 
Acked-by: Bjorn Andersson 
---
v3:
  - Add Acked-by,
  - Rebase to v4.17-rc1,

v2:
  - Add Reviewed-by, Acked-by,
  - Drop RFC state,
  - Split per subsystem.
---
 drivers/remoteproc/Kconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index 027274008b086d6f..cd1c168fd18898dc 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -24,7 +24,6 @@ config IMX_REMOTEPROC
 
 config OMAP_REMOTEPROC
tristate "OMAP remoteproc support"
-   depends on HAS_DMA
depends on ARCH_OMAP4 || SOC_OMAP5
depends on OMAP_IOMMU
select MAILBOX
-- 
2.7.4

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

[PATCH v3 02/20] ata: Remove depends on HAS_DMA in case of platform dependency

[Geert Uytterhoeven]

Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.

Generic symbols and drivers without platform dependencies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.

This simplifies the dependencies, and allows to improve compile-testing.

Signed-off-by: Geert Uytterhoeven 
Reviewed-by: Mark Brown 
Acked-by: Robin Murphy 
---
v3:
  - Rebase to v4.17-rc1,

v2:
  - Add Reviewed-by, Acked-by,
  - Drop RFC state,
  - Split per subsystem.
---
 drivers/ata/Kconfig | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
index 2b16e7c8fff35764..39b181d6bd0d8cf2 100644
--- a/drivers/ata/Kconfig
+++ b/drivers/ata/Kconfig
@@ -398,7 +398,6 @@ config SATA_DWC_VDEBUG
 
 config SATA_HIGHBANK
tristate "Calxeda Highbank SATA support"
-   depends on HAS_DMA
depends on ARCH_HIGHBANK || COMPILE_TEST
help
  This option enables support for the Calxeda Highbank SoC's
@@ -408,7 +407,6 @@ config SATA_HIGHBANK
 
 config SATA_MV
tristate "Marvell SATA support"
-   depends on HAS_DMA
depends on PCI || ARCH_DOVE || ARCH_MV78XX0 || \
   ARCH_MVEBU || ARCH_ORION5X || COMPILE_TEST
select GENERIC_PHY
-- 
2.7.4

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

[PATCH v3 00/20] Allow compile-testing NO_DMA (drivers)

[Geert Uytterhoeven]

Hi all,

As of v4.17-rc1, patch series "[PATCH v2 0/5] Allow compile-testing
NO_DMA (core)" (https://lkml.org/lkml/2018/3/16/435) has been included
upstream, and drivers using the DMA API can be compile-tested on
platforms selecting NO_DMA.

This follow-up patch series removes dependencies on HAS_DMA for symbols
that already have platform dependencies implying HAS_DMA, which increases
compile-coverage.

Please apply to your tree if appropriate.

Changes compared to v2:
  - Add Acked-by,
  - Rebased to v4.17-rc1, dropping applied patch for scsi/hisi_sas,
  - Handle new VIDEO_RENESAS_CEU symbol,
  - Drop obsolete note about FSL_FMAN.

Changes compared to v1:
  - Add Reviewed-by, Acked-by,
  - Drop dependency of SND_SOC_LPASS_IPQ806X on HAS_DMA,
  - Drop dependency of VIDEOBUF{,2}_DMA_{CONTIG,SG} on HAS_DMA,
  - Drop new dependencies of VIDEO_IPU3_CIO2, DVB_C8SECTPFE, and
MTD_NAND_MARVELL on HAS_DMA,
  - Split in per-subsystem patches,
  - Split-off the core part in a separate series.

This series is against v4.17-rc1. It can also be found at
https://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k.git/log/?h=no-dma-compile-testing-v3

It has been compile-tested with allmodconfig and allyesconfig for
m68k/sun3, and has received attention from the kbuild test robot.

Thanks for applying!

Geert Uytterhoeven (20):
  ASoC: Remove depends on HAS_DMA in case of platform dependency
  ata: Remove depends on HAS_DMA in case of platform dependency
  crypto: Remove depends on HAS_DMA in case of platform dependency
  fbdev: Remove depends on HAS_DMA in case of platform dependency
  firewire: Remove depends on HAS_DMA in case of platform dependency
  fpga: Remove depends on HAS_DMA in case of platform dependency
  i2c: Remove depends on HAS_DMA in case of platform dependency
  iio: adc: Remove depends on HAS_DMA in case of platform dependency
  iommu: Remove depends on HAS_DMA in case of platform dependency
  lightnvm: Remove depends on HAS_DMA in case of platform dependency
  mailbox: Remove depends on HAS_DMA in case of platform dependency
  media: Remove depends on HAS_DMA in case of platform dependency
  mmc: Remove depends on HAS_DMA in case of platform dependency
  mtd: Remove depends on HAS_DMA in case of platform dependency
  net: Remove depends on HAS_DMA in case of platform dependency
  remoteproc: Remove depends on HAS_DMA in case of platform dependency
  serial: Remove depends on HAS_DMA in case of platform dependency
  spi: Remove depends on HAS_DMA in case of platform dependency
  staging: vc04_services: Remove depends on HAS_DMA in case of platform
dependency
  usb: Remove depends on HAS_DMA in case of platform dependency

 drivers/ata/Kconfig |  2 --
 drivers/crypto/Kconfig  | 14 +++--
 drivers/firewire/Kconfig|  1 -
 drivers/fpga/Kconfig|  1 -
 drivers/i2c/busses/Kconfig  |  3 --
 drivers/iio/adc/Kconfig |  2 --
 drivers/iommu/Kconfig   |  5 ++-
 drivers/lightnvm/Kconfig|  2 +-
 drivers/mailbox/Kconfig |  2 --
 drivers/media/common/videobuf2/Kconfig  |  2 --
 drivers/media/pci/dt3155/Kconfig|  1 -
 drivers/media/pci/intel/ipu3/Kconfig|  1 -
 drivers/media/pci/solo6x10/Kconfig  |  1 -
 drivers/media/pci/sta2x11/Kconfig   |  1 -
 drivers/media/pci/tw5864/Kconfig|  1 -
 drivers/media/pci/tw686x/Kconfig|  1 -
 drivers/media/platform/Kconfig  | 42 +
 drivers/media/platform/am437x/Kconfig   |  2 +-
 drivers/media/platform/atmel/Kconfig|  4 +--
 drivers/media/platform/davinci/Kconfig  |  6 
 drivers/media/platform/marvell-ccic/Kconfig |  3 +-
 drivers/media/platform/rcar-vin/Kconfig |  2 +-
 drivers/media/platform/soc_camera/Kconfig   |  3 +-
 drivers/media/platform/sti/c8sectpfe/Kconfig|  2 +-
 drivers/media/v4l2-core/Kconfig |  2 --
 drivers/mmc/host/Kconfig| 10 ++
 drivers/mtd/nand/raw/Kconfig|  8 ++---
 drivers/mtd/spi-nor/Kconfig |  2 +-
 drivers/net/ethernet/amd/Kconfig|  2 +-
 drivers/net/ethernet/apm/xgene-v2/Kconfig   |  1 -
 drivers/net/ethernet/apm/xgene/Kconfig  |  1 -
 drivers/net/ethernet/arc/Kconfig|  6 ++--
 drivers/net/ethernet/broadcom/Kconfig   |  2 --
 drivers/net/ethernet/calxeda/Kconfig|  2 +-
 drivers/net/ethernet/hisilicon/Kconfig  |  2 +-
 drivers/net/ethernet/marvell/Kconfig|  8 ++---
 drivers/net/ethernet/mellanox/mlxsw/Kconfig |  2 +-
 drivers/net/ethernet/renesas/Kconfig|  2 --
 drivers/net/wireless/broadcom/brcm80211/Kconfig |  1 -
 

[PATCH v3 11/20] mailbox: Remove depends on HAS_DMA in case of platform dependency

[Geert Uytterhoeven]

Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.

Generic symbols and drivers without platform dependencies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.

This simplifies the dependencies, and allows to improve compile-testing.

Signed-off-by: Geert Uytterhoeven 
Reviewed-by: Mark Brown 
Acked-by: Robin Murphy 
---
v3:
  - Rebase to v4.17-rc1,
  - Removed bogus notes,

v2:
  - Add Reviewed-by, Acked-by,
  - Drop RFC state,
  - Split per subsystem.
---
 drivers/mailbox/Kconfig | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
index a2bb27446dce4e2b..725dce5ba62d5baf 100644
--- a/drivers/mailbox/Kconfig
+++ b/drivers/mailbox/Kconfig
@@ -162,7 +162,6 @@ config XGENE_SLIMPRO_MBOX
 config BCM_PDC_MBOX
tristate "Broadcom FlexSparx DMA Mailbox"
depends on ARCH_BCM_IPROC || COMPILE_TEST
-   depends on HAS_DMA
help
  Mailbox implementation for the Broadcom FlexSparx DMA ring manager,
  which provides access to various offload engines on Broadcom
@@ -172,7 +171,6 @@ config BCM_FLEXRM_MBOX
tristate "Broadcom FlexRM Mailbox"
depends on ARM64
depends on ARCH_BCM_IPROC || COMPILE_TEST
-   depends on HAS_DMA
select GENERIC_MSI_IRQ_DOMAIN
default m if ARCH_BCM_IPROC
help
-- 
2.7.4

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

[PATCH v3 10/20] lightnvm: Remove depends on HAS_DMA in case of platform dependency

[Geert Uytterhoeven]

Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.

Generic symbols and drivers without platform dependencies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.

This simplifies the dependencies, and allows to improve compile-testing.

Signed-off-by: Geert Uytterhoeven 
Reviewed-by: Mark Brown 
Acked-by: Robin Murphy 
Reviewed-by: Matias Bjørling 
---
v3:
  - Add Reviewed-by,
  - Rebase to v4.17-rc1,
  - Removed bogus notes,

v2:
  - Add Reviewed-by, Acked-by,
  - Drop RFC state,
  - Split per subsystem.
---
 drivers/lightnvm/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/lightnvm/Kconfig b/drivers/lightnvm/Kconfig
index 10c08982185a572f..9c03f35d9df113c6 100644
--- a/drivers/lightnvm/Kconfig
+++ b/drivers/lightnvm/Kconfig
@@ -4,7 +4,7 @@
 
 menuconfig NVM
bool "Open-Channel SSD target support"
-   depends on BLOCK && HAS_DMA && PCI
+   depends on BLOCK && PCI
select BLK_DEV_NVME
help
  Say Y here to get to enable Open-channel SSDs.
-- 
2.7.4

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

[PATCH v3 03/20] crypto: Remove depends on HAS_DMA in case of platform dependency

[Geert Uytterhoeven]

Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.

Generic symbols and drivers without platform dependencies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.

This simplifies the dependencies, and allows to improve compile-testing.

Signed-off-by: Geert Uytterhoeven 
Reviewed-by: Mark Brown 
Acked-by: Robin Murphy 
Acked-by: Herbert Xu 
---
v3:
  - Add Acked-by,
  - Rebase to v4.17-rc1,

v2:
  - Add Reviewed-by, Acked-by,
  - Drop RFC state,
  - Split per subsystem.
---
 drivers/crypto/Kconfig | 14 --
 1 file changed, 4 insertions(+), 10 deletions(-)

diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index d1ea1a07cecbb36c..3dbc47528667b77c 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -419,7 +419,7 @@ config CRYPTO_DEV_EXYNOS_RNG
 config CRYPTO_DEV_S5P
tristate "Support for Samsung S5PV210/Exynos crypto accelerator"
depends on ARCH_S5PV210 || ARCH_EXYNOS || COMPILE_TEST
-   depends on HAS_IOMEM && HAS_DMA
+   depends on HAS_IOMEM
select CRYPTO_AES
select CRYPTO_BLKCIPHER
help
@@ -466,7 +466,6 @@ endif # if CRYPTO_DEV_UX500
 
 config CRYPTO_DEV_ATMEL_AUTHENC
tristate "Support for Atmel IPSEC/SSL hw accelerator"
-   depends on HAS_DMA
depends on ARCH_AT91 || COMPILE_TEST
select CRYPTO_AUTHENC
select CRYPTO_DEV_ATMEL_AES
@@ -479,7 +478,6 @@ config CRYPTO_DEV_ATMEL_AUTHENC
 
 config CRYPTO_DEV_ATMEL_AES
tristate "Support for Atmel AES hw accelerator"
-   depends on HAS_DMA
depends on ARCH_AT91 || COMPILE_TEST
select CRYPTO_AES
select CRYPTO_AEAD
@@ -494,7 +492,6 @@ config CRYPTO_DEV_ATMEL_AES
 
 config CRYPTO_DEV_ATMEL_TDES
tristate "Support for Atmel DES/TDES hw accelerator"
-   depends on HAS_DMA
depends on ARCH_AT91 || COMPILE_TEST
select CRYPTO_DES
select CRYPTO_BLKCIPHER
@@ -508,7 +505,6 @@ config CRYPTO_DEV_ATMEL_TDES
 
 config CRYPTO_DEV_ATMEL_SHA
tristate "Support for Atmel SHA hw accelerator"
-   depends on HAS_DMA
depends on ARCH_AT91 || COMPILE_TEST
select CRYPTO_HASH
help
@@ -574,7 +570,8 @@ config CRYPTO_DEV_CAVIUM_ZIP
 
 config CRYPTO_DEV_QCE
tristate "Qualcomm crypto engine accelerator"
-   depends on (ARCH_QCOM || COMPILE_TEST) && HAS_DMA && HAS_IOMEM
+   depends on ARCH_QCOM || COMPILE_TEST
+   depends on HAS_IOMEM
select CRYPTO_AES
select CRYPTO_DES
select CRYPTO_ECB
@@ -598,7 +595,6 @@ source "drivers/crypto/vmx/Kconfig"
 config CRYPTO_DEV_IMGTEC_HASH
tristate "Imagination Technologies hardware hash accelerator"
depends on MIPS || COMPILE_TEST
-   depends on HAS_DMA
select CRYPTO_MD5
select CRYPTO_SHA1
select CRYPTO_SHA256
@@ -650,7 +646,6 @@ config CRYPTO_DEV_ROCKCHIP
 
 config CRYPTO_DEV_MEDIATEK
tristate "MediaTek's EIP97 Cryptographic Engine driver"
-   depends on HAS_DMA
depends on (ARM && ARCH_MEDIATEK) || COMPILE_TEST
select CRYPTO_AES
select CRYPTO_AEAD
@@ -688,7 +683,7 @@ source "drivers/crypto/stm32/Kconfig"
 
 config CRYPTO_DEV_SAFEXCEL
tristate "Inside Secure's SafeXcel cryptographic engine driver"
-   depends on HAS_DMA && OF
+   depends on OF
depends on (ARM64 && ARCH_MVEBU) || (COMPILE_TEST && 64BIT)
select CRYPTO_AES
select CRYPTO_BLKCIPHER
@@ -706,7 +701,6 @@ config CRYPTO_DEV_SAFEXCEL
 config CRYPTO_DEV_ARTPEC6
tristate "Support for Axis ARTPEC-6/7 hardware crypto acceleration."
depends on ARM && (ARCH_ARTPEC || COMPILE_TEST)
-   depends on HAS_DMA
depends on OF
select CRYPTO_AEAD
select CRYPTO_AES
-- 
2.7.4

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

[PATCH v3 09/20] iommu: Remove depends on HAS_DMA in case of platform dependency

[Geert Uytterhoeven]

Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.

Generic symbols and drivers without platform dependencies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.

This simplifies the dependencies, and allows to improve compile-testing.

Signed-off-by: Geert Uytterhoeven 
Reviewed-by: Mark Brown 
Acked-by: Robin Murphy 
Acked-by: Joerg Roedel 
---
v3:
  - Add Acked-by,
  - Rebase to v4.17-rc1,

v2:
  - Add Reviewed-by, Acked-by,
  - Drop RFC state,
  - Split per subsystem.
---
 drivers/iommu/Kconfig | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index df171cb8582296b9..c76157e57f6ba4ba 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -23,7 +23,7 @@ config IOMMU_IO_PGTABLE
 config IOMMU_IO_PGTABLE_LPAE
bool "ARMv7/v8 Long Descriptor Format"
select IOMMU_IO_PGTABLE
-   depends on HAS_DMA && (ARM || ARM64 || (COMPILE_TEST && 
!GENERIC_ATOMIC64))
+   depends on ARM || ARM64 || (COMPILE_TEST && !GENERIC_ATOMIC64)
help
  Enable support for the ARM long descriptor pagetable format.
  This allocator supports 4K/2M/1G, 16K/32M and 64K/512M page
@@ -42,7 +42,7 @@ config IOMMU_IO_PGTABLE_LPAE_SELFTEST
 config IOMMU_IO_PGTABLE_ARMV7S
bool "ARMv7/v8 Short Descriptor Format"
select IOMMU_IO_PGTABLE
-   depends on HAS_DMA && (ARM || ARM64 || COMPILE_TEST)
+   depends on ARM || ARM64 || COMPILE_TEST
help
  Enable support for the ARM Short-descriptor pagetable format.
  This supports 32-bit virtual and physical addresses mapped using
@@ -376,7 +376,6 @@ config QCOM_IOMMU
# Note: iommu drivers cannot (yet?) be built as modules
bool "Qualcomm IOMMU Support"
depends on ARCH_QCOM || (COMPILE_TEST && !GENERIC_ATOMIC64)
-   depends on HAS_DMA
select IOMMU_API
select IOMMU_IO_PGTABLE_LPAE
select ARM_DMA_USE_IOMMU
-- 
2.7.4

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

[PATCH v3 20/20] usb: Remove depends on HAS_DMA in case of platform dependency

[Geert Uytterhoeven]

Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.

Generic symbols and drivers without platform dependencies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.

This simplifies the dependencies, and allows to improve compile-testing.

Signed-off-by: Geert Uytterhoeven 
Reviewed-by: Mark Brown 
Acked-by: Robin Murphy 
Acked-by: Felipe Balbi  [drivers/usb/gadget/]
Acked-by: Greg Kroah-Hartman 
---
v3:
  - Add Acked-by,
  - Rebase to v4.17-rc1,

v2:
  - Add Reviewed-by, Acked-by,
  - Drop RFC state,
  - Split per subsystem.
---
 drivers/usb/gadget/udc/Kconfig | 4 ++--
 drivers/usb/mtu3/Kconfig   | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/gadget/udc/Kconfig b/drivers/usb/gadget/udc/Kconfig
index 0875d38476ee9395..9c3b4f86965e80c7 100644
--- a/drivers/usb/gadget/udc/Kconfig
+++ b/drivers/usb/gadget/udc/Kconfig
@@ -179,7 +179,7 @@ config USB_R8A66597
 
 config USB_RENESAS_USBHS_UDC
tristate 'Renesas USBHS controller'
-   depends on USB_RENESAS_USBHS && HAS_DMA
+   depends on USB_RENESAS_USBHS
help
   Renesas USBHS is a discrete USB host and peripheral controller chip
   that supports both full and high speed USB 2.0 data transfers.
@@ -192,7 +192,7 @@ config USB_RENESAS_USBHS_UDC
 config USB_RENESAS_USB3
tristate 'Renesas USB3.0 Peripheral controller'
depends on ARCH_RENESAS || COMPILE_TEST
-   depends on EXTCON && HAS_DMA
+   depends on EXTCON
help
   Renesas USB3.0 Peripheral controller is a USB peripheral controller
   that supports super, high, and full speed USB 3.0 data transfers.
diff --git a/drivers/usb/mtu3/Kconfig b/drivers/usb/mtu3/Kconfig
index 25cd61947beea51e..c0c0eb88e5eafc74 100644
--- a/drivers/usb/mtu3/Kconfig
+++ b/drivers/usb/mtu3/Kconfig
@@ -2,7 +2,7 @@
 
 config USB_MTU3
tristate "MediaTek USB3 Dual Role controller"
-   depends on EXTCON && (USB || USB_GADGET) && HAS_DMA
+   depends on EXTCON && (USB || USB_GADGET)
depends on ARCH_MEDIATEK || COMPILE_TEST
select USB_XHCI_MTK if USB_SUPPORT && USB_XHCI_HCD
help
-- 
2.7.4

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

[PATCH v3 01/20] ASoC: Remove depends on HAS_DMA in case of platform dependency

[Geert Uytterhoeven]

Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.

Generic symbols and drivers without platform dependencies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.

This simplifies the dependencies, and allows to improve compile-testing.

Note:
  - The various SND_SOC_LPASS_* symbols had to loose their dependencies
on HAS_DMA, as they are selected by SND_SOC_STORM and/or
SND_SOC_APQ8016_SBC.

Signed-off-by: Geert Uytterhoeven 
Reviewed-by: Mark Brown 
Acked-by: Robin Murphy 
Acked-by: Mark Brown 
---
v3:
  - Add Acked-by,
  - Rebase to v4.17-rc1,

v2:
  - Add Reviewed-by, Acked-by,
  - Drop RFC state,
  - Drop dependency of SND_SOC_LPASS_IPQ806X on HAS_DMA,
  - Split per subsystem.
---
 sound/soc/bcm/Kconfig  | 3 +--
 sound/soc/kirkwood/Kconfig | 1 -
 sound/soc/pxa/Kconfig  | 1 -
 sound/soc/qcom/Kconfig | 7 ++-
 4 files changed, 3 insertions(+), 9 deletions(-)

diff --git a/sound/soc/bcm/Kconfig b/sound/soc/bcm/Kconfig
index edf367100ebd2f17..02f50b7a966ff262 100644
--- a/sound/soc/bcm/Kconfig
+++ b/sound/soc/bcm/Kconfig
@@ -11,9 +11,8 @@ config SND_BCM2835_SOC_I2S
 config SND_SOC_CYGNUS
tristate "SoC platform audio for Broadcom Cygnus chips"
depends on ARCH_BCM_CYGNUS || COMPILE_TEST
-   depends on HAS_DMA
help
  Say Y if you want to add support for ASoC audio on Broadcom
  Cygnus chips (bcm958300, bcm958305, bcm911360)
 
- If you don't know what to do here, say N.
\ No newline at end of file
+ If you don't know what to do here, say N.
diff --git a/sound/soc/kirkwood/Kconfig b/sound/soc/kirkwood/Kconfig
index bc3c7b5ac752e471..132bb83f8e99aff3 100644
--- a/sound/soc/kirkwood/Kconfig
+++ b/sound/soc/kirkwood/Kconfig
@@ -1,7 +1,6 @@
 config SND_KIRKWOOD_SOC
tristate "SoC Audio for the Marvell Kirkwood and Dove chips"
depends on ARCH_DOVE || ARCH_MVEBU || COMPILE_TEST
-   depends on HAS_DMA
help
  Say Y or M if you want to add support for codecs attached to
  the Kirkwood I2S interface. You will also need to select the
diff --git a/sound/soc/pxa/Kconfig b/sound/soc/pxa/Kconfig
index 484ab3c2ad672fc8..960744e46edc0549 100644
--- a/sound/soc/pxa/Kconfig
+++ b/sound/soc/pxa/Kconfig
@@ -1,7 +1,6 @@
 config SND_PXA2XX_SOC
tristate "SoC Audio for the Intel PXA2xx chip"
depends on ARCH_PXA || COMPILE_TEST
-   depends on HAS_DMA
select SND_PXA2XX_LIB
help
  Say Y or M if you want to add support for codecs attached to
diff --git a/sound/soc/qcom/Kconfig b/sound/soc/qcom/Kconfig
index 8ec9a074b38bd702..3cc252e55468eaab 100644
--- a/sound/soc/qcom/Kconfig
+++ b/sound/soc/qcom/Kconfig
@@ -11,24 +11,21 @@ config SND_SOC_LPASS_CPU
 
 config SND_SOC_LPASS_PLATFORM
tristate
-   depends on HAS_DMA
select REGMAP_MMIO
 
 config SND_SOC_LPASS_IPQ806X
tristate
-   depends on HAS_DMA
select SND_SOC_LPASS_CPU
select SND_SOC_LPASS_PLATFORM
 
 config SND_SOC_LPASS_APQ8016
tristate
-   depends on HAS_DMA
select SND_SOC_LPASS_CPU
select SND_SOC_LPASS_PLATFORM
 
 config SND_SOC_STORM
tristate "ASoC I2S support for Storm boards"
-   depends on SND_SOC_QCOM && HAS_DMA
+   depends on SND_SOC_QCOM
select SND_SOC_LPASS_IPQ806X
select SND_SOC_MAX98357A
help
@@ -37,7 +34,7 @@ config SND_SOC_STORM
 
 config SND_SOC_APQ8016_SBC
tristate "SoC Audio support for APQ8016 SBC platforms"
-   depends on SND_SOC_QCOM && HAS_DMA
+   depends on SND_SOC_QCOM
select SND_SOC_LPASS_APQ8016
help
   Support for Qualcomm Technologies LPASS audio block in
-- 
2.7.4

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

[PATCH v3 15/20] net: Remove depends on HAS_DMA in case of platform dependency

[Geert Uytterhoeven]

Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.

Generic symbols and drivers without platform dependencies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.

This simplifies the dependencies, and allows to improve compile-testing.

Signed-off-by: Geert Uytterhoeven 
Reviewed-by: Mark Brown 
Acked-by: Robin Murphy 
---
v3:
  - Rebase to v4.17-rc1,
  - Drop obsolete note about FSL_FMAN,

v2:
  - Add Reviewed-by, Acked-by,
  - Drop RFC state,
  - Split per subsystem.
---
 drivers/net/ethernet/amd/Kconfig| 2 +-
 drivers/net/ethernet/apm/xgene-v2/Kconfig   | 1 -
 drivers/net/ethernet/apm/xgene/Kconfig  | 1 -
 drivers/net/ethernet/arc/Kconfig| 6 --
 drivers/net/ethernet/broadcom/Kconfig   | 2 --
 drivers/net/ethernet/calxeda/Kconfig| 2 +-
 drivers/net/ethernet/hisilicon/Kconfig  | 2 +-
 drivers/net/ethernet/marvell/Kconfig| 8 +++-
 drivers/net/ethernet/mellanox/mlxsw/Kconfig | 2 +-
 drivers/net/ethernet/renesas/Kconfig| 2 --
 drivers/net/wireless/broadcom/brcm80211/Kconfig | 1 -
 drivers/net/wireless/quantenna/qtnfmac/Kconfig  | 2 +-
 12 files changed, 12 insertions(+), 19 deletions(-)

diff --git a/drivers/net/ethernet/amd/Kconfig b/drivers/net/ethernet/amd/Kconfig
index d5c15e8bb3de706b..f273af136fc7c995 100644
--- a/drivers/net/ethernet/amd/Kconfig
+++ b/drivers/net/ethernet/amd/Kconfig
@@ -173,7 +173,7 @@ config SUNLANCE
 
 config AMD_XGBE
tristate "AMD 10GbE Ethernet driver"
-   depends on ((OF_NET && OF_ADDRESS) || ACPI || PCI) && HAS_IOMEM && 
HAS_DMA
+   depends on ((OF_NET && OF_ADDRESS) || ACPI || PCI) && HAS_IOMEM
depends on X86 || ARM64 || COMPILE_TEST
select BITREVERSE
select CRC32
diff --git a/drivers/net/ethernet/apm/xgene-v2/Kconfig 
b/drivers/net/ethernet/apm/xgene-v2/Kconfig
index 1205861b631896a0..eedd3f3dd22e2201 100644
--- a/drivers/net/ethernet/apm/xgene-v2/Kconfig
+++ b/drivers/net/ethernet/apm/xgene-v2/Kconfig
@@ -1,6 +1,5 @@
 config NET_XGENE_V2
tristate "APM X-Gene SoC Ethernet-v2 Driver"
-   depends on HAS_DMA
depends on ARCH_XGENE || COMPILE_TEST
help
  This is the Ethernet driver for the on-chip ethernet interface
diff --git a/drivers/net/ethernet/apm/xgene/Kconfig 
b/drivers/net/ethernet/apm/xgene/Kconfig
index afccb033177b3923..e4e33c900b577161 100644
--- a/drivers/net/ethernet/apm/xgene/Kconfig
+++ b/drivers/net/ethernet/apm/xgene/Kconfig
@@ -1,6 +1,5 @@
 config NET_XGENE
tristate "APM X-Gene SoC Ethernet Driver"
-   depends on HAS_DMA
depends on ARCH_XGENE || COMPILE_TEST
select PHYLIB
select MDIO_XGENE
diff --git a/drivers/net/ethernet/arc/Kconfig b/drivers/net/ethernet/arc/Kconfig
index e743ddf46343302f..5d0ab8e74b680cc6 100644
--- a/drivers/net/ethernet/arc/Kconfig
+++ b/drivers/net/ethernet/arc/Kconfig
@@ -24,7 +24,8 @@ config ARC_EMAC_CORE
 config ARC_EMAC
tristate "ARC EMAC support"
select ARC_EMAC_CORE
-   depends on OF_IRQ && OF_NET && HAS_DMA && (ARC || COMPILE_TEST)
+   depends on OF_IRQ && OF_NET
+   depends on ARC || COMPILE_TEST
---help---
  On some legacy ARC (Synopsys) FPGA boards such as ARCAngel4/ML50x
  non-standard on-chip ethernet device ARC EMAC 10/100 is used.
@@ -33,7 +34,8 @@ config ARC_EMAC
 config EMAC_ROCKCHIP
tristate "Rockchip EMAC support"
select ARC_EMAC_CORE
-   depends on OF_IRQ && OF_NET && REGULATOR && HAS_DMA && (ARCH_ROCKCHIP 
|| COMPILE_TEST)
+   depends on OF_IRQ && OF_NET && REGULATOR
+   depends on ARCH_ROCKCHIP || COMPILE_TEST
---help---
  Support for Rockchip RK3036/RK3066/RK3188 EMAC ethernet controllers.
  This selects Rockchip SoC glue layer support for the
diff --git a/drivers/net/ethernet/broadcom/Kconfig 
b/drivers/net/ethernet/broadcom/Kconfig
index af75156919edfead..4c3bfde6e8de00f2 100644
--- a/drivers/net/ethernet/broadcom/Kconfig
+++ b/drivers/net/ethernet/broadcom/Kconfig
@@ -157,7 +157,6 @@ config BGMAC
 config BGMAC_BCMA
tristate "Broadcom iProc GBit BCMA support"
depends on BCMA && BCMA_HOST_SOC
-   depends on HAS_DMA
depends on BCM47XX || ARCH_BCM_5301X || COMPILE_TEST
select BGMAC
select PHYLIB
@@ -170,7 +169,6 @@ config BGMAC_BCMA
 
 config BGMAC_PLATFORM
tristate "Broadcom iProc GBit platform support"
-   depends on HAS_DMA
depends on ARCH_BCM_IPROC || COMPILE_TEST
depends on OF
select BGMAC
diff --git a/drivers/net/ethernet/calxeda/Kconfig 
b/drivers/net/ethernet/calxeda/Kconfig
index 07d2201530d26c85..9fdd496b90ff47cb 100644

[PATCH v3 04/20] fbdev: Remove depends on HAS_DMA in case of platform dependency

[Geert Uytterhoeven]

Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.

Generic symbols and drivers without platform dependencies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.

This simplifies the dependencies, and allows to improve compile-testing.

Signed-off-by: Geert Uytterhoeven 
Reviewed-by: Mark Brown 
Acked-by: Robin Murphy 
Acked-by: Bartlomiej Zolnierkiewicz 
---
v3:
  - Add Acked-by,
  - Rebase to v4.17-rc1,

v2:
  - Add Reviewed-by, Acked-by,
  - Drop RFC state,
  - Split per subsystem.
---
 drivers/video/fbdev/Kconfig | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index d94254263ea5caa7..4f9853ec1721950f 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -2075,7 +2075,8 @@ config FB_XILINX
 
 config FB_GOLDFISH
tristate "Goldfish Framebuffer"
-   depends on FB && HAS_DMA && (GOLDFISH || COMPILE_TEST)
+   depends on FB
+   depends on GOLDFISH || COMPILE_TEST
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
-- 
2.7.4

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

[PATCH v3 08/20] iio: adc: Remove depends on HAS_DMA in case of platform dependency

[Geert Uytterhoeven]

Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.

Generic symbols and drivers without platform dependencies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.

This simplifies the dependencies, and allows to improve compile-testing.

Signed-off-by: Geert Uytterhoeven 
Reviewed-by: Mark Brown 
Acked-by: Robin Murphy 
Acked-by: Jonathan Cameron 
---
v3:
  - Add Acked-by,
  - Rebase to v4.17-rc1,

v2:
  - Add Reviewed-by, Acked-by,
  - Drop RFC state,
  - Split per subsystem.
---
 drivers/iio/adc/Kconfig | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index 15606f237480dacb..88bbcd0e98632273 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -157,7 +157,6 @@ config AT91_SAMA5D2_ADC
tristate "Atmel AT91 SAMA5D2 ADC"
depends on ARCH_AT91 || COMPILE_TEST
depends on HAS_IOMEM
-   depends on HAS_DMA
select IIO_TRIGGERED_BUFFER
help
  Say yes here to build support for Atmel SAMA5D2 ADC which is
@@ -646,7 +645,6 @@ config SD_ADC_MODULATOR
 config STM32_ADC_CORE
tristate "STMicroelectronics STM32 adc core"
depends on ARCH_STM32 || COMPILE_TEST
-   depends on HAS_DMA
depends on OF
depends on REGULATOR
select IIO_BUFFER
-- 
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: [RFT/PATCH 00/38] usb: dwc3: gadget: Rework & Refactoring

[Bin Liu]

Felipe,

On Mon, Apr 09, 2018 at 02:26:14PM +0300, Felipe Balbi wrote:
> Hi guys,
> 
> I've been working on this series for a while now. I feels like after
> this series the transfer management code is far easier to read and
> understand.
> 
> Based on my tests, I have no regressions. Tested g_mass_storage and all
> of testusb's tests (including ISOC).
> 
> Patches are also available on dwc3-improve-isoc-endpoints in my k.org
> tree. Test reports would be VERY, VERY, VERY welcome. Please give this a
> go so we avoid regressions on v4.18.

Have you tested g_webcam? I just tested your dwc3-improve-isoc-endpoints
branch on TI VAYU evm, it has issues in both high-speed and super-speed
connections. It works fine with v4.17-rc1.

If it suppose to work with g-webcam, please let me know if you want
the details of the problems I see - the log is very long in super-speed
failure.

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 v2] usb: chipidea: Hook into mux framework to toggle usb switch

[Peter Rosin]

On 2018-04-17 15:52, Yossi Mansharoff wrote:
> On the db410c 96boards platform we have a TC7USB40MU on the board
> to mux the D+/D- lines coming from the controller between a micro
> usb "device" port and a USB hub for "host" roles[1]. During a
> role switch, we need to toggle this mux to forward the D+/D-
> lines to either the port or the hub. Add the necessary code to do
> the role switch in chipidea core via the generic mux framework.
> Board configurations like on db410c are expected to change roles
> via the sysfs API described in
> Documentation/ABI/testing/sysfs-platform-chipidea-usb2.

Ok, so this is v2. Please describe what is different from v1.
I have told you before that this information helps.

> [1] 
> https://github.com/96boards/documentation/raw/master/ConsumerEdition/DragonBoard-410c/HardwareDocs/Schematics_DragonBoard.pdf

This link returns 404 for me.

Cheers,
Peter
--
To unsubscribe from this list: send the line "unsubscribe 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: ConfigFS, FunctionFS, and MS XInput

[Krzysztof Opasiak]

On 04/17/2018 04:03 AM, Daniel Hefti wrote:

Hey guys,

I've been banging my head against the wall for a couple of days trying 
to get a Raspberry Pi 0W to talk to Windows (8.1/10) as an XInput game 
controller using ConfigFS and FunctionFS, having little success.  I've 
tried to build both a generic XInput device and one that attempts to 
emulate an X360 controller.  The X360 controller seems to get "further", 
in that Windows says it recognizes the device and the drivers are 
working.  Whatever that means.  The generic version just shows up as an 
unrecognized device (with the name I've given it).  Neither are getting 
or able to send any data from/to their respective endpoints.  The X360 
version, I tested locally via loopback/dummy UDC, and the xboxdrv driver 
can detect and read controller state messages/reports I send it, so at 
least that much works.  Not sure what I could possibly be missing.


I can say I've successfully created HID USB game controller devices. 
Those are accessible from Windows, but, unfortunately, many Windows 
games don't support HID particularly well, and I'm trying to avoid 
someone having to use something like XOutput as a workaround to get this 
device to work.


I do have Wireshark with USBPCap installed, so I can at least capture 
some of the data, which I did, but  it wasn't really leading me 
anywhere, possibly due to my lack of knowledge in this particular 
subject.  Unfortunately, I didn't save my pcap results.  I'll likely end 
up doing it again once I've given my head some time to heal.


Any insights?  References?  Something you think could help guide me in 
the right direction?  There's plenty of documentation and example 
implementations out there for HID devices, but not so much for XInput 
devices and functionfs in general, so any help would be greatly 
appreciated!


Did you check that you provided all drivers that a physical device does?
Maybe windows requires correct OS descriptors for that device?
That's just some guesses...

--
Krzysztof Opasiak
Samsung R Institute Poland
Samsung Electronics
--
To unsubscribe from this list: send the line "unsubscribe 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] doc: usb: ci-hdrc-usb2: Add property "mux-controls"

[Yossi Mansharoff]

The chipidea usb controller may be connected, in some platforms,
to an external mux to toggle between different usb ports for
different roles (host and device).

The mux-controller property, if set, binds the chipidea usb
controller with a mux for this use.

Signed-off-by: Yossi Mansharoff 
---
 Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt 
b/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt
index 0e03344..2e93181 100644
--- a/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt
+++ b/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt
@@ -76,6 +76,10 @@ Optional properties:
   needs to make sure it does not send more than 90%
   maximum_periodic_data_per_frame. The use case is multiple transactions, but
   less frame rate.
+- mux-controls: The mux control for toggling host/device output of this
+  controller. It's expected that a mux state of 0 indicates device mode and a
+  mux state of 1 indicates host mode.
+- mux-control-names: Shall be "usb_switch" if mux-controls is specified.
 
 i.mx specific properties
 - fsl,usbmisc: phandler of non-core register device, with one
@@ -102,4 +106,6 @@ Example:
rx-burst-size-dword = <0x10>;
extcon = <0>, <_id>;
phy-clkgate-delay-us = <400>;
+   mux-controls = <_switch>;
+   mux-control-names = "usb_switch";
};
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

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

[PATCH v2] usb: chipidea: Hook into mux framework to toggle usb switch

[Yossi Mansharoff]

On the db410c 96boards platform we have a TC7USB40MU on the board
to mux the D+/D- lines coming from the controller between a micro
usb "device" port and a USB hub for "host" roles[1]. During a
role switch, we need to toggle this mux to forward the D+/D-
lines to either the port or the hub. Add the necessary code to do
the role switch in chipidea core via the generic mux framework.
Board configurations like on db410c are expected to change roles
via the sysfs API described in
Documentation/ABI/testing/sysfs-platform-chipidea-usb2.

[1] 
https://github.com/96boards/documentation/raw/master/ConsumerEdition/DragonBoard-410c/HardwareDocs/Schematics_DragonBoard.pdf

Cc: Peter Rosin 
Cc: Peter Chen 
Cc: Greg Kroah-Hartman 
Cc: 
Signed-off-by: Stephen Boyd 

Signed-off-by: Yossi Mansharoff 
---
 drivers/usb/chipidea/Kconfig |  2 ++
 drivers/usb/chipidea/core.c  |  5 +
 drivers/usb/chipidea/host.c  |  7 +++
 drivers/usb/chipidea/udc.c   | 13 -
 include/linux/usb/chipidea.h |  2 ++
 5 files changed, 28 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/chipidea/Kconfig b/drivers/usb/chipidea/Kconfig
index 785f0ed..6a8e635 100644
--- a/drivers/usb/chipidea/Kconfig
+++ b/drivers/usb/chipidea/Kconfig
@@ -3,6 +3,8 @@ config USB_CHIPIDEA
depends on ((USB_EHCI_HCD && USB_GADGET) || (USB_EHCI_HCD && 
!USB_GADGET) || (!USB_EHCI_HCD && USB_GADGET)) && HAS_DMA
select EXTCON
select RESET_CONTROLLER
+   select MULTIPLEXER
+   select MUX_GPIO
help
  Say Y here if your system has a dual role high speed USB
  controller based on ChipIdea silicon IP. It supports:
diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index 33ae87f..8fa0991 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -61,6 +61,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "ci.h"
 #include "udc.h"
@@ -687,6 +688,10 @@ static int ci_get_platdata(struct device *dev,
if (of_find_property(dev->of_node, "non-zero-ttctrl-ttha", NULL))
platdata->flags |= CI_HDRC_SET_NON_ZERO_TTHA;
 
+   platdata->usb_switch = devm_mux_control_get_optional(dev, "usb_switch");
+   if (IS_ERR(platdata->usb_switch))
+   return PTR_ERR(platdata->usb_switch);
+
ext_id = ERR_PTR(-ENODEV);
ext_vbus = ERR_PTR(-ENODEV);
if (of_property_read_bool(dev->of_node, "extcon")) {
diff --git a/drivers/usb/chipidea/host.c b/drivers/usb/chipidea/host.c
index af45aa32..d9d2d00 100644
--- a/drivers/usb/chipidea/host.c
+++ b/drivers/usb/chipidea/host.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "../host/ehci.h"
 
@@ -161,6 +162,10 @@ static int host_start(struct ci_hdrc *ci)
if (ci_otg_is_fsm_mode(ci)) {
otg->host = >self;
hcd->self.otg_port = 1;
+   } else {
+   ret = mux_control_select(ci->platdata->usb_switch, 1);
+   if (ret)
+   goto disable_reg;
}
}
 
@@ -181,6 +186,8 @@ static void host_stop(struct ci_hdrc *ci)
struct usb_hcd *hcd = ci->hcd;
 
if (hcd) {
+   if (!ci_otg_is_fsm_mode(ci))
+   mux_control_deselect(ci->platdata->usb_switch);
if (ci->platdata->notify_event)
ci->platdata->notify_event(ci,
CI_HDRC_CONTROLLER_STOPPED_EVENT);
diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
index 9852ec5..209d3f6 100644
--- a/drivers/usb/chipidea/udc.c
+++ b/drivers/usb/chipidea/udc.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "ci.h"
 #include "udc.h"
@@ -1965,16 +1966,26 @@ void ci_hdrc_gadget_destroy(struct ci_hdrc *ci)
 
 static int udc_id_switch_for_device(struct ci_hdrc *ci)
 {
+   int ret = 0;
+
if (ci->is_otg)
/* Clear and enable BSV irq */
hw_write_otgsc(ci, OTGSC_BSVIS | OTGSC_BSVIE,
OTGSC_BSVIS | OTGSC_BSVIE);
 
-   return 0;
+   if (!ci_otg_is_fsm_mode(ci))
+   ret = mux_control_select(ci->platdata->usb_switch, 0);
+
+   if (ci->is_otg && ret)
+   hw_write_otgsc(ci, OTGSC_BSVIE | OTGSC_BSVIS, OTGSC_BSVIS);
+
+   return ret;
 }
 
 static void udc_id_switch_for_host(struct ci_hdrc *ci)
 {
+   mux_control_deselect(ci->platdata->usb_switch);
+
/*
 * host doesn't care B_SESSION_VALID event
 * so clear and disbale BSV irq
diff --git a/include/linux/usb/chipidea.h b/include/linux/usb/chipidea.h
index 07f9936..9ea55a1 100644
--- a/include/linux/usb/chipidea.h
+++ b/include/linux/usb/chipidea.h
@@ -10,6 +10,7 @@
 #include 
 
 struct ci_hdrc;
+struct 

Re: Fwd: usb: uas: device reset most the time while enumeration- usb3.0

[Mathias Nyman]

On 17.04.2018 09:23, Tushar Nimkar wrote:

On 2018-04-16 18:46, Mathias Nyman wrote:

On 16.04.2018 13:20, Tushar Nimkar wrote:

On 2018-04-05 11:31, Felipe Balbi wrote:

Hi,

it would help if you would Cc XHCI's maintainer :-)

tnim...@codeaurora.org writes:


On 2018-04-04 19:28, Greg KH wrote:

On Wed, Apr 04, 2018 at 06:41:41PM +0530, tnim...@codeaurora.org wrote:

On 2018-04-04 18:07, Greg KH wrote:
> On Wed, Apr 04, 2018 at 05:14:50PM +0530, tnim...@codeaurora.org wrote:
> > Hi Oliver/Greg,
> >
> > I am able to duplicated the UAS issue on 4.16 as well.
> > The behavior is same new usb device detects and reset after aprox 30
> > sec(SD_TIMEOUT)
> > Logs are already shared below.
> >
> > We are using Synopsys dwc3 as host controller, May I know have
> > tested it
> > with dwc3?
> > I have tried it on Linux PC (x86 Ubuntu machine) I could not see the
> > issue.
> > It enumerates well.
>
> Great, stick with an x86 platform!  :)
>
> Looks like a dwc3 host controller issue, try enabling tracing and
> debugging in that driver when this happens to see what is going on.

Oh if so let me enable the trace for that. I will respond you on this.


I did not get much clue, Greg.  sometime this device enumerates well,
attached both working and non working case logs.
following is not working case
root@OpenWrt:/# dmesg


...


[57214.172683] xhci-hcd xhci-hcd.0.auto: ep 0x83 - asked for 112 bytes,
96 bytes untransferred
[57214.172809] xhci-hcd xhci-hcd.0.auto: ep 0x83 - asked for 112 bytes,
96 bytes untransferred
[57214.172840] sd 1:0:0:0: [sdb] 976773168 512-byte logical blocks: (500
GB/466 GiB)
[57214.172843] xhci-hcd xhci-hcd.0.auto: ep 0x81 - asked for 4096 bytes,
4080 bytes untransferred
[57214.172851] xhci-hcd xhci-hcd.0.auto: ep 0x83 - asked for 112 bytes,
96 bytes untransferred
[57214.253085] xhci-hcd xhci-hcd.0.auto: xhci_hub_status_data: stopping
port polling.


Huge gap before uas_eh_abort_eh_handler is called.


SD_TIMEOUT of 30 sec ...



[57246.701096] sd 1:0:0:0: tag#0 uas_eh_abort_handler 0 uas-tag 1
inflight: CMD IN
[57246.701130] sd 1:0:0:0: tag#0 CDB: opcode=0x1a 1a 00 3f 00 04 00


URB is canceled, maybe that URB never finished?


[57246.707583] xhci-hcd xhci-hcd.0.auto: Cancel URB 07b523f0,
dev 1, ep 0x81, starting at offset 0
[57246.707594] xhci-hcd xhci-hcd.0.auto: // Ding dong!
[57246.707616] xhci-hcd xhci-hcd.0.auto: Stopped on No-op or Link TRB
for slot 1 ep 2
[57246.707625] xhci-hcd xhci-hcd.0.auto: Removing canceled TD starting
at 0x7f0cd0a0 (dma).
[57246.707630] xhci-hcd xhci-hcd.0.auto: Finding endpoint context
[57246.707634] xhci-hcd xhci-hcd.0.auto: Cycle state = 0x1
[57246.707637] xhci-hcd xhci-hcd.0.auto: New dequeue segment =
890c7dc4 (virtual)
[57246.707641] xhci-hcd xhci-hcd.0.auto: New dequeue pointer =
0x7f0cd0b0 (DMA)
[57246.707646] xhci-hcd xhci-hcd.0.auto: Set TR Deq Ptr cmd, new deq seg
= 890c7dc4 (0x7f0cd000 dmeq ptr = 0ce7faa0 (0x7f0cd0b0
dma), new cycle = 1
[57246.707651] xhci-hcd xhci-hcd.0.auto: // Ding dong!
[57246.707671] xhci-hcd xhci-hcd.0.auto: Successful Set TR Deq Ptr cmd,
deq = @7f0cd0b0
[57246.721090] scsi host1: uas_eh_device_reset_handler start
[57246.721114] xhci-hcd xhci-hcd.0.auto: Cancel URB 279f06a2,
dev 1, ep 0x83, starting at offset 0
[57246.721120] xhci-hcd xhci-hcd.0.auto: // Ding dong!
[57246.721135] xhci-hcd xhci-hcd.0.auto: ERROR Transfer event for
unknown stream ring slot 1 ep 6
[57246.725463] xhci-hcd xhci-hcd.0.auto: @7f044780 
 1b00 01078001


Stop -Length invalid transfer event. That is normal when canceling a URB,
but it should point to the TRB xhc was working on when stopped.
Here it just points to 0. That part looks like some issue with this specific
controller.

Some other errors may return 0 as their TRB pointer, but not this event.
 But this is not the cause, just a detail while handling the real cause.
Nothing in this log shows why the URB was canceled in the first place.

usbmon and xhci traces could help, xhci traces:

mount -t debugfs none /sys/kernel/debug
echo 81920 > /sys/kernel/debug/tracing/buffer_size_kb
echo 1 > /sys/kernel/debug/tracing/events/xhci-hcd/enable

then send /sys/kernel/debug/tracing/trace after issue triggered.

-Mathias


Mathias, here is usbmon and trace ..let us know on your observation which will 
help to learn more on xhci level :-)
(same is attached)



The xhci traces show that a ep1in bulk URB is queued on Stream 1, but never 
completes.
Similar URBs queued on the same stream ring before this one work and complete 
fine.

xhci driver never gets a short or success completion transfer event for the URB.
No error messages, nothing special going on either.

To me it looks like the URB was queued correctly, but after the stream protocol 
chose
to transfer and finish stream 2 it never went back to transfer what was queued 
for stream 1.

xhci specs section 4.12.1 say that
"Stream selection is driven by a USB device. The Stream Protocol allows 

Re: [PATCH 4/4] dt-bindings: Document the DT bindings for lan78xx

[Phil Elwell]

On 16/04/2018 20:22, Rob Herring wrote:
> On Thu, Apr 12, 2018 at 02:55:36PM +0100, Phil Elwell wrote:
>> The Microchip LAN78XX family of devices are Ethernet controllers with
>> a USB interface. Despite being discoverable devices it can be useful to
>> be able to configure them from Device Tree, particularly in low-cost
>> applications without an EEPROM or programmed OTP.
>>
>> Document the supported properties in a bindings file, adding it to
>> MAINTAINERS at the same time.
>>
>> Signed-off-by: Phil Elwell 
>> ---
>>  .../devicetree/bindings/net/microchip,lan78xx.txt  | 44 
>> ++
>>  MAINTAINERS|  1 +
>>  2 files changed, 45 insertions(+)
>>  create mode 100644 
>> Documentation/devicetree/bindings/net/microchip,lan78xx.txt
>>
>> diff --git a/Documentation/devicetree/bindings/net/microchip,lan78xx.txt 
>> b/Documentation/devicetree/bindings/net/microchip,lan78xx.txt
>> new file mode 100644
>> index 000..e7d7850
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/net/microchip,lan78xx.txt
>> @@ -0,0 +1,44 @@
>> +Microchip LAN78xx Gigabit Ethernet controller
>> +
>> +The LAN78XX devices are usually configured by programming their OTP or with
>> +an external EEPROM, but some platforms (e.g. Raspberry Pi 3 B+) have 
>> neither.
>> +
>> +Please refer to ethernet.txt for a description of common Ethernet bindings.
>> +
>> +Optional properties:
>> +- microchip,eee-enabled: if present, enable Energy Efficient Ethernet 
>> support;
> 
> I see we have some flags for broken EEE, but nothing already defined to 
> enable EEE. Seems like this should either be a user option (therefore 
> not in DT) or we should use the broken EEE properties if this is h/w 
> dependent.

In the downstream Raspberry Pi kernel we use DT as a way of passing user 
settings
to drivers - it's more powerful than the command line. I understand that this is
not the done thing here so I'm withdrawing this element of the patch series.

Apologies for the noise.

>> +- microchip,led-modes: a two-element vector, with each element configuring
>> +  the operating mode of an LED. The values supported by the device are;
>> +  0: Link/Activity
>> +  1: Link1000/Activity
>> +  2: Link100/Activity
>> +  3: Link10/Activity
>> +  4: Link100/1000/Activity
>> +  5: Link10/1000/Activity
>> +  6: Link10/100/Activity
>> +  7: RESERVED
>> +  8: Duplex/Collision
>> +  9: Collision
>> +  10: Activity
>> +  11: RESERVED
>> +  12: Auto-negotiation Fault
>> +  13: RESERVED
>> +  14: Off
>> +  15: On
>> +- microchip,tx-lpi-timer: the delay (in microseconds) between the TX fifo
>> +  becoming empty and invoking Low Power Idles (default 600).
> 
> Needs a unit suffix as defined in property-units.txt.
> 
>> +
>> +Example:
>> +
>> +/* Standard configuration for a Raspberry Pi 3 B+ */
>> +ethernet: usbether@1 {
>> +compatible = "usb424,7800";
>> +reg = <1>;
>> +microchip,eee-enabled;
>> +microchip,tx-lpi-timer = <600>;
>> +/*
>> + * led0 = 1:link1000/activity
>> + * led1 = 6:link10/100/activity
>> + */
>> +microchip,led-modes = <1 6>;
>> +};
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 2328eed..b637aad 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -14482,6 +14482,7 @@ M:   Microchip Linux Driver Support 
>> 
>>  L:  net...@vger.kernel.org
>>  S:  Maintained
>>  F:  drivers/net/usb/lan78xx.*
>> +F:  Documentation/devicetree/bindings/net/microchip,lan78xx.txt
>>  
>>  USB MASS STORAGE DRIVER
>>  M:  Alan Stern 
>> -- 
>> 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: Add udev-md-raid-safe-timeouts.rules

[Austin S. Hemmelgarn]

On 2018-04-16 13:10, Chris Murphy wrote:

Adding linux-usb@ and linux-scsi@
(This email does contain the thread initiating email, but some replies
are on the other lists.)

On Mon, Apr 16, 2018 at 5:43 AM, Austin S. Hemmelgarn
 wrote:

On 2018-04-15 21:04, Chris Murphy wrote:


I just ran into this:

https://github.com/neilbrown/mdadm/pull/32/commits/af1ddca7d5311dfc9ed60a5eb6497db1296f1bec

This solution is inadequate, can it be made more generic? This isn't
an md specific problem, it affects Btrfs and LVM as well. And in fact
raid0, and even none raid setups.

There is no good reason to prevent deep recovery, which is what
happens with the default command timer of 30 seconds, with this class
of drive. Basically that value is going to cause data loss for the
single device and also raid0 case, where the reset happens before deep
recovery has a chance. And even if deep recovery fails to return user
data, what we need to see is the proper error message: read error UNC,
rather than a link reset message which just obfuscates the problem.



This has been discussed at least once here before (probably more times, hard
to be sure since it usually comes up as a side discussion in an only
marginally related thread).  Last I knew, the consensus here was that it
needs to be changed upstream in the kernel, not by adding a udev rule
because while the value is technically system policy, the default policy is
brain-dead for anything but the original disks it was i9ntended for (30
seconds works perfectly fine for actual SCSI devices because they behave
sanely in the face of media errors, but it's horribly inadequate for ATA
devices).

To re-iterate what I've said before on the subject:

For ATA drives it should probably be 150 seconds.  That's 30 seconds beyond
the typical amount of time most consumer drives will keep retrying a sector,
so even if it goes the full time to try and recover a sector this shouldn't
trigger.  The only people this change should negatively impact are those who
have failing drives which support SCT ERC and have it enabled, but aren't
already adjusting this timeout.

For physical SCSI devices, it should continue to be 30 seconds.  SCSI disks
are sensible here and don't waste your time trying to recover a sector.  For
PV-SCSI devices, it should probably be adjusted too, but I don't know what a
reasonable value is.

For USB devices it should probably be higher than 30 seconds, but again I
have no idea what a reasonable value is.


I don't know how all of this is designed but it seems like there's
only one location for the command timer, and the SCSI driver owns it,
and then everyone else (ATA and USB and for all I know SAN) are on top
of that and lack any ability to have separate timeouts.
On the note of SAN, iSCSI is part of the SCSI subsystem, so it gets 
applied directly there.  I'm pretty sure NBD has it's own thing, and I 
think the same is true of ATAoE.


As far as USB, UMS is essentially a stripped down version of SCSI with 
it's own limitations, and UAS _is_ SCSI, with both of those having 
pretty much always been routed through the SCSI subsystem.


The nice thing about the udev rule is that it tests for SCT ERC before
making a change. There certainly are enterprise and almost enterprise
"NAS" SATA drives that have short SCT ERC times enabled out of the box
- and the udev method makes them immune to the change.
The kernel could just as easily look for that too though.  From what 
I've seen however, other failure sources that wouldn't trigger SCT ERC 
on SATA drives are really rare, usually it means a bad cable, bad drive 
electronics, or a bad storage controller, so i don't think having it set 
really high for SCT ERC enabled drives is likely to be much of an issue 
most of the time.

--
To unsubscribe from this list: send the line "unsubscribe 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: dwc2 ff540000.usb: dwc2_hc_chhltd_intr_dma: Channel 11 - ChHltd set, but reason is unknown

[Rodrigo Stuffs]

Hello Minas,

On Tue, Apr 17, 2018 at 4:51 AM, Minas Harutyunyan
 wrote:
> Hi Rodrigo,
>
>> == COMPILE BARFS ==
>>CC  drivers/usb/dwc2/hcd.o
>> drivers/usb/dwc2/hcd.c: In function ‘dwc2_core_init’:
>> drivers/usb/dwc2/hcd.c:2191:22: error: ‘trdtrim’ undeclared (first use
>> in this function); did you mean ‘strstrip’?
>>u32 usbcfg, otgctl; trdtrim;
>
> Your backport is wrong, you used semicolon instead of comma. Should be:
>  u32 usbcfg, otgctl, trdtrim;
>
> Thanks,
> Minas

Those... Punctuations!

Thank you very much! Kernel was built successfully and is now running.

Will monitor it and will let the list know about the results. Thank
you very much again!

- RF.
--
To unsubscribe from this list: send the line "unsubscribe 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: refine xhci-plat-Fix-xhci_plat-shutdown-sequence

[Greg KH]

On Tue, Apr 17, 2018 at 11:32:42AM +0800, lei...@codeaurora.org wrote:
> 
> xhci-plat Shutdown callback should check HCD_FLAG_HW_ACCESSIBLE
> before accessing any register. This should avoid hung with access
> controllers which support runtime suspend
> 
> This can fix for issue of https://patchwork.kernel.org/patch/10339317/
> corresponding upload in CAF:
> https://source.codeaurora.org/quic/la/kernel/msm-4.4/commit/?h=LV.HB.1.1.5-03810-8x96.0=a7a5307ee04ad349d365ad50f304605a9cd9bd0a
> 
> full patch refer attachment.
> diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
> index 9b27798..bdf914d 100644
> --- a/drivers/usb/host/xhci.c
> +++ b/drivers/usb/host/xhci.c
> @@ -702,6 +702,10 @@ static void xhci_shutdown(struct usb_hcd *hcd)
> usb_disable_xhci_ports(to_pci_dev(hcd->self.sysdev));
> 
> spin_lock_irq(>lock);
> +   if (!HCD_HW_ACCESSIBLE(hcd)) {
> +   spin_unlock_irq(>lock);
> +   return;
> +   }
> xhci_halt(xhci);

A blank line after the if statement?

What about all of the other places in this driver that you should also
check for this?  Look at the other host controllers, shouldn't you
mirror what they are doing?

And this needs a Fixes: tag, along with a cc: stable so as to properly
get backported as this is broken in some stable kernels right now.

thanks,

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

Re: refine xhci-plat-Fix-xhci_plat-shutdown-sequence

[Greg KH]

On Tue, Apr 17, 2018 at 11:32:42AM +0800, lei...@codeaurora.org wrote:
> 
> xhci-plat Shutdown callback should check HCD_FLAG_HW_ACCESSIBLE
> before accessing any register. This should avoid hung with access
> controllers which support runtime suspend
> 
> This can fix for issue of https://patchwork.kernel.org/patch/10339317/
> corresponding upload in CAF:
> https://source.codeaurora.org/quic/la/kernel/msm-4.4/commit/?h=LV.HB.1.1.5-03810-8x96.0=a7a5307ee04ad349d365ad50f304605a9cd9bd0a
> 
> full patch refer attachment.
> diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
> index 9b27798..bdf914d 100644
> --- a/drivers/usb/host/xhci.c
> +++ b/drivers/usb/host/xhci.c
> @@ -702,6 +702,10 @@ static void xhci_shutdown(struct usb_hcd *hcd)
> usb_disable_xhci_ports(to_pci_dev(hcd->self.sysdev));
> 
> spin_lock_irq(>lock);
> +   if (!HCD_HW_ACCESSIBLE(hcd)) {
> +   spin_unlock_irq(>lock);
> +   return;
> +   }
> xhci_halt(xhci);
> /* Workaround for spurious wakeups at shutdown with HSW */
> if (xhci->quirks & XHCI_SPURIOUS_WAKEUP)

> From 9b65acb64f1ad87d115fa147c9e947fb3d37471c Mon Sep 17 00:00:00 2001
> From: Lei wang 
> Date: Tue, 17 Apr 2018 10:55:35 +0800
> Subject: [PATCH] xhci: plat: Fix xhci_plat shutdown hung
> 
> xhci-plat Shutdown callback should check HCD_FLAG_HW_ACCESSIBLE
> before accessing any register. This should avoid hung with access
> controllers which support runtime suspend
> 
> Signed-off-by: Lei wang 
> ---
>  drivers/usb/host/xhci.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
> index 9b27798..bdf914d 100644
> --- a/drivers/usb/host/xhci.c
> +++ b/drivers/usb/host/xhci.c
> @@ -702,6 +702,10 @@ static void xhci_shutdown(struct usb_hcd *hcd)
>   usb_disable_xhci_ports(to_pci_dev(hcd->self.sysdev));
>  
>   spin_lock_irq(>lock);
> + if (!HCD_HW_ACCESSIBLE(hcd)) {
> + spin_unlock_irq(>lock);
> + return;
> + }
>   xhci_halt(xhci);
>   /* Workaround for spurious wakeups at shutdown with HSW */
>   if (xhci->quirks & XHCI_SPURIOUS_WAKEUP)
> -- 
> 1.9.1
> 

Hi,

This is the friendly patch-bot of Greg Kroah-Hartman.  You have sent him
a patch that has triggered this response.  He used to manually respond
to these common problems, but in order to save his sanity (he kept
writing the same thing over and over, yet to different people), I was
created.  Hopefully you will not take offence and will fix the problem
in your patch and resubmit it so that it can be accepted into the Linux
kernel tree.

You are receiving this message because of the following common error(s)
as indicated below:

- Your patch was attached, please place it inline so that it can be
  applied directly from the email message itself.

If you wish to discuss this problem further, or you have questions about
how to resolve this issue, please feel free to respond to this email and
Greg will reply once he has dug out from the pending patches received
from other developers.

thanks,

greg k-h's patch email bot
--
To unsubscribe from this list: send the line "unsubscribe 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: always build usb/common/ targets; fixes extcon-axp288 build error

[Hans de Goede]

Hi,

On 17-04-18 07:14, Randy Dunlap wrote:

From: Randy Dunlap 

The extcon-axp288 driver selects USB_ROLE_SWITCH, but the USB
Makefile does not currently build drivers/usb/common/ (where
USB_ROLE_SWITCH code is) unless USB_COMMON is set, so modify
the USB Makefile to always descend into drivers/usb/common/
to build its configured targets.

Fixes these build errors:

ERROR: "usb_role_switch_get" [drivers/extcon/extcon-axp288.ko] undefined!
ERROR: "usb_role_switch_set_role" [drivers/extcon/extcon-axp288.ko] undefined!
ERROR: "usb_role_switch_get_role" [drivers/extcon/extcon-axp288.ko] undefined!
ERROR: "usb_role_switch_put" [drivers/extcon/extcon-axp288.ko] undefined!

An alternative patch would be to select USB_COMMON in the EXTCON_AXP288
driver Kconfig entry, but this would build more code in
drivers/usb/common/ than is necessary.


Ah, that variant of fixing this got posted yesterday and I acked that,
but I agree that this version is better.

Greg, what is your take on this fix?

Chanwoo Choi, please wait with merging the fix from yesterday until
we've a decision which fix to use.

Regards,

Hans





Reported-by: Fengguang Wu 
Signed-off-by: Randy Dunlap 
Cc: MyungJoo Ham 
Cc: Chanwoo Choi 
Cc: Hans de Goede 
Cc: Greg Kroah-Hartman 
Cc: Andy Shevchenko 
Cc: Heikki Krogerus 
Cc: linux-usb@vger.kernel.org
---
  drivers/usb/Makefile |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

--- lnx-417-rc1.orig/drivers/usb/Makefile
+++ lnx-417-rc1/drivers/usb/Makefile
@@ -60,7 +60,7 @@ obj-$(CONFIG_USB_CHIPIDEA)+= chipidea/
  obj-$(CONFIG_USB_RENESAS_USBHS)   += renesas_usbhs/
  obj-$(CONFIG_USB_GADGET)  += gadget/
  
-obj-$(CONFIG_USB_COMMON)	+= common/

+obj-y  += common/
  
  obj-$(CONFIG_USBIP_CORE)	+= usbip/
  




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

Re: [PATCH 2/3] usb: gadget: configfs: Create control_config group

[Andrzej Pietrasiewicz]

Hi again,

W dniu 17.04.2018 o 09:55, Andrzej Pietrasiewicz pisze:
> Hi,
> 
> W dniu 17.04.2018 o 03:17, Jerry Zhang pisze:
>> Control_config is a group under gadget that acts
> 
> 
> 
>>
>> @@ -1461,6 +1499,18 @@ static struct config_group *gadgets_make(
>>  if (!gi->composite.gadget_driver.function)
>>  goto err;
>>
>> +gi->control_config.c.label = "control_config";
>> +/* composite requires some value, but it doesn't matter */
>> +gi->control_config.c.bConfigurationValue = 42;
> 
> If I understand correctly this is never exposed to the host, is it?
> 
>> +INIT_LIST_HEAD(>control_config.func_list);
>> +config_group_init_type_name(>control_config.group,
>> +"control_config", _config_type);
>> +configfs_add_default_group(>control_config.group, >group);
> 
> Since it is a config I'd rather this be put inside the "configs" group.
> Configs created by the user must be named following the
> . pattern, so there will be no conflict
> with any other conf. The name can be "control" then.
> 

Answering my own doubts: this could be ok from the kernel point of view,
but existing userspace (libusbgx) already assumes that in the configs directory
there are only entries of the form . and anything other than 
that
will cause it to report error.

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

Re: [PATCH 0/3] Fix an Atmel USBA UDC issue introducted in 4.17-rc1

[Nicolas Ferre]

On 16/04/2018 at 11:34, Romain Izard wrote:

The use of GPIO descriptors takes care of inversion flags declared in
the device tree. The conversion of the Atmel USBA UDC driver introduced
in 4.17-rc1 missed it, and as a result the inversion will not work.

In addition, cleanup the code to remove an include left behind after
the suppression of the support of platform_data to declare USBA
controllers.

These changes have not been tested on any hardware, as I do not have
a board that needs to use inverted GPIOs.

Romain Izard (3):
   usb: gadget: udc: atmel: GPIO inversion is handled by gpiod
   usb: gadget: udc: atmel: Remove obsolete include
   usb: gadget: udc: atmel: Fix indenting


To the whole series:
Acked-by: Nicolas Ferre 

Thank you Romain.
Best regards,
  Nicolas



  drivers/usb/gadget/udc/atmel_usba_udc.c | 22 ++
  drivers/usb/gadget/udc/atmel_usba_udc.h |  1 -
  include/linux/usb/atmel_usba_udc.h  | 24 
  3 files changed, 10 insertions(+), 37 deletions(-)
  delete mode 100644 include/linux/usb/atmel_usba_udc.h




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

Re: [PATCH 2/3] usb: gadget: configfs: Create control_config group

[Andrzej Pietrasiewicz]

Hi,

W dniu 17.04.2018 o 03:17, Jerry Zhang pisze:
> Control_config is a group under gadget that acts



>   
> @@ -1461,6 +1499,18 @@ static struct config_group *gadgets_make(
>   if (!gi->composite.gadget_driver.function)
>   goto err;
>   
> + gi->control_config.c.label = "control_config";
> + /* composite requires some value, but it doesn't matter */
> + gi->control_config.c.bConfigurationValue = 42;

If I understand correctly this is never exposed to the host, is it?

> + INIT_LIST_HEAD(>control_config.func_list);
> + config_group_init_type_name(>control_config.group,
> + "control_config", _config_type);
> + configfs_add_default_group(>control_config.group, >group);

Since it is a config I'd rather this be put inside the "configs" group.
Configs created by the user must be named following the
. pattern, so there will be no conflict
with any other conf. The name can be "control" then.

> +
> + if (usb_add_config_only(>cdev, >control_config.c))
> + goto err;
> + list_del(>control_config.c.list);
> +
>   return >group;
>   err:
>   kfree(gi);
> 

Andrzej
--
To unsubscribe from this list: send the line "unsubscribe 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: dwc2 ff540000.usb: dwc2_hc_chhltd_intr_dma: Channel 11 - ChHltd set, but reason is unknown

[Minas Harutyunyan]

Hi Rodrigo,

On 4/16/2018 7:27 PM, Rodrigo Stuffs wrote:
> Hi there Minas / linux-usb ;
> 
> I have a good ole APC Back-UPS ES 600N that from time to time resolves
> that it should stop talking to my SBCs.
> 
> This issue happened in my Raspberry Pi, and when it stopped I had the
> following printk:
> 
> Apr 11 14:10:15 localhost kernel: [9416331.806123] hid-generic
> 0003:051D:0002.000A: usb_submit_urb(ctrl) failed: -1
> 
> All I had to do is monitor the graphics and when it flatlined, unplug
> and plug the UPS usb port. Until the next occurrence. Well, I lived
> with it for some good years.
> 
> Last weekend I changed the Raspberry Pi with a TinkerBoard. And the
> cranky UPS is also tickling TinkerBoard's USB port. Now the issue
> manifests in a slightly different way:
> 
> == DEVICE ENUMERATION ==
> [56529.462106] usb 1-1.1.3: new low-speed USB device number 9 using dwc2
> [56530.222538] usb 1-1.1.3: New USB device found, idVendor=051d, 
> idProduct=0002
> [56530.222638] usb 1-1.1.3: New USB device strings: Mfr=3, Product=1,
> SerialNumber=2
> [56530.222697] usb 1-1.1.3: Product: Back-UPS ES 600N FW:876.Q1j.D USB FW:Q1j
> [56530.222772] usb 1-1.1.3: Manufacturer: APC
> [56530.222821] usb 1-1.1.3: SerialNumber: 5B1017T20483
> [56535.075030] hid-generic 0003:051D:0002.0003: hiddev0,hidraw1: USB
> HID v1.10 Device [APC Back-UPS ES 600N FW:876.Q1j.D USB FW:Q1j] on
> usb-ff54.usb-1.1.3/input0
> 
> == KERNEL WHINES ==
> [105243.156331] dwc2 ff54.usb: dwc2_hc_chhltd_intr_dma: Channel 11
> - ChHltd set, but reason is unknown
> [105243.156414] dwc2 ff54.usb: hcint 0x0002, intsts 0x06600029
> [105273.536188] dwc2 ff54.usb: dwc2_hc_chhltd_intr_dma: Channel 13
> - ChHltd set, but reason is unknown
> [105273.536268] dwc2 ff54.usb: hcint 0x0002, intsts 0x06600029
> 
> Well, in spirit to getting things going nicely in the new system, I
> have found the thread:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.spinics.net_lists_linux-2Dusb_msg161854.html=DwIFaQ=DPL6_X_6JkXFx7AXWqB0tg=cQBKt4q-qzNVC53rNAwuwplH23V61rHQhhULvdLA0U8=YSUQg6kIP4Y-Gp3eOPRqJsOKFEqJhfwK5i4u4G3GSx4=dlmTJf4doonVjjhkGKKAInIpIaKQuPrpIpmCm5eEKGM=
> 
> Where Minas suggests a patch to tackle it.
> 
> I tried to backport the patch to my 4.4 Kernel and it was not really
> happy about it:
> 
> == COMPILE BARFS ==
>CC  drivers/usb/dwc2/hcd.o
> drivers/usb/dwc2/hcd.c: In function ‘dwc2_core_init’:
> drivers/usb/dwc2/hcd.c:2191:22: error: ‘trdtrim’ undeclared (first use
> in this function); did you mean ‘strstrip’?
>u32 usbcfg, otgctl; trdtrim;

Your backport is wrong, you used semicolon instead of comma. Should be:
 u32 usbcfg, otgctl, trdtrim;

Thanks,
Minas


>^~~
>strstrip
> drivers/usb/dwc2/hcd.c:2191:22: note: each undeclared identifier is
> reported only once for each function it appears in
> drivers/usb/dwc2/hcd.c:2192:2: warning: ISO C90 forbids mixed
> declarations and code [-Wdeclaration-after-statement]
> error, forbidden warning: hcd.c:2192
> scripts/Makefile.build:277: recipe for target 'drivers/usb/dwc2/hcd.o' failed
> make[3]: *** [drivers/usb/dwc2/hcd.o] Error 1
> scripts/Makefile.build:484: recipe for target 'drivers/usb/dwc2' failed
> make[2]: *** [drivers/usb/dwc2] Error 2
> scripts/Makefile.build:484: recipe for target 'drivers/usb' failed
> make[1]: *** [drivers/usb] Error 2
> Makefile:1016: recipe for target 'drivers' failed
> make: *** [drivers] Error 2
> 
> 
> 
> Patchset: 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__pastebin.com_v1ink6fJ=DwIFaQ=DPL6_X_6JkXFx7AXWqB0tg=cQBKt4q-qzNVC53rNAwuwplH23V61rHQhhULvdLA0U8=YSUQg6kIP4Y-Gp3eOPRqJsOKFEqJhfwK5i4u4G3GSx4=c0BOzNW40WKgpIngxNKxkJ4qY2bN3h7R2a2DnIBLv3Q=
> 
> == QUESTIONS ==
> 1. What are the odds that the OP patchset will also help my issue?
> 2. IF 1 == true ; then what am I doing wrong in my patch? :-)
> 
> Appreciate your time.
> 

--
To unsubscribe from this list: send the line "unsubscribe 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 02/20] usb: host: xhci: check DYING state earlier

[Felipe Balbi]

Hi,

Mathias Nyman  writes:
> On 16.04.2018 15:29, Felipe Balbi wrote:
>> Instead of allocating urb priv and, maybe, bail out due to xhci being
>> in DYING state, we can move the check earlier and avoid the memory
>> allocation altogether.
>
> This also moves checking for DYING outside the lock.
>
> Most cases set DYING with lock held, so if we first get the lock before
> checking DYING we have a better chance of not being in the process of dying.

pretty sure that's atomic, though.

> Small thing, but so is this cleanup, so not sure its worth the change

Look at the result. With this change we don't need to take a lock,
allocate memory, search for endpoint index, search for endpoint
state. All of those are needed for proper operation of the function, but
if the controller has already died, there's no point in going any
further.

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH 3/3] USB: musb: dsps: propagate device-tree node

[Johan Hovold]

On Mon, Apr 16, 2018 at 03:03:12PM -0500, Bin Liu wrote:
> Johan,
> 
> On Fri, Apr 13, 2018 at 05:15:05PM +0200, Johan Hovold wrote:
> > To be able to use DSPS-based controllers with device-tree descriptions
> > of the USB topology, we need to associate the glue device's device-tree
> > node with the child controller device.
> > 
> > Note that this can also be used to eventually let USB core manage
> > generic phys.
> > 
> > Also note that the other glue drivers will require similar changes to be
> > able to describe their buses in DT.
> > 
> > Signed-off-by: Johan Hovold 
> 
> I will take other two patches for v4.17 rc cycles, but is there any
> problem if I take this patch for v4.18-rc1?

None at all. That sounds good to me.

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

Re: Fwd: usb: uas: device reset most the time while enumeration- usb3.0

[Tushar Nimkar]

On 2018-04-16 20:03, Oliver Neukum wrote:

Am Montag, den 16.04.2018, 10:23 -0400 schrieb Alan Stern:

> > > > [57246.701096] sd 1:0:0:0: tag#0 uas_eh_abort_handler 0 uas-tag 1
> > > > inflight: CMD IN
> > > > [57246.701130] sd 1:0:0:0: tag#0 CDB: opcode=0x1a 1a 00 3f 00 04 00
>
> URB is canceled, maybe that URB never finished?

No doubt.  Perhaps the device doesn't support this particular command.


Then we should expect the enumeration to always fail.
Possibly the lower layers swallow the transfer.

Note not every time abort with 0x1a command ..sometimes it is with 0x9e, 
0x12, 0xa0.
As my observation issue is observed during read_capacity_16/REPORT_LUN 
or INQUIRY.

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


--
Best Regards,
Tushar R Nimkar

QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a 
member of Code Aurora Forum, hosted by The Linux Foundation


--
To unsubscribe from this list: send the line "unsubscribe 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 RFC] usb: typec: tcpm: remove operating_snk_mw for rdo

[Li Jun]

This patch is a further update for rdo based on [1], which
removed max_snk_ma/mv/mw but kept operating_snk_mw.
operating_snk_mw is only used to judge capability mismatch,
per PD spec, we can achieve this via compare the selected
source PDO and matching sink PDO, also after patch [1], we
don't limit the PDO matching between the same type, so the
rdo operating and max current/power calculation should be
updated accordingly.

[1]https://patchwork.kernel.org/patch/10342299/

Signed-off-by: Li Jun 
---
 drivers/usb/typec/tcpm.c | 52 ++--
 1 file changed, 33 insertions(+), 19 deletions(-)

diff --git a/drivers/usb/typec/tcpm.c b/drivers/usb/typec/tcpm.c
index 27192083..0be04b3 100644
--- a/drivers/usb/typec/tcpm.c
+++ b/drivers/usb/typec/tcpm.c
@@ -1854,28 +1854,42 @@ static int tcpm_pd_build_request(struct tcpm_port 
*port, u32 *rdo)
else
mv = pdo_min_voltage(pdo);
 
-   /* Select maximum available current within the sink pdo's limit */
-   if (type == PDO_TYPE_BATT) {
-   mw = min_power(pdo, matching_snk_pdo);
-   ma = 1000 * mw / mv;
-   } else {
-   ma = min_current(pdo, matching_snk_pdo);
-   mw = ma * mv / 1000;
-   }
-
flags = RDO_USB_COMM | RDO_NO_SUSPEND;
 
-   /* Set mismatch bit if offered power is less than operating power */
-   max_ma = ma;
-   max_mw = mw;
-   if (mw < port->operating_snk_mw) {
-   flags |= RDO_CAP_MISMATCH;
-   if (type == PDO_TYPE_BATT &&
-   (pdo_max_power(matching_snk_pdo) > pdo_max_power(pdo)))
-   max_mw = pdo_max_power(matching_snk_pdo);
-   else if (pdo_max_current(matching_snk_pdo) >
-pdo_max_current(pdo))
+   switch (type) {
+   case PDO_TYPE_FIXED:
+   case PDO_TYPE_VAR:
+   if (pdo_type(matching_snk_pdo) == PDO_TYPE_BATT)
+   max_ma = pdo_max_power(matching_snk_pdo) * 1000 / mv;
+   else
max_ma = pdo_max_current(matching_snk_pdo);
+
+   if (max_ma > pdo_max_current(pdo)) {
+   flags |= RDO_CAP_MISMATCH;
+   ma = pdo_max_current(pdo);
+   } else {
+   ma = max_ma;
+   }
+   break;
+   case PDO_TYPE_BATT:
+   if (pdo_type(matching_snk_pdo) == PDO_TYPE_BATT)
+   max_mw = pdo_max_power(matching_snk_pdo);
+   else
+   max_mw = pdo_max_current(matching_snk_pdo) *
+pdo_min_voltage(matching_snk_pdo) /
+1000;
+
+   if (max_mw > pdo_max_power(pdo)) {
+   flags |= RDO_CAP_MISMATCH;
+   mw = pdo_max_power(pdo);
+   } else {
+   mw = max_mw;
+   }
+
+   ma = mw * 1000 / mv;
+   break;
+   default:
+   break;
}
 
tcpm_log(port, "cc=%d cc1=%d cc2=%d vbus=%d vconn=%s polarity=%d",
-- 
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