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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ZiZEqDCqc01Cx3oq@smile.fi.intel.com>
Date: Mon, 22 Apr 2024 14:06:16 +0300
From: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To: Jonathan Cameron <jic23@...nel.org>
Cc: linux-iio@...r.kernel.org, linux-kernel@...r.kernel.org,
	Lars-Peter Clausen <lars@...afoo.de>,
	Martijn Braam <martijn@...xit.nl>
Subject: Re: [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@...ux.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@...ux.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