[src] cvs commit: src/sys/dev/fdc fdc.c fdc_isa.c fdc_pccard.c fdcvar.h src/sys/modules/fdc Makefile

[M. Warner Losh]

In message: <40ECD2F0.3070201 at root.org>
            Nate Lawson <nate at root.org> writes:
: M. Warner Losh wrote:
: > In message: <40EC9698.4050201 at root.org>
: >             Nate Lawson <nate at root.org> writes:
: > : The problem I've run into involves the question that when multiple 
: > : drivers can claim a device, can you use anything in the device to pass 
: > : info to the attach routine?  I want to do a device_set_flags() to pass 
: > : the PNP flag to isa_attach() iff the isa PNP routine wins the probe.  Is 
: > : this ok since device_probe will be called a second time on the winning 
: > : driver?  As long as I destructively set the flags, it seems this is ok.
: > 
: > Generally this is considered bad form.  The only reason we call probe
: > the second time is to get the device name correct.  We may optimize
: > this away at some point, or we may call probe dozens of time in the
: > future.  Generally, you put code into attach routine to cope.  The
: > attach routine can call the get pnp id call in isa to find out if it
: > is plug and play and set the flags there.
: 
: I can't work around this in attach.  Both ACPI and ISA offer the ISA pnp 
: probe method and need to set ISPNP if probing via PNP.  Also, there will 
: be the ACPI _FDE method.  But the attach routine doesn't need to be any 
: different.  I had to add a stub attach for both ISA and ACPI that sets 
: the PNP flag and then calls the common isa_attach.  There was no other 
: way to differentiate which probe succeeded without setting a flag 
: somewhere.  But this was poor.
: 
: I think it should make sense that any flags you set in probe are the 
: ones that are set in attach if you win the probe.  Otherwise you'll end 
: up duplicating probe in attach (another bad idea).

I think that you misunderstand what I'm suggesting.  I'm talking about
doing things in fdc_acpi_attach or fdc_isa_attach, not in fdc_attach.
In fact, I plan on moving much of the code that's in fdc_attach now up
into bus attachments more appropriate for that code.  fdc isn't a good
example of separation.

: > Normally drivers have a common alloc_resources, but the floppy disk
: > can have so many different allocations from the upper layers that I
: > think that we'll have problems having one for all the attachments.
: 
: There's another hack we need. Some people have BIOSs that specify
: 0x3f2-0x3f5 for the data port (leaving out 0x3f0-0x3f1). So we'll need
: to say that if an incomplete range is specified, try adding the bottom
: end. I can't see how Windows works on that system except by hard-coding
: the port values.

Yes.  We'll have to deal with this.  Are these in both acpi and
pnpbios systems?

Warner