lkml.org 
[lkml]   [2024]   [Apr]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v1 1/1] iio: light: stk3310: Drop most likely fake ACPI ID
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



\
 
 \ /
  Last update: 2024-05-27 17:55    [W:0.059 / U:0.328 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site