diff mbox series

[3/3] iio: adc: rockchip_saradc: replace custom logic with devm_reset_control_get_optional_exclusive

Message ID 20240223-saradcv2-chan-mask-v1-3-84b06a0f623a@theobroma-systems.com (mailing list archive)
State New, archived
Headers show
Series iio: adc: rockchip_saradc: fix bitmasking and remove custom logic for getting reset | expand

Commit Message

Quentin Schulz Feb. 23, 2024, 12:45 p.m. UTC
From: Quentin Schulz <quentin.schulz@theobroma-systems.com>

devm_reset_control_get_optional_exclusive does what this driver is
trying to do in its probe function, therefore let's switch over to that
subsystem function.

Cc: Quentin Schulz <foss+kernel@0leil.net>
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
---
 drivers/iio/adc/rockchip_saradc.c | 11 +++--------
 1 file changed, 3 insertions(+), 8 deletions(-)

Comments

Andy Shevchenko Feb. 23, 2024, 1 p.m. UTC | #1
On Fri, Feb 23, 2024 at 2:46 PM Quentin Schulz <foss+kernel@0leil.net> wrote:
>
> From: Quentin Schulz <quentin.schulz@theobroma-systems.com>
>
> devm_reset_control_get_optional_exclusive does what this driver is

devm_reset_control_get_optional_exclusive()

> trying to do in its probe function, therefore let's switch over to that

do it in

> subsystem function.

> Cc: Quentin Schulz <foss+kernel@0leil.net>

You may use the --cc option to `git send-email` instead of polluting
commit messages, or move this after the '---' cutter line.
Quentin Schulz Feb. 23, 2024, 1:10 p.m. UTC | #2
Hi Andy,

Thanks for the prompt feedback on the whole series.

On 2/23/24 14:00, Andy Shevchenko wrote:
> On Fri, Feb 23, 2024 at 2:46 PM Quentin Schulz <foss+kernel@0leil.net> wrote:
>>
>> From: Quentin Schulz <quentin.schulz@theobroma-systems.com>
>>
>> devm_reset_control_get_optional_exclusive does what this driver is
> 
> devm_reset_control_get_optional_exclusive()
> 
>> trying to do in its probe function, therefore let's switch over to that
> 
> do it in
> 
>> subsystem function.
> 
>> Cc: Quentin Schulz <foss+kernel@0leil.net>
> 
> You may use the --cc option to `git send-email` instead of polluting
> commit messages, or move this after the '---' cutter line.
> 

