linux-kernel - Re: [PATCH v4] iio: accel: adxl345: Add ACPI HID table

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: <CAHp75Vdja-9tjXDiR_aMFP3twNuTXtC3w1mkPo81pdM6dRya6Q@mail.gmail.com>
Date:   Fri, 18 Feb 2022 13:27:17 +0100
From:   Andy Shevchenko <andy.shevchenko@...il.com>
To:     Jonathan Cameron <jic23@...nel.org>
Cc:     Kai-Heng Feng <kai.heng.feng@...onical.com>,
        "lars@...afoo.de" <lars@...afoo.de>,
        "Michael.Hennerich@...log.com" <Michael.Hennerich@...log.com>,
        "linux-iio@...r.kernel.org" <linux-iio@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v4] iio: accel: adxl345: Add ACPI HID table

On Fri, Feb 18, 2022 at 1:03 PM Jonathan Cameron <jic23@...nel.org> wrote:
> On Fri, 18 Feb 2022 09:39:14 +0100
> Andy Shevchenko <andy.shevchenko@...il.com> wrote:
> > On Fri, Feb 18, 2022 at 4:46 AM Kai-Heng Feng
> > <kai.heng.feng@...onical.com> wrote:
> > > On Thu, Feb 17, 2022 at 6:57 PM Andy Shevchenko
> > > <andy.shevchenko@...il.com> wrote:
> > > > On Thursday, February 17, 2022, Kai-Heng Feng <kai.heng.feng@...onical.com> wrote:
> >
> > ...
> >
> > > >> +               acpi_id = acpi_match_device(dev->driver->acpi_match_table, dev);
> > > >> +               if (acpi_id) {
> > > >> +                       type = acpi_id->driver_data;
> > > >> +                       name = acpi_id->id;
> > > >> +               } else
> > > >> +                       return -ENODEV;
> > > >
> > > > Thanks, but can we do this in ACPI agnostic way?
> > > >
> > > > Can be as simple as
> > > >
> > > > if (id)
> > > >   ...
> > > > else {
> > > >   match = device_get_match_data(dev);
> > > >   if (!match)
> > > >     return -ENODEV;
> > > > }
> > > >
> > > > Note, it might require to reconsider what is put in the driver data (either convert to pointers, or be sure that valid type is never a 0/NULL).
> > >
> > > Unlike acpi_match_device(), device_get_match_data() only get
> > > driver_data, so we need a new struct to provide both name and type.
> >
> > It's unfortunate. Let me think about it a bit more.
> Usual solution is just to add that name to a per device type structure.
> In this particular case there isn't one so far though and an enum is used
> in the one place we might otherwise have used a part number specific structure.
>
> Probably the easiest thing to do is use the enum to do a lookup in an array
> of structures and have the string there.
>
> >
> > > > Also note, in both cases using ID name for name us fragile. Probably we have to fix that first. Let me check today’s evening.
> > >
> > > Can you please explain more on this? How does ID name make it fragile?
> >
> > I thought this one is used somehow by userspace to distinguish the
> > instance of the device, but looking into the rest of the IIO drivers
> > it seems more or less  a field for part number. That said, the ID is
> > okay to use. I hope Jonathan may correct me.
> >
> Should be part number.  Instances are distinguished via label rather than
> name (or via the device parent on older kernels where we didn't have
> label).
>
> There are a few places where we accidentally let though IDs that aren't
> always simply the part number and they became part of the ABI so we
> couldn't really fix them after the event.

Thanks for chiming in.
So, can we simply use dev_name() then? Or would it be too bad to have
the device instance name there?

-- 
With Best Regards,
Andy Shevchenko