On 10/16/2018 09:22 AM, Andrzej Hajda wrote: > /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 probe_err function introduced recently, > ie. if probe_err will be called with -EPROBE_DEFER instead of printk the > message > will be attached to deferred device and printed when user read > devices_deferred > property. > > Signed-off-by: Andrzej Hajda <a.ha...@samsung.com> > --- > drivers/base/base.h | 3 +++ > drivers/base/core.c | 15 +++++++++------ > drivers/base/dd.c | 34 +++++++++++++++++++++++++++++++++- > 3 files changed, 45 insertions(+), 7 deletions(-) > > diff --git a/drivers/base/base.h b/drivers/base/base.h > index 7a419a7a6235..6f9371bfe40b 100644 > --- a/drivers/base/base.h > +++ b/drivers/base/base.h > @@ -75,6 +75,7 @@ struct device_private { > struct klist_node knode_driver; > struct klist_node knode_bus; > struct list_head deferred_probe; > + char *deferred_probe_msg; > struct device *device; > }; > #define to_device_private_parent(obj) \ > @@ -113,6 +114,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 __deferred_probe_set_msg(const struct device *dev, const char > *fmt, > + va_list args); > 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 23fabefb217a..df9895adf11b 100644 > --- a/drivers/base/core.c > +++ b/drivers/base/core.c > @@ -3076,6 +3076,7 @@ define_dev_printk_level(_dev_info, KERN_INFO); > * > * This helper implements common pattern present in probe functions for error > * checking: print message if the error is not -EPROBE_DEFER and propagate > it. > + * In case of -EPROBE_DEFER it sets defer probe reason. > * It replaces code sequence: > * if (err != -EPROBE_DEFER) > * dev_err(dev, ...); > @@ -3091,15 +3092,17 @@ int probe_err(const struct device *dev, int err, > const char *fmt, ...) > struct va_format vaf; > va_list args; > > - if (err != -EPROBE_DEFER) { > - va_start(args, fmt); > + va_start(args, fmt); > > - vaf.fmt = fmt; > - vaf.va = &args; > + vaf.fmt = fmt; > + vaf.va = &args; > > + if (err != -EPROBE_DEFER) > __dev_printk(KERN_ERR, dev, &vaf); > - va_end(args); > - } > + else > + __deferred_probe_set_msg(dev, fmt, args); > + > + va_end(args); > > return err; > } > diff --git a/drivers/base/dd.c b/drivers/base/dd.c > index 169412ee4ae8..e2f81e538d4b 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" > @@ -132,6 +133,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_msg); > + dev->p->deferred_probe_msg = NULL; > } > mutex_unlock(&deferred_probe_mutex); > } > @@ -202,6 +205,32 @@ void device_unblock_probing(void) > driver_deferred_probe_trigger(); > } > > +/* > + * __deferred_probe_set_msg() - Set defer probe reason message for device > + */ > +void __deferred_probe_set_msg(const struct device *dev, const char *fmt, > + va_list args) > +{ > + const int size = 128; > + char **p; > + int n; > + > + mutex_lock(&deferred_probe_mutex); > + > + p = &dev->p->deferred_probe_msg; > + if (!*p) { > + *p = kmalloc(size, GFP_KERNEL); > + if (!*p) > + goto end; > + } > + n = snprintf(*p, size, "%s %s: ", dev_driver_string(dev), > dev_name(dev)); > + if (n < size) > + vsnprintf(*p + n, size - n, fmt, args);
I wonder if the vsnprintf() return value should be checked and print a warning if the message was truncated. Probably 128 is enough for most error messages? Reviewed-by: Javier Martinez Canillas <javi...@redhat.com> Best regards, -- Javier Martinez Canillas Software Engineer - Desktop Hardware Enablement Red Hat