On Thu, Jul 20, 2023 at 07:23:56PM +0100, Edward Cree wrote:

On 19/07/2023 19:32, Jakub Kicinski wrote:

quoted

We appear to have a gap in our process docs. We go into detail
on how to contribute code to the kernel, and how to be a subsystem
maintainer. I can't find any docs directed towards the thousands
of small scale maintainers, like folks maintaining a single driver
or a single network protocol.

Document our expectations and best practices. I'm hoping this doc
will be particularly useful to set expectations with HW vendors.

Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Reviewed-by: Mark Brown <broonie@kernel.org>
Reviewed-by: Leon Romanovsky <leonro@nvidia.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
---

Thanks for writing this.  One question—

quoted

+Reviews
+-------
+
+Maintainers must review *all* patches touching exclusively their drivers,
+no matter how trivial. If the patch is a tree wide change and modifies
+multiple drivers - whether to provide a review is left to the maintainer.

Does this apply even to "checkpatch cleanup patch spam", where other patches
 sprayed from the same source (perhaps against other drivers) have already
 been nacked as worthless churn?  I've generally been assuming I can ignore
 those, do I need to make sure to explicitly respond with typically a repeat
 of what's already been said elsewhere?

No, you can ignore them if you don't want to take them :)