On Tue, Nov 15, 2022 at 03:08:37PM +0100, Krzysztof Kozlowski wrote: > On 15/11/2022 14:59, Vladimir Oltean wrote: > > On Tue, Nov 15, 2022 at 02:46:21PM +0100, Krzysztof Kozlowski wrote: > >>> +$id: http://devicetree.org/schemas/spi/fsl,spi-fsl-dspi.yaml > >> > >> Why second "fsl" in file name? It does not patch compatibles and > >> duplicates the vendor. We do not have compatibles "nxp,imx6-nxp". > > > > Ok, which file name would be good then? There are 9 different (all SoC > > specific) compatible strings, surely the convention of naming the file > > after a compatible string has some limitations... > > If all DSPI blocks fit here, then maybe: fsl,dspi.yaml > > fsl,spi-dspi.yaml is also a bit redundant. Ok, fsl,dspi.yaml and fsl,dspi-peripheral-props.yaml, and MAINTAINERS entry for fsl,dspi*.yaml? > >>> +properties: > >>> + compatible: > >>> + description: > >>> + Some integrations can have a single compatible string containing their > >>> + SoC name (LS1012A, LS1021A, ...). Others require their SoC compatible > >>> + string, plus a fallback compatible string (either on LS1021A or on > >>> + LS2085A). > >> > >> Why? The fsl,ls1012a-dspi device is either compatible with > >> fsl,ls1021a-v1.0-dspi or not. It cannot be both - compatible and not > >> compatible. > > > > LS1012A is compatible with LS1021A to the extent that it works when > > treated like a LS1021A. LS1012A has a FIFO size of 8 SPI words, LS1021A > > of just 4. Treating it like LS1021A means roughly half the performance, > > but it still works. > > > > I didn't invent any of this. When I took over the driver, there were > > device trees like this all over the place: > > > > dspi: spi@2100000 { > > compatible = "fsl,ls1012a-dspi", "fsl,ls1021a-v1.0-dspi"; > > Which looks ok... > > > #address-cells = <1>; > > #size-cells = <0>; > > reg = <0x0 0x2100000 0x0 0x10000>; > > interrupts = <0 64 IRQ_TYPE_LEVEL_HIGH>; > > clock-names = "dspi"; > > clocks = <&clockgen QORIQ_CLK_PLATFORM_PLL > > QORIQ_CLK_PLL_DIV(1)>; > > spi-num-chipselects = <5>; > > big-endian; > > status = "disabled"; > > }; > > > > but the Linux driver pre-~5.7 always relied on the fallback compatible > > string (LS1021A in this case). I'm working with what's out in the field, > > haven't changed a thing there. > > The driver matters less (except ABI), but anyway it confirms the case - > fallback is expected always. Why the fallback should be removed if the > devices are compatible (including halved performance)? I don't think I said the fallback should be removed? I think you're talking about a typo/braino I made, which puts the LS1012A both in the bucket of SoCs with a single compatible strings required, as well as in that with fallback required. Obviously both can't be true... I didn't mean LS1012A but VF610.
