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

[Imran Shaik <imran.shaik@oss.qualcomm.com>]

On 14-05-2026 08:13 pm, Krzysztof Kozlowski wrote:
> 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!
> 

Hi Krzysztof,

Sure, I will drop the generic compatible approach and introduce a Shikra 
specific bindings file (shikra-cpufreq-qcom-hw.yaml), similar to the 
existing EPSS binding, using the compatible string qcom,shikra-cpufreq-epss.

Thanks,
Imran

> 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