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 <l...@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 <l...@kernel.org> > > Cc: Jean Delvare <jdelv...@suse.com> > > Signed-off-by: Darren Hart (VMware) <dvh...@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
