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:   Sat, 22 Jun 2019 11:54:47 +0200
From:   Stefan Wahren <stefan.wahren@...e.com>
To:     Stephen Boyd <sboyd@...nel.org>,
        Mike Turquette <mturquette@...libre.com>
Cc:     Florian Fainelli <f.fainelli@...il.com>,
        Nicolas Saenz Julienne <nsaenzjulienne@...e.de>,
        linux-kernel@...r.kernel.org, mbrugger@...e.de,
        viresh.kumar@...aro.org, rjw@...ysocki.net, eric@...olt.net,
        bcm-kernel-feedback-list@...adcom.com, ptesarik@...e.com,
        linux-rpi-kernel@...ts.infradead.org, ssuloev@...altech.com,
        linux-clk@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        linux-pm@...r.kernel.org
Subject: Re: [PATCH v4 0/7] cpufreq support for Raspberry Pi

Hi Stephen,
hi Mike,

Am 13.06.19 um 06:31 schrieb Stefan Wahren:
> Hi Florian,
> hi Stephen,
>
> Am 13.06.19 um 05:31 schrieb Florian Fainelli:
>> On 6/12/2019 11:24 AM, Nicolas Saenz Julienne wrote:
>>> Hi all,
>>> this aims at adding cpufreq support to the Raspberry Pi family of
>>> boards.
>>>
>>> The series first factors out 'pllb' from clk-bcm2385 and creates a new
>>> clk driver that operates it over RPi's firmware interface[1]. We are
>>> forced to do so as the firmware 'owns' the pll and we're not allowed to
>>> change through the register interface directly as we might race with the
>>> over-temperature and under-voltage protections provided by the firmware.
>>>
>>> Next it creates a minimal cpufreq driver that populates the CPU's opp
>>> table, and registers cpufreq-dt. Which is needed as the firmware
>>> controls the max and min frequencies available.
>>>
>>> This was tested on a RPi3b+ and RPI2b, both using multi_v7_defconfig and
>>> arm64's defconfig.
>> How do we go about merging this? Stefan, will you pick up patch 3, 6 and
>> 7 and submit them for 5.3/5.4? Viresh has already picked up patch 4.
> is it possible to let patches 1,2, 3 and 5 go via clk-tree?
>
> I would take care of 6 and 7.
>
> Stefan
are you fine with the series, since Viresh already picked up patch 4?

are you okay with my suggestion above?

Stefan


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