[RFC] Maintainer entry profile/contributor guide for IIO

[RFC] Maintainer entry profile/contributor guide for IIO

[Joshua Crofts]

Hi all,

I was browsing lore and checked out the ksummit mailing list, where the
topic about guiding new contributors arose [1]. New contributors tend to
make the same mistakes when sending patches, causing reviewers to point
these out all the time over and over again. For IIO, this is definitely the
case (I myself send an email telling people not to send a v2 in reply to a
v1 several times a week). Other subsystems have a "Maintainer entry profile"
that contains subsystem-specific process info (DAMON for example [2]) and 
(sometimes even [3]) a document describing the code style of the subsystem
(this would be a great place where to mention things like not using
kernel.h in new drivers etc.). I'm happy to create both of the documents
but it's always great to hear other people's ideas! 

Second of all, the idea of having a bot that would automatically detect new
contributors (i.e. the email they're submitting the patch with doesn't show
up in `git log --author`) and send an email reminding them of the basic rules
(while also referring to the entry profile mentioned above) sounds like a
great idea, but of course hosting and maintaining are pain points.

Please let me know what you think of the above ideas!

[1] https://lore.kernel.org/ksummit/87y0ekm9nw.fsf@trenco.lwn.net/
[2] https://github.com/torvalds/linux/blob/master/Documentation/mm/damon/maintainer-profile.rst
[3] https://github.com/torvalds/linux/blob/master/Documentation/hwmon/submitting-patches.rst

-- 
Kind regards,
Joshua Crofts

Re: [RFC] Maintainer entry profile/contributor guide for IIO

[Maxwell Doose]

On Mon Aug 17, 2026 at 4:18 AM CDT
Joshua Crofts <joshua.crofts1@gmail.com> wrote:

> Hi all,
>
> I was browsing lore and checked out the ksummit mailing list, where the
> topic about guiding new contributors arose [1]. New contributors tend to
> make the same mistakes when sending patches, causing reviewers to point
> these out all the time over and over again. For IIO, this is definitely the
> case (I myself send an email telling people not to send a v2 in reply to a
> v1 several times a week). Other subsystems have a "Maintainer entry profile"
> that contains subsystem-specific process info (DAMON for example [2]) and 
> (sometimes even [3]) a document describing the code style of the subsystem
> (this would be a great place where to mention things like not using
> kernel.h in new drivers etc.). I'm happy to create both of the documents
> but it's always great to hear other people's ideas! 
>

Took a look at [1] and it looks like these are issues across multiple
mailing lists so maybe we should add these to the main
submitting-patches documentation? And then for other IIO-specific things
we can put those in a maintainer entry profile.

> Second of all, the idea of having a bot that would automatically detect new
> contributors (i.e. the email they're submitting the patch with doesn't show
> up in `git log --author`) and send an email reminding them of the basic rules
> (while also referring to the entry profile mentioned above) sounds like a
> great idea, but of course hosting and maintaining are pain points.
>

Hm...this one is more difficult. I guess a good first question to ask
would be "can this be hosted on kernel.org infastructure?" But maybe we
can also ask Greg KH about how he does his automated bot.

thanks,
max

> Please let me know what you think of the above ideas!
>
> [1] https://lore.kernel.org/ksummit/87y0ekm9nw.fsf@trenco.lwn.net/
> [2] https://github.com/torvalds/linux/blob/master/Documentation/mm/damon/maintainer-profile.rst
> [3] https://github.com/torvalds/linux/blob/master/Documentation/hwmon/submitting-patches.rst

Re: [RFC] Maintainer entry profile/contributor guide for IIO

[Joshua Crofts]

On Mon, 17 Aug 2026 13:50:29 -0500
"Maxwell Doose" <maxwell@maxwelld.cc> wrote:

> On Mon Aug 17, 2026 at 4:18 AM CDT
> Joshua Crofts <joshua.crofts1@gmail.com> wrote:
> 
> > Hi all,
> >
> > I was browsing lore and checked out the ksummit mailing list, where the
> > topic about guiding new contributors arose [1]. New contributors tend to
> > make the same mistakes when sending patches, causing reviewers to point
> > these out all the time over and over again. For IIO, this is definitely the
> > case (I myself send an email telling people not to send a v2 in reply to a
> > v1 several times a week). Other subsystems have a "Maintainer entry profile"
> > that contains subsystem-specific process info (DAMON for example [2]) and 
> > (sometimes even [3]) a document describing the code style of the subsystem
> > (this would be a great place where to mention things like not using
> > kernel.h in new drivers etc.). I'm happy to create both of the documents
> > but it's always great to hear other people's ideas! 
> >  
> 
> Took a look at [1] and it looks like these are issues across multiple
> mailing lists so maybe we should add these to the main
> submitting-patches documentation? And then for other IIO-specific things
> we can put those in a maintainer entry profile.

