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

[Nate Lawson]

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).

> 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.

-- 
-Nate