On 19/07/2022 00:00, Rob Herring wrote: > On Sat, Jul 16, 2022 at 07:26:04PM +0100, Jonathan Cameron wrote: >> On Fri, 15 Jul 2022 11:53:02 +0200 >> Krzysztof Kozlowski <krzysztof.kozlowski@xxxxxxxxxx> wrote: >> >>> Instead of listing directly properties typical for SPI peripherals, >>> reference the spi-peripheral-props.yaml schema. This allows using all >>> properties typical for SPI-connected devices, even these which device >>> bindings author did not tried yet. >>> >>> Remove the spi-* properties which now come via spi-peripheral-props.yaml >>> schema, except for the cases when device schema adds some constraints >>> like maximum frequency. >>> >>> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@xxxxxxxxxx> >>> >>> --- >>> >>> This is an RFC with only some files changed, as I am still not sure of >>> benefits for typical case - device node has just spi-max-frequency and >>> nothing more. I still find useful to reference the schema, but maybe I >>> am missing something? >>> >>> Before doing wide-tree cleanup like this, I would be happy to receive >>> some feedback whether this makes sense. >> >> Hi Krzysztof, >> >> This has the side effect of allowing spi-cpol / spi-cpha for devices >> where they weren't previously allowed by the binding. A typical device >> only supports a subset of combinations of those. >> >> I'm not clear whether these should always be allowed (e.g. allow for inverters >> etc in the path) or whether we should be enforcing the "correct" >> settings for devices assuming they are directly connected. >> >> Currently we have a bunch of bindings that are documenting the allowed >> flexibility - including cases where only particular combinations of these >> settings are allowed. >> >> So we could either: >> 1) Note that we've been doing it wrong and the binding should not enforce >> these constraints so remove them. > > I'd lean towards this. > >> 2) Add explicit spi-cpol: false statements etc the drivers where they >> are not allowed. > > 3) Drop spi-cpol / spi-cpha from spi-peripheral-props.yaml. It's purpose > is to collect all possible SPI controller properties that are per child > node. Whereas we've said spi-cpol / spi-cpha are device specific > properties. Thanks Rob and Jonathan. I can go with (3). Best regards, Krzysztof
