[GIT PULL 0/3] Samsung for v5.12

[GIT PULL 0/3] Samsung for v5.12

[Krzysztof Kozlowski]

Hi,

Three tags to pull for v5.12. No dependencies, no order of pulls.

Best regards,
Krzysztof

[GIT PULL 0/3] Samsung for v5.12

[Krzysztof Kozlowski]

Hi,

Three tags to pull for v5.12. No dependencies, no order of pulls.

Best regards,
Krzysztof


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[GIT PULL 1/3] soc: samsung: drivers for v5.12

[Krzysztof Kozlowski]

The following changes since commit 5c8fe583cce542aa0b84adc939ce85293de36e5e:

  Linux 5.11-rc1 (2020-12-27 15:30:22 -0800)

are available in the Git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-drivers-5.12

for you to fetch changes up to c09a3e6c97f00a525e23854d63f003aba9adfa41:

  soc: samsung: pm_domains: Convert to regular platform driver (2021-01-15 20:50:34 +0100)

----------------------------------------------------------------
Samsung SoC drivers changes for v5.12

1. Adjust deferred probe and handle regmap_read() errors in Exynos ASV
   driver.
2. Convert the ChipID code into a driver (from a early initcall) and
   merge it into the Exynos ASV.
3. Convert the PM domains code into a driver. This is necessary for
   upcoming code enabling fw_devlinks.

----------------------------------------------------------------
Krzysztof Kozlowski (3):
      soc: samsung: exynos-asv: handle reading revision register error
      soc: samsung: exynos-chipid: convert to driver and merge exynos-asv
      soc: samsung: exynos-chipid: correct helpers __init annotation

Marek Szyprowski (2):
      soc: samsung: exynos-asv: don't defer early on not-supported SoCs
      soc: samsung: pm_domains: Convert to regular platform driver

 arch/arm/mach-exynos/Kconfig        |  1 -
 drivers/soc/samsung/Kconfig         | 12 ++---
 drivers/soc/samsung/Makefile        |  3 +-
 drivers/soc/samsung/exynos-asv.c    | 57 ++++++++--------------
 drivers/soc/samsung/exynos-asv.h    |  2 +
 drivers/soc/samsung/exynos-chipid.c | 71 ++++++++++++++++++---------
 drivers/soc/samsung/pm_domains.c    | 97 ++++++++++++++++++-------------------
 7 files changed, 125 insertions(+), 118 deletions(-)

[GIT PULL 1/3] soc: samsung: drivers for v5.12

[Krzysztof Kozlowski]

The following changes since commit 5c8fe583cce542aa0b84adc939ce85293de36e5e:

  Linux 5.11-rc1 (2020-12-27 15:30:22 -0800)

are available in the Git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-drivers-5.12

for you to fetch changes up to c09a3e6c97f00a525e23854d63f003aba9adfa41:

  soc: samsung: pm_domains: Convert to regular platform driver (2021-01-15 20:50:34 +0100)

----------------------------------------------------------------
Samsung SoC drivers changes for v5.12

1. Adjust deferred probe and handle regmap_read() errors in Exynos ASV
   driver.
2. Convert the ChipID code into a driver (from a early initcall) and
   merge it into the Exynos ASV.
3. Convert the PM domains code into a driver. This is necessary for
   upcoming code enabling fw_devlinks.

----------------------------------------------------------------
Krzysztof Kozlowski (3):
      soc: samsung: exynos-asv: handle reading revision register error
      soc: samsung: exynos-chipid: convert to driver and merge exynos-asv
      soc: samsung: exynos-chipid: correct helpers __init annotation

Marek Szyprowski (2):
      soc: samsung: exynos-asv: don't defer early on not-supported SoCs
      soc: samsung: pm_domains: Convert to regular platform driver

 arch/arm/mach-exynos/Kconfig        |  1 -
 drivers/soc/samsung/Kconfig         | 12 ++---
 drivers/soc/samsung/Makefile        |  3 +-
 drivers/soc/samsung/exynos-asv.c    | 57 ++++++++--------------
 drivers/soc/samsung/exynos-asv.h    |  2 +
 drivers/soc/samsung/exynos-chipid.c | 71 ++++++++++++++++++---------
 drivers/soc/samsung/pm_domains.c    | 97 ++++++++++++++++++-------------------
 7 files changed, 125 insertions(+), 118 deletions(-)

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [GIT PULL 1/3] soc: samsung: drivers for v5.12

[Arnd Bergmann]

From: Arnd Bergmann <arnd@arndb.de>

On Mon, 25 Jan 2021 20:12:38 +0100, Krzysztof Kozlowski wrote:
> The following changes since commit 5c8fe583cce542aa0b84adc939ce85293de36e5e:
> 
>   Linux 5.11-rc1 (2020-12-27 15:30:22 -0800)
> 
> are available in the Git repository at:
> 
>   https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-drivers-5.12
> 
> [...]

Merged into arm/soc, thanks!

merge commit: 8bd99a058fb62af53f9603057f2efd635f149575

       Arnd

Re: [GIT PULL 1/3] soc: samsung: drivers for v5.12

[Arnd Bergmann]

From: Arnd Bergmann <arnd@arndb.de>

On Mon, 25 Jan 2021 20:12:38 +0100, Krzysztof Kozlowski wrote:
> The following changes since commit 5c8fe583cce542aa0b84adc939ce85293de36e5e:
> 
>   Linux 5.11-rc1 (2020-12-27 15:30:22 -0800)
> 
> are available in the Git repository at:
> 
>   https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-drivers-5.12
> 
> [...]

Merged into arm/soc, thanks!

merge commit: 8bd99a058fb62af53f9603057f2efd635f149575

       Arnd

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[GIT PULL 2/3] ARM: dts: samsung: DTS for v5.12

[Krzysztof Kozlowski]

The following changes since commit 5c8fe583cce542aa0b84adc939ce85293de36e5e:

  Linux 5.11-rc1 (2020-12-27 15:30:22 -0800)

are available in the Git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-dt-5.12

for you to fetch changes up to 3803f461bd28c1c817281348509399778633e82f:

  ARM: dts: exynos: Add top-off charging regulator node for I9100 (2021-01-03 17:33:29 +0100)

----------------------------------------------------------------
Samsung DTS ARM changes for v5.12

1. Use new compatile to properly configure Exynos5420 USB2 PHY, fixing
   it suspend/resume cycle.
2. Correct Samsung PMIC interrupt trigger levels on multiple boards.
3. Correct the voltages of Samsung GT-I9100 charger and add top-off
   charger.

----------------------------------------------------------------
Krzysztof Kozlowski (6):
      ARM: dts: exynos: correct PMIC interrupt trigger level on Artik 5
      ARM: dts: exynos: correct PMIC interrupt trigger level on Monk
      ARM: dts: exynos: correct PMIC interrupt trigger level on Rinato
      ARM: dts: exynos: correct PMIC interrupt trigger level on Spring
      ARM: dts: exynos: correct PMIC interrupt trigger level on Arndale Octa
      ARM: dts: exynos: correct PMIC interrupt trigger level on Odroid XU3 family

Marek Szyprowski (1):
      ARM: dts: exynos: use Exynos5420 dedicated USB2 PHY compatible

Timon Baetz (2):
      ARM: dts: exynos: Fix charging regulator voltage and current for I9100
      ARM: dts: exynos: Add top-off charging regulator node for I9100

 arch/arm/boot/dts/exynos3250-artik5.dtsi      |  2 +-
 arch/arm/boot/dts/exynos3250-monk.dts         |  2 +-
 arch/arm/boot/dts/exynos3250-rinato.dts       |  2 +-
 arch/arm/boot/dts/exynos4210-i9100.dts        | 30 ++++++++++++++++-----------
 arch/arm/boot/dts/exynos5250-spring.dts       |  2 +-
 arch/arm/boot/dts/exynos5420-arndale-octa.dts |  2 +-
 arch/arm/boot/dts/exynos5422-odroid-core.dtsi |  2 +-
 arch/arm/boot/dts/exynos54xx.dtsi             |  6 +++---
 8 files changed, 27 insertions(+), 21 deletions(-)

[GIT PULL 2/3] ARM: dts: samsung: DTS for v5.12

[Krzysztof Kozlowski]

The following changes since commit 5c8fe583cce542aa0b84adc939ce85293de36e5e:

  Linux 5.11-rc1 (2020-12-27 15:30:22 -0800)

are available in the Git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-dt-5.12

for you to fetch changes up to 3803f461bd28c1c817281348509399778633e82f:

  ARM: dts: exynos: Add top-off charging regulator node for I9100 (2021-01-03 17:33:29 +0100)

----------------------------------------------------------------
Samsung DTS ARM changes for v5.12

1. Use new compatile to properly configure Exynos5420 USB2 PHY, fixing
   it suspend/resume cycle.
2. Correct Samsung PMIC interrupt trigger levels on multiple boards.
3. Correct the voltages of Samsung GT-I9100 charger and add top-off
   charger.

----------------------------------------------------------------
Krzysztof Kozlowski (6):
      ARM: dts: exynos: correct PMIC interrupt trigger level on Artik 5
      ARM: dts: exynos: correct PMIC interrupt trigger level on Monk
      ARM: dts: exynos: correct PMIC interrupt trigger level on Rinato
      ARM: dts: exynos: correct PMIC interrupt trigger level on Spring
      ARM: dts: exynos: correct PMIC interrupt trigger level on Arndale Octa
      ARM: dts: exynos: correct PMIC interrupt trigger level on Odroid XU3 family

Marek Szyprowski (1):
      ARM: dts: exynos: use Exynos5420 dedicated USB2 PHY compatible

Timon Baetz (2):
      ARM: dts: exynos: Fix charging regulator voltage and current for I9100
      ARM: dts: exynos: Add top-off charging regulator node for I9100

 arch/arm/boot/dts/exynos3250-artik5.dtsi      |  2 +-
 arch/arm/boot/dts/exynos3250-monk.dts         |  2 +-
 arch/arm/boot/dts/exynos3250-rinato.dts       |  2 +-
 arch/arm/boot/dts/exynos4210-i9100.dts        | 30 ++++++++++++++++-----------
 arch/arm/boot/dts/exynos5250-spring.dts       |  2 +-
 arch/arm/boot/dts/exynos5420-arndale-octa.dts |  2 +-
 arch/arm/boot/dts/exynos5422-odroid-core.dtsi |  2 +-
 arch/arm/boot/dts/exynos54xx.dtsi             |  6 +++---
 8 files changed, 27 insertions(+), 21 deletions(-)

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [GIT PULL 2/3] ARM: dts: samsung: DTS for v5.12

[Krzysztof Kozlowski]

On Mon, Jan 25, 2021 at 08:12:39PM +0100, Krzysztof Kozlowski wrote:
> The following changes since commit 5c8fe583cce542aa0b84adc939ce85293de36e5e:
> 
>   Linux 5.11-rc1 (2020-12-27 15:30:22 -0800)
> 
> are available in the Git repository at:
> 
>   https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-dt-5.12
> 
> for you to fetch changes up to 3803f461bd28c1c817281348509399778633e82f:
> 
>   ARM: dts: exynos: Add top-off charging regulator node for I9100 (2021-01-03 17:33:29 +0100)
> 
> ----------------------------------------------------------------
> Samsung DTS ARM changes for v5.12
> 
> 1. Use new compatile to properly configure Exynos5420 USB2 PHY, fixing
>    it suspend/resume cycle.
> 2. Correct Samsung PMIC interrupt trigger levels on multiple boards.
> 3. Correct the voltages of Samsung GT-I9100 charger and add top-off
>    charger.
> 

Hi everyone,

Any progress or new comments about this pull request?

Best regards,
Krzysztof



> ----------------------------------------------------------------
> Krzysztof Kozlowski (6):
>       ARM: dts: exynos: correct PMIC interrupt trigger level on Artik 5
>       ARM: dts: exynos: correct PMIC interrupt trigger level on Monk
>       ARM: dts: exynos: correct PMIC interrupt trigger level on Rinato
>       ARM: dts: exynos: correct PMIC interrupt trigger level on Spring
>       ARM: dts: exynos: correct PMIC interrupt trigger level on Arndale Octa
>       ARM: dts: exynos: correct PMIC interrupt trigger level on Odroid XU3 family
> 
> Marek Szyprowski (1):
>       ARM: dts: exynos: use Exynos5420 dedicated USB2 PHY compatible
> 
> Timon Baetz (2):
>       ARM: dts: exynos: Fix charging regulator voltage and current for I9100
>       ARM: dts: exynos: Add top-off charging regulator node for I9100
> 
>  arch/arm/boot/dts/exynos3250-artik5.dtsi      |  2 +-
>  arch/arm/boot/dts/exynos3250-monk.dts         |  2 +-
>  arch/arm/boot/dts/exynos3250-rinato.dts       |  2 +-
>  arch/arm/boot/dts/exynos4210-i9100.dts        | 30 ++++++++++++++++-----------
>  arch/arm/boot/dts/exynos5250-spring.dts       |  2 +-
>  arch/arm/boot/dts/exynos5420-arndale-octa.dts |  2 +-
>  arch/arm/boot/dts/exynos5422-odroid-core.dtsi |  2 +-
>  arch/arm/boot/dts/exynos54xx.dtsi             |  6 +++---
>  8 files changed, 27 insertions(+), 21 deletions(-)

Re: [GIT PULL 2/3] ARM: dts: samsung: DTS for v5.12

[Krzysztof Kozlowski]

On Mon, Jan 25, 2021 at 08:12:39PM +0100, Krzysztof Kozlowski wrote:
> The following changes since commit 5c8fe583cce542aa0b84adc939ce85293de36e5e:
> 
>   Linux 5.11-rc1 (2020-12-27 15:30:22 -0800)
> 
> are available in the Git repository at:
> 
>   https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-dt-5.12
> 
> for you to fetch changes up to 3803f461bd28c1c817281348509399778633e82f:
> 
>   ARM: dts: exynos: Add top-off charging regulator node for I9100 (2021-01-03 17:33:29 +0100)
> 
> ----------------------------------------------------------------
> Samsung DTS ARM changes for v5.12
> 
> 1. Use new compatile to properly configure Exynos5420 USB2 PHY, fixing
>    it suspend/resume cycle.
> 2. Correct Samsung PMIC interrupt trigger levels on multiple boards.
> 3. Correct the voltages of Samsung GT-I9100 charger and add top-off
>    charger.
> 

Hi everyone,

Any progress or new comments about this pull request?

Best regards,
Krzysztof



> ----------------------------------------------------------------
> Krzysztof Kozlowski (6):
>       ARM: dts: exynos: correct PMIC interrupt trigger level on Artik 5
>       ARM: dts: exynos: correct PMIC interrupt trigger level on Monk
>       ARM: dts: exynos: correct PMIC interrupt trigger level on Rinato
>       ARM: dts: exynos: correct PMIC interrupt trigger level on Spring
>       ARM: dts: exynos: correct PMIC interrupt trigger level on Arndale Octa
>       ARM: dts: exynos: correct PMIC interrupt trigger level on Odroid XU3 family
> 
> Marek Szyprowski (1):
>       ARM: dts: exynos: use Exynos5420 dedicated USB2 PHY compatible
> 
> Timon Baetz (2):
>       ARM: dts: exynos: Fix charging regulator voltage and current for I9100
>       ARM: dts: exynos: Add top-off charging regulator node for I9100
> 
>  arch/arm/boot/dts/exynos3250-artik5.dtsi      |  2 +-
>  arch/arm/boot/dts/exynos3250-monk.dts         |  2 +-
>  arch/arm/boot/dts/exynos3250-rinato.dts       |  2 +-
>  arch/arm/boot/dts/exynos4210-i9100.dts        | 30 ++++++++++++++++-----------
>  arch/arm/boot/dts/exynos5250-spring.dts       |  2 +-
>  arch/arm/boot/dts/exynos5420-arndale-octa.dts |  2 +-
>  arch/arm/boot/dts/exynos5422-odroid-core.dtsi |  2 +-
>  arch/arm/boot/dts/exynos54xx.dtsi             |  6 +++---
>  8 files changed, 27 insertions(+), 21 deletions(-)

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [GIT PULL 2/3] ARM: dts: samsung: DTS for v5.12

[Arnd Bergmann]

On Sat, Feb 6, 2021 at 2:45 PM Krzysztof Kozlowski <krzk@kernel.org> wrote:
> On Mon, Jan 25, 2021 at 08:12:39PM +0100, Krzysztof Kozlowski wrote:
> >
> > ----------------------------------------------------------------
> > Samsung DTS ARM changes for v5.12
> >
> > 1. Use new compatile to properly configure Exynos5420 USB2 PHY, fixing
> >    it suspend/resume cycle.
> > 2. Correct Samsung PMIC interrupt trigger levels on multiple boards.
> > 3. Correct the voltages of Samsung GT-I9100 charger and add top-off
> >    charger.
> >
>
> Hi everyone,
>
> Any progress or new comments about this pull request?

Hi Krzysztof,

Sorry for not getting back to you on this earlier. I discussed this with
Olof the other day and we decided to merge this, I just haven't
gone through the pull requests over the past few days. My plan is
to do the next round on Monday.

That said, I'm still not happy about the patch we discussed in the
other email thread[1] and I'd like to handle it a little more strictly in
the future, but I agree this wasn't obvious and we have been rather
inconsistent about it in the past, with some platform maintainers
handling it way more strictly than others.

I've added the devicetree maintainers and a few other platform
maintainers to Cc here, maybe they can provide some further
opinions on the topic so we can come to an approach that
works for everyone.

My summary of the thread in [1] is there was a driver bug that
required a DT binding change. Krzysztof and the other involved
parties made sure the driver handles it in a backward-compatible
way (an old dtb file will still run into the bug but keep working
with new kernels), but decided that they did not need to worry
about the opposite case (running an old kernel with an updated
dtb). I noticed the compatibility break and said that I would
prefer this to be done in a way that is compatible both ways,
or at the minimum be alerted about the binding break in the
pull request, with an explanation about why this had to be done,
even when we don't think anyone is going to be affected.

