All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jean Delvare <jdelvare@suse.de>
To: Andy Shevchenko <andriy.shevchenko@intel.com>
Cc: Heiner Kallweit <hkallweit1@gmail.com>, linux-i2c@vger.kernel.org
Subject: Re: [PATCH v2 4/9] i2c: i801: Improve is_dell_system_with_lis3lv02d
Date: Thu, 26 Aug 2021 16:19:49 +0200	[thread overview]
Message-ID: <20210826161949.3fd7796b@endymion> (raw)
In-Reply-To: <YRTwCMgqmZmlExZk@smile.fi.intel.com>

On Thu, 12 Aug 2021 12:55:20 +0300, Andy Shevchenko wrote:
> On Wed, Aug 11, 2021 at 10:28:25PM +0200, Heiner Kallweit wrote:
> > On 11.08.2021 17:45, Andy Shevchenko wrote:  
> > > On Fri, Aug 06, 2021 at 11:15:15PM +0200, Heiner Kallweit wrote:  
> > >> Replace the ugly cast of the return_value pointer with proper usage.
> > >> In addition use dmi_match() instead of open-coding it.  
> > > 
> > > ...
> > >   
> > >> -	acpi_get_devices(NULL, check_acpi_smo88xx_device, NULL,
> > >> -			 (void **)&found);
> > >> +	acpi_get_devices(NULL, check_acpi_smo88xx_device, NULL, &err);
> > >>  
> > >> -	return found;
> > >> +	return !IS_ERR(err);  
> > > 
> > > Shouldn't you also check the status of acpi_get_device()?
> >
> > This shouldn't be needed because err isn't touched if function fails.  
> 
> For the sake of clearness of the code I would do it.

This brings us back to how awkward the API is. Most callers don't
bother checking the return value of acpi_get_devices() because it's
useless in practice. But I agree that in theory it could return with an
error and then it would be nicer to catch that.

> (...) But in any case what
> really hurt my eye is the last line here. To me sounds like
> 
> 	if (IS_ERR(err))
> 		return false;
> 	return true;
> 
> is much better to read (and I bet the compiler will generate the very same
> code for it).

Somehow the assembly code differs, but I'm unable to see the relation
between your proposed change and the assembly code changes. That's why
I hate modern compilers. They pretend to be smart, but what they are
essentially is unstable, and this ruins any attempt at such trivial
comparisons. Sad.

Personally I don't really care, Heiner's code did not strike me as
being hard to read in the first place. I tend to avoid conditionals
when possible.

-- 
Jean Delvare
SUSE L3 Support

  reply	other threads:[~2021-08-26 14:19 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-06 21:10 [PATCH v2 0/9] i2c: i801: Series with improvements Heiner Kallweit
2021-08-06 21:12 ` [PATCH v2 1/9] i2c: i801: Improve disabling runtime pm Heiner Kallweit
2021-08-10 20:37   ` Wolfram Sang
2021-08-11 15:41   ` Andy Shevchenko
2021-08-11 20:03     ` Heiner Kallweit
2021-08-12  9:48       ` Andy Shevchenko
2021-08-17 20:15         ` Wolfram Sang
2021-08-26 14:00           ` Jean Delvare
2021-08-26 14:34             ` Andy Shevchenko
2021-08-31  6:05             ` Heiner Kallweit
2021-08-31 11:26               ` Jean Delvare
2021-08-31 20:43                 ` Heiner Kallweit
2021-09-01  6:22                   ` Heiner Kallweit
2021-08-06 21:13 ` [PATCH v2 2/9] i2c: i801: make p2sb_spinlock a mutex Heiner Kallweit
2021-08-10 20:38   ` Wolfram Sang
2021-08-11 15:43   ` Andy Shevchenko
2021-08-11 20:27     ` Heiner Kallweit
2021-08-12  9:53       ` Andy Shevchenko
2021-08-06 21:14 ` [PATCH v2 3/9] i2c: i801: Remove not needed debug message Heiner Kallweit
2021-08-10 20:39   ` Wolfram Sang
2021-08-06 21:15 ` [PATCH v2 4/9] i2c: i801: Improve is_dell_system_with_lis3lv02d Heiner Kallweit
2021-08-11 15:45   ` Andy Shevchenko
2021-08-11 20:28     ` Heiner Kallweit
2021-08-12  9:55       ` Andy Shevchenko
2021-08-26 14:19         ` Jean Delvare [this message]
2021-08-26 13:21   ` Jean Delvare
2021-09-29 19:38   ` Wolfram Sang
2021-08-06 21:15 ` [PATCH v2 5/9] i2c: i801: Remove not needed check for PCI_COMMAND_INTX_DISABLE Heiner Kallweit
2021-08-11 15:46   ` Andy Shevchenko
2021-08-26 15:18   ` Jean Delvare
2021-09-29 19:38   ` Wolfram Sang
2021-08-06 21:16 ` [PATCH v2 6/9] i2c: i801: Improve i801_acpi_probe/remove functions Heiner Kallweit
2021-09-29 19:38   ` Wolfram Sang
2021-08-06 21:17 ` [PATCH v2 7/9] i2c: i801: Improve i801_add_mux Heiner Kallweit
2021-09-29 19:38   ` Wolfram Sang
2021-08-06 21:18 ` [PATCH v2 8/9] i2c: i801: Improve register_dell_lis3lv02d_i2c_device Heiner Kallweit
2021-08-11 15:52   ` Andy Shevchenko
2021-08-11 21:05     ` Heiner Kallweit
2021-08-12  9:57       ` Andy Shevchenko
2021-08-27 16:21       ` Jean Delvare
2021-09-29 20:11         ` Wolfram Sang
2021-10-01 11:46           ` Jean Delvare
2021-08-06 21:18 ` [PATCH v2 9/9] i2c: i801: Improve handling platform data for tco device Heiner Kallweit
2021-08-11 15:53   ` Andy Shevchenko
2021-10-02  7:44   ` Wolfram Sang
2021-11-29  8:58     ` Wolfram Sang
2021-11-29 19:54       ` Heiner Kallweit
2021-11-29 19:53 ` [PATCH v3] " Heiner Kallweit

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210826161949.3fd7796b@endymion \
    --to=jdelvare@suse.de \
    --cc=andriy.shevchenko@intel.com \
    --cc=hkallweit1@gmail.com \
    --cc=linux-i2c@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.