Hi,
On Tue, Jan 6, 2015 at 7:45 AM, Maxime Ripard
wrote:
> Commit 1290a958d48e ("usb: phy: propagate __of_usb_find_phy()'s error on
> failure") actually broke the deferred probing mechanism, since it now returns
> EPROBE_DEFER only when the try_module_get call fails, but not when the phy
> lookup
Based on code for the US Surface Type Cover 3
from commit be3b16341d5cd8cf2a64fcc7a604a8efe6599ff0
("HID: add support for MS Surface Pro 3 Type Cover"):
Signed-off-by: Alan Wu
Tested-by: Karlis Dreizis
---
drivers/hid/hid-core.c | 4 +++-
drivers/hid/hid-ids.h | 1 +
driver
On 01/05/2015 01:16 PM, Paul Zimmerman wrote:
> Adding Dinh to CC.
>
> Robert, Dinh, I would like to have your tested-bys for this series, please.
>
This patch series is producing this error on the SOCFPGA platform. I'll
try to bisect to a specific patch.
root@socfpga_cyclone5:~# [ 47.929743]
On 01/06/2015 05:47 PM, Dinh Nguyen wrote:
> On 01/05/2015 01:16 PM, Paul Zimmerman wrote:
>> Adding Dinh to CC.
>>
>> Robert, Dinh, I would like to have your tested-bys for this series, please.
>>
>
> This patch series is producing this error on the SOCFPGA platform. I'll
> try to bisect to a spe
Just a short note that the issue remains with vanilla 3.18.1.
Greets,
Tobias
--
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 http://vger.kernel.org/majordomo-info.html
As has been discussed in the thread starting with
https://lkml.kernel.org/g/549748e9.d+sijzqu50f1r4lsal043...@arcor.de
Sierra Wireless MC73xx devices with USB VID/PID 0x1199:0x68c0 require the
option_send_setup() code to be used on the USB interface for the AT port
to make unsolicited response code
On Tue, Jan 06, 2015 at 08:42:26PM +0100, Giel van Schijndel wrote:
>
> Question: are you sure the compiler won't optimize the call to memset(0)
> way if it's immediately followed by kfree()?
Yes it won't be optimised away. However, you could use kzfree.
> Another actually does change a stack-a
Am 06.01.2015 um 18:38 schrieb Greg KH:
> On Tue, Jan 06, 2015 at 11:47:29AM +0100, JPT wrote:
>> Hi Greg
>>
>> Am 06.01.2015 um 02:54 schrieb Greg KH:
>>>
>>> Is that where the kernel panics show the problem happens? Without them,
>>> there's nothing we can do to help out except randomly guess, s
Coverity: CID 1260069
Signed-off-by: John W. Linville
---
drivers/usb/gadget/udc/bdc/bdc_ep.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/udc/bdc/bdc_ep.c
b/drivers/usb/gadget/udc/bdc/bdc_ep.c
index ff67ceac77c4..d4fe8d769bd6 100644
--- a/drivers/usb
On Mon, Jan 05, 2015 at 10:36:37 +1100, Herbert Xu wrote:
> On Sun, Jan 04, 2015 at 11:49:09PM +0100, Giel van Schijndel wrote:
>>
>>> sctx does not point to stack memory so this is bogus.
>>>
>>> Only stack memory cleared just before it goes out of scope needs
>>> memzero_explicit.
>>
>> Is that
Hello.
On 01/06/2015 06:45 PM, Maxime Ripard wrote:
The Marvell Armada 385 AP needs a dumb phy in order to enable the USB3 VBUS.
Add a call to retrieve a USB PHY to XHCI plat in order to support this.
Signed-off-by: Maxime Ripard
[...]
diff --git a/drivers/usb/host/xhci.h b/drivers/u
Thank you for the comments Alan
On 15-01-06 07:45 AM, Alan Stern wrote:
On Thu, 11 Dec 2014 arun.ramamur...@broadcom.com wrote:
From: Arun Ramamurthy
Added support for cases where one controller is connected
to multiple phys
Will this continue to work on systems that use only one PHY? Wha
From: Hayes Wang
Date: Tue, 6 Jan 2015 17:41:58 +0800
> Support ndo_features_check to avoid:
> - the transport offset is more than the hw limitation when using hw checksum.
> - the skb->len of a GSO packet is more than the limitation.
>
> Signed-off-by: Hayes Wang
Applied, thanks.
--
To unsu
On Tue, 6 Jan 2015, Michael Tessier wrote:
> > > > > That is interresting, however, I have an older kernel running an
> > > > > OHCI driver which is able to handle 4 codecs. Same usb hardware
> > > > > (codecs and hub), but older kernel on a different CPU, with much
> > > > > less power. This m
On Tue, Jan 06, 2015 at 11:47:29AM +0100, JPT wrote:
> Hi Greg
>
> Am 06.01.2015 um 02:54 schrieb Greg KH:
> >
> > Is that where the kernel panics show the problem happens? Without them,
> > there's nothing we can do to help out except randomly guess, sorry.
>
> well. at least xhci is contained
> > > > That is interresting, however, I have an older kernel running an
> > > > OHCI driver which is able to handle 4 codecs. Same usb hardware
> > > > (codecs and hub), but older kernel on a different CPU, with much
> > > > less power. This makes me believe that there's a solution to make it
> > If sound is ok when using only 1 codec and becomes choppy when adding
> > a second codec, then it means that this issue is still in the 3.x
> > kernel. This answer will tell me if it is worth working on using a newer
> > kernel or not.
> > I have to say that I'm not a linux expert, so I see
> > > > Hi,
> > > >
> > > > I am dealing with a USB EHCI driver bug. Here is the info:
> > > >
> > > > My configuration:
> > > > -
> > > >
> > > > Host: Freescale i.MX512 with ARM Cortex A8 (USB 2.0 host
> > > > controller) Linux kernel: 2.6.31, using EHCI USB driver
> > >
> > >
On Tue, 6 Jan 2015, Michael Tessier wrote:
> > > That is interresting, however, I have an older kernel running an OHCI
> > > driver which is able to handle 4 codecs. Same usb hardware (codecs and
> > > hub), but older kernel on a different CPU, with much less power. This
> > > makes me believe
Dear Maxime Ripard,
On Tue, 6 Jan 2015 16:45:08 +0100, Maxime Ripard wrote:
> + if (of_device_is_compatible(pdev->dev.of_node,
> + "marvell,armada-375-xhci") ||
> + of_device_is_compatible(pdev->dev.of_node,
> + "marvell
On Tue, 6 Jan 2015, vichy wrote:
> >> But I cannot see the keyboard go to suspend even I force autosuspend as 0.
> >> is there any other way to trigger runtime suspend immediately instead
> >> of waiting kernel judge it is idle for a while?
> >
> > There may be other reasons why the keyboard does
On Tue, 6 Jan 2015, Andreas Herrmann wrote:
> ehci-octeon driver used a 64-bit dma_mask. With removal of ehci-octeon
> and usage of ehci-platform ehci dma_mask is now limited to 32 bits
> (coerced in ehci_platform_probe).
>
> Provide a flag in ehci platform data to allow use of 64 bits for
> dma_
Commit 1290a958d48e ("usb: phy: propagate __of_usb_find_phy()'s error on
failure") actually broke the deferred probing mechanism, since it now returns
EPROBE_DEFER only when the try_module_get call fails, but not when the phy
lookup does.
All the other similar functions seem to return ENODEV when
The Armada 385 AP board has a USB3 port exposed that uses a GPIO to drive the
VBUS line. Enable the needed drivers to support this.
Signed-off-by: Maxime Ripard
---
arch/arm/boot/dts/armada-385-ap.dts | 28
1 file changed, 28 insertions(+)
diff --git a/arch/arm/boot
The Marvell Armada 385 AP needs a dumb phy in order to enable the USB3 VBUS.
Add a call to retrieve a USB PHY to XHCI plat in order to support this.
Signed-off-by: Maxime Ripard
---
drivers/usb/host/xhci-plat.c | 13 +
drivers/usb/host/xhci.h | 2 ++
2 files changed, 15 insert
The commit 973747928514 ("usb: host: xhci-plat: add support for the Armada
375/38x XHCI controllers") extended the xhci-plat driver to support the Armada
375/38x SoCs, mostly by adding a quirk configuring the MBUS window.
However, that quirk was run before the clock the controllers needs has been
Hi all,
This serie enables the Armada 385 AP XHCI controller.
Since the controller uses a GPIO-controlled VBUS, we used the
phy-generic driver, and made the needed additions to the xhci-plat
driver to retrieve a USB phy.
Unfortunately, some glitches were also found along the way, mostly
because
On Thu, 11 Dec 2014 arun.ramamur...@broadcom.com wrote:
> From: Arun Ramamurthy
>
> Added support for cases where one controller is connected
> to multiple phys
Will this continue to work on systems that use only one PHY? What
about systems that don't use DT?
> diff --git a/drivers/usb/host/o
On Tue, Jan 06, 2015 at 03:00:52PM +, Peterson, David wrote:
> From: David Peterson
>
> Added virtual com port VID/PID entries for CEL USB sticks and MeshWorks
> devices
>
> Signed-off-by: David Peterson
Applied, thanks.
Johan
> ---
> drivers/usb/serial/cp210x.c | 3 +++
> 1 file chang
On 01/06/2015 07:39 AM, Clemens Ladisch wrote:
> Paul Bonser wrote:
>> This device incorrectly reports its bInterfaceClass as 255, when it
>> should really be 1 (USB_CLASS_AUDIO).
>>
>> +++ b/sound/usb/quirks-table.h
>> +{
>> +/* Akai MPC Element */
>> +USB_DEVICE(0x09e8, 0x0021),
>> +.
hi Alan:
2015-01-06 23:03 GMT+08:00 Alan Stern :
> On Tue, 6 Jan 2015, vichy wrote:
>
>> I use keyboard, it should be default support runtime suspend, for
>> testing runtime suspend like the attach log.
>> insert related modules, change related suspend parameters.
>>
>> But I cannot see the keyboa
On Tue, 6 Jan 2015, vichy wrote:
> > I use keyboard, it should be default support runtime suspend, for
> > testing runtime suspend like the attach log.
> > insert related modules, change related suspend parameters.
> >
> > But I cannot see the keyboard go to suspend even I force autosuspend as 0.
On Tue, 6 Jan 2015, vichy wrote:
> I use keyboard, it should be default support runtime suspend, for
> testing runtime suspend like the attach log.
> insert related modules, change related suspend parameters.
>
> But I cannot see the keyboard go to suspend even I force autosuspend as 0.
> is ther
On Tue, 6 Jan 2015, vichy wrote:
> The mouse will reconnect even I just kept it connected and not moving it.
> is there any method or debug message we can tell what is going on to
> make it resume?
usbmon.
My guess is that the mouse disconnects and reconnects all by itself
after a few seconds of
Hi all,
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=90791
My machine is Thinkpad Yoga with Onelink dock attached. Onelink dock
is a USB 3.0 dock functioning as a USB 3.0 hub. This has two USB 3.0
ports in front. I connected a USB HDD enclosure to one of those ports.
After use, I safely
at91sam9g45, at91sam9x5 and sama5 SoCs should not use
"atmel,at91sam9rl-udc" for their USB device compatible property since
this compatible is attached to a specific hardware bug fix.
Signed-off-by: Boris Brezillon
---
arch/arm/boot/dts/at91sam9g45.dtsi | 2 +-
arch/arm/boot/dts/at91sam9x5.dtsi
Avoid interpreting useless status flags when we're not waiting for such
events by masking the status variable with the interrupt enabled register
value.
Reported-by: Patrice VILCHEZ
Signed-off-by: Boris Brezillon
---
drivers/usb/gadget/udc/atmel_usba_udc.c | 6 +-
1 file changed, 5 insertio
at91sam9g45 and at91sam9x5 SoCs have an hardware bug forcing us to
generate a pulse on the BIAS signal on "USB end of reset” and
“USB end of resume" events.
Reported-by: Patrice VILCHEZ
Signed-off-by: Boris Brezillon
---
drivers/usb/gadget/udc/atmel_usba_udc.c | 28 +++-
at91sam9rl SoC has an erratum forcing us to toggle the BIAS on USB
suspend/resume events.
This specific handling is only activated when CONFIG_ARCH_AT91SAM9RL is
set and this option is only set when building a non-DT kernel, which is
problematic since non-DT support for at91sam9rl SoC has been rem
Cache INT_ENB register value in order to avoid uncached iomem access, and
thus improve access time to INT_ENB value.
Signed-off-by: Boris Brezillon
---
drivers/usb/gadget/udc/atmel_usba_udc.c | 52 ++---
drivers/usb/gadget/udc/atmel_usba_udc.h | 2 ++
2 files changed
Hello,
Here is a set of patches porting existing at91sam9rl erratum handling to
DT and adding new code to handle at91sam9g45/9x5 erratum.
It also adds several compatible strings to differentiate those errata.
These patches should be backported to 3.17 and 3.18 stable releases but
they do not appl
Paul Bonser wrote:
> This device incorrectly reports its bInterfaceClass as 255, when it
> should really be 1 (USB_CLASS_AUDIO).
>
> +++ b/sound/usb/quirks-table.h
> +{
> + /* Akai MPC Element */
> + USB_DEVICE(0x09e8, 0x0021),
> + .bInterfaceClass = USB_CLASS_AUDIO,
> +},
This is not
This is a re-submission of patches 2 and 3 from
http://marc.info/?i=1415914590-31647-1-git-send-email-andreas.herrm...@caviumnetworks.com
(Only patch 1/3 made it into usb-next and meanwhile is in mainline.)
Please apply.
Thanks,
Andreas
PS: It's v2 as with last submission I hit the merge windo
On Tue, Jan 06, 2015 at 01:46:44PM +0100, Andreas Herrmann wrote:
> This is a re-submission of patches 2 and 3 from
> http://marc.info/?i=1415914590-31647-1-git-send-email-andreas.herrm...@caviumnetworks.com
> (Only patch 1/3 made it into usb-next and meanwhile is in mainline.)
>
> Please apply.
>
ehci-octeon driver used a 64-bit dma_mask. With removal of ehci-octeon
and usage of ehci-platform ehci dma_mask is now limited to 32 bits
(coerced in ehci_platform_probe).
Provide a flag in ehci platform data to allow use of 64 bits for
dma_mask.
Cc: David Daney
Cc: Alex Smith
Cc: Alan Stern
S
Instead rely on device tree information for ehci and ohci.
This was suggested with
http://www.linux-mips.org/cgi-bin/mesg.cgi?a=linux-mips&i=1401358203-60225-4-git-send-email-alex.smith%40imgtec.com
"The device tree will *always* have correct ehci/ohci clock
configuration, so use it. This al
hi all:
2015-01-06 16:06 GMT+08:00 vichy :
> hi alan:
>
> 2015-01-06 8:39 GMT+08:00 vichy :
>> 2015-01-05 23:40 GMT+08:00 Alan Stern :
>>> On Mon, 5 Jan 2015, vichy wrote:
>>>
hi all:
after tracing and reading kernel usb source code about run time and
normal suspend.
1. how cou
Hi Greg
Am 06.01.2015 um 02:54 schrieb Greg KH:
>
> Is that where the kernel panics show the problem happens? Without them,
> there's nothing we can do to help out except randomly guess, sorry.
well. at least xhci is contained in the call stack:
> [] (crc32_be) from [] (dvb_dmx_crc32+0x10/0x18
We try to free an ERR_PTR on this error path.
Fixes: b44be2462dbe ('usb: gadget: gadgetfs: Free memory allocated by
memdup_user()')
Signed-off-by: Dan Carpenter
diff --git a/drivers/usb/gadget/legacy/inode.c
b/drivers/usb/gadget/legacy/inode.c
index 0804861..db49ec4 100644
--- a/drivers/usb/ga
On Mon, Jan 05, 2015 at 12:33:51PM -0700, Stephen Warren wrote:
> On 12/23/2014 11:36 AM, Felipe Balbi wrote:
> >On Thu, Dec 04, 2014 at 01:06:07PM +0100, Thierry Reding wrote:
> >>From: Thierry Reding
> >>
> >>Commit 1290a958d48e ("usb: phy: propagate __of_usb_find_phy()'s error on
> >>failure")
On Tue, Jan 06, 2015 at 09:58:40AM +0100, Bjørn Mork wrote:
> Johan Hovold writes:
>
> > Ok, let's move the PID to option and if it turns out that more of these
> > devices require the modem-control signals (e.g. with more recent
> > firmware) we can consider moving it back after adding such supp
Support ndo_features_check to avoid:
- the transport offset is more than the hw limitation when using hw checksum.
- the skb->len of a GSO packet is more than the limitation.
Signed-off-by: Hayes Wang
---
drivers/net/usb/r8152.c | 17 +
1 file changed, 17 insertions(+)
diff --
Johan Hovold writes:
> Ok, let's move the PID to option and if it turns out that more of these
> devices require the modem-control signals (e.g. with more recent
> firmware) we can consider moving it back after adding such support to
> qcserial.
>
> Bjørn, do you see any problems with this? Are
Hi Greet-san,
>
> Hi Shimoda-san,
>
> On Wed, Dec 24, 2014 at 11:02 AM, yoshihiro shimoda
> wrote:
> >> > > Er, OK. Could you update MAINTAINERS?
> >> > there is no entry for renesas driver in MAINTAINERS.
> >> > Shimoda-san, care to send a patch adding yourself or Morimoto-san
On Mon, Jan 05, 2015 at 10:12:33PM +0100, Reinhard Speyerer wrote:
> Johan Hovold wrote:
>
> > On Sat, Dec 27, 2014 at 10:54:09PM +0100, Reinhard Speyerer wrote:
> > > Reinhard Speyerer wrote:
> > > > Johan Hovold wrote:
> > > > > On Sun, Dec 21, 2014 at 11:25:45PM +0100, Reinhard Speyerer wrot
hi alan:
2015-01-06 8:39 GMT+08:00 vichy :
> 2015-01-05 23:40 GMT+08:00 Alan Stern :
>> On Mon, 5 Jan 2015, vichy wrote:
>>
>>> hi all:
>>> after tracing and reading kernel usb source code about run time and
>>> normal suspend.
>>> 1. how could we check the rum time suspend is work on some device?
56 matches
Mail list logo