Fair, the "don't reply with a v2 to a v1" comment was a bit off considering
I was mainly talking about IIO specific documentation, however having a central
document (or documents) of sorts for the IIO code style and process is a nice
thing to have, I'm sure even the most seasoned reviewers forget stuff occasionally.

> 
> > Second of all, the idea of having a bot that would automatically detect new
> > contributors (i.e. the email they're submitting the patch with doesn't show
> > up in `git log --author`) and send an email reminding them of the basic rules
> > (while also referring to the entry profile mentioned above) sounds like a
> > great idea, but of course hosting and maintaining are pain points.
> >  
> 
> Hm...this one is more difficult. I guess a good first question to ask
> would be "can this be hosted on kernel.org infastructure?" But maybe we
> can also ask Greg KH about how he does his automated bot.

From what I gathered, kernel.org doesn't really provide infrastructure for this
type of stuff :( If you look at [1] you see that netdev got overloaded with patches
so they made their own bot for this exact purpose. One could just spin up a
Docker container that periodically pulls from lore using lei and runs a git log
with the author's email against mainline/testing/togreg.

I believe it was David who originally proposed an IIO bot [1], primarily for code
inspection.

[1] https://lore.kernel.org/all/4742ea18-f3df-46dd-aad4-18d1e5f03f7f@baylibre.com/

-- 
Kind regards,
Joshua Crofts

Re: [RFC] Maintainer entry profile/contributor guide for IIO

[David Lechner]

On 8/17/26 4:18 AM, Joshua Crofts wrote:
> Hi all,
> 
> I was browsing lore and checked out the ksummit mailing list, where the
> topic about guiding new contributors arose [1]. New contributors tend to
> make the same mistakes when sending patches, causing reviewers to point
> these out all the time over and over again. For IIO, this is definitely the
> case (I myself send an email telling people not to send a v2 in reply to a
> v1 several times a week). Other subsystems have a "Maintainer entry profile"
> that contains subsystem-specific process info (DAMON for example [2]) and 
> (sometimes even [3]) a document describing the code style of the subsystem
> (this would be a great place where to mention things like not using
> kernel.h in new drivers etc.). I'm happy to create both of the documents
> but it's always great to hear other people's ideas! 

I think there are plenty of new contributor (to the kernel) guides out there.
People just don't read them. So I don't think we need another. Nothing wrong
with trying to make the existing guides more clear/easy to understand though.

A subsystem doc that has our code style quirks and idioms would be helpful
though as I don't think that has every been written down in a single place.
Especially useful now since AI reviewers will read it even if humans don't.

> 
> Second of all, the idea of having a bot that would automatically detect new
> contributors (i.e. the email they're submitting the patch with doesn't show
> up in `git log --author`) and send an email reminding them of the basic rules
> (while also referring to the entry profile mentioned above) sounds like a
> great idea, but of course hosting and maintaining are pain points.
> 
> Please let me know what you think of the above ideas!
> 
> [1] https://lore.kernel.org/ksummit/87y0ekm9nw.fsf@trenco.lwn.net/
> [2] https://github.com/torvalds/linux/blob/master/Documentation/mm/damon/maintainer-profile.rst
> [3] https://github.com/torvalds/linux/blob/master/Documentation/hwmon/submitting-patches.rst
> 

Re: [RFC] Maintainer entry profile/contributor guide for IIO

[Joshua Crofts]

On Mon, 17 Aug 2026 19:31:45 -0500
David Lechner <dlechner@baylibre.com> wrote:

> On 8/17/26 4:18 AM, Joshua Crofts wrote:
> > Hi all,
> > 
> > I was browsing lore and checked out the ksummit mailing list, where the
> > topic about guiding new contributors arose [1]. New contributors tend to
> > make the same mistakes when sending patches, causing reviewers to point
> > these out all the time over and over again. For IIO, this is definitely the
> > case (I myself send an email telling people not to send a v2 in reply to a
> > v1 several times a week). Other subsystems have a "Maintainer entry profile"
> > that contains subsystem-specific process info (DAMON for example [2]) and 
> > (sometimes even [3]) a document describing the code style of the subsystem
> > (this would be a great place where to mention things like not using
> > kernel.h in new drivers etc.). I'm happy to create both of the documents
> > but it's always great to hear other people's ideas!   
> 
> I think there are plenty of new contributor (to the kernel) guides out there.
> People just don't read them. So I don't think we need another. Nothing wrong
> with trying to make the existing guides more clear/easy to understand though.
> 
> A subsystem doc that has our code style quirks and idioms would be helpful
> though as I don't think that has every been written down in a single place.
> Especially useful now since AI reviewers will read it even if humans don't.

Yes, but it shouldn't be limited to code style quirks - I highly doubt new
contributors develop against the togreg tree of iio.git for example.

I'd propose 2 documents:
- entry profile - documenting the review cycle, patchwork, point people over to
  Sashiko, relevant git tree etc.
- code style - the TODO is fine for existing problems in the subsystem but doesn't
  point out idioms we have in IIO, i.e. not using (the awful) kernel.h, preferring
  devm_* functions, not failing on a mismatched ID to ensure fallback etc. This is
  stuff that appears a lot in patches.

Whether new contributors read these is up to them (from my experience if you write
decent docs people still won't read them and ask pointless questions), nevertheless
if we suspect someone is new we can just point them to these documents instead of
reiterating the same over and over again.

-- 
Kind regards,
Joshua Crofts

Re: [RFC] Maintainer entry profile/contributor guide for IIO

[Krzysztof Kozlowski]

On 18/08/2026 09:06, Joshua Crofts wrote:
> On Mon, 17 Aug 2026 19:31:45 -0500
> David Lechner <dlechner@baylibre.com> wrote:
> 
>> On 8/17/26 4:18 AM, Joshua Crofts wrote:
>>> Hi all,
>>>
>>> I was browsing lore and checked out the ksummit mailing list, where the
>>> topic about guiding new contributors arose [1]. New contributors tend to
>>> make the same mistakes when sending patches, causing reviewers to point
>>> these out all the time over and over again. For IIO, this is definitely the

New contributors do the same mistakes because they do not read existing
documentation, thus one more documentation won't solve it.

>>> case (I myself send an email telling people not to send a v2 in reply to a
>>> v1 several times a week). Other subsystems have a "Maintainer entry profile"
>>> that contains subsystem-specific process info (DAMON for example [2]) and 
>>> (sometimes even [3]) a document describing the code style of the subsystem
>>> (this would be a great place where to mention things like not using
>>> kernel.h in new drivers etc.). I'm happy to create both of the documents
>>> but it's always great to hear other people's ideas!   
>>
>> I think there are plenty of new contributor (to the kernel) guides out there.
>> People just don't read them. So I don't think we need another. Nothing wrong
>> with trying to make the existing guides more clear/easy to understand though.
>>
>> A subsystem doc that has our code style quirks and idioms would be helpful
>> though as I don't think that has every been written down in a single place.
>> Especially useful now since AI reviewers will read it even if humans don't.
> 
> Yes, but it shouldn't be limited to code style quirks - I highly doubt new
> contributors develop against the togreg tree of iio.git for example.
> 
> I'd propose 2 documents:
> - entry profile - documenting the review cycle, patchwork, point people over to
>   Sashiko, relevant git tree etc.

Maintainers file already defines git tree. Patchwork as well. Please
read existing docs first, because it seems you propose to duplicate it
(including submitting patches and other process documents).

Subsystem profiles are expected to document things which are done here a
bit differently or specific subsystem expectations, narrowing general
kernel process docs.


> - code style - the TODO is fine for existing problems in the subsystem but doesn't
>   point out idioms we have in IIO, i.e. not using (the awful) kernel.h, preferring
>   devm_* functions, not failing on a mismatched ID to ensure fallback etc. This is
>   stuff that appears a lot in patches.

You just described standard kernel practice. Don't create documents just
for sake of creating them.

> 
> Whether new contributors read these is up to them (from my experience if you write
> decent docs people still won't read them and ask pointless questions), nevertheless
> if we suspect someone is new we can just point them to these documents instead of
> reiterating the same over and over again.

You can already point them to existing docs.


Best regards,
Krzysztof

Re: [RFC] Maintainer entry profile/contributor guide for IIO

[Joshua Crofts]

On Sat, 19 Sep 2026 10:38:13 +0200
Krzysztof Kozlowski <krzk@kernel.org> wrote:

> On 18/08/2026 09:06, Joshua Crofts wrote:
> > On Mon, 17 Aug 2026 19:31:45 -0500
> > David Lechner <dlechner@baylibre.com> wrote:
> >   
> >> On 8/17/26 4:18 AM, Joshua Crofts wrote:  
> >>> Hi all,
> >>>
> >>> I was browsing lore and checked out the ksummit mailing list, where the
> >>> topic about guiding new contributors arose [1]. New contributors tend to
> >>> make the same mistakes when sending patches, causing reviewers to point
> >>> these out all the time over and over again. For IIO, this is definitely the  
> 
> New contributors do the same mistakes because they do not read existing
> documentation, thus one more documentation won't solve it.
> 
> >>> case (I myself send an email telling people not to send a v2 in reply to a
> >>> v1 several times a week). Other subsystems have a "Maintainer entry profile"
> >>> that contains subsystem-specific process info (DAMON for example [2]) and 
> >>> (sometimes even [3]) a document describing the code style of the subsystem
> >>> (this would be a great place where to mention things like not using
> >>> kernel.h in new drivers etc.). I'm happy to create both of the documents
> >>> but it's always great to hear other people's ideas!     
> >>
> >> I think there are plenty of new contributor (to the kernel) guides out there.
> >> People just don't read them. So I don't think we need another. Nothing wrong
> >> with trying to make the existing guides more clear/easy to understand though.
> >>
> >> A subsystem doc that has our code style quirks and idioms would be helpful
> >> though as I don't think that has every been written down in a single place.
> >> Especially useful now since AI reviewers will read it even if humans don't.  
> > 
> > Yes, but it shouldn't be limited to code style quirks - I highly doubt new
> > contributors develop against the togreg tree of iio.git for example.
> > 
> > I'd propose 2 documents:
> > - entry profile - documenting the review cycle, patchwork, point people over to
> >   Sashiko, relevant git tree etc.  
> 
> Maintainers file already defines git tree. Patchwork as well. Please
> read existing docs first, because it seems you propose to duplicate it
> (including submitting patches and other process documents).
> 
> Subsystem profiles are expected to document things which are done here a
> bit differently or specific subsystem expectations, narrowing general
> kernel process docs.
> 
> 
> > - code style - the TODO is fine for existing problems in the subsystem but doesn't
> >   point out idioms we have in IIO, i.e. not using (the awful) kernel.h, preferring
> >   devm_* functions, not failing on a mismatched ID to ensure fallback etc. This is
> >   stuff that appears a lot in patches.  
> 
> You just described standard kernel practice. Don't create documents just
> for sake of creating them.

I'd like you to point me to a doc that says that fallbacks are a thing
and you shouldn't do dev_err_probe() on a bad ID (to name one "quirk").

Otherwise I agree that some of it is repetitive.

-- 
Kind regards,
Joshua Crofts

Re: [RFC] Maintainer entry profile/contributor guide for IIO

[Krzysztof Kozlowski]

On 19/09/2026 11:35, Joshua Crofts wrote:
> On Sat, 19 Sep 2026 10:38:13 +0200
> Krzysztof Kozlowski <krzk@kernel.org> wrote:
> 
>> On 18/08/2026 09:06, Joshua Crofts wrote:
>>> On Mon, 17 Aug 2026 19:31:45 -0500
>>> David Lechner <dlechner@baylibre.com> wrote:
>>>   
>>>> On 8/17/26 4:18 AM, Joshua Crofts wrote:  
>>>>> Hi all,
>>>>>
>>>>> I was browsing lore and checked out the ksummit mailing list, where the
>>>>> topic about guiding new contributors arose [1]. New contributors tend to
>>>>> make the same mistakes when sending patches, causing reviewers to point
>>>>> these out all the time over and over again. For IIO, this is definitely the  
>>
>> New contributors do the same mistakes because they do not read existing
>> documentation, thus one more documentation won't solve it.
>>
>>>>> case (I myself send an email telling people not to send a v2 in reply to a
>>>>> v1 several times a week). Other subsystems have a "Maintainer entry profile"
>>>>> that contains subsystem-specific process info (DAMON for example [2]) and 
>>>>> (sometimes even [3]) a document describing the code style of the subsystem
>>>>> (this would be a great place where to mention things like not using
>>>>> kernel.h in new drivers etc.). I'm happy to create both of the documents
>>>>> but it's always great to hear other people's ideas!     
>>>>
>>>> I think there are plenty of new contributor (to the kernel) guides out there.
>>>> People just don't read them. So I don't think we need another. Nothing wrong
>>>> with trying to make the existing guides more clear/easy to understand though.
>>>>
>>>> A subsystem doc that has our code style quirks and idioms would be helpful
>>>> though as I don't think that has every been written down in a single place.
>>>> Especially useful now since AI reviewers will read it even if humans don't.  
>>>
>>> Yes, but it shouldn't be limited to code style quirks - I highly doubt new
>>> contributors develop against the togreg tree of iio.git for example.
>>>
>>> I'd propose 2 documents:
>>> - entry profile - documenting the review cycle, patchwork, point people over to
>>>   Sashiko, relevant git tree etc.  
>>
>> Maintainers file already defines git tree. Patchwork as well. Please
>> read existing docs first, because it seems you propose to duplicate it
>> (including submitting patches and other process documents).
>>
>> Subsystem profiles are expected to document things which are done here a
>> bit differently or specific subsystem expectations, narrowing general
>> kernel process docs.
>>
>>
>>> - code style - the TODO is fine for existing problems in the subsystem but doesn't
>>>   point out idioms we have in IIO, i.e. not using (the awful) kernel.h, preferring
>>>   devm_* functions, not failing on a mismatched ID to ensure fallback etc. This is
>>>   stuff that appears a lot in patches.  
>>
>> You just described standard kernel practice. Don't create documents just
>> for sake of creating them.
> 
> I'd like you to point me to a doc that says that fallbacks are a thing
> and you shouldn't do dev_err_probe() on a bad ID (to name one "quirk").
> 
> Otherwise I agree that some of it is repetitive.

You wrote devm and kernel.h...

Best regards,
Krzysztof

Re: [RFC] Maintainer entry profile/contributor guide for IIO

[Joshua Crofts]

On Sat, 19 Sep 2026 20:53:36 +0200
Krzysztof Kozlowski <krzk@kernel.org> wrote:
> >> Maintainers file already defines git tree. Patchwork as well. Please
> >> read existing docs first, because it seems you propose to duplicate it
> >> (including submitting patches and other process documents).
> >>
> >> Subsystem profiles are expected to document things which are done here a
> >> bit differently or specific subsystem expectations, narrowing general
> >> kernel process docs.
> >>
> >>  
> >>> - code style - the TODO is fine for existing problems in the subsystem but doesn't
> >>>   point out idioms we have in IIO, i.e. not using (the awful) kernel.h, preferring
> >>>   devm_* functions, not failing on a mismatched ID to ensure fallback etc. This is
> >>>   stuff that appears a lot in patches.    
> >>
> >> You just described standard kernel practice. Don't create documents just
> >> for sake of creating them.  
> > 
> > I'd like you to point me to a doc that says that fallbacks are a thing
> > and you shouldn't do dev_err_probe() on a bad ID (to name one "quirk").
> > 
> > Otherwise I agree that some of it is repetitive.  
> 
> You wrote devm and kernel.h...

I was referring to the next paragraph. Yeah, perhaps it's not the greatest
idea to add new docs if people don't read them. Someone should instead come
up with a way to *force* newcomers to read documentation instead.

-- 
Kind regards,
Joshua Crofts

Re: [RFC] Maintainer entry profile/contributor guide for IIO

[Nuno Sá]

On Tue, Aug 18, 2026 at 09:06:52AM +0200, Joshua Crofts wrote:
> On Mon, 17 Aug 2026 19:31:45 -0500
> David Lechner <dlechner@baylibre.com> wrote:
> 
> > On 8/17/26 4:18 AM, Joshua Crofts wrote:
> > > Hi all,
> > > 
> > > I was browsing lore and checked out the ksummit mailing list, where the
> > > topic about guiding new contributors arose [1]. New contributors tend to
> > > make the same mistakes when sending patches, causing reviewers to point
> > > these out all the time over and over again. For IIO, this is definitely the
> > > case (I myself send an email telling people not to send a v2 in reply to a
> > > v1 several times a week). Other subsystems have a "Maintainer entry profile"
> > > that contains subsystem-specific process info (DAMON for example [2]) and 
> > > (sometimes even [3]) a document describing the code style of the subsystem
> > > (this would be a great place where to mention things like not using
> > > kernel.h in new drivers etc.). I'm happy to create both of the documents
> > > but it's always great to hear other people's ideas!   
> > 
> > I think there are plenty of new contributor (to the kernel) guides out there.
> > People just don't read them. So I don't think we need another. Nothing wrong
> > with trying to make the existing guides more clear/easy to understand though.
> > 
> > A subsystem doc that has our code style quirks and idioms would be helpful
> > though as I don't think that has every been written down in a single place.
> > Especially useful now since AI reviewers will read it even if humans don't.
> 
> Yes, but it shouldn't be limited to code style quirks - I highly doubt new
> contributors develop against the togreg tree of iio.git for example.
> 
> I'd propose 2 documents:
> - entry profile - documenting the review cycle, patchwork, point people over to
>   Sashiko, relevant git tree etc.
> - code style - the TODO is fine for existing problems in the subsystem but doesn't
>   point out idioms we have in IIO, i.e. not using (the awful) kernel.h, preferring
>   devm_* functions, not failing on a mismatched ID to ensure fallback etc. This is
>   stuff that appears a lot in patches.

Personally I do think we have some things (not just coding style)  that are very
specific to IIO. But maybe another docs file is not the question. Or at least one
for humans to read :)?! Have you evaluate just having an IIO entry for
sashiko? That way, hopefully the bot would take care about the subsystem
specifics and preferences.

I wanted to do this myself at some point but I'm always pulled for
something else so if this is feels like something you agree and would
like to get done, please go ahead :)

[1]: https://github.com/masoncl/review-prompts/tree/main/kernel/subsystem

My 2 cents!
- Nuno Sá

> 
> Whether new contributors read these is up to them (from my experience if you write
> decent docs people still won't read them and ask pointless questions), nevertheless
> if we suspect someone is new we can just point them to these documents instead of
> reiterating the same over and over again.
> 
> -- 
> Kind regards,
> Joshua Crofts

Re: [RFC] Maintainer entry profile/contributor guide for IIO

[Joshua Crofts]

On Mon, 21 Sep 2026 10:28:24 +0100
Nuno Sá <nuno.sa@analog.com> wrote:
> > I'd propose 2 documents:
> > - entry profile - documenting the review cycle, patchwork, point people over to
> >   Sashiko, relevant git tree etc.
> > - code style - the TODO is fine for existing problems in the subsystem but doesn't
> >   point out idioms we have in IIO, i.e. not using (the awful) kernel.h, preferring
> >   devm_* functions, not failing on a mismatched ID to ensure fallback etc. This is
> >   stuff that appears a lot in patches.  
> 
> Personally I do think we have some things (not just coding style)  that are very
> specific to IIO. But maybe another docs file is not the question. Or at least one
> for humans to read :)?! Have you evaluate just having an IIO entry for
> sashiko? That way, hopefully the bot would take care about the subsystem
> specifics and preferences.
> 
> I wanted to do this myself at some point but I'm always pulled for
> something else so if this is feels like something you agree and would
> like to get done, please go ahead :)
> 
> [1]: https://github.com/masoncl/review-prompts/tree/main/kernel/subsystem
> 
> My 2 cents!
> - Nuno Sá

