On Wed, Aug 14, 2013 at 03:38:04PM +0200, Andreas Lillebø Holm wrote:
> Hi,
>
> On Tuesday, August 13, 2013 at 8:40 PM, Greg KH wrote:
> > > When communicating with AT90USB1287, at random intervals (1/25 boots)
> > > the linux hid_output_field Oopses and kills the communicating thread.
> > > The A
Hi,
On Wed, Aug 14, 2013 at 10:15:45AM +, Italo Madalozo wrote:
> Dear people,
>
> I have recently bought a transcend USB3.0/ SATA III PCIe card combo. The
> sataIII works fine but, the USB does not work with either kernel 3.9 or
> 3.10 (I have only tried these two).
>
Could you enable C
> > From: Felipe Balbi [mailto:ba...@ti.com]
> > Sent: Tuesday, August 13, 2013 1:30 PM
> >
> > On Tue, Aug 13, 2013 at 08:04:26PM +, Paul Zimmerman wrote:
> > > > From: Felipe Balbi
> > > > Sent: Tuesday, August 13, 2013 12:20 PM
> > > >
> > > > On Mon, Aug 05, 2013 at 03:41:57PM +, Wang,
On Tue, 13 Aug 2013, Daniel Mack wrote:
> Hi Alan,
>
> On 13.08.2013 23:06, Alan Stern wrote:
> > On Mon, 12 Aug 2013, Alan Stern wrote:
> >> On Mon, 12 Aug 2013, Takashi Iwai wrote:
> >>
> >>> So... Clemens, Daniel, Eldad, could you guys review the latest version
> >>> of Alan's patch? I'd lo
OK, so I had to plug the hard drive a couple of time to have the
behavior. I uploaded the files (2 usbmon log files and 1 corresponding
dmesg) as attachments to kernel bug 60738 (
https://bugzilla.kernel.org/show_bug.cgi?id=60738)
Here are the links to the files:
usbmon on all buses (https://b
On Wed, Aug 14, 2013 at 08:16:56PM +, Paul Zimmerman wrote:
> Mark's original complaint about USB was this:
>
> > the device). The hub needs to be "plugged" into the SoC after the SoC
> > USB controller has started with some GPIOs so we need to tell the system
> > that the hub exists and nee
On Wed, Aug 14, 2013 at 03:39:20PM -0400, Alan Stern wrote:
> I don't see the point of all this. Obviously the device can't be used
> until it physically appears on the bus. What benefit do you get from
> registering it and making it available to userspace before that?
Two things. One is that
ATTENTION.
Let me use the liberty of this medium to inform you that my principal is
interested in investing his bond as a silent business partner in your company.
He would like to invest in private sector projects with an established company
in any project(s) which are already in the market
On Wed, Aug 14, 2013 at 12:47:44PM -0700, Greg KH wrote:
> On Wed, Aug 14, 2013 at 08:39:50PM +0100, Mark Brown wrote:
> > That resource is the USB bus I think (I suspect the issue is that the
> > fact that power is always present confuses the USB enumeration protocol
> > if the device gets brough
Hi,
On 12/08/13 21:08, Felipe Balbi wrote:
On Fri, Aug 09, 2013 at 09:23:08PM +0300, Philippe De Swert wrote:
Some bad gadget drivers do not check the return status of usb_add_config.
fix the gadget driver
As stated in my comment (see below) that is indeed what should happen.
But we cannot
Modified the xHCI roothub descriptor to return USB2.0 extension
descriptor Best Effort Service Latency (BESL) and Deep Best Effort
Service Latency (DBESL) values when set on the xHCI host.
On link power management the BESL and DBESL values are used to
estimate L1 exit latency for USB2.0 host and d
Paul,
Thank you for catching the bug.
Sarah,
Thank you for the detailed description and explanation on the changes. I
will send the patch shortly with the updated changes and test.
Alexandra.
> On Sat, Aug 10, 2013 at 04:04:02AM +, Paul Zimmerman wrote:
>> > From: linux-usb-ow...@vger.kerne
On Tue, Aug 13, 2013 at 09:46:36PM +0400, Sergei Shtylyov wrote:
>
> >> Do you really need a copy? Isn't it better to rename the parameter and
> >>remove this line altogether?
>
> >>WBR, Sergei
>
> >Yes, that is the idea, for next patch series, as I don't want to mix two
> >changes in single
On Tue, Aug 13, 2013 at 01:27:33PM +0200, Johan Hovold wrote:
> Greg,
>
> Here's a bunch of fixes for v3.11 and (possibly) v3.12.
>
> The first two I think should go into v3.11 whereas the remaining patches
> could wait for v3.12, unless you think otherwise.
No, that makes sense, I've split the
> From: Alan Stern
> Sent: Wednesday, August 14, 2013 12:39 PM
> Now I'm getting confused. It seems we're talking about at least three
> very different things here:
>
> A: Devising a mechanism for platform code to do things involving
> devices that are dynamically registered on discov
Hi all,
This patch is required for USB support on Tegra30 due to a likely hardware
bug in the PLL_U oscillator which clocks the USB complex.
The other USB patches for Tegra30 and Tegra114 are already on their way
to 3.12, this is the only one left for Tegra30.
Peter, Prashant, any comments on th
The lock bit on PLL_U does not seem to be working correctly and
sometimes never gets set when waiting for the PLL to come up.
Remove the TEGRA_PLL_USE_LOCK flag to use a constant delay.
Signed-off-by: Tuomas Tynkkynen
---
drivers/clk/tegra/clk-tegra30.c | 2 +-
1 file changed, 1 insertion(+), 1
On Wed, Aug 14, 2013 at 08:39:50PM +0100, Mark Brown wrote:
> > > We can't just treat it as a PHY (which is the obvious workaroud) since
> > > we do also need to use the built
> > > in PHY in the SoC.
>
> > There has to be some type of resource that it can grab, as obviously
> > it's failing to wo
On Wed, Aug 14, 2013 at 12:15:13PM -0700, Greg KH wrote:
> On Wed, Aug 14, 2013 at 08:04:10PM +0100, Mark Brown wrote:
> > In order for deferred probing to help the device would need to acquire
> > some resource from the parent USB controller once active, allowing it to
> > defer when it fails to
On Wed, 14 Aug 2013, Mark Brown wrote:
> On Wed, Aug 14, 2013 at 02:35:07PM -0400, Alan Stern wrote:
> > On Wed, 14 Aug 2013, Mark Brown wrote:
>
> > > What I'm proposing is that we have a way of telling buses that devices
> > > exist via a mechanism other than their actually being visible on the
On Wed, Aug 14, 2013 at 12:44:02PM +0300, Alexander Shishkin wrote:
> From: Fabio Estevam
>
> After the rename to ci_hdrc we ended up with two MODULE_ALIAS entries, so
> remove the old one.
>
> Signed-off-by: Fabio Estevam
> Reviewed-by: Peter Chen
> Signed-off-by: Alexander Shishkin
> ---
>
On Wed, Aug 14, 2013 at 03:34:27PM +0200, Hans de Goede wrote:
> Signed-off-by: Hans de Goede
> ---
> Documentation/ABI/testing/sysfs-bus-usb | 38
> +
> 1 file changed, 38 insertions(+)
>
> diff --git a/Documentation/ABI/testing/sysfs-bus-usb
> b/Documentation/
On Wed, Aug 14, 2013 at 03:34:27PM +0200, Hans de Goede wrote:
> Signed-off-by: Hans de Goede
> ---
> Documentation/ABI/testing/sysfs-bus-usb | 38
> +
> 1 file changed, 38 insertions(+)
Please try to remember to cc: me on usb patches you want applied,
otherwise
On Wed, Aug 14, 2013 at 08:04:10PM +0100, Mark Brown wrote:
> On Wed, Aug 14, 2013 at 11:22:39AM -0700, Greg KH wrote:
> > On Wed, Aug 14, 2013 at 03:59:31PM +0530, Tushar Behera wrote:
>
> > > Currently there is no other way to ensure that USB3503 chip is probed
> > > after the USB PHY has been i
On Wed, 2013-08-14 at 09:06 -0700, Stephen Boyd wrote:
> On 08/14/13 05:59, Ivan T. Ivanov wrote:
> > +}
> > +
> > +static const struct of_device_id of_dwc3_matach[] = {
>
> match? Maybe you can make it all one line too { .compatible = "qcom,dwc3" }
>
Thanks. Will do.
Ivan
> > + {
> > +
On Wed, Aug 14, 2013 at 11:22:39AM -0700, Greg KH wrote:
> On Wed, Aug 14, 2013 at 03:59:31PM +0530, Tushar Behera wrote:
> > Currently there is no other way to ensure that USB3503 chip is probed
> > after the USB PHY has been initialized, hence the last resort.
> Are you sure that deferred probi
On 08/14/2013 01:58 PM, Dan Williams wrote:
snip
> The 4G part of the 250U is a Beceem WiMAX chip, for which there are no
> drivers on Linux at this time. The 4G parts are used with a
> pseudo-ethernet interface, but since there aren't any kernel drivers,
> that's not going to work. The 4G parts d
On Wed, 2013-08-14 at 11:43 -0500, Peter Hyman wrote:
> Linux Kernel: 3.9.10
> Device Driver: usb/serial/sierra.c
> Device Driver version: not known
>
> Apparently Sierra has sold the AirCard 250U product to Netgear, so I am
> sure driver development on drivers/usb/serial/sierra.c will be in limbo
On 08/14/2013 01:42 PM, Bjørn Mork wrote:
> snip...
> Great! And if you can snoop on Windows trying to figure out how to
> switch the modes, then that would also help. I believe Wireshark with
> usbpcap is the current state-of-the-art USB sniffer for Windows:
> http://desowin.org/usbpcap/
>
>
> B
On Wed, Aug 14, 2013 at 10:30:44AM -0600, Stephen Warren wrote:
> On 08/14/2013 10:14 AM, Alan Stern wrote:
> > No, no -- this is exactly the point I was trying to make. The on-board
> > hub _won't_ appear on the USB bus until the GPIOs are set. Therefore
> > the callback to set the GPIOs needs
On Wed, Aug 14, 2013 at 02:35:07PM -0400, Alan Stern wrote:
> On Wed, 14 Aug 2013, Mark Brown wrote:
> > What I'm proposing is that we have a way of telling buses that devices
> > exist via a mechanism other than their actually being visible on the bus
> > at the current time. If you're doing tha
Sebastian,
On Wed, Aug 14, 2013 at 1:17 PM, Sebastian Andrzej Siewior
wrote:
> So I tried to boot my beagle bone board to figure out if they use the
> first or the second port in host mode (but it doesn't boot). The tiny
> micro USB plug is 100% for UART and not wired up to MUSB.
I have not run
Peter Hyman writes:
> On 08/14/2013 01:02 PM, Bjørn Mork wrote:
>> Peter Hyman writes:
>>
>>> Linux Kernel: 3.9.10
>>> Device Driver: usb/serial/sierra.c
>>> Device Driver version: not known
>>>
>>> Apparently Sierra has sold the AirCard 250U product to Netgear, so I am
>>> sure driver developme
Hello.
On 08/14/2013 10:04 PM, Sebastian Andrzej Siewior wrote:
+USB
+~~~
+compatible: ti,musb-am33xx
+reg: offset and length "USB Controller Registers"
+reg-names: control
+
+This node contains the musb core:
+- compatible: "mg,musbmhdr"
"mg,musbmhdrc" you mean?
Yes.
Perhaps it'
On Wed, 14 Aug 2013, Mark Brown wrote:
> On Wed, Aug 14, 2013 at 12:14:06PM -0400, Alan Stern wrote:
> > On Wed, 14 Aug 2013, Mark Brown wrote:
>
> > > Yes, so you'd want callbacks when the device actually appears and
> > > disappears.
>
> > No, no -- this is exactly the point I was trying to ma
Alan Stern wrote:
> On Mon, 12 Aug 2013, Alan Stern wrote:
>> Here's a revised version of the patch (still untested). The difference
>> is that this version tries always to keep a period's worth of bytes in
>> the USB hardware queue. This will provide better protection against
>> underruns when t
On 08/14/2013 12:51 PM, Joe Perches wrote:
> On Wed, 2013-08-14 at 09:40 -0700, Sarah Sharp wrote:
>> Hi Xenia,
>>
>> I'm a bit confused. I thought that debugging messages would be turned
>> off by default for a module if CONFIG_DYNAMIC_DEBUG was turned on. When
>> I tested your patch to remove t
On 08/14/2013 01:05 PM, Greg KH wrote:
> On Wed, Aug 14, 2013 at 11:43:37AM -0500, Peter Hyman wrote:
>> Linux Kernel: 3.9.10
>> Device Driver: usb/serial/sierra.c
>> Device Driver version: not known
>>
>> Apparently Sierra has sold the AirCard 250U product to Netgear, so I am
>> sure driver develo
On 08/14/2013 01:02 PM, Bjørn Mork wrote:
> Peter Hyman writes:
>
>> Linux Kernel: 3.9.10
>> Device Driver: usb/serial/sierra.c
>> Device Driver version: not known
>>
>> Apparently Sierra has sold the AirCard 250U product to Netgear, so I am
>> sure driver development on drivers/usb/serial/sierra.
Peter Hyman writes:
> Linux Kernel: 3.9.10
> Device Driver: usb/serial/sierra.c
> Device Driver version: not known
>
> Apparently Sierra has sold the AirCard 250U product to Netgear, so I am
> sure driver development on drivers/usb/serial/sierra.c will be in limbo
> for a period. While I am copyi
On Wed, Aug 14, 2013 at 03:59:31PM +0530, Tushar Behera wrote:
> USB3503 chip needs to be reset after the USB PHY controller has been
> intiliazed, otherwise it is not detected as plugged in.
Why not?
> Currently there is no other way to ensure that USB3503 chip is probed
> after the USB PHY has
On Wed, Aug 14, 2013 at 02:32:01PM +0200, Hans de Goede wrote:
> Hi All,
>
> As discussed a long while back, usbfs is currently missing bulk streams
> support, and we ought to fix this. So this patch extends the usbfs API with
> bulk stream support. Please review.
At first glance, it looks sane,
if pdata is a NULL pointer we could cause a
kernel oops when probing the driver. Make sure
to cope with systems which won't pass pdata
to the driver.
Tested-by: Paul Zimmerman
Reported-by: Paul Zimmerman
Signed-off-by: Felipe Balbi
---
drivers/usb/dwc3/core.c | 5 -
1 file changed, 4 inser
On Wed, Aug 14, 2013 at 09:03:19AM -0500, Felipe Balbi wrote:
> On Tue, Aug 13, 2013 at 09:50:20PM +, Paul Zimmerman wrote:
> > > From: Felipe Balbi [mailto:ba...@ti.com]
> > > Sent: Tuesday, August 13, 2013 2:12 PM
> > >
> > > if pdata is a NULL pointer we could cause a
> > > kernel oops when
On 08/13/2013 04:32 PM, Bin Liu wrote:
> Sebastian,
Hi Bin,
> On Tue, Aug 13, 2013 at 9:23 AM, Sebastian Andrzej Siewior
> wrote:
>> Where is my memory going? So now I have a beagle bone in front of me
>> and I see a micro USB port a standard A connector. My memory was
>> different.
>> The micro
There is no need for two else-if constructs for the type_1 chip
detection in pl2303_startup(), so merge them.
Signed-off-by: Frank Schäfer
---
drivers/usb/serial/pl2303.c |5 ++---
1 Datei geändert, 2 Zeilen hinzugefügt(+), 3 Zeilen entfernt(-)
diff --git a/drivers/usb/serial/pl2303.c b/dri
The chip type distinction is getting more and more relevant and
complicating, so always print the chip type.
Printing a name string is also much better than just printing an
internal index number.
Signed-off-by: Frank Schäfer
---
drivers/usb/serial/pl2303.c | 15 ++-
1 Datei geände
The driver currently knows about 3 different PL2303 chip types:
The two legacy chip types type_0 and type_1 (PL2303H ?) and the HX
type.
The device distinction is currently completely based on the examination
of the USB descriptors.
During the last years, Prolific has introduced further PL2303 chip
The chip type distinction is one of the weak spots of the pl2303 driver.
It currently knows 3 different PL2303 chip types only (the two legacy
chip types type_0 and type_1 (PL2303H ?) and the HX type).
During the last 2-3 years Prolific has introduced additional PL2303
chips, such as the HXD (HX
On Wed, Aug 14, 2013 at 11:43:37AM -0500, Peter Hyman wrote:
> Linux Kernel: 3.9.10
> Device Driver: usb/serial/sierra.c
> Device Driver version: not known
>
> Apparently Sierra has sold the AirCard 250U product to Netgear, so I am
> sure driver development on drivers/usb/serial/sierra.c will be i
On 08/14/2013 07:51 PM, Sergei Shtylyov wrote:
> Hello.
Hi Sergei,
> [...]
>> +USB
>> +~~~
>> +compatible: ti,musb-am33xx
>> +reg: offset and length "USB Controller Registers"
>> +reg-names: control
>> +
>> +This node contains the musb core:
>> +- compatible: "mg,musbmhdr"
>
>"mg,musbmhdrc"
On Wed, Aug 14, 2013 at 10:20:43AM -0700, Sarah Sharp wrote:
> On Wed, Aug 14, 2013 at 10:04:10AM -0700, Greg KH wrote:
> > On Wed, Aug 14, 2013 at 09:51:54AM -0700, Joe Perches wrote:
> > > On Wed, 2013-08-14 at 09:40 -0700, Sarah Sharp wrote:
> > > > Hi Xenia,
> > > >
> > > > I'm a bit confused.
Hello.
On 08/14/2013 09:29 PM, Sebastian Andrzej Siewior wrote:
The support for both am335x-USB instances required changes to the device
tree bindings. This patch reflects these changes in the bindings
document.
Signed-off-by: Sebastian Andrzej Siewior
---
.../devicetree/bindings/usb/am33
Linux Kernel: 3.9.10
Device Driver: usb/serial/sierra.c
Device Driver version: not known
Apparently Sierra has sold the AirCard 250U product to Netgear, so I am
sure driver development on drivers/usb/serial/sierra.c will be in limbo
for a period. While I am copying li...@sierrawireless.com, they w
I forgot to separete the different names in the reg-names property. This
didn't cause anything to fail because the driver does not use the names
and simply relies on the order of the memory offsets in reg.
This patch fixes this in case it is used later.
Signed-off-by: Sebastian Andrzej Siewior
--
On Wed, Aug 14, 2013 at 12:14:06PM -0400, Alan Stern wrote:
> On Wed, 14 Aug 2013, Mark Brown wrote:
> > Yes, so you'd want callbacks when the device actually appears and
> > disappears.
> No, no -- this is exactly the point I was trying to make. The on-board
> hub _won't_ appear on the USB bus
The support for both am335x-USB instances required changes to the device
tree bindings. This patch reflects these changes in the bindings
document.
Signed-off-by: Sebastian Andrzej Siewior
---
.../devicetree/bindings/usb/am33xx-usb.txt | 239 ++---
1 file changed, 210 ins
Hi,
this tiny series updates the bindings document to reflect the code & fixes
typo in one binding.
Sebastian
--
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-inf
On Wed, Aug 14, 2013 at 10:04:10AM -0700, Greg KH wrote:
> On Wed, Aug 14, 2013 at 09:51:54AM -0700, Joe Perches wrote:
> > On Wed, 2013-08-14 at 09:40 -0700, Sarah Sharp wrote:
> > > Hi Xenia,
> > >
> > > I'm a bit confused. I thought that debugging messages would be turned
> > > off by default
On Wed, Aug 14, 2013 at 10:10:23AM -0400, Alan Stern wrote:
> On Tue, 13 Aug 2013, Jack Pham wrote:
>
> > > > In addition, we may want some of the work (though at this point I'm
> > > > not still clear on exactly what parts) to be moved into usbcore.
> >
> > +1. I am open to suggestions on how be
On Wed, Aug 14, 2013 at 09:51:54AM -0700, Joe Perches wrote:
> On Wed, 2013-08-14 at 09:40 -0700, Sarah Sharp wrote:
> > Hi Xenia,
> >
> > I'm a bit confused. I thought that debugging messages would be turned
> > off by default for a module if CONFIG_DYNAMIC_DEBUG was turned on. When
> > I teste
On Wed, 2013-08-14 at 09:40 -0700, Sarah Sharp wrote:
> Hi Xenia,
>
> I'm a bit confused. I thought that debugging messages would be turned
> off by default for a module if CONFIG_DYNAMIC_DEBUG was turned on. When
> I tested your patch to remove the CONFIG_USB_XHCI_HCD_DEBUGGING and just
> use d
On 08/14/2013 10:14 AM, Alan Stern wrote:
> On Wed, 14 Aug 2013, Mark Brown wrote:
>
>> On Wed, Aug 14, 2013 at 10:27:26AM -0400, Alan Stern wrote:
>>> On Wed, 14 Aug 2013, Mark Brown wrote:
>>
I'd expect that we're just looking at hooks around connection and
disconnection here here - if
On Wed, 14 Aug 2013, Mark Brown wrote:
> On Wed, Aug 14, 2013 at 10:27:26AM -0400, Alan Stern wrote:
> > On Wed, 14 Aug 2013, Mark Brown wrote:
>
> > > I'd expect that we're just looking at hooks around connection and
> > > disconnection here here - if we're looking at much more it seems like we
On 08/14/13 05:59, Ivan T. Ivanov wrote:
> +}
> +
> +static const struct of_device_id of_dwc3_matach[] = {
match? Maybe you can make it all one line too { .compatible = "qcom,dwc3" }
> + {
> + .compatible = "qcom,dwc3",
> + },
> + { },
> +};
> +MODULE_DEVICE_TABLE(of, of_d
On Wed, Aug 14, 2013 at 12:07 PM, wrote:
> Well... finally it doesn't work.
>
> When added to sw.c, the key is powered on, it's MAC address and few networks
> can be seen.
>
> But I can't connect to any network.
Have you tried it on 3.11-rc5?
--
To unsubscribe from this list: send the line "uns
On Wed, Aug 14, 2013 at 10:27:26AM -0400, Alan Stern wrote:
> On Wed, 14 Aug 2013, Mark Brown wrote:
> > I'd expect that we're just looking at hooks around connection and
> > disconnection here here - if we're looking at much more it seems like we
> > must be doing something wrong.
> Connection a
Hi Roger,
Am Mittwoch, den 14.08.2013, 16:58 +0300 schrieb Roger Quadros:
> Modelling the RESET line as a regulator supply wasn't a good idea
> as it kind of abuses the regulator framework and also makes adaptation
> code more complex.
>
> Instead, manage the RESET gpio line directly in the drive
Hi,
On Wednesday 14 August 2013 04:34 AM, Tomasz Figa wrote:
> On Wednesday 14 of August 2013 00:19:28 Sylwester Nawrocki wrote:
>> W dniu 2013-08-13 14:05, Kishon Vijay Abraham I pisze:
>>> On Tuesday 13 August 2013 05:07 PM, Tomasz Figa wrote:
On Tuesday 13 of August 2013 16:14:44 Kishon Vi
Well... finally it doesn't work.
When added to sw.c, the key is powered on, it's MAC address and few networks
can be seen.
But I can't connect to any network.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majord
Hi,
On Wed, 2013-08-14 at 09:20 -0500, Josh Cartwright wrote:
> On Wed, Aug 14, 2013 at 03:59:42PM +0300, Ivan T. Ivanov wrote:
> > From: "Ivan T. Ivanov"
> >
> > These drivers handles control and configuration of the HS
> > and SS USB PHY transceivers. They are part of the driver
> > which m
On Wed, 14 Aug 2013, Mark Brown wrote:
> On Mon, Aug 12, 2013 at 09:04:00PM -0400, Alan Stern wrote:
>
> > The bus code would need hooks installed wherever the platform wants to
> > do something extra. This could end up growing to a lot of hooks. How
> > can the whole thing be done in a reaso
On Wed, 14 Aug 2013, Oliver Neukum wrote:
> On Wed, 2013-08-14 at 14:46 +0530, Vivek Gautam wrote:
>
> Hi,
>
> > >> devices and root-hubs across suspend/resume. Are the device contexts
> > >> saved somewhere and then restored back on resume ?
> > >
> > > Usually not. The state of interfaces are
On Wed, Aug 14, 2013 at 03:59:42PM +0300, Ivan T. Ivanov wrote:
> From: "Ivan T. Ivanov"
>
> These drivers handles control and configuration of the HS
> and SS USB PHY transceivers. They are part of the driver
> which manage Synopsys DesignWare USB3 controller stack
> inside Qualcomm SoC's.
>
>
On Wed, 14 Aug 2013, Oliver Neukum wrote:
> On Wed, 2013-08-14 at 13:24 +0530, Vivek Gautam wrote:
> > Hi all,
> >
> >
> > Going through the power suspend/resume sequence of USB, got hit by a doubt.
> >
> > I am not able to figure out how the USB core driver takes care of
>
> It doesn't.
All
Hi,
On Tue, Aug 13, 2013 at 03:29:45PM -0700, Greg KH wrote:
> On Tue, Aug 13, 2013 at 03:01:23PM -0500, Felipe Balbi wrote:
> > Hi,
> >
> > On Tue, Aug 13, 2013 at 02:48:42PM -0500, Felipe Balbi wrote:
> > > On Tue, Aug 13, 2013 at 02:41:25PM -0500, Felipe Balbi wrote:
> > > > Hi Greg,
> > > >
On Tue, 13 Aug 2013, Sarah Sharp wrote:
> > Martin is right; the BOS descriptors are leaked in
> > usb_reset_and_verify_device(). We need to store the old descriptor,
> > compare it with the new one following the reset, and delete one of them
> > afterward. I haven't had time to fix this.
>
>
On Tue, 13 Aug 2013, Jack Pham wrote:
> > > In addition, we may want some of the work (though at this point I'm
> > > not still clear on exactly what parts) to be moved into usbcore.
>
> +1. I am open to suggestions on how best to achieve this. I have a
> another patch in the for doing the same
On Tue, Aug 13, 2013 at 09:50:20PM +, Paul Zimmerman wrote:
> > From: Felipe Balbi [mailto:ba...@ti.com]
> > Sent: Tuesday, August 13, 2013 2:12 PM
> >
> > if pdata is a NULL pointer we could cause a
> > kernel oops when probing the driver. Make sure
> > to cope with systems which won't pass p
Provide RESET GPIO and Power regulator for the USB PHY,
the USB Host port mode and the PHY device for the controller.
Also provide pin multiplexer information for USB host pins.
We also relocate omap3_pmx_core pin definations so that they
are close to omap3_pmx_wkup pin definations.
Signed-off-by
The USB phy-nop nop driver expects the RESET line information
to be sent as a GPIO number via platform data. Adapt to that.
Signed-off-by: Roger Quadros
---
arch/arm/mach-omap2/usb-host.c | 11 +--
1 files changed, 1 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/usb-
Modelling the RESET line as a regulator supply wasn't a good idea
as it kind of abuses the regulator framework and also makes adaptation
code more complex.
Instead, manage the RESET gpio line directly in the driver. Update
the device tree binding information.
This also makes us easy to migrate to
Use a common naming scheme "mode0name.modename flags" for the
USB host pins to be consistent.
Signed-off-by: Roger Quadros
---
arch/arm/boot/dts/omap3-beagle.dts | 24
1 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-beagle.dts
The platform data bits can be inferred from the other members of
struct usbhs_phy_data. So get rid of the platform_data member.
Build the platform data for the PHY device in usbhs_init_phys() instead.
Signed-off-by: Roger Quadros
---
arch/arm/mach-omap2/board-omap3beagle.c |6 --
arch/a
Hi,
Modelling the RESET line as a regulator supply wasn't a good idea
as it abuses the regulator framework and makes adaptation
code/data more complex.
Instead, manage the RESET gpio line directly in the driver.
This also makes us easy to migrate to a dedicated GPIO RESET controller
whenever it
The GPIO number of the RESET line can be passed to the
driver using the gpio_reset member.
Signed-off-by: Roger Quadros
---
include/linux/usb/nop-usb-xceiv.h |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/include/linux/usb/nop-usb-xceiv.h
b/include/linux/usb/nop-usb
We no longer need to model the RESET line as a regulator since
the USB phy-nop driver accepts "reset-gpios" property.
Signed-off-by: Roger Quadros
---
arch/arm/boot/dts/omap5-uevm.dts | 13 +
1 files changed, 1 insertions(+), 12 deletions(-)
diff --git a/arch/arm/boot/dts/omap5-ue
We no longer need to model the RESET line as a regulator since
the USB phy-nop driver accepts "reset-gpios" property.
Signed-off-by: Roger Quadros
---
arch/arm/boot/dts/omap3-beagle.dts | 13 +
1 files changed, 1 insertions(+), 12 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-
We no longer need to model the RESET line as a regulator since
the USB phy-nop driver accepts "reset-gpios" property.
Signed-off-by: Roger Quadros
---
arch/arm/boot/dts/omap4-panda-common.dtsi | 18 +-
1 files changed, 1 insertions(+), 17 deletions(-)
diff --git a/arch/arm/boo
Signed-off-by: Hans de Goede
---
Documentation/ABI/testing/sysfs-bus-usb | 38 +
1 file changed, 38 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-bus-usb
b/Documentation/ABI/testing/sysfs-bus-usb
index 9c8926c..0053ae2 100644
--- a/Documentation/ABI/
Hi All,
This patch adds documentation for all sysfs files used by libusb.
Changes in v2:
-Spelling fixes
-Add text about writing to bConfigurationValue, suggested by Alan Stern
Changes in v3:
-Rebase on latest usb-next
Changes in v4:
-Improve the wording for the descriptors text, suggested by J
Hi,
On 08/14/2013 12:18 PM, Johan Hovold wrote:
On Wed, Aug 14, 2013 at 11:17:57AM +0200, Hans de Goede wrote:
+What: /sys/bus/usb/devices/.../busnum
+KernelVersion: 2.6.22
+Description:
+ Bus-number of the USB-bus the device is connected to.
+
+What: /sys/bus/us
Hi,
On Tuesday, August 13, 2013 at 8:40 PM, Greg KH wrote:
> > When communicating with AT90USB1287, at random intervals (1/25 boots)
> > the linux hid_output_field Oopses and kills the communicating thread.
> > The AT90USB1287 microcontroller uses LUFA library for usb/hid
> > communication. It is
From: "Ivan T. Ivanov"
Hi,
These patches add basic support for USB3.0 controllers found
on MSM platforms. USB3.0 core is based on Synopsys DesignWare
SuperSpeed IP.
Changes since v2:
* Several improvements in devicetree bindings description
* Disable regulators in glue layer if there is error
From: "Ivan T. Ivanov"
These drivers handles control and configuration of the HS
and SS USB PHY transceivers. They are part of the driver
which manage Synopsys DesignWare USB3 controller stack
inside Qualcomm SoC's.
Signed-off-by: Ivan T. Ivanov
---
drivers/usb/phy/Kconfig | 11 ++
From: "Ivan T. Ivanov"
MSM USB3.0 core wrapper consist of USB3.0 IP from Synopsys
(SNPS) and HS, SS PHY's control and configuration registers.
It could operate in device mode (SS, HS, FS) and host
mode (SS, HS, FS, LS).
Signed-off-by: Ivan T. Ivanov
---
.../devicetree/bindings/usb/msm-ssusb.t
From: "Ivan T. Ivanov"
DWC3 glue layer is hardware layer around Synopsys DesignWare
USB3 core. Its purpose is to supply Synopsys IP with required
clocks, voltages and interface it with the rest of the SoC.
Signed-off-by: Ivan T. Ivanov
---
drivers/usb/dwc3/Kconfig|8 ++
drivers/usb/dwc
Use the interrupt transfer to replace polling link status.
Signed-off-by: Hayes Wang
---
drivers/net/usb/r8152.c | 140 ++--
1 file changed, 113 insertions(+), 27 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 4d938a
Enable the tx/rx aggregation which could contain one or more packets
for each bulk in/out. This could reduce the loading of the host
controller by sending less bulk transfer.
The rx packets in the bulk in buffer should be 8-byte aligned, and
the tx packets in the bulk out buffer should be 4-byte a
Enable tx checksum.
Signed-off-by: Hayes Wang
---
drivers/net/usb/r8152.c | 64 +
1 file changed, 59 insertions(+), 5 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index abb0b9f..4d938a7 100644
--- a/drivers/net/usb/r
1 - 100 of 164 matches
Mail list logo
