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 <[email protected]>
---
drivers/iio/light/stk3310.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/iio/light/stk3310.c b/drivers/iio/light/stk3310.c
index 7b71ad71d78d..08d471438175 100644
--- a/drivers/iio/light/stk3310.c
+++ b/drivers/iio/light/stk3310.c
@@ -693,7 +693,6 @@ MODULE_DEVICE_TABLE(i2c, stk3310_i2c_id);
static const struct acpi_device_id stk3310_acpi_id[] = {
{"STK3310", 0},
{"STK3311", 0},
- {"STK3335", 0},
{}
};
--
2.43.0.rc1.1336.g36b5255a03ac
On Mon, 15 Apr 2024 17:18:52 +0300
Andy Shevchenko <[email protected]> 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 <[email protected]>
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?
Jonathan
> ---
> drivers/iio/light/stk3310.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/iio/light/stk3310.c b/drivers/iio/light/stk3310.c
> index 7b71ad71d78d..08d471438175 100644
> --- a/drivers/iio/light/stk3310.c
> +++ b/drivers/iio/light/stk3310.c
> @@ -693,7 +693,6 @@ MODULE_DEVICE_TABLE(i2c, stk3310_i2c_id);
> static const struct acpi_device_id stk3310_acpi_id[] = {
> {"STK3310", 0},
> {"STK3311", 0},
> - {"STK3335", 0},
> {}
> };
>
On Sat, Apr 20, 2024 at 12:26:33PM +0100, Jonathan Cameron wrote:
> On Mon, 15 Apr 2024 17:18:52 +0300
> Andy Shevchenko <[email protected]> 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 <[email protected]>
> 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
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 <[email protected]> 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 <[email protected]>
> > 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
On Mon, 22 Apr 2024 14:06:16 +0300
Andy Shevchenko <[email protected]> wrote:
> 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 <[email protected]> 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 <[email protected]>
> > > 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.
>
That's a compromise I'm fine with. As long as we've done due diligence on
whether there are known cases we can take the risk of breaking someone (briefly)
if these turn out to be in use.
Applied,
On Sun, Apr 28, 2024 at 04:43:33PM +0100, Jonathan Cameron wrote:
> On Mon, 22 Apr 2024 14:06:16 +0300
> Andy Shevchenko <[email protected]> wrote:
> > On Mon, Apr 22, 2024 at 02:04:23PM +0300, Andy Shevchenko wrote:
..
> > P.S>
> > What I may agree on is to drop Fixes tag.
> >
> That's a compromise I'm fine with. As long as we've done due diligence on
> whether there are known cases we can take the risk of breaking someone (briefly)
> if these turn out to be in use.
I'll try to remember not putting Fixes in similar patches in the future,
if any.
> Applied,
Thank you!
--
With Best Regards,
Andy Shevchenko