Message-ID: <436B7B46.6060205@drzeus.cx>
Date: Fri, 04 Nov 2005 16:16:22 +0100
From: Pierre Ossman <drzeus-list@drzeus.cx>
User-Agent: Mail/News 1.4.1 (X11/20051008)
MIME-Version: 1.0
To: dtor_core@ameritech.net
CC: Andrew Morton <akpm@osdl.org>, LKML <linux-kernel@vger.kernel.org>,
       Adam Belay <ambx1@neo.rr.com>
Subject: Re: [Fwd: [PATCH] [PNP][RFC] Suspend support for PNP bus.]
References: <436B2819.4090909@drzeus.cx> <d120d5000511040649u5b33405an73b5e33fb4ce5cf6@mail.gmail.com>
In-Reply-To: <d120d5000511040649u5b33405an73b5e33fb4ce5cf6@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1308
Lines: 41

Dmitry Torokhov wrote:
> On 11/4/05, Pierre Ossman <drzeus-list@drzeus.cx> wrote:
>   
>> +
>> +int pnp_start_dev(struct pnp_dev *dev)
>> +{
>> +       if (!pnp_can_write(dev)) {
>> +               pnp_info("Device %s does not supported activation.", dev->dev.bus_id);
>>     
>
> "...does not support...", there is no "ed" at the end.
>
>   

That's just code that's been moved around. But I suppose a speling fix 
could be included in the same patch. :)

>> +               return -EINVAL;
>> +       }
>>     
>
> 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?

Rgds
Pierre
-
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/