Re: [PATCH 1/2] dt-bindings: cpufreq: qcom-hw: Document Shikra CPUFREQ Hardware

[Krzysztof Kozlowski]

On 08/05/2026 18:03, Imran Shaik wrote:
> 
> 
> On 05-05-2026 02:23 pm, Krzysztof Kozlowski wrote:
>> On 05/05/2026 10:50, Imran Shaik wrote:
>>>
>>>
>>> On 04-05-2026 03:53 pm, Krzysztof Kozlowski wrote:
>>>> On Fri, May 01, 2026 at 12:45:44PM +0530, Imran Shaik wrote:
>>>>> The Qualcomm Shikra cpufreq hardware is functionally identical to EPSS,
>>>>> but supports only up to 12 frequency lookup table (LUT) entries. Introduce
>>>>> qcom,cpufreq-epss-lite to represent this constrained EPSS variant.
>>>>
>>>> The entire point of having a generic compatible is that it MUST match
>>>> all devices. If it does not, then it is pointless to push that generic
>>>> compatible.
>>>>
>>>> I am speaking about qcom,cpufreq-epss.
>>>>
>>>> That's nothing new, I was arguing about it already, but now you have
>>>> confirmation of the mess introduced by generic compatibles. Solution is
>>>> not to add more generic compatibles, because what will be next?
>>>> qcom,cpufreq-epss-lighter?
>>>> qcom,cpufreq-epss-more-lite?
>>>> qcom,cpufreq-epss-high?
>>>>
>>>> Same was here:
>>>> https://lore.kernel.org/all/20240828203721.2751904-17-quic_nkela@xxxxxxxxxxx/
>>>>
>>>> So that's second time I object and do object for every new instance. No
>>>> to generic compatibles, they are proven to be wrong at least for
>>>> Qualcomm.
>>>>
>>>> Best regards,
>>>> Krzysztof
>>>>
>>>
>>> Hi Krzysztof,
>>>
>>> There is no functional change to the latest EPSS hardware
>>> (qcom,cpufreq-epss) in this case. The Shikra platform uses the CPU
>>> frequency scaling block, which is a predecessor of EPSS and is referred
>>> to as EPSS‑lite. The only difference between EPSS‑lite and EPSS is the
>>> maximum number of frequency look up table (LUT) entries.
>>>
>>> This constrained EPSS block is not specific to Shikra and can be reused
>>> by other SoCs that implement the same hardware. Hence, we have added a
>>> separate epss-lite compatible and reused the existing bindings, as all
>>> other aspects of the hardware behavior and interface remain identical.
>>
>> I don't understand how any of this is relevant to my comment. I know
>> what you did.
>>
> 
> Hi Krzysztof,
> 
> The intent behind proposing an epss-lite compatible was to describe a 
> common hardware variant and avoid introducing SoC‑specific handling in 
> the cpufreq driver.

And I already objected. Look:

"So that's second time I object and do object for every new instance. No
to generic compatibles"

I provided arguments for that in the past.

NAK

Best regards,
Krzysztof