Hi Karl,
On 03/06/2016 09:55 PM, Karl Palsson wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Heiner Kallweit wrote:
Add generic support for RGB LED's.
Basic idea is to use enum led_brightness also for the hue and
saturation color components.This allows to implement the color
extension
Hi,
Am 07.03.2016 um 08:26 schrieb Felipe Balbi :
>
> Hi,
>
> John Youn writes:
>> [ text/plain ]
>> On 3/4/2016 6:14 PM, Doug Anderson wrote:
>>> Hi,
>>>
>>> On Fri, Mar 4, 2016 at 5:56 PM, John Youn wrote:
On 3/4/2016 5:04 PM, Doug Anderson wrote:
> Felipe,
>
> Michael po
This is needed to handle the GPIO connected USB ID pin found on
Intel Baytrail devices.
Signed-off-by: Lu Baolu
Reviewed-by: Felipe Balbi
Acked-by: Chanwoo Choi
---
drivers/extcon/extcon-usb-gpio.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/extcon/extcon-usb-gpio.c b/dr
In some Intel platforms, a single usb port is shared between USB host
and device controller. The shared port is under control of GPIO pins.
This patch adds the support for USB GPIO controlled port mux.
Signed-off-by: David Cohen
Signed-off-by: Lu Baolu
Reviewed-by: Heikki Krogerus
Reviewed-by:
Some Intel platforms have an USB port mux controlled by GPIOs.
There's a single ACPI platform device that provides both USB ID
extcon device and a USB port mux device. This MFD driver will
split the 2 devices for their respective drivers.
Signed-off-by: Lu Baolu
Suggested-by: David Cohen
Reviewe
Several Intel PCHs and SOCs have an internal mux that is used to
share one USB port between device controller and host controller.
The mux is handled through the Dual Role Configuration Register.
Signed-off-by: Heikki Krogerus
Signed-off-by: Lu Baolu
Signed-off-by: Wu Hao
Reviewed-by: Felipe Ba
GPIO resource could be retrieved through APCI as well.
Signed-off-by: Lu Baolu
Reviewed-by: Felipe Balbi
Acked-by: Chanwoo Choi
---
drivers/extcon/extcon-usb-gpio.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/extcon/extcon-usb-gpio.c b/drivers/extcon/extcon-us
Several Intel PCHs and SOCs have an internal mux that is used to
share one USB port between device controller and host controller.
A usb port mux could be abstracted as the following elements:
1) mux state: HOST or PERIPHERAL;
2) an extcon cable which triggers the change of mux state between
HO
In some Intel platforms, a single usb port is shared between USB host
and device controllers. The shared port is under control of a switch
which is defined in the Intel vendor defined extended capability for
xHCI.
This patch adds the support to detect and create the platform device
for the port mu
Intel SOC chips are featured with USB dual role. The host role is
provided by Intel xHCI IP, and the gadget role is provided by IP
from designware. Tablet platform designs always share a single
port for both host and gadget controllers. There is a mux to
switch the port to the right controller acco
On Fri, Mar 4, 2016 at 11:43 PM, Linus Torvalds
wrote:
> On Fri, Mar 4, 2016 at 2:26 PM, Andrey Konovalov wrote:
>>
>> and when I run the vm and connect the device I get:
>>
>> [ 23.672662] cdc_ncm 1-1:1.6: bind() failure
>> [ 23.673447] usbnet_probe(): freeing netdev: 88006ab48000
>> [
Hi Balbi,
On 07/03/16 07:36, Felipe Balbi wrote:
>
> Hi,
>
> Felipe Ferreri Tonello writes:
>> [ text/plain ]
>> Hi Balbi,
>>
>> On March 4, 2016 7:13:05 AM GMT+00:00, Felipe Balbi wrote:
>>> "Felipe F. Tonello" writes:
[ text/plain ]
Signed-off-by: Felipe F. Tonello
>>>
>>> no co
Hi Balbi,
On 07/03/16 07:32, Felipe Balbi wrote:
>
> Hi,
>
> (please break your lines at 80-characters, have a look at
> Documentation/email-clients.txt if needed)
>
> Felipe Ferreri Tonello writes:
>> [ text/plain ]
>> Hi Balbi,
>>
>> On March 4, 2016 7:20:10 AM GMT+00:00, Felipe Balbi wrot
Hi Balbi,
On 07/03/16 07:35, Felipe Balbi wrote:
>
> Hi,
>
> Felipe Ferreri Tonello writes:
>> [ text/plain ]
>> Hi Michal,
>>
>> On March 5, 2016 4:28:45 PM GMT+00:00, Michal Nazarewicz
>> wrote:
> On Wed, Mar 02 2016, Felipe F. Tonello wrote:
>> @@ -16,7 +16,7 @@
>> * Copyr
Hi Balbi,
On 07/03/16 07:34, Felipe Balbi wrote:
>
> Hi,
>
> Felipe Ferreri Tonello writes:
>> [ text/plain ]
>> Hi Balbi,
>>
>> On March 4, 2016 7:16:42 AM GMT+00:00, Felipe Balbi wrote:
>>>
>>> Hi,
>>>
>>> "Felipe F. Tonello" writes:
[ text/plain ]
This gadget uses a bmAttributes
From: John Ogness
> Sent: 04 March 2016 10:51
> On 2016-03-04, John Ogness wrote:
> > Using v4.5-rc6, I modified musb_h_tx_flush_fifo() to allow infinite
> > looping and kept a log of the number of loops that were executed. For
> > my test I am regularly seeing 3000-3200 loops (with a max so far o
In case bind() works, but a later error forces bailing
in probe() in error cases work and a timer may be scheduled.
They must be killed. This fixes an error case related to
the double free reported in
http://www.spinics.net/lists/netdev/msg367669.html
and needs to go on top of Linus' fix to cdc-ncm
Hi,
Felipe Ferreri Tonello writes:
"Felipe F. Tonello" writes:
> [ text/plain ]
> This gadget uses a bmAttributes and MaxPower that requires the USB
bus to be
> powered from the host, which is not correct because this
configuration is device
> specific, not a USB-
Hi Balbi, how are you?
On 07/03/16 10:59, Felipe Balbi wrote:
>
> Hi,
>
> Felipe Ferreri Tonello writes:
> "Felipe F. Tonello" writes:
>> [ text/plain ]
>> This gadget uses a bmAttributes and MaxPower that requires the USB
> bus to be
>> powered from the host, which is not
The musb_hdrc_platform_data::config was defined as a non-const pointer.
However some drivers (e.g. the ux500) set up this pointer to point to a
static structure, which is potentially dangerous. Since the musb core
uses the pointer in a read-only manner the const qualifier was added to
protect the c
This adds the function musb_get_mode() to get the DT property "dr_mode"
Signed-off-by: Petr Kulhavy
---
v4:
- created musb_get_dr_mode()
v5:
- musb_get_dr_mode() renamed to musb_get_mode()
- added musb_get_power()
v6:
- musb_get_power() : added missing boundary check for the maximum value
Only few MUSB PHY reference clock frequencies were defined.
This patch defines macros for the missing frequencies:
19.2MHz, 38.4MHz, 13MHz, 26MHz, 20MHz, 40MHz
Signed-off-by: Petr Kulhavy
Acked-by: Sergei Shtylyov
Signed-off-by: Bin Liu
---
v5:
v6:
v7:
v8:
include/linux/platform_data/usb
This adds DT support for TI DA8xx/OMAP-L1x/AM17xx/AM18xx MUSB driver
Signed-off-by: Petr Kulhavy
Tested-by: Petr Kulhavy
Acked-by: Sergei Shtylyov
---
v1:
v2:
- using standard MUSB properties "dr_mode", "mentor,power", "mentor,num-eps",
"mentor,multipoint", "mentor,ram-bits"
- using "ti,"
DT binding for the TI DA8xx/OMAP-L1x/AM17xx/AM18xx MUSB driver.
Signed-off-by: Petr Kulhavy
---
v1:
v2:
- using standard properties "dr_mode", "mentor,power", "mentor,num-eps",
"mentor,multipoint", "mentor,ram-bits"
- using "ti," prefix instead of "da8xx," for specific property names
- no w
On Fri, Mar 04, 2016 at 10:31:45PM -0600, Rob Herring wrote:
> On Fri, Mar 04, 2016 at 05:19:31PM +0100, Thierry Reding wrote:
> > From: Thierry Reding
> >
> > The NVIDIA Tegra XUSB pad controller provides a set of pads, each with a
> > set of lanes that are used for PCIe, SATA and USB.
> >
> >
Hello.
On 3/7/2016 2:20 PM, Petr Kulhavy wrote:
This adds DT support for TI DA8xx/OMAP-L1x/AM17xx/AM18xx MUSB driver
Signed-off-by: Petr Kulhavy
Tested-by: Petr Kulhavy
Acked-by: Sergei Shtylyov
[...]
diff --git a/drivers/usb/musb/da8xx.c b/drivers/usb/musb/da8xx.c
index b03d3b8..bbd8cac
On Sun, Mar 6, 2016 at 6:23 PM, Alan Stern wrote:
> On Sat, 5 Mar 2016, Sedat Dilek wrote:
>
>> On Fri, Mar 4, 2016 at 5:04 PM, Alan Stern wrote:
>> > On Wed, 2 Mar 2016, Sedat Dilek wrote:
>> >
>> >> On 3/1/16, Alan Stern wrote:
>> >> > On Tue, 1 Mar 2016, Sedat Dilek wrote:
>> >> >
>> >> >> On
Hello
On 07.03.2016 14:29, Sergei Shtylyov wrote:
Hello.
On 3/7/2016 2:20 PM, Petr Kulhavy wrote:
@@ -544,17 +643,25 @@ static int da8xx_probe(struct platform_device
*pdev)
pinfo.data = pdata;
pinfo.size_data = sizeof(*pdata);
+ret = regulator_enable(glue->vbus_supply);
On Mon, Mar 7, 2016 at 4:59 PM, Sedat Dilek wrote:
> On Sun, Mar 6, 2016 at 6:23 PM, Alan Stern wrote:
>> On Sat, 5 Mar 2016, Sedat Dilek wrote:
>>
>>> On Fri, Mar 4, 2016 at 5:04 PM, Alan Stern
>>> wrote:
>>> > On Wed, 2 Mar 2016, Sedat Dilek wrote:
>>> >
>>> >> On 3/1/16, Alan Stern wrote:
>
From: Oliver Neukum
Date: Mon, 7 Mar 2016 11:31:10 +0100
> In case bind() works, but a later error forces bailing
> in probe() in error cases work and a timer may be scheduled.
> They must be killed. This fixes an error case related to
> the double free reported in
> http://www.spinics.net/lists
On Mon, 7 Mar 2016, Sedat Dilek wrote:
> Hmm, we are there where I was looking at...
>
> Please, read the reply of Jiri [1], we did some tweaking.
> With CONFIG_FTRACE=n and CONFIG_PROVE_LOCKING=n !
Yes, Jiri was looking more or less at the right place but his
conclusions were wrong.
> *** Part
On Mon, 7 Mar 2016 11:41:37 -0500 (EST)
Alan Stern wrote:
> It's hard to call this a compiler bug, but perhaps it is -- I don't
> know how programmers are supposed to tell CLANG that a subroutine
> modifies the Interrupt Flag in a way that the compiler shouldn't mess
> up.
Really! This is what'
On Mon, 7 Mar 2016, Alan Stern wrote:
> > 319: 9c pushfq
> > 31a: 41 5c pop%r12
> > 31c: 48 89 dfmov%rbx,%rdi
> > 31f: e8 00 00 00 00 callq 324
> > 324: 41 54
On Mon, 7 Mar 2016 11:41:37 -0500 (EST)
Alan Stern wrote:
> It's hard to call this a compiler bug, but perhaps it is -- I don't
> know how programmers are supposed to tell CLANG that a subroutine
> modifies the Interrupt Flag in a way that the compiler shouldn't mess
> up.
I would state that t
On Mon, Mar 7, 2016 at 6:05 PM, Jiri Kosina wrote:
> On Mon, 7 Mar 2016, Alan Stern wrote:
>
>> > 319: 9c pushfq
>> > 31a: 41 5c pop%r12
>> > 31c: 48 89 dfmov%rbx,%rdi
>> > 31f: e8 00 00 00 0
On Mon, Mar 7, 2016 at 5:41 PM, Alan Stern wrote:
> On Mon, 7 Mar 2016, Sedat Dilek wrote:
>
>> Hmm, we are there where I was looking at...
>>
>> Please, read the reply of Jiri [1], we did some tweaking.
>> With CONFIG_FTRACE=n and CONFIG_PROVE_LOCKING=n !
>
> Yes, Jiri was looking more or less at
On Mon, 7 Mar 2016, Sedat Dilek wrote:
> Did someone look at the next/follow-ups in this thread?
> For example: D6629 "x86: Emit LAHF/SAHF instead of PUSHF/POPF" [2]?
Using LAHF/SAHF would "solve" it, as IF is at bit #9. The question is
whether they need to play with flags here at all.
On Mon,
On Mon, 7 Mar 2016 18:24:12 +0100 (CET)
Jiri Kosina wrote:
> > So, if Clang is producing wrong X86 code here, is it possible to turn
> > interrupts on/off manually? But, hmm that affects other places as well
> > in the Linux sources, so.
>
> This issue needs to be handled in the compiler.
>
From: Sedat Dilek
...
> Did someone look at the next/follow-ups in this thread?
> For example: D6629 "x86: Emit LAHF/SAHF instead of PUSHF/POPF" [2]?
LAHF and SAHF come with the following note:
This instruction executes as described above in compatibility mode and legacy
mode.
It is valid in 64-
On Mon, 2016-03-07 at 11:41 -0500, David Miller wrote:
> From: Oliver Neukum
> Date: Mon, 7 Mar 2016 11:31:10 +0100
>
> > In case bind() works, but a later error forces bailing
> > in probe() in error cases work and a timer may be scheduled.
> > They must be killed. This fixes an error case rela
On 03/07/2016 07:08 PM, Petr Kulhavy wrote:
Hello
On 07.03.2016 14:29, Sergei Shtylyov wrote:
Hello.
On 3/7/2016 2:20 PM, Petr Kulhavy wrote:
@@ -544,17 +643,25 @@ static int da8xx_probe(struct platform_device *pdev)
pinfo.data = pdata;
pinfo.size_data = sizeof(*pdata);
+ret
On Mon, Mar 7, 2016 at 9:30 AM, Steven Rostedt wrote:
> On Mon, 7 Mar 2016 18:24:12 +0100 (CET)
> Jiri Kosina wrote:
>
>> > So, if Clang is producing wrong X86 code here, is it possible to turn
>> > interrupts on/off manually? But, hmm that affects other places as well
>> > in the Linux sources,
On Mon, 7 Mar 2016, David Laight wrote:
> From: Sedat Dilek
> ...
> > Did someone look at the next/follow-ups in this thread?
> > For example: D6629 "x86: Emit LAHF/SAHF instead of PUSHF/POPF" [2]?
>
> LAHF and SAHF come with the following note:
>
> This instruction executes as described above i
On Sat, Mar 5, 2016 at 11:53 AM, Bjørn Mork wrote:
>
>
> Definitely. The patch is so obviously correct that we can only wonder how it
> was possible to miss it it the first place :)
>
> Will take a look to see if we could do a better job cleaning up in other
> places.
What should I do for 4.5?
On Mon, Mar 7, 2016 at 10:07 AM, Alan Stern wrote:
>
> Of course, there are other ways to save a single flag value (such as
> setz). It's up to the compiler developers to decide what they think is
> best.
Using 'setcc' to save eflags somewhere is definitely the right thing to do.
Using pushf/po
Hi Doug,
> Douglas Anderson hat am 4. März 2016 um 19:23
> geschrieben:
>
>
> This reverts commit 192cb07f7928 ("usb: dwc2: Fix probe problem on
> bcm2835") now that we've found the root cause. See the change
> titled ("usb: dwc2: Add a 10 ms delay to dwc2_core_reset()").
adding a delay of 10 ms
Quick ping here: this is still busted on 4.5-rc6.
On Wed, Feb 17, 2016 at 9:40 AM, Andy Lutomirski wrote:
> On Wed, Feb 17, 2016 at 8:18 AM, Mathias Nyman
> wrote:
>> On 17.02.2016 07:19, Andy Lutomirski wrote:
>>>
>>> On Tue, Feb 16, 2016 at 6:33 PM, Greg Kroah-Hartman
>>> wrote:
On
On Mon, 7 Mar 2016 10:04:21 -0800
Andy Lutomirski wrote:
> > Exactly. The compiler may get away with this in userspace (maybe), but
> > for the kernel, it is definitely a show stopper. Especially if it knows
> > that an asm() may be called.
>
> It's broken for user code that fiddles with AC,
From: Linus Torvalds
Date: Mon, 7 Mar 2016 10:13:09 -0800
> On Sat, Mar 5, 2016 at 11:53 AM, Bjørn Mork wrote:
>>
>>
>> Definitely. The patch is so obviously correct that we can only wonder how
>> it was possible to miss it it the first place :)
>>
>> Will take a look to see if we could do a b
The uas driver can never queue more then MAX_CMNDS (- 1) tags and tags
are shared between luns, so there is no need to claim that we can_queue
some random large number.
Not claiming that we can_queue 65536 commands, fixes the uas driver
failing to initialize while allocating the tag map with a "Pa
From: Bjørn Mork
Date: Thu, 3 Mar 2016 22:20:53 +0100
> Some devices will silently fail setup unless they are reset first.
> This is necessary even if the data interface is already in
> altsetting 0, which it will be when the device is probed for the
> first time. Briefly toggling the altsettin
On Mon, Mar 7, 2016 at 10:11 PM, David Miller wrote:
> From: Linus Torvalds
> Date: Mon, 7 Mar 2016 10:13:09 -0800
>
>> On Sat, Mar 5, 2016 at 11:53 AM, Bjørn Mork wrote:
>>>
>>>
>>> Definitely. The patch is so obviously correct that we can only wonder how
>>> it was possible to miss it it the
From: Andrey Konovalov
Date: Mon, 7 Mar 2016 22:50:41 +0300
> On Mon, Mar 7, 2016 at 10:11 PM, David Miller wrote:
>> From: Linus Torvalds
>> Date: Mon, 7 Mar 2016 10:13:09 -0800
>>
>>> On Sat, Mar 5, 2016 at 11:53 AM, Bjørn Mork wrote:
Definitely. The patch is so obviously cor
We are seeing relatively high interrupt latencies due to usb_sg_wait()
calling usb_submit_urb() with interrupts disabled (as a result of its
spin_lock_irq() call).
As far as I can see, io->lock protects io->status and it's not really
necessary to hold the lock (or disable interrupts) during the
us
On Mon, Mar 07, 2016 at 02:20:03PM -0500, Nicholas Krause wrote:
> This removes the unneeded marco definitions for the marcos
> of XHCI_PORT_RW1S, XHCI_PORT_RW1C, XHCI_PORT_RWand
> XHCI_PORT_RZ due to no uses of these marcos in the file
> xhci-hub.c or any other related kernel source code f
On Mon, Mar 07, 2016 at 11:09:36AM -0800, Andy Lutomirski wrote:
> Quick ping here: this is still busted on 4.5-rc6.
>
> On Wed, Feb 17, 2016 at 9:40 AM, Andy Lutomirski wrote:
> > On Wed, Feb 17, 2016 at 8:18 AM, Mathias Nyman
> > wrote:
> >> On 17.02.2016 07:19, Andy Lutomirski wrote:
> >>>
>
Running kernel 4.4.4 is no good.. with the same setup as above but
only changing out vmlinuz and initrd.img, I run into a kernel panic.
"Kernel panic - not syncing: attempted to kill init!"
There was an error that I hadn't seen before about
"systemd-udevd: could not open builtin file
/lib/module
On Mon, Mar 7, 2016 at 12:13 PM, Greg Kroah-Hartman
wrote:
> On Mon, Mar 07, 2016 at 11:09:36AM -0800, Andy Lutomirski wrote:
>> Quick ping here: this is still busted on 4.5-rc6.
>>
>> On Wed, Feb 17, 2016 at 9:40 AM, Andy Lutomirski wrote:
>> > On Wed, Feb 17, 2016 at 8:18 AM, Mathias Nyman
>> >
usbnet_link_change will call schedule_work and should be
avoided if bind is failing. Otherwise we will end up with
scheduled work referring to a netdev which has gone away.
Instead of making the call conditional, we can just defer
it to usbnet_probe, using the driver_info flag made for
this purpos
From: Bjørn Mork
Date: Mon, 7 Mar 2016 21:15:36 +0100
> usbnet_link_change will call schedule_work and should be
> avoided if bind is failing. Otherwise we will end up with
> scheduled work referring to a netdev which has gone away.
>
> Instead of making the call conditional, we can just defer
>
Stefan,
On Mon, Mar 7, 2016 at 10:40 AM, Stefan Wahren wrote:
> Hi Doug,
>
>> Douglas Anderson hat am 4. März 2016 um 19:23
>> geschrieben:
>>
>>
>> This reverts commit 192cb07f7928 ("usb: dwc2: Fix probe problem on
>> bcm2835") now that we've found the root cause. See the change
>> titled ("usb
On Mon, 7 Mar 2016, Devon Ash wrote:
> Attached is dmesg.txt and usbmon.txt.
For what kernel version? And what's with all those netconsole error
messages popping up every 5 minutes?
> This is the only usbmon I could
> capture, from 0u, 5u and 6u don't give anything, I've tried to plug
> them
On Mon, 2016-03-07 at 22:50 +0300, Andrey Konovalov wrote:
> Could you also add:
> Reported-by: Andrey Konovalov
Well, the exact bug you reported is fixed in Bjorn's
patch the way Linus suggested. I'm fixing just a further
race that would require an error condition on top
of what you have seen.
S
On Mon, 7 Mar 2016, David Mosberger wrote:
> We are seeing relatively high interrupt latencies due to usb_sg_wait()
> calling usb_submit_urb() with interrupts disabled (as a result of its
> spin_lock_irq() call).
>
> As far as I can see, io->lock protects io->status and it's not really
> necessar
Hi all,
I have some performance issues with the host port on a Beaglebone
board. I tested with kernel 3.8.13, 3.14.55 and 4.1.18 and the issue
still persists. Running a fio test with 64k random reads from a USB
flash drive yields a maximum of 14402.01 KiB/s (115216.08 Kb/s). The
3.14 and 4.1 kerne
Sorry, I accidentally pressed Send
On Mon, Mar 7, 2016 at 7:35 PM, Victor Dodon wrote:
> Hi all,
>
> I have some performance issues with the host port on a Beaglebone
> board. I tested with kernel 3.8.13, 3.14.55 and 4.1.18 and the issue
> still persists. Running a fio test with 64k random reads
Victor
On Tue, Mar 8, 2016 at 9:05 AM, Victor Dodon wrote:
>
> Hi all,
>
> I have some performance issues with the host port on a Beaglebone
> board. I tested with kernel 3.8.13, 3.14.55 and 4.1.18 and the issue
> still persists. Running a fio test with 64k random reads from a USB
> flash drive
On Mon, 07 Mar 2016, Lu Baolu wrote:
> Some Intel platforms have an USB port mux controlled by GPIOs.
> There's a single ACPI platform device that provides both USB ID
> extcon device and a USB port mux device. This MFD driver will
> split the 2 devices for their respective drivers.
>
> Signed-of
This patch adds a code to surely disable tx irq of the pipe before
starting TX DMAC transfer. Otherwise, a lot of unnecessary tx irqs
may heppen in rare cases when DMAC is used.
Signed-off-by: Yoshihiro Shimoda
---
drivers/usb/renesas_usbhs/fifo.c | 1 +
1 file changed, 1 insertion(+)
diff --gi
When unexpected situation happened (e.g. tx/rx irq happened while
DMAC is used), the usbhsf_pkt_handler() was possible to cause NULL
pointer dereference like the followings:
Unable to handle kernel NULL pointer dereference at virtual address
pgd = c0004000
[] *pgd=
Interna
This patch set is based on the latest Felipe's usb.git / testing/next branch.
(commit id = ac5706631325ae3695bfa1527101ab2b2f64859f)
Yoshihiro Shimoda (2):
usb: renesas_usbhs: avoid NULL pointer derefernce in
usbhsf_pkt_handler()
usb: renesas_usbhs: disable tx irq before starting TX DMAC t
Hi,
Victor Dodon writes:
> [ text/plain ]
> Sorry, I accidentally pressed Send
>
> On Mon, Mar 7, 2016 at 7:35 PM, Victor Dodon wrote:
>> Hi all,
>>
>> I have some performance issues with the host port on a Beaglebone
>> board. I tested with kernel 3.8.13, 3.14.55 and 4.1.18 and the issue
>> st
Hi,
Felipe Ferreri Tonello writes:
> Since f_midi_transmit is called by both ALSA and USB frameworks, it
can
> potentially cause a race condition between both calls. This is bad
because the
> way f_midi_transmit is implemented can't handle concurrent calls.
This is due
Hi,
Felipe Ferreri Tonello writes:
>>> @@ -63,6 +63,14 @@ static unsigned int out_ports = 1;
>>> module_param(out_ports, uint, S_IRUGO);
>>> MODULE_PARM_DESC(out_ports, "Number of MIDI output ports");
>>>
>>> +static unsigned int bmAttributes = USB_CONFIG_ATT_ONE;
>>>
Hi,
Felipe Ferreri Tonello writes:
>>> On March 5, 2016 4:28:45 PM GMT+00:00, Michal Nazarewicz
>>> wrote:
>> On Wed, Mar 02 2016, Felipe F. Tonello wrote:
>>> @@ -16,7 +16,7 @@
>>> * Copyright (C) 2006 Thumtronics Pty Ltd.
>>> * Ben Williamson
>>> *
>>> - *
On 03/08/2016 12:40 PM, Lee Jones wrote:
> On Mon, 07 Mar 2016, Lu Baolu wrote:
>
>> Some Intel platforms have an USB port mux controlled by GPIOs.
>> There's a single ACPI platform device that provides both USB ID
>> extcon device and a USB port mux device. This MFD driver will
>> split the 2 de
Intel SOC chips are featured with USB dual role. The host role is
provided by Intel xHCI IP, and the gadget role is provided by IP
from designware. Tablet platform designs always share a single
port for both host and gadget controllers. There is a mux to
switch the port to the right controller acco
Several Intel PCHs and SOCs have an internal mux that is used to
share one USB port between device controller and host controller.
A usb port mux could be abstracted as the following elements:
1) mux state: HOST or PERIPHERAL;
2) an extcon cable which triggers the change of mux state between
HO
In some Intel platforms, a single usb port is shared between USB host
and device controllers. The shared port is under control of a switch
which is defined in the Intel vendor defined extended capability for
xHCI.
This patch adds the support to detect and create the platform device
for the port mu
Some Intel platforms have an USB port mux controlled by GPIOs.
There's a single ACPI platform device that provides both USB ID
extcon device and a USB port mux device. This MFD driver will
split the 2 devices for their respective drivers.
Signed-off-by: Lu Baolu
Suggested-by: David Cohen
Reviewe
In some Intel platforms, a single usb port is shared between USB host
and device controller. The shared port is under control of GPIO pins.
This patch adds the support for USB GPIO controlled port mux.
Signed-off-by: David Cohen
Signed-off-by: Lu Baolu
Reviewed-by: Heikki Krogerus
Reviewed-by:
This is needed to handle the GPIO connected USB ID pin found on
Intel Baytrail devices.
Signed-off-by: Lu Baolu
Reviewed-by: Felipe Balbi
Acked-by: Chanwoo Choi
---
drivers/extcon/extcon-usb-gpio.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/extcon/extcon-usb-gpio.c b/dr
Several Intel PCHs and SOCs have an internal mux that is used to
share one USB port between device controller and host controller.
The mux is handled through the Dual Role Configuration Register.
Signed-off-by: Heikki Krogerus
Signed-off-by: Lu Baolu
Signed-off-by: Wu Hao
Reviewed-by: Felipe Ba
GPIO resource could be retrieved through APCI as well.
Signed-off-by: Lu Baolu
Reviewed-by: Felipe Balbi
Acked-by: Chanwoo Choi
---
drivers/extcon/extcon-usb-gpio.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/extcon/extcon-usb-gpio.c b/drivers/extcon/extcon-us
84 matches
Mail list logo