What do others think about this? Should we generally assume
that breaking old kernels with new dtbs is acceptable, or should
we try to avoid it if possible, the same way we try to avoid
breaking new kernels with old dtbs? Should this be a platform
specific policy or should we try to handle all platforms the same
way?

          Arnd

[1] https://lore.kernel.org/lkml/20210130143949.aamac2724esupt7v@kozik-lap/

Re: [GIT PULL 2/3] ARM: dts: samsung: DTS for v5.12

[Arnd Bergmann]

On Sat, Feb 6, 2021 at 2:45 PM Krzysztof Kozlowski <krzk@kernel.org> wrote:
> On Mon, Jan 25, 2021 at 08:12:39PM +0100, Krzysztof Kozlowski wrote:
> >
> > ----------------------------------------------------------------
> > Samsung DTS ARM changes for v5.12
> >
> > 1. Use new compatile to properly configure Exynos5420 USB2 PHY, fixing
> >    it suspend/resume cycle.
> > 2. Correct Samsung PMIC interrupt trigger levels on multiple boards.
> > 3. Correct the voltages of Samsung GT-I9100 charger and add top-off
> >    charger.
> >
>
> Hi everyone,
>
> Any progress or new comments about this pull request?

Hi Krzysztof,

Sorry for not getting back to you on this earlier. I discussed this with
Olof the other day and we decided to merge this, I just haven't
gone through the pull requests over the past few days. My plan is
to do the next round on Monday.

That said, I'm still not happy about the patch we discussed in the
other email thread[1] and I'd like to handle it a little more strictly in
the future, but I agree this wasn't obvious and we have been rather
inconsistent about it in the past, with some platform maintainers
handling it way more strictly than others.

I've added the devicetree maintainers and a few other platform
maintainers to Cc here, maybe they can provide some further
opinions on the topic so we can come to an approach that
works for everyone.

My summary of the thread in [1] is there was a driver bug that
required a DT binding change. Krzysztof and the other involved
parties made sure the driver handles it in a backward-compatible
way (an old dtb file will still run into the bug but keep working
with new kernels), but decided that they did not need to worry
about the opposite case (running an old kernel with an updated
dtb). I noticed the compatibility break and said that I would
prefer this to be done in a way that is compatible both ways,
or at the minimum be alerted about the binding break in the
pull request, with an explanation about why this had to be done,
even when we don't think anyone is going to be affected.

What do others think about this? Should we generally assume
that breaking old kernels with new dtbs is acceptable, or should
we try to avoid it if possible, the same way we try to avoid
breaking new kernels with old dtbs? Should this be a platform
specific policy or should we try to handle all platforms the same
way?

          Arnd

[1] https://lore.kernel.org/lkml/20210130143949.aamac2724esupt7v@kozik-lap/

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [GIT PULL 2/3] ARM: dts: samsung: DTS for v5.12

[Krzysztof Kozlowski]

On Sat, Feb 06, 2021 at 03:35:54PM +0100, Arnd Bergmann wrote:
> On Sat, Feb 6, 2021 at 2:45 PM Krzysztof Kozlowski <krzk@kernel.org> wrote:
> > On Mon, Jan 25, 2021 at 08:12:39PM +0100, Krzysztof Kozlowski wrote:
> > >
> > > ----------------------------------------------------------------
> > > Samsung DTS ARM changes for v5.12
> > >
> > > 1. Use new compatile to properly configure Exynos5420 USB2 PHY, fixing
> > >    it suspend/resume cycle.
> > > 2. Correct Samsung PMIC interrupt trigger levels on multiple boards.
> > > 3. Correct the voltages of Samsung GT-I9100 charger and add top-off
> > >    charger.
> > >
> >
> > Hi everyone,
> >
> > Any progress or new comments about this pull request?
> 
> Hi Krzysztof,
> 
> Sorry for not getting back to you on this earlier. I discussed this with
> Olof the other day and we decided to merge this, I just haven't
> gone through the pull requests over the past few days. My plan is
> to do the next round on Monday.
> 
> That said, I'm still not happy about the patch we discussed in the
> other email thread[1] and I'd like to handle it a little more strictly in
> the future, but I agree this wasn't obvious and we have been rather
> inconsistent about it in the past, with some platform maintainers
> handling it way more strictly than others.

Thank you for explanation. I would love to receive kind of guidance,
best practices, guide for future patches. I will them write it down and
try to follow during my review. However it made me a sad that a patch,
adhering in my mind to all rules, was postponing the pull request.

> 
> I've added the devicetree maintainers and a few other platform
> maintainers to Cc here, maybe they can provide some further
> opinions on the topic so we can come to an approach that
> works for everyone.
> 
> My summary of the thread in [1] is there was a driver bug that
> required a DT binding change. Krzysztof and the other involved
> parties made sure the driver handles it in a backward-compatible
> way (an old dtb file will still run into the bug but keep working
> with new kernels), but decided that they did not need to worry
> about the opposite case (running an old kernel with an updated
> dtb). I noticed the compatibility break and said that I would
> prefer this to be done in a way that is compatible both ways,
> or at the minimum be alerted about the binding break in the
> pull request, with an explanation about why this had to be done,
> even when we don't think anyone is going to be affected.
> 
> What do others think about this? Should we generally assume
> that breaking old kernels with new dtbs is acceptable, or should
> we try to avoid it if possible, the same way we try to avoid
> breaking new kernels with old dtbs? Should this be a platform
> specific policy or should we try to handle all platforms the same
> way?

Good summary, thanks Arnd. I would like to add that the discussed change
was bringing a new compatible. It was saying: hey, this hardware so far we
treated as old one, but it's not, sorry, it is different, so here you
have a new compatible with a change in few properties as well (and new
bindings which appeared a release earlier).

Best regards,
Krzysztof


> 
>           Arnd
> 
> [1] https://lore.kernel.org/lkml/20210130143949.aamac2724esupt7v@kozik-lap/

Re: [GIT PULL 2/3] ARM: dts: samsung: DTS for v5.12

[Krzysztof Kozlowski]

On Sat, Feb 06, 2021 at 03:35:54PM +0100, Arnd Bergmann wrote:
> On Sat, Feb 6, 2021 at 2:45 PM Krzysztof Kozlowski <krzk@kernel.org> wrote:
> > On Mon, Jan 25, 2021 at 08:12:39PM +0100, Krzysztof Kozlowski wrote:
> > >
> > > ----------------------------------------------------------------
> > > Samsung DTS ARM changes for v5.12
> > >
> > > 1. Use new compatile to properly configure Exynos5420 USB2 PHY, fixing
> > >    it suspend/resume cycle.
> > > 2. Correct Samsung PMIC interrupt trigger levels on multiple boards.
> > > 3. Correct the voltages of Samsung GT-I9100 charger and add top-off
> > >    charger.
> > >
> >
> > Hi everyone,
> >
> > Any progress or new comments about this pull request?
> 
> Hi Krzysztof,
> 
> Sorry for not getting back to you on this earlier. I discussed this with
> Olof the other day and we decided to merge this, I just haven't
> gone through the pull requests over the past few days. My plan is
> to do the next round on Monday.
> 
> That said, I'm still not happy about the patch we discussed in the
> other email thread[1] and I'd like to handle it a little more strictly in
> the future, but I agree this wasn't obvious and we have been rather
> inconsistent about it in the past, with some platform maintainers
> handling it way more strictly than others.

Thank you for explanation. I would love to receive kind of guidance,
best practices, guide for future patches. I will them write it down and
try to follow during my review. However it made me a sad that a patch,
adhering in my mind to all rules, was postponing the pull request.

> 
> I've added the devicetree maintainers and a few other platform
> maintainers to Cc here, maybe they can provide some further
> opinions on the topic so we can come to an approach that
> works for everyone.
> 
> My summary of the thread in [1] is there was a driver bug that
> required a DT binding change. Krzysztof and the other involved
> parties made sure the driver handles it in a backward-compatible
> way (an old dtb file will still run into the bug but keep working
> with new kernels), but decided that they did not need to worry
> about the opposite case (running an old kernel with an updated
> dtb). I noticed the compatibility break and said that I would
> prefer this to be done in a way that is compatible both ways,
> or at the minimum be alerted about the binding break in the
> pull request, with an explanation about why this had to be done,
> even when we don't think anyone is going to be affected.
> 
> What do others think about this? Should we generally assume
> that breaking old kernels with new dtbs is acceptable, or should
> we try to avoid it if possible, the same way we try to avoid
> breaking new kernels with old dtbs? Should this be a platform
> specific policy or should we try to handle all platforms the same
> way?

Good summary, thanks Arnd. I would like to add that the discussed change
was bringing a new compatible. It was saying: hey, this hardware so far we
treated as old one, but it's not, sorry, it is different, so here you
have a new compatible with a change in few properties as well (and new
bindings which appeared a release earlier).

Best regards,
Krzysztof


> 
>           Arnd
> 
> [1] https://lore.kernel.org/lkml/20210130143949.aamac2724esupt7v@kozik-lap/

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [GIT PULL 2/3] ARM: dts: samsung: DTS for v5.12

[Krzysztof Kozlowski]

On Sat, Feb 06, 2021 at 03:35:54PM +0100, Arnd Bergmann wrote:
> On Sat, Feb 6, 2021 at 2:45 PM Krzysztof Kozlowski <krzk@kernel.org> wrote:
> > On Mon, Jan 25, 2021 at 08:12:39PM +0100, Krzysztof Kozlowski wrote:
> > >
> > > ----------------------------------------------------------------
> > > Samsung DTS ARM changes for v5.12
> > >
> > > 1. Use new compatile to properly configure Exynos5420 USB2 PHY, fixing
> > >    it suspend/resume cycle.
> > > 2. Correct Samsung PMIC interrupt trigger levels on multiple boards.
> > > 3. Correct the voltages of Samsung GT-I9100 charger and add top-off
> > >    charger.
> > >
> >
> > Hi everyone,
> >
> > Any progress or new comments about this pull request?
> 
> Hi Krzysztof,
> 
> Sorry for not getting back to you on this earlier. I discussed this with
> Olof the other day and we decided to merge this, I just haven't
> gone through the pull requests over the past few days. My plan is
> to do the next round on Monday.
> 
> That said, I'm still not happy about the patch we discussed in the
> other email thread[1] and I'd like to handle it a little more strictly in
> the future, but I agree this wasn't obvious and we have been rather
> inconsistent about it in the past, with some platform maintainers
> handling it way more strictly than others.

Thank you for explanation. I would love to receive kind of guidance,
best practices, guide for future patches. I will them write it down and
try to follow during my review. However it made me a sad that a patch,
adhering in my mind to all rules, was postponing the pull request.

> 
> I've added the devicetree maintainers and a few other platform
> maintainers to Cc here, maybe they can provide some further
> opinions on the topic so we can come to an approach that
> works for everyone.
> 
> My summary of the thread in [1] is there was a driver bug that
> required a DT binding change. Krzysztof and the other involved
> parties made sure the driver handles it in a backward-compatible
> way (an old dtb file will still run into the bug but keep working
> with new kernels), but decided that they did not need to worry
> about the opposite case (running an old kernel with an updated
> dtb). I noticed the compatibility break and said that I would
> prefer this to be done in a way that is compatible both ways,
> or at the minimum be alerted about the binding break in the
> pull request, with an explanation about why this had to be done,
> even when we don't think anyone is going to be affected.
> 
> What do others think about this? Should we generally assume
> that breaking old kernels with new dtbs is acceptable, or should
> we try to avoid it if possible, the same way we try to avoid
> breaking new kernels with old dtbs? Should this be a platform
> specific policy or should we try to handle all platforms the same
> way?

Good summary, thanks Arnd. I would like to add that the discussed change
was bringing a new compatible. It was saying: hey, this hardware so far we
treated as old one, but it's not, sorry, it is different, so here you
have a new compatible with a change in few properties as well (and new
bindings which appeared a release earlier).

Best regards,
Krzysztof


> 
>           Arnd
> 
> [1] https://lore.kernel.org/lkml/20210130143949.aamac2724esupt7v@kozik-lap/

Re: [GIT PULL 2/3] ARM: dts: samsung: DTS for v5.12

[Geert Uytterhoeven]

Hi Arnd,

On Sat, Feb 6, 2021 at 3:36 PM Arnd Bergmann <arnd@kernel.org> wrote:
> That said, I'm still not happy about the patch we discussed in the
> other email thread[1] and I'd like to handle it a little more strictly in
> the future, but I agree this wasn't obvious and we have been rather
> inconsistent about it in the past, with some platform maintainers
> handling it way more strictly than others.
>
> I've added the devicetree maintainers and a few other platform
> maintainers to Cc here, maybe they can provide some further
> opinions on the topic so we can come to an approach that
> works for everyone.
>
> My summary of the thread in [1] is there was a driver bug that
> required a DT binding change. Krzysztof and the other involved
> parties made sure the driver handles it in a backward-compatible
> way (an old dtb file will still run into the bug but keep working
> with new kernels), but decided that they did not need to worry
> about the opposite case (running an old kernel with an updated
> dtb). I noticed the compatibility break and said that I would
> prefer this to be done in a way that is compatible both ways,
> or at the minimum be alerted about the binding break in the
> pull request, with an explanation about why this had to be done,
> even when we don't think anyone is going to be affected.
>
> What do others think about this? Should we generally assume
> that breaking old kernels with new dtbs is acceptable, or should
> we try to avoid it if possible, the same way we try to avoid
> breaking new kernels with old dtbs? Should this be a platform
> specific policy or should we try to handle all platforms the same
> way?

For Renesas SoCs, we typically only consider compatibility of new
kernels with old DTBs, not the other way around.
However, most DTB updates are due to new hardware support, so using the
new DTB with an old kernel usually just means no newly documented
hardware, or new feature, is being used by the old kernel.

In case there was a real issue fixed, and using the new DTB with the old
kernel would cause a regression, and we're aware of it, we do make sure
the DTS update is postponed until the corresponding driver update has
hit upstream.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [GIT PULL 2/3] ARM: dts: samsung: DTS for v5.12

[Geert Uytterhoeven]

Hi Arnd,

On Sat, Feb 6, 2021 at 3:36 PM Arnd Bergmann <arnd@kernel.org> wrote:
> That said, I'm still not happy about the patch we discussed in the
> other email thread[1] and I'd like to handle it a little more strictly in
> the future, but I agree this wasn't obvious and we have been rather
> inconsistent about it in the past, with some platform maintainers
> handling it way more strictly than others.
>
> I've added the devicetree maintainers and a few other platform
> maintainers to Cc here, maybe they can provide some further
> opinions on the topic so we can come to an approach that
> works for everyone.
>
> My summary of the thread in [1] is there was a driver bug that
> required a DT binding change. Krzysztof and the other involved
> parties made sure the driver handles it in a backward-compatible
> way (an old dtb file will still run into the bug but keep working
> with new kernels), but decided that they did not need to worry
> about the opposite case (running an old kernel with an updated
> dtb). I noticed the compatibility break and said that I would
> prefer this to be done in a way that is compatible both ways,
> or at the minimum be alerted about the binding break in the
> pull request, with an explanation about why this had to be done,
> even when we don't think anyone is going to be affected.
>
> What do others think about this? Should we generally assume
> that breaking old kernels with new dtbs is acceptable, or should
> we try to avoid it if possible, the same way we try to avoid
> breaking new kernels with old dtbs? Should this be a platform
> specific policy or should we try to handle all platforms the same
> way?

For Renesas SoCs, we typically only consider compatibility of new
kernels with old DTBs, not the other way around.
However, most DTB updates are due to new hardware support, so using the
new DTB with an old kernel usually just means no newly documented
hardware, or new feature, is being used by the old kernel.

In case there was a real issue fixed, and using the new DTB with the old
kernel would cause a regression, and we're aware of it, we do make sure
the DTS update is postponed until the corresponding driver update has
hit upstream.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [GIT PULL 2/3] ARM: dts: samsung: DTS for v5.12

[Geert Uytterhoeven]

Hi Arnd,

On Sat, Feb 6, 2021 at 3:36 PM Arnd Bergmann <arnd@kernel.org> wrote:
> That said, I'm still not happy about the patch we discussed in the
> other email thread[1] and I'd like to handle it a little more strictly in
> the future, but I agree this wasn't obvious and we have been rather
> inconsistent about it in the past, with some platform maintainers
> handling it way more strictly than others.
>
> I've added the devicetree maintainers and a few other platform
> maintainers to Cc here, maybe they can provide some further
> opinions on the topic so we can come to an approach that
> works for everyone.
>
> My summary of the thread in [1] is there was a driver bug that
> required a DT binding change. Krzysztof and the other involved
> parties made sure the driver handles it in a backward-compatible
> way (an old dtb file will still run into the bug but keep working
> with new kernels), but decided that they did not need to worry
> about the opposite case (running an old kernel with an updated
> dtb). I noticed the compatibility break and said that I would
> prefer this to be done in a way that is compatible both ways,
> or at the minimum be alerted about the binding break in the
> pull request, with an explanation about why this had to be done,
> even when we don't think anyone is going to be affected.
>
> What do others think about this? Should we generally assume
> that breaking old kernels with new dtbs is acceptable, or should
> we try to avoid it if possible, the same way we try to avoid
> breaking new kernels with old dtbs? Should this be a platform
> specific policy or should we try to handle all platforms the same
> way?

For Renesas SoCs, we typically only consider compatibility of new
kernels with old DTBs, not the other way around.
However, most DTB updates are due to new hardware support, so using the
new DTB with an old kernel usually just means no newly documented
hardware, or new feature, is being used by the old kernel.

In case there was a real issue fixed, and using the new DTB with the old
kernel would cause a regression, and we're aware of it, we do make sure
the DTS update is postponed until the corresponding driver update has
hit upstream.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [GIT PULL 2/3] ARM: dts: samsung: DTS for v5.12

[Tony Lindgren]

