On 12/10/2022 15:56, Hawkins, Nick wrote:
>>> +examples:
>>> + - |
>>> + cpld@1e789000 {
>>> + compatible = "hpe,gxp-plreg", "simple-mfd", "syscon";
>>> + reg = <0x1e789000 0x1000>;
>>> + fan1 {
>>> + bit = <0x01>;
>>> + inst = <0x27>;
>>> + id = <0x2B>;
>
>> These property names are way too generic for device specific properties. There is zero description of what the h/w does and any of these child nodes to give any advice on direction. However, a node per register or register field is generally the wrong direction.
>
> Thank you for your valued feedback. The goal I was trying to achieve here was making our programmable logic register driver interface in a generic way across multiple platforms based on inputs we provide with the .dts file for each platform. For instance if we want to read the fan 1 install status on platform X it would be reading bit 0x01 of byte 0x27 where as on platform Y it could be bit 0x02 of byte 0x16. Is there a format you would recommend that I can adhere too?
I don't think DT place is to describe register or memory layout, with
some exceptions like MTD partitions or nvmem cells. Basically you are
representing here a device register map inside DT, just because it is a
CPLD.
Every regular multi-functional device handles its register map in the
driver itself and uses Linux framework to expose the internals. CPLD
should not be different, except that is programmable.
Best regards,
Krzysztof
