| Message ID | 20241220-gs101-simplefb-v2-0-c10a8f9e490b@linaro.org |
|---|---|
| Headers | show |
| Series | Google Pixel 6 Pro support | expand |
On Fri, 2024-12-20 at 11:27 +0000, André Draszik wrote: > Hi, > > This series enables support for Google Pixel 6 Pro. > > Since Pixel 6 and Pixel 6 Pro use a different resolution display, we > now need to add explicit support for it, we can not piggyback on the > non-Pro version anymore. This means having to separate them into their > respective DTs, and provide one for each of them. > There are other differences between the two of course, like battery > design capacity, etc., but they don't matter at this stage due to > incomplete upstream support. > > * dependency note * > > Due to the renaming of the gs101-oriole.dts, this series will conflict > with any pending patches touching the same file. I have therefore based > this series on top of my USB series from > https://lore.kernel.org/r/20241203-gs101-phy-lanes-orientation-dts-v2-0-1412783a6b01@linaro.org > and the patch enabling framebuffer support for Pixel 6 from > https://lore.kernel.org/r/20241220-gs101-simplefb-oriole-v2-1-df60e566932a@linaro.org Actually, since this series was regenerated with git's diff.renames=copies, it doesn't depend on my USB series anymore, just on the framebuffer enablement for Pixel 6. Cheers, Andre'
On 20/12/2024 12:27, André Draszik wrote: > Raven is Google's code name for Pixel 6 Pro. Since there are > differences compared to Pixel 6 (Oriole), we need to add a separate > compatible for it. > > We also want to support a generic DT, which can work on any type of There are no such generic DT devices upstream, so we cannot add bindings for them. > gs101-based Pixel device, e.g. Pixel 6, or Pixel 6 Pro, or Pixel 6a (as > a future addition). Such a DT will have certain nodes disabled / not > added. To facilitate such a generic gs101-based Pixel device, also add > a more generic gs101-pixel compatible. We can not just use the existing > google,gs101 for that, as it refers to the SoC, not a board. > > Signed-off-by: André Draszik <andre.draszik@linaro.org> > --- > Documentation/devicetree/bindings/arm/google.yaml | 18 ++++++++++++++---- > 1 file changed, 14 insertions(+), 4 deletions(-) > > diff --git a/Documentation/devicetree/bindings/arm/google.yaml b/Documentation/devicetree/bindings/arm/google.yaml > index e20b5c9b16bc..a8faf2256242 100644 > --- a/Documentation/devicetree/bindings/arm/google.yaml > +++ b/Documentation/devicetree/bindings/arm/google.yaml > @@ -34,11 +34,21 @@ properties: > const: '/' > compatible: > oneOf: > - - description: Google Pixel 6 / Oriole > + - description: Google GS101 Pixel devices, as generic Pixel, or Pixel 6 > + (Oriole), or 6 Pro (Raven) > + minItems: 2 > + maxItems: 3 > items: > - - enum: > - - google,gs101-oriole > - - const: google,gs101 > + enum: > + - google,gs101-oriole > + - google,gs101-raven > + - google,gs101-pixel > + - google,gs101 SoC cannot be a board in the same time. > + allOf: > + - contains: > + const: google,gs101-pixel > + - contains: > + const: google,gs101 This should be fixed list. Best regards, Krzysztof
On 20/12/2024 12:27, André Draszik wrote: > Raven is Google's code name for Pixel 6 Pro. Similar to Pixel 6 > (Oriole), this is also based around its Tensor gs101 SoC. > > For now, the relevant difference here is the display resolution: > 1440 x 3120 instead of 1080 x 2400. > > Create a new board file to reflect this difference. There is no board file here, I see only overlay. > > Signed-off-by: André Draszik <andre.draszik@linaro.org> > > --- > Note: MAINTAINERS doesn't need updating, it covers this whole directory > --- > arch/arm64/boot/dts/exynos/google/Makefile | 3 ++ > arch/arm64/boot/dts/exynos/google/gs101-raven.dtso | 33 ++++++++++++++++++++++ Nope, boards are not overlays. Boards are DTB. Best regards, Krzysztof
Hi Krzysztof, On Sun, 2024-12-22 at 12:38 +0100, Krzysztof Kozlowski wrote: > On 20/12/2024 12:27, André Draszik wrote: > > Raven is Google's code name for Pixel 6 Pro. Since there are > > differences compared to Pixel 6 (Oriole), we need to add a separate > > compatible for it. > > > > We also want to support a generic DT, which can work on any type of > > There are no such generic DT devices upstream, so we cannot add bindings > for them. Do you have a better suggestion for the wording? How about 'gs101-based Pixel base board'? > > gs101-based Pixel device, e.g. Pixel 6, or Pixel 6 Pro, or Pixel 6a (as > > a future addition). Such a DT will have certain nodes disabled / not > > added. To facilitate such a generic gs101-based Pixel device, also add > > a more generic gs101-pixel compatible. We can not just use the existing > > google,gs101 for that, as it refers to the SoC, not a board. > > > > Signed-off-by: André Draszik <andre.draszik@linaro.org> > > --- > > Documentation/devicetree/bindings/arm/google.yaml | 18 ++++++++++++++---- > > 1 file changed, 14 insertions(+), 4 deletions(-) > > > > diff --git a/Documentation/devicetree/bindings/arm/google.yaml b/Documentation/devicetree/bindings/arm/google.yaml > > index e20b5c9b16bc..a8faf2256242 100644 > > --- a/Documentation/devicetree/bindings/arm/google.yaml > > +++ b/Documentation/devicetree/bindings/arm/google.yaml > > @@ -34,11 +34,21 @@ properties: > > const: '/' > > compatible: > > oneOf: > > - - description: Google Pixel 6 / Oriole > > + - description: Google GS101 Pixel devices, as generic Pixel, or Pixel 6 > > + (Oriole), or 6 Pro (Raven) > > + minItems: 2 > > + maxItems: 3 > > items: > > - - enum: > > - - google,gs101-oriole > > - - const: google,gs101 > > + enum: > > + - google,gs101-oriole > > + - google,gs101-raven > > + - google,gs101-pixel > > + - google,gs101 > > SoC cannot be a board in the same time. Can you please expand? google,gs101 is the SoC, the other ones are boards. Is the commit message unclear? > > > + allOf: > > + - contains: > > + const: google,gs101-pixel > > + - contains: > > + const: google,gs101 > > This should be fixed list. OK. (This was inspired by Documentation/devicetree/bindings/soc/xilinx/xilinx.yaml) Cheers, Andre'
On Sun, 2024-12-22 at 12:43 +0100, Krzysztof Kozlowski wrote: > On 20/12/2024 12:27, André Draszik wrote: > > Raven is Google's code name for Pixel 6 Pro. Similar to Pixel 6 > > (Oriole), this is also based around its Tensor gs101 SoC. > > > > For now, the relevant difference here is the display resolution: > > 1440 x 3120 instead of 1080 x 2400. > > > > Create a new board file to reflect this difference. > > There is no board file here, I see only overlay. > > > > > Signed-off-by: André Draszik <andre.draszik@linaro.org> > > > > --- > > Note: MAINTAINERS doesn't need updating, it covers this whole directory > > --- > > arch/arm64/boot/dts/exynos/google/Makefile | 3 ++ > > arch/arm64/boot/dts/exynos/google/gs101-raven.dtso | 33 ++++++++++++++++++++++ > > Nope, boards are not overlays. Boards are DTB. Several other boards are using this approach, e.g. in arch/arm64/boot/dts/freescale/ and arch/arm64/boot/dts/xilinx/ and arch/arm/boot/dts/ti/omap/ Can you please explain why this here can not use this approach? Cheers, Andre'
On 23/12/2024 08:45, André Draszik wrote: > Hi Krzysztof, > > On Sun, 2024-12-22 at 12:38 +0100, Krzysztof Kozlowski wrote: >> On 20/12/2024 12:27, André Draszik wrote: >>> Raven is Google's code name for Pixel 6 Pro. Since there are >>> differences compared to Pixel 6 (Oriole), we need to add a separate >>> compatible for it. >>> >>> We also want to support a generic DT, which can work on any type of >> >> There are no such generic DT devices upstream, so we cannot add bindings >> for them. > > Do you have a better suggestion for the wording? > How about 'gs101-based Pixel base board'? It's not exactly about the wording but the concept. We don't have generic devices, thus no generic DT (DTS). Period. Thus you cannot have such schema. > >>> gs101-based Pixel device, e.g. Pixel 6, or Pixel 6 Pro, or Pixel 6a (as >>> a future addition). Such a DT will have certain nodes disabled / not >>> added. To facilitate such a generic gs101-based Pixel device, also add >>> a more generic gs101-pixel compatible. We can not just use the existing >>> google,gs101 for that, as it refers to the SoC, not a board. >>> >>> Signed-off-by: André Draszik <andre.draszik@linaro.org> >>> --- >>> Documentation/devicetree/bindings/arm/google.yaml | 18 ++++++++++++++---- >>> 1 file changed, 14 insertions(+), 4 deletions(-) >>> >>> diff --git a/Documentation/devicetree/bindings/arm/google.yaml b/Documentation/devicetree/bindings/arm/google.yaml >>> index e20b5c9b16bc..a8faf2256242 100644 >>> --- a/Documentation/devicetree/bindings/arm/google.yaml >>> +++ b/Documentation/devicetree/bindings/arm/google.yaml >>> @@ -34,11 +34,21 @@ properties: >>> const: '/' >>> compatible: >>> oneOf: >>> - - description: Google Pixel 6 / Oriole >>> + - description: Google GS101 Pixel devices, as generic Pixel, or Pixel 6 >>> + (Oriole), or 6 Pro (Raven) >>> + minItems: 2 >>> + maxItems: 3 >>> items: >>> - - enum: >>> - - google,gs101-oriole >>> - - const: google,gs101 >>> + enum: >>> + - google,gs101-oriole >>> + - google,gs101-raven >>> + - google,gs101-pixel >>> + - google,gs101 >> >> SoC cannot be a board in the same time. > > Can you please expand? google,gs101 is the SoC, the other ones are boards. > Is the commit message unclear? You now say that these are valid boards: compatible = "google,gs101", "google,gs101"; (although compatibles compatible = "google,gs101", "google,gs101-pixel"; Both are wrong. SoC should not be before the board and SoC cannot be used alone. Your schema allows that and that's not good. I did not get what you want to achieve here, so tricky to advice. Best regards, Krzysztof
On Mon, 2024-12-23 at 15:14 +0100, Krzysztof Kozlowski wrote: > On 23/12/2024 08:45, André Draszik wrote: > > Hi Krzysztof, > > > > On Sun, 2024-12-22 at 12:38 +0100, Krzysztof Kozlowski wrote: > > > On 20/12/2024 12:27, André Draszik wrote: > > > > Raven is Google's code name for Pixel 6 Pro. Since there are > > > > differences compared to Pixel 6 (Oriole), we need to add a separate > > > > compatible for it. > > > > > > > > We also want to support a generic DT, which can work on any type of > > > > > > There are no such generic DT devices upstream, so we cannot add bindings > > > for them. > > > > Do you have a better suggestion for the wording? > > How about 'gs101-based Pixel base board'? > > It's not exactly about the wording but the concept. We don't have > generic devices, thus no generic DT (DTS). Period. Thus you cannot have > such schema. There is a Pixel base board, with different additions to it, e.g. different displays. The boot loader can pick the right one. Let's discuss that in the other thread to have things in one place :-) > > > > > gs101-based Pixel device, e.g. Pixel 6, or Pixel 6 Pro, or Pixel 6a (as > > > > a future addition). Such a DT will have certain nodes disabled / not > > > > added. To facilitate such a generic gs101-based Pixel device, also add > > > > a more generic gs101-pixel compatible. We can not just use the existing > > > > google,gs101 for that, as it refers to the SoC, not a board. > > > > > > > > Signed-off-by: André Draszik <andre.draszik@linaro.org> > > > > --- > > > > Documentation/devicetree/bindings/arm/google.yaml | 18 ++++++++++++++---- > > > > 1 file changed, 14 insertions(+), 4 deletions(-) > > > > > > > > diff --git a/Documentation/devicetree/bindings/arm/google.yaml b/Documentation/devicetree/bindings/arm/google.yaml > > > > index e20b5c9b16bc..a8faf2256242 100644 > > > > --- a/Documentation/devicetree/bindings/arm/google.yaml > > > > +++ b/Documentation/devicetree/bindings/arm/google.yaml > > > > @@ -34,11 +34,21 @@ properties: > > > > const: '/' > > > > compatible: > > > > oneOf: > > > > - - description: Google Pixel 6 / Oriole > > > > + - description: Google GS101 Pixel devices, as generic Pixel, or Pixel 6 > > > > + (Oriole), or 6 Pro (Raven) > > > > + minItems: 2 > > > > + maxItems: 3 > > > > items: > > > > - - enum: > > > > - - google,gs101-oriole > > > > - - const: google,gs101 > > > > + enum: > > > > + - google,gs101-oriole > > > > + - google,gs101-raven > > > > + - google,gs101-pixel > > > > + - google,gs101 > > > > > > SoC cannot be a board in the same time. > > > > Can you please expand? google,gs101 is the SoC, the other ones are boards. > > Is the commit message unclear? > > You now say that these are valid boards: > > compatible = "google,gs101", "google,gs101"; Sorry, I don't see how (apart from the fact that dtbs_check flags non-unique elements anyway). The result of the patch is: minItems: 2 maxItems: 3 items: enum: - google,gs101-oriole - google,gs101-raven - google,gs101-pixel - google,gs101 allOf: - contains: const: google,gs101-pixel - contains: const: google,gs101 So one can not have 'google,gs101' twice. And if I only add compatible = "google,gs101", "google,gs101"; to the .dts, then dtbs_check complains indeed. > (although compatibles > > compatible = "google,gs101", "google,gs101-pixel"; OK, the schema doesn't flag incorrect ordering indeed. > Both are wrong. SoC should not be before the board and SoC cannot be > used alone. Your schema allows that and that's not good. > > I did not get what you want to achieve here, so tricky to advice. The intention is to enforce either of the following three: compatible = "google,gs101-raven", "google,gs101-pixel", "google,gs101"; compatible = "google,gs101-oriole", "google,gs101-pixel", "google,gs101"; compatible = "google,gs101-pixel", "google,gs101"; I think this works (but I was aiming for something shorter, possibly involving minItems): compatible: oneOf: - description: Google GS101 Pixel base board items: - const: google,gs101-pixel - const: google,gs101 - description: Google GS101 Pixel 6 (Oriole), or 6 Pro (Raven) items: - enum: - google,gs101-oriole - google,gs101-raven - const: google,gs101-pixel - const: google,gs101 Cheers, Andre'
On 23/12/2024 16:31, André Draszik wrote: > On Mon, 2024-12-23 at 15:14 +0100, Krzysztof Kozlowski wrote: >> On 23/12/2024 08:45, André Draszik wrote: >>> Hi Krzysztof, >>> >>> On Sun, 2024-12-22 at 12:38 +0100, Krzysztof Kozlowski wrote: >>>> On 20/12/2024 12:27, André Draszik wrote: >>>>> Raven is Google's code name for Pixel 6 Pro. Since there are >>>>> differences compared to Pixel 6 (Oriole), we need to add a separate >>>>> compatible for it. >>>>> >>>>> We also want to support a generic DT, which can work on any type of >>>> >>>> There are no such generic DT devices upstream, so we cannot add bindings >>>> for them. >>> >>> Do you have a better suggestion for the wording? >>> How about 'gs101-based Pixel base board'? >> >> It's not exactly about the wording but the concept. We don't have >> generic devices, thus no generic DT (DTS). Period. Thus you cannot have >> such schema. > > There is a Pixel base board, with different additions to it, e.g. > different displays. The boot loader can pick the right one. > > Let's discuss that in the other thread to have things in one place :-) >> > >>>>> gs101-based Pixel device, e.g. Pixel 6, or Pixel 6 Pro, or Pixel 6a (as >>>>> a future addition). Such a DT will have certain nodes disabled / not >>>>> added. To facilitate such a generic gs101-based Pixel device, also add >>>>> a more generic gs101-pixel compatible. We can not just use the existing >>>>> google,gs101 for that, as it refers to the SoC, not a board. >>>>> >>>>> Signed-off-by: André Draszik <andre.draszik@linaro.org> >>>>> --- >>>>> Documentation/devicetree/bindings/arm/google.yaml | 18 ++++++++++++++---- >>>>> 1 file changed, 14 insertions(+), 4 deletions(-) >>>>> >>>>> diff --git a/Documentation/devicetree/bindings/arm/google.yaml b/Documentation/devicetree/bindings/arm/google.yaml >>>>> index e20b5c9b16bc..a8faf2256242 100644 >>>>> --- a/Documentation/devicetree/bindings/arm/google.yaml >>>>> +++ b/Documentation/devicetree/bindings/arm/google.yaml >>>>> @@ -34,11 +34,21 @@ properties: >>>>> const: '/' >>>>> compatible: >>>>> oneOf: >>>>> - - description: Google Pixel 6 / Oriole >>>>> + - description: Google GS101 Pixel devices, as generic Pixel, or Pixel 6 >>>>> + (Oriole), or 6 Pro (Raven) >>>>> + minItems: 2 >>>>> + maxItems: 3 >>>>> items: >>>>> - - enum: >>>>> - - google,gs101-oriole >>>>> - - const: google,gs101 >>>>> + enum: >>>>> + - google,gs101-oriole >>>>> + - google,gs101-raven >>>>> + - google,gs101-pixel >>>>> + - google,gs101 >>>> >>>> SoC cannot be a board in the same time. >>> >>> Can you please expand? google,gs101 is the SoC, the other ones are boards. >>> Is the commit message unclear? >> >> You now say that these are valid boards: >> >> compatible = "google,gs101", "google,gs101"; > > Sorry, I don't see how (apart from the fact that dtbs_check flags > non-unique elements anyway). The result of the patch is: > > minItems: 2 > maxItems: 3 > items: > enum: > - google,gs101-oriole > - google,gs101-raven > - google,gs101-pixel > - google,gs101 The problem is this line. Although entire concept of flexible list is neither need nor ever recommended. > allOf: > - contains: > const: google,gs101-pixel > - contains: > const: google,gs101 > > So one can not have 'google,gs101' twice. And if I only add Still can be, but indeed not with my example but: "google,gs101", "google,gs101", "google,gs101-pixel"; > compatible = "google,gs101", "google,gs101"; > to the .dts, then dtbs_check complains indeed. > >> (although compatibles >> >> compatible = "google,gs101", "google,gs101-pixel"; > > OK, the schema doesn't flag incorrect ordering indeed. > >> Both are wrong. SoC should not be before the board and SoC cannot be >> used alone. Your schema allows that and that's not good. >> >> I did not get what you want to achieve here, so tricky to advice. > > The intention is to enforce either of the following three: > > compatible = "google,gs101-raven", "google,gs101-pixel", "google,gs101"; > compatible = "google,gs101-oriole", "google,gs101-pixel", "google,gs101"; These two are standard - list of three: enum + const + const > compatible = "google,gs101-pixel", "google,gs101"; And that's a separate entry. > > I think this works (but I was aiming for something shorter, > possibly involving minItems): > > compatible: > oneOf: > - description: Google GS101 Pixel base board What is a base board in terms of phone? This can be only final product, you cannot use/have a baseboard. This is not an evalkit. > items: > - const: google,gs101-pixel > - const: google,gs101 Best regards, Krzysztof
On Mon, 2024-12-23 at 16:39 +0100, Krzysztof Kozlowski wrote: > On 23/12/2024 16:31, André Draszik wrote: > > On Mon, 2024-12-23 at 15:14 +0100, Krzysztof Kozlowski wrote: > > > > > > > > You now say that these are valid boards: > > > > > > compatible = "google,gs101", "google,gs101"; > > > > Sorry, I don't see how (apart from the fact that dtbs_check flags > > non-unique elements anyway). The result of the patch is: > > > > minItems: 2 > > maxItems: 3 > > items: > > enum: > > - google,gs101-oriole > > - google,gs101-raven > > - google,gs101-pixel > > - google,gs101 > > The problem is this line. Although entire concept of flexible list is > neither need nor ever recommended. All of this was inspired by Documentation/devicetree/bindings/soc/xilinx/xilinx.yaml I guess not a good example in this case... > > > allOf: > > - contains: > > const: google,gs101-pixel > > - contains: > > const: google,gs101 > > > > So one can not have 'google,gs101' twice. And if I only add > > Still can be, but indeed not with my example but: > > "google,gs101", "google,gs101", "google,gs101-pixel"; This example doesn't pass irrespective of binding, because dtbs_check will complain about non-unique elements. Anyway, will use separate entries. Thanks Krzysztof, Cheers, Andre' >
On 23/12/2024 16:54, André Draszik wrote: > On Mon, 2024-12-23 at 16:39 +0100, Krzysztof Kozlowski wrote: >> On 23/12/2024 16:31, André Draszik wrote: >>> On Mon, 2024-12-23 at 15:14 +0100, Krzysztof Kozlowski wrote: >>> >>>> >>>> You now say that these are valid boards: >>>> >>>> compatible = "google,gs101", "google,gs101"; >>> >>> Sorry, I don't see how (apart from the fact that dtbs_check flags >>> non-unique elements anyway). The result of the patch is: >>> >>> minItems: 2 >>> maxItems: 3 >>> items: >>> enum: >>> - google,gs101-oriole >>> - google,gs101-raven >>> - google,gs101-pixel >>> - google,gs101 >> >> The problem is this line. Although entire concept of flexible list is >> neither need nor ever recommended. > > All of this was inspired by Documentation/devicetree/bindings/soc/xilinx/xilinx.yaml > I guess not a good example in this case... These are SoMs with multiple revisions, so quite a different case. Plus there is actual reason from Michal for doing that explained in commit msg. > >> >>> allOf: >>> - contains: >>> const: google,gs101-pixel >>> - contains: >>> const: google,gs101 >>> >>> So one can not have 'google,gs101' twice. And if I only add >> >> Still can be, but indeed not with my example but: >> >> "google,gs101", "google,gs101", "google,gs101-pixel"; > > This example doesn't pass irrespective of binding, because > dtbs_check will complain about non-unique elements. Ah, cool, I wasn't really sure. I checked only dt_binding_check on some example and there it was not spotted. Best regards, Krzysztof
Hi, This series enables support for Google Pixel 6 Pro. Since Pixel 6 and Pixel 6 Pro use a different resolution display, we now need to add explicit support for it, we can not piggyback on the non-Pro version anymore. This means having to separate them into their respective DTs, and provide one for each of them. There are other differences between the two of course, like battery design capacity, etc., but they don't matter at this stage due to incomplete upstream support. * dependency note * Due to the renaming of the gs101-oriole.dts, this series will conflict with any pending patches touching the same file. I have therefore based this series on top of my USB series from https://lore.kernel.org/r/20241203-gs101-phy-lanes-orientation-dts-v2-0-1412783a6b01@linaro.org and the patch enabling framebuffer support for Pixel 6 from https://lore.kernel.org/r/20241220-gs101-simplefb-oriole-v2-1-df60e566932a@linaro.org * dependency note end * Signed-off-by: André Draszik <andre.draszik@linaro.org> --- Changes in v2: - We now have a generic gs101-based Pixel board DT, which can work on any Pixel 6 / 6 Pro / 6a - Pixel 6 (Pro) are overlays onto that one. This has the advantage that all boards can be supported without having to have a full copy of the DT for each of them. We still instruct kbuild to create merged DTBs (in addition to the DTBOs) so that existing scripts can keep working while giving the option to just apply the overlay before boot (e.g. by the bootloader). - The binding has been updated according to the above points - I've changed the simple-framebuffer node to specify the memory via memory-region instead of reg, as that avoids unnecessary duplication (of the size), and it avoids having to specify #address-cells and #size-cells in the chosen node (and duplicating this in the DTSO), which is otherwise necessary to keep dt_binding_check happy and DT validation working in general. - sort overriding/extending nodes ordered by label name (Krzysztof) - format patches with diff.renames=copies (Krzysztof) - dependencies have been updated, see below - Link to v1: https://lore.kernel.org/r/20241216-gs101-simplefb-v1-0-8ccad1830281@linaro.org --- André Draszik (3): dt-bindings: arm: google: add gs101-raven and generic gs101-pixel arm64: dts: exynos: gs101-pixel: add generic gs101-based Pixel support arm64: dts: exynos: gs101-raven: add new board file Documentation/devicetree/bindings/arm/google.yaml | 18 +++++++++--- arch/arm64/boot/dts/exynos/google/Makefile | 9 ++++-- .../arm64/boot/dts/exynos/google/gs101-oriole.dtso | 33 ++++++++++++++++++++++ .../{gs101-oriole.dts => gs101-pixel-generic.dts} | 24 +++++++--------- arch/arm64/boot/dts/exynos/google/gs101-raven.dtso | 33 ++++++++++++++++++++++ 5 files changed, 97 insertions(+), 20 deletions(-) --- base-commit: f70ddfc479f2fac1d0b744148743c25ce1778f01 change-id: 20241216-gs101-simplefb-8aae80278ed7 Best regards,