Linux IIO development
 help / color / mirror / Atom feed
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Jonathan Cameron <jic23@kernel.org>
Cc: linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org,
	Lars-Peter Clausen <lars@metafoo.de>,
	Martijn Braam <martijn@brixit.nl>
Subject: Re: [PATCH v1 1/1] iio: light: stk3310: Drop most likely fake ACPI ID
Date: Mon, 22 Apr 2024 14:04:23 +0300	[thread overview]
Message-ID: <ZiZEN807oywU-MAx@smile.fi.intel.com> (raw)
In-Reply-To: <20240420122633.79b4185b@jic23-huawei>

On Sat, Apr 20, 2024 at 12:26:33PM +0100, Jonathan Cameron wrote:
> On Mon, 15 Apr 2024 17:18:52 +0300
> Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
> 
> > The commit in question does not proove that ACPI ID exists.
> > Quite likely it was a cargo cult addition while doint that
> > for DT-based enumeration.  Drop most likely fake ACPI ID.
> > 
> > Googling for STK3335 gives no useful results in regard to DSDT.
> > 
> > Fixes: 677f16813a92 ("iio: light: stk3310: Add support for stk3335")
> > Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> Hi Andy,
> 
> It's been there quite a while (5 years) so whilst I agree it should
> never have gone in without a known DSDT in the wild, I'm not sure we
> should remove it at this point.
> 
> Definitely not with a fixes tag as I don't want to see this picked up
> for stable and breaking some old consumer device we don't know about.
> 
> If there is a good maintenance reason to scrap these I'm in favour,
> but if it's just tidying up errors from the past that have no
> real impact then I'm not so sure.
> 
> Maybe we need a 'deprecated' marking for acpi ids that always prints
> a message telling people not to make them up.  Mind you what would that
> do beyond make us feel better?

I prefer to find the actual users by removing these IDs. It's the best approach
to limiting the presence of wrong ID in time and at the same time harvesting
the actual (ab)users of it. Warning or other "soft" approaches makes rottening
just longer and _increases_ the chance of mis-use/abuse of these fake IDs.

I understand your position as a maintainer who can be blamed by mere user in
case we are (I am) mistaken, but I consider it the least harm than by
continuing "supporting" them. Feel free to NAK this patch, but for the record
I won't like this :-)

TL;DR: I do not buy 5 / 10 / etc years in the Linux kernel as an argument,
sorry.

-- 
With Best Regards,
Andy Shevchenko



  reply	other threads:[~2024-04-22 11:04 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-15 14:18 [PATCH v1 1/1] iio: light: stk3310: Drop most likely fake ACPI ID Andy Shevchenko
2024-04-20 11:26 ` Jonathan Cameron
2024-04-22 11:04   ` Andy Shevchenko [this message]
2024-04-22 11:06     ` Andy Shevchenko
2024-04-28 15:43       ` Jonathan Cameron
2024-04-29  8:37         ` 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=ZiZEN807oywU-MAx@smile.fi.intel.com \
    --to=andriy.shevchenko@linux.intel.com \
    --cc=jic23@kernel.org \
    --cc=lars@metafoo.de \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=martijn@brixit.nl \
    /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