There was a thread about adding Sashiko reviews to IIO but it died out :(
I proposed adding an IIO-specific prompt. Any ideas on what it should contain?

As Krzysztof says, there isn't really a point in making a new doc as people
just don't read docs (I know I didn't when I was starting out, but perhaps
just consulting with an LLM was a mistake :) )

-- 
Kind regards,
Joshua Crofts

Re: [RFC] Maintainer entry profile/contributor guide for IIO

[Nuno Sá]

On Tue, Sep 22, 2026 at 04:51:24PM +0200, Joshua Crofts wrote:
> On Mon, 21 Sep 2026 10:28:24 +0100
> Nuno Sá <nuno.sa@analog.com> wrote:
> > > I'd propose 2 documents:
> > > - entry profile - documenting the review cycle, patchwork, point people over to
> > >   Sashiko, relevant git tree etc.
> > > - code style - the TODO is fine for existing problems in the subsystem but doesn't
> > >   point out idioms we have in IIO, i.e. not using (the awful) kernel.h, preferring
> > >   devm_* functions, not failing on a mismatched ID to ensure fallback etc. This is
> > >   stuff that appears a lot in patches.  
> > 
> > Personally I do think we have some things (not just coding style)  that are very
> > specific to IIO. But maybe another docs file is not the question. Or at least one
> > for humans to read :)?! Have you evaluate just having an IIO entry for
> > sashiko? That way, hopefully the bot would take care about the subsystem
> > specifics and preferences.
> > 
> > I wanted to do this myself at some point but I'm always pulled for
> > something else so if this is feels like something you agree and would
> > like to get done, please go ahead :)
> > 
> > [1]: https://github.com/masoncl/review-prompts/tree/main/kernel/subsystem
> > 
> > My 2 cents!
> > - Nuno Sá
> 
> There was a thread about adding Sashiko reviews to IIO but it died out :(
> I proposed adding an IIO-specific prompt. Any ideas on what it should contain?

Not sure if I get the above. I already see sashiko doing reviews in IIO?
What am I missing?

What I mean is adding specialized IIO preferences/tecnical details to it. And for that
we need to add a new iio.md in [1] and a table entry in [2]. If I'm not
missing anything.

Sashiko is using the review prompt repo.

[1]: https://github.com/masoncl/review-prompts/tree/main/kernel/subsystem
[2]: https://github.com/masoncl/review-prompts/blob/main/kernel/subsystem/subsystem.md

- Nuno Sá

> 
> As Krzysztof says, there isn't really a point in making a new doc as people
> just don't read docs (I know I didn't when I was starting out, but perhaps
> just consulting with an LLM was a mistake :) )
> 
> -- 
> Kind regards,
> Joshua Crofts