The whole point is that my SoB and authorship is from my professional 
mail address which is likely to change over time, the Cc is my personal 
one for development. Basically, in the event that I change my employer, 
I would still be reachable at that Cc address without having to modify 
the .mailmap after the fact (which won't make it to an earlier version 
of the kernel for example). Some maintainers don't really like this, 
some don't mind, we'll see in which category the IIO maintainer(s) fall 
in :) (I don't mind either way just to be clear).

Cheers,
Quentin
Heiko Stuebner Feb. 23, 2024, 1:44 p.m. UTC | #3
Am Freitag, 23. Februar 2024, 13:45:23 CET schrieb Quentin Schulz:
> From: Quentin Schulz <quentin.schulz@theobroma-systems.com>
> 
> devm_reset_control_get_optional_exclusive does what this driver is
> trying to do in its probe function, therefore let's switch over to that
> subsystem function.
> 
> Cc: Quentin Schulz <foss+kernel@0leil.net>
> Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>

Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Andy Shevchenko Feb. 23, 2024, 2:39 p.m. UTC | #4
On Fri, Feb 23, 2024 at 3:10 PM Quentin Schulz
<quentin.schulz@theobroma-systems.com> wrote:
> On 2/23/24 14:00, Andy Shevchenko wrote:
> > On Fri, Feb 23, 2024 at 2:46 PM Quentin Schulz <foss+kernel@0leil.net> wrote:

...

> >> Cc: Quentin Schulz <foss+kernel@0leil.net>
> >
> > You may use the --cc option to `git send-email` instead of polluting
> > commit messages, or move this after the '---' cutter line.
>
> The whole point is that my SoB and authorship is from my professional
> mail address which is likely to change over time, the Cc is my personal
> one for development. Basically, in the event that I change my employer,
> I would still be reachable at that Cc address without having to modify
> the .mailmap after the fact (which won't make it to an earlier version
> of the kernel for example). Some maintainers don't really like this,
> some don't mind, we'll see in which category the IIO maintainer(s) fall
> in :) (I don't mind either way just to be clear).

My point is that Cc and other similar (non-real-tags) stuff is
polluting commit messages. It means that this will be copied to the
Git index to all kernel git repositories in the world from now and
then, This is at bare minimum makes additional burden on git log (and
parsing and so on) and moreover, wastes resources becoming less
environment friendly (no jokes). Using --cc or moving to the behind
the commit message will keep email copied with cleaner commit
messages. Yet, all email tags are available in lore archive
(lore.kernel.org). Please, really reconsider the commit messages
content in the Linux kernel project and elsewhere, it will help to
make the world more friendly.
Dragan Simic Feb. 26, 2024, 8:31 p.m. UTC | #5
Hello Andy and Quentin,

On 2024-02-23 15:39, Andy Shevchenko wrote:
> On Fri, Feb 23, 2024 at 3:10 PM Quentin Schulz
> <quentin.schulz@theobroma-systems.com> wrote:
>> On 2/23/24 14:00, Andy Shevchenko wrote:
>> > On Fri, Feb 23, 2024 at 2:46 PM Quentin Schulz <foss+kernel@0leil.net> wrote:
> 
> ...
> 
>> >> Cc: Quentin Schulz <foss+kernel@0leil.net>
>> >
>> > You may use the --cc option to `git send-email` instead of polluting
>> > commit messages, or move this after the '---' cutter line.
>> 
>> The whole point is that my SoB and authorship is from my professional
>> mail address which is likely to change over time, the Cc is my 
>> personal
>> one for development. Basically, in the event that I change my 
>> employer,
>> I would still be reachable at that Cc address without having to modify
>> the .mailmap after the fact (which won't make it to an earlier version
>> of the kernel for example). Some maintainers don't really like this,
>> some don't mind, we'll see in which category the IIO maintainer(s) 
>> fall
>> in :) (I don't mind either way just to be clear).
> 
> My point is that Cc and other similar (non-real-tags) stuff is
> polluting commit messages. It means that this will be copied to the
> Git index to all kernel git repositories in the world from now and
> then, This is at bare minimum makes additional burden on git log (and
> parsing and so on) and moreover, wastes resources becoming less
> environment friendly (no jokes). Using --cc or moving to the behind
> the commit message will keep email copied with cleaner commit
> messages. Yet, all email tags are available in lore archive
> (lore.kernel.org). Please, really reconsider the commit messages
> content in the Linux kernel project and elsewhere, it will help to
> make the world more friendly.

Believe it or not, I'm working on some patches for Git that, I believe,
should help a lot when it comes to handling Cc: addresses.  Would you
like to be included in the list of recipients for those Git patches, so
you could, hopefully, provide some feeback?
Andy Shevchenko Feb. 27, 2024, 12:48 p.m. UTC | #6
On Mon, Feb 26, 2024 at 10:31 PM Dragan Simic <dsimic@manjaro.org> wrote:
> On 2024-02-23 15:39, Andy Shevchenko wrote:
> > On Fri, Feb 23, 2024 at 3:10 PM Quentin Schulz
> > <quentin.schulz@theobroma-systems.com> wrote:
> >> On 2/23/24 14:00, Andy Shevchenko wrote:

...

> >> I would still be reachable at that Cc address without having to modify
> >> the .mailmap after the fact (which won't make it to an earlier version
> >> of the kernel for example). Some maintainers don't really like this,
> >> some don't mind, we'll see in which category the IIO maintainer(s)
> >> fall
> >> in :) (I don't mind either way just to be clear).
> >
> > My point is that Cc and other similar (non-real-tags) stuff is
> > polluting commit messages. It means that this will be copied to the
> > Git index to all kernel git repositories in the world from now and
> > then, This is at bare minimum makes additional burden on git log (and
> > parsing and so on) and moreover, wastes resources becoming less
> > environment friendly (no jokes). Using --cc or moving to the behind
> > the commit message will keep email copied with cleaner commit
> > messages. Yet, all email tags are available in lore archive
> > (lore.kernel.org). Please, really reconsider the commit messages
> > content in the Linux kernel project and elsewhere, it will help to
> > make the world more friendly.
>
> Believe it or not, I'm working on some patches for Git that, I believe,
> should help a lot when it comes to handling Cc: addresses.  Would you
> like to be included in the list of recipients for those Git patches, so
> you could, hopefully, provide some feeback?

You may Cc me if you want to, but I can't guarantee I have time or
valuable input to that.
Dragan Simic Feb. 27, 2024, 2:55 p.m. UTC | #7
On 2024-02-27 13:48, Andy Shevchenko wrote:
> On Mon, Feb 26, 2024 at 10:31 PM Dragan Simic <dsimic@manjaro.org> 
> wrote:
>> On 2024-02-23 15:39, Andy Shevchenko wrote:
>> > On Fri, Feb 23, 2024 at 3:10 PM Quentin Schulz
>> > <quentin.schulz@theobroma-systems.com> wrote:
>> >> On 2/23/24 14:00, Andy Shevchenko wrote:
> 
> ...
> 
>> >> I would still be reachable at that Cc address without having to modify
>> >> the .mailmap after the fact (which won't make it to an earlier version
>> >> of the kernel for example). Some maintainers don't really like this,
>> >> some don't mind, we'll see in which category the IIO maintainer(s)
>> >> fall
>> >> in :) (I don't mind either way just to be clear).
>> >
>> > My point is that Cc and other similar (non-real-tags) stuff is
>> > polluting commit messages. It means that this will be copied to the
>> > Git index to all kernel git repositories in the world from now and
>> > then, This is at bare minimum makes additional burden on git log (and
>> > parsing and so on) and moreover, wastes resources becoming less
>> > environment friendly (no jokes). Using --cc or moving to the behind
>> > the commit message will keep email copied with cleaner commit
>> > messages. Yet, all email tags are available in lore archive
>> > (lore.kernel.org). Please, really reconsider the commit messages
>> > content in the Linux kernel project and elsewhere, it will help to
>> > make the world more friendly.
>> 
>> Believe it or not, I'm working on some patches for Git that, I 
>> believe,
>> should help a lot when it comes to handling Cc: addresses.  Would you
>> like to be included in the list of recipients for those Git patches, 
>> so
>> you could, hopefully, provide some feeback?
> 
> You may Cc me if you want to, but I can't guarantee I have time or
> valuable input to that.

Thanks, I'll be happy to have another set of eyes on those Git patches.
diff mbox series

Patch

diff --git a/drivers/iio/adc/rockchip_saradc.c b/drivers/iio/adc/rockchip_saradc.c
index 1c0042fbbb54..bbe954a738c7 100644
--- a/drivers/iio/adc/rockchip_saradc.c
+++ b/drivers/iio/adc/rockchip_saradc.c
@@ -450,16 +450,11 @@  static int rockchip_saradc_probe(struct platform_device *pdev)
 	 * The reset should be an optional property, as it should work
 	 * with old devicetrees as well
 	 */
-	info->reset = devm_reset_control_get_exclusive(&pdev->dev,
-						       "saradc-apb");
+	info->reset = devm_reset_control_get_optional_exclusive(&pdev->dev,
+								"saradc-apb");
 	if (IS_ERR(info->reset)) {
 		ret = PTR_ERR(info->reset);
-		if (ret != -ENOENT)
-			return dev_err_probe(&pdev->dev, ret,
-					     "failed to get saradc-apb\n");
-
-		dev_dbg(&pdev->dev, "no reset control found\n");
-		info->reset = NULL;
+		return dev_err_probe(&pdev->dev, ret, "failed to get saradc-apb\n");
 	}
 
 	init_completion(&info->completion);