Felipe Ferreri Tonello wrote:
> On 03/03/16 11:38, Clemens Ladisch wrote:
>> But in what way was the old state machine not "proper"?
>
> Because it didn't reflect all the correct and possible MIDI states
The whole point of the one-byte real-time messages is that they do not
affect the parsing of t
Some super speed device, insert the u3 port, sometimes link is in the
Compliance Mode State(0x340), and then satisfy hub_port_warm_reset_required
conditions, the software will perform a warm reset, u3 PORTSC becomes
0x2a1203. In hub_port_reset function, it will clear
USB_PORT_FEAT_C_CONNECTION by u
Hi Heiner,
Please split the sysfs-class-led part to a separate patch.
On 03/02/2016 08:31 PM, Heiner Kallweit wrote:
Document the color extension in Documentation/leds/leds-class.txt
Signed-off-by: Heiner Kallweit
---
v2:
- introduced to patch series
v3:
- document extension in more detail
v4
On 03/01/2016 10:36 PM, Heiner Kallweit wrote:
Export a function to convert HSV color values to RGB.
It's intended to be called by drivers for RGB LEDs.
Signed-off-by: Heiner Kallweit
---
v2:
- move hsv -> rgb conversion to separate file
- remove flag LED_DEV_CAP_RGB
v3:
- call led_hsv_to_rgb o
Hi Heiner,
Thanks for the updated version. Some nitpicking below.
Please remove "Color" from the patch title.
On 03/01/2016 10:26 PM, Heiner Kallweit wrote:
Add generic support for RGB Color LED's.
^^^
Ditto.
Basic idea is to use enum led_brightness also for
On Thu, Mar 03, 2016 at 04:29:31PM -0500, Jaret Cantu wrote:
> +static void mxs_phy_tx_init(struct mxs_phy *mxs_phy)
> +{
> + void __iomem *base = mxs_phy->phy.io_priv;
> + u32 phytx;
> +
> + /* Update TX register if there is anything to write */
> + if (mxs_phy->tx_reg_mask) {
> +
On Thu, Mar 03, 2016 at 11:16:11PM +0800, yoma sophian wrote:
> hi all:
> When I porting my platform ehci driver on kernel v4.1,
> I get back trace like below without plug in any device and just insert
> usb-common.ko, usbcore.ko and ehci-hcd.ko.
> (and detail is show in the attachment)
>
> It see
On 2016-03-03, John Ogness wrote:
>>> Using next-20160302 I can very reliably hit this warning on an
>>> AM335x BeagleBone by playing a short audio file over USB-Audio:
>>>
>>> $ aplay -Dplughw:1,0 -r 44100 -c 2 -f S16_LE
>>> /usr/share/sounds/alsa/Front_Center.wav
>>>
>>> $ aplay -l
>>> L
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 of
> 3289). Since there used to be an msleep() in the l
-rejudge/20160304-163718
base: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
usb-testing
config: x86_64-lkp (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
drive
Hello.
On 3/4/2016 11:28 AM, l00229106 wrote:
Some super speed device, insert the u3 port, sometimes link is in the
Compliance Mode State(0x340), and then satisfy hub_port_warm_reset_required
conditions, the software will perform a warm reset, u3 PORTSC becomes
0x2a1203. In hub_port_reset funct
hi Alan and Peter:
>>
>> Backtrace:
>> [] (ehci_handle_start_intr_unlinks [ehci_hcd]) from
>> [] (ehci_bus_suspend+0x388/0x464 [ehci_hcd])
>
> Since there aren't any devices registered on the USB bus yet,
> ehci_handle_start_intr_unlink() should do nothing. It iterates over
> ehci->intr_unlink, bu
Hi Greg,
here's the gadget pull request for v4.6. This time I had to based it on
top of your greg/usb-next to avoid duplicated commits for the USB 3.1
work which some dwc3 changes depended on. Another benefit of the rebase
is that I don't have a merge commit of v4.5-rc6 anymore :-)
Let me know i
On ven., 2016-03-04 at 08:18 +0100, Hans de Goede wrote:
> Thanks for testing, there shouldn't be any side-effects, I'll turn this into
> a proper patch, add a:
>
> Reported-and-tested-by: Yves-Alexis Perez
>
> line to the comit msg and submit this upstream.
>
>
Thanks,
I guess it can also be
On Fri, 4 Mar 2016, yoma sophian wrote:
> hi Alan and Peter:
> >>
> >> Backtrace:
> >> [] (ehci_handle_start_intr_unlinks [ehci_hcd]) from
> >> [] (ehci_bus_suspend+0x388/0x464 [ehci_hcd])
> >
> > Since there aren't any devices registered on the USB bus yet,
> > ehci_handle_start_intr_unlink() sho
On Fri, 4 Mar 2016, l00229106 wrote:
> Some super speed device, insert the u3 port, sometimes link is in the
> Compliance Mode State(0x340), and then satisfy hub_port_warm_reset_required
> conditions, the software will perform a warm reset, u3 PORTSC becomes
> 0x2a1203. In hub_port_reset function,
On Wed, 2 Mar 2016, Sedat Dilek wrote:
> On 3/1/16, Alan Stern wrote:
> > On Tue, 1 Mar 2016, Sedat Dilek wrote:
> >
> >> On Tue, Oct 13, 2015 at 2:57 AM, Steven Rostedt
> >> wrote:
> >> > On Sat, 3 Oct 2015 12:05:42 +0200
> >> > Sedat Dilek wrote:
> >> >
> >> >> So, at the beginning... dunno W
From: Thierry Reding
Add support for the XUSB pad controller found on Tegra210 SoCs. The
hardware is roughly the same, but some of the registers have been moved
around and the number and type of supported pads has changed.
Signed-off-by: Thierry Reding
---
Changes in v9:
- expose more public AP
From: Thierry Reding
Parameterize more parts of the driver and add support for Tegra210.
Cc: Greg Kroah-Hartman
Cc: Mathias Nyman
Signed-off-by: Thierry Reding
---
drivers/usb/host/xhci-tegra.c | 59 +--
1 file changed, 51 insertions(+), 8 deletions(-)
From: Thierry Reding
Add device-tree binding documentation for the XUSB controller present
on Tegra124 and later SoCs. This controller supports USB 3.0 via an xHCI
compliant interface.
Based on work by Andrew Bresticker .
Cc: Rob Herring
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Ian Campbell
Cc:
From: Thierry Reding
Add a new driver for the XUSB pad controller found on NVIDIA Tegra SoCs.
This hardware block used to be exposed as a pin controller, but it turns
out that this isn't a good fit. The new driver and DT binding much more
accurately describe the hardware and are more flexible in
From: Thierry Reding
Extend the Tegra XUSB controller device tree binding with Tegra210
support.
Signed-off-by: Thierry Reding
---
.../devicetree/bindings/usb/nvidia,tegra124-xusb.txt | 12
1 file changed, 12 insertions(+)
diff --git a/Documentation/devicetree/bindings/us
From: Thierry Reding
Add support for the on-chip XUSB controller present on Tegra SoCs. This
controller, when loaded with external firmware, exposes an interface
compliant with xHCI. This driver loads the firmware, starts the
controller, and is able to service host-specific messages sent by the
c
From: Thierry Reding
Extend the binding to cover the set of feature found in Tegra210.
Signed-off-by: Thierry Reding
---
.../bindings/phy/nvidia,tegra124-xusb-padctl.txt | 327 +
1 file changed, 327 insertions(+)
diff --git
a/Documentation/devicetree/bindings/phy/nvidia
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.
Signed-off-by: Thierry Reding
---
Changes in v10:
- clarify that the hardware documentation means something different when
referring to a "port" (in
From: Thierry Reding
This is an old version of the binding that isn't flexible enough to
describe all aspects of the XUSB pad controller. Specifically with the
addition of XUSB support (for SuperSpeed USB) the existing binding is
no longer suitable.
Signed-off-by: Thierry Reding
---
.../device
On 02/03/16 16:24, Arnd Bergmann wrote:
The mediatek XHCI glue driver uses SET_SYSTEM_SLEEP_PM_OPS() to
conditionally set the correct suspend/resume options, and
also puts both the dev_pm_ops and the functions inside of
an #ifdef testing for CONFIG_PM_SLEEP, but those functions
then call other
>From testing and trying to make sense of the documentation, it appears
that a 10 ms delay is needed after resetting the core to make sure that
everything is stable and consistent. Let's add it.
In my testing (on rk3288) this allows us to revert commit
192cb07f7928 ("usb: dwc2: Fix probe problem
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()").
Signed-off-by: Douglas Anderson
---
drivers/usb/dwc2/core.c | 6 ++
1 file changed, 6 insertions(+)
I'm unable to use 8 of the 10 USB devices I have on a motherboard. Two
USB 3.0 ports work, and all of the devices, if plugged into a hub, can
be recognized and used if plugged through those 2 ports. However, the
other ports are completely unresponsive.
Thoughts/Ideas? The broken drivers are ehci-p
On Fri, Oct 9, 2015 at 5:30 AM, Mathias Nyman
wrote:
> The xhci platform driver needs to work on systems that
> either only support 64-bit DMA or only support 32-bit DMA.
> Attempt to set a coherent dma mask for 64-bit DMA, and
> attempt again with 32-bit DMA if that fails.
I know this patch is a
Hi Clemens,
On March 4, 2016 8:07:40 AM GMT+00:00, Clemens Ladisch
wrote:
>Felipe Ferreri Tonello wrote:
>> On 03/03/16 11:38, Clemens Ladisch wrote:
>>> But in what way was the old state machine not "proper"?
>>
>> Because it didn't reflect all the correct and possible MIDI states
>
>The whole
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 commit log == no commit
Got it.
>
>> ---
>> drivers/usb/gadget/function/f_midi.c | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> d
Hi Balbi,
On March 4, 2016 7:11:30 AM GMT+00:00, Felipe Balbi wrote:
>
>Hi,
>
>"Felipe F. Tonello" writes:
>> [ text/plain ]
>> Patches are pretty much self-described.
>>
>> Patch 1 is revised from comments.
>
>you really need to describe what you changed. This also should have v2
>on subject l
Felipe Ferreri Tonello wrote:
> On March 4, 2016 8:07:40 AM GMT+00:00, Clemens Ladisch
> wrote:
>> Felipe Ferreri Tonello wrote:
>>> On 03/03/16 11:38, Clemens Ladisch wrote:
But in what way was the old state machine not "proper"?
>>>
>>> Because it didn't reflect all the correct and possibl
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 and MaxPower that requires the USB
>bus to be
>> powered from the host, which is not correct because this
>configuration is device
>> s
Hi Balbi,
On March 4, 2016 7:20:10 AM GMT+00:00, Felipe Balbi wrote:
>
>Hi,
>
>"Felipe F. Tonello" writes:
>> [ text/plain ]
>> 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_mi
On Fri, 4 Mar 2016, Devon Ash wrote:
> I'm unable to use 8 of the 10 USB devices I have on a motherboard. Two
> USB 3.0 ports work, and all of the devices, if plugged into a hub, can
> be recognized and used if plugged through those 2 ports. However, the
> other ports are completely unresponsive.
On Wed, Mar 02 2016, Felipe F. Tonello wrote:
> Signed-off-by: Felipe F. Tonello
> ---
> drivers/usb/gadget/function/f_midi.c | 77
> +++-
> 1 file changed, 40 insertions(+), 37 deletions(-)
>
> diff --git a/drivers/usb/gadget/function/f_midi.c
> b/drivers/usb/ga
If they are completely unresponsive, why do you get the -110 errors? I
would expect you wouldn't get anything at all.
They become unresponsive after the -110 errors. Dmesg will show
nothing after those errors come up during boot.
Failing that, can you at least provide a usbmon trace showing what
Regarding Kernel 4.2.0-30-lowlatency,
system-udevd is now giving me the outputs on boot:
seq 1106 '/devices/pci:00/:00:1a.0/usb5 killed (same for usb6)
reason being ; a timeout
Then I start to get
usb 5-1: device not accepting address 5, error -110
usb usb5-port1; unable to enumerate US
Hi Michal,
On March 4, 2016 7:17:31 PM GMT+00:00, Michal Nazarewicz
wrote:
>On Wed, Mar 02 2016, Felipe F. Tonello wrote:
>> Signed-off-by: Felipe F. Tonello
>> ---
>> drivers/usb/gadget/function/f_midi.c | 77
>+++-
>> 1 file changed, 40 insertions(+), 37 dele
On Fri, Mar 04, 2016 at 02:53:59PM -0500, Devon Ash wrote:
> Regarding Kernel 4.2.0-30-lowlatency,
What is "lowlatency"? Try 4.4.4 please, 4.2 is now old and obsolete :(
And can you test this without any -rt patches, we have no idea how those
interact with the USB subsystem, sorry.
thanks,
gre
My deepest apologies.. I ran those commands on another computer (I'm
ssh tunnelling)...
here is the output of:
sudo mount -t usbfs none /proc/bus/usb
mount: mounting none on /proc/bus/usb failed: no such file or directory
cat /proc/bus/usb/devices: no such file or directory
sudo mount -t debug
On Tue, 1 Mar 2016, Alan Stern wrote:
On Mon, 29 Feb 2016, Rian Hunter wrote:
Hello,
I own a JBOD SATA<->USB 3.0 bridge. All information about this device
and my kernel version is below.
My trouble is that every so often this device will undergo a virtual
USB disconnect and then be reconnect
On 03/04/2016 12:24 PM, Greg KH wrote:
> On Fri, Mar 04, 2016 at 02:53:59PM -0500, Devon Ash wrote:
>> Regarding Kernel 4.2.0-30-lowlatency,
>
> What is "lowlatency"?
-lowlatency is Ubuntu's optional kernel config.
A stock Ubuntu kernel is CONFIG_PREEMPT_VOLUNTARY=y && CONFIG_HZ=250
The -lowlate
Export a function to convert HSV color values to RGB.
It's intended to be called by drivers for RGB LEDs.
Signed-off-by: Heiner Kallweit
---
v2:
- move hsv -> rgb conversion to separate file
- remove flag LED_DEV_CAP_RGB
v3:
- call led_hsv_to_rgb only if LED_DEV_CAP_HSV is set
This is needed in
Document the ABI change in Documentation/ABI/testing/sysfs-class-led.
Signed-off-by: Heiner Kallweit
---
v7:
- separated from patch 3
---
Documentation/ABI/testing/sysfs-class-led | 11 +++
1 file changed, 11 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-class-led
b/Docume
Extend brightness sysfs property handling to deal with monochrome
and color mode as well.
Signed-off-by: Heiner Kallweit
---
v2:
- split from patch 1
v3:
- moved one change (led_is_off) to patch 1
v4:
- changed printf format string to %#.6x
v5:
- no changes
v6:
- no changes
v7:
- no changes
---
Document the RGB extension in Documentation/leds/leds-class.txt
Signed-off-by: Heiner Kallweit
---
v2:
- introduced to patch series
v3:
- document extension in more detail
v4:
- Better explain why flag LED_SET_HUE_SAT is needed
v5:
- no changes
v6:
- no changes
v7:
- move Documentation/ABI change
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 w/o
changes to struct led_classdev.
Select LEDS_RGB to enable building drivers using the RGB extension.
Flag LED_SET_HUE_SAT a
Am 04.03.2016 um 10:05 schrieb Jacek Anaszewski:
> On 03/01/2016 10:36 PM, Heiner Kallweit wrote:
>> Export a function to convert HSV color values to RGB.
>> It's intended to be called by drivers for RGB LEDs.
>>
>> Signed-off-by: Heiner Kallweit
>> ---
>> v2:
>> - move hsv -> rgb conversion to se
[ Moving this to proper lists ]
On Thu, Mar 3, 2016 at 4:19 PM, Andrey Konovalov wrote:
>
> I found another double-free, this time in the usbnet driver.
Hmm. It doesn't look like a double free to me, at least from the logs
you attached.
> Whenever the `bind()` function fails (drivers/net/usb/us
Hi Thierry,
On Fri, Mar 4, 2016 at 8:19 AM, 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.
>
> Signed-off-by: Thierry Reding
Thanks, this binding looks much better, I
On Fri, Mar 4, 2016 at 8:19 AM, Thierry Reding wrote:
> From: Thierry Reding
>
> Extend the binding to cover the set of feature found in Tegra210.
>
> Signed-off-by: Thierry Reding
> +PCIe pad:
> +-
> +
> +Required properties:
> +- clocks: Must contain an entry for each entry in clock-n
On Fri, 4 Mar 2016, Devon Ash wrote:
> Failing that, can you at least provide a usbmon trace showing what
> happens when you plug a device into one of the bad ports?
>
> usbmon trace:
>
> I'm unable to get anything from doing "cat 0u && cat 5u && cat 6u"
> (which are all of the offending devices
> +Required properties:
> +
> +- compatible: Must be:
> + - Tegra124: "nvidia,tegra124-xusb-padctl"
> + - Tegra132: "nvidia,tegra132-xusb-padctl", "nvidia,tegra124-xusb-padctl"
> +- reg: Physical base address and length of the controller's registers.
> +- resets: Must contain
On Fri, 4 Mar 2016, Rian Hunter wrote:
> Thanks for the great tip. I used tcpdump on the bus of my device and
> waited for a couple days for the effect to happen again.
>
> I found that whenever I would get the "usb 2-3: reset SuperSpeed USB
> device number 2 using xhci_hcd" what was happening at
On Sat, Mar 5, 2016 at 12:26 AM, Linus Torvalds
wrote:
> [ Moving this to proper lists ]
>
> On Thu, Mar 3, 2016 at 4:19 PM, Andrey Konovalov wrote:
>>
>> I found another double-free, this time in the usbnet driver.
>
> Hmm. It doesn't look like a double free to me, at least from the logs
> you a
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
> [ 23.675822] usbnet_probe(): freeing netdev: 88006ab48000
>
>
On Sat, 2016-03-05 at 01:26 +0300, 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
> [ 23.675822] usbnet_probe(): freeing netdev: 88006ab48000
>
Hi Douglas,
Am 04.03.2016 um 19:23 schrieb Douglas Anderson :
> From testing and trying to make sense of the documentation, it appears
> that a 10 ms delay is needed after resetting the core to make sure that
> everything is stable and consistent. Let's add it.
>
> In my testing (on rk3288) thi
Am 04.03.2016 um 19:23 schrieb Douglas Anderson :
> 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()").
>
> Signed-off-by: Douglas Anderson
Tested-by:
On Sat, Mar 5, 2016 at 1:43 AM, 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
>> [
On Sat, Mar 5, 2016 at 1:42 AM, Oliver Neukum wrote:
> On Sat, 2016-03-05 at 01:26 +0300, 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
>> [ 23
On Sat, Mar 5, 2016 at 2:00 AM, Andrey Konovalov wrote:
> On Sat, Mar 5, 2016 at 1:42 AM, Oliver Neukum wrote:
>> On Sat, 2016-03-05 at 01:26 +0300, 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.67
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Douglas Anderson wrote:
>
> + /*
> + * Sleep for 10-15 ms after the reset to let it finish.
> + *
> + * It's been confirmed on at least one version of the controller
> + * that this is a requirement that this is a requirement
Hello.
On 03/04/2016 09:23 PM, Douglas Anderson wrote:
From testing and trying to make sense of the documentation, it appears
that a 10 ms delay is needed after resetting the core to make sure that
everything is stable and consistent. Let's add it.
In my testing (on rk3288) this allows us to
Hi Douglas,
Am 04.03.2016 um 23:54 schrieb Michael Niewoehner :
> Hi Douglas,
>
> Am 04.03.2016 um 19:23 schrieb Douglas Anderson :
>
>> From testing and trying to make sense of the documentation, it appears
>> that a 10 ms delay is needed after resetting the core to make sure that
>> everythin
Michael,
On Fri, Mar 4, 2016 at 4:09 PM, Michael Niewoehner wrote:
>>> From testing and trying to make sense of the documentation, it appears
>>> that a 10 ms delay is needed after resetting the core to make sure that
>>> everything is stable and consistent. Let's add it.
>>>
>>> In my testing (
Hi,
On Fri, Mar 4, 2016 at 3:46 PM, Karl Palsson wrote:
>> + /*
>> + * Sleep for 10-15 ms after the reset to let it finish.
>> + *
>> + * It's been confirmed on at least one version of the controller
>> + * that this is a requirement that this is a requirement in order for
Felipe,
Michael pointed out that there's an odd merge that happened.
Specifically it looks like commit bd84f4ae9986 ("usb: dwc2: Add extra
delay when forcing dr_mode") got lost somehow in the merge commit
3b30be3b6487 ("Merge tag 'v4.5-rc6' into next")
Specifically:
$ git blame 3b30be3b6487 -- d
Hi,
On Fri, Mar 4, 2016 at 4:33 PM, Doug Anderson wrote:
> Michael,
>
> On Fri, Mar 4, 2016 at 4:09 PM, Michael Niewoehner
> wrote:
From testing and trying to make sense of the documentation, it appears
that a 10 ms delay is needed after resetting the core to make sure that
every
On 3/4/2016 5:04 PM, Doug Anderson wrote:
> Felipe,
>
> Michael pointed out that there's an odd merge that happened.
> Specifically it looks like commit bd84f4ae9986 ("usb: dwc2: Add extra
> delay when forcing dr_mode") got lost somehow in the merge commit
> 3b30be3b6487 ("Merge tag 'v4.5-rc6' int
7;m about at the limit of my git-fu, so I'm a bit baffled.
>> Any idea what happened? Was anything else lost?
>>
>
>
> Felipe recently rebased his next branch without the merge commit
> referenced above. So maybe that's causing some issues.
>
> But ever
On 3/4/2016 10:23 AM, Douglas Anderson wrote:
> From testing and trying to make sense of the documentation, it appears
> that a 10 ms delay is needed after resetting the core to make sure that
> everything is stable and consistent. Let's add it.
>
> In my testing (on rk3288) this allows us to rev
>
>> Felipe recently rebased his next branch without the merge commit
>> referenced above. So maybe that's causing some issues.
>>
>> But everything seems ok to me. I see the commit and correct code on
>> 4.5-rc6, Felipe's next branch, and Greg's usb-
On Fri, Mar 04, 2016 at 03:19:11PM +0200, Felipe Balbi wrote:
>
> Hi Greg,
>
> here's the gadget pull request for v4.6. This time I had to based it on
> top of your greg/usb-next to avoid duplicated commits for the USB 3.1
> work which some dwc3 changes depended on. Another benefit of the rebase
On Fri, Mar 04, 2016 at 10:37:50AM +0800, Peter Chen wrote:
> On Fri, Mar 04, 2016 at 03:23:05AM +0100, Andrew Lunn wrote:
> > On Fri, Mar 04, 2016 at 10:02:42AM +0800, Peter Chen wrote:
> > > On Thu, Mar 03, 2016 at 02:54:55PM -0600, Rob Herring wrote:
> > > > On Thu, Mar 3, 2016 at 4:01 AM, Peter
On Fri, Mar 04, 2016 at 05:19:33PM +0100, Thierry Reding wrote:
> From: Thierry Reding
>
> Extend the binding to cover the set of feature found in Tegra210.
>
> Signed-off-by: Thierry Reding
> ---
> .../bindings/phy/nvidia,tegra124-xusb-padctl.txt | 327
> +
> 1 file cha
On Fri, Mar 04, 2016 at 05:19:32PM +0100, Thierry Reding wrote:
> From: Thierry Reding
>
> This is an old version of the binding that isn't flexible enough to
> describe all aspects of the XUSB pad controller. Specifically with the
> addition of XUSB support (for SuperSpeed USB) the existing bind
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.
>
> Signed-off-by: Thierry Reding
> ---
> Changes in v10:
> - clarify that the
On Wed, 2016-03-02 at 13:08 +0300, Dan Carpenter wrote:
> We need to move the kfree() down a line so we don't dereference a freed
> variable.
>
> Fixes: 1b418a8fcbc0 ('target: Convert demo-mode only drivers to
> target_alloc_session')
> Signed-off-by: Dan Carpenter
>
> diff --git a/drivers/usb/
Hi Felipe + usb-gadget folks,
On Wed, 2016-03-02 at 13:55 +0200, Felipe Balbi wrote:
> Dan Carpenter writes:
> > We need to move the kfree() down a line so we don't dereference a freed
> > variable.
> >
> > Fixes: 1b418a8fcbc0 ('target: Convert demo-mode only drivers to
> > target_alloc_session'
84 matches
Mail list logo
