All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 1/3] dm: core: Add DM_FLAG_PROBE_AFTER_BIND flag
@ 2022-04-22 13:15 Marek Vasut
  2022-04-22 13:15 ` [PATCH 2/3] led: Mark device instance with DM_FLAG_PROBE_AFTER_BIND Marek Vasut
                   ` (4 more replies)
  0 siblings, 5 replies; 17+ messages in thread
From: Marek Vasut @ 2022-04-22 13:15 UTC (permalink / raw)
  To: u-boot
  Cc: Marek Vasut, Patrice Chotard, Patrick Delaunay, Sean Anderson,
	Simon Glass, Steven Lawrance

Introduce DM_FLAG_PROBE_AFTER_BIND flag, which can be set by driver or
uclass in .bind(), to indicate such driver instance should be probe()d
once binding of all devices is complete.

This is useful in case the driver determines that hardware initialization
is mandatory on boot, and such initialization happens only in probe().
This also solves the inability to call device_probe() from .bind().

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Patrice Chotard <patrice.chotard@foss.st.com>
Cc: Patrick Delaunay <patrick.delaunay@foss.st.com>
Cc: Sean Anderson <seanga2@gmail.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Steven Lawrance <steven.lawrance@softathome.com>
---
 drivers/core/root.c | 24 +++++++++++++++++++++++-
 include/dm/device.h |  3 +++
 2 files changed, 26 insertions(+), 1 deletion(-)

diff --git a/drivers/core/root.c b/drivers/core/root.c
index e09c12f4d6e..17dd1205a32 100644
--- a/drivers/core/root.c
+++ b/drivers/core/root.c
@@ -361,6 +361,28 @@ void *dm_priv_to_rw(void *priv)
 }
 #endif
 
+static int dm_probe_devices(struct udevice *dev, bool pre_reloc_only)
+{
+	u32 mask = DM_FLAG_PROBE_AFTER_BIND;
+	u32 flags = dev_get_flags(dev);
+	struct udevice *child;
+	int ret;
+
+	if (pre_reloc_only)
+		mask |= DM_FLAG_PRE_RELOC;
+
+	if ((flags & mask) == mask) {
+		ret = device_probe(dev);
+		if (ret)
+			return ret;
+	}
+
+	list_for_each_entry(child, &dev->child_head, sibling_node)
+		dm_probe_devices(child, pre_reloc_only);
+
+	return 0;
+}
+
 /**
  * dm_scan() - Scan tables to bind devices
  *
@@ -393,7 +415,7 @@ static int dm_scan(bool pre_reloc_only)
 	if (ret)
 		return ret;
 
-	return 0;
+	return dm_probe_devices(gd->dm_root, pre_reloc_only);
 }
 
 int dm_init_and_scan(bool pre_reloc_only)
diff --git a/include/dm/device.h b/include/dm/device.h
index e0f86f5df9f..e7dd90399f9 100644
--- a/include/dm/device.h
+++ b/include/dm/device.h
@@ -80,6 +80,9 @@ struct driver_info;
  */
 #define DM_FLAG_VITAL			(1 << 14)
 
+/* Device must be probed after it was bound */
+#define DM_FLAG_PROBE_AFTER_BIND	(1 << 15)
+
 /*
  * One or multiple of these flags are passed to device_remove() so that
  * a selective device removal as specified by the remove-stage and the
-- 
2.35.1


^ permalink raw reply related	[flat|nested] 17+ messages in thread

* [PATCH 2/3] led: Mark device instance with DM_FLAG_PROBE_AFTER_BIND
  2022-04-22 13:15 [PATCH 1/3] dm: core: Add DM_FLAG_PROBE_AFTER_BIND flag Marek Vasut
@ 2022-04-22 13:15 ` Marek Vasut
  2022-04-22 13:44   ` Patrice CHOTARD
                     ` (2 more replies)
  2022-04-22 13:15 ` [PATCH 3/3] led: gpio: Check device compatible string to determine the top level node Marek Vasut
                   ` (3 subsequent siblings)
  4 siblings, 3 replies; 17+ messages in thread
From: Marek Vasut @ 2022-04-22 13:15 UTC (permalink / raw)
  To: u-boot
  Cc: Marek Vasut, Patrice Chotard, Patrick Delaunay, Sean Anderson,
	Simon Glass, Steven Lawrance

Calling device_probe() from uclass .post_bind() callback has all kinds
of odd side-effects, e.g. device instances not being available just yet.
Make use of the DM_FLAG_PROBE_AFTER_BIND instead, mark device instances
which need to be probe()d in order to configure the LED default state
with this flag and let the DM core do the device_probe() at the right
time instead.

Fixes: 72675b063b6 ("led: Configure LED default-state on boot")
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Patrice Chotard <patrice.chotard@foss.st.com>
Cc: Patrick Delaunay <patrick.delaunay@foss.st.com>
Cc: Sean Anderson <seanga2@gmail.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Steven Lawrance <steven.lawrance@softathome.com>
---
 drivers/led/led-uclass.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/led/led-uclass.c b/drivers/led/led-uclass.c
index 5d7bf40896b..2ce72933b6c 100644
--- a/drivers/led/led-uclass.c
+++ b/drivers/led/led-uclass.c
@@ -98,7 +98,9 @@ static int led_post_bind(struct udevice *dev)
 	 * In case the LED has default-state DT property, trigger
 	 * probe() to configure its default state during startup.
 	 */
