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

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

[Imran Shaik]

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@quicinc.com/
> 
> 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.

Thanks,
Imran

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

[Krzysztof Kozlowski]

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@quicinc.com/
>>
>> 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.

Best regards,
Krzysztof

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

[Imran Shaik]

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@quicinc.com/
>>>
>>> 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.

While reviewing existing upstream targets, I noticed that SM6375 also 
appears to use this constrained EPSS hardware variant, which is 
currently not represented accurately and would require a similar fix.

Since both Shikra and SM6375 share this hardware variant, would it be 
acceptable to use a common epss-lite compatible for these targets?

Please let me know your thoughts on this.

Thanks,
Imran

> Best regards,
> Krzysztof

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@quicinc.com/
>>>>
>>>> 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

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

[Krzysztof Kozlowski]

On 14/05/2026 16:39, Krzysztof Kozlowski wrote:
> 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@quicinc.com/
>>>>>
>>>>> 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,

I already provided the arguments here:

"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."

so if you have generic compatible, IT MUST be used. You cannot keep
adding more generic compatibles just because existing generic compatible
is not generic enough!

I gave you detailed reasoning and even example why this approach is
getting ridiculous, but you just have to keep pushing your solution to
maintainers and keep asking the same.

You were given the answer and the argument. Now you are just wasting
maintainers time.

Best regards,
Krzysztof