On Thu, Oct 06, 2022 at 06:29:43AM +0200, Sergio Paracuellos wrote: > Hi all, > > This series tries to make the correct thing to represent in schema > all the current documentation related with MIPS CPUs. > > Broadcom cpus node is a bit special and need to use the property > 'mips-hpt-frequency' in the cpus node. Because of this I have introduced > brcm/soc.yaml schema with current broadcom SoCs and making this property > required as per Rob's v3 review comments. > > Ingenic cpus have also its schema already mainlined. To unify things I > have also put this information in this mips/cpus.yaml schema and remove > the 'mips/ingenic/ingenic,cpu.yaml' schema. I have also added current > maintainer as maintainer for this 'mips/cpus.yaml' file. > > Thomas, are these patches going through the mips git tree? > > Thanks, > Sergio Paracuellos > > Changes in v8: > - Remove Hauke Mehrtens from brcm/soc.yaml maintainers as per Hauke Mehrtens's > requested in v7 response. > > Changes in v7: > - Remove Rafał Miłecki from brcm/soc.yaml maintainers as per Rafał Miłecki's > requested in v6 response. > > Changes in v6: > - Avoid 'convert' in SoC's patch commit message since this is just an > addition and nothing is removed in this patch. > - Add Florian Fainelli to maintainers of Broadcom SoC bindings > - Add Florian's Acked-by for broadcom SoC PATCH. > - Collect Rob's Reviewed-by for both patches. > > Changes in v5: > - Address Krzysztof comments in v4: > - change BMIPS SoC compatibles into an enum and drop descriptions, > - Add blank line. > - Redo commit message since it is not a conversion to schema. > - Drop 'device tree bindings' from description. > - Properly describe 'mips-hpt-frequency'. > - Review cpus node and add a sample to check schema correctness. > > Changes in v4: > - Address Rob's v3 review comments: > * Drop PATCH introducing special brcm,cpus.yaml only because properyu > 'mips-hpt-frequency' is required and move this property to brcm/soc.yaml > schema. > * Remove 'Documentation/devicetree/bindings/mips/ingenic/ingenic,cpu.yaml' > and add that information to general mips/cpus.yaml schema. > * Define all properties in mips/cpus.yaml and set 'additionalProperties' > to false. > > Changes in v3: > - cpus.yaml: > * address Krzysztof comment in v2: > * add Thomas as maintainer since this is architecture binding. > * s/cpu/CPU > * compatible goes first > * Add compatible 'mips,mips4Kc' as per Thomas request. > - Introduce two new schemas for Broadcom BMIPS: > * soc.yaml: describing the BRCM SoC's > * brcm,bmips-cpus.yaml: describing the cpu nodes for this platform. > > Previous series: > v1: https://lore.kernel.org/all/CAMhs-H-eUTOHjAXAbywOXQJgc_j5Ex-1sB7eBZU_bWt1fpNVzA@xxxxxxxxxxxxxx/T/ > v2: https://lore.kernel.org/all/20220918112245.GA5555@xxxxxxxxxxxxxxxx/T/ > v3: https://lore.kernel.org/linux-devicetree/20220929072004.874795-1-sergio.paracuellos@xxxxxxxxx/T/#t > v4: https://lore.kernel.org/linux-devicetree/20221001043855.933528-1-sergio.paracuellos@xxxxxxxxx/T/#t > v5: https://lore.kernel.org/linux-devicetree/20221002091611.946210-1-sergio.paracuellos@xxxxxxxxx/T/#t > v6: https://lore.kernel.org/linux-devicetree/20221004050924.986211-1-sergio.paracuellos@xxxxxxxxx/T/#t > > Sergio Paracuellos (2): > dt-bindings: mips: add CPU bindings for MIPS architecture > dt-bindings: mips: brcm: add Broadcom SoCs bindings > > .../bindings/mips/brcm/brcm,bmips.txt | 8 -- > .../devicetree/bindings/mips/brcm/soc.yaml | 97 +++++++++++++++ > .../devicetree/bindings/mips/cpus.yaml | 115 ++++++++++++++++++ > .../bindings/mips/ingenic/ingenic,cpu.yaml | 69 ----------- > 4 files changed, 212 insertions(+), 77 deletions(-) > delete mode 100644 Documentation/devicetree/bindings/mips/brcm/brcm,bmips.txt > create mode 100644 Documentation/devicetree/bindings/mips/brcm/soc.yaml > create mode 100644 Documentation/devicetree/bindings/mips/cpus.yaml > delete mode 100644 Documentation/devicetree/bindings/mips/ingenic/ingenic,cpu.yaml > > -- > 2.25.1 series applied to mips-next. Thomas. -- Crap can work. Given enough thrust pigs will fly, but it's not necessarily a good idea. [ RFC1925, 2.3 ]