-	return device_probe(dev);
+	dev_or_flags(dev, DM_FLAG_PROBE_AFTER_BIND);
+
+	return 0;
 }
 
 static int led_post_probe(struct udevice *dev)
-- 
2.35.1


^ permalink raw reply related	[flat|nested] 17+ messages in thread

* [PATCH 3/3] led: gpio: Check device compatible string to determine the top level node
  2022-04-22 13:15 [PATCH 1/3] dm: core: Add DM_FLAG_PROBE_AFTER_BIND flag Marek Vasut
  2022-04-22 13:15 ` [PATCH 2/3] led: Mark device instance with DM_FLAG_PROBE_AFTER_BIND Marek Vasut
@ 2022-04-22 13:15 ` Marek Vasut
  2022-04-22 13:45   ` Patrice CHOTARD
  2022-04-28 19:42   ` Tom Rini
  2022-04-22 13:43 ` [PATCH 1/3] dm: core: Add DM_FLAG_PROBE_AFTER_BIND flag Patrice CHOTARD
                   ` (2 subsequent siblings)
  4 siblings, 2 replies; 17+ messages in thread
From: Marek Vasut @ 2022-04-22 13:15 UTC (permalink / raw)
  To: u-boot
  Cc: Marek Vasut, Patrice Chotard, Patrick Delaunay, Sean Anderson,
	Simon Glass, Steven Lawrance

Since 2d1deaf88ed ("led: gpio: Drop duplicate OF "label" property parsing"),
all LED nodes have some sort of label. Use device_is_compatible(..."leds-gpio")
to determine whether this is a top-level node, since it is only the top
level node which is compatible with "leds-gpio", the GPIO LEDs subnodes
are not.

Fixes: 2d1deaf88ed ("led: gpio: Drop duplicate OF "label" property parsing")
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Patrice Chotard <patrice.chotard@foss.st.com>
Cc: Patrick Delaunay <patrick.delaunay@foss.st.com>
Cc: Sean Anderson <seanga2@gmail.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Steven Lawrance <steven.lawrance@softathome.com>
---
 drivers/led/led_gpio.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/led/led_gpio.c b/drivers/led/led_gpio.c
