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 t
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.
>
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
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 = "co
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
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_drive
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/
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://patchwor
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://patchwor
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
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 thi
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, p
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 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
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
---
Do
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 ge
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 t
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
> >> @@ -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->con
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, ther
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
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/of
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
ap
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 ret
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
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_O
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_re
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 alw
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
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 fo
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 n
On 04/17/18 02:01, Hans de Goede wrote:
> 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,
54 matches
Mail list logo
