[RFC PATCH] ARM: dts: i.MX8MP: remove barebox environment handling

[RFC PATCH] ARM: dts: i.MX8MP: remove barebox environment handling

[Marco Felsch]

While specifying the barebox environment within the barebox dts is very
helpful for standalone barebox development it's difficult for BSPs which
use this development platform and want to use the GPT mechanism.
As a result BSPs had to manually delete the nodes via a external
provided dts, because we wanted to keep the comfort for the standalone
development flow.

Lucky commit 86531d4bf7aa ("commands: create createnv command")
introduced a convenient helper to create a barebox environemnt on
demand exactly for this purpose:

| "We want to move away from describing the barebox environment explicitly
| in the device tree and instead motivate usage of GPT partitions.."

So start with the i.MX8MP-EVK to encourage the use of GPT partitions and
to make the BSP integration for these development platforms easier.

Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
---
 arch/arm/dts/imx8mp-evk.dts | 43 -------------------------------------
 1 file changed, 43 deletions(-)

diff --git a/arch/arm/dts/imx8mp-evk.dts b/arch/arm/dts/imx8mp-evk.dts
index e6f8c2d1b482..37798fa99efa 100644
--- a/arch/arm/dts/imx8mp-evk.dts
+++ b/arch/arm/dts/imx8mp-evk.dts
@@ -12,19 +12,6 @@
 / {
 	barebox,deep-probe;
 
-	chosen {
-		environment-sd {
-			compatible = "barebox,environment";
-			device-path = &env_sd2;
-			status = "disabled";
-		};
-		environment-emmc {
-			compatible = "barebox,environment";
-			device-path = &env_sd3;
-			status = "disabled";
-		};
-	};
-
 	gpio-leds {
 		status {
 			barebox,default-trigger = "heartbeat";
@@ -78,33 +65,3 @@ &usb_dwc3_0 {
 	usb-role-switch;
 	status = "okay";
 };
-
-&usdhc2 {
-	#address-cells = <1>;
-	#size-cells = <1>;
-
-	partition@0 {
-		label = "barebox";
-		reg = <0x0 0xe0000>;
-	};
-
-	env_sd2: partition@e0000 {
-		label = "barebox-environment";
-		reg = <0xe0000 0x20000>;
-	};
-};
-
-&usdhc3 {
-	#address-cells = <1>;
-	#size-cells = <1>;
-
-	partition@0 {
-		label = "barebox";
-		reg = <0x0 0xe0000>;
-	};
-
-	env_sd3: partition@e0000 {
-		label = "barebox-environment";
-		reg = <0xe0000 0x20000>;
-	};
-};
-- 
2.47.3

Re: [RFC PATCH] ARM: dts: i.MX8MP: remove barebox environment handling

[Sascha Hauer]

On Tue, Feb 10, 2026 at 11:13:40PM +0100, Marco Felsch wrote:
> While specifying the barebox environment within the barebox dts is very
> helpful for standalone barebox development it's difficult for BSPs which
> use this development platform and want to use the GPT mechanism.
> As a result BSPs had to manually delete the nodes via a external
> provided dts, because we wanted to keep the comfort for the standalone
> development flow.
> 
> Lucky commit 86531d4bf7aa ("commands: create createnv command")
> introduced a convenient helper to create a barebox environemnt on
> demand exactly for this purpose:
> 
> | "We want to move away from describing the barebox environment explicitly
> | in the device tree and instead motivate usage of GPT partitions.."
> 
> So start with the i.MX8MP-EVK to encourage the use of GPT partitions and
> to make the BSP integration for these development platforms easier.

Generally I like this idea, but it breaks the existing users
environment and doing this sharp cut might be annoying for the phase
where you switch between different barebox versions which could be quite
common for development boards.

Would be great to have a grace period in which we prefer the UUID
environment over the device tree environment (we might do this already)
and warn in case we still use the latter. We could stick the warning to
a device tree property like "warn-deprecated-env" and remove the
environment once they carry this property for a year or so.

Just the ideas from the top of my head. Thoughts?

Sascha

> 
> Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
> ---
>  arch/arm/dts/imx8mp-evk.dts | 43 -------------------------------------
>  1 file changed, 43 deletions(-)
> 
> diff --git a/arch/arm/dts/imx8mp-evk.dts b/arch/arm/dts/imx8mp-evk.dts
> index e6f8c2d1b482..37798fa99efa 100644
> --- a/arch/arm/dts/imx8mp-evk.dts
> +++ b/arch/arm/dts/imx8mp-evk.dts
> @@ -12,19 +12,6 @@
>  / {
>  	barebox,deep-probe;
>  
> -	chosen {
> -		environment-sd {
> -			compatible = "barebox,environment";
> -			device-path = &env_sd2;
> -			status = "disabled";
> -		};
> -		environment-emmc {
> -			compatible = "barebox,environment";
> -			device-path = &env_sd3;
> -			status = "disabled";
> -		};
> -	};
> -
>  	gpio-leds {
>  		status {
>  			barebox,default-trigger = "heartbeat";
> @@ -78,33 +65,3 @@ &usb_dwc3_0 {
>  	usb-role-switch;
>  	status = "okay";
>  };
> -
> -&usdhc2 {
> -	#address-cells = <1>;
> -	#size-cells = <1>;
> -
> -	partition@0 {
> -		label = "barebox";
> -		reg = <0x0 0xe0000>;
> -	};
> -
> -	env_sd2: partition@e0000 {
> -		label = "barebox-environment";
> -		reg = <0xe0000 0x20000>;
> -	};
> -};
> -
> -&usdhc3 {
> -	#address-cells = <1>;
> -	#size-cells = <1>;
> -
> -	partition@0 {
> -		label = "barebox";
> -		reg = <0x0 0xe0000>;
> -	};
> -
> -	env_sd3: partition@e0000 {
> -		label = "barebox-environment";
> -		reg = <0xe0000 0x20000>;
> -	};
> -};
> -- 
> 2.47.3
> 
> 
> 

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: [RFC PATCH] ARM: dts: i.MX8MP: remove barebox environment handling

[Ahmad Fatoum]

Hi,

On 2/11/26 8:53 AM, Sascha Hauer wrote:
> On Tue, Feb 10, 2026 at 11:13:40PM +0100, Marco Felsch wrote:
>> While specifying the barebox environment within the barebox dts is very
>> helpful for standalone barebox development it's difficult for BSPs which
>> use this development platform and want to use the GPT mechanism.
>> As a result BSPs had to manually delete the nodes via a external
>> provided dts, because we wanted to keep the comfort for the standalone
>> development flow.
>>
>> Lucky commit 86531d4bf7aa ("commands: create createnv command")
>> introduced a convenient helper to create a barebox environemnt on
>> demand exactly for this purpose:
>>
>> | "We want to move away from describing the barebox environment explicitly
>> | in the device tree and instead motivate usage of GPT partitions.."
>>
>> So start with the i.MX8MP-EVK to encourage the use of GPT partitions and
>> to make the BSP integration for these development platforms easier.
> 
> Generally I like this idea, but it breaks the existing users
> environment and doing this sharp cut might be annoying for the phase
> where you switch between different barebox versions which could be quite
> common for development boards.
> 
> Would be great to have a grace period in which we prefer the UUID
> environment over the device tree environment (we might do this already)
> and warn in case we still use the latter. We could stick the warning to
> a device tree property like "warn-deprecated-env" and remove the
> environment once they carry this property for a year or so.
> 
> Just the ideas from the top of my head. Thoughts?

Here's my opinion from a year back:
https://lore.barebox.org/barebox/1ff0f545-effa-4b87-81b7-524919333777@pengutronix.de/

I am interested to hear thoughts on it.
Compared to our suggestion, there will be no eventual removal of the node.

Cheers,
Ahmad

> 
> Sascha
> 
>>
>> Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
>> ---
>>  arch/arm/dts/imx8mp-evk.dts | 43 -------------------------------------
>>  1 file changed, 43 deletions(-)
>>
>> diff --git a/arch/arm/dts/imx8mp-evk.dts b/arch/arm/dts/imx8mp-evk.dts
>> index e6f8c2d1b482..37798fa99efa 100644
>> --- a/arch/arm/dts/imx8mp-evk.dts
>> +++ b/arch/arm/dts/imx8mp-evk.dts
>> @@ -12,19 +12,6 @@
>>  / {
>>  	barebox,deep-probe;
>>  
>> -	chosen {
>> -		environment-sd {
>> -			compatible = "barebox,environment";
>> -			device-path = &env_sd2;
>> -			status = "disabled";
>> -		};
>> -		environment-emmc {
>> -			compatible = "barebox,environment";
>> -			device-path = &env_sd3;
>> -			status = "disabled";
>> -		};
>> -	};
>> -
>>  	gpio-leds {
>>  		status {
>>  			barebox,default-trigger = "heartbeat";
>> @@ -78,33 +65,3 @@ &usb_dwc3_0 {
>>  	usb-role-switch;
>>  	status = "okay";
>>  };
>> -
>> -&usdhc2 {
>> -	#address-cells = <1>;
>> -	#size-cells = <1>;
>> -
>> -	partition@0 {
>> -		label = "barebox";
>> -		reg = <0x0 0xe0000>;
>> -	};
>> -
>> -	env_sd2: partition@e0000 {
>> -		label = "barebox-environment";
>> -		reg = <0xe0000 0x20000>;
>> -	};
>> -};
>> -
>> -&usdhc3 {
>> -	#address-cells = <1>;
>> -	#size-cells = <1>;
>> -
>> -	partition@0 {
>> -		label = "barebox";
>> -		reg = <0x0 0xe0000>;
>> -	};
>> -
>> -	env_sd3: partition@e0000 {
>> -		label = "barebox-environment";
>> -		reg = <0xe0000 0x20000>;
>> -	};
>> -};
>> -- 
>> 2.47.3
>>
>>
>>
> 

-- 
Pengutronix e.K.                  |                             |
Steuerwalder Str. 21              | http://www.pengutronix.de/  |
31137 Hildesheim, Germany         | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686  | Fax:   +49-5121-206917-5555 |

Re: [RFC PATCH] ARM: dts: i.MX8MP: remove barebox environment handling

[Sascha Hauer]

On Wed, Feb 11, 2026 at 10:37:18AM +0100, Ahmad Fatoum wrote:
> Hi,
> 
> On 2/11/26 8:53 AM, Sascha Hauer wrote:
> > On Tue, Feb 10, 2026 at 11:13:40PM +0100, Marco Felsch wrote:
> >> While specifying the barebox environment within the barebox dts is very
> >> helpful for standalone barebox development it's difficult for BSPs which
> >> use this development platform and want to use the GPT mechanism.
> >> As a result BSPs had to manually delete the nodes via a external
> >> provided dts, because we wanted to keep the comfort for the standalone
> >> development flow.
> >>
> >> Lucky commit 86531d4bf7aa ("commands: create createnv command")
> >> introduced a convenient helper to create a barebox environemnt on
> >> demand exactly for this purpose:
> >>
> >> | "We want to move away from describing the barebox environment explicitly
> >> | in the device tree and instead motivate usage of GPT partitions.."
> >>
> >> So start with the i.MX8MP-EVK to encourage the use of GPT partitions and
> >> to make the BSP integration for these development platforms easier.
> > 
> > Generally I like this idea, but it breaks the existing users
> > environment and doing this sharp cut might be annoying for the phase
> > where you switch between different barebox versions which could be quite
> > common for development boards.
> > 
> > Would be great to have a grace period in which we prefer the UUID
> > environment over the device tree environment (we might do this already)
> > and warn in case we still use the latter. We could stick the warning to
> > a device tree property like "warn-deprecated-env" and remove the
> > environment once they carry this property for a year or so.
> > 
> > Just the ideas from the top of my head. Thoughts?
> 
> Here's my opinion from a year back:
> https://lore.barebox.org/barebox/1ff0f545-effa-4b87-81b7-524919333777@pengutronix.de/
> 
> I am interested to hear thoughts on it.
> Compared to our suggestion, there will be no eventual removal of the node.

Seems to match mostly what I said, only that instead of a
warn-deprecated-env property you suggest a different compatible which
I think better matches what we are doing. Whether or not we remove the
fallback nodes in future is something our future-selves can discuss.

Sascha

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: [RFC PATCH] ARM: dts: i.MX8MP: remove barebox environment handling

[Marco Felsch]

Hi Sascha, Ahmad,

On 26-02-11, Ahmad Fatoum wrote:
> Hi,
> 
> On 2/11/26 8:53 AM, Sascha Hauer wrote:
> > On Tue, Feb 10, 2026 at 11:13:40PM +0100, Marco Felsch wrote:
> >> While specifying the barebox environment within the barebox dts is very
> >> helpful for standalone barebox development it's difficult for BSPs which
> >> use this development platform and want to use the GPT mechanism.
> >> As a result BSPs had to manually delete the nodes via a external
> >> provided dts, because we wanted to keep the comfort for the standalone
> >> development flow.
> >>
> >> Lucky commit 86531d4bf7aa ("commands: create createnv command")
> >> introduced a convenient helper to create a barebox environemnt on
> >> demand exactly for this purpose:
> >>
> >> | "We want to move away from describing the barebox environment explicitly
> >> | in the device tree and instead motivate usage of GPT partitions.."
> >>
> >> So start with the i.MX8MP-EVK to encourage the use of GPT partitions and
> >> to make the BSP integration for these development platforms easier.
> > 
> > Generally I like this idea, but it breaks the existing users
> > environment and doing this sharp cut might be annoying for the phase
> > where you switch between different barebox versions which could be quite
> > common for development boards.

Good point, albeit commit 86531d4bf7aa is part of v2025.08.0, so it's
~6months old. I also don't know how often i.MX8MP-EVK barebox features
are implemented which require to jump between barebox versions.

> > Would be great to have a grace period in which we prefer the UUID
> > environment over the device tree environment (we might do this already)
> > and warn in case we still use the latter. We could stick the warning to
> > a device tree property like "warn-deprecated-env" and remove the
> > environment once they carry this property for a year or so.
> > 
> > Just the ideas from the top of my head. Thoughts?
> 
> Here's my opinion from a year back:
> https://lore.barebox.org/barebox/1ff0f545-effa-4b87-81b7-524919333777@pengutronix.de/

Thanks for the link, I fogot that I've send somthing similar already ^^

> I am interested to hear thoughts on it.
> Compared to our suggestion, there will be no eventual removal of the node.

Both your suggestions are very similar and provide a smother transistion
though. I would like to get rid of the old OF-env handling completely
and therefore prefer Sascha's approach a bit more. Having a fallback is
good, but fallbacks tend to crumble over time since they aren't tested.

Of course we could add tests to keep the barebox,environment-fallback
running, but is it worth it?

Regards,
  Marco



> 
> Cheers,
> Ahmad
> 
> > 
> > Sascha
> > 
> >>
> >> Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
> >> ---
> >>  arch/arm/dts/imx8mp-evk.dts | 43 -------------------------------------
> >>  1 file changed, 43 deletions(-)
> >>
> >> diff --git a/arch/arm/dts/imx8mp-evk.dts b/arch/arm/dts/imx8mp-evk.dts
> >> index e6f8c2d1b482..37798fa99efa 100644
> >> --- a/arch/arm/dts/imx8mp-evk.dts
> >> +++ b/arch/arm/dts/imx8mp-evk.dts
> >> @@ -12,19 +12,6 @@
> >>  / {
> >>  	barebox,deep-probe;
> >>  
> >> -	chosen {
> >> -		environment-sd {
> >> -			compatible = "barebox,environment";
> >> -			device-path = &env_sd2;
> >> -			status = "disabled";
> >> -		};
> >> -		environment-emmc {
> >> -			compatible = "barebox,environment";
> >> -			device-path = &env_sd3;
> >> -			status = "disabled";
> >> -		};
> >> -	};
> >> -
> >>  	gpio-leds {
> >>  		status {
> >>  			barebox,default-trigger = "heartbeat";
> >> @@ -78,33 +65,3 @@ &usb_dwc3_0 {
> >>  	usb-role-switch;
> >>  	status = "okay";
> >>  };
> >> -
> >> -&usdhc2 {
> >> -	#address-cells = <1>;
> >> -	#size-cells = <1>;
> >> -
> >> -	partition@0 {
> >> -		label = "barebox";
> >> -		reg = <0x0 0xe0000>;
> >> -	};
> >> -
> >> -	env_sd2: partition@e0000 {
> >> -		label = "barebox-environment";
> >> -		reg = <0xe0000 0x20000>;
> >> -	};
> >> -};
> >> -
> >> -&usdhc3 {
> >> -	#address-cells = <1>;
> >> -	#size-cells = <1>;
> >> -
> >> -	partition@0 {
> >> -		label = "barebox";
> >> -		reg = <0x0 0xe0000>;
> >> -	};
> >> -
> >> -	env_sd3: partition@e0000 {
> >> -		label = "barebox-environment";
> >> -		reg = <0xe0000 0x20000>;
> >> -	};
> >> -};
> >> -- 
> >> 2.47.3
> >>
> >>
> >>
> > 
> 
> -- 
> Pengutronix e.K.                  |                             |
> Steuerwalder Str. 21              | http://www.pengutronix.de/  |
> 31137 Hildesheim, Germany         | Phone: +49-5121-206917-0    |
> Amtsgericht Hildesheim, HRA 2686  | Fax:   +49-5121-206917-5555 |
> 
> 

-- 
#gernperDu 
#CallMeByMyFirstName

Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | https://www.pengutronix.de/ |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-9    |

Re: [RFC PATCH] ARM: dts: i.MX8MP: remove barebox environment handling

[Sascha Hauer]

On Wed, Feb 11, 2026 at 11:14:51AM +0100, Marco Felsch wrote:
> Hi Sascha, Ahmad,
> 
> On 26-02-11, Ahmad Fatoum wrote:
> > Hi,
> > 
> > On 2/11/26 8:53 AM, Sascha Hauer wrote:
> > > On Tue, Feb 10, 2026 at 11:13:40PM +0100, Marco Felsch wrote:
> > >> While specifying the barebox environment within the barebox dts is very
> > >> helpful for standalone barebox development it's difficult for BSPs which
> > >> use this development platform and want to use the GPT mechanism.
> > >> As a result BSPs had to manually delete the nodes via a external
> > >> provided dts, because we wanted to keep the comfort for the standalone
> > >> development flow.
> > >>
> > >> Lucky commit 86531d4bf7aa ("commands: create createnv command")
> > >> introduced a convenient helper to create a barebox environemnt on
> > >> demand exactly for this purpose:
> > >>
> > >> | "We want to move away from describing the barebox environment explicitly
> > >> | in the device tree and instead motivate usage of GPT partitions.."
> > >>
> > >> So start with the i.MX8MP-EVK to encourage the use of GPT partitions and
> > >> to make the BSP integration for these development platforms easier.
> > > 
> > > Generally I like this idea, but it breaks the existing users
> > > environment and doing this sharp cut might be annoying for the phase
> > > where you switch between different barebox versions which could be quite
> > > common for development boards.
> 
> Good point, albeit commit 86531d4bf7aa is part of v2025.08.0, so it's
> ~6months old. I also don't know how often i.MX8MP-EVK barebox features
> are implemented which require to jump between barebox versions.

Jumping between versions is something that just happens, be it for
bisecting or you have a development and stable branch for a BSP with
different barebox versions.

> 
> > > Would be great to have a grace period in which we prefer the UUID
> > > environment over the device tree environment (we might do this already)
> > > and warn in case we still use the latter. We could stick the warning to
> > > a device tree property like "warn-deprecated-env" and remove the
> > > environment once they carry this property for a year or so.
> > > 
> > > Just the ideas from the top of my head. Thoughts?
> > 
> > Here's my opinion from a year back:
> > https://lore.barebox.org/barebox/1ff0f545-effa-4b87-81b7-524919333777@pengutronix.de/
> 
> Thanks for the link, I fogot that I've send somthing similar already ^^
> 
> > I am interested to hear thoughts on it.
> > Compared to our suggestion, there will be no eventual removal of the node.
> 
> Both your suggestions are very similar and provide a smother transistion
> though. I would like to get rid of the old OF-env handling completely
> and therefore prefer Sascha's approach a bit more. Having a fallback is
> good, but fallbacks tend to crumble over time since they aren't tested.

I like Ahmads approach with a different compatible better as it makes
clear that it's only used as a fallback. Whether we
remove the device tree nodes from the repository or not doesn't matter
now, we can decide that later with both approaches.

Sascha

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: [RFC PATCH] ARM: dts: i.MX8MP: remove barebox environment handling

[Ahmad Fatoum]

Hi,

On 2/11/26 1:53 PM, Sascha Hauer wrote:
> On Wed, Feb 11, 2026 at 11:14:51AM +0100, Marco Felsch wrote:
>> Hi Sascha, Ahmad,
>>
>> On 26-02-11, Ahmad Fatoum wrote:
>>> Hi,
>>>
>>> On 2/11/26 8:53 AM, Sascha Hauer wrote:
>>>> On Tue, Feb 10, 2026 at 11:13:40PM +0100, Marco Felsch wrote:
>>>>> While specifying the barebox environment within the barebox dts is very
>>>>> helpful for standalone barebox development it's difficult for BSPs which
>>>>> use this development platform and want to use the GPT mechanism.
>>>>> As a result BSPs had to manually delete the nodes via a external
>>>>> provided dts, because we wanted to keep the comfort for the standalone
>>>>> development flow.
>>>>>
>>>>> Lucky commit 86531d4bf7aa ("commands: create createnv command")
>>>>> introduced a convenient helper to create a barebox environemnt on
>>>>> demand exactly for this purpose:
>>>>>
>>>>> | "We want to move away from describing the barebox environment explicitly
>>>>> | in the device tree and instead motivate usage of GPT partitions.."
>>>>>
>>>>> So start with the i.MX8MP-EVK to encourage the use of GPT partitions and
>>>>> to make the BSP integration for these development platforms easier.
>>>>
>>>> Generally I like this idea, but it breaks the existing users
>>>> environment and doing this sharp cut might be annoying for the phase
>>>> where you switch between different barebox versions which could be quite
>>>> common for development boards.
>>
>> Good point, albeit commit 86531d4bf7aa is part of v2025.08.0, so it's
>> ~6months old. I also don't know how often i.MX8MP-EVK barebox features
>> are implemented which require to jump between barebox versions.
> 
> Jumping between versions is something that just happens, be it for
> bisecting or you have a development and stable branch for a BSP with
> different barebox versions.

Worth noting that we already have a way out: If someone's bisecting,
they can set global.env.autoprobe=0 (or disable CONFIG_INSECURE..) to
restore the old behavior.

> 
>>
>>>> Would be great to have a grace period in which we prefer the UUID
>>>> environment over the device tree environment (we might do this already)
>>>> and warn in case we still use the latter. We could stick the warning to
>>>> a device tree property like "warn-deprecated-env" and remove the
>>>> environment once they carry this property for a year or so.
>>>>
>>>> Just the ideas from the top of my head. Thoughts?
>>>
>>> Here's my opinion from a year back:
>>> https://lore.barebox.org/barebox/1ff0f545-effa-4b87-81b7-524919333777@pengutronix.de/
>>
>> Thanks for the link, I fogot that I've send somthing similar already ^^
>>
>>> I am interested to hear thoughts on it.
>>> Compared to our suggestion, there will be no eventual removal of the node.
>>
>> Both your suggestions are very similar and provide a smother transistion
>> though. I would like to get rid of the old OF-env handling completely
>> and therefore prefer Sascha's approach a bit more. Having a fallback is
>> good, but fallbacks tend to crumble over time since they aren't tested.
> 
> I like Ahmads approach with a different compatible better as it makes
> clear that it's only used as a fallback. Whether we
> remove the device tree nodes from the repository or not doesn't matter
> now, we can decide that later with both approaches.
> 
> Sascha
> 

-- 
Pengutronix e.K.                  |                             |
Steuerwalder Str. 21              | http://www.pengutronix.de/  |
31137 Hildesheim, Germany         | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686  | Fax:   +49-5121-206917-5555 |