Re: [PATCH v4 1/8] dt-bindings: serial: describe SA8255p

[Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>]

On 5/5/25 3:42 PM, Praveen Talari wrote:
> Hi Krzysztof
> 
> On 5/5/2025 3:29 PM, Krzysztof Kozlowski wrote:
>> On 05/05/2025 08:51, Praveen Talari wrote:
>>>>>>> +    serial@990000 {
>>>>>>> +        compatible = "qcom,sa8255p-geni-uart";
>>>>>>> +        reg = <0x990000 0x4000>;
>>>>>>> +        interrupts = <GIC_SPI 531 IRQ_TYPE_LEVEL_HIGH>;
>>>>>> Why isn't here wakeup interrupt? Commit msg also does not help me to
>>>>>> understand why number of interrupts varies.
>>>>> Currently we are not using wake-irq because it is optional for our current
>>>>> implementation.
>>>> Great explanation. I asked why is it optional, answer because it is
>>>> optional.
>>> sorry.
>>>> What does it mean optional? This is part of the SoC, so how given one,
>>>> fixed SoC can have it routed or not routed in the same time?
>>> the serial driver doesn't enter runtime suspend mode until the port is
>>> closed.
>>>
>>> therefore, there is no need for a wake IRQ when the driver is in an
>>> active state
>> You described current Linux driver, so if we change Linux driver or we
>> try for example FreeBSD, then bindings are different?
> 
> Currently, the driver includes code to register the device's wakeup capability
> 
> but it lacks the necessary handler code for wakeup IRQ. According to the serial driver,
> 
> the wake IRQ is meant to wake up the device but the device remains active because
> 
> the serial driver does not enter runtime suspend mode until the port closed.
> 
> So it is better to exclude the wake IRQ until the appropriate code is added.

No, dt-bindings must describe the hardware in its entirety (to the
extent that software differentiates it), to the best of our
understanding, the drivers are free to exist or not, similarly they
may not implement all the features

DTB and kernel versions can be out of sync, so having a complete DT
description saves us from having to add explicit backwards
compatibility clauses in each driver and maintain them for the next 15
years, as well as letting the user update the kernel without worrying
about a breakage

Konrad