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>
next in thread | previous in thread | raw e-mail | index | archive | help
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= =20 well (see usage in the pnpmss driver in the same file). I think that any=20 drivers that actually need to interface with ACPI do need to just use=20 ISA_PNP_PROBE(). I think that drivers that don't implement devices ACPI=20 enumerates should stop attaching to ACPI as well. Finally, it may be that= =20 ISA_PNP_PROBE() needs to return a string version of the PNP ID that was=20 actually probed so that drivers can do extra tests. First though, we shoul= d=20 go through removing extra acpi attachments for drivers for ISA PNP cards=20 since ACPI enumerates the equivalent of PNP BIOS, not ISA PNP. =2D-=20 John Baldwin <jhb@FreeBSD.org> =A0<>< =A0http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" =A0=3D =A0http://www.FreeBSD.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200507180715.41974.jhb>