> > autosuspend. It's not supposed to work by the higher level announcing:
> > "I want to autosuspend now, so all you lower guys had better get
> > ready."
>
> I see. And there's an appealing simplicity to it. But why insist that
> this is the one true way?
I was unaware there was another defin
On Sat, 29 Sep 2007, Oliver Neukum wrote:
> > autosuspend. It's not supposed to work by the higher level announcing:
> > "I want to autosuspend now, so all you lower guys had better get
> > ready."
>
> I see. And there's an appealing simplicity to it. But why insist that
> this is the one true
Am Samstag 29 September 2007 schrieb Alan Stern:
> I disagree. That bug report shows that problems arise when we try to
> suspend a parent without making sure the children are suspended first.
> If the sd suspend method had already run then it would have been okay
> for the enclosure to cut powe
On Sat, 29 Sep 2007, Oliver Neukum wrote:
> > I don't know what that's supposed to mean. And whatever that means, it
> > must be equally true that usb-storage doesn't know CD drives. Or disk
> > drives, or flash memories, or SCSI tape drives, or ... On the whole,
> > I'd say that usb-storage's
Am Samstag 29 September 2007 schrieb Alan Stern:
> On Fri, 28 Sep 2007, Oliver Neukum wrote:
>
> > Am Freitag 28 September 2007 schrieb Alan Stern:
> > > On Fri, 28 Sep 2007, Oliver Neukum wrote:
> I don't know what that's supposed to mean. And whatever that means, it
> must be equally true that
On Fri, 28 Sep 2007, Oliver Neukum wrote:
> Am Freitag 28 September 2007 schrieb Alan Stern:
> > On Fri, 28 Sep 2007, Oliver Neukum wrote:
> >
> > > Am Donnerstag 27 September 2007 schrieb Alan Stern:
> > > > There's also a philosophical objection. Who is in a better position to
> > > > judge wh
Am Samstag 29 September 2007 schrieb Alan Stern:
> On Fri, 28 Sep 2007, Oliver Neukum wrote:
>
> > Unless I am very mistaken, further down in storage_suspend, I call
> >
> > + /* In case of autosuspend device must be unblocked again */
> > + if (us->pusb_dev->auto_pm) {
> > +err_unblock:
> >
On Fri, 28 Sep 2007, Oliver Neukum wrote:
> Unless I am very mistaken, further down in storage_suspend, I call
>
> + /* In case of autosuspend device must be unblocked again */
> + if (us->pusb_dev->auto_pm) {
> +err_unblock:
> + shost_for_each_device(sdev, host) {
> +
Am Freitag 28 September 2007 schrieb Alan Stern:
> On Fri, 28 Sep 2007, Oliver Neukum wrote:
>
> > Am Donnerstag 27 September 2007 schrieb Alan Stern:
> > > Have you thought about how autoresume would fit into this picture? I
> > > don't think you can rely on usb-storage telling the SCSI core to
Am Freitag 28 September 2007 schrieb Alan Stern:
> On Fri, 28 Sep 2007, Oliver Neukum wrote:
>
> > Am Donnerstag 27 September 2007 schrieb Alan Stern:
> > > There's also a philosophical objection. Who is in a better position to
> > > judge when a device like a SCSI drive should be autosuspended:
On Fri, 28 Sep 2007, Oliver Neukum wrote:
> Am Donnerstag 27 September 2007 schrieb Alan Stern:
> > Have you thought about how autoresume would fit into this picture? I
> > don't think you can rely on usb-storage telling the SCSI core to resume
> > devices when it gets handed a command, because t
On Fri, Sep 28, 2007 at 09:02:45AM +0200, Oliver Neukum wrote:
> Am Freitag 28 September 2007 schrieb Greg KH:
> > On Tue, Sep 25, 2007 at 05:11:00PM +0200, Oliver Neukum wrote:
> > >
> > > PS: Whoever designed klists is suffering from a case of
> > > overengineeringosis.
> >
> > No objection fr
On Fri, 28 Sep 2007, Oliver Neukum wrote:
> Am Donnerstag 27 September 2007 schrieb Alan Stern:
> > There's also a philosophical objection. Who is in a better position to
> > judge when a device like a SCSI drive should be autosuspended: its own
> > driver (sd) or someone else (usb-storage)?
>
>
On Fri, 28 Sep 2007, Oliver Neukum wrote:
> > You're right; there's no showstopping reason particular subsystems like
> > SCSI can't use a different approach. However bus activity alone isn't
> > a sufficient criterion. For example, suppose somebody sends a PLAY
> > AUDIO command to a SCSI cdrom
Am Donnerstag 27 September 2007 schrieb Alan Stern:
> There's also a philosophical objection. Who is in a better position to
> judge when a device like a SCSI drive should be autosuspended: its own
> driver (sd) or someone else (usb-storage)?
Then a philosophical answer. The highest entity which
Am Donnerstag 27 September 2007 schrieb Alan Stern:
> Have you thought about how autoresume would fit into this picture? I
> don't think you can rely on usb-storage telling the SCSI core to resume
> devices when it gets handed a command, because the commands to spin-up
> the drives would have to b
Am Donnerstag 27 September 2007 schrieb Alan Stern:
> On Thu, 27 Sep 2007, Oliver Neukum wrote:
>
> > > > 1. autosuspend should not be specific to USB
> > >
> > > Correct. Which means support for it should be added to the SCSI
> > > drivers. SCSI autosuspend shouldn't be kluged into usb-storage
Am Freitag 28 September 2007 schrieb Greg KH:
> On Tue, Sep 25, 2007 at 05:11:00PM +0200, Oliver Neukum wrote:
> >
> > PS: Whoever designed klists is suffering from a case of overengineeringosis.
>
> No objection from me there. If you can think of a way to do list
> traversal without taking lock
On Tue, Sep 25, 2007 at 05:11:00PM +0200, Oliver Neukum wrote:
>
> PS: Whoever designed klists is suffering from a case of overengineeringosis.
No objection from me there. If you can think of a way to do list
traversal without taking locks, please, feel free to redo the whole
klist stuff.
As it
No. You shouldn't expect users to run a program that would notice a
particular disk drive hasn't been used in X minutes and then power it
down. (Although they could if they wanted to... except that there's no
way for userspace to know when the drive was most recently used.)
I use noflushd to
On Thu, 27 Sep 2007, Steve Calfee wrote:
> Isn't power saving a policy decision?
Whether or not power saving should be implemented and under what
conditions it should occur are indeed policy decisions. However the
decision to actually power-down a device (because the specified
conditions have
> Date: Thu, 27 Sep 2007 16:26:56 -0400
> From: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> CC: [EMAIL PROTECTED]; [EMAIL PROTECTED]; linux-scsi@vger.kernel.org
> Subject: Re: [linux-usb-devel] question on flushing buffers and spinning down
> disk
>
> On Thu, 27 Sep 2
On Thu, 27 Sep 2007, Oliver Neukum wrote:
> > > 1. autosuspend should not be specific to USB
> >
> > Correct. Which means support for it should be added to the SCSI
> > drivers. SCSI autosuspend shouldn't be kluged into usb-storage in a
> > way that basically ignores what the SCSI layer is doin
Am Donnerstag 27 September 2007 schrieb Alan Stern:
> On Thu, 27 Sep 2007, Oliver Neukum wrote:
>
> > > Oliver, I'm surprised at you! This patch is a big hack, not to mention
> > > a layering violation and an inversion of the proper calling sequence.
> >
> > Well,
> >
> > 1. autosuspend should
On Thu, 27 Sep 2007, Oliver Neukum wrote:
> > Oliver, I'm surprised at you! This patch is a big hack, not to mention
> > a layering violation and an inversion of the proper calling sequence.
>
> Well,
>
> 1. autosuspend should not be specific to USB
Correct. Which means support for it should
Am Donnerstag 27 September 2007 schrieb Alan Stern:
> On Thu, 27 Sep 2007, Oliver Neukum wrote:
>
> > Am Dienstag 25 September 2007 schrieb Alan Stern:
> > > Getting all this to work will be tricky, because sd is a block device
> > > driven by requests issued through the block layer in atomic cont
On Thu, 27 Sep 2007, Oliver Neukum wrote:
> Am Dienstag 25 September 2007 schrieb Alan Stern:
> > Getting all this to work will be tricky, because sd is a block device
> > driven by requests issued through the block layer in atomic context,
> > whereas suspend and resume require a process context.
Am Dienstag 25 September 2007 schrieb Alan Stern:
> Getting all this to work will be tricky, because sd is a block device
> driven by requests issued through the block layer in atomic context,
> whereas suspend and resume require a process context. Probably the
> SCSI core would have to get invol
Am Dienstag 25 September 2007 schrieb Alan Stern:
> > Furthermore for many devices it will take real user intervention to
> > determine what is in the enclosure. This isn't very good. I think
> > we can do better.
>
> If by "we" you mean the Linux kernel in general, then I agree. If by
> "we" you
On Tue, 25 Sep 2007, Oliver Neukum wrote:
> Am Montag 24 September 2007 schrieb Alan Stern:
> > On Mon, 24 Sep 2007, Oliver Neukum wrote:
> >
> > > > subsystem implements its own form of runtime PM support, then you'll be
> > > > able to use it properly. But until then, there isn't anything much
On Mon, 24 Sep 2007, Oliver Neukum wrote:
> Am Montag 24 September 2007 schrieb Alan Stern:
> > On Mon, 24 Sep 2007, Oliver Neukum wrote:
> >
> > > > subsystem implements its own form of runtime PM support, then you'll be
> > > > able to use it properly. But until then, there isn't anything much
Am Montag 24 September 2007 schrieb Alan Stern:
> On Mon, 24 Sep 2007, Oliver Neukum wrote:
>
> > > subsystem implements its own form of runtime PM support, then you'll be
> > > able to use it properly. But until then, there isn't anything much you
> > > can do.
> >
> > Well, we can't simply cut
Am Montag 24 September 2007 schrieb Alan Stern:
> On Mon, 24 Sep 2007, Oliver Neukum wrote:
>
> > > subsystem implements its own form of runtime PM support, then you'll be
> > > able to use it properly. But until then, there isn't anything much you
> > > can do.
> >
> > Well, we can't simply cut
On Mon, 24 Sep 2007, Oliver Neukum wrote:
> > subsystem implements its own form of runtime PM support, then you'll be
> > able to use it properly. But until then, there isn't anything much you
> > can do.
>
> Well, we can't simply cut power. Buffers must be flushed and the disk
> spun down. The
Am Montag 24 September 2007 schrieb Alan Stern:
> On Mon, 24 Sep 2007, Oliver Neukum wrote:
> > But we don't bother when suspending the whole system. So why not simply
> > walk the subtrees under a USB device? Let the subsystem choose what
> > depth of sleep to use.
>
> Because by doing so you ar
35 matches
Mail list logo
