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

[Krzysztof Kozlowski <krzk@kernel.org>]

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