linux-kernel - Re: [RFC] clk: imx: Allow re-parenting by default on set rate

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 11 Mar 2019 10:41:40 +0000
From:   Abel Vesa <abel.vesa@....com>
To:     Sascha Hauer <s.hauer@...gutronix.de>
CC:     Michael Turquette <mturquette@...libre.com>,
        Stephen Boyd <sboyd@...nel.org>,
        Sascha Hauer <kernel@...gutronix.de>,
        Lucas Stach <l.stach@...gutronix.de>,
        Shawn Guo <shawnguo@...nel.org>,
        Aisheng Dong <aisheng.dong@....com>,
        Jacky Bai <ping.bai@....com>,
        Anson Huang <anson.huang@....com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        dl-linux-imx <linux-imx@....com>,
        Fabio Estevam <fabio.estevam@....com>,
        "linux-clk@...r.kernel.org" <linux-clk@...r.kernel.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [RFC] clk: imx: Allow re-parenting by default on set rate

On 19-03-11 11:28:25, Sascha Hauer wrote:
> Hi Abel,
> 
> On Thu, Mar 07, 2019 at 09:20:37AM +0000, Abel Vesa wrote:
> > By default, the muxes should re-parent on set_rate.
> > This would allow the drivers to control only the leaf clock node,
> > leaving the rest to the clock driver, that way simplifying the
> > clock control.
> 
> I am afraid of this change. Besides the rate there might be other
> reasons to choose one mux input over another, consider for example low
> power audio playback where we need one specific mux setting because it
> provides a clock which runs at low power mode.
> On the IPU on i.MX5/6 there are clocks being used as pixel clocks
> derived from different muxes. I don't think you want to pick an input
> clock just because it happens to deliver the best clock rate at that
> point in time, but really is shared with some other clock that changes
> its rate in the next moment.
> 

> I have no concrete examples for things that break with this change, but
> I would be more confident if we change the behaviour explicitly only for
> the muxes that we have reviewed to cope with this change.
> 

Fair enough. We could replace all the imx_clk_mux with imx_clk_mux_noreparent
and after that we can independently switch the clocks that are safe (to switch)
to imx_clk_mux (which would not have the noreparent flag set).

The main idea is to simplify the clock control from drivers point of view.

The end goal here would be to only have noreparent flag set for the clocks that
need specific mux control.

> Sascha
> 
> -- 
> Pengutronix e.K.                           |                             |
> Industrial Linux Solutions                 | https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.pengutronix.de%2F&amp;data=02%7C01%7Cabel.vesa%40nxp.com%7Cde43ba7dcd774a3709df08d6a60c4d90%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636878969100157679&amp;sdata=4eU6YmuXDhHJZUKVKJhiRwlzq7b9XIrUfLSl2JFlRd8%3D&amp;reserved=0  |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
> Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |