The rtc device node is always or at the very least can possibly be NULL.
Since v5.12-rc1-dontuse/3c9ea42802a1fbf7ef29660ff8c6e526c58114f6 this
will lead to a NULL pointer dereference.
To fix this we fallback to using the parent node which is the i2c client
node as set by devm_rtc_allocate_device().
Using the i2c client node seems to be what other similar drivers do
e.g. rtc-pcf8563.c.
Signed-off-by: Francois Gervais <[email protected]>
---
drivers/rtc/rtc-pcf85063.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/rtc/rtc-pcf85063.c b/drivers/rtc/rtc-pcf85063.c
index aef6c1ee8bb0..463991c74fdd 100644
--- a/drivers/rtc/rtc-pcf85063.c
+++ b/drivers/rtc/rtc-pcf85063.c
@@ -478,6 +478,7 @@ static struct clk *pcf85063_clkout_register_clk(struct pcf85063 *pcf85063)
{
struct clk *clk;
struct clk_init_data init;
+ struct device_node *node = pcf85063->rtc->dev.of_node;
init.name = "pcf85063-clkout";
init.ops = &pcf85063_clkout_ops;
@@ -486,16 +487,17 @@ static struct clk *pcf85063_clkout_register_clk(struct pcf85063 *pcf85063)
init.num_parents = 0;
pcf85063->clkout_hw.init = &init;
+ if (node == NULL)
+ node = pcf85063->rtc->dev.parent->of_node;
+
/* optional override of the clockname */
- of_property_read_string(pcf85063->rtc->dev.of_node,
- "clock-output-names", &init.name);
+ of_property_read_string(node, "clock-output-names", &init.name);
/* register the clock */
clk = devm_clk_register(&pcf85063->rtc->dev, &pcf85063->clkout_hw);
if (!IS_ERR(clk))
- of_clk_add_provider(pcf85063->rtc->dev.of_node,
- of_clk_src_simple_get, clk);
+ of_clk_add_provider(node, of_clk_src_simple_get, clk);
return clk;
}
--
2.17.1
On Wed, 10 Mar 2021 16:10:26 -0500, Francois Gervais wrote:
> The rtc device node is always or at the very least can possibly be NULL.
>
> Since v5.12-rc1-dontuse/3c9ea42802a1fbf7ef29660ff8c6e526c58114f6 this
> will lead to a NULL pointer dereference.
>
> To fix this we fallback to using the parent node which is the i2c client
> node as set by devm_rtc_allocate_device().
>
> [...]
Applied, thanks!
[1/1] rtc: pcf85063: fallback to parent of_node
commit: 03531606ef4cda25b629f500d1ffb6173b805c05
I made the fallback unconditionnal because this should have been that way from
the beginning as you point out.
Best regards,
--
Alexandre Belloni <[email protected]>
Hello Greg,
On 17.04.2021 00:16:40, Alexandre Belloni wrote:
> On Wed, 10 Mar 2021 16:10:26 -0500, Francois Gervais wrote:
> > The rtc device node is always or at the very least can possibly be NULL.
> >
> > Since v5.12-rc1-dontuse/3c9ea42802a1fbf7ef29660ff8c6e526c58114f6 this
> > will lead to a NULL pointer dereference.
> >
> > To fix this we fallback to using the parent node which is the i2c client
> > node as set by devm_rtc_allocate_device().
> >
> > [...]
>
> Applied, thanks!
>
> [1/1] rtc: pcf85063: fallback to parent of_node
> commit: 03531606ef4cda25b629f500d1ffb6173b805c05
>
> I made the fallback unconditionnal because this should have been that way from
> the beginning as you point out.
can you queue this for stable, as it causes a NULL Pointer deref with
(at least) v5.12.
Thanks,
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Embedded Linux | https://www.pengutronix.de |
Vertretung West/Dortmund | Phone: +49-231-2826-924 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
On Sat, May 22, 2021 at 05:36:36PM +0200, Marc Kleine-Budde wrote:
> Hello Greg,
>
> On 17.04.2021 00:16:40, Alexandre Belloni wrote:
> > On Wed, 10 Mar 2021 16:10:26 -0500, Francois Gervais wrote:
> > > The rtc device node is always or at the very least can possibly be NULL.
> > >
> > > Since v5.12-rc1-dontuse/3c9ea42802a1fbf7ef29660ff8c6e526c58114f6 this
> > > will lead to a NULL pointer dereference.
> > >
> > > To fix this we fallback to using the parent node which is the i2c client
> > > node as set by devm_rtc_allocate_device().
> > >
> > > [...]
> >
> > Applied, thanks!
> >
> > [1/1] rtc: pcf85063: fallback to parent of_node
> > commit: 03531606ef4cda25b629f500d1ffb6173b805c05
> >
> > I made the fallback unconditionnal because this should have been that way from
> > the beginning as you point out.
>
> can you queue this for stable, as it causes a NULL Pointer deref with
> (at least) v5.12.
After it hits Linus's tree, let [email protected] know the id and
we will glad to add it to the stable trees.
thanks,
greg k-h
On 23.05.2021 10:21:10, Greg Kroah-Hartman wrote:
> On Sat, May 22, 2021 at 05:36:36PM +0200, Marc Kleine-Budde wrote:
> > > [1/1] rtc: pcf85063: fallback to parent of_node
> > > commit: 03531606ef4cda25b629f500d1ffb6173b805c05
> > >
> > > I made the fallback unconditionnal because this should have been that way from
> > > the beginning as you point out.
> >
> > can you queue this for stable, as it causes a NULL Pointer deref with
> > (at least) v5.12.
>
> After it hits Linus's tree, let [email protected] know the id and
> we will glad to add it to the stable trees.
It's in Linus's tree since v5.13-rc1~64^2~19 and the commit id is
03531606ef4c ("rtc: pcf85063: fallback to parent of_node").
regards,
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Embedded Linux | https://www.pengutronix.de |
Vertretung West/Dortmund | Phone: +49-231-2826-924 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
On Sun, May 23, 2021 at 08:24:41PM +0200, Marc Kleine-Budde wrote:
> On 23.05.2021 10:21:10, Greg Kroah-Hartman wrote:
> > On Sat, May 22, 2021 at 05:36:36PM +0200, Marc Kleine-Budde wrote:
> > > > [1/1] rtc: pcf85063: fallback to parent of_node
> > > > commit: 03531606ef4cda25b629f500d1ffb6173b805c05
> > > >
> > > > I made the fallback unconditionnal because this should have been that way from
> > > > the beginning as you point out.
> > >
> > > can you queue this for stable, as it causes a NULL Pointer deref with
> > > (at least) v5.12.
> >
> > After it hits Linus's tree, let [email protected] know the id and
> > we will glad to add it to the stable trees.
>
> It's in Linus's tree since v5.13-rc1~64^2~19 and the commit id is
> 03531606ef4c ("rtc: pcf85063: fallback to parent of_node").
Now queued up, thanks.
greg k-h