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

[Joshua Crofts <joshua.crofts1@gmail.com>]

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