Re: [RFC] Maintainer entry profile/contributor guide for IIO

[Joshua Crofts]

On Tue, 22 Sep 2026 16:03:26 +0100
Nuno Sá <nuno.sa@analog.com> wrote:

> On Tue, Sep 22, 2026 at 04:51:24PM +0200, Joshua Crofts wrote:
> > On Mon, 21 Sep 2026 10:28:24 +0100
> > Nuno Sá <nuno.sa@analog.com> wrote:  
> > > > I'd propose 2 documents:
> > > > - entry profile - documenting the review cycle, patchwork, point people over to
> > > >   Sashiko, relevant git tree etc.
> > > > - code style - the TODO is fine for existing problems in the subsystem but doesn't
> > > >   point out idioms we have in IIO, i.e. not using (the awful) kernel.h, preferring
> > > >   devm_* functions, not failing on a mismatched ID to ensure fallback etc. This is
> > > >   stuff that appears a lot in patches.    
> > > 
> > > Personally I do think we have some things (not just coding style)  that are very
> > > specific to IIO. But maybe another docs file is not the question. Or at least one
> > > for humans to read :)?! Have you evaluate just having an IIO entry for
> > > sashiko? That way, hopefully the bot would take care about the subsystem
> > > specifics and preferences.
> > > 
> > > I wanted to do this myself at some point but I'm always pulled for
> > > something else so if this is feels like something you agree and would
> > > like to get done, please go ahead :)
> > > 
> > > [1]: https://github.com/masoncl/review-prompts/tree/main/kernel/subsystem
> > > 
> > > My 2 cents!
> > > - Nuno Sá  
> > 
> > There was a thread about adding Sashiko reviews to IIO but it died out :(
> > I proposed adding an IIO-specific prompt. Any ideas on what it should contain?  
> 
> Not sure if I get the above. I already see sashiko doing reviews in IIO?
> What am I missing?
> 
> What I mean is adding specialized IIO preferences/tecnical details to it. And for that
> we need to add a new iio.md in [1] and a table entry in [2]. If I'm not
> missing anything.
> 
> Sashiko is using the review prompt repo.
> 

Yes, that is what I meant, adding iio.md (or something like that). I believe Sashiko
pulls prompts from here [1] (?).

[1] https://github.com/sashiko-dev/sashiko/blob/main/third_party/prompts/kernel/subsystem/hwmon.md

-- 
Kind regards,
Joshua Crofts

Re: [RFC] Maintainer entry profile/contributor guide for IIO

[Nuno Sá]

On Tue, Sep 22, 2026 at 05:07:34PM +0200, Joshua Crofts wrote:
> On Tue, 22 Sep 2026 16:03:26 +0100
> Nuno Sá <nuno.sa@analog.com> wrote:
> 
> > On Tue, Sep 22, 2026 at 04:51:24PM +0200, Joshua Crofts wrote:
> > > On Mon, 21 Sep 2026 10:28:24 +0100
> > > Nuno Sá <nuno.sa@analog.com> wrote:  
> > > > > I'd propose 2 documents:
> > > > > - entry profile - documenting the review cycle, patchwork, point people over to
> > > > >   Sashiko, relevant git tree etc.
> > > > > - code style - the TODO is fine for existing problems in the subsystem but doesn't
> > > > >   point out idioms we have in IIO, i.e. not using (the awful) kernel.h, preferring
> > > > >   devm_* functions, not failing on a mismatched ID to ensure fallback etc. This is
> > > > >   stuff that appears a lot in patches.    
> > > > 
> > > > Personally I do think we have some things (not just coding style)  that are very
> > > > specific to IIO. But maybe another docs file is not the question. Or at least one
> > > > for humans to read :)?! Have you evaluate just having an IIO entry for
> > > > sashiko? That way, hopefully the bot would take care about the subsystem
> > > > specifics and preferences.
> > > > 
> > > > I wanted to do this myself at some point but I'm always pulled for
> > > > something else so if this is feels like something you agree and would
> > > > like to get done, please go ahead :)
> > > > 
> > > > [1]: https://github.com/masoncl/review-prompts/tree/main/kernel/subsystem
> > > > 
> > > > My 2 cents!
> > > > - Nuno Sá  
> > > 
> > > There was a thread about adding Sashiko reviews to IIO but it died out :(
> > > I proposed adding an IIO-specific prompt. Any ideas on what it should contain?  
> > 
> > Not sure if I get the above. I already see sashiko doing reviews in IIO?
> > What am I missing?
> > 
> > What I mean is adding specialized IIO preferences/tecnical details to it. And for that
> > we need to add a new iio.md in [1] and a table entry in [2]. If I'm not
> > missing anything.
> > 
> > Sashiko is using the review prompt repo.
> > 
> 
> Yes, that is what I meant, adding iio.md (or something like that). I believe Sashiko
> pulls prompts from here [1] (?).

For hwmon yes. For iio we would need our own set of rules. AFAIK, sashiko will
use the entries in [2] (see my previous email) so that it will pull the
proper subsystem set of rules. Given we have none, it probably uses the
more generic technical patterns. Basically this why I suggested to have
an iio.md for the bot rather than other howto doc in tree.

- Nuno Sá

> 
> [1] https://github.com/sashiko-dev/sashiko/blob/main/third_party/prompts/kernel/subsystem/hwmon.md
> 
> -- 
> Kind regards,
> Joshua Crofts

Re: [RFC] Maintainer entry profile/contributor guide for IIO

[Joshua Crofts]

On Tue, 22 Sep 2026 16:44:07 +0100
Nuno Sá <nuno.sa@analog.com> wrote:

> On Tue, Sep 22, 2026 at 05:07:34PM +0200, Joshua Crofts wrote:
> > On Tue, 22 Sep 2026 16:03:26 +0100
> > Nuno Sá <nuno.sa@analog.com> wrote:
> >   
> > > On Tue, Sep 22, 2026 at 04:51:24PM +0200, Joshua Crofts wrote:  
> > > > On Mon, 21 Sep 2026 10:28:24 +0100
> > > > Nuno Sá <nuno.sa@analog.com> wrote:    
> > > > > > I'd propose 2 documents:
> > > > > > - entry profile - documenting the review cycle, patchwork, point people over to
> > > > > >   Sashiko, relevant git tree etc.
> > > > > > - code style - the TODO is fine for existing problems in the subsystem but doesn't
> > > > > >   point out idioms we have in IIO, i.e. not using (the awful) kernel.h, preferring
> > > > > >   devm_* functions, not failing on a mismatched ID to ensure fallback etc. This is
> > > > > >   stuff that appears a lot in patches.      
> > > > > 
> > > > > Personally I do think we have some things (not just coding style)  that are very
> > > > > specific to IIO. But maybe another docs file is not the question. Or at least one
> > > > > for humans to read :)?! Have you evaluate just having an IIO entry for
> > > > > sashiko? That way, hopefully the bot would take care about the subsystem
> > > > > specifics and preferences.
> > > > > 
> > > > > I wanted to do this myself at some point but I'm always pulled for
> > > > > something else so if this is feels like something you agree and would
> > > > > like to get done, please go ahead :)
> > > > > 
> > > > > [1]: https://github.com/masoncl/review-prompts/tree/main/kernel/subsystem
> > > > > 
> > > > > My 2 cents!
> > > > > - Nuno Sá    
> > > > 
> > > > There was a thread about adding Sashiko reviews to IIO but it died out :(
> > > > I proposed adding an IIO-specific prompt. Any ideas on what it should contain?    
> > > 
> > > Not sure if I get the above. I already see sashiko doing reviews in IIO?
> > > What am I missing?
> > > 
> > > What I mean is adding specialized IIO preferences/tecnical details to it. And for that
> > > we need to add a new iio.md in [1] and a table entry in [2]. If I'm not
> > > missing anything.
> > > 
> > > Sashiko is using the review prompt repo.
> > >   
> > 
> > Yes, that is what I meant, adding iio.md (or something like that). I believe Sashiko
> > pulls prompts from here [1] (?).  
> 
> For hwmon yes. For iio we would need our own set of rules. AFAIK, sashiko will
> use the entries in [2] (see my previous email) so that it will pull the
> proper subsystem set of rules. Given we have none, it probably uses the
> more generic technical patterns. Basically this why I suggested to have
> an iio.md for the bot rather than other howto doc in tree.
> 

Yes, I should've clarified the hwmon entry is just an example :)

I guess the only thing that remains is to write the prompt.

-- 
Kind regards,
Joshua Crofts