[<prev] [next>] [day] [month] [year] [list]
Message-ID: <vovtxpuwsdncuzwzr4kygpwcw2nhzabxi4aaxaejczt3catiby@zqr45leuglav>
Date: Thu, 4 Sep 2025 14:37:18 +0200
From: Andi Shyti <andi.shyti@...nel.org>
To: Cezar Chiru <chiru.cezar.89@...il.com>
Cc: Wolfram Sang <wsa+renesas@...g-engineering.com>, peda@...ntia.se,
jdelvare@...e.com, linux-i2c@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] i2c: Main i2c-*.c files and algos/ subdirectory : Fix
errors and warnings generated by checkpatch
Hi Cezar,
I think your first email reached everyone.
On Wed, Sep 03, 2025 at 10:25:41PM +0300, Cezar Chiru wrote:
> I am new to submitting linux kernel patches. The first patch i submitted "
> [PATCH] Fix checkpatch.pl warnings and errors in i2c driver directory and
> subdirectories" was wrong and also missed signed--off--by git signature. Some
> change i made originally broke the build . I rushed and sent it before I built
> the kernel and modules. rookie mistake.
> But on the second patch I submitted, I built the kernel and modules after i
> made the changes and fixed the build errors. I activated all i2c external
> modules and built in modules in the .config under Device Drivers---> I2C in the
> menuconfig. But didn't tested the kernel on my linux laptop and didn't loaded
> all the external modules to see if they generate dmesg errors.
> I plan to resubmit and break down changes from 1 commit to several commits
> (patches) as Andi suggested. I will create a commit in git explaining how the
> patches apply (their order) and this patch can be disregarded. And along with
> it i will send 1 patch for each i2c file i submit changes for. Also after I
> commit locally on git the final version of the commits I will create a build
> with everything under Device Drivers---> I2C menuconfig . Upon success I will
> locally test the build on my laptop. load manually all external i2c modules and
> make sure there aren't any dmesg errors and modules are loaded successfully.
> Other than that I don't own any I2C hardware device that I could test with my
> laptop.
> Wolfram, Andi, if you have other ideas on how i could test the i2c
> functionality to make sure i don't break anything with my changes please let me
> know.
> I am a newbie to linux kernel development and want to take it slow with small
> changes in the beginning and then possibly to grow this in a full time Linux
> Kernel Developer career.
First of all, welcome to the community, any effort is
appreciated.
Start small: one file at a time. Some files are affected by
different kind of checkpatch issues, split them in separate
patches.
Before sending a patch make sure that everything builds (if it
doesn't maintainers don't like it) and that checkpatch doesn't
provide errors and warnings.
Woflram asked you how you tested your changes and this is the
major challenge. On one hand I can accept obvious changes, but
for major refactorings, I will require the changes to be tested.
I'm sure you can ask for help for further testing on some
drivers.
Finally make sure you have skimmed through the guidelines:
https://www.kernel.org/doc/html/v4.17/process/submitting-patches.html
https://kernelnewbies.org/KernelHacking
https://www.ietf.org/rfc/rfc1855.txt
The latter tells how to properly write email.
Andi
Powered by blists - more mailing lists