index 958dbd31e77..23156907593 100644
--- a/drivers/led/led_gpio.c
+++ b/drivers/led/led_gpio.c
@@ -57,12 +57,11 @@ static enum led_state_t gpio_led_get_state(struct udevice *dev)
 
 static int led_gpio_probe(struct udevice *dev)
 {
-	struct led_uc_plat *uc_plat = dev_get_uclass_plat(dev);
 	struct led_gpio_priv *priv = dev_get_priv(dev);
 	int ret;
 
 	/* Ignore the top-level LED node */
-	if (!uc_plat->label)
+	if (device_is_compatible(dev, "gpio-leds"))
 		return 0;
 
 	ret = gpio_request_by_name(dev, "gpios", 0, &priv->gpio, GPIOD_IS_OUT);
-- 
2.35.1


^ permalink raw reply related	[flat|nested] 17+ messages in thread

* Re: [PATCH 1/3] dm: core: Add DM_FLAG_PROBE_AFTER_BIND flag
  2022-04-22 13:15 [PATCH 1/3] dm: core: Add DM_FLAG_PROBE_AFTER_BIND flag Marek Vasut
  2022-04-22 13:15 ` [PATCH 2/3] led: Mark device instance with DM_FLAG_PROBE_AFTER_BIND Marek Vasut
  2022-04-22 13:15 ` [PATCH 3/3] led: gpio: Check device compatible string to determine the top level node Marek Vasut
@ 2022-04-22 13:43 ` Patrice CHOTARD
  2022-04-22 13:49 ` Sean Anderson
  2022-04-28 19:42 ` Tom Rini
  4 siblings, 0 replies; 17+ messages in thread
From: Patrice CHOTARD @ 2022-04-22 13:43 UTC (permalink / raw)
  To: Marek Vasut, u-boot
  Cc: Patrick Delaunay, Sean Anderson, Simon Glass, Steven Lawrance

Hi Marek

On 4/22/22 15:15, Marek Vasut wrote:
> Introduce DM_FLAG_PROBE_AFTER_BIND flag, which can be set by driver or
> uclass in .bind(), to indicate such driver instance should be probe()d
> once binding of all devices is complete.
> 
> This is useful in case the driver determines that hardware initialization
> is mandatory on boot, and such initialization happens only in probe().
> This also solves the inability to call device_probe() from .bind().
> 
> Signed-off-by: Marek Vasut <marex@denx.de>
> Cc: Patrice Chotard <patrice.chotard@foss.st.com>
> Cc: Patrick Delaunay <patrick.delaunay@foss.st.com>
> Cc: Sean Anderson <seanga2@gmail.com>
> Cc: Simon Glass <sjg@chromium.org>
> Cc: Steven Lawrance <steven.lawrance@softathome.com>
> ---
>  drivers/core/root.c | 24 +++++++++++++++++++++++-
>  include/dm/device.h |  3 +++
>  2 files changed, 26 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/core/root.c b/drivers/core/root.c
> index e09c12f4d6e..17dd1205a32 100644
> --- a/drivers/core/root.c
> +++ b/drivers/core/root.c
> @@ -361,6 +361,28 @@ void *dm_priv_to_rw(void *priv)
>  }
>  #endif
>  
> +static int dm_probe_devices(struct udevice *dev, bool pre_reloc_only)
> +{
> +	u32 mask = DM_FLAG_PROBE_AFTER_BIND;
> +	u32 flags = dev_get_flags(dev);
> +	struct udevice *child;
> +	int ret;
> +
> +	if (pre_reloc_only)
> +		mask |= DM_FLAG_PRE_RELOC;
> +
> +	if ((flags & mask) == mask) {
> +		ret = device_probe(dev);
> +		if (ret)
> +			return ret;
> +	}
> +
> +	list_for_each_entry(child, &dev->child_head, sibling_node)
> +		dm_probe_devices(child, pre_reloc_only);
> +
> +	return 0;
> +}
> +
>  /**
>   * dm_scan() - Scan tables to bind devices
>   *
> @@ -393,7 +415,7 @@ static int dm_scan(bool pre_reloc_only)
>  	if (ret)
>  		return ret;
>  
> -	return 0;
> +	return dm_probe_devices(gd->dm_root, pre_reloc_only);
>  }
>  
>  int dm_init_and_scan(bool pre_reloc_only)
> diff --git a/include/dm/device.h b/include/dm/device.h
> index e0f86f5df9f..e7dd90399f9 100644
> --- a/include/dm/device.h
> +++ b/include/dm/device.h
> @@ -80,6 +80,9 @@ struct driver_info;
>   */
>  #define DM_FLAG_VITAL			(1 << 14)
>  
> +/* Device must be probed after it was bound */
> +#define DM_FLAG_PROBE_AFTER_BIND	(1 << 15)
> +
>  /*
>   * One or multiple of these flags are passed to device_remove() so that
>   * a selective device removal as specified by the remove-stage and the


Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Tested-by: Patrice Chotard <patrice.chotard@foss.st.com>

Tested on stm32mp157c-dk2 board
Thanks
Patrice

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH 2/3] led: Mark device instance with DM_FLAG_PROBE_AFTER_BIND
  2022-04-22 13:15 ` [PATCH 2/3] led: Mark device instance with DM_FLAG_PROBE_AFTER_BIND Marek Vasut
@ 2022-04-22 13:44   ` Patrice CHOTARD
  2022-04-25 14:31   ` Tom Rini
  2022-04-28 19:42   ` Tom Rini
  2 siblings, 0 replies; 17+ messages in thread
From: Patrice CHOTARD @ 2022-04-22 13:44 UTC (permalink / raw)
  To: Marek Vasut, u-boot
  Cc: Patrick Delaunay, Sean Anderson, Simon Glass, Steven Lawrance

Hi Marek

On 4/22/22 15:15, Marek Vasut wrote:
> Calling device_probe() from uclass .post_bind() callback has all kinds
> of odd side-effects, e.g. device instances not being available just yet.
> Make use of the DM_FLAG_PROBE_AFTER_BIND instead, mark device instances
> which need to be probe()d in order to configure the LED default state
> with this flag and let the DM core do the device_probe() at the right
> time instead.
> 
> Fixes: 72675b063b6 ("led: Configure LED default-state on boot")
> Signed-off-by: Marek Vasut <marex@denx.de>
> Cc: Patrice Chotard <patrice.chotard@foss.st.com>
> Cc: Patrick Delaunay <patrick.delaunay@foss.st.com>
> Cc: Sean Anderson <seanga2@gmail.com>
> Cc: Simon Glass <sjg@chromium.org>
> Cc: Steven Lawrance <steven.lawrance@softathome.com>
> ---
>  drivers/led/led-uclass.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/led/led-uclass.c b/drivers/led/led-uclass.c
> index 5d7bf40896b..2ce72933b6c 100644
> --- a/drivers/led/led-uclass.c
> +++ b/drivers/led/led-uclass.c
> @@ -98,7 +98,9 @@ static int led_post_bind(struct udevice *dev)
>  	 * In case the LED has default-state DT property, trigger
>  	 * probe() to configure its default state during startup.
>  	 */
> -	return device_probe(dev);
> +	dev_or_flags(dev, DM_FLAG_PROBE_AFTER_BIND);
> +
> +	return 0;
>  }
>  
>  static int led_post_probe(struct udevice *dev)

Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Tested-by: Patrice Chotard <patrice.chotard@foss.st.com>

Tested on stm32mp157c-dk2 board
Thanks
Patrice

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH 3/3] led: gpio: Check device compatible string to determine the top level node
  2022-04-22 13:15 ` [PATCH 3/3] led: gpio: Check device compatible string to determine the top level node Marek Vasut
@ 2022-04-22 13:45   ` Patrice CHOTARD
  2022-04-28 19:42   ` Tom Rini
  1 sibling, 0 replies; 17+ messages in thread
From: Patrice CHOTARD @ 2022-04-22 13:45 UTC (permalink / raw)
  To: Marek Vasut, u-boot
  Cc: Patrick Delaunay, Sean Anderson, Simon Glass, Steven Lawrance

Hi Marek

On 4/22/22 15:15, Marek Vasut wrote:
> Since 2d1deaf88ed ("led: gpio: Drop duplicate OF "label" property parsing"),
> all LED nodes have some sort of label. Use device_is_compatible(..."leds-gpio")
> to determine whether this is a top-level node, since it is only the top
> level node which is compatible with "leds-gpio", the GPIO LEDs subnodes
> are not.
> 
> Fixes: 2d1deaf88ed ("led: gpio: Drop duplicate OF "label" property parsing")
> Signed-off-by: Marek Vasut <marex@denx.de>
> Cc: Patrice Chotard <patrice.chotard@foss.st.com>
> Cc: Patrick Delaunay <patrick.delaunay@foss.st.com>
> Cc: Sean Anderson <seanga2@gmail.com>
> Cc: Simon Glass <sjg@chromium.org>
> Cc: Steven Lawrance <steven.lawrance@softathome.com>
> ---
>  drivers/led/led_gpio.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/led/led_gpio.c b/drivers/led/led_gpio.c
> index 958dbd31e77..23156907593 100644
> --- a/drivers/led/led_gpio.c
> +++ b/drivers/led/led_gpio.c
> @@ -57,12 +57,11 @@ static enum led_state_t gpio_led_get_state(struct udevice *dev)
>  
>  static int led_gpio_probe(struct udevice *dev)
>  {
> -	struct led_uc_plat *uc_plat = dev_get_uclass_plat(dev);
>  	struct led_gpio_priv *priv = dev_get_priv(dev);
>  	int ret;
>  
>  	/* Ignore the top-level LED node */
> -	if (!uc_plat->label)
> +	if (device_is_compatible(dev, "gpio-leds"))
>  		return 0;
>  
>  	ret = gpio_request_by_name(dev, "gpios", 0, &priv->gpio, GPIOD_IS_OUT);

Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Tested-by: Patrice Chotard <patrice.chotard@foss.st.com>

Tested on stm32mp157c-dk2 board
Thanks
Patrice

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH 1/3] dm: core: Add DM_FLAG_PROBE_AFTER_BIND flag
  2022-04-22 13:15 [PATCH 1/3] dm: core: Add DM_FLAG_PROBE_AFTER_BIND flag Marek Vasut
                   ` (2 preceding siblings ...)
  2022-04-22 13:43 ` [PATCH 1/3] dm: core: Add DM_FLAG_PROBE_AFTER_BIND flag Patrice CHOTARD
@ 2022-04-22 13:49 ` Sean Anderson
  2022-04-22 13:52   ` Marek Vasut
  2022-04-28 19:42 ` Tom Rini
  4 siblings, 1 reply; 17+ messages in thread
From: Sean Anderson @ 2022-04-22 13:49 UTC (permalink / raw)
  To: Marek Vasut, u-boot
  Cc: Patrice Chotard, Patrick Delaunay, Simon Glass, Steven Lawrance

On 4/22/22 9:15 AM, Marek Vasut wrote:
> Introduce DM_FLAG_PROBE_AFTER_BIND flag, which can be set by driver or
> uclass in .bind(), to indicate such driver instance should be probe()d
> once binding of all devices is complete.
> 
> This is useful in case the driver determines that hardware initialization
> is mandatory on boot, and such initialization happens only in probe().
> This also solves the inability to call device_probe() from .bind().

So why not add an init_leds function to init_sequence_r?

--Sean


^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH 1/3] dm: core: Add DM_FLAG_PROBE_AFTER_BIND flag
  2022-04-22 13:49 ` Sean Anderson
@ 2022-04-22 13:52   ` Marek Vasut
  2022-04-22 22:45     ` Sean Anderson
  0 siblings, 1 reply; 17+ messages in thread
From: Marek Vasut @ 2022-04-22 13:52 UTC (permalink / raw)
  To: Sean Anderson, u-boot
  Cc: Patrice Chotard, Patrick Delaunay, Simon Glass, Steven Lawrance

On 4/22/22 15:49, Sean Anderson wrote:
> On 4/22/22 9:15 AM, Marek Vasut wrote:
>> Introduce DM_FLAG_PROBE_AFTER_BIND flag, which can be set by driver or
>> uclass in .bind(), to indicate such driver instance should be probe()d
>> once binding of all devices is complete.
>>
>> This is useful in case the driver determines that hardware initialization
>> is mandatory on boot, and such initialization happens only in probe().
>> This also solves the inability to call device_probe() from .bind().
> 
> So why not add an init_leds function to init_sequence_r?

Because this flag is generic solution and not hack specific to LEDs.

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH 1/3] dm: core: Add DM_FLAG_PROBE_AFTER_BIND flag
  2022-04-22 13:52   ` Marek Vasut
@ 2022-04-22 22:45     ` Sean Anderson
  2022-04-22 23:07       ` Marek Vasut
  0 siblings, 1 reply; 17+ messages in thread
From: Sean Anderson @ 2022-04-22 22:45 UTC (permalink / raw)
  To: Marek Vasut, u-boot
  Cc: Patrice Chotard, Patrick Delaunay, Simon Glass, Steven Lawrance

On 4/22/22 9:52 AM, Marek Vasut wrote:
> On 4/22/22 15:49, Sean Anderson wrote:
>> On 4/22/22 9:15 AM, Marek Vasut wrote:
>>> Introduce DM_FLAG_PROBE_AFTER_BIND flag, which can be set by driver or
>>> uclass in .bind(), to indicate such driver instance should be probe()d
>>> once binding of all devices is complete.
>>>
>>> This is useful in case the driver determines that hardware initialization
>>> is mandatory on boot, and such initialization happens only in probe().
>>> This also solves the inability to call device_probe() from .bind().
>>
>> So why not add an init_leds function to init_sequence_r?
> 
> Because this flag is generic solution and not hack specific to LEDs.

Isn't init_sequence_r the generic solution? Every device gets probed that
way (or directly as a result of a command).

--Sean

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH 1/3] dm: core: Add DM_FLAG_PROBE_AFTER_BIND flag
  2022-04-22 22:45     ` Sean Anderson
