Page MenuHomeFreeBSD

device: add device_get_property and device_has_property
ClosedPublic

Authored by bag_semihalf.com on Aug 18 2021, 8:46 AM.
Tags
None
Referenced Files
Unknown Object (File)
Thu, Oct 24, 2:57 AM
Unknown Object (File)
Fri, Oct 18, 6:49 AM
Unknown Object (File)
Sep 22 2024, 11:08 AM
Unknown Object (File)
Sep 19 2024, 12:20 AM
Unknown Object (File)
Sep 18 2024, 6:38 PM
Unknown Object (File)
Sep 18 2024, 5:25 AM
Unknown Object (File)
Sep 17 2024, 7:38 PM
Unknown Object (File)
Sep 15 2024, 10:34 PM

Details

Summary

Generialize bus specific property accessors. Those functions allow driver code
to access device specific information.

Currently there is only support for FDT and ACPI buses.

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

manu added a subscriber: manu.

LGTM but that should be documented somewhere (tm)

This revision is now accepted and ready to land.Aug 18 2021, 5:43 PM
imp requested changes to this revision.Aug 18 2021, 6:01 PM

This really needs man pages, but otherwise looks OK to me module one nit in bus.h

sys/kern/bus_if.m
957

This needs a man page.

sys/kern/subr_bus.c
2718

This needs a man page.

sys/sys/bus.h
640

I'd move the implementation of this to subr_bus.c. There's no need for it to be inline and it's the only function like that here.
this also needs a man page :)

This revision now requires changes to proceed.Aug 18 2021, 6:01 PM

I've created requested man pages.

@imp Did you have time to look at these man pages?

This revision was not accepted when it landed; it landed in state Needs Review.Sep 20 2021, 3:18 PM
This revision was automatically updated to reflect the committed changes.

Sorry; post-commit comment for enhancement.

sys/dev/acpica/acpi.c
1852

I believe you need a

default:
    return (0);

here; otherwise if the type is not handled here, device_has_property() will get a -1 result and return "no such property" rather than "property exists".

sys/kern/subr_bus.c
2722

This is not correct. But the real problem is elsehere (see other comment on acpi.c).

In D31597#744282, @bz wrote:

Sorry; post-commit comment for enhancement.

Thank you for the comment. I will work on this next week.

In D31597#744282, @bz wrote:

Sorry; post-commit comment for enhancement.

Thank you for the comment. I will work on this next week.

FYI I have further changes to use the handle internally for _DSD as some non-native ACPI devices (no _HID) can then also use these functions (directly) to get properties; I'll extract them and post them and try to Cc: you. And maybe you guys have better ways to handle that; I hit the problem with MDI0/PHY and PR<n>s for dpaa2.

In D31597#746913, @bz wrote:
In D31597#744282, @bz wrote:

Sorry; post-commit comment for enhancement.

Thank you for the comment. I will work on this next week.

FYI I have further changes to use the handle internally for _DSD as some non-native ACPI devices (no _HID) can then also use these functions (directly) to get properties; I'll extract them and post them and try to Cc: you. And maybe you guys have better ways to handle that; I hit the problem with MDI0/PHY and PR<n>s for dpaa2.

Please add me to all related dpaa2/MDIO/PHY/ACPI-related reviews.

Thank you in advance,
Marcin