Message ID | 20240229-anx7625-defer-log-no-dsi-host-v2-0-00506941049a@collabora.com (mailing list archive) |
---|---|
Headers | show |
Series | drm: Switch from dev_err to dev_err_probe for missing DSI host error path | expand |
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
Il 01/03/24 01:12, Nícolas F. R. A. Prado ha scritto: > 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 > Apart from patch [8/9], where you're going over 100 cols, this series looks good. After fixing that, on v3, please feel free to add my.... Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> ...to all of the patches in this series (and the one that you'll fix as well). Cheers! Angelo > --- > 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,
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>