On 03/11/2022 22:03, Vladimir Oltean wrote: > On Thu, Nov 03, 2022 at 09:44:36PM -0400, Krzysztof Kozlowski wrote: >>> Don't these belong to spi-peripheral-props.yaml? >> >> No, they are device specific, not controller specific. Every device >> requiring them must explicitly include them. >> >> See: >> https://lore.kernel.org/all/20220816124321.67817-1-krzysztof.kozlowski@xxxxxxxxxx/ >> >> Best regards, >> Krzysztof >> > > I think you really mean to link to: > https://lore.kernel.org/all/20220718220012.GA3625497-robh@xxxxxxxxxx/ > > oh and btw, doesn't that mean that the patch is missing > Fixes: 233363aba72a ("spi/panel: dt-bindings: drop CPHA and CPOL from common properties") > ? > > but I'm not sure I understand the reasoning? I mean, from the > perspective of the common schema, isn't it valid to put "spi-cpha" on a > SPI peripheral OF node even if the hardware doesn't support it, in the > same way that it's valid to put spi-max-frequency = 1 GHz even if the It is not valid to put spi-max-frequency = 1 GHz in spi-peripheral-props.yaml. > hardware doesn't support it? Or maybe I'm missing the point of > spi-peripheral-props.yaml entirely? Since when is stacked-memories/ > parallel-memories something that should be accepted by all schemas of > all SPI peripherals (for example here, an Ethernet switch)? Since we discussed it last time. What is not clear in Rob's response? He nicely explained the purpose of spi-peripheral-props.yaml. > I think that spi-cpha/spi-cpol belongs to spi-peripheral-props.yaml just > as much as the others do. > > The distinction "device specific, not controller specific" is arbitrary > to me. These are settings that the controller has to make in order to > talk to that specific peripheral. Same as many others in that file. Not every fruit is an orange, but every orange is a fruit. You do not put "color: orange" to schema for fruits. You put it to the schema for oranges. IOW, CPHA/CPOL are not valid for most devices, so they cannot be in spi-peripheral-props.yaml. Best regards, Krzysztof
