From: Andrea della Porta <andrea.porta@suse.com>
To: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Cc: "Andrea della Porta" <andrea.porta@suse.com>,
"Uwe Kleine-König" <ukleinek@kernel.org>,
linux-pwm@vger.kernel.org, "Rob Herring" <robh@kernel.org>,
"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
"Conor Dooley" <conor+dt@kernel.org>,
"Florian Fainelli" <florian.fainelli@broadcom.com>,
"Broadcom internal kernel review list"
<bcm-kernel-feedback-list@broadcom.com>,
devicetree@vger.kernel.org, linux-rpi-kernel@lists.infradead.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org,
"Naushir Patuck" <naush@raspberrypi.com>,
"Stanimir Varbanov" <svarbanov@suse.de>,
mbrugger@suse.com, "Sean Young" <sean@mess.org>,
"Julian Braha" <julianbraha@gmail.com>
Subject: Re: [PATCH v7 2/3] pwm: rp1: Add RP1 PWM controller driver
Date: Fri, 4 Sep 2026 18:31:57 +0200 [thread overview]
Message-ID: <apryfdwBCHaGJobA@apocalypse> (raw)
In-Reply-To: <46772551-207f-4795-89d5-6c02a0b85410@wanadoo.fr>
Hi Christophe,
On 22:36 Thu 03 Sep , Christophe JAILLET wrote:
> Le 20/07/2026 à 11:44, Andrea della Porta a écrit :
> > From: Naushir Patuck <naush@raspberrypi.com>
> >
> > The Raspberry Pi RP1 southbridge features an embedded PWM
> > controller with 4 output channels, alongside an RPM interface
> > to read the fan speed on the Raspberry Pi 5.
> >
> > Add the supporting driver.
> >
> > Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
> > Co-developed-by: Stanimir Varbanov <svarbanov@suse.de>
> > Signed-off-by: Stanimir Varbanov <svarbanov@suse.de>
> > Signed-off-by: Andrea della Porta <andrea.porta@suse.com>
>
> Hi,
>
> ...
>
> > +static int rp1_pwm_probe(struct platform_device *pdev)
> > +{
> > + struct device *dev = &pdev->dev;
> > + struct device_node *np = dev->of_node;
> > + unsigned long clk_rate;
> > + struct pwm_chip *chip;
> > + void __iomem *base;
> > + struct rp1_pwm *rp1;
> > + int ret;
> > +
> > + chip = devm_pwmchip_alloc(dev, RP1_PWM_NUM_PWMS, sizeof(*rp1));
> > + if (IS_ERR(chip))
> > + return PTR_ERR(chip);
> > +
> > + rp1 = pwmchip_get_drvdata(chip);
> > +
> > + base = devm_platform_ioremap_resource(pdev, 0);
> > + if (IS_ERR(base))
> > + return PTR_ERR(base);
> > +
> > + rp1->regmap = devm_regmap_init_mmio(dev, base, &rp1_pwm_regmap_config);
> > + if (IS_ERR(rp1->regmap))
> > + return dev_err_probe(dev, PTR_ERR(rp1->regmap), "Cannot initialize regmap\n");
> > +
> > + rp1->clk = devm_clk_get(dev, NULL);
>
> Could it be devm_clk_get_enabled() to simplify the error handling path as
> done above with other devm function?
The very first version of this patches had devres everywhere, but Uwe has correctly
spotted that this could lead to clock ops imbalance, please see:
https://lore.kernel.org/all/adLTwOTbkJ0VQXy6@monoceros/
As a result, I turned devm_clk_get_enabled() into the corresponding non devres/single
component functions since now disengaging the clock depends on a conditional.
Of course this does not make much sense in case we don't need a .remove callback,
but it seems that I can reintroduce it again if we agree to use EXPORT_SYMBOL_NS.
> ...
>
> > + if (IS_ERR(rp1->clk))
> > + return dev_err_probe(dev, PTR_ERR(rp1->clk), "Clock not found\n");
> > +
> > + ret = clk_prepare_enable(rp1->clk);
> > + if (ret)
> > + return dev_err_probe(dev, ret, "Failed to enable clock\n");
>
> ... this also saves these 3 lines.
See above.
>
> > + rp1->clk_enabled = true;
> > +
> > + ret = devm_clk_rate_exclusive_get(dev, rp1->clk);
> > + if (ret) {
> > + dev_err_probe(dev, ret, "Failed to get exclusive rate\n");
> > + goto err_disable_clk;
> > + }
> > +
> > + clk_rate = clk_get_rate(rp1->clk);
> > + if (!clk_rate) {
> > + ret = dev_err_probe(dev, -EINVAL, "Failed to get clock rate\n");
> > + goto err_disable_clk;
> > + }
> > + /*
> > + * To prevent u64 overflow in period calculations:
> > + * mul_u64_u64_div_u64(period_ns, clk_rate, NSEC_PER_SEC)
> > + * If clk_rate > 1 GHz, the result can overflow.
> > + */
> > + if (clk_rate > HZ_PER_GHZ) {
> > + ret = dev_err_probe(dev, -EINVAL, "Clock rate > 1 GHz is not supported\n");
> > + goto err_disable_clk;
> > + }
> > + rp1->clk_rate = clk_rate;
> > +
> > + chip->ops = &rp1_pwm_ops;
> > + chip->atomic = true;
> > +
> > + platform_set_drvdata(pdev, chip);
> > +
> > + ret = pwmchip_add(chip);
>
> Could it be devm_pwmchip_add() to simplify the error handling path as done
> above with other devm function?
Due to the above-mentioned scenario and since .remove is called before devres release
funtions, that would make the clock to be released before the pwm chip, causing
inconsistencies if the pwm is used in the meanwhile.
Many thanks,
Andrea.
>
> > + if (ret) {
> > + dev_err_probe(dev, ret, "Failed to register PWM chip\n");
> > + goto err_disable_clk;
> > + }
> > +
> > + ret = of_syscon_register_regmap(np, rp1->regmap);
> > + if (ret) {
> > + dev_err_probe(dev, ret, "Failed to register syscon\n");
> > + goto err_remove_chip;
> > + }
> > +
> > + return 0;
> > +
> > +err_remove_chip:
> > + pwmchip_remove(chip);
> > +err_disable_clk:
> > + clk_disable_unprepare(rp1->clk);
> > +
> > + return ret;
> > +}
> ...
>
> CJ
next prev parent reply other threads:[~2026-09-04 16:28 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-20 9:44 [PATCH v7 0/3] Add RP1 PWM controller support Andrea della Porta
2026-07-20 9:44 ` [PATCH v7 1/3] dt-bindings: pwm: Add Raspberry Pi RP1 PWM controller Andrea della Porta
2026-07-20 9:44 ` [PATCH v7 2/3] pwm: rp1: Add RP1 PWM controller driver Andrea della Porta
2026-09-03 20:36 ` Christophe JAILLET
2026-09-04 16:31 ` Andrea della Porta [this message]
2026-07-20 9:44 ` [PATCH v7 3/3] arm64: dts: broadcom: rpi-5: Add RP1 PWM node Andrea della Porta
2026-09-03 20:11 ` [PATCH v7 0/3] Add RP1 PWM controller support Florian Fainelli
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=apryfdwBCHaGJobA@apocalypse \
--to=andrea.porta@suse.com \
--cc=bcm-kernel-feedback-list@broadcom.com \
--cc=christophe.jaillet@wanadoo.fr \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=florian.fainelli@broadcom.com \
--cc=julianbraha@gmail.com \
--cc=krzk+dt@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pwm@vger.kernel.org \
--cc=linux-rpi-kernel@lists.infradead.org \
--cc=mbrugger@suse.com \
--cc=naush@raspberrypi.com \
--cc=robh@kernel.org \
--cc=sean@mess.org \
--cc=svarbanov@suse.de \
--cc=ukleinek@kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox