linux-kernel - Re: [PATCH v3 03/15] soc: tegra: Add Tegra PMC clock registrations into PMC driver

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:   Mon, 16 Dec 2019 17:11:32 +0200
From:   Peter De Schrijver <pdeschrijver@...dia.com>
To:     Dmitry Osipenko <digetx@...il.com>
CC:     Sowjanya Komatineni <skomatineni@...dia.com>,
        <thierry.reding@...il.com>, <jonathanh@...dia.com>,
        <mperttunen@...dia.com>, <sboyd@...nel.org>,
        <gregkh@...uxfoundation.org>, <tglx@...utronix.de>,
        <robh+dt@...nel.org>, <mark.rutland@....com>,
        <allison@...utok.net>, <pgaikwad@...dia.com>,
        <mturquette@...libre.com>, <horms+renesas@...ge.net.au>,
        <Jisheng.Zhang@...aptics.com>, <krzk@...nel.org>, <arnd@...db.de>,
        <spujar@...dia.com>, <josephl@...dia.com>, <vidyas@...dia.com>,
        <daniel.lezcano@...aro.org>, <mmaddireddy@...dia.com>,
        <markz@...dia.com>, <devicetree@...r.kernel.org>,
        <linux-clk@...r.kernel.org>, <linux-tegra@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, <lgirdwood@...il.com>,
        <broonie@...nel.org>, <perex@...ex.cz>, <tiwai@...e.com>,
        <alexios.zavras@...el.com>, <alsa-devel@...a-project.org>
Subject: Re: [PATCH v3 03/15] soc: tegra: Add Tegra PMC clock registrations
 into PMC driver

On Mon, Dec 16, 2019 at 05:23:23PM +0300, Dmitry Osipenko wrote:
> >> Could you please clarify what do you mean by the "existing users"?
> >> AFAIK, nothing in kernel uses mux clocks.
> >
> > The DT clk bindings allow for parent initialization, so it's certainly
> > possible there are some DTs which rely on this. We promised to never
> > break the bindings, which changing to 1 clock would do.
> 
> What about this variant:
> 
>   1. Keep the old CaR code in place.
> 
>   2. Make CaR driver to scan whole device-tree for the legacy PMC clocks.
> 
>   3. If legacy clock is found, then register PMC clocks from CaR.
> 
>   4. If legacy clocks are not found, then don't register PMC clocks from
> CaR.
> 
>   5. Add clocks support to the PMC driver and only register them if
> legacy clocks are not registered by CaR.
> 
> Now both old and new DTBs can co-exist and work, everyone happy.

That seems even more work.. Today the only upstream user is audio. 
Currently these clocks are setup by the CAR clock driver. However
as they will move to the PMC driver, this mechanism cannot be used.
Hence the plan is to modify the audio driver to check for the PMC clocks
in DT and if they are not available use the CAR clocks as fallback.
The whole reason the clocks move to the PMC driver, is that when PMC
becomes secure, all accesses have to go via an SMC. Given that we don't
want SMCs all over the Tegra drivers, it's a good opportunity to move
the PMC clock handling into the PMC driver. PMC can be secure with both
'new' and old DTs, so just registering the PMC clocks in the CAR driver
if legacy clocks are found in the DT, won't always work.

Peter.