Date: Wed, 07 Jul 2004 23:34:46 -0600 (MDT) From: "M. Warner Losh" <imp@bsdimp.com> To: nate@root.org Cc: cvs-all@FreeBSD.org Subject: Re: [src] cvs commit: src/sys/dev/fdc fdc.c fdc_isa.c fdc_pccard.c fdcvar.h src/sys/modules/fdc Makefile Message-ID: <20040707.233446.117910204.imp@bsdimp.com> In-Reply-To: <40ECD2F0.3070201@root.org> References: <40EC9698.4050201@root.org> <20040707.185814.113735786.imp@bsdimp.com> <40ECD2F0.3070201@root.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <40ECD2F0.3070201@root.org>
Nate Lawson <nate@root.org> writes:
: M. Warner Losh wrote:
: > In message: <40EC9698.4050201@root.org>
: > Nate Lawson <nate@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040707.233446.117910204.imp>