* Geert Uytterhoeven <geert@linux-m68k.org> [210206 19:48]:
> On Sat, Feb 6, 2021 at 3:36 PM Arnd Bergmann <arnd@kernel.org> wrote:
> > What do others think about this? Should we generally assume
> > that breaking old kernels with new dtbs is acceptable, or should
> > we try to avoid it if possible, the same way we try to avoid
> > breaking new kernels with old dtbs? Should this be a platform
> > specific policy or should we try to handle all platforms the same
> > way?
> 
> For Renesas SoCs, we typically only consider compatibility of new
> kernels with old DTBs, not the other way around.
> However, most DTB updates are due to new hardware support, so using the
> new DTB with an old kernel usually just means no newly documented
> hardware, or new feature, is being used by the old kernel.
> 
> In case there was a real issue fixed, and using the new DTB with the old
> kernel would cause a regression, and we're aware of it, we do make sure
> the DTS update is postponed until the corresponding driver update has
> hit upstream.

Yeah agreed. Adding new devicetree properties should not be a problem
for device drivers.

For renamed devicetree properties, the driver won't be aware of them
if a newer dtb is used. The only thing the driver can possibly do at
this point is maybe warn about some missing old property and bail out.

Making sure the driver changes are in place first helps a bit..
But naturally fixing the driver in advance won't help booting kernels
before the driver changes with a newer dtb :)

What helps though is to make sure git bisect works for building and
booting already at -rc1 kernel to make debugging the issue easy. As
-rc1 is used typically as the merge base the problem causing branches
can be tested separately that way.

Regards,

Tony

Re: [GIT PULL 2/3] ARM: dts: samsung: DTS for v5.12

[Tony Lindgren]

* Geert Uytterhoeven <geert@linux-m68k.org> [210206 19:48]:
> On Sat, Feb 6, 2021 at 3:36 PM Arnd Bergmann <arnd@kernel.org> wrote:
> > What do others think about this? Should we generally assume
> > that breaking old kernels with new dtbs is acceptable, or should
> > we try to avoid it if possible, the same way we try to avoid
> > breaking new kernels with old dtbs? Should this be a platform
> > specific policy or should we try to handle all platforms the same
> > way?
> 
> For Renesas SoCs, we typically only consider compatibility of new
> kernels with old DTBs, not the other way around.
> However, most DTB updates are due to new hardware support, so using the
> new DTB with an old kernel usually just means no newly documented
> hardware, or new feature, is being used by the old kernel.
> 
> In case there was a real issue fixed, and using the new DTB with the old
> kernel would cause a regression, and we're aware of it, we do make sure
> the DTS update is postponed until the corresponding driver update has
> hit upstream.

Yeah agreed. Adding new devicetree properties should not be a problem
for device drivers.

For renamed devicetree properties, the driver won't be aware of them
if a newer dtb is used. The only thing the driver can possibly do at
this point is maybe warn about some missing old property and bail out.

Making sure the driver changes are in place first helps a bit..
But naturally fixing the driver in advance won't help booting kernels
before the driver changes with a newer dtb :)

What helps though is to make sure git bisect works for building and
booting already at -rc1 kernel to make debugging the issue easy. As
-rc1 is used typically as the merge base the problem causing branches
can be tested separately that way.

Regards,

Tony

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [GIT PULL 2/3] ARM: dts: samsung: DTS for v5.12

[Tony Lindgren]

* Geert Uytterhoeven <geert@linux-m68k.org> [210206 19:48]:
> On Sat, Feb 6, 2021 at 3:36 PM Arnd Bergmann <arnd@kernel.org> wrote:
> > What do others think about this? Should we generally assume
> > that breaking old kernels with new dtbs is acceptable, or should
> > we try to avoid it if possible, the same way we try to avoid
> > breaking new kernels with old dtbs? Should this be a platform
> > specific policy or should we try to handle all platforms the same
> > way?
> 
> For Renesas SoCs, we typically only consider compatibility of new
> kernels with old DTBs, not the other way around.
> However, most DTB updates are due to new hardware support, so using the
> new DTB with an old kernel usually just means no newly documented
> hardware, or new feature, is being used by the old kernel.
> 
> In case there was a real issue fixed, and using the new DTB with the old
> kernel would cause a regression, and we're aware of it, we do make sure
> the DTS update is postponed until the corresponding driver update has
> hit upstream.

Yeah agreed. Adding new devicetree properties should not be a problem
for device drivers.

For renamed devicetree properties, the driver won't be aware of them
if a newer dtb is used. The only thing the driver can possibly do at
this point is maybe warn about some missing old property and bail out.

Making sure the driver changes are in place first helps a bit..
But naturally fixing the driver in advance won't help booting kernels
before the driver changes with a newer dtb :)

What helps though is to make sure git bisect works for building and
booting already at -rc1 kernel to make debugging the issue easy. As
-rc1 is used typically as the merge base the problem causing branches
can be tested separately that way.

Regards,

Tony

Re: [GIT PULL 2/3] ARM: dts: samsung: DTS for v5.12

[Bjorn Andersson]

On Sat 06 Feb 13:47 CST 2021, Geert Uytterhoeven wrote:

> Hi Arnd,
> 
> On Sat, Feb 6, 2021 at 3:36 PM Arnd Bergmann <arnd@kernel.org> wrote:
> > That said, I'm still not happy about the patch we discussed in the
> > other email thread[1] and I'd like to handle it a little more strictly in
> > the future, but I agree this wasn't obvious and we have been rather
> > inconsistent about it in the past, with some platform maintainers
> > handling it way more strictly than others.
> >
> > I've added the devicetree maintainers and a few other platform
> > maintainers to Cc here, maybe they can provide some further
> > opinions on the topic so we can come to an approach that
> > works for everyone.
> >
> > My summary of the thread in [1] is there was a driver bug that
> > required a DT binding change. Krzysztof and the other involved
> > parties made sure the driver handles it in a backward-compatible
> > way (an old dtb file will still run into the bug but keep working
> > with new kernels), but decided that they did not need to worry
> > about the opposite case (running an old kernel with an updated
> > dtb). I noticed the compatibility break and said that I would
> > prefer this to be done in a way that is compatible both ways,
> > or at the minimum be alerted about the binding break in the
> > pull request, with an explanation about why this had to be done,
> > even when we don't think anyone is going to be affected.
> >
> > What do others think about this? Should we generally assume
> > that breaking old kernels with new dtbs is acceptable, or should
> > we try to avoid it if possible, the same way we try to avoid
> > breaking new kernels with old dtbs? Should this be a platform
> > specific policy or should we try to handle all platforms the same
> > way?
> 
> For Renesas SoCs, we typically only consider compatibility of new
> kernels with old DTBs, not the other way around.
> However, most DTB updates are due to new hardware support, so using the
> new DTB with an old kernel usually just means no newly documented
> hardware, or new feature, is being used by the old kernel.
> 

This is the case for the Qualcomm tree as well, it's expected that a new
kernel should work with older DT. But, while we don't actively try to
break it, there are plenty of examples where we don't/can't give the
promise in the other direction.

These examples ranges from advancements in power management
(implementation and binding) to DT validation forcing deprecation and
adoption of new bindings.

Regards,
Bjorn

Re: [GIT PULL 2/3] ARM: dts: samsung: DTS for v5.12

[Bjorn Andersson]

On Sat 06 Feb 13:47 CST 2021, Geert Uytterhoeven wrote:

> Hi Arnd,
> 
> On Sat, Feb 6, 2021 at 3:36 PM Arnd Bergmann <arnd@kernel.org> wrote:
> > That said, I'm still not happy about the patch we discussed in the
> > other email thread[1] and I'd like to handle it a little more strictly in
> > the future, but I agree this wasn't obvious and we have been rather
> > inconsistent about it in the past, with some platform maintainers
> > handling it way more strictly than others.
> >
> > I've added the devicetree maintainers and a few other platform
> > maintainers to Cc here, maybe they can provide some further
> > opinions on the topic so we can come to an approach that
> > works for everyone.
> >
> > My summary of the thread in [1] is there was a driver bug that
> > required a DT binding change. Krzysztof and the other involved
> > parties made sure the driver handles it in a backward-compatible
> > way (an old dtb file will still run into the bug but keep working
> > with new kernels), but decided that they did not need to worry
> > about the opposite case (running an old kernel with an updated
> > dtb). I noticed the compatibility break and said that I would
> > prefer this to be done in a way that is compatible both ways,
> > or at the minimum be alerted about the binding break in the
> > pull request, with an explanation about why this had to be done,
> > even when we don't think anyone is going to be affected.
> >
> > What do others think about this? Should we generally assume
> > that breaking old kernels with new dtbs is acceptable, or should
> > we try to avoid it if possible, the same way we try to avoid
> > breaking new kernels with old dtbs? Should this be a platform
> > specific policy or should we try to handle all platforms the same
> > way?
> 
> For Renesas SoCs, we typically only consider compatibility of new
> kernels with old DTBs, not the other way around.
> However, most DTB updates are due to new hardware support, so using the
> new DTB with an old kernel usually just means no newly documented
> hardware, or new feature, is being used by the old kernel.
> 

This is the case for the Qualcomm tree as well, it's expected that a new
kernel should work with older DT. But, while we don't actively try to
break it, there are plenty of examples where we don't/can't give the
promise in the other direction.

These examples ranges from advancements in power management
(implementation and binding) to DT validation forcing deprecation and
adoption of new bindings.

Regards,
Bjorn

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [GIT PULL 2/3] ARM: dts: samsung: DTS for v5.12

[Bjorn Andersson]

On Sat 06 Feb 13:47 CST 2021, Geert Uytterhoeven wrote:

> Hi Arnd,
> 
> On Sat, Feb 6, 2021 at 3:36 PM Arnd Bergmann <arnd@kernel.org> wrote:
> > That said, I'm still not happy about the patch we discussed in the
> > other email thread[1] and I'd like to handle it a little more strictly in
> > the future, but I agree this wasn't obvious and we have been rather
> > inconsistent about it in the past, with some platform maintainers
> > handling it way more strictly than others.
> >
> > I've added the devicetree maintainers and a few other platform
> > maintainers to Cc here, maybe they can provide some further
> > opinions on the topic so we can come to an approach that
> > works for everyone.
> >
> > My summary of the thread in [1] is there was a driver bug that
> > required a DT binding change. Krzysztof and the other involved
> > parties made sure the driver handles it in a backward-compatible
> > way (an old dtb file will still run into the bug but keep working
> > with new kernels), but decided that they did not need to worry
> > about the opposite case (running an old kernel with an updated
> > dtb). I noticed the compatibility break and said that I would
> > prefer this to be done in a way that is compatible both ways,
> > or at the minimum be alerted about the binding break in the
> > pull request, with an explanation about why this had to be done,
> > even when we don't think anyone is going to be affected.
> >
> > What do others think about this? Should we generally assume
> > that breaking old kernels with new dtbs is acceptable, or should
> > we try to avoid it if possible, the same way we try to avoid
> > breaking new kernels with old dtbs? Should this be a platform
> > specific policy or should we try to handle all platforms the same
> > way?
> 
> For Renesas SoCs, we typically only consider compatibility of new
> kernels with old DTBs, not the other way around.
> However, most DTB updates are due to new hardware support, so using the
> new DTB with an old kernel usually just means no newly documented
> hardware, or new feature, is being used by the old kernel.
> 

This is the case for the Qualcomm tree as well, it's expected that a new
kernel should work with older DT. But, while we don't actively try to
break it, there are plenty of examples where we don't/can't give the
promise in the other direction.

These examples ranges from advancements in power management
(implementation and binding) to DT validation forcing deprecation and
adoption of new bindings.

Regards,
Bjorn

Re: [GIT PULL 2/3] ARM: dts: samsung: DTS for v5.12

[Krzysztof Kozlowski]

On Mon, Feb 08, 2021 at 12:21:22PM -0600, Bjorn Andersson wrote:
> On Sat 06 Feb 13:47 CST 2021, Geert Uytterhoeven wrote:
> 
> > Hi Arnd,
> > 
> > On Sat, Feb 6, 2021 at 3:36 PM Arnd Bergmann <arnd@kernel.org> wrote:
> > > That said, I'm still not happy about the patch we discussed in the
> > > other email thread[1] and I'd like to handle it a little more strictly in
> > > the future, but I agree this wasn't obvious and we have been rather
> > > inconsistent about it in the past, with some platform maintainers
> > > handling it way more strictly than others.
> > >
> > > I've added the devicetree maintainers and a few other platform
> > > maintainers to Cc here, maybe they can provide some further
> > > opinions on the topic so we can come to an approach that
> > > works for everyone.
> > >
> > > My summary of the thread in [1] is there was a driver bug that
> > > required a DT binding change. Krzysztof and the other involved
> > > parties made sure the driver handles it in a backward-compatible
> > > way (an old dtb file will still run into the bug but keep working
> > > with new kernels), but decided that they did not need to worry
> > > about the opposite case (running an old kernel with an updated
> > > dtb). I noticed the compatibility break and said that I would
> > > prefer this to be done in a way that is compatible both ways,
> > > or at the minimum be alerted about the binding break in the
> > > pull request, with an explanation about why this had to be done,
> > > even when we don't think anyone is going to be affected.
> > >
> > > What do others think about this? Should we generally assume
> > > that breaking old kernels with new dtbs is acceptable, or should
> > > we try to avoid it if possible, the same way we try to avoid
> > > breaking new kernels with old dtbs? Should this be a platform
> > > specific policy or should we try to handle all platforms the same
> > > way?
> > 
> > For Renesas SoCs, we typically only consider compatibility of new
> > kernels with old DTBs, not the other way around.
> > However, most DTB updates are due to new hardware support, so using the
> > new DTB with an old kernel usually just means no newly documented
> > hardware, or new feature, is being used by the old kernel.
> > 
> 
> This is the case for the Qualcomm tree as well, it's expected that a new
> kernel should work with older DT. But, while we don't actively try to
> break it, there are plenty of examples where we don't/can't give the
> promise in the other direction.

Thanks everyone for comments.

Let me steer the discussion to original topic - it's about old kernel
and new DTB, assuming that mainline kernel bisectability is not
affected.

Flow looks like this:

0. You have existing bidings and drivers.
1. Patch changing bindings (with new compatible) and drivers gets
   accepted by maintainer.
2. Patch above (bindings+drivers) goes during merge window to v5.11-rc1.
3. Patch changing in-tree DTS to new compatible gets accepted by
   maintainer and it is sent as v5.12-rc1 material to SoC maintainers.

So again: old kernel, using old bindings, new DTB.

