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

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

[Darren Hart]

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.

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.
  */
 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;
 
 	buf = dmi_remap(dmi_base, dmi_len);
 	if (buf == NULL)
-		return -1;
+		return -ENOMEM;
 
 	dmi_decode_table(buf, decode, private_data);
 
diff --git a/include/linux/dmi.h b/include/linux/dmi.h
index 5e9c74c..9bbf21a 100644
--- a/include/linux/dmi.h
+++ b/include/linux/dmi.h
@@ -136,7 +136,7 @@ static inline int dmi_name_in_vendors(const char *s) { return 0; }
 static inline int dmi_name_in_serial(const char *s) { return 0; }
 #define dmi_available 0
 static inline int dmi_walk(void (*decode)(const struct dmi_header *, void *),
-	void *private_data) { return -1; }
+	void *private_data) { return -ENXIO; }
 static inline bool dmi_match(enum dmi_field f, const char *str)
 	{ return false; }
 static inline void dmi_memdev_name(u16 handle, const char **bank,
-- 
2.9.4

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

[Andy Shevchenko]

On Sat, May 27, 2017 at 2:59 AM, Darren Hart <dvhart@infradead.org> 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.
>

Obviously makes sense!

Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>

> 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.
>   */
>  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;
>
>         buf = dmi_remap(dmi_base, dmi_len);
>         if (buf == NULL)
> -               return -1;
> +               return -ENOMEM;
>
>         dmi_decode_table(buf, decode, private_data);
>
> diff --git a/include/linux/dmi.h b/include/linux/dmi.h
> index 5e9c74c..9bbf21a 100644
> --- a/include/linux/dmi.h
> +++ b/include/linux/dmi.h
> @@ -136,7 +136,7 @@ static inline int dmi_name_in_vendors(const char *s) { return 0; }
>  static inline int dmi_name_in_serial(const char *s) { return 0; }
>  #define dmi_available 0
>  static inline int dmi_walk(void (*decode)(const struct dmi_header *, void *),
> -       void *private_data) { return -1; }
> +       void *private_data) { return -ENXIO; }
>  static inline bool dmi_match(enum dmi_field f, const char *str)
>         { return false; }
>  static inline void dmi_memdev_name(u16 handle, const char **bank,
> --
> 2.9.4
>



-- 
With Best Regards,
Andy Shevchenko

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

[Jean Delvare]

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,
as when DMI support isn't included. I can't think of a reason why the
caller would treat both cases differently.

>  
>  	buf = dmi_remap(dmi_base, dmi_len);
>  	if (buf == NULL)
> -		return -1;
> +		return -ENOMEM;
>  
>  	dmi_decode_table(buf, decode, private_data);
>  
> diff --git a/include/linux/dmi.h b/include/linux/dmi.h
> index 5e9c74c..9bbf21a 100644
> --- a/include/linux/dmi.h
> +++ b/include/linux/dmi.h
> @@ -136,7 +136,7 @@ static inline int dmi_name_in_vendors(const char *s) { return 0; }
>  static inline int dmi_name_in_serial(const char *s) { return 0; }
>  #define dmi_available 0
>  static inline int dmi_walk(void (*decode)(const struct dmi_header *, void *),
> -	void *private_data) { return -1; }
> +	void *private_data) { return -ENXIO; }
>  static inline bool dmi_match(enum dmi_field f, const char *str)
>  	{ return false; }
>  static inline void dmi_memdev_name(u16 handle, const char **bank,


-- 
Jean Delvare
SUSE L3 Support

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

[Darren Hart]

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