@ 2022-04-22 23:07       ` Marek Vasut
  2022-04-23  0:16         ` Sean Anderson
  0 siblings, 1 reply; 17+ messages in thread
From: Marek Vasut @ 2022-04-22 23:07 UTC (permalink / raw)
  To: Sean Anderson, u-boot
  Cc: Patrice Chotard, Patrick Delaunay, Simon Glass, Steven Lawrance

On 4/23/22 00:45, Sean Anderson wrote:
> On 4/22/22 9:52 AM, Marek Vasut wrote:
>> On 4/22/22 15:49, Sean Anderson wrote:
>>> On 4/22/22 9:15 AM, Marek Vasut wrote:
>>>> Introduce DM_FLAG_PROBE_AFTER_BIND flag, which can be set by driver or
>>>> uclass in .bind(), to indicate such driver instance should be probe()d
>>>> once binding of all devices is complete.
>>>>
>>>> This is useful in case the driver determines that hardware 
>>>> initialization
>>>> is mandatory on boot, and such initialization happens only in probe().
>>>> This also solves the inability to call device_probe() from .bind().
>>>
>>> So why not add an init_leds function to init_sequence_r?
>>
>> Because this flag is generic solution and not hack specific to LEDs.
> 
> Isn't init_sequence_r the generic solution?

