Re: [PATCH v3 0/6] Prerequisites for NXP LS104xA SMMU enablement
Am 31.05.19 um 19:32 schrieb Laurentiu Tudor: >> -Original Message- >> From: Andreas Färber >> Sent: Friday, May 31, 2019 8:04 PM >> >> Hello Laurentiu, >> >> Am 31.05.19 um 18:46 schrieb Laurentiu Tudor: >>>> -Original Message- >>>> From: Andreas Färber >>>> Sent: Friday, May 31, 2019 7:15 PM >>>> >>>> Hi Laurentiu, >>>> >>>> Am 30.05.19 um 16:19 schrieb laurentiu.tu...@nxp.com: >>>>> This patch series contains several fixes in preparation for SMMU >>>>> support on NXP LS1043A and LS1046A chips. Once these get picked up, >>>>> I'll submit the actual SMMU enablement patches consisting in the >>>>> required device tree changes. >>>> >>>> Have you thought through what will happen if this patch ordering is not >>>> preserved? In particular, a user installing a future U-Boot update with >>>> the DTB bits but booting a stable kernel without this patch series - >>>> wouldn't that regress dpaa then for our customers? >>>> >>> >>> These are fixes for issues that popped out after enabling SMMU. >>> I do not expect them to break anything. >> >> That was not my question! You're missing my point: All your patches are >> lacking a Fixes header in their commit message, for backporting them, to >> avoid _your DT patches_ breaking the driver on stable branches! > > It does appear that I'm missing your point. For sure, the DT updates solely > will > break the kernel without these fixes but I'm not sure I understand how this > could happen. In short, customers rarely run master branch. Kindly have your colleagues explain stable branches to you in details. With Fixes header I was referring to the syntax explained here: https://www.kernel.org/doc/html/latest/process/submitting-patches.html#describe-your-changes https://www.kernel.org/doc/html/latest/process/submitting-patches.html#using-reported-by-tested-by-reviewed-by-suggested-by-and-fixes > My plan was to share the kernel dts patches sometime after this series > makes it through. That's fine. What I'm warning you is that seemingly your DT patches, once in one of your LSDK U-Boot releases, will cause a regression for distros like our SLES 15 SP1 unless these prereq kernel patches get applied on the respective stable branches. Which will not happen automatically unless you as patch author take the appropriate action before they get merged. Thanks, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 21284 (AG Nürnberg)
Re: [PATCH v3 0/6] Prerequisites for NXP LS104xA SMMU enablement
Hello Laurentiu, Am 31.05.19 um 18:46 schrieb Laurentiu Tudor: >> -Original Message- >> From: Andreas Färber >> Sent: Friday, May 31, 2019 7:15 PM >> >> Hi Laurentiu, >> >> Am 30.05.19 um 16:19 schrieb laurentiu.tu...@nxp.com: >>> This patch series contains several fixes in preparation for SMMU >>> support on NXP LS1043A and LS1046A chips. Once these get picked up, >>> I'll submit the actual SMMU enablement patches consisting in the >>> required device tree changes. >> >> Have you thought through what will happen if this patch ordering is not >> preserved? In particular, a user installing a future U-Boot update with >> the DTB bits but booting a stable kernel without this patch series - >> wouldn't that regress dpaa then for our customers? >> > > These are fixes for issues that popped out after enabling SMMU. > I do not expect them to break anything. That was not my question! You're missing my point: All your patches are lacking a Fixes header in their commit message, for backporting them, to avoid _your DT patches_ breaking the driver on stable branches! Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 21284 (AG Nürnberg)
Re: [PATCH v3 0/6] Prerequisites for NXP LS104xA SMMU enablement
Hi Laurentiu, Am 30.05.19 um 16:19 schrieb laurentiu.tu...@nxp.com: > This patch series contains several fixes in preparation for SMMU > support on NXP LS1043A and LS1046A chips. Once these get picked up, > I'll submit the actual SMMU enablement patches consisting in the > required device tree changes. Have you thought through what will happen if this patch ordering is not preserved? In particular, a user installing a future U-Boot update with the DTB bits but booting a stable kernel without this patch series - wouldn't that regress dpaa then for our customers? Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 21284 (AG Nürnberg)
Re: [PATCH 27/36] dt-bindings: arm: Convert Realtek board/soc bindings to json-schema
Am 05.10.18 um 18:58 schrieb Rob Herring: > Convert Realtek SoC bindings to DT schema format using json-schema. YAML (2x) > > Cc: "Andreas Färber" > Cc: Mark Rutland > Cc: linux-arm-ker...@lists.infradead.org > Cc: devicet...@vger.kernel.org > Signed-off-by: Rob Herring > --- > .../devicetree/bindings/arm/realtek.txt | 22 > .../devicetree/bindings/arm/realtek.yaml | 25 +++ > 2 files changed, 25 insertions(+), 22 deletions(-) > delete mode 100644 Documentation/devicetree/bindings/arm/realtek.txt > create mode 100644 Documentation/devicetree/bindings/arm/realtek.yaml > > diff --git a/Documentation/devicetree/bindings/arm/realtek.txt > b/Documentation/devicetree/bindings/arm/realtek.txt > deleted file mode 100644 > index 95839e19ae92.. > --- a/Documentation/devicetree/bindings/arm/realtek.txt > +++ /dev/null > @@ -1,22 +0,0 @@ > -Realtek platforms device tree bindings > --- > - > - > -RTD1295 SoC > -=== > - > -Required root node properties: > - > - - compatible : must contain "realtek,rtd1295" > - > - > -Root node property compatible must contain, depending on board: > - > - - MeLE V9: "mele,v9" > - - ProBox2 AVA: "probox2,ava" > - - Zidoo X9S: "zidoo,x9s" > - > - > -Example: > - > -compatible = "zidoo,x9s", "realtek,rtd1295"; > diff --git a/Documentation/devicetree/bindings/arm/realtek.yaml > b/Documentation/devicetree/bindings/arm/realtek.yaml > new file mode 100644 > index ..9e3bb3249c77 > --- /dev/null > +++ b/Documentation/devicetree/bindings/arm/realtek.yaml > @@ -0,0 +1,25 @@ > +# SPDX-License-Identifier: None What is the expected license for such bindings? You did not add such a line for actions.yaml. > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/bindings/arm/realtek.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Realtek platforms device tree bindings > + > +maintainers: > + - Andreas Färber > + > +description: |+ "|+"? > + RTD1295 SoC > + > +properties: > + $nodename: > +const: '/' > + compatible: > +items: > + - enum: > + - mele,v9 > + - probox2,ava > + - zidoo,x9s > + - const: realtek,rtd1295 > +... That does not look like a full "PATCH" yet? It also confuses me whether or when leading dashes are necessary - for Actions Semi "items" had one. I have preparations on my GitHub staging tree for three more SoCs, so we should prepare the structure to ease adding SoCs and avoid re-indenting patches - adding SoCs was much easier in the original flat text format. Please also consider for other vendors. Same comment as for Actions: We're losing a human description of the enum values. Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg)
Re: [PATCH 15/36] dt-bindings: arm: Convert Actions Semi bindings to jsonschema
Hi Rob, Am 05.10.18 um 18:58 schrieb Rob Herring: > Convert Actions Semi SoC bindings to DT schema format using json-schema. This sounds like the next Yanny vs. Laurel... I fail to see any json. ;) Also, it may help my understanding to be CC'ed on the cover letter, too? > > Cc: "Andreas Färber" > Cc: Mark Rutland > Cc: linux-arm-ker...@lists.infradead.org > Cc: devicet...@vger.kernel.org > Signed-off-by: Rob Herring > --- > .../devicetree/bindings/arm/actions.txt | 56 --- > .../devicetree/bindings/arm/actions.yaml | 34 +++ > 2 files changed, 34 insertions(+), 56 deletions(-) > delete mode 100644 Documentation/devicetree/bindings/arm/actions.txt > create mode 100644 Documentation/devicetree/bindings/arm/actions.yaml > > diff --git a/Documentation/devicetree/bindings/arm/actions.txt > b/Documentation/devicetree/bindings/arm/actions.txt > deleted file mode 100644 > index d54f33c4e0da.. > --- a/Documentation/devicetree/bindings/arm/actions.txt > +++ /dev/null > @@ -1,56 +0,0 @@ > -Actions Semi platforms device tree bindings > > - > - > -S500 SoC > - > - > -Required root node properties: > - > - - compatible : must contain "actions,s500" > - > - > -Modules: > - > -Root node property compatible must contain, depending on module: > - > - - LeMaker Guitar: "lemaker,guitar" > - > - > -Boards: > - > -Root node property compatible must contain, depending on board: > - > - - Allo.com Sparky: "allo,sparky" > - - Cubietech CubieBoard6: "cubietech,cubieboard6" > - - LeMaker Guitar Base Board rev. B: "lemaker,guitar-bb-rev-b", > "lemaker,guitar" > - > - > -S700 SoC > - > - > -Required root node properties: > - > -- compatible : must contain "actions,s700" > - > - > -Boards: > - > -Root node property compatible must contain, depending on board: > - > - - Cubietech CubieBoard7: "cubietech,cubieboard7" > - > - > -S900 SoC > - > - > -Required root node properties: > - > -- compatible : must contain "actions,s900" > - > - > -Boards: > - > -Root node property compatible must contain, depending on board: > - > - - uCRobotics Bubblegum-96: "ucrobotics,bubblegum-96" > diff --git a/Documentation/devicetree/bindings/arm/actions.yaml > b/Documentation/devicetree/bindings/arm/actions.yaml > new file mode 100644 > index ..af9345a228b4 > --- /dev/null > +++ b/Documentation/devicetree/bindings/arm/actions.yaml > @@ -0,0 +1,34 @@ > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/soc/arm/actions.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# 404 for the schema. Where does one find an explanation? > + > +title: Actions Semi platforms device tree bindings > + > +maintainers: > + - Andreas Färber Mani is now officially reviewer and the closest I have to a co-maintainer. I suggest we add him here in some form. I assume this is independent of MAINTAINERS patterns though, or will get_maintainers.pl parse this, too? > + > +description: | Does the | have any meaning, or a stray typo? > + The Actions Semi S500 is a quad-core ARM Cortex-A9 SoC. The Actions Semi > + S900 is a quad-core ARM Cortex-A53 SoC. You forgot the S700 as another quad-core Cortex-A53 SoC. Also, arm or Arm rather than ARM these days? > + > +properties: > + compatible: > +oneOf: > + - items: > + - enum: > + - lemaker,guitar-bb-rev-b > + - enum: > + - lemaker,guitar > + - allo,sparky > + - cubietech,cubieboard6 > + - const: actions,s500 > +minItems: 2 > +maxItems: 3 > +additionalItems: false Objection. You've managed to turn a perfectly human-comprehensible text into a machine-parseable representation incomprehensible for humans. First, there should remain some free-text explanation of the values defined here. Are comments allowed after the value or indented maybe? Alternatively we could have a per-vendor file à la vendor-prefixes.txt, but that would seem inefficient. Next, the above items construct is horrible. What about nested oneOf: + - items: + - oneOf: + - items: + - enum: + - lemaker,guitar-bb-rev-b + - const: lemaker,guitar + - items: + - enum: + - allo,sparky + - cubietech,cubieboard6 + - const: actions,s500 This grouping is much clearer to me and hopefully to anyon
Re: [PATCH v3 6/9] kbuild: consolidate Devicetree dtb build rules
Hi Geert, Am 13.09.18 um 17:51 schrieb Geert Uytterhoeven: > On Wed, Sep 12, 2018 at 3:02 AM Masahiro Yamada > wrote: >> Even x86 can enable OF and OF_UNITTEST. >> >> Another solution might be, >> guard it by 'depends on ARCH_SUPPORTS_OF'. >> >> This is actually what ACPI does. >> >> menuconfig ACPI >> bool "ACPI (Advanced Configuration and Power Interface) Support" >> depends on ARCH_SUPPORTS_ACPI >> ... > > ACPI is a real platform feature, as it depends on firmware. > > CONFIG_OF can be enabled, and DT overlays can be loaded, on any platform, > even if it has ACPI ;-) How would loading a DT overlay work on an ACPI platform? I.e., what would it overlay against and how to practically load such a file? I wonder whether that could be helpful for USB devices and serdev... Cheers, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg)
Re: [PATCH 2/2] offb: Add palette hack for qemu standard vga framebuffer
Am 15.12.2011 00:58, schrieb Benjamin Herrenschmidt: We rename the mach64 hack to simple since that's also applicable to anything using VGA-style DAC IO ports (set to 8-bit DAC) and we use it for qemu vga. Note that this is keyed on a device-tree compatible property that is currently only set by an upcoming version of SLOF when using the qemu pseries platform. This is on purpose as other qemu ppc platforms using OpenBIOS aren't properly setting the DAC to 8-bit at the time of the writing of this patch. We can fix OpenBIOS later to do that and add the required property, in which case it will be matched by this change. Just let me know what's needed for OpenBIOS. Is this just for -vga std as opposed to the default cirrus? Cheers, Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
