linux-kernel - Re: [PATCH 2/2] clk: amlogic: c3: Limit the rate boundaries of clk

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: <1ja5bu90jb.fsf@starbuckisacylon.baylibre.com>
Date: Mon, 13 Jan 2025 16:49:28 +0100
From: Jerome Brunet <jbrunet@...libre.com>
To: Neil Armstrong <neil.armstrong@...aro.org>
Cc: Chuan Liu <chuan.liu@...ogic.com>,  Chuan Liu via B4 Relay
 <devnull+chuan.liu.amlogic.com@...nel.org>,  Michael Turquette
 <mturquette@...libre.com>,  Stephen Boyd <sboyd@...nel.org>,  Kevin Hilman
 <khilman@...libre.com>,  Martin Blumenstingl
 <martin.blumenstingl@...glemail.com>,  linux-clk@...r.kernel.org,
  linux-kernel@...r.kernel.org,  linux-amlogic@...ts.infradead.org,
  linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH 2/2] clk: amlogic: c3: Limit the rate boundaries of clk_hw

On Mon 13 Jan 2025 at 15:46, Neil Armstrong <neil.armstrong@...aro.org> wrote:

>>>
>>> I think that the clock configuration exceeding the timing constraints
>>> is a hidden danger that all chips have and face, but this hidden danger
>>> is not easy to be exposed?
>>>
>>> For instance, if the routing of a clock network is close to the clock
>>> or data bus of other modules, and this clock network is wrongly
>>> configured to a frequency beyond the constraints, causing crosstalk
>>> that affects the normal operation of other modules. If such a situation
>>> occurs, it will be very difficult to troubleshoot. How should this
>>> situation be handled more reasonably?
>> Fix your consumers drivers if you need to. Set range if you must.
>> Those are not clock provider constraints. Those are use-case ones. It
>> does belong here and CCF already provides the necessary infra to deal
>> with ranges.
>
> I kind of disagree here, if the vendor has the data and is willing to share
> the range for each clock path of the system, I think it should be welcome!
>
> Usually those ranges are not disclosed, so we don't set them, but CCF will
> certainly use all those range to make an even better decision on the lock
> routing.

I did not say you should not use them, I say that a platform
use-case, which is what this is, should not be hard coded within the
clock provider driver.

This is no different than an assigned-rate, and like any other platform
description, it belong in DT.

We've already seen how these ranges may depend on what else you choose
to do on the system or even what package a particular SoC variant is
using.

>
> Neil
>
>>