From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Hans de Goede <hdegoede@redhat.com>
Cc: Mark Gross <mgross@linux.intel.com>, platform-driver-x86@vger.kernel.org
Subject: Re: [PATCH v1 3/4] platform/x86: i2c-multi-instantiate: Make number of clients unsigned
Date: Mon, 9 Nov 2020 13:53:16 +0200 [thread overview]
Message-ID: <20201109115316.GA4077@smile.fi.intel.com> (raw)
In-Reply-To: <f1ca37a0-85db-0edd-7f4c-14143254ebfe@redhat.com>
On Mon, Nov 09, 2020 at 12:39:45PM +0100, Hans de Goede wrote:
> On 11/5/20 12:05 PM, Andy Shevchenko wrote:
> > There is no need to use signed type for number of clients. Moreover,
> > it's cleaner to show that we never go negative there.
> >
> > Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
>
> I'm not a big fan of this change, it feels like needless churn to me.
Feel free to not apply it. I think I don't need to resend w/o it (IIRC the rest
pretty much independent of this change). But if you need a v2, tell me.
> Integers are signed by default and just because a value cannot become
> negative is not really a reason to make it unsigned. E.g. your typical
> "int i" is often used as an array index so it cannot go negative, still
> it almost always is an "int i" not an "unsigned int i".
>
> IMHO good reasons for deviating from the default signedness and
> making a value unsigned are:
>
> 1. Because the value cannot go negative and we need more range.
> 2. To avoid sign-extension when upcasting it to a larger integer type.
>
> Neither is the case here.
I consider one more, i.e. if we know that value may not be negative the
unsigned type gives a hint. I always stumbled over signed integers used for
loop counters since they confuse me (Q in mind: "should I read code carefully
and check if it may or may not be signed? Why it's signed?").
That's why I like the idea of be a bit stricter about types.
Hope this explains my motivation.
> I do like the other 3 patches, thank you for those. I'm going to wait
> a bit with applying them though, to see where things go with the
> "[RFC 0/4] platform/x86: i2c-multi-instantiate: Pass ACPI fwnode to instantiated i2c-clients"
>
> Merging them now may get in the way with merging that series if
> Wolfram wants to pick up the entire series (since it also involves
> an i2c-core change).
Usually I expect that RFC has less priority than normal series and I wouldn't
expect any maintainer (with some rare exceptions) to take series marked as RFC.
And TBH I was wondering why you marked them as such, to me that was fine to
send as normal one.
Thanks for the review!
--
With Best Regards,
Andy Shevchenko
next prev parent reply other threads:[~2020-11-09 11:52 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-05 11:05 [PATCH v1 1/4] platform/x86: i2c-multi-instantiate: Drop redundant ACPI_PTR() Andy Shevchenko
2020-11-05 11:05 ` [PATCH v1 2/4] platform/x86: i2c-multi-instantiate: Simplify with dev_err_probe() Andy Shevchenko
2020-11-05 11:05 ` [PATCH v1 3/4] platform/x86: i2c-multi-instantiate: Make number of clients unsigned Andy Shevchenko
2020-11-09 11:39 ` Hans de Goede
2020-11-09 11:53 ` Andy Shevchenko [this message]
2020-11-09 12:43 ` Hans de Goede
2020-11-05 11:05 ` [PATCH v1 4/4] platform/x86: i2c-multi-instantiate: Use device_get_match_data() to get driver data Andy Shevchenko
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=20201109115316.GA4077@smile.fi.intel.com \
--to=andriy.shevchenko@linux.intel.com \
--cc=hdegoede@redhat.com \
--cc=mgross@linux.intel.com \
--cc=platform-driver-x86@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox