[v2,0/9] drm: Switch from dev_err to dev_err_probe for missing DSI host error path

  This series changes every occurence of the following pattern: 

	dsi_host = of_find_mipi_dsi_host_by_node(dsi);
	if (!dsi_host) {
		dev_err(dev, "failed to find dsi host\n");
		return -EPROBE_DEFER;
	}

into

	dsi_host = of_find_mipi_dsi_host_by_node(dsi);
	if (!dsi_host)
		return dev_err_probe(dev, -EPROBE_DEFER, "failed to find dsi host\n");

This registers the defer probe reason (so it can later be printed by the
driver core or checked on demand through the devices_deferred file in
debugfs) and prevents errors to be spammed in the kernel log every time
the driver retries to probe, unnecessarily alerting userspace about
something that is a normal part of the boot process.

I have omitted a Fixes: tag in the last patch, for the truly-nt35597
panel, because it predates the dev_err_probe() helper.

Changes in v2:
- Added patches 2 onwards to fix all occurences of this pattern instead
  of just for the anx7625 driver
- Link to v1: https://lore.kernel.org/r/20240226-anx7625-defer-log-no-dsi-host-v1-1-242b1af31884@collabora.com

---
Nícolas F. R. A. Prado (9):
      drm/bridge: anx7625: Don't log an error when DSI host can't be found
      drm/bridge: icn6211: Don't log an error when DSI host can't be found
      drm/bridge: lt8912b: Don't log an error when DSI host can't be found
      drm/bridge: lt9611: Don't log an error when DSI host can't be found
      drm/bridge: lt9611uxc: Don't log an error when DSI host can't be found
      drm/bridge: tc358775: Don't log an error when DSI host can't be found
      drm/bridge: dpc3433: Don't log an error when DSI host can't be found
      drm/panel: novatek-nt35950: Don't log an error when DSI host can't be found
      drm/panel: truly-nt35597: Don't log an error when DSI host can't be found

 drivers/gpu/drm/bridge/analogix/anx7625.c     |  6 ++----
 drivers/gpu/drm/bridge/chipone-icn6211.c      |  6 ++----
 drivers/gpu/drm/bridge/lontium-lt8912b.c      |  6 ++----
 drivers/gpu/drm/bridge/lontium-lt9611.c       |  6 ++----
 drivers/gpu/drm/bridge/lontium-lt9611uxc.c    |  6 ++----
 drivers/gpu/drm/bridge/tc358775.c             |  6 ++----
 drivers/gpu/drm/bridge/ti-dlpc3433.c          | 17 +++++++++--------
 drivers/gpu/drm/panel/panel-novatek-nt35950.c |  6 ++----
 drivers/gpu/drm/panel/panel-truly-nt35597.c   |  6 ++----
 9 files changed, 25 insertions(+), 40 deletions(-)
---
base-commit: 2ae0a045e6814c8c1d676d6153c605a65746aa29
change-id: 20240226-anx7625-defer-log-no-dsi-host-c3f9ccbcb287

Best regards,
  

Hi Nícolas,

On Thu, Feb 29, 2024 at 07:12:06PM -0500, Nícolas F. R. A. Prado wrote:
> This series changes every occurence of the following pattern: 
> 
> 	dsi_host = of_find_mipi_dsi_host_by_node(dsi);
> 	if (!dsi_host) {
> 		dev_err(dev, "failed to find dsi host\n");
> 		return -EPROBE_DEFER;
> 	}
> 
> into
> 
> 	dsi_host = of_find_mipi_dsi_host_by_node(dsi);
> 	if (!dsi_host)
> 		return dev_err_probe(dev, -EPROBE_DEFER, "failed to find dsi host\n");
> 
> This registers the defer probe reason (so it can later be printed by the
> driver core or checked on demand through the devices_deferred file in
> debugfs) and prevents errors to be spammed in the kernel log every time
> the driver retries to probe, unnecessarily alerting userspace about
> something that is a normal part of the boot process.

The idea is good, but I have a small issue with patches 1/9 to 7/9. They
all patch a function that is called by the probe function. Calling
dev_err_probe() in such functions is error-prone. I had to manually
check when reviewing the patches that those functions were indeed called
at probe time, and not through other code paths, and I also had to check
that no callers were using dev_err_probe() in the error handling path,
as that would have overridden the error message.

