Re: [Fwd: [PATCH] [PNP][RFC] Suspend support for PNP bus.]

[Dmitry Torokhov <dmitry.torokhov@gmail.com>]

On 11/4/05, Pierre Ossman <drzeus-list@drzeus.cx> wrote:
> Dmitry Torokhov wrote:
> > On 11/4/05, Pierre Ossman <drzeus-list@drzeus.cx> wrote:
> >
> >> Dmitry Torokhov wrote:
> >>
> >>> Hmm, would'nt presence of such device stop suspend process? It will
> >>> cause pnp_bus_resume to fail too. Perhaps returning 0 in this case is
> >>> better.
> >>>
> >>>
> >>>
> >> The problem is that this code is also visited from pnp_activate_dev() &
> >> co where this return value is needed. For pnp_stop_dev() the same check
> >> (pnp_can_disable()) is performed in the suspend routine to avoid that
> >> particular problem. For resume my assumption was that a device that
> >> doesn't support activation will not have a driver attached to it.
> >> Perhaps this is wrong?
> >>
> >>
> >
> > i8042 registers drivers for keyboard and AUX ports to gather
> > information whether the ports are present and what IRQ and IO ports
> > shoudl be used to access them. And I have seen a few boxes that do not
> > alloe [de]activate these devices.
> >
> >
>
> But the activation is performed by the PNP layer when the driver is
> matched with a driver. So the driver isn't really responsible for the
> activation. It can prevent activation through
> PNP_DRIVER_RES_DO_NOT_CHANGE though, but that flag is also checked in
> the suspend routines.
>

You lost me... We have a scenario when a PNP driver is bound to a PNP
device that does not support deactivation. Looking at the proposed PNP
bus suspend code presence of such device will cause suspend process to
fail. Are you saying this is what you want?

--
Dmitry