Suspending an open usbnet device results in constant
rescheduling of usbnet_bh.
commit 65841fd5 "usbnet: handle remote wakeup asap"
refactored the usbnet_bh code to allow sharing the
urb allocate and submit code with usbnet_resume. In
this process, a test for, and immediate return on,
ENOLINK from
Hi,
I'm facing some problems with USB power management on OMAP3 (Beagleboard-Xm).
Lately I have tried kernel 3.6-rc3 for omap but usb bus suspend/resume is
switched off there due to some problems with clocks:
This is described in:
[PATCH] OMAP: USB : Fix the EHCI enumeration and core retention is
Signed-off-by: Bjørn Mork
---
drivers/net/usb/cx82310_eth.c | 11 +--
1 file changed, 1 insertion(+), 10 deletions(-)
diff --git a/drivers/net/usb/cx82310_eth.c b/drivers/net/usb/cx82310_eth.c
index 49ab45e..1e207f0 100644
--- a/drivers/net/usb/cx82310_eth.c
+++ b/drivers/net/usb/cx823
Signed-off-by: Bjørn Mork
---
drivers/net/usb/sierra_net.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/usb/sierra_net.c b/drivers/net/usb/sierra_net.c
index 7be49ea..596ddaa 100644
--- a/drivers/net/usb/sierra_net.c
+++ b/drivers/net/usb/sierra_net.c
@
The rx_urb_size is set to the same value for every device
supported by this driver. No need to keep a per-device
data structure to do that. Replacing with a macro constant.
This was the last device specific info, and removing it
allows us to delete the sierra_net_info_data struct.
Signed-off-by:
devm_* functions are used to replace kzalloc, request_mem_region, ioremap
clk_get and request_irq functions in probe call. With the usage of devm_*
functions explicit freeing and unmapping is not required.
Signed-off-by: Sachin Kamat
---
drivers/usb/gadget/s3c-hsudc.c | 41
Silences the following checkpatch warning:
WARNING: sizeof *hsreq should be sizeof(*hsreq)
Signed-off-by: Sachin Kamat
---
drivers/usb/gadget/s3c-hsudc.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/usb/gadget/s3c-hsudc.c b/drivers/usb/gadget/s3c-hsudc.c
inde
Silences the following type of sparse warnings:
warning: Using plain integer as NULL pointer
Signed-off-by: Sachin Kamat
---
drivers/usb/gadget/s3c-hsudc.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/gadget/s3c-hsudc.c b/drivers/usb/gadget/s3c-hsud
devm_* functions are already used in this file. Hence
convert clk_get to devm_clk_get for completeness.
Signed-off-by: Sachin Kamat
---
drivers/usb/gadget/s3c-hsotg.c |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/gadget/s3c-hsotg.c b/drivers/usb/gadget/s
Hi,
On Mon, Sep 3, 2012 at 3:48 PM, Sachin Kamat wrote:
> Silences the following type of sparse warnings:
> warning: Using plain integer as NULL pointer
>
> Signed-off-by: Sachin Kamat
> ---
> drivers/usb/gadget/s3c-hsudc.c |8
> 1 files changed, 4 insertions(+), 4 deletions(-)
>
>
Hi
On 3 September 2012 16:37, ABRAHAM, KISHON VIJAY wrote:
> Hi,
>
> On Mon, Sep 3, 2012 at 3:48 PM, Sachin Kamat wrote:
>> Silences the following type of sparse warnings:
>> warning: Using plain integer as NULL pointer
>>
>> Signed-off-by: Sachin Kamat
>> ---
>> drivers/usb/gadget/s3c-hsudc.c
Alan Stern wrote:
> How should the lower USB layers handle delays in transferring
> isochronous data? [...] when this happens the endpoint's queue
> drains completely.
>
> Clearly this will cause a glitch in the data stream. The question is:
> What should we do to recover and re-synchronize?
The
Peter Chen wrote:
>> How should the lower USB layers handle delays in transferring
>> isochronous data?
>> I have seen reports from users where URB completion interrupts were
>> delayed by as much as 50 ms.
>>
>> What should we do to recover and re-synchronize?
>
> I am not sure if feedback endpoin
On Friday 24 August 2012 16:42:20 Yann Cantin wrote:
> Hi,
>
> Le 24/08/2012 13:41, Oliver Neukum a écrit :
> > On Friday 24 August 2012 11:37:45 Yann Cantin wrote:
> >> Hi,
> >>
> >> Le 23/08/2012 09:23, Oliver Neukum a écrit :
> >>> On Thursday 23 August 2012 00:11:54 Yann Cantin wrote:
> >
> >
On Fri, Aug 31, 2012 at 08:37:26PM -0400, Forest Bond wrote:
> From: Forest Bond
>
> Certain eGalax devices expose an interface with class HID and protocol
> None. Some work with usbhid and some work with usbtouchscreen, but
> there is no easy way to differentiate. Sending an eGalax diagnostic
On Mon, Sep 03, 2012 at 05:00:44PM +0530, Sachin Kamat wrote:
> Hi
>
> On 3 September 2012 16:37, ABRAHAM, KISHON VIJAY wrote:
> > Hi,
> >
> > On Mon, Sep 3, 2012 at 3:48 PM, Sachin Kamat
> > wrote:
> >> Silences the following type of sparse warnings:
> >> warning: Using plain integer as NULL p
Hi,
On Wed, Aug 29, 2012 at 12:17:01PM +0530, Venu Byravarasu wrote:
> As otg.h is containing lots of phy interface related
> stuff, moving all phy interface related stuff to new
> file named phy.h
>
> Signed-off-by: Venu Byravarasu
this doesn't apply to my "xceiv" branch. Please rebase there s
Hi,
this is my first try on activating EHCI on imx53 (primarily via dt). However,
probe() still hangs on the first ehci_writel() l.189. I guess some
clock/enabling is still missing?
Sascha, do you already have EHCI running on imx53?
Any hint would be very much appreciated.
Thanks in advance,
R
Hi Roland,
On Mon, Sep 03, 2012 at 04:27:57PM +0200, Roland Stigge wrote:
> Hi,
>
> this is my first try on activating EHCI on imx53 (primarily via dt). However,
> probe() still hangs on the first ehci_writel() l.189. I guess some
> clock/enabling is still missing?
>
> Sascha, do you already hav
On 09/03/2012 04:37 PM, Sascha Hauer wrote:
> Hi Roland,
>
> On Mon, Sep 03, 2012 at 04:27:57PM +0200, Roland Stigge wrote:
>> Hi,
>>
>> this is my first try on activating EHCI on imx53 (primarily via dt). However,
>> probe() still hangs on the first ehci_writel() l.189. I guess some
>> clock/enab
This patch is to add "auto" option to attribute portX/control.
When echo "auto", the port's feature PORT_POWER would be clear
if the port's connect type was mark not-used(connectability and
visibility are both cleared) and with no device attached.
Signed-off-by: Lan Tianyu
---
This patchset is ba
ACPI provide "_PLD" and "_UPC" aml methods to describe usb port
visibility and connectability. This patch is to use those information
to set usb port's DeviceRemovable.
Signed-off-by: Lan Tianyu
---
v2: Set DeviceRemovable according acpi infomation in the hub_configure()
instead of calling get_hu
On Sun, 2 Sep 2012, Matthew Hall wrote:
> > > What about a quirk which gets the blocksize from the smaller commands and
> > > combines with the device size from the larger command?
> >
> > It's not quite that simple. The trace showed that two different
> > commands gave the right block size, a
Hi Marc and Sascha,
On 09/03/2012 04:49 PM, Marc Kleine-Budde wrote:
>> On Mon, Sep 03, 2012 at 04:27:57PM +0200, Roland Stigge wrote:
>>> Hi,
>>>
>>> this is my first try on activating EHCI on imx53 (primarily via
>>> dt). However, probe() still hangs on the first ehci_writel()
>>> l.189. I gues
Only this part of the question about kernel 3.x is actual.
In older kernel I have problems with clock domains and their dependencies.
--
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.
On 09/03/2012 05:39 PM, Roland Stigge wrote:
> Hi Marc and Sascha,
>
> On 09/03/2012 04:49 PM, Marc Kleine-Budde wrote:
>>> On Mon, Sep 03, 2012 at 04:27:57PM +0200, Roland Stigge wrote:
Hi,
this is my first try on activating EHCI on imx53 (primarily via
dt). However, probe() s
On Mon, 3 Sep 2012, Clemens Ladisch wrote:
> Alan Stern wrote:
> > How should the lower USB layers handle delays in transferring
> > isochronous data? [...] when this happens the endpoint's queue
> > drains completely.
> >
> > Clearly this will cause a glitch in the data stream. The question is:
On Fri, Aug 31, 2012 at 11:56 PM, Alan Stern wrote:
> Clemens and Laurent (and anyone else who's interested):
>
> How should the lower USB layers handle delays in transferring
> isochronous data? I'm asking you because the most common usages of
> isochronous transfers are for audio and video.
>
>
From: Forest Bond
Certain eGalax devices expose an interface with class HID and protocol
None. Some work with usbhid and some work with usbtouchscreen, but
there is no easy way to differentiate. Sending an eGalax diagnostic
packet seems to kick them all into using the right protocol for
usbtouc
From: Bjørn Mork
Date: Mon, 3 Sep 2012 10:26:18 +0200
> Suspending an open usbnet device results in constant
> rescheduling of usbnet_bh.
>
> commit 65841fd5 "usbnet: handle remote wakeup asap"
> refactored the usbnet_bh code to allow sharing the
> urb allocate and submit code with usbnet_resum
From: Bjørn Mork
Date: Mon, 3 Sep 2012 11:20:31 +0200
> Signed-off-by: Bjørn Mork
Applied.
--
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
From: Bjørn Mork
Date: Mon, 3 Sep 2012 11:20:32 +0200
> Signed-off-by: Bjørn Mork
Applied.
--
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
From: Bjørn Mork
Date: Mon, 3 Sep 2012 11:20:33 +0200
> The rx_urb_size is set to the same value for every device
> supported by this driver. No need to keep a per-device
> data structure to do that. Replacing with a macro constant.
>
> This was the last device specific info, and removing it
>
The various Orion SoCs, i.e. orion5x, kirkwood, dove, mv78xx0
and 370/XP have EHCI. Make sure USB_ARCH_HAS_EHCI reflects this.
Reported-by: Sebastian Hesselbarth
Signed-off-by: Andrew Lunn
---
drivers/usb/Kconfig |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/Kconfig b/drive
Andrew Lunn wrote:
>The various Orion SoCs, i.e. orion5x, kirkwood, dove, mv78xx0
>and 370/XP have EHCI. Make sure USB_ARCH_HAS_EHCI reflects this.
>
>Reported-by: Sebastian Hesselbarth
>Signed-off-by: Andrew Lunn
>---
> drivers/usb/Kconfig |1 +
> 1 file changed, 1 insertion(+)
>
>diff --gi
Alan Stern wrote:
> On Mon, 3 Sep 2012, Clemens Ladisch wrote:
>> Alan Stern wrote:
>>> Alternatively, the host controller driver could fail the next 40 ms
>>> worth of isochronous URBs, so that the higher-level client catches up
>>> to where it should be. The failure could occur during submission
On Mon, 3 Sep 2012, Jassi Brar wrote:
> On Fri, Aug 31, 2012 at 11:56 PM, Alan Stern
> wrote:
> > Clemens and Laurent (and anyone else who's interested):
> >
> > How should the lower USB layers handle delays in transferring
> > isochronous data? I'm asking you because the most common usages of
On Mon, 3 Sep 2012, Clemens Ladisch wrote:
> Alan Stern wrote:
> > On Mon, 3 Sep 2012, Clemens Ladisch wrote:
> >> Alan Stern wrote:
> >>> Alternatively, the host controller driver could fail the next 40 ms
> >>> worth of isochronous URBs, so that the higher-level client catches up
> >>> to where
With "select USB_ISP1301 ...", it could happen that I2C isn't selected although
USB_ISP1301 depends on it. Fixing with "depends on ..." and emulating the
condition via "|| !()".
Signed-off-by: Roland Stigge
Acked-by: Alan Stern
---
drivers/usb/host/Kconfig |2 +-
1 file changed, 1 insertion
Dnia sobota, 1 września 2012 o 22:51:42 Alan Stern napisał(a):
> On Sat, 1 Sep 2012, Marek Floriańczyk wrote:
> > > It's possible that data is getting lost, but it's pretty unlikely. The
> > > only way to get more detailed debugging information is to use a USB bus
> > > analyzer.
> >
> > HI,
> >
On Mon, 3 Sep 2012, Marek Floriańczyk wrote:
> HI,
>
> Debian testing, kernel 3.2.0-3 and results are the same. Order in which I
> call
> devices is important, first device I call always gives reply, second one
> almost
> never, no matter on what bus number they are. When I insert some delay
Dnia poniedziałek, 3 września 2012 o 22:00:03 Alan Stern napisał(a):
> On Mon, 3 Sep 2012, Marek Floriańczyk wrote:
> > HI,
> >
> > Debian testing, kernel 3.2.0-3 and results are the same. Order in which I
> > call devices is important, first device I call always gives reply,
> > second one almost
Alan Stern wrote:
> On Mon, 3 Sep 2012, Clemens Ladisch wrote:
>> The audio driver wouldn't care. Logically, it starts a new stream.
>
> Really? Why not just skip a few packets and carry on with the existing
> stream?
> Logically, the situation isn't very different from what happens when
> packet
On Mon, 3 Sep 2012, Clemens Ladisch wrote:
> Alan Stern wrote:
> > On Mon, 3 Sep 2012, Clemens Ladisch wrote:
> >> The audio driver wouldn't care. Logically, it starts a new stream.
> >
> > Really? Why not just skip a few packets and carry on with the existing
> > stream?
> > Logically, the situ
Despite the patch
{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1018, 0xff, 0xff,
0xff),
.driver_info = (kernel_ulong_t)&net_intf3_blacklist },
is included in option, it has no effect.
[ 1109.116127] usb 1-4: new high-speed USB device number 3 using ehci_hcd
[ 1109.251733]
> In such a situation, the delay is much bigger than the device's buffer,
> so just sending more samples afterwards will not help.
>
It is ISO transfer, if the delay is too much, and the buffer at device side is
empty, it is normal the screen is stopped like we watch movie on Internet
(buffering...
[CC'ing an USB audio heavyweight - Daniel Mack]
On Tue, Sep 4, 2012 at 12:39 AM, Alan Stern wrote:
> On Mon, 3 Sep 2012, Jassi Brar wrote:
>
>> On Fri, Aug 31, 2012 at 11:56 PM, Alan Stern
>> wrote:
>> > Clemens and Laurent (and anyone else who's interested):
>> >
>> > How should the lower USB
On Mon, Sep 3, 2012 at 4:26 PM, Bjørn Mork wrote:
> Suspending an open usbnet device results in constant
> rescheduling of usbnet_bh.
>
> commit 65841fd5 "usbnet: handle remote wakeup asap"
> refactored the usbnet_bh code to allow sharing the
> urb allocate and submit code with usbnet_resume. In
>
This patch adds Renesas R-Car USB phy driver.
It supports R8A7779 chip at this point.
Signed-off-by: Kuninori Morimoto
---
drivers/usb/phy/Kconfig| 11
drivers/usb/phy/Makefile |1 +
drivers/usb/phy/rcar-phy.c | 137
3 files changed,
49 matches
Mail list logo
