Re: Infrastructure for zerocopy I/O

On Mon, Nov 16, 2015 at 03:22:06PM -0500, Alan Stern wrote: > In other words, you're suggesting we do this: > > Check that userspace requested zerocopy (otherwise the user > program might try to access other data stored in the same cache > lines as the buffer while the I/O is

[PATCH v3] usb: chipidea: removing of_find_property

call to of_find_property() before of_property_read_u32() is unnecessary. of_property_read_u32() anyway calls to of_find_property() only. Signed-off-by: Saurabh Sengar --- v2 : removed pval variable v3 : removed unnecessary if condition drivers/usb/chipidea/core.c | 59

Re: [PATCH v2] usb: chipidea: removing of_find_property

ING on peter.chen-usb/ci-for-usb-next] > [also build test WARNING on v4.4-rc1 next-20151117] > > url: > https://github.com/0day-ci/linux/commits/Saurabh-Sengar/usb-chipidea-removing-of_find_property/20151117-194333 > base: https://git.kernel.org/pub/scm/linux/kernel/gi

Re: [PATCH v12 1/3] dt-bindings: Add a binding for Mediatek xHCI host controller

Hello. On 11/17/2015 12:18 PM, Chunfeng Yun wrote: add a DT binding documentation of xHCI host controller for the MT8173 SoC from Mediatek. Signed-off-by: Chunfeng Yun --- .../devicetree/bindings/usb/mt8173-xhci.txt| 51 ++ 1 file

Re: Infrastructure for zerocopy I/O

