[PATCH] pwm: meson: Simplify using dev_err_probe()

[PATCH] pwm: meson: Simplify using dev_err_probe()

[Uwe Kleine-König]

Using dev_err_probe() emitting an error message mentioning a return
value and returning that value can be done in a single statement. Make
use of that to simplify the probe part of the driver. This has the
additional advantage to emit the symbolic name for the error instead of
the integer error value.

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
Hello,

while trying to understand Jerome's series[1] I noticed this patch
opportunity.

Best regards
Uwe

[1] https://lore.kernel.org/linux-pwm/20231129134004.3642121-1-jbrunet@baylibre.com

 drivers/pwm/pwm-meson.c | 35 ++++++++++++++---------------------
 1 file changed, 14 insertions(+), 21 deletions(-)

diff --git a/drivers/pwm/pwm-meson.c b/drivers/pwm/pwm-meson.c
index 5bea53243ed2..2971bbf3b5e7 100644
--- a/drivers/pwm/pwm-meson.c
+++ b/drivers/pwm/pwm-meson.c
@@ -468,10 +468,9 @@ static int meson_pwm_init_channels(struct meson_pwm *meson)
 		channel->mux.hw.init = &init;
 
 		err = devm_clk_hw_register(dev, &channel->mux.hw);
-		if (err) {
-			dev_err(dev, "failed to register %s: %d\n", name, err);
-			return err;
-		}
+		if (err)
+			return dev_err_probe(dev, err,
+					     "failed to register %s\n", name);
 
 		snprintf(name, sizeof(name), "%s#div%u", dev_name(dev), i);
 
@@ -491,10 +490,9 @@ static int meson_pwm_init_channels(struct meson_pwm *meson)
 		channel->div.lock = &meson->lock;
 
 		err = devm_clk_hw_register(dev, &channel->div.hw);
-		if (err) {
-			dev_err(dev, "failed to register %s: %d\n", name, err);
-			return err;
-		}
+		if (err)
+			return dev_err_probe(dev, err,
+					     "failed to register %s\n", name);
 
 		snprintf(name, sizeof(name), "%s#gate%u", dev_name(dev), i);
 
@@ -513,17 +511,13 @@ static int meson_pwm_init_channels(struct meson_pwm *meson)
 		channel->gate.lock = &meson->lock;
 
 		err = devm_clk_hw_register(dev, &channel->gate.hw);
-		if (err) {
-			dev_err(dev, "failed to register %s: %d\n", name, err);
-			return err;
-		}
+		if (err)
+			return dev_err_probe(dev, err, "failed to register %s\n", name);
 
 		channel->clk = devm_clk_hw_get_clk(dev, &channel->gate.hw, NULL);
-		if (IS_ERR(channel->clk)) {
-			err = PTR_ERR(channel->clk);
-			dev_err(dev, "failed to register %s: %d\n", name, err);
-			return err;
-		}
+		if (IS_ERR(channel->clk))
+			return dev_err_probe(dev, PTR_ERR(channel->clk),
+					     "failed to register %s\n", name);
 	}
 
 	return 0;
@@ -554,10 +548,9 @@ static int meson_pwm_probe(struct platform_device *pdev)
 		return err;
 
 	err = devm_pwmchip_add(&pdev->dev, &meson->chip);
-	if (err < 0) {
-		dev_err(&pdev->dev, "failed to register PWM chip: %d\n", err);
-		return err;
-	}
+	if (err < 0)
+		return dev_err_probe(&pdev->dev, err,
+				     "failed to register PWM chip\n");
 
 	return 0;
 }
-- 
2.42.0


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH] pwm: meson: Simplify using dev_err_probe()

[Thierry Reding]

