| Message ID | 20230606175246.190465-1-miquel.raynal@bootlin.com |
|---|---|
| Headers | show |
| Series | Prevent NAND chip unevaluated properties | expand |
On Tue, Jun 06, 2023 at 07:52:29PM +0200, Miquel Raynal wrote: > As discussed with Krzysztof and Chris, it seems like each NAND > controller binding should actually restrain the properties allowed in > the NAND chip node with its own "unevaluatedProperties: false". This > only works if we reference a yaml schema which contains all the possible > properties *in the NAND chip node*. Indeed, the NAND controller yaml > schema contains properties for the NAND chip which are not evaluated > with this construction. > > Link: https://lore.kernel.org/all/a23dd485-a3d9-e31f-be3e-0ab293fcfc4a@linaro.org/ > > While converting Marvell controller bindings, Chris explicitly pointed > similar bindings which would also trigger errors when using > "unevaluatedProperties: false" because of the problem mentioned above. > > Here is an attempt at making this logic more robust: > * All NAND chip properties which are specific to the raw NAND world are > moved into a raw-nand-chip.yaml file. > * raw-nand-chip.yaml is referenced by all NAND controller bindings when > the NAND chip must be further constrained. > * raw-nand-chip.yaml and spi-nand.yaml reference nand-chip.yaml. > > These change made me realize the qcom,boot-partition property > description was broken, and a few other descriptions needed small > updates. Here is a batch of updates to fix all these. > > Thanks, > Miquèl > > Miquel Raynal (17): > dt-bindings: mtd: Accept nand related node names > dt-bindings: mtd: Create a file for raw NAND chip properties > dt-bindings: mtd: Mark nand-ecc-placement deprecated > dt-bindings: mtd: Describe nand-ecc-mode > dt-bindings: mtd: qcom: Fix a property position > dt-bindings: mtd: qcom: Prevent NAND chip unevaluated properties > dt-bindings: mtd: ingenic: Prevent NAND chip unevaluated properties > dt-bindings: mtd: sunxi: Prevent NAND chip unevaluated properties > dt-bindings: mtd: meson: Prevent NAND chip unevaluated properties > dt-bindings: mtd: brcmnand: Prevent NAND chip unevaluated properties > dt-bindings: mtd: denali: Prevent NAND chip unevaluated properties > dt-bindings: mtd: intel: Prevent NAND chip unevaluated properties > dt-bindings: mtd: rockchip: Prevent NAND chip unevaluated properties > dt-bindings: mtd: stm32: Prevent NAND chip unevaluated properties > dt-bindings: mtd: mediatek: Reference raw-nand-chip.yaml > dt-bindings: mtd: mediatek: Prevent NAND chip unevaluated properties > dt-bindings: mtd: ti,am654: Prevent unevaluated properties > > .../mtd/allwinner,sun4i-a10-nand.yaml | 5 +- > .../bindings/mtd/amlogic,meson-nand.yaml | 3 + > .../bindings/mtd/brcm,brcmnand.yaml | 3 + > .../devicetree/bindings/mtd/denali,nand.yaml | 9 +- > .../devicetree/bindings/mtd/ingenic,nand.yaml | 4 + > .../bindings/mtd/intel,lgm-ebunand.yaml | 5 +- > .../bindings/mtd/mediatek,mtk-nfc.yaml | 3 +- > .../devicetree/bindings/mtd/mtd.yaml | 2 +- > .../bindings/mtd/nand-controller.yaml | 85 +------------- > .../devicetree/bindings/mtd/qcom,nandc.yaml | 45 ++++--- > .../bindings/mtd/raw-nand-chip.yaml | 111 ++++++++++++++++++ > .../mtd/rockchip,nand-controller.yaml | 3 + > .../bindings/mtd/st,stm32-fmc2-nand.yaml | 3 + > .../bindings/mtd/ti,am654-hbmc.yaml | 2 + > 14 files changed, 172 insertions(+), 111 deletions(-) > create mode 100644 Documentation/devicetree/bindings/mtd/raw-nand-chip.yaml For the series: Reviewed-by: Rob Herring <robh@kernel.org>
On 06/06/2023 19:52, Miquel Raynal wrote: > As discussed with Krzysztof and Chris, it seems like each NAND > controller binding should actually restrain the properties allowed in > the NAND chip node with its own "unevaluatedProperties: false". This > only works if we reference a yaml schema which contains all the possible > properties *in the NAND chip node*. Indeed, the NAND controller yaml > schema contains properties for the NAND chip which are not evaluated > with this construction. > > Link: https://lore.kernel.org/all/a23dd485-a3d9-e31f-be3e-0ab293fcfc4a@linaro.org/ Please rebase on latest kernel. This is some very old tree if you CC this address. Best regards, Krzysztof
Hi Krzysztof, krzk@kernel.org wrote on Sat, 10 Jun 2023 11:27:55 +0200: > On 06/06/2023 19:52, Miquel Raynal wrote: > > As discussed with Krzysztof and Chris, it seems like each NAND > > controller binding should actually restrain the properties allowed in > > the NAND chip node with its own "unevaluatedProperties: false". This > > only works if we reference a yaml schema which contains all the possible > > properties *in the NAND chip node*. Indeed, the NAND controller yaml > > schema contains properties for the NAND chip which are not evaluated > > with this construction. > > > > Link: https://lore.kernel.org/all/a23dd485-a3d9-e31f-be3e-0ab293fcfc4a@linaro.org/ > > Please rebase on latest kernel. This is some very old tree if you CC > this address. Sorry for the trouble, it was a hardcoded address on my side. I've updated the address to Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org> The series is based on v6.4-rc1. Against what branch/tag do you want it to be rebased? Thanks, Miquèl
Hi Krzysztof, miquel.raynal@bootlin.com wrote on Tue, 13 Jun 2023 13:43:50 +0200: > Hi Krzysztof, > > krzk@kernel.org wrote on Sat, 10 Jun 2023 11:27:55 +0200: > > > On 06/06/2023 19:52, Miquel Raynal wrote: > > > As discussed with Krzysztof and Chris, it seems like each NAND > > > controller binding should actually restrain the properties allowed in > > > the NAND chip node with its own "unevaluatedProperties: false". This > > > only works if we reference a yaml schema which contains all the possible > > > properties *in the NAND chip node*. Indeed, the NAND controller yaml > > > schema contains properties for the NAND chip which are not evaluated > > > with this construction. > > > > > > Link: https://lore.kernel.org/all/a23dd485-a3d9-e31f-be3e-0ab293fcfc4a@linaro.org/ > > > > Please rebase on latest kernel. This is some very old tree if you CC > > this address. > > Sorry for the trouble, it was a hardcoded address on my side. I've > updated the address to > > Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org> > > The series is based on v6.4-rc1. Against what branch/tag do you want it > to be rebased? When I asked this question I forgot I usually apply mtd bindings in my own tree :) I usually do it after receiving at least one R-by on the whole series, but here as I'm the author I would just like to get confirmation from you Krzysztof that I can go ahead (or if you prefer to take it, or maybe want to give this another look later). Thanks, Miquèl
On Tue, 6 Jun 2023 19:52:29 +0200, Miquel Raynal wrote: > As discussed with Krzysztof and Chris, it seems like each NAND > controller binding should actually restrain the properties allowed in > the NAND chip node with its own "unevaluatedProperties: false". This > only works if we reference a yaml schema which contains all the possible > properties *in the NAND chip node*. Indeed, the NAND controller yaml > > [ ... ] Acked-by: Maxime Ripard <mripard@kernel.org> Reviewed-by: Maxime Ripard <mripard@kernel.org> Tested-by: Maxime Ripard <mripard@kernel.org> Thanks! Maxime
On Tue, 6 Jun 2023 19:52:29 +0200, Miquel Raynal wrote: > As discussed with Krzysztof and Chris, it seems like each NAND > controller binding should actually restrain the properties allowed in > the NAND chip node with its own "unevaluatedProperties: false". This > only works if we reference a yaml schema which contains all the possible > properties *in the NAND chip node*. Indeed, the NAND controller yaml > > [ ... ] Thanks! Maxime
On Tue, 6 Jun 2023 19:52:29 +0200, Miquel Raynal wrote: > As discussed with Krzysztof and Chris, it seems like each NAND > controller binding should actually restrain the properties allowed in > the NAND chip node with its own "unevaluatedProperties: false". This > only works if we reference a yaml schema which contains all the possible > properties *in the NAND chip node*. Indeed, the NAND controller yaml > > [ ... ] Acked-by: Maxime Ripard <mripard@kernel.org> Reviewed-by: Maxime Ripard <mripard@kernel.org> Thanks! Maxime
On Tue, 6 Jun 2023 19:52:29 +0200, Miquel Raynal wrote: > As discussed with Krzysztof and Chris, it seems like each NAND > controller binding should actually restrain the properties allowed in > the NAND chip node with its own "unevaluatedProperties: false". This > only works if we reference a yaml schema which contains all the possible > properties *in the NAND chip node*. Indeed, the NAND controller yaml > > [ ... ] Acked-by: Maxime Ripard <mripard@kernel.org> Reviewed-by: Maxime Ripard <mripard@kernel.org> Thanks! Maxime
On Wed, Sep 27, 2023 at 07:20:12AM +0000, Maxime Ripard wrote: > On Tue, 6 Jun 2023 19:52:29 +0200, Miquel Raynal wrote: > > As discussed with Krzysztof and Chris, it seems like each NAND > > controller binding should actually restrain the properties allowed in > > the NAND chip node with its own "unevaluatedProperties: false". This > > only works if we reference a yaml schema which contains all the possible > > properties *in the NAND chip node*. Indeed, the NAND controller yaml > > > > [ ... ] > > Acked-by: Maxime Ripard <mripard@kernel.org> > Reviewed-by: Maxime Ripard <mripard@kernel.org> > Tested-by: Maxime Ripard <mripard@kernel.org> Erm, sorry for the noise, I ended up sending those by mistake... Maxime