No, init_sequence_r is just a list of functions that gets called early 
on during boot to bring U-Boot up. One of the functions is initr_dm(), 
DM init, which brings up the driver model. The init_sequence_r has 
nothing to do with driver binding or probing though, that's the DM job.

> Every device gets probed that way (or directly as a result of a command).

No device probe gets triggered via init_sequence_r. There are many 
ad-hoc device_probe() calls in the various init_sequence_r function 
implementation, but that's all there because there is no better way to 
implement that within the DM framework so far. Now there is, with this 
flag, so those workarounds can also be cleaned up.

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH 1/3] dm: core: Add DM_FLAG_PROBE_AFTER_BIND flag
  2022-04-22 23:07       ` Marek Vasut
@ 2022-04-23  0:16         ` Sean Anderson
  2022-04-23  2:02           ` Marek Vasut
  0 siblings, 1 reply; 17+ messages in thread
From: Sean Anderson @ 2022-04-23  0:16 UTC (permalink / raw)
  To: Marek Vasut, u-boot
  Cc: Patrice Chotard, Patrick Delaunay, Simon Glass, Steven Lawrance

On 4/22/22 7:07 PM, Marek Vasut wrote:
> On 4/23/22 00:45, Sean Anderson wrote:
>> On 4/22/22 9:52 AM, Marek Vasut wrote:
>>> On 4/22/22 15:49, Sean Anderson wrote:
>>>> On 4/22/22 9:15 AM, Marek Vasut wrote:
>>>>> Introduce DM_FLAG_PROBE_AFTER_BIND flag, which can be set by driver or
>>>>> uclass in .bind(), to indicate such driver instance should be probe()d
>>>>> once binding of all devices is complete.
>>>>>
>>>>> This is useful in case the driver determines that hardware initialization
>>>>> is mandatory on boot, and such initialization happens only in probe().
>>>>> This also solves the inability to call device_probe() from .bind().
>>>>
>>>> So why not add an init_leds function to init_sequence_r?
>>>
>>> Because this flag is generic solution and not hack specific to LEDs.
>>
>> Isn't init_sequence_r the generic solution?
> 
> No, init_sequence_r is just a list of functions that gets called early on during boot to bring U-Boot up. One of the functions is initr_dm(), DM init, which brings up the driver model. The init_sequence_r has nothing to do with driver binding or probing though, that's the DM job.
> 
>> Every device gets probed that way (or directly as a result of a command).
> 
> No device probe gets triggered via init_sequence_r.
> There are many ad-hoc device_probe() calls in the various init_sequence_r function implementation,

Every device in U-Boot is probed in one of three ways

- As a dependency of another device (clocks, pinmuxes, gpios, etc.)
- Directly on the command line (most boot devices)
- From an init_sequence (timers, watchdogs, serial, PCI, gpio hogs, etc.)

The goal of course being to minimize the amount of probed devices. This of course requires having
some things at the "root" of the tree. In Linux, everything bound is probed until nothing more can
be probed. In that sense, under Linux everything is the "root" of the tree. But for U-Boot the
second two options specify the "roots."

Some of the things in init_sequence are ad-hoc, especially the non-DM stuff. LEDs are pretty ad-hoc,
last I checked, but that's mainly because there are 2-3 separate non-DM ways to control LEDs.

> but that's all there because there is no better way to implement that within the DM framework so far. Now there is, with this flag, so those workarounds can also be cleaned up.

This *is* within the DM framework. Adding a flag which is set on bound devices has the same effect
as dm_mux_init does when called from initr_dm_devices. The only difference is implementation. So
why is this better?

--Sean

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH 1/3] dm: core: Add DM_FLAG_PROBE_AFTER_BIND flag
  2022-04-23  0:16         ` Sean Anderson
