BSD Commit Log Search

acpi_cmbat: Use nitems instead of sizeof

Reviewed by: imp, markj, Elliott Mitchell
Pull Request: https://github.com/freebsd/freebsd-src/pull/1125

(cherry picked from commit d0cc25f770aee068bcbaee89aa2f52cc5dd79dd5)

ACPI: Treat all 20-element _BIX entires as revision 0

Some Fujitsu Lifebooks return an invalid _BIX object. The first element
of _BIX is a revision number, which indicates what elements will follow:
* ACPI 4.0 defined _BIX revision 0 with 20 elements.
* ACPI 6.0 introduced _BIX revision 1 with 21 elements.
The problem is that the offending Lifebooks have the a non-zero _BIX
revision, but provide 20 fields only.

The ACPICA parser chokes on this [1], but that seems to be
inconsequential. More importantly, our own battery info handling code
also verifies that for revision > 0, there are at least 21 fields - and
refuses to process the invalid _BIX. One workaround would be to
introduce special case / quirk handling for Fujitsu Lifebooks. A better
one is to relax the requirements check: If there are only 20 elements,
treat the _BIX as revision 0, no matter what revision number was
provided by the device.

Linux doesn't run into this problem by the way because it only supports

    [12 lines not shown]

ACPI: Treat all 20-element _BIX entires as revision 0

Some Fujitsu Lifebooks return an invalid _BIX object. The first element
of _BIX is a revision number, which indicates what elements will follow:
* ACPI 4.0 defined _BIX revision 0 with 20 elements.
* ACPI 6.0 introduced _BIX revision 1 with 21 elements.
The problem is that the offending Lifebooks have the a non-zero _BIX
revision, but provide 20 fields only.

The ACPICA parser chokes on this [1], but that seems to be
inconsequential. More importantly, our own battery info handling code
also verifies that for revision > 0, there are at least 21 fields - and
refuses to process the invalid _BIX. One workaround would be to
introduce special case / quirk handling for Fujitsu Lifebooks. A better
one is to relax the requirements check: If there are only 20 elements,
treat the _BIX as revision 0, no matter what revision number was
provided by the device.

Linux doesn't run into this problem by the way because it only supports

    [12 lines not shown]

ACPI: Treat all 20-element _BIX entires as revision 0

Some Fujitsu Lifebooks return an invalid _BIX object. The first element
of _BIX is a revision number, which indicates what elements will follow:
* ACPI 4.0 defined _BIX revision 0 with 20 elements.
* ACPI 6.0 introduced _BIX revision 1 with 21 elements.
The problem is that the offending Lifebooks have the a non-zero _BIX
revision, but provide 20 fields only.

The ACPICA parser chokes on this [1], but that seems to be
inconsequential. More importantly, our own battery info handling code
also verifies that for revision > 0, there are at least 21 fields - and
refuses to process the invalid _BIX. One workaround would be to
introduce special case / quirk handling for Fujitsu Lifebooks. A better
one is to relax the requirements check: If there are only 20 elements,
treat the _BIX as revision 0, no matter what revision number was
provided by the device.

Linux doesn't run into this problem by the way because it only supports

    [10 lines not shown]

acpi_cmbat: Use nitems instead of sizeof

Reviewed by: imp, markj, Elliott Mitchell
Pull Request: https://github.com/freebsd/freebsd-src/pull/1125

sys: Remove $FreeBSD$: one-line .c pattern

Remove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\n/

Similar commit in current:
(cherry picked from commit 685dc743dc3b)

sys: Remove $FreeBSD$: one-line .c pattern

Remove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\n/

acpi(4): Fix a typo in a kernel message

- s/enitialization/initialization/

MFC afer:       5 days

acpi: Remove unused devclass arguments to DRIVER_MODULE.

MFC of r355574, r358095, and r358395:

Add ACPI battery subsystem man page.

Add _BIX (Battery Information Extended) object support.

ACPI Control Method Batteries have a _BIF and/or _BIX object which
provide static properties of the battery.  FreeBSD acpi_cmbat module
supported _BIF object only, which was deprecated as of ACPI 4.0.
_BIX is an extended version of _BIF defined in ACPI 4.0 or later.

As of writing, _BIX has two revisions.  One is in ACPI 4.0 (rev.0) and
another is in ACPI 6.0 (rev.1).  It seems that hardware vendors still
stick to _BIF only or _BIX rev.0 + _BIF for the maximum compatibility.
Microsoft requires _BIX rev.0 for Windows machines, so there are some
laptop machines with _BIX rev.0 only. In this case, FreeBSD does not
recognize the battery information.

After this change, the acpi_cmbat module gets battery information from

    [20 lines not shown]

MFC of r355574, r358095, and r358395:

Add ACPI battery subsystem man page.

Add _BIX (Battery Information Extended) object support.

ACPI Control Method Batteries have a _BIF and/or _BIX object which
provide static properties of the battery.  FreeBSD acpi_cmbat module
supported _BIF object only, which was deprecated as of ACPI 4.0.
_BIX is an extended version of _BIF defined in ACPI 4.0 or later.

As of writing, _BIX has two revisions.  One is in ACPI 4.0 (rev.0) and
another is in ACPI 6.0 (rev.1).  It seems that hardware vendors still
stick to _BIF only or _BIX rev.0 + _BIF for the maximum compatibility.
Microsoft requires _BIX rev.0 for Windows machines, so there are some
laptop machines with _BIX rev.0 only. In this case, FreeBSD does not
recognize the battery information.

After this change, the acpi_cmbat module gets battery information from

    [20 lines not shown]

Merge ^/head r358269 through r358399.

Add workaround for models which do not follow the ACPI specification strictly.
Extra objects are now simply ignored instead of rejecting everything.

Merge ^/head r358075 through r358130.

Add _BIX (Battery Information Extended) object support.

ACPI Control Method Batteries have a _BIF and/or _BIX object which
provide static properties of the battery.  FreeBSD acpi_cmbat module
supported _BIF object only, which was deprecated as of ACPI 4.0.
_BIX is an extended version of _BIF defined in ACPI 4.0 or later.

As of writing, _BIX has two revisions.  One is in ACPI 4.0 (rev.0) and
another is in ACPI 6.0 (rev.1).  It seems that hardware vendors still
stick to _BIF only or _BIX rev.0 + _BIF for the maximum compatibility.
Microsoft requires _BIX rev.0 for Windows machines, so there are some
laptop machines with _BIX rev.0 only. In this case, FreeBSD does not
recognize the battery information.

After this change, the acpi_cmbat module gets battery information from
_BIX or _BIF object and internally uses _BIX rev.1 data structure as
the primary information store in the kernel.  ACPIIO_BATT_GET_BI[FX]
returns an acpi_bi[fx] structure built by using information obtained
from a _BIF or a _BIX object found on the system.  The revision number

    [14 lines not shown]

Merge ^/head r339670 through r339812.

Distinguish _CID match and _HID match and make lower priority probe
when _CID match.

Reviewed by: jhb, imp
Differential Revision:https://reviews.freebsd.org/D16468

MFH @ r337607, in preparation for boarding

Merge ^/head r336870 through r337285, and resolve conflicts.

Make timespecadd(3) and friends public

The timespecadd(3) family of macros were imported from NetBSD back in
r35029. However, they were initially guarded by #ifdef _KERNEL. In the
meantime, we have grown at least 28 syscalls that use timespecs in some
way, leading many programs both inside and outside of the base system to
redefine those macros. It's better just to make the definitions public.

Our kernel currently defines two-argument versions of timespecadd and
timespecsub.  NetBSD, OpenBSD, and FreeDesktop.org's libbsd, however, define
three-argument versions.  Solaris also defines a three-argument version, but
only in its kernel.  This revision changes our definition to match the
common three-argument version.

Bump _FreeBSD_version due to the breaking KPI change.

Discussed with: cem, jilles, ian, bde
Differential Revision:  https://reviews.freebsd.org/D14725

MFC r314328:

Fix startup race initialising ACPI CM battery structures on MacBookPro.

During acpi_cmbat_attach() the acpi_cmbat_init_battery() notification
handler is registered. It has been observed this notification handler
can be called instantly, before the attach routine has returned. In
the notification handler there is a call to device_is_attached() which
returns false. Because the softc is set we know an attach is in
progress and the fix is simply to wait and try again in this case.

Reviewed by:            avg @

MFC r314328:

Fix startup race initialising ACPI CM battery structures on MacBookPro.

During acpi_cmbat_attach() the acpi_cmbat_init_battery() notification
handler is registered. It has been observed this notification handler
can be called instantly, before the attach routine has returned. In
the notification handler there is a call to device_is_attached() which
returns false. Because the softc is set we know an attach is in
progress and the fix is simply to wait and try again in this case.

Reviewed by:            avg @

MFC r314328:

Fix startup race initialising ACPI CM battery structures on MacBookPro.

During acpi_cmbat_attach() the acpi_cmbat_init_battery() notification
handler is registered. It has been observed this notification handler
can be called instantly, before the attach routine has returned. In
the notification handler there is a call to device_is_attached() which
returns false. Because the softc is set we know an attach is in
progress and the fix is simply to wait and try again in this case.

Reviewed by:            avg @

MFC r314328:

Fix startup race initialising ACPI CM battery structures on MacBookPro.

During acpi_cmbat_attach() the acpi_cmbat_init_battery() notification
handler is registered. It has been observed this notification handler
can be called instantly, before the attach routine has returned. In
the notification handler there is a call to device_is_attached() which
returns false. Because the softc is set we know an attach is in
progress and the fix is simply to wait and try again in this case.

Reviewed by:            avg @

Merge ^/head r314270 through r314419.

Fix startup race initialising ACPI CM battery structures on MacBookPro.

During acpi_cmbat_attach() the acpi_cmbat_init_battery() notification
handler is registered. It has been observed this notification handler
can be called instantly, before the attach routine has returned. In
the notification handler there is a call to device_is_attached() which
returns false. Because the softc is set we know an attach is in
progress and the fix is simply to wait and try again in this case.

Reviewed by:            avg @
MFC after:              1 week

Merge fresh head.

MFC r227293 (by ed):
Mark MALLOC_DEFINEs static that have no corresponding MALLOC_DECLAREs.

This means that their use is restricted to a single C file.

IFC @247348.

Sync with HEAD.