lkml.org 
[lkml]   [2003]   [Aug]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PM] Patrick: which part of "maintainer" and "peer review" needs explaining to you?
On Mon, Aug 25, 2003 at 08:47:16AM -0700, Patrick Mochel wrote:
> > There is a hell of a lot of work which now needs to be done to re-fix
> > everything which was working. For example, there is no sign of any
> > power management for platform devices currently. Could you give some
> > clues as to what you'd like to see there?
>
> How about following the system device scheme: 1 call, with interrupts
> disabled?

I don't think that's going to work well when you have more conventional
devices below a platform device which need to be power managed (eg, a
USB host.)

I think we need to expand the platform device support to include the
notion of platform drivers. For example:

struct platform_driver {
int (*probe)(struct platform_device *);
int (*remove)(struct platform_device *);
int (*suspend)(struct platform_device *, u32);
int (*resume)(struct platform_device *);
struct device_driver drv;
};

(Aside: I like the movement of the suspend/resume methods to the bus_type,
and I'd like to see the probe/remove methods also move there. For the
vast majority of cases, the probe/remove methods in struct device_driver
end up pointing at the same functions for any particular bus.)

> > There's also a fair number of drivers to update to this new power
> > management model - eg, ARM device drivers, PCMCIA socket drivers to
> > name just two.
>
> That's fine. I will fix PCMCIA, as I have devices to test with. I have no
> ARM devices (nor do I want any). I can take a stab, but won't guarantee
> anything. Could you tell me, though, when/if these devices did work with
> what power management scheme? APM?

I know it works on ARM, but, since APM is completely fscked in 2.6
kernels and no one seems to be interested in the issue, its something
I can't test on x86.

> > We also need to fix the device model probing so we can have a generic
> > PCI bridge driver but override it if we have a more specific driver.
>
> We talked about that, and it's going to require some changes to the core,
> albeit small. We're not prepared to do that right now, though we'll
> reconsider depending on necessity and impact of the patch..

Bear in mind that Red Hat kernels contain a generic PCI bridge driver
in order to save its state across suspend/resume, and that the PPC
people also seem to need it. Also bear in mind that the Mobility Docks
have some non-standard configuration controls in their PCI-PCI bridge
which needs a vendor specific PCI-PCI bridge driver.

--
Russell King (rmk@arm.linux.org.uk) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:48    [W:0.124 / U:0.760 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site