@ 2022-04-23  2:02           ` Marek Vasut
  0 siblings, 0 replies; 17+ messages in thread
From: Marek Vasut @ 2022-04-23  2:02 UTC (permalink / raw)
  To: Sean Anderson, u-boot
  Cc: Patrice Chotard, Patrick Delaunay, Simon Glass, Steven Lawrance

On 4/23/22 02:16, Sean Anderson wrote:
> On 4/22/22 7:07 PM, Marek Vasut wrote:
>> On 4/23/22 00:45, Sean Anderson wrote:
>>> On 4/22/22 9:52 AM, Marek Vasut wrote:
>>>> On 4/22/22 15:49, Sean Anderson wrote:
>>>>> On 4/22/22 9:15 AM, Marek Vasut wrote:
>>>>>> Introduce DM_FLAG_PROBE_AFTER_BIND flag, which can be set by 
>>>>>> driver or
>>>>>> uclass in .bind(), to indicate such driver instance should be 
>>>>>> probe()d
>>>>>> once binding of all devices is complete.
>>>>>>
>>>>>> This is useful in case the driver determines that hardware 
>>>>>> initialization
>>>>>> is mandatory on boot, and such initialization happens only in 
>>>>>> probe().
>>>>>> This also solves the inability to call device_probe() from .bind().
>>>>>
>>>>> So why not add an init_leds function to init_sequence_r?
>>>>
>>>> Because this flag is generic solution and not hack specific to LEDs.
>>>
>>> Isn't init_sequence_r the generic solution?
>>
>> No, init_sequence_r is just a list of functions that gets called early 
>> on during boot to bring U-Boot up. One of the functions is initr_dm(), 
>> DM init, which brings up the driver model. The init_sequence_r has 
>> nothing to do with driver binding or probing though, that's the DM job.
>>
>>> Every device gets probed that way (or directly as a result of a 
>>> command).
>>
>> No device probe gets triggered via init_sequence_r.
>> There are many ad-hoc device_probe() calls in the various 
>> init_sequence_r function implementation,
> 
> Every device in U-Boot is probed in one of three ways
> 
> - As a dependency of another device (clocks, pinmuxes, gpios, etc.)
> - Directly on the command line (most boot devices)
> - From an init_sequence (timers, watchdogs, serial, PCI, gpio hogs, etc.)

In short, the DM does lazy initialization of devices to boot quickly and 
waste few resources.

> The goal of course being to minimize the amount of probed devices.

This was never the goal. The probe() is called when needed, that's all.

> This of course requires having
> some things at the "root" of the tree. In Linux, everything bound is 
> probed until nothing more can
> be probed. In that sense, under Linux everything is the "root" of the 
> tree. But for U-Boot the
> second two options specify the "roots."
> 
> Some of the things in init_sequence are ad-hoc, especially the non-DM 
> stuff. LEDs are pretty ad-hoc,
> last I checked, but that's mainly because there are 2-3 separate non-DM 
> ways to control LEDs.

I'm not sure I understand this part, but maybe see

doc/develop/driver-model/design.rst

that should clarify the design decisions behind the DM.

>> but that's all there because there is no better way to implement that 
>> within the DM framework so far. Now there is, with this flag, so those 
>> workarounds can also be cleaned up.
> 
> This *is* within the DM framework.

No, init_sequence_r/init_sequence_f is U-Boot init sequence. The DM init 
is only one step in that init sequence. Please do not conflate those two 
concepts.

> Adding a flag which is set on bound 
> devices has the same effect
> as dm_mux_init does when called from initr_dm_devices.

This cannot scale, you would have to add a huge list of such functions 
to init_sequence_r/init_sequence_f probably for each uclass, which would 
each do some sort of ad-hoc device_probe(), outside of DM. And neither 
of those functions would have easy access to the context of each driver 
instance, so they would have to work around that somehow (that's usually 
done by wasting cycles on traversing DT again or other such heuristics).

> The only 
> difference is implementation. So
> why is this better?

See above. Also, this implementation is within the context of DM, i.e. 
driver/uclass bind call sets this flag for driver instances which for 
some reason need to be probe()d. The reason can be inferred from the 
driver instance context, e.g. because the DT node matching the driver 
instance contains some DT property, this flag is set, and the DM core 
probes the driver instead of only binding it. No need for any ad-hoc 
workarounds in init code.

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH 2/3] led: Mark device instance with DM_FLAG_PROBE_AFTER_BIND
  2022-04-22 13:15 ` [PATCH 2/3] led: Mark device instance with DM_FLAG_PROBE_AFTER_BIND Marek Vasut
  2022-04-22 13:44   ` Patrice CHOTARD
@ 2022-04-25 14:31   ` Tom Rini
  2022-04-25 16:43     ` Marek Vasut
  2022-04-28 19:42   ` Tom Rini
  2 siblings, 1 reply; 17+ messages in thread
From: Tom Rini @ 2022-04-25 14:31 UTC (permalink / raw)
  To: Marek Vasut
  Cc: u-boot, Patrice Chotard, Patrick Delaunay, Sean Anderson,
	Simon Glass, Steven Lawrance

