Date: Mon, 18 Jul 2005 07:15:40 -0400 From: John Baldwin <jhb@FreeBSD.org> To: Nate Lawson <nate@root.org> Cc: freebsd-current@FreeBSD.org, harrycoin@qconline.com, "M. Warner Losh" <imp@bsdimp.com> Subject: Re: mss.c pcm fix to ' attach returned 6 ' load failure for v5.x acpi and up Message-ID: <200507180715.41974.jhb@FreeBSD.org> In-Reply-To: <42D9DA05.1020806@root.org> References: <20050716.113059.82101301.imp@bsdimp.com> <20050716.131701.124866666.imp@bsdimp.com> <42D9DA05.1020806@root.org>
index | next in thread | previous in thread | raw e-mail
On Sunday 17 July 2005 12:09 am, Nate Lawson wrote: > M. Warner Losh wrote: > > <the refs are wrong for this reply> > > > > Nate writes: > >>I really think the driver is broken and the API is fine for this. I > >>don't like the hack of returning a random CID for checks against the > >>HID. Drivers down the road may come to rely on this and then every BIOS > >>that has a different order for CIDs becomes a potential breakage point. > > > > They alredy do rely on this. When they support pnp, they call the > > ISA_PNP_PROBE routine. When they don't then your observation doesn't > > matter because the order of the IDs doesn't matter: their non-zeroness > > does. > > > >>Drivers should not rely on isa_get_logicalid() to determine a boolean > >>"is PNP?" > > > > Actually, that's the interface. We have to follow it, even if you > > think it is stupid. It is how we do things. When we don't have a > > logicalid, we return 0. When drivers don't support pnp devices, it > > uses the existance of a non-zero pnpid to know the device isn't for > > them. It has been this way since 3.0. > > > > Warner > > Rather than John's addition of returning an arbitrary CID, can we return > ~0 or some other obviously invalid HID so that drivers don't start > depending on the order of CIDs? Actually, drivers also use isa_get_logicalid() to get real actual PnP ID as well (see usage in the pnpmss driver in the same file). I think that any drivers that actually need to interface with ACPI do need to just use ISA_PNP_PROBE(). I think that drivers that don't implement devices ACPI enumerates should stop attaching to ACPI as well. Finally, it may be that ISA_PNP_PROBE() needs to return a string version of the PNP ID that was actually probed so that drivers can do extra tests. First though, we should go through removing extra acpi attachments for drivers for ISA PNP cards since ACPI enumerates the equivalent of PNP BIOS, not ISA PNP. -- John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.orghelp
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200507180715.41974.jhb>