On 24-Jun-25 08:06, Krzysztof Kozlowski wrote:

On 23/06/2025 14:31, Konrad Dybcio wrote:

quoted

On 6/23/25 2:16 PM, Krzysztof Kozlowski wrote:

quoted

On 23/06/2025 14:08, Konrad Dybcio wrote:

quoted

quoted

quoted

quoted

This might be fine, but your DTS suggests clearly this is SoC compatible
deducible, which I already said at v1.

I don't understand why you're rejecting a common solution to a problem
that surely exists outside this one specific chip from one specific
vendor, which may be caused by a multitude of design choices, including
erratic board (not SoC) electrical design

No one brought any arguments so far that common solution is needed. The
only argument provided - sm8550 - is showing this is soc design.

I don't reject common solution. I provided review at v1 to which no one
responded, no one argued, no one provided other arguments.

Okay, so the specific problem that causes this observable limitation
exists on SM8550 and at least one more platform which is not upstream
today. It can be caused by various electrical issues, in our specific
case by something internal to the SoC (but external factors may apply
too)

Looking at the docs, a number of platforms have various limitations
with regards to frequency at specific speed-modes, some of which seem
to be handled implicitly by rounding in the clock framework's
round/set_rate().

I can very easily imagine there are either boards or platforms in the
wild, where the speed must be limited for various reasons, maybe some
of them currently don't advertise it (like sm8550 on next/master) to
hide that

But there are no such now. The only argument (fact) provided in this
patchset is: this is issue specific to SM8550 SoC, not the board. See
last patch. Therefore this is compatible-deducible and this makes
property without any upstream user.

When one appears, we will have to carry code to repeat what the property
does, based on a specific compatible.. And all OS implementations will
have to do the same, instead of parsing the explicit information

Adding new property in such case will be trivial and simple, unlike
having to maintain unused ABI.

And it will be unused, because last patch DTS should be rejected on that
basis: adding redundant properties which are already defined by the
compatible.

Got some more fresh information.. This apparently *does* vary across
boards, as there is a recommended hardware workaround to this rate
limitation (requiring an external clock source, which is up to the
OEM to implement or not)

Konrad