Message-ID: <CANvS2vWNrib9TXenDjUemCfJjU14LVJcq42GW7XZ11=6egWPRQ@mail.gmail.com>
Date: Thu, 4 Sep 2025 03:28:08 +0300
From: Cezar Chiru <chiru.cezar.89@...il.com>
To: Wolfram Sang <wsa+renesas@...g-engineering.com>, Andi Shyti <andi.shyti@...nel.org>
Cc: 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

Hello Andi, Wolfram,

Resending email to entire receipients in plain text mode from Gmail
client with linux-i2c@...r.kernel.org and linux-kernel@...r.kernel.org
who rejected the email as being not plain mode. I thought maybe you
didn't receive it. sorry if I sent twice..

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.
I will be back to you with next patches by Sunday night. Sorry for the
long email but I wanted you to know the whole process I did to submit
the patches.

Best regards,
Cezar Chiru


On Wed, Sep 3, 2025 at 10:25 PM Cezar Chiru <chiru.cezar.89@...il.com> wrote:
>
> Hello Andi, Wolfram,
>
> 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.
>
> Best regards,
> Cezar Chiru
>
> On Wed, Sep 3, 2025 at 8:15 PM Wolfram Sang <wsa+renesas@...g-engineering.com> wrote:
>>
>> On Wed, Sep 03, 2025 at 06:56:12PM +0200, Andi Shyti wrote:
>> > Hi Cezar,
>> >
>> > On Sat, Aug 30, 2025 at 12:30:15PM +0300, Cezar Chiru wrote:
>> > > Fixed some coding style errors and warnings plus some minor changes
>> > > in code as reported by checkpatch script. The busses/ and muxes/
>> > > subfolders will be dealt with another commit. Main changes were done
>> > > to comments, defines of 'if' statement, swapping 'unsigned' with
>> > > 'unsigned int' and other minor changes.
>> > >
>> > > Signed-off-by: Cezar Chiru <chiru.cezar.89@...il.com>
>> > > ---
>> > >  drivers/i2c/Kconfig              |  2 +-
>> > >  drivers/i2c/algos/i2c-algo-bit.c | 29 +++++++++------
>> > >  drivers/i2c/algos/i2c-algo-pca.c | 25 +++++++++----
>> > >  drivers/i2c/algos/i2c-algo-pcf.c | 61 ++++++++++++++++++++++----------
>> > >  drivers/i2c/algos/i2c-algo-pcf.h | 10 +++---
>> > >  drivers/i2c/i2c-boardinfo.c      |  2 +-
>> > >  drivers/i2c/i2c-core-base.c      | 59 +++++++++++++++++++-----------
>> > >  drivers/i2c/i2c-dev.c            | 47 ++++++++++++++----------
>> > >  drivers/i2c/i2c-mux.c            |  1 +
>> > >  drivers/i2c/i2c-slave-eeprom.c   |  2 +-
>> > >  drivers/i2c/i2c-smbus.c          |  2 +-
>> > >  drivers/i2c/i2c-stub.c           | 29 +++++++--------
>> > >  12 files changed, 170 insertions(+), 99 deletions(-)
>> >
>> > first of all, thanks for your patch, but I can't accept it.
>> > Please split your patch in several smaller patches with single
>> > changes.
>> >
>> > Granularity is very important for reviews and git blame.
>>
>> Same comment as previous patch: describe testing please
>>

Powered by blists - more mailing lists