This adds more Rust bindings for reading device properties, based on
Rob Herring's work. I'm working on a driver[1] that uses these, but the
driver has more dependencies than this.

Rob Herring and Dirk Behme did several review iterations over on Zulip
already[1], I'm thankful for their great input.

This is my second-ever patch series. I read through the documentation
for sending patches[2] carefully, trying to apply everything to the best
of my understanding. Please point out any specifics if I got something
wrong.

Best regards,
Remo

changes in v2:
- Add property.rs to maintainers file
- Add and improve lots of safety comments
- Use `__dev_fwnode` istead of `dev_fwnode` to express the intent better
- Make `get_child_by_name` not return a `PropertyGuard`
- Squash the patch with the generic read method
- Squash the PropertyGuard patch
- Remove `arrayvec`, abstract over `fwnode_reference_args` instead
- Log the full fwnode path in case of a missing property
- Remove integer trait and export of fwnode_property_read_int_array
  These are not needed now that a macro is used to associate each
  integer type with its corresponding `read_*_array` function.
- Replace `impl Property for bool` with a standalone function
  `property_read_bool` with an infallible function signature
- Extract parsing of properties into separate function in sample
  platform driver

Link: https://rust-for-linux.zulipchat.com/#narrow/channel/288089-General/topic/DS90UB954.20driver.20done.2C.20ready.20to.20upstream.3F/with/507874342 [1]
Link: https://www.kernel.org/doc/html/latest/process/submitting-patches.html#the-canonical-patch-format [2]

Remo Senekowitsch (5):
  rust: Move property_present to separate file
  rust: Add bindings for reading device properties
  rust: property: Add child accessor and iterator
  rust: property: Add property_get_reference_args
  samples: rust: platform: Add property read examples

 MAINTAINERS                                  |   1 +
 drivers/of/unittest-data/tests-platform.dtsi |   3 +
 rust/helpers/helpers.c                       |   1 +
 rust/helpers/property.c                      |   8 +
 rust/kernel/device.rs                        |   7 -
 rust/kernel/lib.rs                           |   1 +
 rust/kernel/property.rs                      | 608 +++++++++++++++++++
 samples/rust/rust_driver_platform.rs         |  69 ++-
 8 files changed, 688 insertions(+), 10 deletions(-)
 create mode 100644 rust/helpers/property.c
 create mode 100644 rust/kernel/property.rs

-- 
2.49.0

On Mon, Apr 14, 2025 at 5:26 PM Remo Senekowitsch <remo@buenzli.dev> wrote:
>
> changes in v2:

If possible (no need to resend, it is just a suggestion), please
submit new versions (especially multi-patch ones) in a new thread,
otherwise in some clients (including lore.kernel.org) it gets harder
to read.

> Link: https://www.kernel.org/doc/html/latest/process/submitting-patches.html#the-canonical-patch-format [2]

By the way, since I am here: to link to docs, nowadays there is
docs.kernel.org which is nicer/shorter:

    https://docs.kernel.org/process/submitting-patches.html#the-canonical-patch-format

I hope that helps!

Cheers,
Miguel

On Mon Apr 14, 2025 at 5:38 PM CEST, Miguel Ojeda wrote:
> On Mon, Apr 14, 2025 at 5:26 PM Remo Senekowitsch <remo@buenzli.dev> wrote:
>>
>> changes in v2:
>
> If possible (no need to resend, it is just a suggestion), please
> submit new versions (especially multi-patch ones) in a new thread,
> otherwise in some clients (including lore.kernel.org) it gets harder
> to read.

Okay, will do next time.

Junio Hamano recently wrote on the Git mailing list[1] that he wants
his contributors to do this, so the original message-ID can be used as
a "patch set ID". A quick glace at the archive[2] confirms that people
work this way. I assumed the kernel community would appreciate this
as well.

Link: https://lore.kernel.org/git/xmqqy0w8ng5r.fsf@gitster.g/ [1]
Link: https://lore.kernel.org/git/ [2]

Best regards,
Remo

On Mon, Apr 14, 2025 at 6:07 PM Remo Senekowitsch <remo@buenzli.dev> wrote:
>
> Junio Hamano recently wrote on the Git mailing list[1] that he wants
> his contributors to do this, so the original message-ID can be used as
> a "patch set ID". A quick glace at the archive[2] confirms that people
> work this way. I assumed the kernel community would appreciate this
> as well.

I see, thanks for the reference!

I don't think it is a good idea for long series, given how some
clients render things, e.g. GMail just shows the new version in a
single linear thread and it gets really confusing.

Even in a nested/tree render, like Lore's option, it is harder to see
and/or compare the versions, in my opinion. Perhaps Lore could be
improved here (e.g. offering (auto-)folding of versions) -- most of
the time we only care about the last version (and perhaps last - 1)
anyway.

I think `b4` behavior of subject+author works OK, but an explicit
change-id would be nice. Reusing the Message-ID for that would only
really work well if we could control the UI for everyone, I think.

Cheers,
Miguel