Re: [PATCH 0/2] rust: hwmon: rework hwmon abstractions, add TMP108 driver

[skxby]

Hi Donjuanplatinum,

Thank you for taking the time to look at this - and for replying at all.
Let me answer each point.

1. AI involvement

Fair question, and I should have stated it up front. The work was
developed with AI assistance: I run a multi-agent setup (a scheduler
plus several model-backed agents) that produced code drafts, ran the
build/regression/stress-test cycles and drafted the commit messages and
cover letter. Every patch was reviewed by me, and I built and tested
each change myself; the two bugs we found during this round (an i2c
client leak on the registration error path, and a missing null
terminator in chip_config) were both found by the lifecycle stress tests
I ran and reproduced before fixing. I signed off on the series and I
take responsibility for it.

For v2 I will add an "Assisted-by: LLM" tag as described in
Documentation/process/coding-assistants.html. Please tell me if you want
the tool names listed there as well.

2. Cc Rust-for-Linux

Agreed - I did not Cc rust-for-linux on v1, and I should have. v2 will
Cc rust-for-linux@xxxxxxxxxxxxxxx.

3. "?"

I am not sure what this referred to - could you say a little more about
what you were questioning there? I would rather ask than guess.

4. Legal name in sign-off

You are right that "skxby <2374604267@xxxxxx>" is not a legal name.
The series will be re-signed with my real name and address in v2.

5. Maintainership and interest

I am not asking anyone to take this over, and I am not claiming
maintainership. The point of posting was to have the shape of the
abstraction and one real driver on top of it looked at, and to find out
whether that shape is the right one at all - which your reply and the
review have already started to do.

On that note: Sashiko's review of patch 1 found issues that are real,
and I agree with the ones I have checked so far. In particular it
flagged the missing null terminator in chip_config - which we had
already found and fixed ourselves through stress testing, and which is a
good sign the review is looking at the right things - and it flagged
that chip_read/chip_write are called unconditionally in the read/write
callbacks, which would break any driver that does not implement those
optional methods. That second one is a genuine design flaw in the
abstraction, not in the driver, and I am fixing it in v2 along with the
name lifetime issue and the locking documentation.

So: is there enough interest to keep going? That is exactly what I am
trying to establish too, and your answer - either way - is the most
useful input available. If the answer is "not yet", I would rather hear
it now than keep posting revisions.

Thanks again for looking.

<SENDER REAL NAME>