From: Adam Belay <ambx1@neo.rr.com>
To: "Ruslan U. Zakirov" <cubic@wildrose.miee.ru>
Cc: Andrew Morton <akpm@digeo.com>,
linux-mm@kvack.org, Alexander Hoogerhuis <alexh@ihatent.com>,
linux-kernel@vger.kernel.org
Subject: Re: 2.5.65-mm1
Date: Tue, 18 Mar 2003 21:33:07 +0000 [thread overview]
Message-ID: <20030318213307.GA13998@neo.rr.com> (raw)
In-Reply-To: <1731494377120.20030318224925@wr.miee.ru>
On Tue, Mar 18, 2003 at 10:49:25PM +0300, Ruslan U. Zakirov wrote:
> AH> Alexander Hoogerhuis <alexh@ihatent.com> writes:
> >> Andrew Morton <akpm@digeo.com> writes:
> >> >
> >> > [SNIP]
> >> >
> >>
> >> [SNIP MYSELF]
> >>
> AH> And this one when probing for my PCIC:
>
> AH> Intel PCIC probe: PNP <6>pnp: res: The PnP device '00:0f' is already
> AH> active.
> Hello, Alexandre and other.
> This error is not mm specific.
> This was brought with latest PnP changes.
> As I've understood that latest PnP Layer activates all devices during layer
> initialisation, but I don't know how it could be if we don't register
PnP code currently assigns resources at init and then activates during driver
matching.
> pnp_driver. With first look I didn't find this runpaths. I'll try to
> review all changes.
> Adam know absolutly right solution in this case, I think :)
> Best regards, Ruslan.
>
> mailto:cubic@wr.miee.ru
Hi Ruslan and others,
Yes, this is actually a glitch in the driver. The bios has activated this
device at boot time and the driver tries to activate it again without
checking if it was active in the first place.
I'm going to do the following to correct this:
1.) Update this driver to use the new pnp code, the new code automatically
manages this.
2.) Change pnp_activate_dev so that it doesn't return an error if the device
is already active, instead have it silently stop. This is a more logical
behavior because the device will function properly even if it was already
active. I should probably do the same with pnp_disable_dev.
Regards,
Adam
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>
next prev parent reply other threads:[~2003-03-18 21:33 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-03-18 11:11 2.5.65-mm1 Andrew Morton
2003-03-18 13:15 ` 2.5.65-mm1 Helge Hafting
2003-03-18 15:08 ` 2.5.65-mm1 Alexander Hoogerhuis
2003-03-18 15:51 ` 2.5.65-mm1 Alexander Hoogerhuis
2003-03-18 16:09 ` 2.5.65-mm1 Russell King
2003-03-19 0:14 ` 2.5.65-mm1 Alexander Hoogerhuis
2003-03-19 0:26 ` 2.5.65-mm1 Andrew Morton
2003-03-19 6:16 ` 2.5.65-mm1 Alexander Hoogerhuis
2003-03-19 8:12 ` 2.5.65-mm1 Alexander Hoogerhuis
2003-03-19 8:20 ` 2.5.65-mm1 Alexander Hoogerhuis
2003-03-18 19:49 ` Re[2]: 2.5.65-mm1 Ruslan U. Zakirov
2003-03-18 21:33 ` Adam Belay [this message]
2003-03-18 21:40 ` 2.5.65-mm1 William Lee Irwin III
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20030318213307.GA13998@neo.rr.com \
--to=ambx1@neo.rr.com \
--cc=akpm@digeo.com \
--cc=alexh@ihatent.com \
--cc=cubic@wildrose.miee.ru \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox