Re: [PATCH] Documentation: remove the requirement for LLM attribution

[Lorenzo Stoakes <ljs@kernel.org>]

On Thu, Jul 02, 2026 at 06:28:15PM +0300, Laurent Pinchart wrote:
> Hi Lorenzo,
>
> On Thu, Jul 02, 2026 at 03:57:11PM +0100, Lorenzo Stoakes wrote:
> > I'm a little surprised I'm cc'd on this :) I'm not entirely sure if my pushing
> > back on this is going to mean anything but I suppose here goes nothing.
> >
> > On Thu, Jul 02, 2026 at 10:32:48AM -0400, Jeff Layton wrote:
> > > We've had this requirement in place in the Documentation for several
> > > months, but it's becoming clear that the signal to noise ratio from this
> > > is quite low.
> > >
> > > 1/ It's not universally followed. While many people do try to attribute
> > > the LLMs in good faith, not everyone does for various reasons.
> >
> > Does something not being universally followed therefore make it worthless?
> >
> > You really have to explain that, because this is literally true of any rule
> > whatsoever we might have in the kernel, should we drop all of them?
> >
> > I think you should replace this with a cogent argument such as that you feel it
> > is not being used in the _majority_ of cases or is very rarely used, and that
> > value is in your view not there.
> >
> > >
> > > 2/ It basically serves as free advertising for proprietary LLM companies.
> >
> > I agree with this point, we should drop the model.
> >
> > > 3/ It's not clear why we want to collect this info in the first place.
> >
> > Well I made arguments on the other thread, but to repeat:
> >
> > - It makes it easier to engage with people when they do ack it.
> >
> > - It makes it far quicker to be able to do so.
> >
> > - There's a barrier to mentioning an LLM if it's not provided - people can get
> >   upset, or it can cause issues to raise it as a concern.
> >
> > - Even if it's only there in _some_ cases, it makes _those_ cases easier to deal
> >   with.
>
> As far as I understand, all the above arguments would also be addressed
> with either a free-formed mention of LLM usage, or a formal
> "non-advertising" tag that is not merged in the kernel history, right ?

Well I prefer a tag for reasons below. I'm fine with non-advertising yeah.

>
> > - It provides some (incomplete) data that might make it easier to deal with
> >   bug-causing patches.
> >
> > - It provides some (incomplete) data on bug rates with/without LLMs.
>
> For those two I suppose a machine-parseable tag in the git history could
> improve things slightly compared to information provided in the patch
> submission that would not get recorded in the history.

Yeah, again I could live without it being in the tree. I think there's some
advantages though.

See below for tag argument.

>
> Is this why you have a preference for a formal tag compared to a
> free-formed mention ?
>
> > I do agree they're far far less useful when there's not some indication of how
> > much of the patch was LLM-generated.
> >
> > Their usefulness is obviously deeply far from perfect, but not zero.
> >
> > > Given that the data this provides is flawed at best and is being
> > > collected for a purpose that isn't clear, let's just kill the
> > > requirement for these tags from the kernel at large.
> >
> > I feel there are purposes. Perhaps the argument is stronger for having the tags
> > on submissions rather than actually in-tree, however.
>
> I really think we need to have the information at submission. I think I
> have a slight preference for not recording it in the kernel tree, but
> only slight.

It seems we are more in agreement than it seems :)

I prefer a tag as it's clear cut and easily greppable and easily noticeable.

If it's words it can be vague or be unclear or inconsistent and you might miss
etc.

So I have a strong preference for a tag, would love to add details about how
much LLM done (that'll be vague obviously + have grey lines).

I agree gettig rid of model is worthwhile but I'm not bothered if we don't do
that.

Thanks, Lorenzo