Date: Wed, 16 Jun 2004 15:02:27 -0600 (MDT) From: "M. Warner Losh" <imp@bsdimp.com> To: liamfoy@sepulcrum.org Cc: acpi@freebsd.org Subject: Re: apm problem Message-ID: <20040616.150227.68884900.imp@bsdimp.com> In-Reply-To: <20040616215708.360cf786.liamfoy@sepulcrum.org> References: <20040616213946.6f7def3d.liamfoy@sepulcrum.org> <20040616.145257.88000637.imp@bsdimp.com> <20040616215708.360cf786.liamfoy@sepulcrum.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <20040616215708.360cf786.liamfoy@sepulcrum.org>
"Liam J. Foy" <liamfoy@sepulcrum.org> writes:
: On Wed, 16 Jun 2004 14:52:57 -0600 (MDT)
: "M. Warner Losh" <imp@bsdimp.com> wrote:
:
: > In message: <20040616213946.6f7def3d.liamfoy@sepulcrum.org>
: > Liam Foy <liamfoy@sepulcrum.org> writes:
: > : > +#define APM_UNKNOWN 0xff /* Unknown in APM BIOS spec */
: > :
: > : Do you not mean 0xffffffff ?
: >
: > No. 0xff is the right number here. The problem is that there's a
: > number of different flag values, some which come directly from the APM
: > BIOS, and others that are generated by the drivers.
:
: Seems am confused. If they are returning 0xffffffff why are we testing for
: 0xff?
Because they aren't returning 0xffffffff. They are returning 0xff.
That's the point Nate seems to be confused on. For both apm and acpi
I've confirmed that 0xff is returned. If there are situations that
I've not been able to find where this isn't the case, the drivers
should be corrected. Code inspection can only go so far on this.
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040616.150227.68884900.imp>