public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Adam Belay <ambx1@neo.rr.com>
To: "Grover, Andrew" <andrew.grover@intel.com>
Cc: John Bradford <john@grabjohn.com>,
	perex@perex.cz, linux-kernel@vger.kernel.org, greg@kroah.com,
	alan@lxorguk.ukuu.org.uk
Subject: Re: PnP model
Date: Thu, 6 Feb 2003 18:49:16 +0000	[thread overview]
Message-ID: <20030206184916.GC10021@neo.rr.com> (raw)
In-Reply-To: <F760B14C9561B941B89469F59BA3A84725A154@orsmsx401.jf.intel.com>

On Tue, Feb 04, 2003 at 11:53:40AM -0800, Grover, Andrew wrote:
> > From: John Bradford [mailto:john@grabjohn.com] 
> > > I think the people who want to manually configure their device's
> > > resources need to step up and justify why this is really necessary.
> > 
> > Prototyping an embedded system, maybe, where you have devices in the
> > test box that won't be in the production machine.  You would want them
> > to use resources other than those that you want the hardware which
> > will be present to use.
>
> Ok fair enough. But I think the drivers should always think things are
> handled in a PnP manner, even if they really aren't. ;-) For example,
> between the stages where PnP enumerates the devices and the stage where
> drivers get device_add notifications as a result of that, we will be
> assigning the system resources to each device, but we could also
> implement a way at this stage for people to manually alter things. I
> think this is the right place to do this, as opposed to having all the
> drivers implement code to probe for themselves.
> 
> Thoughts?

I agree.  Actually the isapnp specifications (see Figure 2. Plug and Play ISA 
Configuration Flow for Plug and Play BIOS located in Plug and Play ISA
Specification Version 1.0a) recommend that the operating system configures
and activates all devices before drivers are loaded.  For the most part
linux plug and play follows this standard with the exception of manual
configuration support which is included in my latest patches.

Regards,
Adam

  parent reply	other threads:[~2003-02-06 23:39 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-02-04 19:53 PnP model Grover, Andrew
2003-02-04 22:56 ` Alan Cox
2003-02-06 18:49 ` Adam Belay [this message]
  -- strict thread matches above, loose matches on Subject: below --
2003-02-04 19:25 Grover, Andrew
2003-02-04 19:40 ` John Bradford
2003-02-03 15:31 PnP Model James Bottomley
2003-02-03 16:41 ` Alan Cox
2003-02-04 16:45   ` James Bottomley
2003-02-02 20:36 [PATCH][RFC] Resource Management Improvements (1/4) Adam Belay
2003-02-03 13:55 ` PnP model Jaroslav Kysela
2003-02-03 15:45   ` Alan Cox
2003-02-03 20:43   ` Adam Belay
2003-02-04  9:46     ` Russell King
2003-02-04 10:18       ` Jaroslav Kysela
2003-02-04 10:49         ` Russell King
2003-02-05 21:34           ` Adam Belay
2003-02-07  8:56             ` Jaroslav Kysela
2003-02-04 10:40     ` Jaroslav Kysela

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=20030206184916.GC10021@neo.rr.com \
    --to=ambx1@neo.rr.com \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=andrew.grover@intel.com \
    --cc=greg@kroah.com \
    --cc=john@grabjohn.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=perex@perex.cz \
    /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