On Wed, Oct 17, 2018 at 2:29 PM Russell King - ARM Linux <li...@armlinux.org.uk> wrote: > > On Tue, Oct 16, 2018 at 04:55:00PM +0300, Andy Shevchenko wrote: > > On Tue, Oct 16, 2018 at 3:55 PM Andrzej Hajda <a.ha...@samsung.com> wrote: > > > On 16.10.2018 13:29, Andrzej Hajda wrote: > > > > On 16.10.2018 13:01, Andy Shevchenko wrote: > > > >> On Tue, Oct 16, 2018 at 10:22 AM Andrzej Hajda <a.ha...@samsung.com> > > > >> wrote: > > > >>> During probe every time driver gets resource it should usually check > > > >>> for error > > > >>> printk some message if it is not -EPROBE_DEFER and return the error. > > > >>> This > > > >>> pattern is simple but requires adding few lines after any resource > > > >>> acquisition > > > >>> code, as a result it is often omited or implemented only partially. > > > >>> probe_err helps to replace such code seqences with simple call, so > > > >>> code: > > > >>> if (err != -EPROBE_DEFER) > > > >>> dev_err(dev, ...); > > > >>> return err; > > > >>> becomes: > > > >>> return probe_err(dev, err, ...); > > > > > >>> + va_start(args, fmt); > > > >>> + > > > >>> + vaf.fmt = fmt; > > > >>> + vaf.va = &args; > > > >>> + > > > >>> + __dev_printk(KERN_ERR, dev, &vaf); > > > > > >> It would be nice to print an error code as well, wouldn't it? > > > > Hmm, on probe fail error is printed anyway (with exception of > > > > EPROBE_DEFER, ENODEV and ENXIO): > > > > "probe of %s failed with error %d\n" > > > > On the other side currently some drivers prints the error code anyway > > > > via dev_err or similar, so I guess during conversion to probe_err it > > > > should be removed then. > > > > > > > > If we add error code to probe_err is it OK to report it this way? > > > > dev_err(dev, "%V, %d\n", &vaf, err); > > > > > > Ups, I forgot that message passed to probe_err will contain already > > > newline character. > > > > You may consider not to pass it. > > It's normal to pass the '\n', so by doing this, we create the situation > where this function becomes the exception to the norm. That's not a > good idea - we will see people forget that appending '\n' should not > be done for this particular function. > > While we could add a checkpatch rule, that's hassle (extra rework). In > any case, I think the message would be much better formatted if we did: > > dev_err(dev, "error %d: %V", err, &vaf); > > which means we end up with (eg): > > error -5: request_irq failed for irq 9 > > rather than: > > request_irq failed for irq 9, -5 > > which is more confusing.
As I said earlier, I'm fine to either variant and I see your point here, so, I tend to agree to this variant. P.S. Andrzej, in any case my Rb tag, which I just gave, stays. -- With Best Regards, Andy Shevchenko