Another case is where out-of-tree user of bindings, e.g. FreeBSD, takes
new DTS (at point of #3 above or later) but did not take the bindings.
Such system would be broken but it's their fault - they took DTS without
taking the bindings (which were there already for one release!).

Best regards,
Krzysztof

Re: [GIT PULL 2/3] ARM: dts: samsung: DTS for v5.12

[Krzysztof Kozlowski]

On Mon, Feb 08, 2021 at 12:21:22PM -0600, Bjorn Andersson wrote:
> On Sat 06 Feb 13:47 CST 2021, Geert Uytterhoeven wrote:
> 
> > Hi Arnd,
> > 
> > On Sat, Feb 6, 2021 at 3:36 PM Arnd Bergmann <arnd@kernel.org> wrote:
> > > That said, I'm still not happy about the patch we discussed in the
> > > other email thread[1] and I'd like to handle it a little more strictly in
> > > the future, but I agree this wasn't obvious and we have been rather
> > > inconsistent about it in the past, with some platform maintainers
> > > handling it way more strictly than others.
> > >
> > > I've added the devicetree maintainers and a few other platform
> > > maintainers to Cc here, maybe they can provide some further
> > > opinions on the topic so we can come to an approach that
> > > works for everyone.
> > >
> > > My summary of the thread in [1] is there was a driver bug that
> > > required a DT binding change. Krzysztof and the other involved
> > > parties made sure the driver handles it in a backward-compatible
> > > way (an old dtb file will still run into the bug but keep working
> > > with new kernels), but decided that they did not need to worry
> > > about the opposite case (running an old kernel with an updated
> > > dtb). I noticed the compatibility break and said that I would
> > > prefer this to be done in a way that is compatible both ways,
> > > or at the minimum be alerted about the binding break in the
> > > pull request, with an explanation about why this had to be done,
> > > even when we don't think anyone is going to be affected.
> > >
> > > What do others think about this? Should we generally assume
> > > that breaking old kernels with new dtbs is acceptable, or should
> > > we try to avoid it if possible, the same way we try to avoid
> > > breaking new kernels with old dtbs? Should this be a platform
> > > specific policy or should we try to handle all platforms the same
> > > way?
> > 
> > For Renesas SoCs, we typically only consider compatibility of new
> > kernels with old DTBs, not the other way around.
> > However, most DTB updates are due to new hardware support, so using the
> > new DTB with an old kernel usually just means no newly documented
> > hardware, or new feature, is being used by the old kernel.
> > 
> 
> This is the case for the Qualcomm tree as well, it's expected that a new
> kernel should work with older DT. But, while we don't actively try to
> break it, there are plenty of examples where we don't/can't give the
> promise in the other direction.

Thanks everyone for comments.

Let me steer the discussion to original topic - it's about old kernel
and new DTB, assuming that mainline kernel bisectability is not
affected.

Flow looks like this:

0. You have existing bidings and drivers.
1. Patch changing bindings (with new compatible) and drivers gets
   accepted by maintainer.
2. Patch above (bindings+drivers) goes during merge window to v5.11-rc1.
3. Patch changing in-tree DTS to new compatible gets accepted by
   maintainer and it is sent as v5.12-rc1 material to SoC maintainers.

So again: old kernel, using old bindings, new DTB.

Another case is where out-of-tree user of bindings, e.g. FreeBSD, takes
new DTS (at point of #3 above or later) but did not take the bindings.
Such system would be broken but it's their fault - they took DTS without
taking the bindings (which were there already for one release!).

Best regards,
Krzysztof

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [GIT PULL 2/3] ARM: dts: samsung: DTS for v5.12

[Krzysztof Kozlowski]

On Mon, Feb 08, 2021 at 12:21:22PM -0600, Bjorn Andersson wrote:
> On Sat 06 Feb 13:47 CST 2021, Geert Uytterhoeven wrote:
> 
> > Hi Arnd,
> > 
> > On Sat, Feb 6, 2021 at 3:36 PM Arnd Bergmann <arnd@kernel.org> wrote:
> > > That said, I'm still not happy about the patch we discussed in the
> > > other email thread[1] and I'd like to handle it a little more strictly in
> > > the future, but I agree this wasn't obvious and we have been rather
> > > inconsistent about it in the past, with some platform maintainers
> > > handling it way more strictly than others.
> > >
> > > I've added the devicetree maintainers and a few other platform
> > > maintainers to Cc here, maybe they can provide some further
> > > opinions on the topic so we can come to an approach that
> > > works for everyone.
> > >
> > > My summary of the thread in [1] is there was a driver bug that
> > > required a DT binding change. Krzysztof and the other involved
> > > parties made sure the driver handles it in a backward-compatible
> > > way (an old dtb file will still run into the bug but keep working
> > > with new kernels), but decided that they did not need to worry
> > > about the opposite case (running an old kernel with an updated
> > > dtb). I noticed the compatibility break and said that I would
> > > prefer this to be done in a way that is compatible both ways,
> > > or at the minimum be alerted about the binding break in the
> > > pull request, with an explanation about why this had to be done,
> > > even when we don't think anyone is going to be affected.
> > >
> > > What do others think about this? Should we generally assume
> > > that breaking old kernels with new dtbs is acceptable, or should
> > > we try to avoid it if possible, the same way we try to avoid
> > > breaking new kernels with old dtbs? Should this be a platform
> > > specific policy or should we try to handle all platforms the same
> > > way?
> > 
> > For Renesas SoCs, we typically only consider compatibility of new
> > kernels with old DTBs, not the other way around.
> > However, most DTB updates are due to new hardware support, so using the
> > new DTB with an old kernel usually just means no newly documented
> > hardware, or new feature, is being used by the old kernel.
> > 
> 
> This is the case for the Qualcomm tree as well, it's expected that a new
> kernel should work with older DT. But, while we don't actively try to
> break it, there are plenty of examples where we don't/can't give the
> promise in the other direction.

Thanks everyone for comments.

Let me steer the discussion to original topic - it's about old kernel
and new DTB, assuming that mainline kernel bisectability is not
affected.

Flow looks like this:

0. You have existing bidings and drivers.
1. Patch changing bindings (with new compatible) and drivers gets
   accepted by maintainer.
2. Patch above (bindings+drivers) goes during merge window to v5.11-rc1.
3. Patch changing in-tree DTS to new compatible gets accepted by
   maintainer and it is sent as v5.12-rc1 material to SoC maintainers.

So again: old kernel, using old bindings, new DTB.

Another case is where out-of-tree user of bindings, e.g. FreeBSD, takes
new DTS (at point of #3 above or later) but did not take the bindings.
Such system would be broken but it's their fault - they took DTS without
taking the bindings (which were there already for one release!).

Best regards,
Krzysztof

Re: [GIT PULL 2/3] ARM: dts: samsung: DTS for v5.12

[Arnd Bergmann]

On Mon, Feb 8, 2021 at 7:42 PM Krzysztof Kozlowski <krzk@kernel.org> wrote:
> Let me steer the discussion to original topic - it's about old kernel
> and new DTB, assuming that mainline kernel bisectability is not
> affected.
>
> Flow looks like this:
>
> 0. You have existing bidings and drivers.
> 1. Patch changing bindings (with new compatible) and drivers gets
>    accepted by maintainer.
> 2. Patch above (bindings+drivers) goes during merge window to v5.11-rc1.
> 3. Patch changing in-tree DTS to new compatible gets accepted by
>    maintainer and it is sent as v5.12-rc1 material to SoC maintainers.
>
> So again: old kernel, using old bindings, new DTB.
>
> Another case is where out-of-tree user of bindings, e.g. FreeBSD, takes
> new DTS (at point of #3 above or later) but did not take the bindings.
> Such system would be broken but it's their fault - they took DTS without
> taking the bindings (which were there already for one release!).

The particular boot flow that I am worried about here is when the dtb and
kernel are not updated in sync. Traditionally this happens when the dtb
is contained in the firmware image or generated by the firmware, as would
be the case on any server class system, but also on embedded systems
that can run an upstream kernel but without having the dts contributed
into the kernel sources.

When you have this case, you can install a working system, and install
an upgraded kernel without problems. You might then want to update the
firmware as well, in order to take advantage of the features implemented
in the kernel kernel that require a DT description. Again, no problem.

However, once the firmware is updated, it may no longer be possible to
go back to the old kernel in case the new one is busted.

A similar problem can happen with the EBBR boot flow that relies on
a uefi-enabled firmware such as a u-boot, while using grub2 as the
actual boot loader. This is commonly supported across distros. While
grub2 can load a matching set of kernel+initrd+dtb from disk and run
that, this often fails in practice because u-boot needs to fill a
board specific set of DT properties (bootargs, detected memory,
mac address, ...). The usual way this gets handled is that u-boot loads
grub2 and the dtb from disk and then passes the modified dtb to grub,
which picks only kernel+initrd from disk and boots this with the dtb.

The result is similar to case with dtb built into the firmware: after
upgrading the dtb that gets loaded by u-boot, grub can still pick
old kernels but they may not work as they did in the past. There are
obviously ways to work around it, but it does lead to user frustration.

         Arnd

Re: [GIT PULL 2/3] ARM: dts: samsung: DTS for v5.12

[Arnd Bergmann]

On Mon, Feb 8, 2021 at 7:42 PM Krzysztof Kozlowski <krzk@kernel.org> wrote:
> Let me steer the discussion to original topic - it's about old kernel
> and new DTB, assuming that mainline kernel bisectability is not
> affected.
>
> Flow looks like this:
>
> 0. You have existing bidings and drivers.
> 1. Patch changing bindings (with new compatible) and drivers gets
>    accepted by maintainer.
> 2. Patch above (bindings+drivers) goes during merge window to v5.11-rc1.
> 3. Patch changing in-tree DTS to new compatible gets accepted by
>    maintainer and it is sent as v5.12-rc1 material to SoC maintainers.
>
> So again: old kernel, using old bindings, new DTB.
>
> Another case is where out-of-tree user of bindings, e.g. FreeBSD, takes
> new DTS (at point of #3 above or later) but did not take the bindings.
> Such system would be broken but it's their fault - they took DTS without
> taking the bindings (which were there already for one release!).

The particular boot flow that I am worried about here is when the dtb and
kernel are not updated in sync. Traditionally this happens when the dtb
is contained in the firmware image or generated by the firmware, as would
be the case on any server class system, but also on embedded systems
that can run an upstream kernel but without having the dts contributed
into the kernel sources.

When you have this case, you can install a working system, and install
an upgraded kernel without problems. You might then want to update the
firmware as well, in order to take advantage of the features implemented
in the kernel kernel that require a DT description. Again, no problem.

However, once the firmware is updated, it may no longer be possible to
go back to the old kernel in case the new one is busted.

A similar problem can happen with the EBBR boot flow that relies on
a uefi-enabled firmware such as a u-boot, while using grub2 as the
actual boot loader. This is commonly supported across distros. While
grub2 can load a matching set of kernel+initrd+dtb from disk and run
that, this often fails in practice because u-boot needs to fill a
board specific set of DT properties (bootargs, detected memory,
mac address, ...). The usual way this gets handled is that u-boot loads
grub2 and the dtb from disk and then passes the modified dtb to grub,
which picks only kernel+initrd from disk and boots this with the dtb.

The result is similar to case with dtb built into the firmware: after
upgrading the dtb that gets loaded by u-boot, grub can still pick
old kernels but they may not work as they did in the past. There are
obviously ways to work around it, but it does lead to user frustration.

         Arnd

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [GIT PULL 2/3] ARM: dts: samsung: DTS for v5.12

[Alexandre Belloni]

Hello,

On 08/02/2021 20:52:37+0100, Arnd Bergmann wrote:
> On Mon, Feb 8, 2021 at 7:42 PM Krzysztof Kozlowski <krzk@kernel.org> wrote:
> > Let me steer the discussion to original topic - it's about old kernel
> > and new DTB, assuming that mainline kernel bisectability is not
> > affected.
> >
> > Flow looks like this:
> >
> > 0. You have existing bidings and drivers.
> > 1. Patch changing bindings (with new compatible) and drivers gets
> >    accepted by maintainer.
> > 2. Patch above (bindings+drivers) goes during merge window to v5.11-rc1.
> > 3. Patch changing in-tree DTS to new compatible gets accepted by
> >    maintainer and it is sent as v5.12-rc1 material to SoC maintainers.
> >
> > So again: old kernel, using old bindings, new DTB.
> >

I don't think forward compatibility was ever considered. I've seen it
being mentioned a few times on #armlinux but honestly this simply can't
be achieved. This would mean being able to write complete DT bindings
for a particular SoC at day 0 which will realistically never happen. You
may noteven have a complete datasheet and even if you have a datasheet,
it may not be complete or it may be missing hw errata that are
discovered later on and need a new binding to handle.

> > Another case is where out-of-tree user of bindings, e.g. FreeBSD, takes
> > new DTS (at point of #3 above or later) but did not take the bindings.
> > Such system would be broken but it's their fault - they took DTS without
> > taking the bindings (which were there already for one release!).
> 
> The particular boot flow that I am worried about here is when the dtb and
> kernel are not updated in sync. Traditionally this happens when the dtb
> is contained in the firmware image or generated by the firmware, as would
> be the case on any server class system, but also on embedded systems
> that can run an upstream kernel but without having the dts contributed
> into the kernel sources.
> 
> When you have this case, you can install a working system, and install
> an upgraded kernel without problems. You might then want to update the
> firmware as well, in order to take advantage of the features implemented
> in the kernel kernel that require a DT description. Again, no problem.
> 
> However, once the firmware is updated, it may no longer be possible to
> go back to the old kernel in case the new one is busted.
> 

Any serious update strategy will update both the kernel and device tree
at the same time, exactly like you already have to update the initramfs
with the kernel as soon as it is including kernel modules.
I would expect any embedded platform to actually use a container format,
like a FIT image that will ship the kernel, DT and intiramfs in a single
image and will allow to sign all parts.

> A similar problem can happen with the EBBR boot flow that relies on
> a uefi-enabled firmware such as a u-boot, while using grub2 as the
> actual boot loader. This is commonly supported across distros. While
> grub2 can load a matching set of kernel+initrd+dtb from disk and run
> that, this often fails in practice because u-boot needs to fill a
> board specific set of DT properties (bootargs, detected memory,
> mac address, ...). The usual way this gets handled is that u-boot loads
> grub2 and the dtb from disk and then passes the modified dtb to grub,
> which picks only kernel+initrd from disk and boots this with the dtb.
> 
> The result is similar to case with dtb built into the firmware: after
> upgrading the dtb that gets loaded by u-boot, grub can still pick
> old kernels but they may not work as they did in the past. There are
> obviously ways to work around it, but it does lead to user frustration.
> 

Are there really any platforms with the dtb built into the firmware? I
feel like this is a mythical creature used to scare people into keeping
the DTB ABI stable. Aren't all the distribution already able to cope
with keeping DTB and kernel in sync?

-- 
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [GIT PULL 2/3] ARM: dts: samsung: DTS for v5.12

[Alexandre Belloni]

Hello,

On 08/02/2021 20:52:37+0100, Arnd Bergmann wrote:
> On Mon, Feb 8, 2021 at 7:42 PM Krzysztof Kozlowski <krzk@kernel.org> wrote:
> > Let me steer the discussion to original topic - it's about old kernel
> > and new DTB, assuming that mainline kernel bisectability is not
> > affected.
> >
> > Flow looks like this:
> >
> > 0. You have existing bidings and drivers.
> > 1. Patch changing bindings (with new compatible) and drivers gets
> >    accepted by maintainer.
> > 2. Patch above (bindings+drivers) goes during merge window to v5.11-rc1.
> > 3. Patch changing in-tree DTS to new compatible gets accepted by
> >    maintainer and it is sent as v5.12-rc1 material to SoC maintainers.
> >
> > So again: old kernel, using old bindings, new DTB.
> >

I don't think forward compatibility was ever considered. I've seen it
being mentioned a few times on #armlinux but honestly this simply can't
be achieved. This would mean being able to write complete DT bindings
for a particular SoC at day 0 which will realistically never happen. You
may noteven have a complete datasheet and even if you have a datasheet,
it may not be complete or it may be missing hw errata that are
discovered later on and need a new binding to handle.

> > Another case is where out-of-tree user of bindings, e.g. FreeBSD, takes
> > new DTS (at point of #3 above or later) but did not take the bindings.
> > Such system would be broken but it's their fault - they took DTS without
> > taking the bindings (which were there already for one release!).
> 
> The particular boot flow that I am worried about here is when the dtb and
> kernel are not updated in sync. Traditionally this happens when the dtb
> is contained in the firmware image or generated by the firmware, as would
> be the case on any server class system, but also on embedded systems
> that can run an upstream kernel but without having the dts contributed
> into the kernel sources.
> 
> When you have this case, you can install a working system, and install
> an upgraded kernel without problems. You might then want to update the
> firmware as well, in order to take advantage of the features implemented
> in the kernel kernel that require a DT description. Again, no problem.
> 
> However, once the firmware is updated, it may no longer be possible to
> go back to the old kernel in case the new one is busted.
> 

Any serious update strategy will update both the kernel and device tree
at the same time, exactly like you already have to update the initramfs
with the kernel as soon as it is including kernel modules.
I would expect any embedded platform to actually use a container format,
like a FIT image that will ship the kernel, DT and intiramfs in a single
image and will allow to sign all parts.

> A similar problem can happen with the EBBR boot flow that relies on
> a uefi-enabled firmware such as a u-boot, while using grub2 as the
> actual boot loader. This is commonly supported across distros. While
> grub2 can load a matching set of kernel+initrd+dtb from disk and run
> that, this often fails in practice because u-boot needs to fill a
> board specific set of DT properties (bootargs, detected memory,
> mac address, ...). The usual way this gets handled is that u-boot loads
> grub2 and the dtb from disk and then passes the modified dtb to grub,
> which picks only kernel+initrd from disk and boots this with the dtb.
> 
> The result is similar to case with dtb built into the firmware: after
> upgrading the dtb that gets loaded by u-boot, grub can still pick
> old kernels but they may not work as they did in the past. There are
> obviously ways to work around it, but it does lead to user frustration.
> 

Are there really any platforms with the dtb built into the firmware? I
feel like this is a mythical creature used to scare people into keeping
the DTB ABI stable. Aren't all the distribution already able to cope
with keeping DTB and kernel in sync?

-- 
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [GIT PULL 2/3] ARM: dts: samsung: DTS for v5.12

[Alexandre Belloni]

Hello,

On 08/02/2021 20:52:37+0100, Arnd Bergmann wrote:
> On Mon, Feb 8, 2021 at 7:42 PM Krzysztof Kozlowski <krzk@kernel.org> wrote:
> > Let me steer the discussion to original topic - it's about old kernel
> > and new DTB, assuming that mainline kernel bisectability is not
> > affected.
> >
> > Flow looks like this:
> >
> > 0. You have existing bidings and drivers.
> > 1. Patch changing bindings (with new compatible) and drivers gets
> >    accepted by maintainer.
> > 2. Patch above (bindings+drivers) goes during merge window to v5.11-rc1.
> > 3. Patch changing in-tree DTS to new compatible gets accepted by
> >    maintainer and it is sent as v5.12-rc1 material to SoC maintainers.
> >
> > So again: old kernel, using old bindings, new DTB.
> >

I don't think forward compatibility was ever considered. I've seen it
being mentioned a few times on #armlinux but honestly this simply can't
be achieved. This would mean being able to write complete DT bindings
for a particular SoC at day 0 which will realistically never happen. You
may noteven have a complete datasheet and even if you have a datasheet,
it may not be complete or it may be missing hw errata that are
discovered later on and need a new binding to handle.

> > Another case is where out-of-tree user of bindings, e.g. FreeBSD, takes
> > new DTS (at point of #3 above or later) but did not take the bindings.
> > Such system would be broken but it's their fault - they took DTS without
> > taking the bindings (which were there already for one release!).
> 
> The particular boot flow that I am worried about here is when the dtb and
> kernel are not updated in sync. Traditionally this happens when the dtb
> is contained in the firmware image or generated by the firmware, as would
> be the case on any server class system, but also on embedded systems
> that can run an upstream kernel but without having the dts contributed
> into the kernel sources.
> 
> When you have this case, you can install a working system, and install
> an upgraded kernel without problems. You might then want to update the
> firmware as well, in order to take advantage of the features implemented
> in the kernel kernel that require a DT description. Again, no problem.
> 
> However, once the firmware is updated, it may no longer be possible to
> go back to the old kernel in case the new one is busted.
> 

Any serious update strategy will update both the kernel and device tree
at the same time, exactly like you already have to update the initramfs
with the kernel as soon as it is including kernel modules.
I would expect any embedded platform to actually use a container format,
like a FIT image that will ship the kernel, DT and intiramfs in a single
image and will allow to sign all parts.

> A similar problem can happen with the EBBR boot flow that relies on
> a uefi-enabled firmware such as a u-boot, while using grub2 as the
> actual boot loader. This is commonly supported across distros. While
> grub2 can load a matching set of kernel+initrd+dtb from disk and run
> that, this often fails in practice because u-boot needs to fill a
> board specific set of DT properties (bootargs, detected memory,
> mac address, ...). The usual way this gets handled is that u-boot loads
> grub2 and the dtb from disk and then passes the modified dtb to grub,
> which picks only kernel+initrd from disk and boots this with the dtb.
> 
> The result is similar to case with dtb built into the firmware: after
> upgrading the dtb that gets loaded by u-boot, grub can still pick
> old kernels but they may not work as they did in the past. There are
> obviously ways to work around it, but it does lead to user frustration.
> 

Are there really any platforms with the dtb built into the firmware? I
feel like this is a mythical creature used to scare people into keeping
the DTB ABI stable. Aren't all the distribution already able to cope
with keeping DTB and kernel in sync?

-- 
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [GIT PULL 2/3] ARM: dts: samsung: DTS for v5.12

[Arnd Bergmann]

On Mon, Feb 8, 2021 at 10:35 PM Alexandre Belloni
<alexandre.belloni@bootlin.com> wrote:
> On 08/02/2021 20:52:37+0100, Arnd Bergmann wrote:
> > On Mon, Feb 8, 2021 at 7:42 PM Krzysztof Kozlowski <krzk@kernel.org> wrote:
> > > Let me steer the discussion to original topic - it's about old kernel
> > > and new DTB, assuming that mainline kernel bisectability is not
> > > affected.
> > >
> > > Flow looks like this:
> > >
> > > 0. You have existing bidings and drivers.
> > > 1. Patch changing bindings (with new compatible) and drivers gets
> > >    accepted by maintainer.
> > > 2. Patch above (bindings+drivers) goes during merge window to v5.11-rc1.
> > > 3. Patch changing in-tree DTS to new compatible gets accepted by
> > >    maintainer and it is sent as v5.12-rc1 material to SoC maintainers.
> > >
> > > So again: old kernel, using old bindings, new DTB.
> > >
>
> I don't think forward compatibility was ever considered. I've seen it
> being mentioned a few times on #armlinux but honestly this simply can't
> be achieved. This would mean being able to write complete DT bindings
> for a particular SoC at day 0 which will realistically never happen. You
> may noteven have a complete datasheet and even if you have a datasheet,
> it may not be complete or it may be missing hw errata that are
> discovered later on and need a new binding to handle.

You do not have to write the correct DT for this, the only requirement
is that any changes to a node are backward-compatible, which is
typically the case if you add properties or compatible strings without
removing the old one. A bugfix in this case is also backward-compatible.

The part that can not happen instead is to write a DT that can expose
features that any future kernel will use.

> >
> > However, once the firmware is updated, it may no longer be possible to
> > go back to the old kernel in case the new one is busted.
> >
>
> Any serious update strategy will update both the kernel and device tree
> at the same time, exactly like you already have to update the initramfs
> with the kernel as soon as it is including kernel modules.
> I would expect any embedded platform to actually use a container format,
> like a FIT image that will ship the kernel, DT and intiramfs in a single
> image and will allow to sign all parts.

Embedded systems that do this have no requirement for backward
or forward compatibility at all, the only requirement for these is bisectability
of git commits.

> > A similar problem can happen with the EBBR boot flow that relies on
> > a uefi-enabled firmware such as a u-boot, while using grub2 as the
> > actual boot loader. This is commonly supported across distros. While
> > grub2 can load a matching set of kernel+initrd+dtb from disk and run
> > that, this often fails in practice because u-boot needs to fill a
> > board specific set of DT properties (bootargs, detected memory,
> > mac address, ...). The usual way this gets handled is that u-boot loads
> > grub2 and the dtb from disk and then passes the modified dtb to grub,
> > which picks only kernel+initrd from disk and boots this with the dtb.
> >
> > The result is similar to case with dtb built into the firmware: after
> > upgrading the dtb that gets loaded by u-boot, grub can still pick
> > old kernels but they may not work as they did in the past. There are
> > obviously ways to work around it, but it does lead to user frustration.
> >
>
> Are there really any platforms with the dtb built into the firmware?
> I feel like this is a mythical creature used to scare people into keeping
> the DTB ABI stable. Aren't all the distribution already able to cope
> with keeping DTB and kernel in sync?

I think most traditional PowerPC systems fall into this category, most
systems that boot using UEFI+grub (as I explained), and anyone who
uses a distro kernel on custom hardware with their own dtb.

       Arnd

Re: [GIT PULL 2/3] ARM: dts: samsung: DTS for v5.12

[Arnd Bergmann]

On Mon, Feb 8, 2021 at 10:35 PM Alexandre Belloni
<alexandre.belloni@bootlin.com> wrote:
> On 08/02/2021 20:52:37+0100, Arnd Bergmann wrote:
> > On Mon, Feb 8, 2021 at 7:42 PM Krzysztof Kozlowski <krzk@kernel.org> wrote:
> > > Let me steer the discussion to original topic - it's about old kernel
> > > and new DTB, assuming that mainline kernel bisectability is not
> > > affected.
> > >
> > > Flow looks like this:
> > >
> > > 0. You have existing bidings and drivers.
> > > 1. Patch changing bindings (with new compatible) and drivers gets
> > >    accepted by maintainer.
> > > 2. Patch above (bindings+drivers) goes during merge window to v5.11-rc1.
> > > 3. Patch changing in-tree DTS to new compatible gets accepted by
> > >    maintainer and it is sent as v5.12-rc1 material to SoC maintainers.
> > >
> > > So again: old kernel, using old bindings, new DTB.
> > >
>
> I don't think forward compatibility was ever considered. I've seen it
> being mentioned a few times on #armlinux but honestly this simply can't
> be achieved. This would mean being able to write complete DT bindings
> for a particular SoC at day 0 which will realistically never happen. You
> may noteven have a complete datasheet and even if you have a datasheet,
> it may not be complete or it may be missing hw errata that are
> discovered later on and need a new binding to handle.

You do not have to write the correct DT for this, the only requirement
is that any changes to a node are backward-compatible, which is
typically the case if you add properties or compatible strings without
removing the old one. A bugfix in this case is also backward-compatible.

The part that can not happen instead is to write a DT that can expose
features that any future kernel will use.

> >
> > However, once the firmware is updated, it may no longer be possible to
> > go back to the old kernel in case the new one is busted.
> >
>
> Any serious update strategy will update both the kernel and device tree
> at the same time, exactly like you already have to update the initramfs
> with the kernel as soon as it is including kernel modules.
> I would expect any embedded platform to actually use a container format,
> like a FIT image that will ship the kernel, DT and intiramfs in a single
> image and will allow to sign all parts.

Embedded systems that do this have no requirement for backward
or forward compatibility at all, the only requirement for these is bisectability
of git commits.

> > A similar problem can happen with the EBBR boot flow that relies on
> > a uefi-enabled firmware such as a u-boot, while using grub2 as the
> > actual boot loader. This is commonly supported across distros. While
> > grub2 can load a matching set of kernel+initrd+dtb from disk and run
> > that, this often fails in practice because u-boot needs to fill a
> > board specific set of DT properties (bootargs, detected memory,
> > mac address, ...). The usual way this gets handled is that u-boot loads
> > grub2 and the dtb from disk and then passes the modified dtb to grub,
> > which picks only kernel+initrd from disk and boots this with the dtb.
> >
> > The result is similar to case with dtb built into the firmware: after
> > upgrading the dtb that gets loaded by u-boot, grub can still pick
> > old kernels but they may not work as they did in the past. There are
> > obviously ways to work around it, but it does lead to user frustration.
> >
>
> Are there really any platforms with the dtb built into the firmware?
> I feel like this is a mythical creature used to scare people into keeping
> the DTB ABI stable. Aren't all the distribution already able to cope
> with keeping DTB and kernel in sync?

I think most traditional PowerPC systems fall into this category, most
systems that boot using UEFI+grub (as I explained), and anyone who
uses a distro kernel on custom hardware with their own dtb.

       Arnd

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [GIT PULL 2/3] ARM: dts: samsung: DTS for v5.12

[Alexandre Belloni]

On 08/02/2021 23:14:02+0100, Arnd Bergmann wrote:
> On Mon, Feb 8, 2021 at 10:35 PM Alexandre Belloni
> <alexandre.belloni@bootlin.com> wrote:
> > On 08/02/2021 20:52:37+0100, Arnd Bergmann wrote:
> > > On Mon, Feb 8, 2021 at 7:42 PM Krzysztof Kozlowski <krzk@kernel.org> wrote:
> > > > Let me steer the discussion to original topic - it's about old kernel
> > > > and new DTB, assuming that mainline kernel bisectability is not
> > > > affected.
> > > >
> > > > Flow looks like this:
> > > >
> > > > 0. You have existing bidings and drivers.
> > > > 1. Patch changing bindings (with new compatible) and drivers gets
> > > >    accepted by maintainer.
> > > > 2. Patch above (bindings+drivers) goes during merge window to v5.11-rc1.
> > > > 3. Patch changing in-tree DTS to new compatible gets accepted by
> > > >    maintainer and it is sent as v5.12-rc1 material to SoC maintainers.
> > > >
> > > > So again: old kernel, using old bindings, new DTB.
> > > >
> >
> > I don't think forward compatibility was ever considered. I've seen it
> > being mentioned a few times on #armlinux but honestly this simply can't
> > be achieved. This would mean being able to write complete DT bindings
> > for a particular SoC at day 0 which will realistically never happen. You
> > may noteven have a complete datasheet and even if you have a datasheet,
> > it may not be complete or it may be missing hw errata that are
> > discovered later on and need a new binding to handle.
> 
> You do not have to write the correct DT for this, the only requirement
> is that any changes to a node are backward-compatible, which is
> typically the case if you add properties or compatible strings without
> removing the old one. A bugfix in this case is also backward-compatible.
> 
> The part that can not happen instead is to write a DT that can expose
> features that any future kernel will use.
> 

But I think we are speaking about the other way around were you would be
e.g. removing properties or splitting a node is multiple different
nodes following a different understanding of the hardware.
And in this case, any rework of the bindings will be forbidden, like
32b7cfbd4bb2 ("ARM: dts: at91: remove deprecated ADC properties") will
break older kernels trying to use the new dtb.
761f6ed85417 ("ARM: dts: at91: sama5d4: use correct rtc compatible") is
an other case.
I'm not sure want to keep the older properties or the older compatible
string as a fallback for this use case.

> > > However, once the firmware is updated, it may no longer be possible to
> > > go back to the old kernel in case the new one is busted.
> > >
> >
> > Any serious update strategy will update both the kernel and device tree
> > at the same time, exactly like you already have to update the initramfs
> > with the kernel as soon as it is including kernel modules.
> > I would expect any embedded platform to actually use a container format,
> > like a FIT image that will ship the kernel, DT and intiramfs in a single
> > image and will allow to sign all parts.
> 
> Embedded systems that do this have no requirement for backward
> or forward compatibility at all, the only requirement for these is bisectability
> of git commits.
> 

Yes and I can't see any drawbacks in this approach.

> > > A similar problem can happen with the EBBR boot flow that relies on
> > > a uefi-enabled firmware such as a u-boot, while using grub2 as the
> > > actual boot loader. This is commonly supported across distros. While
> > > grub2 can load a matching set of kernel+initrd+dtb from disk and run
> > > that, this often fails in practice because u-boot needs to fill a
> > > board specific set of DT properties (bootargs, detected memory,
> > > mac address, ...). The usual way this gets handled is that u-boot loads
> > > grub2 and the dtb from disk and then passes the modified dtb to grub,
> > > which picks only kernel+initrd from disk and boots this with the dtb.
> > >
> > > The result is similar to case with dtb built into the firmware: after
> > > upgrading the dtb that gets loaded by u-boot, grub can still pick
> > > old kernels but they may not work as they did in the past. There are
> > > obviously ways to work around it, but it does lead to user frustration.
> > >
> >
> > Are there really any platforms with the dtb built into the firmware?
> > I feel like this is a mythical creature used to scare people into keeping
> > the DTB ABI stable. Aren't all the distribution already able to cope
> > with keeping DTB and kernel in sync?
> 
> I think most traditional PowerPC systems fall into this category, most

My understanding was that the traditional PPC systems had a small device
tree and usually are not affected by driver changes but I may be wrong.

> systems that boot using UEFI+grub (as I explained), and anyone who
> uses a distro kernel on custom hardware with their own dtb.
> 

Aren't the ones using a distro kernel with a custom dtb more concerned
by backward compatibility (i.e. new kernel with old dtb) rather than old
kernel on new dtb? If they have an old dtb, an old kernel, and update to
a new kernel, backward compatibility will ensure this continues to work.
If then they work on updating their dtb, they still have the old one and
can make the distribution match dtb and kernel. This is already handled
properly by debian and I guess the other distributions as it is anyway
already matching kernel and initramfs.

This is what I have on my NAS:

$ ls /boot
config-4.12.0-1-marvell  initrd.img-4.12.0-1-marvell  uImage.bak
config-4.13.0-1-marvell  initrd.img-4.13.0-1-marvell  uInitrd
dtb                      initrd.img.old               uInitrd.bak
dtb-4.12.0-1-marvell     lost+found                   vmlinuz
dtb-4.13.0-1-marvell     System.map-4.12.0-1-marvell  vmlinuz-4.12.0-1-marvell
dtbs                     System.map-4.13.0-1-marvell  vmlinuz-4.13.0-1-marvell
initrd.img               uImage                       vmlinuz.old

So dtbs and kernels are already matching even when the dtbs didn't
change between 4.9 and 4.13.

I don't have any solution for the UEFI+grub use case but I will also
question the sanity of doing that ;)

-- 
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [GIT PULL 2/3] ARM: dts: samsung: DTS for v5.12

[Alexandre Belloni]

On 08/02/2021 23:14:02+0100, Arnd Bergmann wrote:
> On Mon, Feb 8, 2021 at 10:35 PM Alexandre Belloni
> <alexandre.belloni@bootlin.com> wrote:
> > On 08/02/2021 20:52:37+0100, Arnd Bergmann wrote:
> > > On Mon, Feb 8, 2021 at 7:42 PM Krzysztof Kozlowski <krzk@kernel.org> wrote:
> > > > Let me steer the discussion to original topic - it's about old kernel
> > > > and new DTB, assuming that mainline kernel bisectability is not
> > > > affected.
> > > >
> > > > Flow looks like this:
> > > >
> > > > 0. You have existing bidings and drivers.
> > > > 1. Patch changing bindings (with new compatible) and drivers gets
> > > >    accepted by maintainer.
> > > > 2. Patch above (bindings+drivers) goes during merge window to v5.11-rc1.
> > > > 3. Patch changing in-tree DTS to new compatible gets accepted by
> > > >    maintainer and it is sent as v5.12-rc1 material to SoC maintainers.
> > > >
> > > > So again: old kernel, using old bindings, new DTB.
> > > >
> >
> > I don't think forward compatibility was ever considered. I've seen it
> > being mentioned a few times on #armlinux but honestly this simply can't
> > be achieved. This would mean being able to write complete DT bindings
> > for a particular SoC at day 0 which will realistically never happen. You
> > may noteven have a complete datasheet and even if you have a datasheet,
> > it may not be complete or it may be missing hw errata that are
> > discovered later on and need a new binding to handle.
> 
> You do not have to write the correct DT for this, the only requirement
> is that any changes to a node are backward-compatible, which is
> typically the case if you add properties or compatible strings without
> removing the old one. A bugfix in this case is also backward-compatible.
> 
> The part that can not happen instead is to write a DT that can expose
> features that any future kernel will use.
> 

But I think we are speaking about the other way around were you would be
e.g. removing properties or splitting a node is multiple different
nodes following a different understanding of the hardware.
And in this case, any rework of the bindings will be forbidden, like
32b7cfbd4bb2 ("ARM: dts: at91: remove deprecated ADC properties") will
break older kernels trying to use the new dtb.
761f6ed85417 ("ARM: dts: at91: sama5d4: use correct rtc compatible") is
an other case.
I'm not sure want to keep the older properties or the older compatible
string as a fallback for this use case.

> > > However, once the firmware is updated, it may no longer be possible to
> > > go back to the old kernel in case the new one is busted.
> > >
> >
> > Any serious update strategy will update both the kernel and device tree
> > at the same time, exactly like you already have to update the initramfs
> > with the kernel as soon as it is including kernel modules.
> > I would expect any embedded platform to actually use a container format,
> > like a FIT image that will ship the kernel, DT and intiramfs in a single
> > image and will allow to sign all parts.
> 
> Embedded systems that do this have no requirement for backward
> or forward compatibility at all, the only requirement for these is bisectability
> of git commits.
> 

Yes and I can't see any drawbacks in this approach.

> > > A similar problem can happen with the EBBR boot flow that relies on
> > > a uefi-enabled firmware such as a u-boot, while using grub2 as the
> > > actual boot loader. This is commonly supported across distros. While
> > > grub2 can load a matching set of kernel+initrd+dtb from disk and run
> > > that, this often fails in practice because u-boot needs to fill a
> > > board specific set of DT properties (bootargs, detected memory,
> > > mac address, ...). The usual way this gets handled is that u-boot loads
> > > grub2 and the dtb from disk and then passes the modified dtb to grub,
> > > which picks only kernel+initrd from disk and boots this with the dtb.
> > >
> > > The result is similar to case with dtb built into the firmware: after
> > > upgrading the dtb that gets loaded by u-boot, grub can still pick
> > > old kernels but they may not work as they did in the past. There are
> > > obviously ways to work around it, but it does lead to user frustration.
> > >
> >
> > Are there really any platforms with the dtb built into the firmware?
> > I feel like this is a mythical creature used to scare people into keeping
> > the DTB ABI stable. Aren't all the distribution already able to cope
> > with keeping DTB and kernel in sync?
> 
> I think most traditional PowerPC systems fall into this category, most

My understanding was that the traditional PPC systems had a small device
tree and usually are not affected by driver changes but I may be wrong.

> systems that boot using UEFI+grub (as I explained), and anyone who
> uses a distro kernel on custom hardware with their own dtb.
> 

Aren't the ones using a distro kernel with a custom dtb more concerned
by backward compatibility (i.e. new kernel with old dtb) rather than old
kernel on new dtb? If they have an old dtb, an old kernel, and update to
a new kernel, backward compatibility will ensure this continues to work.
If then they work on updating their dtb, they still have the old one and
can make the distribution match dtb and kernel. This is already handled
properly by debian and I guess the other distributions as it is anyway
already matching kernel and initramfs.

This is what I have on my NAS:

$ ls /boot
config-4.12.0-1-marvell  initrd.img-4.12.0-1-marvell  uImage.bak
config-4.13.0-1-marvell  initrd.img-4.13.0-1-marvell  uInitrd
dtb                      initrd.img.old               uInitrd.bak
dtb-4.12.0-1-marvell     lost+found                   vmlinuz
dtb-4.13.0-1-marvell     System.map-4.12.0-1-marvell  vmlinuz-4.12.0-1-marvell
dtbs                     System.map-4.13.0-1-marvell  vmlinuz-4.13.0-1-marvell
initrd.img               uImage                       vmlinuz.old

So dtbs and kernels are already matching even when the dtbs didn't
change between 4.9 and 4.13.

I don't have any solution for the UEFI+grub use case but I will also
question the sanity of doing that ;)

-- 
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [GIT PULL 2/3] ARM: dts: samsung: DTS for v5.12

[Alexandre Belloni]

On 08/02/2021 23:14:02+0100, Arnd Bergmann wrote:
> On Mon, Feb 8, 2021 at 10:35 PM Alexandre Belloni
> <alexandre.belloni@bootlin.com> wrote:
> > On 08/02/2021 20:52:37+0100, Arnd Bergmann wrote:
> > > On Mon, Feb 8, 2021 at 7:42 PM Krzysztof Kozlowski <krzk@kernel.org> wrote:
> > > > Let me steer the discussion to original topic - it's about old kernel
> > > > and new DTB, assuming that mainline kernel bisectability is not
> > > > affected.
> > > >
> > > > Flow looks like this:
> > > >
> > > > 0. You have existing bidings and drivers.
> > > > 1. Patch changing bindings (with new compatible) and drivers gets
> > > >    accepted by maintainer.
> > > > 2. Patch above (bindings+drivers) goes during merge window to v5.11-rc1.
> > > > 3. Patch changing in-tree DTS to new compatible gets accepted by
> > > >    maintainer and it is sent as v5.12-rc1 material to SoC maintainers.
> > > >
> > > > So again: old kernel, using old bindings, new DTB.
> > > >
> >
> > I don't think forward compatibility was ever considered. I've seen it
> > being mentioned a few times on #armlinux but honestly this simply can't
> > be achieved. This would mean being able to write complete DT bindings
> > for a particular SoC at day 0 which will realistically never happen. You
> > may noteven have a complete datasheet and even if you have a datasheet,
> > it may not be complete or it may be missing hw errata that are
> > discovered later on and need a new binding to handle.
> 
> You do not have to write the correct DT for this, the only requirement
> is that any changes to a node are backward-compatible, which is
> typically the case if you add properties or compatible strings without
> removing the old one. A bugfix in this case is also backward-compatible.
> 
> The part that can not happen instead is to write a DT that can expose
> features that any future kernel will use.
> 

But I think we are speaking about the other way around were you would be
e.g. removing properties or splitting a node is multiple different
nodes following a different understanding of the hardware.
And in this case, any rework of the bindings will be forbidden, like
32b7cfbd4bb2 ("ARM: dts: at91: remove deprecated ADC properties") will
break older kernels trying to use the new dtb.
761f6ed85417 ("ARM: dts: at91: sama5d4: use correct rtc compatible") is
an other case.
I'm not sure want to keep the older properties or the older compatible
string as a fallback for this use case.

> > > However, once the firmware is updated, it may no longer be possible to
> > > go back to the old kernel in case the new one is busted.
> > >
> >
> > Any serious update strategy will update both the kernel and device tree
> > at the same time, exactly like you already have to update the initramfs
> > with the kernel as soon as it is including kernel modules.
> > I would expect any embedded platform to actually use a container format,
> > like a FIT image that will ship the kernel, DT and intiramfs in a single
> > image and will allow to sign all parts.
> 
> Embedded systems that do this have no requirement for backward
> or forward compatibility at all, the only requirement for these is bisectability
> of git commits.
> 

Yes and I can't see any drawbacks in this approach.

> > > A similar problem can happen with the EBBR boot flow that relies on
> > > a uefi-enabled firmware such as a u-boot, while using grub2 as the
> > > actual boot loader. This is commonly supported across distros. While
> > > grub2 can load a matching set of kernel+initrd+dtb from disk and run
> > > that, this often fails in practice because u-boot needs to fill a
> > > board specific set of DT properties (bootargs, detected memory,
> > > mac address, ...). The usual way this gets handled is that u-boot loads
> > > grub2 and the dtb from disk and then passes the modified dtb to grub,
> > > which picks only kernel+initrd from disk and boots this with the dtb.
> > >
> > > The result is similar to case with dtb built into the firmware: after
> > > upgrading the dtb that gets loaded by u-boot, grub can still pick
> > > old kernels but they may not work as they did in the past. There are
> > > obviously ways to work around it, but it does lead to user frustration.
> > >
> >
> > Are there really any platforms with the dtb built into the firmware?
> > I feel like this is a mythical creature used to scare people into keeping
> > the DTB ABI stable. Aren't all the distribution already able to cope
> > with keeping DTB and kernel in sync?
> 
> I think most traditional PowerPC systems fall into this category, most

My understanding was that the traditional PPC systems had a small device
tree and usually are not affected by driver changes but I may be wrong.

> systems that boot using UEFI+grub (as I explained), and anyone who
> uses a distro kernel on custom hardware with their own dtb.
> 

Aren't the ones using a distro kernel with a custom dtb more concerned
by backward compatibility (i.e. new kernel with old dtb) rather than old
kernel on new dtb? If they have an old dtb, an old kernel, and update to
a new kernel, backward compatibility will ensure this continues to work.
If then they work on updating their dtb, they still have the old one and
can make the distribution match dtb and kernel. This is already handled
properly by debian and I guess the other distributions as it is anyway
already matching kernel and initramfs.

This is what I have on my NAS:

$ ls /boot
config-4.12.0-1-marvell  initrd.img-4.12.0-1-marvell  uImage.bak
config-4.13.0-1-marvell  initrd.img-4.13.0-1-marvell  uInitrd
dtb                      initrd.img.old               uInitrd.bak
dtb-4.12.0-1-marvell     lost+found                   vmlinuz
dtb-4.13.0-1-marvell     System.map-4.12.0-1-marvell  vmlinuz-4.12.0-1-marvell
dtbs                     System.map-4.13.0-1-marvell  vmlinuz-4.13.0-1-marvell
initrd.img               uImage                       vmlinuz.old

So dtbs and kernels are already matching even when the dtbs didn't
change between 4.9 and 4.13.

I don't have any solution for the UEFI+grub use case but I will also
question the sanity of doing that ;)

-- 
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [GIT PULL 2/3] ARM: dts: samsung: DTS for v5.12

[Geert Uytterhoeven]

Hi Alexandre,

On Tue, Feb 9, 2021 at 12:10 AM Alexandre Belloni
<alexandre.belloni@bootlin.com> wrote:
> On 08/02/2021 23:14:02+0100, Arnd Bergmann wrote:
> > On Mon, Feb 8, 2021 at 10:35 PM Alexandre Belloni
> > <alexandre.belloni@bootlin.com> wrote:
> > > Are there really any platforms with the dtb built into the firmware?
> > > I feel like this is a mythical creature used to scare people into keeping
> > > the DTB ABI stable. Aren't all the distribution already able to cope
> > > with keeping DTB and kernel in sync?
> >
> > I think most traditional PowerPC systems fall into this category, most
>
> My understanding was that the traditional PPC systems had a small device
> tree and usually are not affected by driver changes but I may be wrong.

They were much simpler than a modern SoC, with most functionality
implemented by modularity (e.g. PCI devices, I still like 'compatible
= "pci1186,100"'[1] ;-)
And the bindings were simple and stable (i.e. they did exist before the
platform was shipped).

[1] http://users.telenet.be/geertu/Linux/PPC/pci/ethernetAT4/

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [GIT PULL 2/3] ARM: dts: samsung: DTS for v5.12

[Geert Uytterhoeven]

Hi Alexandre,

On Tue, Feb 9, 2021 at 12:10 AM Alexandre Belloni
<alexandre.belloni@bootlin.com> wrote:
> On 08/02/2021 23:14:02+0100, Arnd Bergmann wrote:
> > On Mon, Feb 8, 2021 at 10:35 PM Alexandre Belloni
> > <alexandre.belloni@bootlin.com> wrote:
> > > Are there really any platforms with the dtb built into the firmware?
> > > I feel like this is a mythical creature used to scare people into keeping
> > > the DTB ABI stable. Aren't all the distribution already able to cope
> > > with keeping DTB and kernel in sync?
> >
> > I think most traditional PowerPC systems fall into this category, most
>
> My understanding was that the traditional PPC systems had a small device
> tree and usually are not affected by driver changes but I may be wrong.

They were much simpler than a modern SoC, with most functionality
implemented by modularity (e.g. PCI devices, I still like 'compatible
= "pci1186,100"'[1] ;-)
And the bindings were simple and stable (i.e. they did exist before the
platform was shipped).

[1] http://users.telenet.be/geertu/Linux/PPC/pci/ethernetAT4/

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [GIT PULL 2/3] ARM: dts: samsung: DTS for v5.12

[Geert Uytterhoeven]

Hi Alexandre,

On Tue, Feb 9, 2021 at 12:10 AM Alexandre Belloni
<alexandre.belloni@bootlin.com> wrote:
> On 08/02/2021 23:14:02+0100, Arnd Bergmann wrote:
> > On Mon, Feb 8, 2021 at 10:35 PM Alexandre Belloni
> > <alexandre.belloni@bootlin.com> wrote:
> > > Are there really any platforms with the dtb built into the firmware?
> > > I feel like this is a mythical creature used to scare people into keeping
> > > the DTB ABI stable. Aren't all the distribution already able to cope
> > > with keeping DTB and kernel in sync?
> >
> > I think most traditional PowerPC systems fall into this category, most
>
> My understanding was that the traditional PPC systems had a small device
> tree and usually are not affected by driver changes but I may be wrong.

They were much simpler than a modern SoC, with most functionality
implemented by modularity (e.g. PCI devices, I still like 'compatible
= "pci1186,100"'[1] ;-)
And the bindings were simple and stable (i.e. they did exist before the
platform was shipped).

[1] http://users.telenet.be/geertu/Linux/PPC/pci/ethernetAT4/

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [GIT PULL 2/3] ARM: dts: samsung: DTS for v5.12

[Rob Herring]

On Mon, Feb 8, 2021 at 5:10 PM Alexandre Belloni
<alexandre.belloni@bootlin.com> wrote:
>
> On 08/02/2021 23:14:02+0100, Arnd Bergmann wrote:
> > On Mon, Feb 8, 2021 at 10:35 PM Alexandre Belloni
> > <alexandre.belloni@bootlin.com> wrote:
> > > On 08/02/2021 20:52:37+0100, Arnd Bergmann wrote:
> > > > On Mon, Feb 8, 2021 at 7:42 PM Krzysztof Kozlowski <krzk@kernel.org> wrote:
> > > > > Let me steer the discussion to original topic - it's about old kernel
> > > > > and new DTB, assuming that mainline kernel bisectability is not
> > > > > affected.
> > > > >
> > > > > Flow looks like this:
> > > > >
> > > > > 0. You have existing bidings and drivers.
> > > > > 1. Patch changing bindings (with new compatible) and drivers gets
> > > > >    accepted by maintainer.
> > > > > 2. Patch above (bindings+drivers) goes during merge window to v5.11-rc1.
> > > > > 3. Patch changing in-tree DTS to new compatible gets accepted by
> > > > >    maintainer and it is sent as v5.12-rc1 material to SoC maintainers.
> > > > >
> > > > > So again: old kernel, using old bindings, new DTB.
> > > > >
> > >
> > > I don't think forward compatibility was ever considered. I've seen it
> > > being mentioned a few times on #armlinux but honestly this simply can't
> > > be achieved. This would mean being able to write complete DT bindings
> > > for a particular SoC at day 0 which will realistically never happen. You
> > > may noteven have a complete datasheet and even if you have a datasheet,
> > > it may not be complete or it may be missing hw errata that are
> > > discovered later on and need a new binding to handle.
> >
> > You do not have to write the correct DT for this, the only requirement
> > is that any changes to a node are backward-compatible, which is
> > typically the case if you add properties or compatible strings without
> > removing the old one. A bugfix in this case is also backward-compatible.
> >
> > The part that can not happen instead is to write a DT that can expose
> > features that any future kernel will use.
> >
>
> But I think we are speaking about the other way around were you would be
> e.g. removing properties or splitting a node is multiple different
> nodes following a different understanding of the hardware.
> And in this case, any rework of the bindings will be forbidden, like
> 32b7cfbd4bb2 ("ARM: dts: at91: remove deprecated ADC properties") will
> break older kernels trying to use the new dtb.
> 761f6ed85417 ("ARM: dts: at91: sama5d4: use correct rtc compatible") is
> an other case.
> I'm not sure want to keep the older properties or the older compatible
> string as a fallback for this use case.
>
> > > > However, once the firmware is updated, it may no longer be possible to
> > > > go back to the old kernel in case the new one is busted.
> > > >
> > >
> > > Any serious update strategy will update both the kernel and device tree
> > > at the same time, exactly like you already have to update the initramfs
> > > with the kernel as soon as it is including kernel modules.
> > > I would expect any embedded platform to actually use a container format,
> > > like a FIT image that will ship the kernel, DT and intiramfs in a single
> > > image and will allow to sign all parts.
> >
> > Embedded systems that do this have no requirement for backward
> > or forward compatibility at all, the only requirement for these is bisectability
> > of git commits.
> >
>
> Yes and I can't see any drawbacks in this approach.
>
> > > > A similar problem can happen with the EBBR boot flow that relies on
> > > > a uefi-enabled firmware such as a u-boot, while using grub2 as the
> > > > actual boot loader. This is commonly supported across distros. While
> > > > grub2 can load a matching set of kernel+initrd+dtb from disk and run
> > > > that, this often fails in practice because u-boot needs to fill a
> > > > board specific set of DT properties (bootargs, detected memory,
> > > > mac address, ...). The usual way this gets handled is that u-boot loads
> > > > grub2 and the dtb from disk and then passes the modified dtb to grub,
> > > > which picks only kernel+initrd from disk and boots this with the dtb.
> > > >
> > > > The result is similar to case with dtb built into the firmware: after
> > > > upgrading the dtb that gets loaded by u-boot, grub can still pick
> > > > old kernels but they may not work as they did in the past. There are
> > > > obviously ways to work around it, but it does lead to user frustration.
> > > >
> > >
> > > Are there really any platforms with the dtb built into the firmware?
> > > I feel like this is a mythical creature used to scare people into keeping
> > > the DTB ABI stable. Aren't all the distribution already able to cope
> > > with keeping DTB and kernel in sync?
> >
> > I think most traditional PowerPC systems fall into this category, most
>
> My understanding was that the traditional PPC systems had a small device
> tree and usually are not affected by driver changes but I may be wrong.
>
> > systems that boot using UEFI+grub (as I explained), and anyone who
> > uses a distro kernel on custom hardware with their own dtb.
> >
>
> Aren't the ones using a distro kernel with a custom dtb more concerned
> by backward compatibility (i.e. new kernel with old dtb) rather than old
> kernel on new dtb? If they have an old dtb, an old kernel, and update to
> a new kernel, backward compatibility will ensure this continues to work.
> If then they work on updating their dtb, they still have the old one and
> can make the distribution match dtb and kernel. This is already handled
> properly by debian and I guess the other distributions as it is anyway
> already matching kernel and initramfs.

SUSE is doing the opposite AIUI. This is a bit harder because adding
any new provider breaks compatibility as the old kernel will wait for
a non-existent driver for the new provider. That was the motivation
for deferred probe timeouts. Of course, I wouldn't really call a
platform stable if you are still adding clock, pinctrl, power-domain,
etc. providers.

Rob

Re: [GIT PULL 2/3] ARM: dts: samsung: DTS for v5.12

[Rob Herring]

On Mon, Feb 8, 2021 at 5:10 PM Alexandre Belloni
<alexandre.belloni@bootlin.com> wrote:
>
> On 08/02/2021 23:14:02+0100, Arnd Bergmann wrote:
> > On Mon, Feb 8, 2021 at 10:35 PM Alexandre Belloni
> > <alexandre.belloni@bootlin.com> wrote:
> > > On 08/02/2021 20:52:37+0100, Arnd Bergmann wrote:
> > > > On Mon, Feb 8, 2021 at 7:42 PM Krzysztof Kozlowski <krzk@kernel.org> wrote:
> > > > > Let me steer the discussion to original topic - it's about old kernel
> > > > > and new DTB, assuming that mainline kernel bisectability is not
> > > > > affected.
> > > > >
> > > > > Flow looks like this:
> > > > >
> > > > > 0. You have existing bidings and drivers.
> > > > > 1. Patch changing bindings (with new compatible) and drivers gets
> > > > >    accepted by maintainer.
> > > > > 2. Patch above (bindings+drivers) goes during merge window to v5.11-rc1.
> > > > > 3. Patch changing in-tree DTS to new compatible gets accepted by
> > > > >    maintainer and it is sent as v5.12-rc1 material to SoC maintainers.
> > > > >
> > > > > So again: old kernel, using old bindings, new DTB.
> > > > >
> > >
> > > I don't think forward compatibility was ever considered. I've seen it
> > > being mentioned a few times on #armlinux but honestly this simply can't
> > > be achieved. This would mean being able to write complete DT bindings
> > > for a particular SoC at day 0 which will realistically never happen. You
> > > may noteven have a complete datasheet and even if you have a datasheet,
> > > it may not be complete or it may be missing hw errata that are
> > > discovered later on and need a new binding to handle.
> >
> > You do not have to write the correct DT for this, the only requirement
> > is that any changes to a node are backward-compatible, which is
> > typically the case if you add properties or compatible strings without
> > removing the old one. A bugfix in this case is also backward-compatible.
> >
> > The part that can not happen instead is to write a DT that can expose
> > features that any future kernel will use.
> >
>
> But I think we are speaking about the other way around were you would be
> e.g. removing properties or splitting a node is multiple different
> nodes following a different understanding of the hardware.
> And in this case, any rework of the bindings will be forbidden, like
> 32b7cfbd4bb2 ("ARM: dts: at91: remove deprecated ADC properties") will
> break older kernels trying to use the new dtb.
> 761f6ed85417 ("ARM: dts: at91: sama5d4: use correct rtc compatible") is
> an other case.
> I'm not sure want to keep the older properties or the older compatible
> string as a fallback for this use case.
>
> > > > However, once the firmware is updated, it may no longer be possible to
> > > > go back to the old kernel in case the new one is busted.
> > > >
> > >
> > > Any serious update strategy will update both the kernel and device tree
> > > at the same time, exactly like you already have to update the initramfs
> > > with the kernel as soon as it is including kernel modules.
> > > I would expect any embedded platform to actually use a container format,
> > > like a FIT image that will ship the kernel, DT and intiramfs in a single
> > > image and will allow to sign all parts.
> >
> > Embedded systems that do this have no requirement for backward
> > or forward compatibility at all, the only requirement for these is bisectability
> > of git commits.
> >
>
> Yes and I can't see any drawbacks in this approach.
>
> > > > A similar problem can happen with the EBBR boot flow that relies on
> > > > a uefi-enabled firmware such as a u-boot, while using grub2 as the
> > > > actual boot loader. This is commonly supported across distros. While
> > > > grub2 can load a matching set of kernel+initrd+dtb from disk and run
> > > > that, this often fails in practice because u-boot needs to fill a
> > > > board specific set of DT properties (bootargs, detected memory,
> > > > mac address, ...). The usual way this gets handled is that u-boot loads
> > > > grub2 and the dtb from disk and then passes the modified dtb to grub,
> > > > which picks only kernel+initrd from disk and boots this with the dtb.
> > > >
> > > > The result is similar to case with dtb built into the firmware: after
> > > > upgrading the dtb that gets loaded by u-boot, grub can still pick
> > > > old kernels but they may not work as they did in the past. There are
> > > > obviously ways to work around it, but it does lead to user frustration.
> > > >
> > >
> > > Are there really any platforms with the dtb built into the firmware?
> > > I feel like this is a mythical creature used to scare people into keeping
> > > the DTB ABI stable. Aren't all the distribution already able to cope
> > > with keeping DTB and kernel in sync?
> >
> > I think most traditional PowerPC systems fall into this category, most
>
> My understanding was that the traditional PPC systems had a small device
> tree and usually are not affected by driver changes but I may be wrong.
>
> > systems that boot using UEFI+grub (as I explained), and anyone who
> > uses a distro kernel on custom hardware with their own dtb.
> >
>
> Aren't the ones using a distro kernel with a custom dtb more concerned
> by backward compatibility (i.e. new kernel with old dtb) rather than old
> kernel on new dtb? If they have an old dtb, an old kernel, and update to
> a new kernel, backward compatibility will ensure this continues to work.
> If then they work on updating their dtb, they still have the old one and
> can make the distribution match dtb and kernel. This is already handled
> properly by debian and I guess the other distributions as it is anyway
> already matching kernel and initramfs.

SUSE is doing the opposite AIUI. This is a bit harder because adding
any new provider breaks compatibility as the old kernel will wait for
a non-existent driver for the new provider. That was the motivation
for deferred probe timeouts. Of course, I wouldn't really call a
platform stable if you are still adding clock, pinctrl, power-domain,
etc. providers.

Rob

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [GIT PULL 2/3] ARM: dts: samsung: DTS for v5.12

[Bjorn Andersson]

On Tue 09 Feb 08:27 CST 2021, Rob Herring wrote:

> On Mon, Feb 8, 2021 at 5:10 PM Alexandre Belloni
> <alexandre.belloni@bootlin.com> wrote:
> >
> > On 08/02/2021 23:14:02+0100, Arnd Bergmann wrote:
> > > On Mon, Feb 8, 2021 at 10:35 PM Alexandre Belloni
> > > <alexandre.belloni@bootlin.com> wrote:
> > > > On 08/02/2021 20:52:37+0100, Arnd Bergmann wrote:
> > > > > On Mon, Feb 8, 2021 at 7:42 PM Krzysztof Kozlowski <krzk@kernel.org> wrote:
> > > > > > Let me steer the discussion to original topic - it's about old kernel
> > > > > > and new DTB, assuming that mainline kernel bisectability is not
> > > > > > affected.
> > > > > >
> > > > > > Flow looks like this:
> > > > > >
> > > > > > 0. You have existing bidings and drivers.
> > > > > > 1. Patch changing bindings (with new compatible) and drivers gets
> > > > > >    accepted by maintainer.
> > > > > > 2. Patch above (bindings+drivers) goes during merge window to v5.11-rc1.
> > > > > > 3. Patch changing in-tree DTS to new compatible gets accepted by
> > > > > >    maintainer and it is sent as v5.12-rc1 material to SoC maintainers.
> > > > > >
> > > > > > So again: old kernel, using old bindings, new DTB.
> > > > > >
> > > >
> > > > I don't think forward compatibility was ever considered. I've seen it
> > > > being mentioned a few times on #armlinux but honestly this simply can't
> > > > be achieved. This would mean being able to write complete DT bindings
> > > > for a particular SoC at day 0 which will realistically never happen. You
> > > > may noteven have a complete datasheet and even if you have a datasheet,
> > > > it may not be complete or it may be missing hw errata that are
> > > > discovered later on and need a new binding to handle.
> > >
> > > You do not have to write the correct DT for this, the only requirement
> > > is that any changes to a node are backward-compatible, which is
> > > typically the case if you add properties or compatible strings without
> > > removing the old one. A bugfix in this case is also backward-compatible.
> > >
> > > The part that can not happen instead is to write a DT that can expose
> > > features that any future kernel will use.
> > >
> >
> > But I think we are speaking about the other way around were you would be
> > e.g. removing properties or splitting a node is multiple different
> > nodes following a different understanding of the hardware.
> > And in this case, any rework of the bindings will be forbidden, like
> > 32b7cfbd4bb2 ("ARM: dts: at91: remove deprecated ADC properties") will
> > break older kernels trying to use the new dtb.
> > 761f6ed85417 ("ARM: dts: at91: sama5d4: use correct rtc compatible") is
> > an other case.
> > I'm not sure want to keep the older properties or the older compatible
> > string as a fallback for this use case.
> >
> > > > > However, once the firmware is updated, it may no longer be possible to
> > > > > go back to the old kernel in case the new one is busted.
> > > > >
> > > >
> > > > Any serious update strategy will update both the kernel and device tree
> > > > at the same time, exactly like you already have to update the initramfs
> > > > with the kernel as soon as it is including kernel modules.
> > > > I would expect any embedded platform to actually use a container format,
> > > > like a FIT image that will ship the kernel, DT and intiramfs in a single
> > > > image and will allow to sign all parts.
> > >
> > > Embedded systems that do this have no requirement for backward
> > > or forward compatibility at all, the only requirement for these is bisectability
> > > of git commits.
> > >
> >
> > Yes and I can't see any drawbacks in this approach.
> >
> > > > > A similar problem can happen with the EBBR boot flow that relies on
> > > > > a uefi-enabled firmware such as a u-boot, while using grub2 as the
> > > > > actual boot loader. This is commonly supported across distros. While
> > > > > grub2 can load a matching set of kernel+initrd+dtb from disk and run
> > > > > that, this often fails in practice because u-boot needs to fill a
> > > > > board specific set of DT properties (bootargs, detected memory,
> > > > > mac address, ...). The usual way this gets handled is that u-boot loads
> > > > > grub2 and the dtb from disk and then passes the modified dtb to grub,
> > > > > which picks only kernel+initrd from disk and boots this with the dtb.
> > > > >
> > > > > The result is similar to case with dtb built into the firmware: after
> > > > > upgrading the dtb that gets loaded by u-boot, grub can still pick
> > > > > old kernels but they may not work as they did in the past. There are
> > > > > obviously ways to work around it, but it does lead to user frustration.
> > > > >
> > > >
> > > > Are there really any platforms with the dtb built into the firmware?
> > > > I feel like this is a mythical creature used to scare people into keeping
> > > > the DTB ABI stable. Aren't all the distribution already able to cope
> > > > with keeping DTB and kernel in sync?
> > >
> > > I think most traditional PowerPC systems fall into this category, most
> >
> > My understanding was that the traditional PPC systems had a small device
> > tree and usually are not affected by driver changes but I may be wrong.
> >
> > > systems that boot using UEFI+grub (as I explained), and anyone who
> > > uses a distro kernel on custom hardware with their own dtb.
> > >
> >
> > Aren't the ones using a distro kernel with a custom dtb more concerned
> > by backward compatibility (i.e. new kernel with old dtb) rather than old
> > kernel on new dtb? If they have an old dtb, an old kernel, and update to
> > a new kernel, backward compatibility will ensure this continues to work.
> > If then they work on updating their dtb, they still have the old one and
> > can make the distribution match dtb and kernel. This is already handled
> > properly by debian and I guess the other distributions as it is anyway
> > already matching kernel and initramfs.
> 
> SUSE is doing the opposite AIUI. This is a bit harder because adding
> any new provider breaks compatibility as the old kernel will wait for
> a non-existent driver for the new provider. That was the motivation
> for deferred probe timeouts. Of course, I wouldn't really call a
> platform stable if you are still adding clock, pinctrl, power-domain,
> etc. providers.
> 

IMHO "stable" in this context means that we've hit the point in
development when these questions are no longer relevant. Either because
the development is _done_ or more likely it's too old for anyone to
care.

Unfortunately this is the state that we're optimizing for and we're
simply relying on luck to boot Linux on a reasonably complex machine.

Regards,
Bjorn

Re: [GIT PULL 2/3] ARM: dts: samsung: DTS for v5.12

[Bjorn Andersson]

On Tue 09 Feb 08:27 CST 2021, Rob Herring wrote:

> On Mon, Feb 8, 2021 at 5:10 PM Alexandre Belloni
> <alexandre.belloni@bootlin.com> wrote:
> >
> > On 08/02/2021 23:14:02+0100, Arnd Bergmann wrote:
> > > On Mon, Feb 8, 2021 at 10:35 PM Alexandre Belloni
> > > <alexandre.belloni@bootlin.com> wrote:
> > > > On 08/02/2021 20:52:37+0100, Arnd Bergmann wrote:
> > > > > On Mon, Feb 8, 2021 at 7:42 PM Krzysztof Kozlowski <krzk@kernel.org> wrote:
> > > > > > Let me steer the discussion to original topic - it's about old kernel
> > > > > > and new DTB, assuming that mainline kernel bisectability is not
> > > > > > affected.
> > > > > >
> > > > > > Flow looks like this:
> > > > > >
> > > > > > 0. You have existing bidings and drivers.
> > > > > > 1. Patch changing bindings (with new compatible) and drivers gets
> > > > > >    accepted by maintainer.
> > > > > > 2. Patch above (bindings+drivers) goes during merge window to v5.11-rc1.
> > > > > > 3. Patch changing in-tree DTS to new compatible gets accepted by
> > > > > >    maintainer and it is sent as v5.12-rc1 material to SoC maintainers.
> > > > > >
> > > > > > So again: old kernel, using old bindings, new DTB.
> > > > > >
> > > >
> > > > I don't think forward compatibility was ever considered. I've seen it
> > > > being mentioned a few times on #armlinux but honestly this simply can't
> > > > be achieved. This would mean being able to write complete DT bindings
> > > > for a particular SoC at day 0 which will realistically never happen. You
> > > > may noteven have a complete datasheet and even if you have a datasheet,
> > > > it may not be complete or it may be missing hw errata that are
> > > > discovered later on and need a new binding to handle.
> > >
> > > You do not have to write the correct DT for this, the only requirement
> > > is that any changes to a node are backward-compatible, which is
> > > typically the case if you add properties or compatible strings without
> > > removing the old one. A bugfix in this case is also backward-compatible.
> > >
> > > The part that can not happen instead is to write a DT that can expose
> > > features that any future kernel will use.
> > >
> >
> > But I think we are speaking about the other way around were you would be
> > e.g. removing properties or splitting a node is multiple different
> > nodes following a different understanding of the hardware.
> > And in this case, any rework of the bindings will be forbidden, like
> > 32b7cfbd4bb2 ("ARM: dts: at91: remove deprecated ADC properties") will
> > break older kernels trying to use the new dtb.
> > 761f6ed85417 ("ARM: dts: at91: sama5d4: use correct rtc compatible") is
> > an other case.
> > I'm not sure want to keep the older properties or the older compatible
> > string as a fallback for this use case.
> >
> > > > > However, once the firmware is updated, it may no longer be possible to
> > > > > go back to the old kernel in case the new one is busted.
> > > > >
> > > >
> > > > Any serious update strategy will update both the kernel and device tree
> > > > at the same time, exactly like you already have to update the initramfs
> > > > with the kernel as soon as it is including kernel modules.
> > > > I would expect any embedded platform to actually use a container format,
> > > > like a FIT image that will ship the kernel, DT and intiramfs in a single
> > > > image and will allow to sign all parts.
> > >
> > > Embedded systems that do this have no requirement for backward
> > > or forward compatibility at all, the only requirement for these is bisectability
> > > of git commits.
> > >
> >
> > Yes and I can't see any drawbacks in this approach.
> >
> > > > > A similar problem can happen with the EBBR boot flow that relies on
> > > > > a uefi-enabled firmware such as a u-boot, while using grub2 as the
> > > > > actual boot loader. This is commonly supported across distros. While
> > > > > grub2 can load a matching set of kernel+initrd+dtb from disk and run
> > > > > that, this often fails in practice because u-boot needs to fill a
> > > > > board specific set of DT properties (bootargs, detected memory,
> > > > > mac address, ...). The usual way this gets handled is that u-boot loads
> > > > > grub2 and the dtb from disk and then passes the modified dtb to grub,
> > > > > which picks only kernel+initrd from disk and boots this with the dtb.
> > > > >
> > > > > The result is similar to case with dtb built into the firmware: after
> > > > > upgrading the dtb that gets loaded by u-boot, grub can still pick
> > > > > old kernels but they may not work as they did in the past. There are
> > > > > obviously ways to work around it, but it does lead to user frustration.
> > > > >
> > > >
> > > > Are there really any platforms with the dtb built into the firmware?
> > > > I feel like this is a mythical creature used to scare people into keeping
> > > > the DTB ABI stable. Aren't all the distribution already able to cope
> > > > with keeping DTB and kernel in sync?
> > >
> > > I think most traditional PowerPC systems fall into this category, most
> >
> > My understanding was that the traditional PPC systems had a small device
> > tree and usually are not affected by driver changes but I may be wrong.
> >
> > > systems that boot using UEFI+grub (as I explained), and anyone who
> > > uses a distro kernel on custom hardware with their own dtb.
> > >
> >
> > Aren't the ones using a distro kernel with a custom dtb more concerned
> > by backward compatibility (i.e. new kernel with old dtb) rather than old
> > kernel on new dtb? If they have an old dtb, an old kernel, and update to
> > a new kernel, backward compatibility will ensure this continues to work.
> > If then they work on updating their dtb, they still have the old one and
> > can make the distribution match dtb and kernel. This is already handled
> > properly by debian and I guess the other distributions as it is anyway
> > already matching kernel and initramfs.
> 
> SUSE is doing the opposite AIUI. This is a bit harder because adding
> any new provider breaks compatibility as the old kernel will wait for
> a non-existent driver for the new provider. That was the motivation
> for deferred probe timeouts. Of course, I wouldn't really call a
> platform stable if you are still adding clock, pinctrl, power-domain,
> etc. providers.
> 

IMHO "stable" in this context means that we've hit the point in
development when these questions are no longer relevant. Either because
the development is _done_ or more likely it's too old for anyone to
care.

Unfortunately this is the state that we're optimizing for and we're
simply relying on luck to boot Linux on a reasonably complex machine.

Regards,
Bjorn

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [GIT PULL 2/3] ARM: dts: samsung: DTS for v5.12

[Bjorn Andersson]

On Tue 09 Feb 08:27 CST 2021, Rob Herring wrote:

> On Mon, Feb 8, 2021 at 5:10 PM Alexandre Belloni
> <alexandre.belloni@bootlin.com> wrote:
> >
> > On 08/02/2021 23:14:02+0100, Arnd Bergmann wrote:
> > > On Mon, Feb 8, 2021 at 10:35 PM Alexandre Belloni
> > > <alexandre.belloni@bootlin.com> wrote:
> > > > On 08/02/2021 20:52:37+0100, Arnd Bergmann wrote:
> > > > > On Mon, Feb 8, 2021 at 7:42 PM Krzysztof Kozlowski <krzk@kernel.org> wrote:
> > > > > > Let me steer the discussion to original topic - it's about old kernel
> > > > > > and new DTB, assuming that mainline kernel bisectability is not
> > > > > > affected.
> > > > > >
> > > > > > Flow looks like this:
> > > > > >
> > > > > > 0. You have existing bidings and drivers.
> > > > > > 1. Patch changing bindings (with new compatible) and drivers gets
> > > > > >    accepted by maintainer.
> > > > > > 2. Patch above (bindings+drivers) goes during merge window to v5.11-rc1.
> > > > > > 3. Patch changing in-tree DTS to new compatible gets accepted by
> > > > > >    maintainer and it is sent as v5.12-rc1 material to SoC maintainers.
> > > > > >
> > > > > > So again: old kernel, using old bindings, new DTB.
> > > > > >
> > > >
> > > > I don't think forward compatibility was ever considered. I've seen it
> > > > being mentioned a few times on #armlinux but honestly this simply can't
> > > > be achieved. This would mean being able to write complete DT bindings
> > > > for a particular SoC at day 0 which will realistically never happen. You
> > > > may noteven have a complete datasheet and even if you have a datasheet,
> > > > it may not be complete or it may be missing hw errata that are
> > > > discovered later on and need a new binding to handle.
> > >
> > > You do not have to write the correct DT for this, the only requirement
> > > is that any changes to a node are backward-compatible, which is
> > > typically the case if you add properties or compatible strings without
> > > removing the old one. A bugfix in this case is also backward-compatible.
> > >
> > > The part that can not happen instead is to write a DT that can expose
> > > features that any future kernel will use.
> > >
> >
> > But I think we are speaking about the other way around were you would be
> > e.g. removing properties or splitting a node is multiple different
> > nodes following a different understanding of the hardware.
> > And in this case, any rework of the bindings will be forbidden, like
> > 32b7cfbd4bb2 ("ARM: dts: at91: remove deprecated ADC properties") will
> > break older kernels trying to use the new dtb.
> > 761f6ed85417 ("ARM: dts: at91: sama5d4: use correct rtc compatible") is
> > an other case.
> > I'm not sure want to keep the older properties or the older compatible
> > string as a fallback for this use case.
> >
> > > > > However, once the firmware is updated, it may no longer be possible to
> > > > > go back to the old kernel in case the new one is busted.
> > > > >
> > > >
> > > > Any serious update strategy will update both the kernel and device tree
> > > > at the same time, exactly like you already have to update the initramfs
> > > > with the kernel as soon as it is including kernel modules.
> > > > I would expect any embedded platform to actually use a container format,
> > > > like a FIT image that will ship the kernel, DT and intiramfs in a single
> > > > image and will allow to sign all parts.
> > >
> > > Embedded systems that do this have no requirement for backward
> > > or forward compatibility at all, the only requirement for these is bisectability
> > > of git commits.
> > >
> >
> > Yes and I can't see any drawbacks in this approach.
> >
> > > > > A similar problem can happen with the EBBR boot flow that relies on
> > > > > a uefi-enabled firmware such as a u-boot, while using grub2 as the
> > > > > actual boot loader. This is commonly supported across distros. While
> > > > > grub2 can load a matching set of kernel+initrd+dtb from disk and run
> > > > > that, this often fails in practice because u-boot needs to fill a
> > > > > board specific set of DT properties (bootargs, detected memory,
> > > > > mac address, ...). The usual way this gets handled is that u-boot loads
> > > > > grub2 and the dtb from disk and then passes the modified dtb to grub,
> > > > > which picks only kernel+initrd from disk and boots this with the dtb.
> > > > >
> > > > > The result is similar to case with dtb built into the firmware: after
> > > > > upgrading the dtb that gets loaded by u-boot, grub can still pick
> > > > > old kernels but they may not work as they did in the past. There are
> > > > > obviously ways to work around it, but it does lead to user frustration.
> > > > >
> > > >
> > > > Are there really any platforms with the dtb built into the firmware?
> > > > I feel like this is a mythical creature used to scare people into keeping
> > > > the DTB ABI stable. Aren't all the distribution already able to cope
> > > > with keeping DTB and kernel in sync?
> > >
> > > I think most traditional PowerPC systems fall into this category, most
> >
> > My understanding was that the traditional PPC systems had a small device
> > tree and usually are not affected by driver changes but I may be wrong.
> >
> > > systems that boot using UEFI+grub (as I explained), and anyone who
> > > uses a distro kernel on custom hardware with their own dtb.
> > >
> >
> > Aren't the ones using a distro kernel with a custom dtb more concerned
> > by backward compatibility (i.e. new kernel with old dtb) rather than old
> > kernel on new dtb? If they have an old dtb, an old kernel, and update to
> > a new kernel, backward compatibility will ensure this continues to work.
> > If then they work on updating their dtb, they still have the old one and
> > can make the distribution match dtb and kernel. This is already handled
> > properly by debian and I guess the other distributions as it is anyway
> > already matching kernel and initramfs.
> 
> SUSE is doing the opposite AIUI. This is a bit harder because adding
> any new provider breaks compatibility as the old kernel will wait for
> a non-existent driver for the new provider. That was the motivation
> for deferred probe timeouts. Of course, I wouldn't really call a
> platform stable if you are still adding clock, pinctrl, power-domain,
> etc. providers.
> 

IMHO "stable" in this context means that we've hit the point in
development when these questions are no longer relevant. Either because
the development is _done_ or more likely it's too old for anyone to
care.

Unfortunately this is the state that we're optimizing for and we're
simply relying on luck to boot Linux on a reasonably complex machine.

Regards,
Bjorn

Re: [GIT PULL 2/3] ARM: dts: samsung: DTS for v5.12

[Frank Rowand]

On 2/6/21 8:35 AM, Arnd Bergmann wrote:
> On Sat, Feb 6, 2021 at 2:45 PM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>> On Mon, Jan 25, 2021 at 08:12:39PM +0100, Krzysztof Kozlowski wrote:
>>>
>>> ----------------------------------------------------------------
>>> Samsung DTS ARM changes for v5.12
>>>
>>> 1. Use new compatile to properly configure Exynos5420 USB2 PHY, fixing
>>>    it suspend/resume cycle.
>>> 2. Correct Samsung PMIC interrupt trigger levels on multiple boards.
>>> 3. Correct the voltages of Samsung GT-I9100 charger and add top-off
>>>    charger.
>>>
>>
>> Hi everyone,
>>
>> Any progress or new comments about this pull request?
> 
> Hi Krzysztof,
> 
> Sorry for not getting back to you on this earlier. I discussed this with
> Olof the other day and we decided to merge this, I just haven't
> gone through the pull requests over the past few days. My plan is
> to do the next round on Monday.
> 
> That said, I'm still not happy about the patch we discussed in the
> other email thread[1] and I'd like to handle it a little more strictly in
> the future, but I agree this wasn't obvious and we have been rather
> inconsistent about it in the past, with some platform maintainers
> handling it way more strictly than others.
> 
> I've added the devicetree maintainers and a few other platform
> maintainers to Cc here, maybe they can provide some further
> opinions on the topic so we can come to an approach that
> works for everyone.
> 
> My summary of the thread in [1] is there was a driver bug that
> required a DT binding change. Krzysztof and the other involved
> parties made sure the driver handles it in a backward-compatible
> way (an old dtb file will still run into the bug but keep working
> with new kernels), but decided that they did not need to worry
> about the opposite case (running an old kernel with an updated
> dtb). I noticed the compatibility break and said that I would
> prefer this to be done in a way that is compatible both ways,
> or at the minimum be alerted about the binding break in the
> pull request, with an explanation about why this had to be done,
> even when we don't think anyone is going to be affected.
> 
> What do others think about this? Should we generally assume
> that breaking old kernels with new dtbs is acceptable, or should
> we try to avoid it if possible, the same way we try to avoid
> breaking new kernels with old dtbs? Should this be a platform
> specific policy or should we try to handle all platforms the same
> way?

The current policy (since before 2013) is that newer kernels,
implementing new bindings, do not break with old existing dtbs.

Old existing kernels are not required to work with new dtbs.

See Documentation/devicetree/bindings/ABI.rst

We can choose to change the rules, so I'm not saying that the
discussion should not occur.  I'm just pointing out the
current policy.

I think that ABI.rst does not state "Old existing kernels are
not required to work with new dtbs" clearly enough, and
should be updated to do so.

I also think it would be good to explicitly say that care
should be taken with new bindings to not break existing
kernels, if reasonably possible.

-Frank

> 
>           Arnd
> 
> [1] https://lore.kernel.org/lkml/20210130143949.aamac2724esupt7v@kozik-lap/
> 

Re: [GIT PULL 2/3] ARM: dts: samsung: DTS for v5.12

[Frank Rowand]

On 2/6/21 8:35 AM, Arnd Bergmann wrote:
> On Sat, Feb 6, 2021 at 2:45 PM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>> On Mon, Jan 25, 2021 at 08:12:39PM +0100, Krzysztof Kozlowski wrote:
>>>
>>> ----------------------------------------------------------------
>>> Samsung DTS ARM changes for v5.12
>>>
>>> 1. Use new compatile to properly configure Exynos5420 USB2 PHY, fixing
>>>    it suspend/resume cycle.
>>> 2. Correct Samsung PMIC interrupt trigger levels on multiple boards.
>>> 3. Correct the voltages of Samsung GT-I9100 charger and add top-off
>>>    charger.
>>>
>>
>> Hi everyone,
>>
>> Any progress or new comments about this pull request?
> 
> Hi Krzysztof,
> 
> Sorry for not getting back to you on this earlier. I discussed this with
> Olof the other day and we decided to merge this, I just haven't
> gone through the pull requests over the past few days. My plan is
> to do the next round on Monday.
> 
> That said, I'm still not happy about the patch we discussed in the
> other email thread[1] and I'd like to handle it a little more strictly in
> the future, but I agree this wasn't obvious and we have been rather
> inconsistent about it in the past, with some platform maintainers
> handling it way more strictly than others.
> 
> I've added the devicetree maintainers and a few other platform
> maintainers to Cc here, maybe they can provide some further
> opinions on the topic so we can come to an approach that
> works for everyone.
> 
> My summary of the thread in [1] is there was a driver bug that
> required a DT binding change. Krzysztof and the other involved
> parties made sure the driver handles it in a backward-compatible
> way (an old dtb file will still run into the bug but keep working
> with new kernels), but decided that they did not need to worry
> about the opposite case (running an old kernel with an updated
> dtb). I noticed the compatibility break and said that I would
> prefer this to be done in a way that is compatible both ways,
> or at the minimum be alerted about the binding break in the
> pull request, with an explanation about why this had to be done,
> even when we don't think anyone is going to be affected.
> 
> What do others think about this? Should we generally assume
> that breaking old kernels with new dtbs is acceptable, or should
> we try to avoid it if possible, the same way we try to avoid
> breaking new kernels with old dtbs? Should this be a platform
> specific policy or should we try to handle all platforms the same
> way?

The current policy (since before 2013) is that newer kernels,
implementing new bindings, do not break with old existing dtbs.

Old existing kernels are not required to work with new dtbs.

See Documentation/devicetree/bindings/ABI.rst

We can choose to change the rules, so I'm not saying that the
discussion should not occur.  I'm just pointing out the
current policy.

I think that ABI.rst does not state "Old existing kernels are
not required to work with new dtbs" clearly enough, and
should be updated to do so.

I also think it would be good to explicitly say that care
should be taken with new bindings to not break existing
kernels, if reasonably possible.

-Frank

> 
>           Arnd
> 
> [1] https://lore.kernel.org/lkml/20210130143949.aamac2724esupt7v@kozik-lap/
> 


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [GIT PULL 2/3] ARM: dts: samsung: DTS for v5.12

[Frank Rowand]

On 2/6/21 8:35 AM, Arnd Bergmann wrote:
> On Sat, Feb 6, 2021 at 2:45 PM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>> On Mon, Jan 25, 2021 at 08:12:39PM +0100, Krzysztof Kozlowski wrote:
>>>
>>> ----------------------------------------------------------------
>>> Samsung DTS ARM changes for v5.12
>>>
>>> 1. Use new compatile to properly configure Exynos5420 USB2 PHY, fixing
>>>    it suspend/resume cycle.
>>> 2. Correct Samsung PMIC interrupt trigger levels on multiple boards.
>>> 3. Correct the voltages of Samsung GT-I9100 charger and add top-off
>>>    charger.
>>>
>>
>> Hi everyone,
>>
>> Any progress or new comments about this pull request?
> 
> Hi Krzysztof,
> 
> Sorry for not getting back to you on this earlier. I discussed this with
> Olof the other day and we decided to merge this, I just haven't
> gone through the pull requests over the past few days. My plan is
> to do the next round on Monday.
> 
> That said, I'm still not happy about the patch we discussed in the
> other email thread[1] and I'd like to handle it a little more strictly in
> the future, but I agree this wasn't obvious and we have been rather
> inconsistent about it in the past, with some platform maintainers
> handling it way more strictly than others.
> 
> I've added the devicetree maintainers and a few other platform
> maintainers to Cc here, maybe they can provide some further
> opinions on the topic so we can come to an approach that
> works for everyone.
> 
> My summary of the thread in [1] is there was a driver bug that
> required a DT binding change. Krzysztof and the other involved
> parties made sure the driver handles it in a backward-compatible
> way (an old dtb file will still run into the bug but keep working
> with new kernels), but decided that they did not need to worry
> about the opposite case (running an old kernel with an updated
> dtb). I noticed the compatibility break and said that I would
> prefer this to be done in a way that is compatible both ways,
> or at the minimum be alerted about the binding break in the
> pull request, with an explanation about why this had to be done,
> even when we don't think anyone is going to be affected.
> 
> What do others think about this? Should we generally assume
> that breaking old kernels with new dtbs is acceptable, or should
> we try to avoid it if possible, the same way we try to avoid
> breaking new kernels with old dtbs? Should this be a platform
> specific policy or should we try to handle all platforms the same
> way?

The current policy (since before 2013) is that newer kernels,
implementing new bindings, do not break with old existing dtbs.

Old existing kernels are not required to work with new dtbs.

See Documentation/devicetree/bindings/ABI.rst

We can choose to change the rules, so I'm not saying that the
discussion should not occur.  I'm just pointing out the
current policy.

I think that ABI.rst does not state "Old existing kernels are
not required to work with new dtbs" clearly enough, and
should be updated to do so.

I also think it would be good to explicitly say that care
should be taken with new bindings to not break existing
kernels, if reasonably possible.

-Frank

> 
>           Arnd
> 
> [1] https://lore.kernel.org/lkml/20210130143949.aamac2724esupt7v@kozik-lap/
> 

Re: [GIT PULL 2/3] ARM: dts: samsung: DTS for v5.12

[Arnd Bergmann]

From: Arnd Bergmann <arnd@arndb.de>

On Mon, 25 Jan 2021 20:12:39 +0100, Krzysztof Kozlowski wrote:
> The following changes since commit 5c8fe583cce542aa0b84adc939ce85293de36e5e:
> 
>   Linux 5.11-rc1 (2020-12-27 15:30:22 -0800)
> 
> are available in the Git repository at:
> 
>   https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-dt-5.12
> 
> [...]

Merged into arm/dt at least, sorry for the long delay.

merge commit: f3d8876acac00e7430e46679fb1da26e50c006d5

       Arnd

Re: [GIT PULL 2/3] ARM: dts: samsung: DTS for v5.12

[Arnd Bergmann]

From: Arnd Bergmann <arnd@arndb.de>

On Mon, 25 Jan 2021 20:12:39 +0100, Krzysztof Kozlowski wrote:
> The following changes since commit 5c8fe583cce542aa0b84adc939ce85293de36e5e:
> 
>   Linux 5.11-rc1 (2020-12-27 15:30:22 -0800)
> 
> are available in the Git repository at:
> 
>   https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-dt-5.12
> 
> [...]

Merged into arm/dt at least, sorry for the long delay.

merge commit: f3d8876acac00e7430e46679fb1da26e50c006d5

       Arnd

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[GIT PULL 3/3] arm64: dts: samsung: DTS for v5.12

[Krzysztof Kozlowski]

The following changes since commit 5c8fe583cce542aa0b84adc939ce85293de36e5e:

  Linux 5.11-rc1 (2020-12-27 15:30:22 -0800)

are available in the Git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-dt64-5.12

for you to fetch changes up to 545a540a9c2ec192cdd5c75af1e334711a79354a:

  arm64: dts: exynos: correct S3FWRN5 NFC interrupt trigger level on TM2 (2020-12-29 16:47:20 +0100)

----------------------------------------------------------------
Samsung DTS ARM64 changes for v5.12

Correct Samsung PMIC and S3FWRN5 NFC interrupts trigger levels on
TM2/TM2E and Espresso boards.

----------------------------------------------------------------
Krzysztof Kozlowski (3):
      arm64: dts: exynos: correct PMIC interrupt trigger level on TM2
      arm64: dts: exynos: correct PMIC interrupt trigger level on Espresso
      arm64: dts: exynos: correct S3FWRN5 NFC interrupt trigger level on TM2

 arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi | 4 ++--
 arch/arm64/boot/dts/exynos/exynos7-espresso.dts       | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

[GIT PULL 3/3] arm64: dts: samsung: DTS for v5.12

[Krzysztof Kozlowski]

The following changes since commit 5c8fe583cce542aa0b84adc939ce85293de36e5e:

  Linux 5.11-rc1 (2020-12-27 15:30:22 -0800)

are available in the Git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-dt64-5.12

for you to fetch changes up to 545a540a9c2ec192cdd5c75af1e334711a79354a:

  arm64: dts: exynos: correct S3FWRN5 NFC interrupt trigger level on TM2 (2020-12-29 16:47:20 +0100)

----------------------------------------------------------------
Samsung DTS ARM64 changes for v5.12

Correct Samsung PMIC and S3FWRN5 NFC interrupts trigger levels on
TM2/TM2E and Espresso boards.

----------------------------------------------------------------
Krzysztof Kozlowski (3):
      arm64: dts: exynos: correct PMIC interrupt trigger level on TM2
      arm64: dts: exynos: correct PMIC interrupt trigger level on Espresso
      arm64: dts: exynos: correct S3FWRN5 NFC interrupt trigger level on TM2

 arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi | 4 ++--
 arch/arm64/boot/dts/exynos/exynos7-espresso.dts       | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [GIT PULL 3/3] arm64: dts: samsung: DTS for v5.12

[Arnd Bergmann]

From: Arnd Bergmann <arnd@arndb.de>

On Mon, 25 Jan 2021 20:12:40 +0100, Krzysztof Kozlowski wrote:
> The following changes since commit 5c8fe583cce542aa0b84adc939ce85293de36e5e:
> 
>   Linux 5.11-rc1 (2020-12-27 15:30:22 -0800)
> 
> are available in the Git repository at:
> 
>   https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-dt64-5.12
> 
> [...]

Merged into arm/dt, thanks!

merge commit: 1f99bd1a51b836bc60482370d89bd16a564d28c2

       Arnd

Re: [GIT PULL 3/3] arm64: dts: samsung: DTS for v5.12

[Arnd Bergmann]

From: Arnd Bergmann <arnd@arndb.de>

On Mon, 25 Jan 2021 20:12:40 +0100, Krzysztof Kozlowski wrote:
> The following changes since commit 5c8fe583cce542aa0b84adc939ce85293de36e5e:
> 
>   Linux 5.11-rc1 (2020-12-27 15:30:22 -0800)
> 
> are available in the Git repository at:
> 
>   https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-dt64-5.12
> 
> [...]

Merged into arm/dt, thanks!

merge commit: 1f99bd1a51b836bc60482370d89bd16a564d28c2

       Arnd

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel