Re: General device properties API

[Jason Thorpe <thorpej%me.com@localhost>]

> On Aug 15, 2021, at 2:08 AM, Taylor R Campbell <campbell+netbsd-tech-kern%mumble.net@localhost> wrote:
> 
>> Date: Fri, 13 Aug 2021 19:10:20 -0700
>> From: Jason Thorpe <thorpej%me.com@localhost>
>> 
>> Over the last year or so, I've been playing around with ideas for a
>> generic device properties API, and have been slowly adding some
>> infrastructure to the kernel to enable it.  Enough of the
>> infrastructure is now in place (or in the pipeline) and I think my
>> design is now fully-formed enough in my head to float it here.
> 
> This is a little abstract to follow just from the types.  Can you show
> examples of:
> 
> - code scattered around to reflect device tree properties?

Great example starts at: sys/arch/sparc64/sparc64/autoconf.c:1248 and continues to line 1319.

> - duplicated-and-tweaked code?
> - reducing boilerplate in drivers?
> 
> Can you give a little more detail about: what information needs to be
> encoded in a driver?  For example, if an ethernet device needs to get
> its mac address from an OF/FDT property called mumblefrotz,mac-addr or
> an ACPI method called _MAC, do we write code that looks like
> device_hasprop(dh, "mumblefrotz,mac-addr"), device_hasprop(dh,
> "_MAC"); or do we put those in separate mumblefrotz_fdt.c and
> mumblefrotz_acpi.c bus attachments and pass it through
> mumblefrotz_attach_args, or what?  Or am I barking up the wrong tree
> about what this API is supposed to be used for?

Ethernet MAC addresses are a very prevalent use of device properties these days, but it’s not actually the best example to use, because Ethernet MAC addresses are one of those situations where there is often a complex platform binding for how they’re derived (this is certainly true for FDT and the sparc* platforms, and we don’t actually handle the FDT case correctly *at all* yet).

Look around the tree at places that call acpi_dsd_integer() and acpi_dsd_string().  That code is querying properties defined by the FDT bindings for those devices, but they’re wrapped inside an ACPI container object.  There even exist ACPI objects these days that have entire FDT blobs in them (Jared can provide more details)

> Why do we pass untyped strings around with this device_call mechanism?
> Was there any discussion about this beforehand?  Had I known it was
> proposed I would have objected to an untyped string method calling
> mechanism -- surely we can do better to detect typos and type errors
> at compile-time.

This complaint is at best tangentially related to the topic at hand, and can be adjusted separately from this discussion.

> How do clients know they are following the typing rules?  Does the
> compiler provide any way to detect errors, or can that be detected
> only at run-time depending on what OF/FDT/ACPI data the firmware
> provides?

Code needs to check at run-time, which has been the case for a long time already, and honestly I don’t see any problem with that at all.

>> Anyway, the API: [...]
> 
> What's the advantage of creating a new API with many of essentially
> the same functions prop_* (prop_dictionary_get_string, &c.), vs just
> mapping the entire tree recursively into a proplib dictionary and
> having drivers use the existing prop_* API to query it?

Mainly because recursively mapping the entire device tree into a dictionary would be wasteful (there are plenty of properties nobody cares about, so why allocate objects for them?).  Also, the structure of the underlying device tree does not necessarily map directly to how we structure our representation of it with device_t’s.  My approach coerces it into our logical format by virtue of assigning the correct dev handles to the device_t’s when things are enumerated (we do a good chunk of this in the tree now using CFARGS() and there is more of this in the pipeline in the thorpej-i2c-spi-conf2 branch).

-- thorpej