[-- Attachment #1: Type: text/plain, Size: 1383 bytes --]

On Fri, Apr 22, 2022 at 03:15:54PM +0200, Marek Vasut wrote:

> Calling device_probe() from uclass .post_bind() callback has all kinds
> of odd side-effects, e.g. device instances not being available just yet.
> Make use of the DM_FLAG_PROBE_AFTER_BIND instead, mark device instances
> which need to be probe()d in order to configure the LED default state
> with this flag and let the DM core do the device_probe() at the right
> time instead.
> 
> Fixes: 72675b063b6 ("led: Configure LED default-state on boot")
> Signed-off-by: Marek Vasut <marex@denx.de>
> Cc: Patrice Chotard <patrice.chotard@foss.st.com>
> Cc: Patrick Delaunay <patrick.delaunay@foss.st.com>
> Cc: Sean Anderson <seanga2@gmail.com>
> Cc: Simon Glass <sjg@chromium.org>
> Cc: Steven Lawrance <steven.lawrance@softathome.com>
> Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
> Tested-by: Patrice Chotard <patrice.chotard@foss.st.com>
> ---
>  drivers/led/led-uclass.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)

This breaks all of the sandbox tests, which perhaps need another update
for what you've changed here?  I already had to tweak them once in 
72675b063b6e ("led: Configure LED default-state on boot").  But my
perhaps incorrect read then was that the dts / test weren't quite right
to start with.  Perhaps that's still the case however?

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH 2/3] led: Mark device instance with DM_FLAG_PROBE_AFTER_BIND
  2022-04-25 14:31   ` Tom Rini
@ 2022-04-25 16:43     ` Marek Vasut
  0 siblings, 0 replies; 17+ messages in thread
From: Marek Vasut @ 2022-04-25 16:43 UTC (permalink / raw)
  To: Tom Rini
  Cc: u-boot, Patrice Chotard, Patrick Delaunay, Sean Anderson,
	Simon Glass, Steven Lawrance

On 4/25/22 16:31, Tom Rini wrote:
> On Fri, Apr 22, 2022 at 03:15:54PM +0200, Marek Vasut wrote:
> 
>> Calling device_probe() from uclass .post_bind() callback has all kinds
>> of odd side-effects, e.g. device instances not being available just yet.
>> Make use of the DM_FLAG_PROBE_AFTER_BIND instead, mark device instances
>> which need to be probe()d in order to configure the LED default state
>> with this flag and let the DM core do the device_probe() at the right
>> time instead.
>>
>> Fixes: 72675b063b6 ("led: Configure LED default-state on boot")
>> Signed-off-by: Marek Vasut <marex@denx.de>
>> Cc: Patrice Chotard <patrice.chotard@foss.st.com>
>> Cc: Patrick Delaunay <patrick.delaunay@foss.st.com>
>> Cc: Sean Anderson <seanga2@gmail.com>
>> Cc: Simon Glass <sjg@chromium.org>
>> Cc: Steven Lawrance <steven.lawrance@softathome.com>
>> Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
>> Tested-by: Patrice Chotard <patrice.chotard@foss.st.com>
>> ---
>>   drivers/led/led-uclass.c | 4 +++-
>>   1 file changed, 3 insertions(+), 1 deletion(-)
> 
> This breaks all of the sandbox tests, which perhaps need another update
> for what you've changed here?  I already had to tweak them once in
> 72675b063b6e ("led: Configure LED default-state on boot").  But my
> perhaps incorrect read then was that the dts / test weren't quite right
> to start with.  Perhaps that's still the case however?

Pick these two test fixes:

[PATCH 1/2] test: dm: led: Fix LED enumeration
[PATCH 2/2] test: dm: pinmux: Get LED2 udevice in the pinmux test

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH 1/3] dm: core: Add DM_FLAG_PROBE_AFTER_BIND flag
  2022-04-22 13:15 [PATCH 1/3] dm: core: Add DM_FLAG_PROBE_AFTER_BIND flag Marek Vasut
                   ` (3 preceding siblings ...)
  2022-04-22 13:49 ` Sean Anderson
@ 2022-04-28 19:42 ` Tom Rini
  4 siblings, 0 replies; 17+ messages in thread
From: Tom Rini @ 2022-04-28 19:42 UTC (permalink / raw)
  To: Marek Vasut
  Cc: u-boot, Patrice Chotard, Patrick Delaunay, Sean Anderson,
	Simon Glass, Steven Lawrance

[-- Attachment #1: Type: text/plain, Size: 946 bytes --]

On Fri, Apr 22, 2022 at 03:15:53PM +0200, Marek Vasut wrote:

> Introduce DM_FLAG_PROBE_AFTER_BIND flag, which can be set by driver or
> uclass in .bind(), to indicate such driver instance should be probe()d
> once binding of all devices is complete.
> 
> This is useful in case the driver determines that hardware initialization
> is mandatory on boot, and such initialization happens only in probe().
> This also solves the inability to call device_probe() from .bind().
> 
> Signed-off-by: Marek Vasut <marex@denx.de>
> Cc: Patrice Chotard <patrice.chotard@foss.st.com>
> Cc: Patrick Delaunay <patrick.delaunay@foss.st.com>
> Cc: Sean Anderson <seanga2@gmail.com>
> Cc: Simon Glass <sjg@chromium.org>
> Cc: Steven Lawrance <steven.lawrance@softathome.com>
> Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
> Tested-by: Patrice Chotard <patrice.chotard@foss.st.com>

Applied to u-boot/master, thanks!

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH 2/3] led: Mark device instance with DM_FLAG_PROBE_AFTER_BIND
  2022-04-22 13:15 ` [PATCH 2/3] led: Mark device instance with DM_FLAG_PROBE_AFTER_BIND Marek Vasut
  2022-04-22 13:44   ` Patrice CHOTARD
  2022-04-25 14:31   ` Tom Rini