Would there be a way to move the dev_err_probe() to the top-level ? I
understand it's not always possible or convenient, but if it was doable
in at least some of the drivers, I think it would be better. I'll let
you be the judge.

> I have omitted a Fixes: tag in the last patch, for the truly-nt35597
> panel, because it predates the dev_err_probe() helper.
> 
> Changes in v2:
> - Added patches 2 onwards to fix all occurences of this pattern instead
>   of just for the anx7625 driver
> - Link to v1: https://lore.kernel.org/r/20240226-anx7625-defer-log-no-dsi-host-v1-1-242b1af31884@collabora.com
> 
> ---
> Nícolas F. R. A. Prado (9):
>       drm/bridge: anx7625: Don't log an error when DSI host can't be found
>       drm/bridge: icn6211: Don't log an error when DSI host can't be found
>       drm/bridge: lt8912b: Don't log an error when DSI host can't be found
>       drm/bridge: lt9611: Don't log an error when DSI host can't be found
>       drm/bridge: lt9611uxc: Don't log an error when DSI host can't be found
>       drm/bridge: tc358775: Don't log an error when DSI host can't be found
>       drm/bridge: dpc3433: Don't log an error when DSI host can't be found
>       drm/panel: novatek-nt35950: Don't log an error when DSI host can't be found
>       drm/panel: truly-nt35597: Don't log an error when DSI host can't be found
> 
>  drivers/gpu/drm/bridge/analogix/anx7625.c     |  6 ++----
>  drivers/gpu/drm/bridge/chipone-icn6211.c      |  6 ++----
>  drivers/gpu/drm/bridge/lontium-lt8912b.c      |  6 ++----
>  drivers/gpu/drm/bridge/lontium-lt9611.c       |  6 ++----
>  drivers/gpu/drm/bridge/lontium-lt9611uxc.c    |  6 ++----
>  drivers/gpu/drm/bridge/tc358775.c             |  6 ++----
>  drivers/gpu/drm/bridge/ti-dlpc3433.c          | 17 +++++++++--------
>  drivers/gpu/drm/panel/panel-novatek-nt35950.c |  6 ++----
>  drivers/gpu/drm/panel/panel-truly-nt35597.c   |  6 ++----
>  9 files changed, 25 insertions(+), 40 deletions(-)
> ---
> base-commit: 2ae0a045e6814c8c1d676d6153c605a65746aa29
> change-id: 20240226-anx7625-defer-log-no-dsi-host-c3f9ccbcb287
  

On Fri, Mar 01, 2024 at 08:34:31AM +0200, Laurent Pinchart wrote:
> Hi Nícolas,
> 
> On Thu, Feb 29, 2024 at 07:12:06PM -0500, Nícolas F. R. A. Prado wrote:
> > This series changes every occurence of the following pattern: 
> > 
> > 	dsi_host = of_find_mipi_dsi_host_by_node(dsi);
> > 	if (!dsi_host) {
> > 		dev_err(dev, "failed to find dsi host\n");
> > 		return -EPROBE_DEFER;
> > 	}
> > 
> > into
> > 
> > 	dsi_host = of_find_mipi_dsi_host_by_node(dsi);
> > 	if (!dsi_host)
> > 		return dev_err_probe(dev, -EPROBE_DEFER, "failed to find dsi host\n");
> > 
> > This registers the defer probe reason (so it can later be printed by the
> > driver core or checked on demand through the devices_deferred file in
> > debugfs) and prevents errors to be spammed in the kernel log every time
> > the driver retries to probe, unnecessarily alerting userspace about
> > something that is a normal part of the boot process.
> 
> The idea is good, but I have a small issue with patches 1/9 to 7/9. They
> all patch a function that is called by the probe function. Calling
> dev_err_probe() in such functions is error-prone. I had to manually
> check when reviewing the patches that those functions were indeed called
> at probe time, and not through other code paths, and I also had to check
> that no callers were using dev_err_probe() in the error handling path,
> as that would have overridden the error message.
> 
> Would there be a way to move the dev_err_probe() to the top-level ? I
> understand it's not always possible or convenient, but if it was doable
> in at least some of the drivers, I think it would be better. I'll let
> you be the judge.

