Re: [PATCH v1 1/1] iio: light: stk3310: Drop most likely fake ACPI ID

[Andy Shevchenko <andriy.shevchenko@linux.intel.com>]

On Mon, Apr 22, 2024 at 02:04:23PM +0300, Andy Shevchenko wrote:
> 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.

P.S>
What I may agree on is to drop Fixes tag.

-- 
With Best Regards,
Andy Shevchenko