On Mon, 26 Dec 2005, Pavel Machek wrote:
> On Po 26-12-05 12:43:43, Patrick Mochel wrote:
> > > Is there enough locking in driver core to make this safe?
> >
> > The issue I stated is actually orthogonal to locking the device; but the
> > answer to your question is: probably not. We should probably be taking the
> > per-device semaphore to prevent against competing events that are trying
> > to add/remove a device or driver.
>
> Ok, thanks. That means that some races are still there, but they
> probably don't matter for non-hotpluggable stuff like PCI, right?
Well, the semapohre blocks against driver probing and removing, too.
> Noone uses .../power API just now (except Holger :-), so I think we
> can still change it. Currently it is horribly broken -- taking 0/2 and
> passing it directly to pm_message_t.event. I don't think we can solve
> worlds hunger today... but what about at least changing interface so
> that it lists two states ("on" and "suspend") that are more or less
> common to all drivers?
I don't think we want to do something from the core that is common to all
drivers in that area. The PM values and semantics are so different across
that I don't think we could effectively abstract something for everything.
What we could do is remove the file from being added in the core, and have
the PCI core add it for all PCI devices that have PM capabilities and show
all the states that appear in the config space. From there, we could start
adding logic to filter out unsupported states and adding extra states that
the driver supports (that aren't in the config space, assuming that they
exist for some devices).
In short, you're right - we can't solve world hunger, but we should be
able to make some good progress on at least one continent. Once I'm back
to a development machine (and not a coffee shop wireless connection), I'll
try to cook up a patch..
Patrick
