[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ac008fb8-7c82-4b9c-9d24-52ea38b920e5@kernel.org>
Date: Tue, 18 Mar 2025 18:37:06 +0100
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Sergio Pérez <sergio@...eznus.es>,
linux-iio@...r.kernel.org
Cc: tduszyns@...il.com, jic23@...nel.org, lars@...afoo.de, robh@...nel.org,
conor+dt@...nel.org, linux-kernel@...r.kernel.org, devicetree@...r.kernel.org
Subject: Re: [PATCH] iio: light: bh1750: Add hardware reset support via GPIO
On 18/03/2025 18:26, Sergio Pérez wrote:
>
> El 18/03/2025 a las 17:23, Krzysztof Kozlowski escribió:
>> On 18/03/2025 17:21, Krzysztof Kozlowski wrote:
>>> On 18/03/2025 17:06, Sergio Pérez wrote:
>>>> El 18/03/2025 a las 16:16, Krzysztof Kozlowski escribió:
>>>>> On 18/03/2025 15:16, Sergio Pérez wrote:
>>>>>> Hello,
>>>>>>
>>>>>> El 17/03/2025 a las 8:24, Krzysztof Kozlowski escribió:
>>>>>>> On 16/03/2025 15:55, Sergio Perez wrote:
>>>>>>>> Some BH1750 sensors require a hardware reset before they can be
>>>>>>>> detected on the I2C bus. This patch adds support for an optional
>>>>>>>> reset GPIO that can be specified in the device tree.
>>>>>>>>
>>>>>>>> The reset sequence pulls the GPIO low and then high before
>>>>>>>> initializing the sensor, which enables proper detection with
>>>>>>>> tools like i2cdetect.
>>>>>>>>
>>>>>>>> Update the devicetree binding documentation to include the new
>>>>>>>> reset-gpios property with examples.
>>>>>>>>
>>>>>>>> Signed-off-by: Sergio Perez <sergio@...eznus.es>
>>>>>>> Please run scripts/checkpatch.pl and fix reported warnings. After that,
>>>>>>> run also `scripts/checkpatch.pl --strict` and (probably) fix more
>>>>>>> warnings. Some warnings can be ignored, especially from --strict run,
>>>>>>> but the code here looks like it needs a fix. Feel free to get in touch
>>>>>>> if the warning is not clear.
>>>>> You keep ignoring paragraphs. Did you read this?
>>>> I pass this check several times and every time I do any step to make
>>>> sure I am well.
>>>>
>>>> scripts/checkpatch.pl -f drivers/iio/light/bh1750.c
>>>> total: 0 errors, 0 warnings, 354 lines checked
>>>
>>> That's not how you run checkpatch. Read the submitting patches. Just
>>> like the name tells you, check the patch, you run it on the patch.
>> BTW, I wonder which guideline told you to run it on the file? Because
>> checkpatch description and submitting patches tell about running it on
>> the patches, so I wonder where did you get suggestion to run it like that?
> You're absolutely right. I misunderstood how to use checkpatch.pl and
> was incorrectly running it on the source files instead of the patch
> file. Thank you for pointing this out.
>
> $ scripts/checkpatch.pl --strict -f
No '-f'. Don't use such argument. Almost never. Read the help:
" -f
Treat FILE as a regular source file. This option must be used when
running checkpatch on source files in the kernel."
so why do you want a patch file to be a regular source file? How would
it ever work?
> 0001-iio-light-bh1750-Add-hardware-reset-support-via-GPIO.patch
> total: 0 errors, 0 warnings, 0 checks, 102 lines checked
>
> 0001-iio-light-bh1750-Add-hardware-reset-support-via-GPIO.patch has no
> obvious style problems and is ready for submission.
You have clear examples how to run it inside:
https://docs.kernel.org/dev-tools/checkpatch.html
"./scripts/checkpatch.pl mypatch.patch --types EMAIL_SUBJECT,BRACES"
So:
checkpatch.pl mypatch
>
> I've now run the tool correctly on my patch file and have fixed the
> identified issues:
> - Removed trailing whitespace
> - Fixed lines exceeding 79 characters
> - Fixed the inconsistency between the description and example for
> reset-gpios
> - Modified the existing example instead of adding a new one
> - Ensured proper line endings and formatting
> - Used proper get_maintainers.pl to include all recipients
>
Please read the guides carefully. The process is extremely simple as:
git add ...
git commit --signed-off
git format-patch -v3 -2
scripts/chekpatch.pl v3*
scripts/get_maintainers.pl --no-git-fallback v3*
git send-email *
(or just use my git_send_email for last two)
(or just use b4 for last four)
The burden of reading the contributing guides is on you. We documented
all this on purpose, so we will not have to repeat this on every email.
[1]
https://github.com/search?q=repo%3Akrzk%2Ftools%20git_send_email&type=code
Best regards,
Krzysztof
Powered by blists - more mailing lists