On Tue, 2015-11-17 at 13:07 +0100, Steinar H. Gunderson wrote: > On Mon, Nov 16, 2015 at 03:22:06PM -0500, Alan Stern wrote: > > Check that userspace requested zerocopy (otherwise the user > > program might try to access other data stored in the same cache > > lines as the buffer

Re: [PATCH] usb: chipidea: removing of_find_property

Saurabh Sengar writes: > call to of_find_property() before of_property_read_u32() is unnecessary. > of_property_read_u32() anyway calls to of_find_property() only. > > Signed-off-by: Saurabh Sengar > --- > drivers/usb/chipidea/core.c | 67 >

[PATCH] usb: chipidea: removing of_find_property

call to of_find_property() before of_property_read_u32() is unnecessary. of_property_read_u32() anyway calls to of_find_property() only. Signed-off-by: Saurabh Sengar --- drivers/usb/chipidea/core.c | 67 ++--- 1 file changed, 32

[PATCH v2] usb: chipidea: removing of_find_property

call to of_find_property() before of_property_read_u32() is unnecessary. of_property_read_u32() anyway calls to of_find_property() only. Signed-off-by: Saurabh Sengar --- v2: removed pval variable drivers/usb/chipidea/core.c | 61

Re: [PATCH v2] usb: chipidea: removing of_find_property

t;> >> Hi Saurabh, >> >> [auto build test WARNING on peter.chen-usb/ci-for-usb-next] >> [also build test WARNING on v4.4-rc1 next-20151117] >> >> url: >> https://github.com/0day-ci/linux/commits/Saurabh-Sengar/usb-chipidea-removing-of_find_proper

[PATCH] ARM: dts: sun8i-h3-orangepi-plus: Enable USB host controllers

Enable the 2 USB host controllers used on the Orange Pi Plus and add the necessary regulators. Signed-off-by: Reinder de Haan Signed-off-by: Hans de Goede Signed-off-by: Jens Kuske --- Hi Hans, with these regulators USB works on

Re: [PATCH v2 1/2] usb: dwc2: host: Fix missing device insertions

Alan, On Tue, Nov 17, 2015 at 7:40 AM, Alan Stern wrote: > On Mon, 16 Nov 2015, Doug Anderson wrote: > >> > Fundamentally there's no difference between a "connect" interrupt and a >> > "disconnect" interrupt. They should both do exactly the same things: >> > clear the

[PATCH] drivers:hid:usbhid Fix ERROR: "foo * bar" should be "foo *bar"

This fixes all errors from checkpatch.pl about that "foo * bar" should be "foo *bar" Signed-off-by: Bogicevic Sasa --- drivers/hid/usbhid/hiddev.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/hid/usbhid/hiddev.c

Re: [PATCH v2] usb: chipidea: removing of_find_property

Saurabh Sengar writes: > call to of_find_property() before of_property_read_u32() is unnecessary. > of_property_read_u32() anyway calls to of_find_property() only. > > Signed-off-by: Saurabh Sengar > --- > v2: removed pval variable >

[PATCHv2] usb: dwc3: gadget: let us set lower max_speed

From: Ben McCauley In some SoCs, dwc3 is implemented as a USB2.0 only core, meaning that it can't ever achieve SuperSpeed. Currect driver always sets gadget.max_speed to USB_SPEED_SUPER unconditionally. This can causes issues to some Host stacks where the host will

Re: [PATCH v2 1/2] usb: dwc2: host: Fix missing device insertions

On Mon, 16 Nov 2015, Doug Anderson wrote: > > Fundamentally there's no difference between a "connect" interrupt and a > > "disconnect" interrupt. They should both do exactly the same things: > > clear the interrupt source, post a "connection change" event, and set > > the driver's connect status

Re: Help needed for EHCI problem: removing an active bulk-in QH

On Thu, Nov 12, 2015 at 10:46 AM, Michael Reutman wrote: > On Mon, Nov 9, 2015 at 9:21 AM, Alan Stern wrote: >> Here's a revised quick-and-dirty workaround. It replaces the earlier >> one. (And like the earlier one, it is meant to apply on

Re: [PATCH 1/3] usb: renesas_usbhs: gadget: Fix NULL pointer dereference in usbhsg_ep_dequeue()

Hi, Yoshihiro Shimoda writes: > This patch fixes an issue that NULL pointer dereference happens when > a gadget driver calls usb_ep_dequeue() after usb_ep_disable(). > > Signed-off-by: Yoshihiro Shimoda and which gadget

Re: scsi-sd fails with error "Invalid field in cdb" for SATA-to-USB adapter JMicron

On 2015-11-12 13:09, Dmitry Katsubo wrote: > On 2015-11-11 16:16, Alan Stern wrote: >>> Bus 001 Device 007: ID 152d:0567 JMicron Technology Corp. / JMicron USA >>> Technology Corp. >>> Device Descriptor: >>>bLength18 >>>bDescriptorType 1 >>>bcdUSB

Re: Infrastructure for zerocopy I/O

On Tue, 17 Nov 2015, Christoph Hellwig wrote: > On Mon, Nov 16, 2015 at 03:22:06PM -0500, Alan Stern wrote: > > In other words, you're suggesting we do this: > > > > Check that userspace requested zerocopy (otherwise the user > > program might try to access other data stored in the same

Re: Infrastructure for zerocopy I/O

On Mon, Nov 16, 2015 at 03:22:06PM -0500, Alan Stern wrote: > Check that userspace requested zerocopy (otherwise the user > program might try to access other data stored in the same cache > lines as the buffer while the I/O is in progres); Needed for send only, right? For

Re: [PATCH] usb: gadget: Add the console support for usb-to-serial port

On Mon, Nov 16, 2015 at 9:05 AM, Baolin Wang wrote: > It dose not work when we want to use the usb-to-serial port based > on one usb gadget as a console. Thus this patch adds the console > initialization to support this request. > @@ -79,6 +80,16 @@ > */ > #define

Re: scsi-sd fails with error "Invalid field in cdb" for SATA-to-USB adapter JMicron

On Tue, 17 Nov 2015, Dmitry Katsubo wrote: > Alan, I have difficulties with making it working. The patch that was > supposed to be trivial, does not work. The problem is that given USB > adapter is detected as "uas" device (so, driven by uas.ko module). It > took me few days to understand that,

Re: Help needed for EHCI problem: removing an active bulk-in QH

On Tue, 17 Nov 2015, Michael Reutman wrote: > > Apologies for the delay, been working on another project recently that > > has taken up most of my time. > > > > I applied the patch and have ran our application for 20 to 30 minutes > > thus far without issue. Later on tonight I'll set it up for an

Re: Infrastructure for zerocopy I/O

There are 2 problems with the current implementation: 1. the memset on isochronous transfers to empty the buffers in order to avoid leaking raw memory to userspace (this costs a lot on intel Atoms and is also noticeable on other systems). 2. the memory fragmentation. Seems like recent systems

[GIT PULL] USB fixes for v4.4-rc2

Hi Greg, Here's the first round of fixes for this first rc. Only 11 commits this time. Let me know if you want anything to be changed. thanks The following changes since commit 8005c49d9aea74d382f474ce11afbbc7d7130bec: Linux 4.4-rc1 (2015-11-15 17:00:27 -0800) are available in the git

Re: Infrastructure for zerocopy I/O

On Tue, Nov 17, 2015 at 07:17:31PM +0100, Markus Rechberger wrote: > 1. the memset on isochronous transfers to empty the buffers in order > to avoid leaking raw memory to userspace (this costs a lot on intel > Atoms and is also noticeable on other systems). > > 2. the memory fragmentation. Seems

Re: Infrastructure for zerocopy I/O

On Tue, 17 Nov 2015, Markus Rechberger wrote: > There are 2 problems with the current implementation: > > 1. the memset on isochronous transfers to empty the buffers in order > to avoid leaking raw memory to userspace (this costs a lot on intel > Atoms and is also noticeable on other systems).

Re: Infrastructure for zerocopy I/O

Just a side note, for older videodevices it was also common to allocate the DMA memory during bootup because it might have failed during runtime because of memory fragmentation. The reason for the memset on the isochronous transfer is that USB might not fill up the entire buffer leaving half of

Re: [GIT PULL] USB fixes for v4.4-rc2

On Tue, Nov 17, 2015 at 11:41:03AM -0600, Felipe Balbi wrote: > Hi Greg, > > Here's the first round of fixes for this first > rc. Only 11 commits this time. > > Let me know if you want anything to be changed. > > thanks > > The following changes since commit

Re: Infrastructure for zerocopy I/O

Hi, Markus Rechberger writes: > Such kind of security is a little bit odd for a stack that doesn't > work nearly as well as Mac or Windows. And you say this based on what, exactly ? Linux supports many more devices, it's usually faster with most devices (actually Mac's

[PATCH] usb: Quiet down false peer failure messages

My recent Intel box is spewing these messages: xhci_hcd :00:14.0: xHCI Host Controller xhci_hcd :00:14.0: new USB bus registered, assigned bus number 2 usb usb2: New USB device found, idVendor=1d6b, idProduct=0003 usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb

[PATCH] USB: USB_OTG does not depend on PM

USB_OTG initially depended on USB_SUSPEND, which was later turned into PM_RUNTIME and finally into PM. I don't know at what point the dependency became unnecessary but it appears to work fine without CONFIG_PM now. However, we get lots of warnings in randconfig kernels like: warning:

Re: Infrastructure for zerocopy I/O

On Tue, Nov 17, 2015 at 02:07:58PM -0500, Alan Stern wrote: > Is there an API for allocating user memory below 4 GB? Would a new > MMAP flag be acceptable? MAP_32BIT (to mmap) can seemingly do this, but from the man page, it sounds more like a kludge than anything else. /* Steinar */ --

Re: Infrastructure for zerocopy I/O

On Tue, 17 Nov 2015, Steinar H. Gunderson wrote: > On Tue, Nov 17, 2015 at 02:13:49PM -0500, Alan Stern wrote: > > But what other way of allocating memory is there? > > For my part, GPU memory versus malloc(). (You can ask OpenGL to permanently > map up a chunk of GPU memory for you into

Re: Infrastructure for zerocopy I/O

By the way on MacOSX we also pre-allocate some buffer in userspace first for everything. Well it's up to you anyway I haven't seen a move into a good direction in that area for years anyway on Linux so I'm used to deal with what is currently available. On Tue, Nov 17, 2015 at 8:13 PM, Alan Stern

Re: Infrastructure for zerocopy I/O

On Tue, Nov 17, 2015 at 02:13:49PM -0500, Alan Stern wrote: > But what other way of allocating memory is there? For my part, GPU memory versus malloc(). (You can ask OpenGL to permanently map up a chunk of GPU memory for you into userspace, but you have no guarantees as of if it's DMA-able. But

Re: [PATCH] usb: gadget: Add the console support for usb-to-serial port

On 17 November 2015 at 21:34, Andy Shevchenko wrote: > On Mon, Nov 16, 2015 at 9:05 AM, Baolin Wang wrote: >> It dose not work when we want to use the usb-to-serial port based >> on one usb gadget as a console. Thus this patch adds the console

[PATCH] usb: Use the USB_SS_MULT() macro to decode burst multiplier for log message

usb_parse_ss_endpoint_companion() now decodes the burst multiplier correctly in order to check that it's <= 3, but still uses the wrong expression if warning that it's > 3. Fixes: ff30cbc8da42 ("usb: Use the USB_SS_MULT() macro to get the ...") Signed-off-by: Ben Hutchings

RE: [PATCH 1/3] usb: renesas_usbhs: gadget: Fix NULL pointer dereference in usbhsg_ep_dequeue()

Hi, > From: Felipe Balbi [mailto:ba...@ti.com] > Sent: Wednesday, November 18, 2015 12:32 AM > > Hi, > > Yoshihiro Shimoda writes: > > This patch fixes an issue that NULL pointer dereference happens when > > a gadget driver calls usb_ep_dequeue() after

[PATCH v2] usb: renesas_usbhs: gadget: Fix NULL pointer dereference in usbhsg_ep_dequeue()

This patch fixes an issue that NULL pointer dereference happens when a gadget driver calls usb_ep_dequeue() for ep0 after disconnected a usb cable. This is because that usbhsg_try_stop() will call usbhsg_ep_disable(>ep) when a usb cable is disconnected and the pipe of dcp (ep0) is set to NULL.

[PATCH v2 0/3] usb: renesas_usbhs: gadget: modifications for g_audio

This patch is based on the latest Felipe's usb.git / testing/next branch. (The commit id = 81e9d14a53eb1abfbe6ac828a87a2deb4702b5f1) Changes from v1: - Rebase the latest usb.git testing/next branch. - Separate other one patch. (In other words, that patch is for bugfix.) Yoshihiro Shimoda (2):

[PATCH v2 2/2] usb: renesas_usbhs: Modify ep.caps.type_xxx and usb_ep_maxpacket_limit()

This patch modifies the ep.caps.type_{iso,bulk,int} setting and the second argument of usb_ep_maxpacket_limit() using the dparam.pipe_configs. In the previous code, all the type_{iso,bulk,int} were set to true. However, to avoid waste time for finding suitable pipe in usb_ep_enable(), this driver

[PATCH v2 1/2] usb: renesas_usbhs: Modify pipe configuration

The current code has info->bufnmb_last to calculate the BUFNMB bits of PIPEBUF register. However, since the bufnmb_last is initialized in the usbhs_pipe_init() only, this driver is possible to set unexpected value to the register if usb_ep_{enable,disable}() are called many times. So, this patch

Re: [PATCH v3] usb: chipidea: removing of_find_property

Hi Peter, Yes itc_setting is still optional, in case dts does not pass this property, return type will be -EINVAL and there would be no problem. The function will break only if there is 'No data'(-ENODATA) or 'overflow'(-ENODATA) error for this property. In case this is not OK, I will send a

Re: [PATCH v3] usb: chipidea: removing of_find_property

On Tue, Nov 17, 2015 at 05:22:26PM +0530, Saurabh Sengar wrote: > call to of_find_property() before of_property_read_u32() is unnecessary. > of_property_read_u32() anyway calls to of_find_property() only. > > Signed-off-by: Saurabh Sengar > --- > v2 : removed pval

[PATCH v4] usb: chipidea: removing of_find_property

call to of_find_property() before of_property_read_u32() is unnecessary. of_property_read_u32() anyway calls to of_find_property() only. Signed-off-by: Saurabh Sengar --- v4 : removed return type check for optional property 'itc-setting' drivers/usb/chipidea/core.c |

Re: [PATCH v3] usb: chipidea: removing of_find_property

On Wed, Nov 18, 2015 at 09:30:39AM +0530, Saurabh Sengar wrote: > Hi Peter, > > Yes itc_setting is still optional, in case dts does not pass this > property, return type will be -EINVAL and there would be no problem. > The function will break only if there is 'No data'(-ENODATA) or >

Re: Infrastructure for zerocopy I/O

Alan Stern wrote: > if we can directly map the user-provided buffer for DMA. Given a memory buffer either kernel or userspace has to apply the hardware constraints to find out what part if any is usable for DMA. I think it's fine to push this task to userspace - as long as userspace has a way to

Re: [PATCH] USB: USB_OTG does not depend on PM

On Tue, Nov 17, 2015 at 11:00:18PM +0100, Arnd Bergmann wrote: > On Tuesday 17 November 2015 15:38:33 Felipe Balbi wrote: > > > > Arnd Bergmann writes: > > > USB_OTG initially depended on USB_SUSPEND, which was later turned into > > > PM_RUNTIME and finally into PM. I don't know

Re: XHCI, "brain-dead scanner", and microframe rounding

On 16.11.2015 17:25, Alan Stern wrote: On Sun, 15 Nov 2015, Stéphane Lavergne wrote: On Sat, Sep 12, 2015 at 4:08 AM, Hans-Peter Jansen wrote: With some changes in the 4.0 time frame, AND an update of the epson iscan stuff, I'm happily scanning with my Epson 4490 Photo

Re: Kernel v4.3 - RCU hang, USB implicated

On Mon, 2015-11-16 at 12:30 -0500, Ilia Mirkin wrote: > Task dump for CPU 2: > kworker/2:2 R running task13152 23226 2 0x > Workqueue: usb_hub_wq hub_event > 88017fd3ba08 88017fd3b9c8 8111dfc8 0002 > 88017fd3ba08 88017fd3b9e0

[PATCH v12 0/3] Mediatek xHCI support

>From 577f68d9c0ca1531d5f9cae0dcbea2ba116c8551 Mon Sep 17 00:00:00 2001 From: Chunfeng Yun Date: Tue, 17 Nov 2015 17:09:05 +0800 Subject: [PATCH v12 0/3] Mediatek xHCI support The patch supports MediaTek's xHCI controller. There are some differences from xHCI spec: 1.

Re: [PATCH v3 04/12] usb: xhci: dbc: add support for Intel xHCI dbc quirk

On Mon, 16 Nov 2015 10:18:42 +0800, Lu Baolu wrote: > This quirk works as well if debug host doesn't have DBC. I didn't try a > DBC-capable debug host yet. Hi, I went through it again, with your v3 patch series on top of vanilla v4.3.0. Two targets, one host, all with Intel chipset (XHCI device

[PATCH v12 2/3] xhci: mediatek: support MTK xHCI host controller

There some vendor quirks for MTK xhci host controller: 1. It defines some extra SW scheduling parameters for HW to minimize the scheduling effort for synchronous and interrupt endpoints. The parameters are put into reseved DWs of slot context and endpoint context. 2. Its IMODI unit for

[PATCH v12 1/3] dt-bindings: Add a binding for Mediatek xHCI host controller

add a DT binding documentation of xHCI host controller for the MT8173 SoC from Mediatek. Signed-off-by: Chunfeng Yun --- .../devicetree/bindings/usb/mt8173-xhci.txt| 51 ++ 1 file changed, 51 insertions(+) create mode 100644

[PATCH v12 3/3] arm64: dts: mediatek: add xHCI & usb phy for mt8173

add xHCI and phy drivers for MT8173-EVB Signed-off-by: Chunfeng Yun --- arch/arm64/boot/dts/mediatek/mt8173-evb.dts | 16 +++ arch/arm64/boot/dts/mediatek/mt8173.dtsi| 42 + 2 files changed, 58 insertions(+) diff --git

Re: [PATCH v4] usb: chipidea: removing of_find_property

On Wed, Nov 18, 2015 at 11:48:36AM +0530, Saurabh Sengar wrote: > On 18 November 2015 at 11:35, Peter Chen wrote: > > On Wed, Nov 18, 2015 at 09:40:12AM +0530, Saurabh Sengar wrote: > >> call to of_find_property() before of_property_read_u32() is unnecessary. > >>

[PATCH] usb: dwc2: add support of hi6220

Support hisilicon,hi6220-usb for HiKey board Signed-off-by: Zhangfei Gao --- Documentation/devicetree/bindings/usb/dwc2.txt | 1 + drivers/usb/dwc2/platform.c| 32 ++ 2 files changed, 33 insertions(+) diff --git

[PATCH] usb: dwc2: add support of hi6220

Support hisilicon,hi6220-usb for HiKey board Signed-off-by: Zhangfei Gao --- Documentation/devicetree/bindings/usb/dwc2.txt | 1 + drivers/usb/dwc2/platform.c| 32 ++ 2 files changed, 33 insertions(+) diff --git

Re: [PATCH v4] usb: chipidea: removing of_find_property

On 18 November 2015 at 12:54, Peter Chen wrote: > I am clear now, I will queue it. Thank you -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at

[GIT PULL] USB Chipidea fixes for v4.4-rc2

The following changes since commit aa05cfa95f686be5d1485094402ebc7b03729e0e: Merge tag 'fixes-for-v4.4-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-linus (2015-11-17 14:48:24 -0800) are available in the git repository at:

Re: Infrastructure for zerocopy I/O

On Tue, 2015-11-17 at 14:13 -0500, Alan Stern wrote: > On Tue, 17 Nov 2015, Steinar H. Gunderson wrote: > > > Alan, could we perhaps let the zerocopy flag make the request fail (instead > > of going through a bounce buffer) if direct DMA is not possible? That way, > > it would be quite obvious

[PATCH] phy: add phy-hi6220-usb

Support hi6220 use phy for HiKey board Signed-off-by: Zhangfei Gao --- .../devicetree/bindings/phy/phy-hi6220-usb.txt | 16 ++ drivers/phy/Kconfig| 9 ++ drivers/phy/Makefile | 1 +

Re: Infrastructure for zerocopy I/O

On Tue, 17 Nov 2015, Steinar H. Gunderson wrote: > On Tue, Nov 17, 2015 at 07:17:31PM +0100, Markus Rechberger wrote: > > 1. the memset on isochronous transfers to empty the buffers in order > > to avoid leaking raw memory to userspace (this costs a lot on intel > > Atoms and is also noticeable

Re: Infrastructure for zerocopy I/O

On Tue, 17 Nov 2015, Steinar H. Gunderson wrote: > On Tue, Nov 17, 2015 at 02:07:58PM -0500, Alan Stern wrote: > > Is there an API for allocating user memory below 4 GB? Would a new > > MMAP flag be acceptable? > > MAP_32BIT (to mmap) can seemingly do this, but from the man page, it sounds >

Re: Infrastructure for zerocopy I/O

On Tue, 17 Nov 2015, Steinar H. Gunderson wrote: > > xHCI always uses 64-bit addresses. But many EHCI controllers don't, > > and only a few of the EHCI platform drivers support 64-bit DMA. > > OK, sure. But are systems with USB2 only and more than 4GB of RAM common? > (And will they not

Re: Infrastructure for zerocopy I/O

On Mon, 16 Nov 2015, Christoph Hellwig wrote: > On Mon, Nov 16, 2015 at 08:03:12PM +0100, Steinar H. Gunderson wrote: > > The original use case: DVB capture on embedded devices. > > > > My use case: USB3 uncompressed HD video capture (from multiple cards). > > > > Both of these hit (beyond the

Re: Infrastructure for zerocopy I/O

On Tue, Nov 17, 2015 at 03:01:39PM -0500, Alan Stern wrote: >> On Tue, Nov 17, 2015 at 02:07:58PM -0500, Alan Stern wrote: >>> Is there an API for allocating user memory below 4 GB? Would a new >>> MMAP flag be acceptable? >> MAP_32BIT (to mmap) can seemingly do this, but from the man page, it

Re: Infrastructure for zerocopy I/O

On Tue, Nov 17, 2015 at 03:16:55PM -0500, Alan Stern wrote: >>> But what other way of allocating memory is there? >> For my part, GPU memory versus malloc(). (You can ask OpenGL to permanently >> map up a chunk of GPU memory for you into userspace, but you have no >> guarantees as of if it's

Re: [PATCH v3 6/8] usb: dwc2: host: Assume all devices are on one single_tt hub

Hi, On Mon, Nov 16, 2015 at 4:51 PM, Douglas Anderson wrote: > Until we have logic to determine which devices share the same TT let's > add logic to assume that all devices on a given dwc2 controller are on > one single_tt hub. This is better than the previous code that

Re: [PATCH] USB: USB_OTG does not depend on PM

On Tuesday 17 November 2015 15:38:33 Felipe Balbi wrote: > > Arnd Bergmann writes: > > USB_OTG initially depended on USB_SUSPEND, which was later turned into > > PM_RUNTIME and finally into PM. I don't know at what point the dependency > > became unnecessary but it appears to work

Re: [PATCH] USB: USB_OTG does not depend on PM

Hi, Arnd Bergmann writes: > On Tuesday 17 November 2015 15:38:33 Felipe Balbi wrote: >> >> Arnd Bergmann writes: >> > USB_OTG initially depended on USB_SUSPEND, which was later turned into >> > PM_RUNTIME and finally into PM. I don't know at what point the

Re: [PATCH 0/4 V2 RESEND] usb: dwc2: fix usb host support on Raspberry Pi

Stefan Wahren writes: > This patch series fixes multiple issues on Raspberry Pi which > were reproducable since commit 09a75e857790 > ("usb: dwc2: refactor common low-level hw code to platform.c") > > Changes in V2: > - add fix for kernel oops > - extend "usb: dwc2:

Re: [PATCH] USB: USB_OTG does not depend on PM

Hi, Arnd Bergmann writes: > USB_OTG initially depended on USB_SUSPEND, which was later turned into > PM_RUNTIME and finally into PM. I don't know at what point the dependency > became unnecessary but it appears to work fine without CONFIG_PM now. > > However, we get lots of

Re: [PATCH v4] usb: chipidea: removing of_find_property

On Wed, Nov 18, 2015 at 09:40:12AM +0530, Saurabh Sengar wrote: > call to of_find_property() before of_property_read_u32() is unnecessary. > of_property_read_u32() anyway calls to of_find_property() only. > > Signed-off-by: Saurabh Sengar > --- > v4 : removed return type

Re: [PATCH v4] usb: chipidea: removing of_find_property

On 18 November 2015 at 11:35, Peter Chen wrote: > On Wed, Nov 18, 2015 at 09:40:12AM +0530, Saurabh Sengar wrote: >> call to of_find_property() before of_property_read_u32() is unnecessary. >> of_property_read_u32() anyway calls to of_find_property() only. >> >>