[-- Attachment #1.1: Type: text/plain, Size: 3429 bytes --]

On Wed, Dec 06, 2023 at 10:48:18PM +0100, Uwe Kleine-König wrote:
> Using dev_err_probe() emitting an error message mentioning a return
> value and returning that value can be done in a single statement. Make
> use of that to simplify the probe part of the driver. This has the
> additional advantage to emit the symbolic name for the error instead of
> the integer error value.
> 
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> ---
> Hello,
> 
> while trying to understand Jerome's series[1] I noticed this patch
> opportunity.
> 
> Best regards
> Uwe
> 
> [1] https://lore.kernel.org/linux-pwm/20231129134004.3642121-1-jbrunet@baylibre.com
> 
>  drivers/pwm/pwm-meson.c | 35 ++++++++++++++---------------------
>  1 file changed, 14 insertions(+), 21 deletions(-)
> 
> diff --git a/drivers/pwm/pwm-meson.c b/drivers/pwm/pwm-meson.c
> index 5bea53243ed2..2971bbf3b5e7 100644
> --- a/drivers/pwm/pwm-meson.c
> +++ b/drivers/pwm/pwm-meson.c
> @@ -468,10 +468,9 @@ static int meson_pwm_init_channels(struct meson_pwm *meson)
>  		channel->mux.hw.init = &init;
>  
>  		err = devm_clk_hw_register(dev, &channel->mux.hw);
> -		if (err) {
> -			dev_err(dev, "failed to register %s: %d\n", name, err);
> -			return err;
> -		}
> +		if (err)
> +			return dev_err_probe(dev, err,
> +					     "failed to register %s\n", name);
>  
>  		snprintf(name, sizeof(name), "%s#div%u", dev_name(dev), i);
>  
> @@ -491,10 +490,9 @@ static int meson_pwm_init_channels(struct meson_pwm *meson)
>  		channel->div.lock = &meson->lock;
>  
>  		err = devm_clk_hw_register(dev, &channel->div.hw);
> -		if (err) {
> -			dev_err(dev, "failed to register %s: %d\n", name, err);
> -			return err;
> -		}
> +		if (err)
> +			return dev_err_probe(dev, err,
> +					     "failed to register %s\n", name);
>  
>  		snprintf(name, sizeof(name), "%s#gate%u", dev_name(dev), i);
>  
> @@ -513,17 +511,13 @@ static int meson_pwm_init_channels(struct meson_pwm *meson)
>  		channel->gate.lock = &meson->lock;
>  
>  		err = devm_clk_hw_register(dev, &channel->gate.hw);
> -		if (err) {
> -			dev_err(dev, "failed to register %s: %d\n", name, err);
> -			return err;
> -		}
> +		if (err)
> +			return dev_err_probe(dev, err, "failed to register %s\n", name);
>  
>  		channel->clk = devm_clk_hw_get_clk(dev, &channel->gate.hw, NULL);
> -		if (IS_ERR(channel->clk)) {
> -			err = PTR_ERR(channel->clk);
> -			dev_err(dev, "failed to register %s: %d\n", name, err);
> -			return err;
> -		}
> +		if (IS_ERR(channel->clk))
> +			return dev_err_probe(dev, PTR_ERR(channel->clk),
> +					     "failed to register %s\n", name);
>  	}
>  
>  	return 0;
> @@ -554,10 +548,9 @@ static int meson_pwm_probe(struct platform_device *pdev)
>  		return err;
>  
>  	err = devm_pwmchip_add(&pdev->dev, &meson->chip);
> -	if (err < 0) {
> -		dev_err(&pdev->dev, "failed to register PWM chip: %d\n", err);
> -		return err;
> -	}
> +	if (err < 0)
> +		return dev_err_probe(&pdev->dev, err,
> +				     "failed to register PWM chip\n");
>  
>  	return 0;
>  }

This is a lot of churn for very little gain. None of these functions are
ever going to return -EPROBE_DEFER. And yes, I know that function's doc
says that it is "deemed acceptable to use" elsewhere. However, the
existing error messages are just fine, no need to churn just for the
sake of it.

Thierry

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH] pwm: meson: Simplify using dev_err_probe()

[Uwe Kleine-König]

