linux-kernel - Re: [RFC v2 3/5] clk: bcm2835: use firmware interface to update pllb

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]

Message-ID: <a142b72b828a798610d885d81189dd21b1870d78.camel@suse.de>
Date:   Tue, 21 May 2019 17:47:03 +0200
From:   Nicolas Saenz Julienne <nsaenzjulienne@...e.de>
To:     Stefan Wahren <stefan.wahren@...e.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        Ray Jui <rjui@...adcom.com>,
        Scott Branden <sbranden@...adcom.com>,
        bcm-kernel-feedback-list@...adcom.com,
        Eric Anholt <eric@...olt.net>
Cc:     linux-pm@...r.kernel.org, sboyd@...nel.org,
        viresh.kumar@...aro.org, mturquette@...libre.com,
        ptesarik@...e.com, rjw@...ysocki.net, linux-kernel@...r.kernel.org,
        mbrugger@...e.de, linux-rpi-kernel@...ts.infradead.org,
        linux-clk@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        ssuloev@...altech.com
Subject: Re: [RFC v2 3/5] clk: bcm2835: use firmware interface to update pllb

Hi Stefan, thanks for your comments!

On Tue, 2019-05-21 at 14:40 +0200, Stefan Wahren wrote:
> Hi Nicolas,
> 
> On 20.05.19 14:11, Stefan Wahren wrote:
> > Hi Nicolas,
> > 
> > the following comments applies only in case Eric is fine with the whole
> > approach.
> > 
> > On 20.05.19 12:47, Nicolas Saenz Julienne wrote:
> > > Raspberry Pi's firmware, which runs in a dedicated processor, keeps
> > maybe we should clarify that the firmware is running in the VPU
> > > track of the board's temperature and voltage. It's resposible for
> > > scaling the CPU frequency whenever it deems the device reached an unsafe
> > > state. On top of that the firmware provides an interface which allows
> > > Linux to to query the clock's state or change it's frequency.
> > I think this requires a separate update of the devicetree binding.
> > > Being the sole user of the bcm2835 clock driver, this integrates the
> > > firmware interface into the clock driver and adds a first user: the CPU
> > > pll, also known as 'pllb'.
> > Please verify that the kernel still works (and this clock driver probe)
> > under the following conditions:
> > 
> > - CONFIG_RASPBERRYPI_FIRMWARE=n
> > - CONFIG_RASPBERRYPI_FIRMWARE=m
> > - older DTBs without patch #1
> i thought about this and the case this driver would return
> -EPROBE_DEFER. The clock driver is too essential for doing such a thing.
> So i think the best solution would be to move these changes into a
> separate driver which should be register by the clock driver (similiar
> to vchiq). This also avoid the need of a new device tree binding.

I understand your concerns.

Wouldn't you prefer registering the device trough the device tree? I'd go with
the same approach as the firmware touchscreen driver, which is registered after
the firmware's probe trough dt's 'simple-bus'. That said, it's not a strongly
held opinion, I'm happy with whatever solution as long as it works.

I get from your comments that you'd like the register based version of 'pllb'
and 'pllb_arm' to be loaded if for some reason the firmware isn't available. Is
that right? The main problem I see with this is the duplication of 'pllb' and
'pllb_arm'. Both drivers will create the same clock device through different
interfaces. Any suggestions on how to deal with that? If not I can simply
remove 'pllb' and 'pllb_arm' from clk-bcm2835.c.

Regards,
Nicolas


Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)