Re: RFC: device flavours

[David Young <dyoung%pobox.com@localhost>]

On Wed, Jul 28, 2010 at 03:09:36PM +0000, Quentin Garnier wrote:
> On Tue, Jul 27, 2010 at 09:23:04AM +0200, Martin Husemann wrote:
> > On Tue, Jul 27, 2010 at 01:56:23AM +0000, Quentin Garnier wrote:
> > > "For free" is a subjective thing.  I don't think using device_register()
> > > --which is a MD callback--to pass information between two MI drivers is
> > > free.
> > 
> > Well, using a MD callback to attach MD information from ACPI somehow
> > makes sense to me.
> 
> Information is just what it is, information.  It becomes MD only when
> something tries to interpret it, and that's the job of the ISA backend
> through the bus_space functions and the interrupt stuff.

Martin may have meant that the information's source is MD code, but I
think that the format of the information and its consumers will be MI.

> > FWIW, what David outlines is pretty close to the way i2c direct config
> > works in -current.
> 
> Your point is?  In David's scheme, the ichlpc driver has to do the work
> to attach the pcib driver and said work has to be replicated in every
> other variant, and you still need a generic variant to attach the actual
> pcib driver when none of the *pcib drivers match.

Replicating the work of attaching a pcib(4) in the variant drivers is
not so much work.

> And after that, the
> pcib driver will have to know that it might be on an ACPI system and
> thus can fetch information there.  Think what you want, but to me it is
> nonsense and that's exactly what I am trying to find a solution to here.

The pcib(4) driver only needs to attach its isa(4). isa(4) need not know
anything about ACPI, it just walks its MI device properties list to see
what is directly configurable.

I don't understand why isa(4) was out of the picture in your flavors
proposal.

Dave

-- 
David Young             OJC Technologies
dyoung%ojctech.com@localhost      Urbana, IL * (217) 278-3933