[-- Attachment #1.1: Type: text/plain, Size: 1275 bytes --]

Hello Thierry,

On Fri, Dec 08, 2023 at 04:52:57PM +0100, Thierry Reding wrote:
> This is a lot of churn for very little gain.

We seem to have different conceptions of churn. Each hunk here is an
improvement for both SLOC count and usefulness of the generated error
message.

	failed to register somename: -5

is worse than

	error EIO: failed to register somename

, isn't it?

> None of these functions are ever going to return -EPROBE_DEFER. And
> yes, I know that function's doc says that it is "deemed acceptable to
> use" elsewhere. However, the existing error messages are just fine, no
> need to churn just for the sake of it.

We had this disagreement already before. Yes dev_err_probe() is useful
for three reasons and this driver only benefits from two of these.
That's IMHO still one reason more than needed to justify such a change.

And if you think that a function should only be used if all advantages
are useful for the caller, let us reconsider if we really need capture
support in the pwm framework as only two of the 68 drivers make use of
it.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH] pwm: meson: Simplify using dev_err_probe()

[Thierry Reding]

[-- Attachment #1.1: Type: text/plain, Size: 1864 bytes --]

On Fri, Dec 08, 2023 at 08:06:20PM +0100, Uwe Kleine-König wrote:
> Hello Thierry,
> 
> On Fri, Dec 08, 2023 at 04:52:57PM +0100, Thierry Reding wrote:
> > This is a lot of churn for very little gain.
> 
> We seem to have different conceptions of churn. Each hunk here is an
> improvement for both SLOC count and usefulness of the generated error
> message.
> 
> 	failed to register somename: -5
> 
> is worse than
> 
> 	error EIO: failed to register somename
> 
> , isn't it?

That's entirely subjective. I think the first version is just fine. I,
and I suspect most developers will, know what to do with either of those
error messages.

> > None of these functions are ever going to return -EPROBE_DEFER. And
> > yes, I know that function's doc says that it is "deemed acceptable to
> > use" elsewhere. However, the existing error messages are just fine, no
> > need to churn just for the sake of it.
> 
> We had this disagreement already before. Yes dev_err_probe() is useful
> for three reasons and this driver only benefits from two of these.
> That's IMHO still one reason more than needed to justify such a change.

I disagree. There are certainly cases where dev_err_probe() can be a
significant improvement, but there are others where the improvement is
very minor (if there's any at all) and in my opinion the churn isn't
justified. Otherwise we'll just forever keep rewriting the same code
over and over again because somebody comes up with yet another variant
of mostly the same code.

> And if you think that a function should only be used if all advantages
> are useful for the caller, let us reconsider if we really need capture
> support in the pwm framework as only two of the 68 drivers make use of
> it.

That's a ridiculous argument and you know it. You are comparing apples
to oranges.

Thierry

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH] pwm: meson: Simplify using dev_err_probe()

[Uwe Kleine-König]

[-- Attachment #1.1: Type: text/plain, Size: 3038 bytes --]

Hello,

On Mon, Dec 11, 2023 at 12:01:33PM +0100, Thierry Reding wrote:
> On Fri, Dec 08, 2023 at 08:06:20PM +0100, Uwe Kleine-König wrote:
> > On Fri, Dec 08, 2023 at 04:52:57PM +0100, Thierry Reding wrote:
> > > This is a lot of churn for very little gain.
> > 
> > We seem to have different conceptions of churn. Each hunk here is an
> > improvement for both SLOC count and usefulness of the generated error
> > message.
> > 
> > 	failed to register somename: -5
> > 
> > is worse than
> > 
> > 	error EIO: failed to register somename
> > 
> > , isn't it?
> 
> That's entirely subjective.

It's not. You and me both know that -5 is EIO. But there are quite a few
people who don't. And for other error codes I'm not that fluent. (Do you
know -2 and -19?) Also some constants are architecture specific, so e.g.
-11 is -35 on alpha.

> I think the first version is just fine. I,
> and I suspect most developers will, know what to do with either of those
> error messages.

Error messages aren't only for (kernel) developers. If you don't know
that the kernel uses negative error numbers as return codes, the
translation of -5 to EIO is even further away than opening
/usr/include/errno.h.
 
> > > None of these functions are ever going to return -EPROBE_DEFER. And
> > > yes, I know that function's doc says that it is "deemed acceptable to
> > > use" elsewhere. However, the existing error messages are just fine, no
> > > need to churn just for the sake of it.
> > 
> > We had this disagreement already before. Yes dev_err_probe() is useful
> > for three reasons and this driver only benefits from two of these.
> > That's IMHO still one reason more than needed to justify such a change.
> 
> I disagree. There are certainly cases where dev_err_probe() can be a
> significant improvement, but there are others where the improvement is
> very minor (if there's any at all) and in my opinion the churn isn't
> justified.

What is churn for you? Many changes? Big changes? For me churn is only a
big amount of changes where a considerable part cancels out if it was
squashed together. For you this concept seems to be broader.

> Otherwise we'll just forever keep rewriting the same code
> over and over again because somebody comes up with yet another variant
> of mostly the same code.

If there is an improvement in each adaption that's fine for me.
 
> > And if you think that a function should only be used if all advantages
> > are useful for the caller, let us reconsider if we really need capture
> > support in the pwm framework as only two of the 68 drivers make use of
> > it.
> 
> That's a ridiculous argument and you know it. You are comparing apples
> to oranges.

I would have been surprised if it had convinced you, but I honestly
think there is a (admittedly small) point.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH] pwm: meson: Simplify using dev_err_probe()

[Thierry Reding]

[-- Attachment #1.1: Type: text/plain, Size: 5375 bytes --]

On Mon, Dec 11, 2023 at 03:19:00PM +0100, Uwe Kleine-König wrote:
> Hello,
> 
> On Mon, Dec 11, 2023 at 12:01:33PM +0100, Thierry Reding wrote:
> > On Fri, Dec 08, 2023 at 08:06:20PM +0100, Uwe Kleine-König wrote:
> > > On Fri, Dec 08, 2023 at 04:52:57PM +0100, Thierry Reding wrote:
> > > > This is a lot of churn for very little gain.
> > > 
> > > We seem to have different conceptions of churn. Each hunk here is an
> > > improvement for both SLOC count and usefulness of the generated error
> > > message.
> > > 
> > > 	failed to register somename: -5
> > > 
> > > is worse than
> > > 
> > > 	error EIO: failed to register somename
> > > 
> > > , isn't it?
> > 
> > That's entirely subjective.
> 
> It's not. You and me both know that -5 is EIO. But there are quite a few
> people who don't.

So it is, in fact, subjective.

>                   And for other error codes I'm not that fluent. (Do you
> know -2 and -19?) Also some constants are architecture specific, so e.g.
> -11 is -35 on alpha.

I didn't know about -11 and -35 on Alpha. Looks like %pe would handle
those properly, so yeah, I suppose one could count that as a benefit.
Not sure if we have PWM drivers that run on Alpha, and Meson in
particular probably doesn't.

> > I think the first version is just fine. I,
> > and I suspect most developers will, know what to do with either of those
> > error messages.
> 
> Error messages aren't only for (kernel) developers. If you don't know
> that the kernel uses negative error numbers as return codes, the
> translation of -5 to EIO is even further away than opening
> /usr/include/errno.h.

Actually, kernel developers are exactly who these error messages are
for. Regular users that don't know how to decipher the error codes are
typically not going to know what to do about the error anyway, so they
are likely just going to copy/paste into some forum or bug tracker.

> > > > None of these functions are ever going to return -EPROBE_DEFER. And
> > > > yes, I know that function's doc says that it is "deemed acceptable to
> > > > use" elsewhere. However, the existing error messages are just fine, no
> > > > need to churn just for the sake of it.
> > > 
> > > We had this disagreement already before. Yes dev_err_probe() is useful
> > > for three reasons and this driver only benefits from two of these.
> > > That's IMHO still one reason more than needed to justify such a change.
> > 
> > I disagree. There are certainly cases where dev_err_probe() can be a
> > significant improvement, but there are others where the improvement is
> > very minor (if there's any at all) and in my opinion the churn isn't
> > justified.
> 
> What is churn for you? Many changes? Big changes? For me churn is only a
> big amount of changes where a considerable part cancels out if it was
> squashed together. For you this concept seems to be broader.

Churn for me is really any kind of change and it's not bad per se. What
I don't like are changes that are basically done just for the sake of
changing something. I don't have any strict rules for this, so I apply
common sense. If you want to rewrite an error message because it
contains typos or bad grammar, or is generally hard to understand,
that's what I'd consider fine and an improvement.

But this patch exchanges one format of the error message by another. It
doesn't change the error message or the information content in any way,
but instead just rearranges where the error is printed.

On top of it not adding any benefit, this might cause somebody to get
confused because some error message that they were looking out for is
now different. They may have to adjust a script or something.

You also mentioned that you saw the opportunity to do this while
reviewing Jerome's patches and looking at those patches, Jerome will now
have to solve a couple of conflicts when rebasing. They should
admittedly be fairly minor, but if Jerome wasn't experienced this might
be really annoying. Again, if this was a significant improvement I'm
sure this would be easily acceptable, but if it's just for format's sake
I'm not so sure it is.

> > Otherwise we'll just forever keep rewriting the same code
> > over and over again because somebody comes up with yet another variant
> > of mostly the same code.
> 
> If there is an improvement in each adaption that's fine for me.

I can't speak for other maintainers, but I get very annoyed every time
somebody introduces some new helper and then I get to deal with 60 or so
patches just because there's a new thing that ultimately doesn't really
change or improve anything.

It's easier to apply 60 patches today that it was perhaps a few years
ago, but it also entails a bunch of things like reviewing the code
because sometimes even trivial conversions are faulty, the nrunning test
builds and pushing changes.

It all adds up in the end and keeps me from doing other things. Again,
if this all has some sort of benefit it makes sense to put in the time,
but if it's just for the sake of shuffling around parts of error
messages it just makes me grumpy.

Unfortunately, with all of that said I probably have no other choice but
to apply this patch because if I don't, then I know somebody else will
send the very same patch at some point...

Thierry

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH] pwm: meson: Simplify using dev_err_probe()

[Uwe Kleine-König]

[-- Attachment #1.1: Type: text/plain, Size: 5229 bytes --]

Hello Thierry,

On Mon, Dec 11, 2023 at 04:24:35PM +0100, Thierry Reding wrote:
> On Mon, Dec 11, 2023 at 03:19:00PM +0100, Uwe Kleine-König wrote:
> > On Mon, Dec 11, 2023 at 12:01:33PM +0100, Thierry Reding wrote:
> > > On Fri, Dec 08, 2023 at 08:06:20PM +0100, Uwe Kleine-König wrote:
> > > > On Fri, Dec 08, 2023 at 04:52:57PM +0100, Thierry Reding wrote:
> > > > > This is a lot of churn for very little gain.
> > > > 
> > > > We seem to have different conceptions of churn. Each hunk here is an
> > > > improvement for both SLOC count and usefulness of the generated error
> > > > message.
> > > > 
> > > > 	failed to register somename: -5
> > > > 
> > > > is worse than
> > > > 
> > > > 	error EIO: failed to register somename
> > > > 
> > > > , isn't it?
> > > 
> > > That's entirely subjective.
> > 
> > It's not. You and me both know that -5 is EIO. But there are quite a few
> > people who don't.
> 
> So it is, in fact, subjective.

For some individuals it's an improvement and for others it doesn't make
things worse. So in sum it's an objective improvement.
 
> >                   And for other error codes I'm not that fluent. (Do you
> > know -2 and -19?) Also some constants are architecture specific, so e.g.
> > -11 is -35 on alpha.
> 
> I didn't know about -11 and -35 on Alpha. Looks like %pe would handle
> those properly, so yeah, I suppose one could count that as a benefit.
> Not sure if we have PWM drivers that run on Alpha, and Meson in
> particular probably doesn't.

So using a symbolic error number (e.g. by using dev_err_probe) makes it
unnecessary to think about which arch the given driver runs on and if
the returned values might differ by architecture. One less problem to
think about, that's an advantage.

Also the next person to write a driver on alpha (or another platform
where the error codes differ from those on x86) will probably pick an
existing driver as a template. So the meson driver being robust to run
on alpha is a good thing.

> > > I think the first version is just fine. I,
> > > and I suspect most developers will, know what to do with either of those
> > > error messages.
> > 
> > Error messages aren't only for (kernel) developers. If you don't know
> > that the kernel uses negative error numbers as return codes, the
> > translation of -5 to EIO is even further away than opening
> > /usr/include/errno.h.
> 
> Actually, kernel developers are exactly who these error messages are
> for. Regular users that don't know how to decipher the error codes are
> typically not going to know what to do about the error anyway, so they
> are likely just going to copy/paste into some forum or bug tracker.

That seems to be a very cocky POV to me. But that explains a lot.
The kernel community has a very l33t reputation, lowering the bar for
newbies is a nice move IMHO.

Also EIO in a forum or bug tracker is more relevantly better, because
there are more readers that then all individually have to interpret the
-5 and know/research it's -EIO.

> > > > > None of these functions are ever going to return -EPROBE_DEFER. And
> > > > > yes, I know that function's doc says that it is "deemed acceptable to
> > > > > use" elsewhere. However, the existing error messages are just fine, no
> > > > > need to churn just for the sake of it.
> > > > 
> > > > We had this disagreement already before. Yes dev_err_probe() is useful
> > > > for three reasons and this driver only benefits from two of these.
> > > > That's IMHO still one reason more than needed to justify such a change.
> > > 
> > > I disagree. There are certainly cases where dev_err_probe() can be a
> > > significant improvement, but there are others where the improvement is
> > > very minor (if there's any at all) and in my opinion the churn isn't
> > > justified.
> > 
> > What is churn for you? Many changes? Big changes? For me churn is only a
> > big amount of changes where a considerable part cancels out if it was
> > squashed together. For you this concept seems to be broader.
> 
> Churn for me is really any kind of change and it's not bad per se. What
> I don't like are changes that are basically done just for the sake of
> changing something.

That's not my motivation.

> I don't have any strict rules for this, so I apply
> common sense. If you want to rewrite an error message because it
> contains typos or bad grammar, or is generally hard to understand,
> that's what I'd consider fine and an improvement.

I'd count "-5" as "generally hard to understand".
 
> But this patch exchanges one format of the error message by another. It
> doesn't change the error message or the information content in any way,
> but instead just rearranges where the error is printed.
> 
> On top of it not adding any benefit, this might cause somebody to get
> confused because some error message that they were looking out for is
> now different. They may have to adjust a script or something.

Yeah sure, xkcd#1172.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH] pwm: meson: Simplify using dev_err_probe()

[Uwe Kleine-König]

[-- Attachment #1.1: Type: text/plain, Size: 430 bytes --]

Hello Thierry,

On Mon, Dec 11, 2023 at 04:24:35PM +0100, Thierry Reding wrote:
> It all adds up in the end and keeps me from doing other things.

If that means you'd be glad to give up the PWM maintainer job, I'd
happily take over this post.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH] pwm: meson: Simplify using dev_err_probe()

[Thierry Reding]

[-- Attachment #1.1: Type: text/plain, Size: 686 bytes --]

On Tue, Dec 12, 2023 at 09:33:52PM +0100, Uwe Kleine-König wrote:
> Hello Thierry,
> 
> On Mon, Dec 11, 2023 at 04:24:35PM +0100, Thierry Reding wrote:
> > It all adds up in the end and keeps me from doing other things.
> 
> If that means you'd be glad to give up the PWM maintainer job, I'd
> happily take over this post.

"Glad" is not the word that I would choose. After all I've looked after
this subsystem for almost 12 years, and letting it go isn't something
that is particularly easy. However, I do realize that my heart isn't in
it anymore and I don't want to be in the way of anyone.

So I'll take you up on that offer. Do you want to send a patch?

Thierry

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH] MAINTAINERS: pwm: Thierry steps down, Uwe takes over

[Uwe Kleine-König]

[-- Attachment #1.1: Type: text/plain, Size: 2717 bytes --]

It's not easy to let go responsibility for a subsystem that one cared
for for a long time, but Thierry realized that his heart isn't in the
pwm framework any more.

Thierry cared for the pwm subsystem (commit 200efedd8766 ("pwm: Take
over maintainership of the PWM subsystem")) as a maintainer during
nearly 12 years. A big thanks for the time, effort and dedication spend
during that time.

Uwe takes over maintenance.

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
Hello Thierry,

On Wed, Dec 20, 2023 at 04:59:47PM +0100, Thierry Reding wrote:
> On Tue, Dec 12, 2023 at 09:33:52PM +0100, Uwe Kleine-König wrote:
> > On Mon, Dec 11, 2023 at 04:24:35PM +0100, Thierry Reding wrote:
> > > It all adds up in the end and keeps me from doing other things.
> > 
> > If that means you'd be glad to give up the PWM maintainer job, I'd
> > happily take over this post.
> 
> "Glad" is not the word that I would choose. After all I've looked after
> this subsystem for almost 12 years, and letting it go isn't something
> that is particularly easy. However, I do realize that my heart isn't in
> it anymore and I don't want to be in the way of anyone.
> 
> So I'll take you up on that offer. Do you want to send a patch?

Sure, here it comes.

I hesitated to remove you completely, but I guess you intended a clean
cut? Or would you prefer to stay as a reviewer?

Usually I would have added you to CREDITS, but as you will continue to
fill your various other responsibilities (I expect), this felt wrong. 

Best regards
Uwe

 MAINTAINERS | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 5342cf32d73f..16c6aa0ad1ae 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -17561,12 +17561,11 @@ F:	Documentation/devicetree/bindings/leds/irled/pwm-ir-tx.yaml
 F:	drivers/media/rc/pwm-ir-tx.c
 
 PWM SUBSYSTEM
-M:	Thierry Reding <thierry.reding@gmail.com>
-R:	Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
+M:	Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
 L:	linux-pwm@vger.kernel.org
 S:	Maintained
 Q:	https://patchwork.ozlabs.org/project/linux-pwm/list/
-T:	git git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm.git
+T:	git https://git.kernel.org/pub/scm/linux/kernel/git/ukleinek/linux-pwm.git
 F:	Documentation/devicetree/bindings/gpio/gpio-mvebu.yaml
 F:	Documentation/devicetree/bindings/pwm/
 F:	Documentation/driver-api/pwm.rst

base-commit: 881791886bfa8e353c3203f95bfbaaeee25d2d50
-- 
2.42.0


-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH] MAINTAINERS: pwm: Thierry steps down, Uwe takes over

[Neil Armstrong]

On 21/12/2023 10:21, Uwe Kleine-König wrote:
> It's not easy to let go responsibility for a subsystem that one cared
> for for a long time, but Thierry realized that his heart isn't in the
> pwm framework any more.
> 
> Thierry cared for the pwm subsystem (commit 200efedd8766 ("pwm: Take
> over maintainership of the PWM subsystem")) as a maintainer during
> nearly 12 years. A big thanks for the time, effort and dedication spend
> during that time.
> 
> Uwe takes over maintenance.
> 
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> ---
> Hello Thierry,
> 
> On Wed, Dec 20, 2023 at 04:59:47PM +0100, Thierry Reding wrote:
>> On Tue, Dec 12, 2023 at 09:33:52PM +0100, Uwe Kleine-König wrote:
>>> On Mon, Dec 11, 2023 at 04:24:35PM +0100, Thierry Reding wrote:
>>>> It all adds up in the end and keeps me from doing other things.
>>>
>>> If that means you'd be glad to give up the PWM maintainer job, I'd
>>> happily take over this post.
>>
>> "Glad" is not the word that I would choose. After all I've looked after
>> this subsystem for almost 12 years, and letting it go isn't something
>> that is particularly easy. However, I do realize that my heart isn't in
>> it anymore and I don't want to be in the way of anyone.
>>
>> So I'll take you up on that offer. Do you want to send a patch?
> 
> Sure, here it comes.
> 
> I hesitated to remove you completely, but I guess you intended a clean
> cut? Or would you prefer to stay as a reviewer?
> 
> Usually I would have added you to CREDITS, but as you will continue to
> fill your various other responsibilities (I expect), this felt wrong.
> 
> Best regards
> Uwe
> 
>   MAINTAINERS | 5 ++---
>   1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 5342cf32d73f..16c6aa0ad1ae 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -17561,12 +17561,11 @@ F:	Documentation/devicetree/bindings/leds/irled/pwm-ir-tx.yaml
>   F:	drivers/media/rc/pwm-ir-tx.c
>   
>   PWM SUBSYSTEM
> -M:	Thierry Reding <thierry.reding@gmail.com>
> -R:	Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> +M:	Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
>   L:	linux-pwm@vger.kernel.org
>   S:	Maintained
>   Q:	https://patchwork.ozlabs.org/project/linux-pwm/list/
> -T:	git git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm.git
> +T:	git https://git.kernel.org/pub/scm/linux/kernel/git/ukleinek/linux-pwm.git
>   F:	Documentation/devicetree/bindings/gpio/gpio-mvebu.yaml
>   F:	Documentation/devicetree/bindings/pwm/
>   F:	Documentation/driver-api/pwm.rst
> 
> base-commit: 881791886bfa8e353c3203f95bfbaaeee25d2d50

Thanks Thierry for all support and work over pwm and your help for pwm-meson!

Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH] MAINTAINERS: pwm: Thierry steps down, Uwe takes over

[Thierry Reding]

[-- Attachment #1.1: Type: text/plain, Size: 1901 bytes --]

On Thu, Dec 21, 2023 at 10:21:36AM +0100, Uwe Kleine-König wrote:
> It's not easy to let go responsibility for a subsystem that one cared
> for for a long time, but Thierry realized that his heart isn't in the
> pwm framework any more.
> 
> Thierry cared for the pwm subsystem (commit 200efedd8766 ("pwm: Take
> over maintainership of the PWM subsystem")) as a maintainer during
> nearly 12 years. A big thanks for the time, effort and dedication spend
> during that time.
> 
> Uwe takes over maintenance.
> 
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> ---
> Hello Thierry,
> 
> On Wed, Dec 20, 2023 at 04:59:47PM +0100, Thierry Reding wrote:
> > On Tue, Dec 12, 2023 at 09:33:52PM +0100, Uwe Kleine-König wrote:
> > > On Mon, Dec 11, 2023 at 04:24:35PM +0100, Thierry Reding wrote:
> > > > It all adds up in the end and keeps me from doing other things.
> > > 
> > > If that means you'd be glad to give up the PWM maintainer job, I'd
> > > happily take over this post.
> > 
> > "Glad" is not the word that I would choose. After all I've looked after
> > this subsystem for almost 12 years, and letting it go isn't something
> > that is particularly easy. However, I do realize that my heart isn't in
> > it anymore and I don't want to be in the way of anyone.
> > 
> > So I'll take you up on that offer. Do you want to send a patch?
> 
> Sure, here it comes.
> 
> I hesitated to remove you completely, but I guess you intended a clean
> cut? Or would you prefer to stay as a reviewer?
> 
> Usually I would have added you to CREDITS, but as you will continue to
> fill your various other responsibilities (I expect), this felt wrong. 

Looks all good to me. I'll keep things going until the next merge window
and will then send out my last PWM pull request and let Linus know to
expect future requests to come from you.

Thierry

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH] MAINTAINERS: pwm: Thierry steps down, Uwe takes over

[Uwe Kleine-König]

[-- Attachment #1.1: Type: text/plain, Size: 466 bytes --]

Hello Thierry,

On Thu, Dec 21, 2023 at 10:57:23AM +0100, Thierry Reding wrote:
> Looks all good to me. I'll keep things going until the next merge window
> and will then send out my last PWM pull request and let Linus know to
> expect future requests to come from you.

Sounds good.

Thanks
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel