On Mon, Jun 17, 2013 at 9:59 AM, Peter Chen wrote:
> On Thu, Mar 21, 2013 at 11:06 AM, Peter Chen wrote:
>> On Wed, Mar 20, 2013 at 01:04:33PM +0200, Alexander Shishkin wrote:
>>> Peter Chen writes:
>>>
>>> > On Fri, Mar 15, 2013 at 05:17:08PM +0200, Alexander Shishkin wrote:
>>> >>
>>> >> > Eg,
> - I use the port in HOST mode by plugging in a USB pendrive over the OTG-
> capable
> reduction ; this works OK
> - I disconnect the reduction and connect it to the computer ; here I get
> "timeout waiting for 0800 in 11".
>
> This means the BSV bit in OTGSC register wasn't unset.
>
> Int
On Friday 28 June 2013 08:57 AM, Jingoo Han wrote:
On Wed, 26 Jun 2013 17:17:29 +0530, Kishon Vijay Abraham Iwrote:
The PHY framework provides a set of APIs for the PHY drivers to
create/destroy a PHY and APIs for the PHY users to obtain a reference to the
PHY with or without using phandle. For
On Wed, 26 Jun 2013 17:17:29 +0530, Kishon Vijay Abraham Iwrote:
> The PHY framework provides a set of APIs for the PHY drivers to
> create/destroy a PHY and APIs for the PHY users to obtain a reference to the
> PHY with or without using phandle. For dt-boot, the PHY drivers should
> also register
USB spec stats that short packet can only appear at the end
of transfer. Because lost of HC(EHCI/UHCI/OHCI/...) can't
build a full packet from discontinuous buffers, we introduce
the limit in usb_submit_urb() to avoid such kind of bad sg buffers
coming from driver.
The limit might be a bit strict:
There was a problem, the warning "Controller not stopped yet".
And your last patch for this problem does a wrong thing:
It prevents all HP uhci devices from auto-stop, which make HP uhci
devices waste more
power.
This is another new problem.
I think this should be corrected, so I want to apply
Control transfers have both IN and OUT (or SETUP) packets, so when
clearing TT buffers for a control transfer it's necessary to send
two HUB_CLEAR_TT_BUFFER requests to the hub.
Signed-off-by: William Gulland
---
drivers/usb/core/hub.c | 9 +
1 file changed, 9 insertions(+)
On Thu, Jun 27, 2013 at 11:56:13PM +0200, Tim Sander wrote:
> Hi Alan
> > > > > I have just written a ehci testing driver which enables the testing
> > > > > modes used for hw testing via a file in debugfs. This patch is for
> > > > > 3.4.47 not any usb branch. But if this driver is ready for main
Hi Alan
> > > > I have just written a ehci testing driver which enables the testing
> > > > modes used for hw testing via a file in debugfs. This patch is for
> > > > 3.4.47 not any usb branch. But if this driver is ready for mainline
> > > > i will be happy to port it to whatever branch you wish.
In a message of Wed, 26 Jun 2013 12:39:24 +0200, Johan Hovold writes:
>On Wed, Jun 26, 2013 at 10:29:59AM +0200, Anders Hammarquist wrote:
>> In a message of Tue, 25 Jun 2013 16:39:11 -0700, Greg KH writes:
>> >> Indeed. I'd already had some (failed) thoughts about how to handle it
>> >> nicely. No
Hi
On Thu, Jun 27, 2013 at 11:07:11PM +0300, Ruslan Bilovol wrote:
> On Thu, Jun 27, 2013 at 10:24 PM, Michael Trimarchi
> wrote:
> > Hi
> >
> > On Thu, Jun 27, 2013 at 09:59:35PM +0300, Ruslan Bilovol wrote:
> >> Hello guys,
> >>
> >> On Thu, Jun 27, 2013 at 8:56 PM, Michael Trimarchi
> >> wrot
On Thu, 27 Jun 2013 at 20:53, Frank Schäfer wrote:
Am 27.06.2013 19:14, schrieb Reinhard Max:
But the same datasheets also contain the statement I cited before,
that the baud rate generator can be programmed to *any* baud rate
between 75 and the limit of the respective chip.
Well, all I can
On Thu, Jun 27, 2013 at 10:24 PM, Michael Trimarchi
wrote:
> Hi
>
> On Thu, Jun 27, 2013 at 09:59:35PM +0300, Ruslan Bilovol wrote:
>> Hello guys,
>>
>> On Thu, Jun 27, 2013 at 8:56 PM, Michael Trimarchi
>> wrote:
>> > Hi Roger
>> >
>> > On Thu, Jun 27, 2013 at 05:49:41PM +0300, Roger Quadros wro
The USB_MAXCHILDREN symbol is used in include/uapi/linux/usb/ch11.h, a
user-mode header, even though it is defined in include/linux/usb.h,
which is kernel-only. This causes compile-time errors when user
programs try to #include linux/usb/ch11.h.
This patch fixes the problem by moving the definiti
Hi
On Thu, Jun 27, 2013 at 09:59:35PM +0300, Ruslan Bilovol wrote:
> Hello guys,
>
> On Thu, Jun 27, 2013 at 8:56 PM, Michael Trimarchi
> wrote:
> > Hi Roger
> >
> > On Thu, Jun 27, 2013 at 05:49:41PM +0300, Roger Quadros wrote:
> >> +Ruslan
> >>
> >> On 06/27/2013 05:17 PM, Michael Trimarchi wr
On Thu, Jun 27, 2013 at 09:11:36PM +0200, Bjørn Mork wrote:
> Johan Hovold writes:
>
> > Remove the vendor and product module parameters which were added a long
> > time ago when we did not have the dynamic sysfs interface to add new
> > device ids (and which isn't limited to a single new vid/pid
Johan Hovold writes:
> Remove the vendor and product module parameters which were added a long
> time ago when we did not have the dynamic sysfs interface to add new
> device ids (and which isn't limited to a single new vid/pid pair).
>
> A vid/pid pair can be added dynamically using sysfs, for e
Hello guys,
On Thu, Jun 27, 2013 at 8:56 PM, Michael Trimarchi
wrote:
> Hi Roger
>
> On Thu, Jun 27, 2013 at 05:49:41PM +0300, Roger Quadros wrote:
>> +Ruslan
>>
>> On 06/27/2013 05:17 PM, Michael Trimarchi wrote:
>> > Hi Roger
>> >
>> > On Thu, Jun 27, 2013 at 04:59:38PM +0300, Roger Quadros wro
Am 27.06.2013 19:14, schrieb Reinhard Max:
> Thanks for jumping in, Frank.
>
> Frank Schäfer writes:
>
>> I didn't read the whole thread yet, but what I can say for sure is that
>> the device I tested did _NOT_ support any non-standard baud rates.
> Then I'd be interested if it really was a PL2303
Ok. so I will prepare a patch for option instead. Thank you!
On Thu, 27 Jun 2013, Dan Williams wrote:
==Date: Thu, 27 Jun 2013 12:56:49 -0500
==From: Dan Williams
==To: Bj?rn Mork
==Cc: Enrico Mioso , linux-usb@vger.kernel.org,
==Greg Kroah-Hartman ,
==Johan Hovold , Richard Weinberge
On Thu, 27 Jun 2013, Manjunath Goudar wrote:
> Separate the W90X900(W90P910) on-chip host controller driver from
> ehci-hcd host code so that it can be built as a separate driver module.
> This work is part of enabling multi-platform kernels on ARM;
> however, note that other changes are still nee
Hi Roger
On Thu, Jun 27, 2013 at 05:49:41PM +0300, Roger Quadros wrote:
> +Ruslan
>
> On 06/27/2013 05:17 PM, Michael Trimarchi wrote:
> > Hi Roger
> >
> > On Thu, Jun 27, 2013 at 04:59:38PM +0300, Roger Quadros wrote:
> >> Hi Michael,
> >>
> >> On 06/27/2013 02:51 PM, Michael Trimarchi wrote:
>
On Thu, 2013-06-27 at 18:34 +0200, Bjørn Mork wrote:
> Enrico Mioso writes:
>
> > thank you for your help and incredible knowledge. I would never have
> > arrived to
> > this depth of details and conclusion.
> >
> > Effectively, it looks like a firmware for such a product, is practically a
> >
On Thu, 2013-06-27 at 16:12 +0200, Enrico Mioso wrote:
> Hi Bjorn and thank you very much for your kindness, attention and reply!
>
> Yes - I tested the all three ports of the device, even because my
> understanding
> of the Windows INF files is very primitive!
> And yes - I have verified that t
On Thu, 27 Jun 2013 at 19:25, Greg KH wrote:
None of those datasheets really help as they do not describe exactly
how to set the baud rates (or much anything else), so we can't rely
on them at all, sorry.
Come on, the configuration values for the documented baud rates are
exactly the 32bit i
On Thu, Jun 27, 2013 at 03:32:20PM +0200, Reinhard Max wrote:
> On Thu, 27 Jun 2013 at 07:17, Greg KH wrote:
>
> >On Wed, Jun 26, 2013 at 12:03:23PM +0200, Reinhard Max wrote:
> >
> >>OTOH, why should a driver impose such a limit at all [...]
> >
> >Because that's the way the driver has successful
Thanks for jumping in, Frank.
Frank Schäfer writes:
> I didn't read the whole thread yet, but what I can say for sure is that
> the device I tested did _NOT_ support any non-standard baud rates.
Then I'd be interested if it really was a PL2303X as you wrote in your
comment, because Prolific say
On Thu, 27 Jun 2013, victor yeo wrote:
> I find some clue. From USB 2.0 Compliance Test Spec, quoted:
>
> "Address State:
> 1. Put the device in the configured state following the procedure below.
> 2. Issue a valid Set Configuration command to the device with
> configuration value zero.
> 3.
On Thu, 27 Jun 2013, Tim Sander wrote:
> Hi Alan
> > > I have just written a ehci testing driver which enables the testing modes
> > > used for hw testing via a file in debugfs. This patch is for 3.4.47 not
> > > any usb branch. But if this driver is ready for mainline i will be happy
> > > to po
On 06/26/13 23:58, Felipe Balbi wrote:
> On Wed, Jun 26, 2013 at 02:52:56PM -0700, Stephen Boyd wrote:
>> Hi,
>>
>> I'm getting the folllowing BUG message on bootup with 3.10-rc5
>>
>> BUG: sleeping function called from invalid context at mm/slub.c:926
>> in_atomic(): 1, irqs_disabled(): 128, pid:
Enrico Mioso writes:
> thank you for your help and incredible knowledge. I would never have arrived
> to
> this depth of details and conclusion.
>
> Effectively, it looks like a firmware for such a product, is practically a
> collage. The complexity is so high, so many parts of the code aren't
On 06/27/2013 01:20 AM, Mikko Perttunen wrote:
> On Wed, 26 Jun 2013 20:14:35 +0300, Stephen Warren
> wrote:
>
>> On 06/26/2013 03:59 AM, Mikko Perttunen wrote:
>>> After this patch, usb vbus regulators for tegra usb phy devices can
>>> be specified
>>> with the device tree attribute vbus-supply
body {height: 100%; color:#00; font-size:12pt;
font-family:Arial;}
--
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
thank you for your help and incredible knowledge. I would never have arrived to
this depth of details and conclusion.
Effectively, it looks like a firmware for such a product, is practically a
collage. The complexity is so high, so many parts of the code aren't provided
even to manufacturers an
On Thu, 27 Jun 2013, Li, Zhen-Hua (USL-China) wrote:
> Hi Alan,
>
> I don't have a machine that this makes action different.
Then why do you want to apply the patch?
> No matter whether it makes different, there is one thing will never change:
> We create a patch to FIX a problem, not to avoid
Sorry - I sent the mail in private by mistake.
Re-sending in the list...
Hey - there must be something like telepathy between us!!
Infact it is - playing with the driver - I can obtain the new port for the
interface.
Script started on Thu Jun 27 17:48:17 2013
mrkiko@eeeadesso:/mnt/sd/sdfiles/hu
On Wed, 26 Jun 2013, Mariusz Grecki wrote:
> The problem relates directly to the old one:
>
> http://thread.gmane.org/gmane.linux.usb.general/20816/focus=20850
>
> The problem is, that usually (in fact all the time with one! exception
> so far) the card is recognized by operating system as a ful
Enrico Mioso writes:
> Hi Bjorn and thank you very much for your kindness, attention and reply!
>
> Yes - I tested the all three ports of the device, even because my
> understanding
> of the Windows INF files is very primitive!
> And yes - I have verified that the device doesn't correspond to a
On Wed, 26 Jun 2013, Roger Quadros wrote:
> > Could the mapping be changed so that a different interrupt vector was
> > used for wakeups and normal I/O? That would make this a little easier,
> > although it wouldn't solve the general problem.
>
> I'm not sure which IRQ we can map it to, but it
On Wed, Jun 26, 2013 at 10:43:39PM +0200, Mariusz Grecki wrote:
> The problem relates directly to the old one:
>
> http://thread.gmane.org/gmane.linux.usb.general/20816/focus=20850
>
> The problem is, that usually (in fact all the time with one! exception
> so far) the card is recognized by opera
Separate the W90X900(W90P910) on-chip host controller driver from
ehci-hcd host code so that it can be built as a separate driver module.
This work is part of enabling multi-platform kernels on ARM;
however, note that other changes are still needed before W90X900(W90P910)
can be booted with a multi
Am 27.06.2013 15:32, schrieb Reinhard Max:
> On Thu, 27 Jun 2013 at 07:17, Greg KH wrote:
>
>> On Wed, Jun 26, 2013 at 12:03:23PM +0200, Reinhard Max wrote:
>>
>>> OTOH, why should a driver impose such a limit at all [...]
>>
>> Because that's the way the driver has successfully worked for the
>> p
+Ruslan
On 06/27/2013 05:17 PM, Michael Trimarchi wrote:
> Hi Roger
>
> On Thu, Jun 27, 2013 at 04:59:38PM +0300, Roger Quadros wrote:
>> Hi Michael,
>>
>> On 06/27/2013 02:51 PM, Michael Trimarchi wrote:
>>> Hi
>>>
>>> I'm working on omap4460 with two ulpi connected to (SMSC3320 -> HUB
>>> SMSC
On Wed, 26 Jun 2013, Ming Lei wrote:
> USB spec stats that short packet can only appear at the end
> of transfer. Because lost of HC(EHCI/UHCI/OHCI/...) can't
> build a full packet from discontinuous buffers, we introduce
> the limit in usb_submit_urb() to avoid such kind of bad sg buffers
> comin
Add support for the ONYX 3G device, a Qualcomm MSM-based product.
Signed-off-by: Enrico Mioso
diff --git a/drivers/usb/serial/qcserial.c b/drivers/usb/serial/qcserial.c
index bd794b4..bba2fc0 100644
--- a/drivers/usb/serial/qcserial.c
+++ b/drivers/usb/serial/qcserial.c
@@ -133,6 +133,9 @@ stati
Hi Roger
On Thu, Jun 27, 2013 at 04:59:38PM +0300, Roger Quadros wrote:
> Hi Michael,
>
> On 06/27/2013 02:51 PM, Michael Trimarchi wrote:
> > Hi
> >
> > I'm working on omap4460 with two ulpi connected to (SMSC3320 -> HUB
> > SMSC2514) or (TUSB1210 -> HUB SMSC2514).
> > The problem only happen
Hi Bjorn and thank you very much for your kindness, attention and reply!
Yes - I tested the all three ports of the device, even because my understanding
of the Windows INF files is very primitive!
And yes - I have verified that the device doesn't correspond to any of the goby
layouts, even if I
Hi Michael,
On 06/27/2013 02:51 PM, Michael Trimarchi wrote:
> Hi
>
> I'm working on omap4460 with two ulpi connected to (SMSC3320 -> HUB SMSC2514)
> or (TUSB1210 -> HUB SMSC2514).
> The problem only happen when both port are used and after few suspend resume
> are triggered.
> If I use just o
Hi Peter,
> > No, I don't have this one available right now. I tried both MX23
> > Olinuxino maxi
> > (I just mutilated the board so that I cut traces to the USB devices on
> > the board
> > and routed out USB gadget connector) and a custom MX23 board.
> >
> > Note that both have working USB peri
On Thu, 27 Jun 2013 at 07:17, Greg KH wrote:
On Wed, Jun 26, 2013 at 12:03:23PM +0200, Reinhard Max wrote:
OTOH, why should a driver impose such a limit at all [...]
Because that's the way the driver has successfully worked for the
past 10+ years?
Well, this particular part was added less
On Thu, 27 Jun 2013 at 15:32, Reinhard Max wrote:
(a PL2303HX as per the comment)
Sorry, I meant PL2303X.
cu
Reinhard
--
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.kerne
On Thu, Jun 27, 2013 at 01:23:59PM +0200, Benoit Cousson wrote:
> Hi Sebastian,
>
> On 06/26/2013 05:33 PM, Sebastian Andrzej Siewior wrote:
> > I've been thinkig about creating two child nodes for the independent musb
> > controllers on the am33. I've been thinking about the following:
> >
> > d
Hello.
On 27-06-2013 3:30, Greg Kroah-Hartman wrote:
Use the pr_* calls instead, which are much more descriptive.
Signed-off-by: Greg Kroah-Hartman
---
drivers/usb/misc/adutux.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/misc/adutux.c b
Hi
I'm working on omap4460 with two ulpi connected to (SMSC3320 -> HUB SMSC2514)
or (TUSB1210 -> HUB SMSC2514).
The problem only happen when both port are used and after few suspend resume
are triggered.
If I use just one port there is no issue on suspend resume. I already covered
all TI
errat
On 06/27/2013 01:23 PM, Benoit Cousson wrote:
> Hi Sebastian,
Hi Benoit,
> BTW, why do have so many DMA compared to the previous version?
I added them, the previous had none and is PIO only.
I currently use three cells per dma channel (the posted example had
two).
In general I think I have to req
Hi Sebastian,
On 06/26/2013 05:33 PM, Sebastian Andrzej Siewior wrote:
> I've been thinkig about creating two child nodes for the independent musb
> controllers on the am33. I've been thinking about the following:
>
> diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
> in
Enrico Mioso writes:
> Hi guys!
> I can confirm the setup is correct - and even the NMEA interface is working
> properly!
> So that - with this small modem, now it's possible to make and receive voice
> calls. So I think this patch should be applied.
>
> Can somebody give some feedback?
The pa
Hi guys!
I can confirm the setup is correct - and even the NMEA interface is working
properly!
So that - with this small modem, now it's possible to make and receive voice
calls. So I think this patch should be applied.
Can somebody give some feedback?
On Mon, 24 Jun 2013, Enrico Mioso wrote:
dev_warn() is preferred over pr_warning().
container_of() is used to get usb_driver pointer from usbip_device container
(stub_device or vhci_device), to get device structure required for dev_warn().
Signed-off-by: navin patidar
---
drivers/staging/usbip/usbip_event.c | 11 ++-
1 file
I tested with the AX88179 usb dongle, if without .reset_resume hook,
after S3/S4 resume you have to enable network interface or reload the
dirver module manually otherwise the network interface can not work.
Signed-off-by: David Chang
---
drivers/net/usb/ax88179_178a.c | 1 +
1 file changed, 1
Correct a typo in description of driver_info, it should be Gigabit
Signed-off-by: David Chang
---
drivers/net/usb/ax88179_178a.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/usb/ax88179_178a.c b/drivers/net/usb/ax88179_178a.c
index bd8758f..7ce243b 100644
Hi,
> You should not be concerned about variables in the gadget driver. The
> problem is in the UDC driver.
>
> For some examples of what the UDC driver needs to do, look at
> handle_control_request() in drivers/usb/gadget/dummy_hcd.c or the
> "switch (u.r.bRequest)" statement of handle_stat0_irq
On 06/26/2013 08:51 PM, Stephen Warren wrote:
On 06/26/2013 06:34 AM, Mikko Perttunen wrote:
UTMIP parameters used to be hardcoded into tables in the
PHY driver. This patch reads them from the device tree instead
in accordance with the phy-tegra-usb DT documentation.
This looks fine, although
Hi,
On Thu, Jun 27, 2013 at 09:31:34AM +0200, Sebastian Andrzej Siewior wrote:
> > the patch is alright, but what about the giant amoutn of function
> > pointers we have ? Are you planning to use of_dev_auxdata ??
>
> I didn't plan to use of_dev_auxdata. What do you mean by "giant amount
> of fu
Hi Alan
> > I have just written a ehci testing driver which enables the testing modes
> > used for hw testing via a file in debugfs. This patch is for 3.4.47 not
> > any usb branch. But if this driver is ready for mainline i will be happy
> > to port it to whatever branch you wish.
>
> It's not c
On 06/27/2013 08:51 AM, Felipe Balbi wrote:
> Hi,
Hi Felipe,
> the patch is alright, but what about the giant amoutn of function
> pointers we have ? Are you planning to use of_dev_auxdata ??
I didn't plan to use of_dev_auxdata. What do you mean by "giant amount
of function pointers"?
Sebastia
Hi,
On Thu, Jun 27, 2013 at 09:24:08AM +0200, Michael Grzeschik wrote:
> > > > > right, but in DT you will define both instances and each instance will
> > > > > have a seaparate snps,maximum_speed attribute :-)
> > > > >
> > > > > I'm now considering if we should make maximum_speed a generic
> >
That driver hasn't been really maintained for
a long time. It doesn't compile in any way, it
includes non-existent headers, has no users,
and is just plain broken.
The person who used to work with that driver
has publicly stated that he has no plans to
touch that driver again and is ok with remova
Hi,
On Thu, Jun 27, 2013 at 09:35:26AM +0300, Felipe Balbi wrote:
> Hi,
>
> On Thu, Jun 27, 2013 at 08:14:16AM +0200, Michael Grzeschik wrote:
> > > > right, but in DT you will define both instances and each instance will
> > > > have a seaparate snps,maximum_speed attribute :-)
> > > >
> > > > I
On Wed, 26 Jun 2013 20:14:35 +0300, Stephen Warren
wrote:
On 06/26/2013 03:59 AM, Mikko Perttunen wrote:
After this patch, usb vbus regulators for tegra usb phy devices can be
specified
with the device tree attribute vbus-supply = <&x> where x is a
regulator defined
in the device tree.
70 matches
Mail list logo
