public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jean Delvare <jdelvare@suse.de>
To: Wolfram Sang <wsa@the-dreams.de>
Cc: Wolfram Sang <wsa+renesas@sang-engineering.com>,
	linux-i2c@vger.kernel.org,
	Benjamin Tissoires <benjamin.tissoires@redhat.com>,
	Phil Reid <preid@electromag.com.au>,
	Robert Richter <rrichter@marvell.com>,
	George Cherian <gcherian@marvell.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/3] i2c: convert SMBus alert setup function to return an ERRPTR
Date: Sat, 15 Feb 2020 09:11:39 +0100	[thread overview]
Message-ID: <20200215091139.0311bc7b@endymion> (raw)
In-Reply-To: <20200215065018.GA1005@ninjato>

On Sat, 15 Feb 2020 07:50:18 +0100, Wolfram Sang wrote:
> On Sat, Feb 15, 2020 at 07:20:20AM +0100, Jean Delvare wrote:
> > Hi Wolfram,
> > 
> > On Mon, 10 Feb 2020 18:29:25 +0100, Wolfram Sang wrote:  
> > > Only few drivers use this call, so drivers and I2C core are converted at
> > > once with this patch. By simply using i2c_new_client_device() instead of
> > > i2c_new_device(), we easily can return an ERRPTR for this function as
> > > well. To make out of tree users aware that something changed, the
> > > function is renamed to i2c_install_smbus_alert().  
> > 
> > I wouldn't bother renaming the function. Chances that there actually
> > are out-of-tree users of this function are pretty small, and if that is
> > the case, they can adjust their code easily in a way that is still
> > compatible with old kernels.  
> 
> Agreed, it is easy. But they need to *know* that they need to adjust.
> Build error makes it obvious. Otherwise, the code will compile and
> silently not work anymore, I am afraid.

The code will keep working as long as there is no error, which is a
rare situation. If/when it happens, they'll get a very visible error
message in their kernel log.

I understand that this makes them discover the problem later. But we
are talking about a case which most likely does not exist. On the other
hand, renaming makes compatibility harder to achieve for them in the
long term (#ifdefs needed forever), and it makes the work of the
distribution kernel maintainers harder.

I don't think we should make our lives harder to help people who keep
their kernel drivers out of tree. If they are not happy, they know what
they should do.

Just my 2 cents anyway, your call.

-- 
Jean Delvare
SUSE L3 Support

  reply	other threads:[~2020-02-15  8:11 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-10 17:29 [PATCH 0/3] i2c: updates to SMBus alert setup Wolfram Sang
2020-02-10 17:29 ` [PATCH 1/3] i2c: convert SMBus alert setup function to return an ERRPTR Wolfram Sang
2020-02-15  6:20   ` Jean Delvare
2020-02-15  6:50     ` Wolfram Sang
2020-02-15  8:11       ` Jean Delvare [this message]
2020-02-17  7:58   ` Robert Richter
2020-02-17  8:17     ` Wolfram Sang
2020-02-17  9:14       ` Luca Ceresoli
2020-02-17 10:00         ` Robert Richter
2020-02-17 13:29           ` Wolfram Sang
2020-02-10 17:29 ` [PATCH 2/3] i2c: rename of_i2c_setup_smbus_alert() to keep in sync Wolfram Sang
2020-02-10 17:29 ` [PATCH 3/3] i2c: smbus: remove outdated references to irq level triggers Wolfram Sang

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=20200215091139.0311bc7b@endymion \
    --to=jdelvare@suse.de \
    --cc=benjamin.tissoires@redhat.com \
    --cc=gcherian@marvell.com \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=preid@electromag.com.au \
    --cc=rrichter@marvell.com \
    --cc=wsa+renesas@sang-engineering.com \
    --cc=wsa@the-dreams.de \
    /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