Hi All,
Thanks for comments.
Changes since v8:
- fixed typo in function name,
- removed cocci script (added by mistake)
Changes since v7:
- improved commit message
- added R-Bs
Changes since v6:
- removed leftovers from old naming scheme in commit descritions,
- added R-Bs.
Changes since v5:
- removed patch adding macro, dev_err_probe(dev, PTR_ERR(ptr), ...) should be used instead,
- added dev_dbg logging in case of -EPROBE_DEFER,
- renamed functions and vars according to comments,
- extended docs,
- cosmetics.
Original message (with small adjustments):
Recently I took some time to re-check error handling in drivers probe code,
and I have noticed that number of incorrect resource acquisition error handling
increased and there are no other propositions which can cure the situation.
So I have decided to resend my old proposition of probe_err helper which should
simplify resource acquisition error handling, it also extend it with adding defer
probe reason to devices_deferred debugfs property, which should improve debugging
experience for developers/testers.
I have also added two patches showing usage and benefits of the helper.
My dirty/ad-hoc cocci scripts shows that this helper can be used in at least 2700 places
saving about 3500 lines of code.
Regards
Andrzej
Andrzej Hajda (4):
driver core: add device probe log helper
driver core: add deferring probe reason to devices_deferred property
drm/bridge/sii8620: fix resource acquisition error handling
drm/bridge: lvds-codec: simplify error handling
drivers/base/base.h | 3 ++
drivers/base/core.c | 46 ++++++++++++++++++++++++++++
drivers/base/dd.c | 23 +++++++++++++-
drivers/gpu/drm/bridge/lvds-codec.c | 10 ++----
drivers/gpu/drm/bridge/sil-sii8620.c | 21 ++++++-------
include/linux/device.h | 3 ++
6 files changed, 86 insertions(+), 20 deletions(-)
--
2.17.1
Using dev_err_probe code has following advantages:
- shorter code,
- recorded defer probe reason for debugging,
- uniform error code logging.
Signed-off-by: Andrzej Hajda <[email protected]>
Reviewed-by: Neil Armstrong <[email protected]>
---
drivers/gpu/drm/bridge/lvds-codec.c | 10 +++-------
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/bridge/lvds-codec.c b/drivers/gpu/drm/bridge/lvds-codec.c
index 24fb1befdfa2..f19d9f7a5db2 100644
--- a/drivers/gpu/drm/bridge/lvds-codec.c
+++ b/drivers/gpu/drm/bridge/lvds-codec.c
@@ -71,13 +71,9 @@ static int lvds_codec_probe(struct platform_device *pdev)
lvds_codec->connector_type = (uintptr_t)of_device_get_match_data(dev);
lvds_codec->powerdown_gpio = devm_gpiod_get_optional(dev, "powerdown",
GPIOD_OUT_HIGH);
- if (IS_ERR(lvds_codec->powerdown_gpio)) {
- int err = PTR_ERR(lvds_codec->powerdown_gpio);
-
- if (err != -EPROBE_DEFER)
- dev_err(dev, "powerdown GPIO failure: %d\n", err);
- return err;
- }
+ if (IS_ERR(lvds_codec->powerdown_gpio))
+ return dev_err_probe(dev, PTR_ERR(lvds_codec->powerdown_gpio),
+ "powerdown GPIO failure\n");
/* Locate the panel DT node. */
panel_node = of_graph_get_remote_node(dev->of_node, 1, 0);
--
2.17.1
/sys/kernel/debug/devices_deferred property contains list of deferred devices.
This list does not contain reason why the driver deferred probe, the patch
improves it.
The natural place to set the reason is dev_err_probe function introduced
recently, ie. if dev_err_probe will be called with -EPROBE_DEFER instead of
printk the message will be attached to a deferred device and printed when user
reads devices_deferred property.
Signed-off-by: Andrzej Hajda <[email protected]>
Reviewed-by: Mark Brown <[email protected]>
Reviewed-by: Javier Martinez Canillas <[email protected]>
Reviewed-by: Andy Shevchenko <[email protected]>
Reviewed-by: Rafael J. Wysocki <[email protected]>
---
v9:
- fixed typo in function name
v8:
- improved commit message
---
drivers/base/base.h | 3 +++
drivers/base/core.c | 8 ++++++--
drivers/base/dd.c | 23 ++++++++++++++++++++++-
3 files changed, 31 insertions(+), 3 deletions(-)
diff --git a/drivers/base/base.h b/drivers/base/base.h
index 95c22c0f9036..c3562adf4789 100644
--- a/drivers/base/base.h
+++ b/drivers/base/base.h
@@ -93,6 +93,7 @@ struct device_private {
struct klist_node knode_class;
struct list_head deferred_probe;
struct device_driver *async_driver;
+ char *deferred_probe_reason;
struct device *device;
u8 dead:1;
};
@@ -134,6 +135,8 @@ extern void device_release_driver_internal(struct device *dev,
extern void driver_detach(struct device_driver *drv);
extern int driver_probe_device(struct device_driver *drv, struct device *dev);
extern void driver_deferred_probe_del(struct device *dev);
+extern void device_set_deferred_probe_reason(const struct device *dev,
+ struct va_format *vaf);
static inline int driver_match_device(struct device_driver *drv,
struct device *dev)
{
diff --git a/drivers/base/core.c b/drivers/base/core.c
index 3a827c82933f..d04d19458795 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -3963,6 +3963,8 @@ define_dev_printk_level(_dev_info, KERN_INFO);
* This helper implements common pattern present in probe functions for error
* checking: print debug or error message depending if the error value is
* -EPROBE_DEFER and propagate error upwards.
+ * In case of -EPROBE_DEFER it sets also defer probe reason, which can be
+ * checked later by reading devices_deferred debugfs attribute.
* It replaces code sequence:
* if (err != -EPROBE_DEFER)
* dev_err(dev, ...);
@@ -3984,10 +3986,12 @@ int dev_err_probe(const struct device *dev, int err, const char *fmt, ...)
vaf.fmt = fmt;
vaf.va = &args;
- if (err != -EPROBE_DEFER)
+ if (err != -EPROBE_DEFER) {
dev_err(dev, "error %d: %pV", err, &vaf);
- else
+ } else {
+ device_set_deferred_probe_reason(dev, &vaf);
dev_dbg(dev, "error %d: %pV", err, &vaf);
+ }
va_end(args);
diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index 9a1d940342ac..7555b31bdfdc 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -27,6 +27,7 @@
#include <linux/async.h>
#include <linux/pm_runtime.h>
#include <linux/pinctrl/devinfo.h>
+#include <linux/slab.h>
#include "base.h"
#include "power/power.h"
@@ -136,6 +137,8 @@ void driver_deferred_probe_del(struct device *dev)
if (!list_empty(&dev->p->deferred_probe)) {
dev_dbg(dev, "Removed from deferred list\n");
list_del_init(&dev->p->deferred_probe);
+ kfree(dev->p->deferred_probe_reason);
+ dev->p->deferred_probe_reason = NULL;
}
mutex_unlock(&deferred_probe_mutex);
}
@@ -211,6 +214,23 @@ void device_unblock_probing(void)
driver_deferred_probe_trigger();
}
+/**
+ * device_set_deferred_probe_reason() - Set defer probe reason message for device
+ * @dev: the pointer to the struct device
+ * @vaf: the pointer to va_format structure with message
+ */
+void device_set_deferred_probe_reason(const struct device *dev, struct va_format *vaf)
+{
+ const char *drv = dev_driver_string(dev);
+
+ mutex_lock(&deferred_probe_mutex);
+
+ kfree(dev->p->deferred_probe_reason);
+ dev->p->deferred_probe_reason = kasprintf(GFP_KERNEL, "%s: %pV", drv, vaf);
+
+ mutex_unlock(&deferred_probe_mutex);
+}
+
/*
* deferred_devs_show() - Show the devices in the deferred probe pending list.
*/
@@ -221,7 +241,8 @@ static int deferred_devs_show(struct seq_file *s, void *data)
mutex_lock(&deferred_probe_mutex);
list_for_each_entry(curr, &deferred_probe_pending_list, deferred_probe)
- seq_printf(s, "%s\n", dev_name(curr->device));
+ seq_printf(s, "%s\t%s", dev_name(curr->device),
+ curr->device->p->deferred_probe_reason ?: "\n");
mutex_unlock(&deferred_probe_mutex);
--
2.17.1
Hi Greg,
Apparently the patchset has no more comments.
Could you take the patches to your tree? At least 1st and 2nd.
Regards
Andrzej
On 13.07.2020 16:43, Andrzej Hajda wrote:
> Hi All,
>
> Thanks for comments.
>
> Changes since v8:
> - fixed typo in function name,
> - removed cocci script (added by mistake)
>
> Changes since v7:
> - improved commit message
> - added R-Bs
>
> Changes since v6:
> - removed leftovers from old naming scheme in commit descritions,
> - added R-Bs.
>
> Changes since v5:
> - removed patch adding macro, dev_err_probe(dev, PTR_ERR(ptr), ...) should be used instead,
> - added dev_dbg logging in case of -EPROBE_DEFER,
> - renamed functions and vars according to comments,
> - extended docs,
> - cosmetics.
>
> Original message (with small adjustments):
>
> Recently I took some time to re-check error handling in drivers probe code,
> and I have noticed that number of incorrect resource acquisition error handling
> increased and there are no other propositions which can cure the situation.
>
> So I have decided to resend my old proposition of probe_err helper which should
> simplify resource acquisition error handling, it also extend it with adding defer
> probe reason to devices_deferred debugfs property, which should improve debugging
> experience for developers/testers.
>
> I have also added two patches showing usage and benefits of the helper.
>
> My dirty/ad-hoc cocci scripts shows that this helper can be used in at least 2700 places
> saving about 3500 lines of code.
>
> Regards
> Andrzej
>
>
> Andrzej Hajda (4):
> driver core: add device probe log helper
> driver core: add deferring probe reason to devices_deferred property
> drm/bridge/sii8620: fix resource acquisition error handling
> drm/bridge: lvds-codec: simplify error handling
>
> drivers/base/base.h | 3 ++
> drivers/base/core.c | 46 ++++++++++++++++++++++++++++
> drivers/base/dd.c | 23 +++++++++++++-
> drivers/gpu/drm/bridge/lvds-codec.c | 10 ++----
> drivers/gpu/drm/bridge/sil-sii8620.c | 21 ++++++-------
> include/linux/device.h | 3 ++
> 6 files changed, 86 insertions(+), 20 deletions(-)
>
On Tue, Jul 28, 2020 at 05:05:03PM +0200, Andrzej Hajda wrote:
> Hi Greg,
>
> Apparently the patchset has no more comments.
>
> Could you take the patches to your tree? At least 1st and 2nd.
All now queued up, thanks!
greg k-h
On Thu, Jul 30, 2020 at 12:10 AM Greg Kroah-Hartman
<[email protected]> wrote:
>
> On Tue, Jul 28, 2020 at 05:05:03PM +0200, Andrzej Hajda wrote:
> > Hi Greg,
> >
> > Apparently the patchset has no more comments.
> >
> > Could you take the patches to your tree? At least 1st and 2nd.
>
> All now queued up, thanks!
I believe it still has not been answered why this can't be pushed into
resource providers (clock, regulators, gpio, interrupts, etc),
especially for devm APIs where we know exactly what device we are
requesting a resource for, so that individual drivers do not need to
change anything. We can mark the device as being probed so that probe
deferral is only handled when we actually execute probe() (and for the
bonus points scream loudly if someone tries to return -EPROBE_DEFER
outside of probe path).
And now with coccinelle script we can expect a deluge of patches
reshuffling drivers...
Thanks.
--
Dmitry
On Thu, Jul 30, 2020 at 09:18:30AM -0700, Dmitry Torokhov wrote:
> I believe it still has not been answered why this can't be pushed into
> resource providers (clock, regulators, gpio, interrupts, etc),
> especially for devm APIs where we know exactly what device we are
> requesting a resource for, so that individual drivers do not need to
> change anything.
The error messages are frequently in the caller rather than the
frameworks, it's often helpful for the comprehensibility of the error
messages especially in cases where things may be legitimately absent.
> We can mark the device as being probed so that probe
> deferral is only handled when we actually execute probe() (and for the
> bonus points scream loudly if someone tries to return -EPROBE_DEFER
> outside of probe path).
Is this a big issue?
On Thu, Jul 30, 2020 at 9:49 AM Mark Brown <[email protected]> wrote:
>
> On Thu, Jul 30, 2020 at 09:18:30AM -0700, Dmitry Torokhov wrote:
>
> > I believe it still has not been answered why this can't be pushed into
> > resource providers (clock, regulators, gpio, interrupts, etc),
> > especially for devm APIs where we know exactly what device we are
> > requesting a resource for, so that individual drivers do not need to
> > change anything.
>
> The error messages are frequently in the caller rather than the
> frameworks, it's often helpful for the comprehensibility of the error
> messages especially in cases where things may be legitimately absent.
Not for deferral. All you need to know in this case is:
"device A is attempting to request resource B which is not ready yet"
There is nothing to handle on the caller part except to float the error up.
>
> > We can mark the device as being probed so that probe
> > deferral is only handled when we actually execute probe() (and for the
> > bonus points scream loudly if someone tries to return -EPROBE_DEFER
> > outside of probe path).
>
> Is this a big issue?
We do not know ;) Probably not. It will just get reported as an
ordinary failure and the driver will handle it somehow. Still it would
be nice to know if we attempt to raise deferrals in code paths where
they do not make sense.
Thanks.
--
Dmitry
On Thu, Jul 30, 2020 at 10:46:31AM -0700, Dmitry Torokhov wrote:
> On Thu, Jul 30, 2020 at 9:49 AM Mark Brown <[email protected]> wrote:
> > The error messages are frequently in the caller rather than the
> > frameworks, it's often helpful for the comprehensibility of the error
> > messages especially in cases where things may be legitimately absent.
> Not for deferral. All you need to know in this case is:
> "device A is attempting to request resource B which is not ready yet"
> There is nothing to handle on the caller part except to float the error up.
You can sometimes do a better job of explaining what the resource you
were looking for was, and of course you still need diagnostics in the
non-deferral case. Whatever happens we'll need a lot of per-driver
churn, either removing existing diagnostics that get factored into cores
or updating to use this new API.
On Thu, Jul 30, 2020 at 11:16 AM Mark Brown <[email protected]> wrote:
>
> On Thu, Jul 30, 2020 at 10:46:31AM -0700, Dmitry Torokhov wrote:
> > On Thu, Jul 30, 2020 at 9:49 AM Mark Brown <[email protected]> wrote:
>
> > > The error messages are frequently in the caller rather than the
> > > frameworks, it's often helpful for the comprehensibility of the error
> > > messages especially in cases where things may be legitimately absent.
>
> > Not for deferral. All you need to know in this case is:
>
> > "device A is attempting to request resource B which is not ready yet"
>
> > There is nothing to handle on the caller part except to float the error up.
>
> You can sometimes do a better job of explaining what the resource you
> were looking for was,
I think it is true for very esoteric cases. I.e. your driver uses 2
interrupt lines, or something like that. For GPIO, regulators, and
clocks we normally have a name/connection ID that provides enough of
context. We need to remember, the error messages really only make
total sense to a person familiar with the driver to begin with, not
for a random person looking at the log.
> and of course you still need diagnostics in the
> non-deferral case. Whatever happens we'll need a lot of per-driver
> churn, either removing existing diagnostics that get factored into cores
> or updating to use this new API.
The point is if you push it into core you'll get the benefit of
notifying about the deferral (and can "attach" deferral reason to a
device) without changing drivers at all. You can clean them up later
if you want, or decide that additional logging in error paths does not
hurt. This new API does not do you any good unless you convert
drivers, and you need to convert the majority of them to be able to
rely on the deferral diagnostic that is being added.
Thanks.
--
Dmitry
On Thu, Jul 30, 2020 at 11:45:25AM -0700, Dmitry Torokhov wrote:
> On Thu, Jul 30, 2020 at 11:16 AM Mark Brown <[email protected]> wrote:
> > You can sometimes do a better job of explaining what the resource you
> > were looking for was,
> I think it is true for very esoteric cases. I.e. your driver uses 2
> interrupt lines, or something like that. For GPIO, regulators, and
> clocks we normally have a name/connection ID that provides enough of
*Normally* but not always - some of the older bindings do love their
arrays of phandles (or mixes of numbers and phandles!) unfortunately.
> context. We need to remember, the error messages really only make
> total sense to a person familiar with the driver to begin with, not
> for a random person looking at the log.
Not really, one of the big targets is people doing system integration
who are writing a DT or possibly producing a highly tuned kernel config.
They needn't have a strong familiarity with the driver, they're often
just picking it up off the shelf.
> > and of course you still need diagnostics in the
> > non-deferral case. Whatever happens we'll need a lot of per-driver
> > churn, either removing existing diagnostics that get factored into cores
> > or updating to use this new API.
> The point is if you push it into core you'll get the benefit of
> notifying about the deferral (and can "attach" deferral reason to a
> device) without changing drivers at all. You can clean them up later
> if you want, or decide that additional logging in error paths does not
> hurt. This new API does not do you any good unless you convert
> drivers, and you need to convert the majority of them to be able to
> rely on the deferral diagnostic that is being added.
The push for this is that there's already people going around modifying
drivers whatever happens but at present they're mainly trying to delete
diagnostics which isn't wonderful. Besides, even if we push things into
the subsystems they'd want to use this interface or something quite like
it anyway - it's more a question of if we go quickly add some users to
subsystems isn't it? I'm not against that.