Hey Laurent, thanks for the review.

I get where you're coming from, as I checked those things myself while writing
the patch. That said, I don't think moving dev_err_probe() to the top-level is a
good move for a few reasons:
* Keeping the log message as close to the source of the error makes it more
  specific, and consequently, more useful.
* The original code already returned -EPROBE_DEFER, implying the function is
  expected to be called only from the probe function.

With those points in mind, the only way I see to guarantee
dev_err_probe(...,-EPROBE_DEFER...) would only be called by probe, and that the
reason wouldn't be overriden, would be to move the entire code path of that
function that calls into dev_err_probe() up into the probe function. But if we
adopt this pattern consistently across the drivers in the tree, I think it would
drastically worsen readability and cancel out the benefits.

IMO the way forward with the API we have, is to make use of warnings and static
checkers to catch cases where dev_err_probe() is overriding a defer probe
reason, and where it's called outside of the probe function scope.

So I'm inclined to leave the patches as they are, but am happy to discuss this
further or other ideas.

Thanks,
Nícolas
  

On Fri, Mar 01, 2024 at 11:19:27AM -0500, Nícolas F. R. A. Prado wrote:
> On Fri, Mar 01, 2024 at 08:34:31AM +0200, Laurent Pinchart wrote:
> > Hi Nícolas,
> > 
> > On Thu, Feb 29, 2024 at 07:12:06PM -0500, Nícolas F. R. A. Prado wrote:
> > > This series changes every occurence of the following pattern: 
> > > 
> > > 	dsi_host = of_find_mipi_dsi_host_by_node(dsi);
> > > 	if (!dsi_host) {
> > > 		dev_err(dev, "failed to find dsi host\n");
> > > 		return -EPROBE_DEFER;
> > > 	}
> > > 
> > > into
> > > 
> > > 	dsi_host = of_find_mipi_dsi_host_by_node(dsi);
> > > 	if (!dsi_host)
> > > 		return dev_err_probe(dev, -EPROBE_DEFER, "failed to find dsi host\n");
> > > 
> > > This registers the defer probe reason (so it can later be printed by the
> > > driver core or checked on demand through the devices_deferred file in
> > > debugfs) and prevents errors to be spammed in the kernel log every time
> > > the driver retries to probe, unnecessarily alerting userspace about
> > > something that is a normal part of the boot process.
> > 
> > The idea is good, but I have a small issue with patches 1/9 to 7/9. They
> > all patch a function that is called by the probe function. Calling
> > dev_err_probe() in such functions is error-prone. I had to manually
> > check when reviewing the patches that those functions were indeed called
> > at probe time, and not through other code paths, and I also had to check
> > that no callers were using dev_err_probe() in the error handling path,
> > as that would have overridden the error message.
> > 
> > Would there be a way to move the dev_err_probe() to the top-level ? I
> > understand it's not always possible or convenient, but if it was doable
> > in at least some of the drivers, I think it would be better. I'll let
> > you be the judge.
> 
> Hey Laurent, thanks for the review.
> 
> I get where you're coming from, as I checked those things myself while writing
> the patch. That said, I don't think moving dev_err_probe() to the top-level is a
> good move for a few reasons:
> * Keeping the log message as close to the source of the error makes it more
>   specific, and consequently, more useful.
> * The original code already returned -EPROBE_DEFER, implying the function is
>   expected to be called only from the probe function.
> 
> With those points in mind, the only way I see to guarantee
> dev_err_probe(...,-EPROBE_DEFER...) would only be called by probe, and that the
> reason wouldn't be overriden, would be to move the entire code path of that
> function that calls into dev_err_probe() up into the probe function. But if we
> adopt this pattern consistently across the drivers in the tree, I think it would
> drastically worsen readability and cancel out the benefits.
> 
> IMO the way forward with the API we have, is to make use of warnings and static
> checkers to catch cases where dev_err_probe() is overriding a defer probe
> reason, and where it's called outside of the probe function scope.
> 
> So I'm inclined to leave the patches as they are, but am happy to discuss this
> further or other ideas.

Thanks for checking and having taken the time to explain your rationale.
For the whole series,

Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>