Re: [RFC v1 2/2] platform/x86/amd: Add AMD DPTCi driver

[Antheas Kapenekakis]

On Tue, 3 Mar 2026 at 22:45, Sasha Levin <sashal@xxxxxxxxxx> wrote:
>
> On Tue, Mar 03, 2026 at 02:54:59PM -0600, Mario Limonciello (AMD) (kernel.org) wrote:
> >+ Sasha
> >
> >On 3/3/2026 2:40 PM, Antheas Kapenekakis wrote:
> >>On Tue, 3 Mar 2026 at 21:10, Mario Limonciello (AMD) (kernel.org)
> >><superm1@xxxxxxxxxx> wrote:
> >>>
> >>>I'll preface this by saying - I don't have a problem with using an AI to
> >>>help write a driver, but please disclose that it was done and that in
> >>>this case even you haven't closely audited the results.
> >>>
> >>>I personally would never submit something generated by an LLM that I
> >>>didn't audit and add a S-o-b tag to it (asserting I am willing to stand
> >>>by the code).
> >>>
> >>>I'm glad that I found out it was AI written before I started to review
> >>>the code, I would have had a lot more candid comments for you.
> >>>
> >>>There is a lot of weird stuff in this driver that I'm not going to
> >>>comment on and nitpick, but I'll leave a few broad strokes things.
> >>
> >>Of course, to that end, feel free to skip a full review until I get to
> >>properly rewriting it.
> >>
> >>What is the current stance on Co-bys for that? I'm trying to follow
> >>the discussion but I missed the news. I can lint it properly next
> >>time.
> >>
> >> From my perspective, pouring a month into a driver like this without
> >>having a firm commitment that it will go somewhere is a bit hard to
> >>stomach.
> >
> >Sure.
> >
> >I don't need a dedicated tag telling me what tool you wrote it with.
> >I don't care if it was Opus, Gemini or Qwen3.5.  They all can make
> >mistakes that need to be audited.
> >
> >The most important part to me (or any reviewer) is a signal that I
> >shouldn't invest more effort reviewing this than you did writing it
> >and reviewing it.
> >
> >My feeling on this kind of RFC this is the most appropriate tag:
> >
> >Not-signed-off-by: Foo Bar <foo@xxxxxxx>
>
> We have docs for this now :) Both in the README file as well as
> Documentation/process/coding-assistants.rst .
>
> In particular, you should be upfront about using AI to generate code, using the
> Assisted-by: tag, and definitely giving it a very careful review making sure
> you completely understand what the code does.
>
> As the README says:
>
>    The human submitter is responsible for:
>
>    * Reviewing all AI-generated code
>    * Ensuring compliance with licensing requirements
>    * Adding their own Signed-off-by tag to certify the DCO
>    * Taking full responsibility for the contribution

Ok, I will add the missing tag then :)

Assisted-by: Claude:claude-4.6-opus

I do stand by the code, as far as a V1 RFC is concerned at least. The
driver uses basic primitives, has correct functionality, and I
reviewed the code. Licensing is clean too. Comments need tweaking, but
that's always the case for a V1. I would spend some TLC before I
deploy it making sure it loads and unloads correctly and there are no
edge cases, but for that to happen, I need a stable ABI otherwise my
userspace will drift, and that's no different than not using AI
assistance.

Speaking of Nvidia and vibing, here is a complete OOT kernel driver
written by an LLM [1] that enables full TDP controls and hwmon
monitoring on a DGX spark using the Steam Deck ABI and its Mediatek
chipset. Sasha, you might be interested in it. Claude decoded the DSDT
tables, wrote the driver, and tested it. It wrote the readme too.
Yeah, sure its ABI choices were not the best, but that's nothing some
prompting can't fix. To be fair, it did not do everything, I tab
aligned the constants and tweaked the readme and some of the comments
:) Things are evolving rapidly to say the least.

Antheas

[1] https://github.com/antheas/spark_hwmon

> --
> Thanks,
> Sasha
>