Re: [PATCH] dmi: Make dmi_walk and dmi_walk_early return real error codes

[Darren Hart <dvhart@infradead.org>]

On Thu, Jun 01, 2017 at 10:05:43AM +0200, Jean Delvare wrote:
> Hi Darren,
> 
> On Fri, 26 May 2017 16:59:17 -0700, Darren Hart wrote:
> > From: Andy Lutomirski <luto@kernel.org>
> > 
> > Currently they return -1 on error, which will confuse callers if
> > they try to interpret it as a normal negative error code.
> 
> I thought would had fixed this already, but apparently not.
> 
> > Signed-off-by: Andy Lutomirski <luto@kernel.org>
> > Cc: Jean Delvare <jdelvare@suse.com>
> > Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>
> > ---
> >  drivers/firmware/dmi_scan.c | 9 +++++----
> >  include/linux/dmi.h         | 2 +-
> >  2 files changed, 6 insertions(+), 5 deletions(-)
> > 
> > diff --git a/drivers/firmware/dmi_scan.c b/drivers/firmware/dmi_scan.c
> > index 54be60e..08b3c8b 100644
> > --- a/drivers/firmware/dmi_scan.c
> > +++ b/drivers/firmware/dmi_scan.c
> > @@ -144,7 +144,7 @@ static int __init dmi_walk_early(void (*decode)(const struct dmi_header *,
> >  
> >  	buf = dmi_early_remap(dmi_base, orig_dmi_len);
> >  	if (buf == NULL)
> > -		return -1;
> > +		return -ENOMEM;
> >  
> >  	dmi_decode_table(buf, decode, NULL);
> >  
> > @@ -992,7 +992,8 @@ EXPORT_SYMBOL(dmi_get_date);
> >   *	@decode: Callback function
> >   *	@private_data: Private data to be passed to the callback function
> >   *
> > - *	Returns -1 when the DMI table can't be reached, 0 on success.
> > + *	Returns 0 on success, -ENXIO if DMI is not selected or not present,
> > + *	or a different negative error code if DMI walking fails.
> 
> You document this...
> 
> >   */
> >  int dmi_walk(void (*decode)(const struct dmi_header *, void *),
> >  	     void *private_data)
> > @@ -1000,11 +1001,11 @@ int dmi_walk(void (*decode)(const struct dmi_header *, void *),
> >  	u8 *buf;
> >  
> >  	if (!dmi_available)
> > -		return -1;
> > +		return -ENOENT;
> 
> ... but implementation differs? I think you should return -ENXIO here,

Hrm, the comment does also say "or not present" which I agree with you can be
interpreted to equate to the !dmi_available condition above.

> as when DMI support isn't included. I can't think of a reason why the
> caller would treat both cases differently.

Considering the definitions for ENXIO and ENOENT, ENXIO seems closer to both
scenarios. I'll send a v2 with ENXIO is both locations.

Thanks for catching this.

-- 
Darren Hart
VMware Open Source Technology Center