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]
Message-ID: <20191216122005.GB28289@pdeschrijver-desktop.Nvidia.com>
Date:   Mon, 16 Dec 2019 14:20:05 +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 Thu, Dec 12, 2019 at 04:43:53AM +0300, Dmitry Osipenko wrote:
> External email: Use caution opening links or attachments
> 
> 
> 11.12.2019 18:10, Peter De Schrijver пишет:
> > On Tue, Dec 10, 2019 at 08:41:56PM +0300, Dmitry Osipenko wrote:
> >
> > ..
> >
> >>>
> >>> PMC clock gate is based on the state of CLKx_ACCEPT_REQ and FORCE_EN
> >>> like explained above.
> >>>
> >>> CLKx_ACCEPT_REQ is 0 default and FORCE_EN acts as gate to enable/disable
> >>> EXTPERIPH clock output to PMC CLK_OUT_1/2/3.
> >>
> >> [and to enable OSC as well]
> >>
> >>> So I believe we need to register as MUX and Gate rather than as a single
> >>> clock. Please confirm.
> >>
> >> 1. The force-enabling is applied to both OSC and EXTERN sources of
> >> PMC_CLK_OUT_x by PMC at once.
> >>
> >> 2. Both of PMC's force-enabling and OSC/EXTERN selection is internal to PMC.
> >>
> >> Should be better to define it as a single "pmc_clk_out_x". I don't see
> >> any good reasons for differentiating PMC's Gate from the MUX, it's a
> >> single hardware unit from a point of view of the rest of the system.
> >>
> >> Peter, do you have any objections?
> >
> > The reason to have separate gate and mux clocks, is to preserve compatibility
> > with existing users.
> > Otherwise the current users would need to figure out if there's a
> > single clock or 2 clocks to configure. I don't think adding that code in
> > each user is worth it only to have a sligthly nicer modelling of the
> > hardware.
> 
> 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. 

Peter.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