headers
Oliver Neukum | 1 Aug 2009 01:00

Re: Autosuspend for mass storage?

Am Samstag, 1. August 2009 00:01:27 schrieb Sarah Sharp:
> Hi Oliver,
Hello,

> I know you worked on several versions of a mass storage device
> autosuspend patch.

For the discussion I am attaching what I found in my archives.
It is a bit incomplete in hindsight. We should definitely do autopm_get
in the open methods of sg and st.
Be careful they surprised Alan and maybe caused convultions.

	Regards
		Oliver

--

--- a/drivers/usb/storage/usb.c	2007-09-27 13:33:31.000000000 +0200
+++ b/drivers/usb/storage/usb.c	2007-09-27 13:30:21.000000000 +0200
 <at>  <at>  -182,33 +182,100  <at>  <at>  static struct us_unusual_dev us_unusual_
 
 static int storage_suspend(struct usb_interface *iface, pm_message_t message)
 {
+	struct device *child;
 	struct us_data *us = usb_get_intfdata(iface);
+	struct Scsi_Host *host = us_to_host(us);
+	struct scsi_device *sdev, *sdev2 = NULL;
+	int err = 0;
+
+	/* In case of autosuspend we need to do extra work to flush
(Continue reading)

Permalink | Reply | 1 comment |
headers
Robin Callender | 1 Aug 2009 03:05
Picon
Favicon

[PATCH] usb gadget audio driver seg-fault fix

Hi all,
The included patch can be applied to the new usb gadget audio driver 
introduced in patch-2.6.31-rc4.
It addresses a seg-fault in uncovered in g_audio.ko.
The fault occurs in the function u_audio.c::gaudio_open_end_dev() when 
device /dev/snd/pcmC0D0c (FILE_PCM_CAPTURE) is not present.

I suspect there may be similar problems with device /dev/snd/pcmC0D0p 
(FILE_PCM_PLAYBACK) handling also.
I leave that for the developer(s), as I was unsure as to the side-effects of 
not calling playback_default_hw_params() in the initialization phase.

 - Robin Callender -

======================================================

diff -r linux-2.6.30.4.orig/drivers/usb/gadget/u_audio.c 
linux-2.6.30.4/drivers/usb/gadget/u_audio.c
256c256,261
<   snd->filp = NULL;
---
>   snd->substream = NULL;
>   snd->card = NULL;
>  } else {
>   pcm_file = snd->filp->private_data;
>   snd->substream = pcm_file->substream;
>   snd->card = card;
258,260d262
<  pcm_file = snd->filp->private_data;
<  snd->substream = pcm_file->substream;
(Continue reading)

Permalink | Reply | 502 comments |
headers
Alan Stern | 1 Aug 2009 03:54
Picon
Favicon

Re: Autosuspend for mass storage?

On Sat, 1 Aug 2009, Oliver Neukum wrote:

> Am Samstag, 1. August 2009 00:01:27 schrieb Sarah Sharp:
> > Hi Oliver,
> Hello,
> 
> > I know you worked on several versions of a mass storage device
> > autosuspend patch.
> 
> Alan wrote them, Pavel and I tried to finish them.

There were several different proposed kinds of autosuspend for USB mass 
storage.  None of them proved to be sufficiently safe and acceptable to 
the community.

> > ISTR that they got dropped because the USB core
> > turned on autosuspend by default and some USB MSDs with spinning disks
> > didn't park their heads when they were told to suspend.  Were there
> > any other problems with the patches?
> 
> Yes, they basically come down to enclosures cutting power to the devices.
> This means
> - the cache in the drive is lost
> - any setting local to the drive might be lost
> 
> > I'm wondering if now that userspace has to enable autosuspend if we can
> > get away with re-adding those patches.
> 
> This is basically a judgement call. How much damage is acceptable if
> autosuspend is activated on a device that can't handle it?
(Continue reading)

Permalink | Reply | 13 comments |
headers
Alan Stern | 1 Aug 2009 03:56
Picon
Favicon

Re: Autosuspend for mass storage?

On Sat, 1 Aug 2009, Oliver Neukum wrote:

> Am Samstag, 1. August 2009 00:01:27 schrieb Sarah Sharp:
> > Hi Oliver,
> Hello,
> 
> > I know you worked on several versions of a mass storage device
> > autosuspend patch.
> 
> For the discussion I am attaching what I found in my archives.
> It is a bit incomplete in hindsight. We should definitely do autopm_get
> in the open methods of sg and st.

And don't forget the SCSI error handler.

> Be careful they surprised Alan and maybe caused convultions.

"Surprised" isn't quite the right word.  :-)

This patch had the substantial drawback of doing a ton of work in 
usb-storage which really ought to be done within the SCSI layer.

Alan Stern

--
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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Greg KH | 1 Aug 2009 05:42
Gravatar

Re: [PATCH] usb gadget audio driver seg-fault fix

On Fri, Jul 31, 2009 at 06:05:24PM -0700, Robin Callender wrote:
> Hi all,
> The included patch can be applied to the new usb gadget audio driver 
> introduced in patch-2.6.31-rc4.
> It addresses a seg-fault in uncovered in g_audio.ko.
> The fault occurs in the function u_audio.c::gaudio_open_end_dev() when 
> device /dev/snd/pcmC0D0c (FILE_PCM_CAPTURE) is not present.
> 
> I suspect there may be similar problems with device /dev/snd/pcmC0D0p 
> (FILE_PCM_PLAYBACK) handling also.
> I leave that for the developer(s), as I was unsure as to the side-effects of 
> not calling playback_default_hw_params() in the initialization phase.
> 
>  - Robin Callender -
> 
> ======================================================
> 
> diff -r linux-2.6.30.4.orig/drivers/usb/gadget/u_audio.c 
> linux-2.6.30.4/drivers/usb/gadget/u_audio.c
> 256c256,261
> <   snd->filp = NULL;

Hm, can you redo this patch based on the info in the file,
Documentation/SubmittingPatches which shows the needed options to diff
(-u is the key), as well as the need for a Signed-off-by: line in the
body of the email so that it can be applied?

thanks,

greg k-h
(Continue reading)

Permalink | Reply | 502 comments |
headers
Viral Mehta | 1 Aug 2009 06:46

Re: urb packetizing


> Any chance to see your driver source code?
>   
Well, I do not mind. But, the decision entirely lies with my manager and 
he might be dependent on our customer.
And I have an NDA so :(

But, i am yet in feasibility cum design phase and what i m trying to 
code is not present in kernel yet or i hv not yet discovered. Related to 
DivX.
I will try my best to get it open sourced in a hope to 
give-back/contribute something.
> 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
>
>
> Email Scanned for Virus & Dangerous Content by : www.CleanMailGateway.com
>
>
>   
--

-- 
_____________________________________________________________________
Disclaimer: This e-mail message and all attachments transmitted with it
are intended solely for the use of the addressee and may contain legally
privileged and confidential information. If the reader of this message
(Continue reading)

Permalink | Reply | 0 comments |
headers
Robin Callender | 1 Aug 2009 07:02
Picon
Favicon

Re: [PATCH] usb gadget audio driver seg-fault fix

----- Original Message ----- 
From: "Greg KH" <greg@...>
To: "Robin Callender" <robin_callender@...>
Cc: "linux-usb" <linux-usb@...>
Sent: Friday, July 31, 2009 8:42 PM
Subject: Re: [PATCH] usb gadget audio driver seg-fault fix

> On Fri, Jul 31, 2009 at 06:05:24PM -0700, Robin Callender wrote:
>> Hi all,
>> The included patch can be applied to the new usb gadget audio driver
>> introduced in patch-2.6.31-rc4.
>> It addresses a seg-fault in uncovered in g_audio.ko.
>> The fault occurs in the function u_audio.c::gaudio_open_end_dev() when
>> device /dev/snd/pcmC0D0c (FILE_PCM_CAPTURE) is not present.
>>
>> I suspect there may be similar problems with device /dev/snd/pcmC0D0p
>> (FILE_PCM_PLAYBACK) handling also.
>> I leave that for the developer(s), as I was unsure as to the side-effects 
>> of
>> not calling playback_default_hw_params() in the initialization phase.
>>
>>  - Robin Callender -
>>
>> ======================================================
>>
>> diff -r linux-2.6.30.4.orig/drivers/usb/gadget/u_audio.c
>> linux-2.6.30.4/drivers/usb/gadget/u_audio.c
>> 256c256,261
>> <   snd->filp = NULL;
>
(Continue reading)

Permalink | Reply | 3 comments |
headers
Arjan van de Ven | 1 Aug 2009 07:15
Picon

Re: Autosuspend for mass storage?

Alan Stern wrote:
> On Sat, 1 Aug 2009, Oliver Neukum wrote:
> 
>> Am Samstag, 1. August 2009 00:01:27 schrieb Sarah Sharp:
>>> Hi Oliver,
>> Hello,
>>
>>> I know you worked on several versions of a mass storage device
>>> autosuspend patch.
>> Alan wrote them, Pavel and I tried to finish them.
> 
> There were several different proposed kinds of autosuspend for USB mass 
> storage.  None of them proved to be sufficiently safe and acceptable to 
> the community.
> 

fwiw the device I care about most is a SD card reader, and most of all,
when there is no card in the device.

--
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 | 3 comments |
headers
Oliver Neukum | 1 Aug 2009 10:51

Re: Autosuspend for mass storage?

Am Samstag, 1. August 2009 03:54:04 schrieb Alan Stern:
> On Sat, 1 Aug 2009, Oliver Neukum wrote:

> > This is basically a judgement call. How much damage is acceptable if
> > autosuspend is activated on a device that can't handle it?
> > We felt that filesystem corruption is beyond the pale in any case.
>
> Add to this the fact that the kernel can't tell whether a particular
> drive will lose its cached data when it is suspended.

Exactly. The scsi layer leaves this to user space with sysfs attributes.
This however raises the point whether the storage driver need be more
saintly than scsi itself.

> > The data loss issue can be solved, but it can't be easily solved cleanly.
> > An implementation to do it the dirty way existed. Alan and I differed on
> > accepatibility.
> > But I never managed to find a solution to vendor specific commands over
> > sd. The possibility to run generic commands over sd is a nightmare from
>
> Don't you mean generic commands over _sg_?

No, specifically and at that time surprisingly, sd.
sd_ioctl() is the problem. sg has nice semantics with open/close
With sg you get a pm reference when you open and drop it when you
close. sd is the problem.

> > a pm viewpoint. I was forced to disable autosuspend in literally more
> > than a dozen points and sometimes permanently. And it took heavy surgery
> > to the SCSI layer. It was hopeless.
(Continue reading)

Permalink | Reply | 8 comments |
headers
Oliver Neukum | 1 Aug 2009 10:54

Re: Autosuspend for mass storage?

Am Samstag, 1. August 2009 07:15:44 schrieb Arjan van de Ven:
> > There were several different proposed kinds of autosuspend for USB mass
> > storage.  None of them proved to be sufficiently safe and acceptable to
> > the community.
>
> fwiw the device I care about most is a SD card reader, and most of all,
> when there is no card in the device.

This is going to be fun. USB storage devices are usually polled to notice
media insertion. Haldemon does it every 3 seconds or so. Do you know the
people who are designing that infrastructure?

	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 |

Gmane