Re: [PATCH v6 2/5] dt-bindings: media: camss: Add qcom,sdm670-camss

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 01/11/2024 10:36, Bryan O'Donoghue wrote:
> On 01/11/2024 09:17, Krzysztof Kozlowski wrote:
>> On 31/10/2024 16:42, Bryan O'Donoghue wrote:
>>> On 11/10/2024 15:29, Krzysztof Kozlowski wrote:
>>>> How do you imagine writing drivers and request items by order (not by
>>>> name) if the order is different in each flavor?
>>>
>>> I don't think I'd be much in favour of relying on declaration order in
>>> the dts, favouring names to find resources instead, tbh.
>>>
>>> The 8250 has regs that sort by address and name in the same order. For
>>> 8280xp we preferred sort by address and you're right the interrupt
>>> sorting isn't consistent.
>>>
>>> However the latest applied dts for CAMSS is sort by address/irq not sort
>>> by reg-name irq-name.
>>>
>>> Unless its a NAK from yourself and Rob, that would certainly be my
>>> preference for any _new_ additions subsequent.
>>
>> It's not a NAK as long you keep the same order in new bindings, which I
>> think it is not possible. I repeat myself: there is no rule/style that
>> list should be ordered by values, but there is a rule that all devices
>> from the same family should have the same order of items in the list. I
>> don't think it is achievable with your approach - sorting by value.
> 
> Grand.
> 
> I'm happy enough to sort by IP alpha TBH.

I actually missed that Rob responded here clarifying his point of view.
Two of DT maintainers expressed their dislike for such coding style of
sorting by value.

Regardless whether it is helping or not, it is not even possible to
implement. Binding does not know the addresses and one could add a
binding without DTS and drivers for some other user or future
implementation. It's not even possible to implement that coding style.

Best regards,
Krzysztof





[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [Linux for Sparc]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux