linux-kernel - Re: [PATCH 0/3] clk: bcm2835: critical clocks and parent selection

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: <87oa8b9lv0.fsf@eliezer.anholt.net>
Date:	Thu, 12 May 2016 11:23:15 -0700
From:	Eric Anholt <eric@...olt.net>
To:	Martin Sperl <kernel@...tin.sperl.org>
Cc:	Michael Turquette <mturquette@...libre.com>,
	Stephen Boyd <sboyd@...eaurora.org>,
	linux-kernel@...r.kernel.org, linux-rpi-kernel@...ts.infradead.org,
	linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH 0/3] clk: bcm2835: critical clocks and parent selection

Martin Sperl <kernel@...tin.sperl.org> writes:

>> On 10.05.2016, at 19:37, Eric Anholt <eric@...olt.net> wrote:
>> 
>> Martin Sperl <kernel@...tin.sperl.org> writes:
>>> and also hsm (probably hardware security module):
>>> root@...pcm:~# cat /sys/kernel/debug/clk/hsm/regdump
>>> ctl = 0x000002d6
>>> div = 0x000030e0
>>> root@...pcm:~# cat /sys/kernel/debug/clk/hsm/clk_rate
>>> 163551916
>> 
>> That's the HDMI state machine (there's even a comment saying so),
>> controlled by the vc4 driver.
>> 
>>> So turning plld off stops sdram and hsm - at least that is my
>>> interpretation.
>>> 
>>> This means we need to define a clock property in firmware or
>>> we need a ram node making use of "mmio-sram" maybe?
>>> 
>>> Marking sdram as "critical" or "hand_off" could also solve that
>>> for the moment (but it does not solve all the other hidden
>>> clock dependencies of the firmware)
>> 
>> If there are other hidden dependencies, then we should figure them out.
>
> But strangely the sdram (plus the below) is the only one with
> plld that is enabled (unless it is one of the clocks we have not
> added to the kernel side yet)
>
> Maybe there is something that derives directly from plld_core
> or any of the other plld-dividers?

Nothing I can find.

> Core would indicate anything central to the videocore...
> Anyway both plld_core as well as plld_per ad well as both
> Pll_dsi that are running by default (but I doubt that the
> Dsi would be relevant)
>
> I guess you are in a better situation to figure out which
> hidden HW blocks uses plld...
>
>> 
>>> --- a/drivers/clk/bcm/clk-bcm2835.c
>>> +++ b/drivers/clk/bcm/clk-bcm2835.c
>>> @@ -1655,7 +1655,8 @@ static const struct bcm2835_clk_desc 
>>> clk_desc_array[] = {
>>>                .ctl_reg = CM_SDCCTL,
>>>                .div_reg = CM_SDCDIV,
>>>                .int_bits = 6,
>>> -               .frac_bits = 0),
>>> +               .frac_bits = 0,
>>> +               .flags = CLK_IS_CRITICAL),
>>>        [BCM2835_CLOCK_V3D]     = REGISTER_VPU_CLK(
>>>                .name = "v3d",
>>>                .ctl_reg = CM_V3DCTL,
>> 
>> The Pi foundation folks believe that the cprman SDRAM clock isn't ever
>> used (there's a separate PLL in the SDRAM controller, and cprman is only
>> intended for unused low-power states), and at least in your sample of
>> the reg, it's not enabled.  Instead of grepping for clk_enable_count, it
> See my comment above - it must be configured for some reason
> during the boot process by the firmware .

You have to write the register to configure the sdram controller's clock
parent.

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