lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 9 Sep 2022 02:06:36 +0000
From:   Peng Fan <peng.fan@....com>
To:     Marek Vasut <marex@...x.de>,
        "tharvey@...eworks.com" <tharvey@...eworks.com>,
        Stephen Boyd <sboyd@...nel.org>
CC:     Matti Vaittinen <mazziesaccount@...il.com>,
        linux-clk <linux-clk@...r.kernel.org>,
        open list <linux-kernel@...r.kernel.org>,
        Fabio Estevam <festevam@...il.com>,
        Shawn Guo <shawnguo@...nel.org>,
        dl-linux-imx <linux-imx@....com>,
        Michael Turquette <mturquette@...libre.com>
Subject: RE: BD71847 clk driver disables clk-32k-out causing RTC/WDT failure

> Subject: Re: BD71847 clk driver disables clk-32k-out causing RTC/WDT failure
> 
> On 9/8/22 21:25, Tim Harvey wrote:
> > On Thu, Sep 8, 2022 at 9:55 AM Marek Vasut <marex@...x.de> wrote:
> >>
> >> On 9/8/22 18:00, Tim Harvey wrote:
> >>> On Thu, Sep 1, 2022 at 9:14 PM Matti Vaittinen
> <mazziesaccount@...il.com> wrote:
> >>>>
> >>>> Hi Tim,
> >>>>
> >>>> On 9/2/22 01:23, Tim Harvey wrote:
> >>>>> Greetings,
> >>>>>
> >>>>> I've found that the bd71847 clk driver
> (CONFIG_COMMON_CLK_BD718XX
> >>>>> drivers/clk/clk-bd718x7.c) disables clk-32k-out (the BD71847
> >>>>> C32K_OUT
> >>>>> pin) which is connected IMX8MM RTC_XTALI which ends up disabling
> >>>>> the IMX RTC as well as the IMX WDOG functionality.
> >>>>
> >>>> //snip
> >>>>
> >>>>> This happens via clk_unprepare_unused() as nothing is flagging the
> >>>>> clk-32k-out as being used. What should be added to the device-tree
> >>>>> to signify that this clk is indeed necessary and should not be disabled?
> >>>>
> >>>> I have seen following proposal from Marek Vasut:
> >>>>
> >>>>
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fl
> >>>> ore.kernel.org%2Fall%2F20220517235919.200375-1-
> marex%40denx.de%2FT%
> >>>>
> 2F%23m52d6d0831bf43d5f293e35cb27f3021f278d0564&amp;data=05%7C0
> 1%7Cp
> >>>>
> eng.fan%40nxp.com%7C07d48edcc47c4694e08208da91da2bf4%7C686ea1d
> 3bc2b
> >>>>
> 4c6fa92cd99c5c301635%7C0%7C0%7C637982664162868785%7CUnknown%
> 7CTWFpb
> >>>>
> GZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI
> 6
> >>>>
> Mn0%3D%7C3000%7C%7C%7C&amp;sdata=uF26u9g4onuqCWzPRAvD%2F%
> 2FLByaEhh5
> >>>> Dtah9K8CcAOAM%3D&amp;reserved=0
> >>>>
> >>>> I am not sure if the discussion is completed though. I guess it was
> >>>> agreed this was needed/usefull and maybe the remaining thing to
> >>>> decide was just the property naming.
> >>>>
> >>>> Best Regards
> >>>>           -- Matti
> >>>>
> >>>
> >>> Thanks Matti,
> >>>
> >>> Marek - has there been any progress on determining how best to keep
> >>> certain clocks from being disabled?
> >>
> >> No. You can read the discussion above.
> >
> > Marek,
> >
> > I wasn't on the linux-clk list at that time so can't respond to the
> > thread but the discussion seems to have died out a couple of months
> > ago with no agreement between you or Stephen on how to deal with it.
> >
> > So where do we take this from here? It looks like there are about 18
> > boards with dt's using "rohm,bd718*" which would all have non working
> > RTC/WDOG with CONFIG_COMMON_CLK_BD718XX enabled (which it is in
> > arch/arm64/configs/defconfig) right?

Is there any requirement that the bd718xx clk needs to be runtime on/off?
I suppose the clk should always be never be off, if yes, why not have something:

diff --git a/drivers/clk/clk-bd718x7.c b/drivers/clk/clk-bd718x7.c
index ac40b669d60b..109cef35418b 100644
--- a/drivers/clk/clk-bd718x7.c
+++ b/drivers/clk/clk-bd718x7.c
@@ -104,6 +104,8 @@ static int bd71837_clk_probe(struct platform_device *pdev)
                dev_err(&pdev->dev, "No parent clk found\n");
                return -EINVAL;
        }
+       init.flags = CLK_IGNORE_UNUSED;
+
        switch (chip) {
        case ROHM_CHIP_TYPE_BD71837:
        case ROHM_CHIP_TYPE_BD71847:

> 
> Feel free to continue the effort.

Tim, would you continue the effort?

Regards,
Peng.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