headers
Greg KH | 1 Feb 2009 05:47
Gravatar

Re: serial.h: nano-doc outdated

On Sat, Jan 31, 2009 at 10:00:53PM +0100, Wolfram Sang wrote:
> Hello,
> 
> while looking for some nano-doc references today, I stumbled over
> include/linux/usb/serial.h. At least commit
> 95da310e66ee8090119596c70ca8432e57f9a97f changed a few members of the
> struct usb_serial_port, but the nano-doc description has not been
> updated accordingly. Having never dealt with the topic itself, I thought
> it is best if I just file this short report.

It would be even better if you could send a patch, as per
Documentation/SubmittingPatches fixing up the information :)

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Oliver Neukum | 1 Feb 2009 11:17

Re: [PATCH]suspend/resume support for option driver

Am Saturday 31 January 2009 16:35:17 schrieb Alexey Klimov:
> Hello, Oliver
> 
> Sorry for asking this question.

No problem. Questions should be asked.

> >  	} else
> > -		dbg("%s: error %d", __func__, status);
> > +		err("%s: error %d", __func__, status);
> 
> Do your patch use err macros defined in usb.h ?

Yes.

> If yes, probably it's better to avoid using it, because this interface
> may become deprecated. Anyway, Greg should know sitation better.
> If no, sorry for bothering.

They may become obsolete. Then somebody needs to go through
the driver to replace them. Until then, I prefer to keep the driver
uniform in that regard. The patch does what it says it does, nothing
else.

> Hmmm, btw CodingStyle wants that you place bracers in else section too.
> Like this: 
> 
> > -	} else
> > +	} else {
> > -		dbg("%s: error %d", __func__, status);
(Continue reading)

Permalink | Reply | 0 comments |
headers
Oliver Neukum | 1 Feb 2009 11:20

Re: [rft]autosuspend for option driver (resend)

Am Saturday 31 January 2009 16:45:24 schrieb Alexey Klimov:
> Why don't turn supports_autosuspend off ?
> 
> Like: .supports_autosuspend = 0
> Is it worse ?

It's the default, so why bother? In fact, that would hurt.
Currently, I can grep for "autosuspend" and see which drivers
in a directory support it.

	Regards
		Oliver

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Dave Young | 1 Feb 2009 11:53
Picon

[PATCH 1/2] usb-serial : fix the nousb oops


In case with "nousb" booting, serial drivers will trigger kernel oops.

Here add usb_disabled() check in usb_serial_init and usb_serial_register

Signed-off-by: Dave Young <hidave.darkstar@...>
---
drivers/usb/serial/usb-serial.c |    6 ++++++
1 file changed, 6 insertions(+)

diff -uprN a/drivers/usb/serial/usb-serial.c b/drivers/usb/serial/usb-serial.c
--- a/drivers/usb/serial/usb-serial.c	2009-02-01 13:11:11.000000000 +0800
+++ b/drivers/usb/serial/usb-serial.c	2009-02-01 13:24:32.000000000 +0800
 <at>  <at>  -1113,6 +1113,9  <at>  <at>  static int __init usb_serial_init(void)
 	int i;
 	int result;

+	if (usb_disabled())
+		return -ENODEV;
+
 	usb_serial_tty_driver = alloc_tty_driver(SERIAL_TTY_MINORS);
 	if (!usb_serial_tty_driver)
 		return -ENOMEM;
 <at>  <at>  -1230,6 +1233,9  <at>  <at>  int usb_serial_register(struct usb_seria
 	/* must be called with BKL held */
 	int retval;

+	if (usb_disabled())
+		return -ENODEV;
+
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dave Young | 1 Feb 2009 11:54
Picon

[PATCH 2/2] usb-serial: fix the aircable_init failure path


The failure path of aircable_init is wrong, fix the order of (goto) labels.

Signed-off-by: Dave Young <hidave.darkstar@...>
---
drivers/usb/serial/aircable.c |    4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff -uprN a/drivers/usb/serial/aircable.c b/drivers/usb/serial/aircable.c
--- a/drivers/usb/serial/aircable.c	2009-02-01 13:12:35.000000000 +0800
+++ b/drivers/usb/serial/aircable.c	2009-02-01 13:26:28.000000000 +0800
 <at>  <at>  -621,9 +621,9  <at>  <at>  static int __init aircable_init(void)
 		goto failed_usb_register;
 	return 0;

-failed_serial_register:
-	usb_serial_deregister(&aircable_device);
 failed_usb_register:
+	usb_serial_deregister(&aircable_device);
+failed_serial_register:
 	return retval;
 }

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Sergei Shtylyov | 1 Feb 2009 14:47

Re: [PATCH 2/3] MUSB : Fix for DaVinci CPPI DMA incorrect handling of actual_len field

Hello.

Felipe Balbi wrote:

>> ... but that implies a substantial cleanup of the DMA paths,
>> and I'll be content to defer such only-one-place cleanup until
>> that happens.
>>     
>
> for sure today's code is really messy. All those ifs and ifdefery to
> check which dma we're using look awful...
>   
>> To summarize, musb_hdrc has four basic DMA paths today, the
>> cross product of {RX, TX} and {host, gadget}, each of which
>> looks more or less like
>>
>> 	if (cppi/davinci)
>> 		do this
>> 	else if (omap native/TUSB)
>> 		do that
>> 	else if (mentor's DMA)
>> 		do something else
>>     
>
> ... I'm trying to move that to something like:
>
> if (use_dma)
> 	do_this();
> else
> 	do_pio();
(Continue reading)

Permalink | Reply | 10 comments |
headers
Greg KH | 1 Feb 2009 16:51
Gravatar

Re: [PATCH 1/2] usb-serial : fix the nousb oops

On Sun, Feb 01, 2009 at 06:53:23PM +0800, Dave Young wrote:
> 
> In case with "nousb" booting, serial drivers will trigger kernel oops.

They will?  What is the oops message?

> Here add usb_disabled() check in usb_serial_init and usb_serial_register

This is odd, is it something new?  Why is usb-serial the only driver
that needs such a thing?

confused,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Sergei Shtylyov | 1 Feb 2009 21:10

Re: [PATCH 2/3] MUSB : Fix for DaVinci CPPI DMA incorrect handling of actual_len field

Hello, I wrote:

>>> ... but that implies a substantial cleanup of the DMA paths,
>>> and I'll be content to defer such only-one-place cleanup until
>>> that happens.

>> for sure today's code is really messy. All those ifs and ifdefery to
>> check which dma we're using look awful...

>>> To summarize, musb_hdrc has four basic DMA paths today, the
>>> cross product of {RX, TX} and {host, gadget}, each of which
>>> looks more or less like

>>>     if (cppi/davinci)
>>>         do this
>>>     else if (omap native/TUSB)
>>>         do that
>>>     else if (mentor's DMA)
>>>         do something else

>> ... I'm trying to move that to something like:

>> if (use_dma)
>>     do_this();
>> else
>>     do_pio();

>   I'm also not sure it's a good idea to handle DMA compeltion by calling 
> musb_host_[rt]x() -- IMHO, having a separate DMA completion handling 
> functions would lead to a cleaner code...
(Continue reading)

Permalink | Reply | 8 comments |
headers
Felipe Balbi | 1 Feb 2009 23:49

Re: [PATCH 2/3] MUSB : Fix for DaVinci CPPI DMA incorrect handling of actual_len field

On Sun, Feb 01, 2009 at 11:10:53PM +0300, Sergei Shtylyov wrote:
>>   CPPI basically fails now with the bulk transfers, at least under the  
>> high load -- the patch is coming... I don't feel sure but looking at 
>> the Inventra DMA code it seems that it might have the same issue when 
>> using DMA mode 1 -- I don't see where it clears TXCSR.DMAReqMode bit if 
>> it decides to set TxPktRdy instead of calling musb_dma_completion(), so 
>> it should never be getting another interrupt on TxPktRdy = 0...
>
>    Ah, it implicitly clears DMA bits by writing only 
> MUSB_TXCSR_TXPKTDRY... but that violates the programming guide then which 
> says that DMAReq{Enab|Mode} can't be cleared at once -- DMAReqMode must 
> always be cleared after DMAReqEnab.

There's another thing I'm experimenting with... Taking musb_gadget.c as
example, I'm setting correct [RT}XCSR registers on musb_gadget_enable()
time, meaning that DMAReqEnab and DMAReqMode would be set there and
never touched again.

It seems to work for gadget side. So I just have to play with
[RT]XPKTRDY bit.

I still have some glitches but seems that we don't have to keep
enabling/disabling DMA bits in [RT]XCSR registers. Still need some more
experimentation to see until when will that really work or if it's
working due to some strange scenario I'm always in.

--

-- 
balbi
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
(Continue reading)

Permalink | Reply | 6 comments |
headers
Qiuping Chen | 2 Feb 2009 02:07
Picon

Re: [PATCH v4] usb: add Intel Poulsbo USB client controller driver [IUSBC]

It cannot pass some subtests in test #10 of test.sh. It can pass ping
stress test.

OK to change "Intel USB Client Controller" to "Intel Poulsbo USB
Client Controller". The latter is better. Should I re-submit the patch
with this change?

On Mon, Jan 26, 2009 at 5:31 AM, David Brownell <david-b@...> wrote:
> On Thursday 08 January 2009, Qiuping Chen wrote:
>>  The tests passed include:
>>  - hotplug, with and without hubs.
>>  - g_file_storage: file copying for 12 hours at full speed and high
>>                         speed.
>>  - g_file_storage: USBCV chap9 tests.
>>  - g_file_storage: USBCV MSC tests.
>>  - g_ether: scp files for 12 hours at full speed and high speed.
>>  - g_ether: USBCV chap9 tests.
>
> That's good basic coverage; it means the main code paths
> are behaving well.
>
> How does it do on http://www.linux-usb.org/usbtest/#gadgets
> test scripts?  That is, run "test.sh" with a Linux host.
>
> The usual problem is that while test #9 works OK (hard for
> it to fail if USBCV ch9 passes), test #10 turns up races in
> fault handling paths for control transfers.  You should be
> able to run "test.sh control" overnight, too.  (USBCV was
> clearly not intended to include stress tests modes.)
>
(Continue reading)

Permalink | Reply | 5 comments |

Gmane