Re: [PATCH 1/3] libata: add missing PM callbacks

Re: [PATCH 1/3] libata: add missing PM callbacks

[Tejun Heo]

[cc'ing Pavel and linux-kernel, hello]

Original thread can be read from

  http://thread.gmane.org/gmane.linux.ide/16475

Jeff Garzik wrote:
> Tejun Heo wrote:
>> Some LLDs were missing scsi device PM callbacks while having host/port
>> suspend support.  Add missing ones.
>>
>> Signed-off-by: Tejun Heo <htejun@gmail.com>
> 
> applied 1-3, though I agree with Alan that a non-ifdef solution should
> be sought (by the PM & PCI people?), where possible

Agreed, CONFIG_PM ifdefs are all over low level drivers, libata or not,
and ugly as hell.  Maybe use separate section, mark functions with
__power and drop them at link time is a better idea.  With linker
tricks, we can make references to __power symbols NULL.  How does it sound?

-- 
tejun

Re: [PATCH 1/3] libata: add missing PM callbacks

[Pavel Machek]

Hi!

> [cc'ing Pavel and linux-kernel, hello]
> 
> Original thread can be read from
> 
>   http://thread.gmane.org/gmane.linux.ide/16475
> 
> Jeff Garzik wrote:
> > Tejun Heo wrote:
> >> Some LLDs were missing scsi device PM callbacks while having host/port
> >> suspend support.  Add missing ones.
> >>
> >> Signed-off-by: Tejun Heo <htejun@gmail.com>
> > 
> > applied 1-3, though I agree with Alan that a non-ifdef solution should
> > be sought (by the PM & PCI people?), where possible
> 
> Agreed, CONFIG_PM ifdefs are all over low level drivers, libata or not,
> and ugly as hell.  Maybe use separate section, mark functions with
> __power and drop them at link time is a better idea.  With linker
> tricks, we can make references to __power symbols NULL.  How does it sound?

Much complexity for little gain. Who is running _without_ CONFIG_PM
these days?
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [PATCH 1/3] libata: add missing PM callbacks

[Tejun Heo]

Pavel Machek wrote:
> Much complexity for little gain. Who is running _without_ CONFIG_PM
> these days?

Embedded people, I guess.  The problem here is that if we are gonna
support !CONFIG_PM configuration and try to reduce the kernel/module
images size for such case, we end up sprinkling #ifdef's all over huge
number of device drivers.

If we determine to drop !CONFIG_PM configuration, I'm happy with that
too but we need to determine something here.  Alternatives...

1. drop !CONFIG_PM configuration
2. continue to sprinkle #ifdef's over device drivers
3. find out prettier way to mark PM functions

-- 
tejun

Re: [PATCH 1/3] libata: add missing PM callbacks

[Pavel Machek]

Hi!

> > Much complexity for little gain. Who is running _without_ CONFIG_PM
> > these days?
> 
> Embedded people, I guess.  The problem here is that if we are gonna
> support !CONFIG_PM configuration and try to reduce the kernel/module
> images size for such case, we end up sprinkling #ifdef's all over huge
> number of device drivers.

Ok, in separate mail I see you already did the work...

> If we determine to drop !CONFIG_PM configuration, I'm happy with that
> too but we need to determine something here.  Alternatives...
> 
> 1. drop !CONFIG_PM configuration
> 2. continue to sprinkle #ifdef's over device drivers
> 3. find out prettier way to mark PM functions

...of 3., and code is nicely generic and fairly simple. I thought it
would be too much work to implemente it, and it would get too messy.

Given that it is so simple, I believe 3. is the best option. We can
still do 1. in future if we feel like so...
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [PATCH 1/3] libata: add missing PM callbacks

[Andrew Grover]

On 3/6/07, Pavel Machek <pavel@ucw.cz> wrote:
> > 1. drop !CONFIG_PM configuration
> > 2. continue to sprinkle #ifdef's over device drivers
> > 3. find out prettier way to mark PM functions
>
> ...of 3., and code is nicely generic and fairly simple. I thought it
> would be too much work to implemente it, and it would get too messy.
>
> Given that it is so simple, I believe 3. is the best option. We can
> still do 1. in future if we feel like so...

How much room does it actually save? And, can we maybe have some
actual embedded people saying they need this special treatment?

-- Andy