tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: aibs(4): ASUSTeK AI Booster (ACPI ATK0110) hardware monitor with limit support



On Wed, Dec 30, 2009 at 08:49:32PM -0500, Constantine Aleksandrovich Murenin 
wrote:
> 2009/12/30 Jukka Ruohonen <jruohonen%iki.fi@localhost>:
> > The correct type for these would probably be uint64_t, given the relation to
> > the type ACPI_INTEGER, which AFAIR is an unsigned 64-bit integer (from ACPI
> > 2.0 onwards). Or maybe even plain ACPI_INTEGER?
> 
> Yes, this sounds good -- I'll try changing all of these to ACPI_INTEGER.

The other places where int64_t is used could be changed as well, if
appropriate.

> ACPI_ALLOCATE_LOCAL_BUFFER is not documented in the latest
> http://www.acpica.org/download/acpica-reference.pdf (Revision 1.26,
> from October 2009).  Is there any principal difference between the
> two?
> 
> ACPICA Reference, Section 3.2.2.2, "ACPI Allocates Return Buffers",
> explicitly suggests the use of AcpiOsFree().  Is it wrong?

Like in any good [...] API, a lot of things in ACPICA are not documented.
Both of these allow tracking the internal memory usage of ACPICA when
compile-time debugging options are defined. But nothing wrong as such. At
the end of the day ACPICA just hammers malloc() and free().

> >> +     as = malloc(sizeof(*as) * n, M_DEVBUF, M_NOWAIT | M_ZERO);
> >
> > I reckon that there is no reason to prefer malloc(9) instead of kmem(9).
> 
> I didn't use kmem(9) since that would require knowing the size of the
> structure on kmem_free(9).

Ah yes. The size (or 'n') could be recorded, but I am not sure if it is
worth the cause.

> it'll be more useful.  I'd prefer the driver to be as cross-portable
> as possible, though, and acpica functions seem like a natural choice
> for such a direction.

That is of course a good approach.

> > These should probably be %"PRId64" (or %"PRIx64" with uint64_t).
> 
> Sure, looks good...  Actually, what's the purpose of this?  Is
> sizeof(unsigned long long) greater than sizeof(uint64_t) on amd64?  If
> not, then why do you have to change llx to lx?  :/

Someone wiser has to answer this one :).

- Jukka.


Home | Main Index | Thread Index | Old Index