@ 2022-04-28 19:42   ` Tom Rini
  2 siblings, 0 replies; 17+ messages in thread
From: Tom Rini @ 2022-04-28 19:42 UTC (permalink / raw)
  To: Marek Vasut
  Cc: u-boot, Patrice Chotard, Patrick Delaunay, Sean Anderson,
	Simon Glass, Steven Lawrance

[-- Attachment #1: Type: text/plain, Size: 983 bytes --]

On Fri, Apr 22, 2022 at 03:15:54PM +0200, Marek Vasut wrote:

> Calling device_probe() from uclass .post_bind() callback has all kinds
> of odd side-effects, e.g. device instances not being available just yet.
> Make use of the DM_FLAG_PROBE_AFTER_BIND instead, mark device instances
> which need to be probe()d in order to configure the LED default state
> with this flag and let the DM core do the device_probe() at the right
> time instead.
> 
> Fixes: 72675b063b6 ("led: Configure LED default-state on boot")
> Signed-off-by: Marek Vasut <marex@denx.de>
> Cc: Patrice Chotard <patrice.chotard@foss.st.com>
> Cc: Patrick Delaunay <patrick.delaunay@foss.st.com>
> Cc: Sean Anderson <seanga2@gmail.com>
> Cc: Simon Glass <sjg@chromium.org>
> Cc: Steven Lawrance <steven.lawrance@softathome.com>
> Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
> Tested-by: Patrice Chotard <patrice.chotard@foss.st.com>

Applied to u-boot/master, thanks!

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH 3/3] led: gpio: Check device compatible string to determine the top level node
  2022-04-22 13:15 ` [PATCH 3/3] led: gpio: Check device compatible string to determine the top level node Marek Vasut
  2022-04-22 13:45   ` Patrice CHOTARD
@ 2022-04-28 19:42   ` Tom Rini
  1 sibling, 0 replies; 17+ messages in thread
From: Tom Rini @ 2022-04-28 19:42 UTC (permalink / raw)
  To: Marek Vasut
  Cc: u-boot, Patrice Chotard, Patrick Delaunay, Sean Anderson,
	Simon Glass, Steven Lawrance

[-- Attachment #1: Type: text/plain, Size: 933 bytes --]

On Fri, Apr 22, 2022 at 03:15:55PM +0200, Marek Vasut wrote:

> Since 2d1deaf88ed ("led: gpio: Drop duplicate OF "label" property parsing"),
> all LED nodes have some sort of label. Use device_is_compatible(..."leds-gpio")
> to determine whether this is a top-level node, since it is only the top
> level node which is compatible with "leds-gpio", the GPIO LEDs subnodes
> are not.
> 
> Fixes: 2d1deaf88ed ("led: gpio: Drop duplicate OF "label" property parsing")
> Signed-off-by: Marek Vasut <marex@denx.de>
> Cc: Patrice Chotard <patrice.chotard@foss.st.com>
> Cc: Patrick Delaunay <patrick.delaunay@foss.st.com>
> Cc: Sean Anderson <seanga2@gmail.com>
> Cc: Simon Glass <sjg@chromium.org>
> Cc: Steven Lawrance <steven.lawrance@softathome.com>
> Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
> Tested-by: Patrice Chotard <patrice.chotard@foss.st.com>

Applied to u-boot/master, thanks!

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

^ permalink raw reply	[flat|nested] 17+ messages in thread

end of thread, other threads:[~2022-04-28 19:43 UTC | newest]

Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-04-22 13:15 [PATCH 1/3] dm: core: Add DM_FLAG_PROBE_AFTER_BIND flag Marek Vasut
2022-04-22 13:15 ` [PATCH 2/3] led: Mark device instance with DM_FLAG_PROBE_AFTER_BIND Marek Vasut
2022-04-22 13:44   ` Patrice CHOTARD
2022-04-25 14:31   ` Tom Rini
2022-04-25 16:43     ` Marek Vasut
2022-04-28 19:42   ` Tom Rini
2022-04-22 13:15 ` [PATCH 3/3] led: gpio: Check device compatible string to determine the top level node Marek Vasut
2022-04-22 13:45   ` Patrice CHOTARD
2022-04-28 19:42   ` Tom Rini
2022-04-22 13:43 ` [PATCH 1/3] dm: core: Add DM_FLAG_PROBE_AFTER_BIND flag Patrice CHOTARD
2022-04-22 13:49 ` Sean Anderson
2022-04-22 13:52   ` Marek Vasut
2022-04-22 22:45     ` Sean Anderson
2022-04-22 23:07       ` Marek Vasut
2022-04-23  0:16         ` Sean Anderson
2022-04-23  2:02           ` Marek Vasut
2022-04-28 19:42 ` Tom Rini

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.