All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
To: Thierry Reding <thierry.reding@gmail.com>,
	Fabrice Gasnier <fabrice.gasnier@foss.st.com>,
	Maxime Coquelin <mcoquelin.stm32@gmail.com>,
	Alexandre Torgue <alexandre.torgue@foss.st.com>,
	Mark Brown <broonie@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org, linux-pwm@vger.kernel.org,
	linux-stm32@st-md-mailman.stormreply.com, kernel@pengutronix.de
Subject: Re: [PATCH 0/5] pwm: Use regmap_clear_bits and regmap_set_bits where applicable
Date: Thu, 17 Nov 2022 14:52:37 +0100	[thread overview]
Message-ID: <20221117135237.vqhe6z7aklindlgq@pengutronix.de> (raw)
In-Reply-To: <20221115111347.3705732-1-u.kleine-koenig@pengutronix.de>

[-- Attachment #1: Type: text/plain, Size: 2020 bytes --]

Hello,

On Tue, Nov 15, 2022 at 12:13:42PM +0100, Uwe Kleine-König wrote:
> I recently learned a bit of coccinelle and triggered by Paul Cercueil's
> patch that replaces regmap_update_bits() by regmap_set_bits() and
> regmap_clear_bits() where applicable in the jz4740 pwm driver[1] I
> created a cocci patch for such calls.

Pointing to this series I asked broonie in irc if a conversion like that
would be suitable to do in the complete tree. He objected that doing
that mechanically is probably wrong. His explicit concern was that a
call to regmap_clear_bits() (or regmap_set_bits()) in a series of
regmap_update_bits() is more disturbing than helpful.

So I looked at the remaining calls to regmap_update_bits() in the
drivers I converted in this series:

 - pwm-fsl-ftm
   There are two calls left that set bits in a mask (these should stay
   as they are) and one:

        reg_polarity = 0;
        if (newstate->polarity == PWM_POLARITY_INVERSED)
                reg_polarity = BIT(pwm->hwpwm);

        regmap_update_bits(fpc->regmap, FTM_POL, BIT(pwm->hwpwm), reg_polarity);

   which could benefit from a conversion (though I expect that to be
   controversial).
   The converted calls are all independent of the remaining
   regmap_update_bits().

 - pwm-img
   No regmap_update_bits() calls left.

 - pwm-iqs620a
   There is one call left that does:

        return regmap_update_bits(iqs62x->regmap, IQS620_PWR_SETTINGS,
                                  IQS620_PWR_SETTINGS_PWM_OUT, 0xff);

   I think this is a bug because IQS620_PWR_SETTINGS_PWM_OUT is only
   0xf.

 - pwm-stm32-lp
   No regmap_update_bits() calls left.

 - pwm-stm32
   There are several calls left, some of them also near converted calls.
   My personal opinion is, that the conversion is fine anyhow.

Best regards
Uwe

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

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

WARNING: multiple messages have this Message-ID (diff)
From: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
To: Thierry Reding <thierry.reding@gmail.com>,
	Fabrice Gasnier <fabrice.gasnier@foss.st.com>,
	Maxime Coquelin <mcoquelin.stm32@gmail.com>,
	Alexandre Torgue <alexandre.torgue@foss.st.com>,
	Mark Brown <broonie@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org, linux-pwm@vger.kernel.org,
	linux-stm32@st-md-mailman.stormreply.com, kernel@pengutronix.de
Subject: Re: [PATCH 0/5] pwm: Use regmap_clear_bits and regmap_set_bits where applicable
Date: Thu, 17 Nov 2022 14:52:37 +0100	[thread overview]
Message-ID: <20221117135237.vqhe6z7aklindlgq@pengutronix.de> (raw)
In-Reply-To: <20221115111347.3705732-1-u.kleine-koenig@pengutronix.de>


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

Hello,

On Tue, Nov 15, 2022 at 12:13:42PM +0100, Uwe Kleine-König wrote:
> I recently learned a bit of coccinelle and triggered by Paul Cercueil's
> patch that replaces regmap_update_bits() by regmap_set_bits() and
> regmap_clear_bits() where applicable in the jz4740 pwm driver[1] I
> created a cocci patch for such calls.

Pointing to this series I asked broonie in irc if a conversion like that
would be suitable to do in the complete tree. He objected that doing
that mechanically is probably wrong. His explicit concern was that a
call to regmap_clear_bits() (or regmap_set_bits()) in a series of
regmap_update_bits() is more disturbing than helpful.

So I looked at the remaining calls to regmap_update_bits() in the
drivers I converted in this series:

 - pwm-fsl-ftm
   There are two calls left that set bits in a mask (these should stay
   as they are) and one:

        reg_polarity = 0;
        if (newstate->polarity == PWM_POLARITY_INVERSED)
                reg_polarity = BIT(pwm->hwpwm);

        regmap_update_bits(fpc->regmap, FTM_POL, BIT(pwm->hwpwm), reg_polarity);

   which could benefit from a conversion (though I expect that to be
   controversial).
   The converted calls are all independent of the remaining
   regmap_update_bits().

 - pwm-img
   No regmap_update_bits() calls left.

 - pwm-iqs620a
   There is one call left that does:

        return regmap_update_bits(iqs62x->regmap, IQS620_PWR_SETTINGS,
                                  IQS620_PWR_SETTINGS_PWM_OUT, 0xff);

   I think this is a bug because IQS620_PWR_SETTINGS_PWM_OUT is only
   0xf.

 - pwm-stm32-lp
   No regmap_update_bits() calls left.

 - pwm-stm32
   There are several calls left, some of them also near converted calls.
   My personal opinion is, that the conversion is fine anyhow.

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

  parent reply	other threads:[~2022-11-17 13:52 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-15 11:13 [PATCH 0/5] pwm: Use regmap_clear_bits and regmap_set_bits where applicable Uwe Kleine-König
2022-11-15 11:13 ` Uwe Kleine-König
2022-11-15 11:13 ` [PATCH 1/5] pwm: fsl-ftm: " Uwe Kleine-König
2022-11-15 11:13 ` [PATCH 2/5] pwm: img: " Uwe Kleine-König
2022-11-15 11:13 ` [PATCH 3/5] pwm: iqs620a: " Uwe Kleine-König
2022-11-15 11:13 ` [PATCH 4/5] pwm: stm32-lp: " Uwe Kleine-König
2022-11-15 11:13   ` Uwe Kleine-König
2022-11-23 10:23   ` Fabrice Gasnier
2022-11-23 10:23     ` Fabrice Gasnier
2022-12-02 17:57     ` Uwe Kleine-König
2022-12-02 17:57       ` Uwe Kleine-König
2022-11-15 11:13 ` [PATCH 5/5] pwm: stm32: " Uwe Kleine-König
2022-11-15 11:13   ` Uwe Kleine-König
2022-11-23 10:23   ` Fabrice Gasnier
2022-11-23 10:23     ` Fabrice Gasnier
2022-11-17 13:52 ` Uwe Kleine-König [this message]
2022-11-17 13:52   ` [PATCH 0/5] pwm: " Uwe Kleine-König

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20221117135237.vqhe6z7aklindlgq@pengutronix.de \
    --to=u.kleine-koenig@pengutronix.de \
    --cc=alexandre.torgue@foss.st.com \
    --cc=broonie@kernel.org \
    --cc=fabrice.gasnier@foss.st.com \
    --cc=kernel@pengutronix.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-pwm@vger.kernel.org \
    --cc=linux-stm32@st-md-mailman.stormreply.com \
    --cc=mcoquelin.stm32@gmail.com \
    --cc=thierry.reding@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.