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,
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 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
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
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
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
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
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
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 happen in a few ways, such as if the userspace uvc gadget
ap
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
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
> >> @@ -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 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.
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 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
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
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
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
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 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
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 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 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
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 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
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/
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
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,
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
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,
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.
>
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
54 matches
Mail list logo