lkml.org 
[lkml]   [2018]   [Feb]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH v2] i2c: i801: Register optional lis3lv02d i2c device on Dell machines
    On Tuesday 13 February 2018 16:55:00 Andy Shevchenko wrote:
    > On Mon, Feb 12, 2018 at 5:30 PM, Pali Rohár <pali.rohar@gmail.com> wrote:
    > > On Wednesday 31 January 2018 14:27:51 Andy Shevchenko wrote:
    > >> On Wed, Jan 31, 2018 at 2:03 PM, Pali Rohár <pali.rohar@gmail.com> wrote:
    > >> > On Sunday 28 January 2018 17:00:35 Andy Shevchenko wrote:
    > >> >> On Sun, Jan 28, 2018 at 4:45 PM, Pali Rohár <pali.rohar@gmail.com> wrote:
    > >>
    > >> >> > ACPI device name is SMO8800, SMO8810, ... Will that acpi_dev_present
    > >> >> > function match only prefix and not exact string?
    > >> >>
    > >> >> OK, fair enough.
    > >> >>
    > >> >> Do we have more users of such pattern?
    > >> >
    > >> > I have not seen this ACPI pattern yet, so probably not.
    > >>
    > >> I see. So, my one concern is the implicit names of the devices. I
    > >> would like rather to see
    > >>
    > >> ... acpi_device_id ... []= {
    > >> {"SMO8800"},
    > >> {"SMO8810"},
    > >> ...
    > >> {}
    > >> };
    > >
    > > Following table already exists in dell-smo8800.c file:
    > >
    > > static const struct acpi_device_id smo8800_ids[] = {
    > > { "SMO8800", 0 },
    > > { "SMO8801", 0 },
    > > { "SMO8810", 0 },
    > > { "SMO8811", 0 },
    > > { "SMO8820", 0 },
    > > { "SMO8821", 0 },
    > > { "SMO8830", 0 },
    > > { "SMO8831", 0 },
    > > { "", 0 },
    > > };
    > >
    > > MODULE_DEVICE_TABLE(acpi, smo8800_ids);
    > >
    > > Can we reuse it?
    >
    > > Maybe moving array smo8800_ids[] into some header file
    > > (which one?) and statically inline it?
    >
    > Bad idea.
    >
    > > Or having it only in
    > > dell-smo8800.c file and exporting its symbol?
    >
    > Even worse.
    >
    > > Or is there better idea?
    > >
    > > For sure I do not want to copy paste this table into another module and
    > > maintaining two copies of this list.
    >
    > The copy is fine. Can you guarantee that those two lists would be
    > always the same? I'm not.

    Me neither.

    > And besides that explicitly over implicitly is a really good thing. I
    > would not like to grep for an ID followed by grepping include line and
    > check each files to check if it uses it or not.

    So what do you suggest now?

    Having one file where it would be defined is a bad idea for you.
    And maintaining copy of same array in two different files in two
    different subsystems is something which I cannot guarantee.

    Therefore the current patch is the best approach. No shared file with
    shared array/table and also no copy of that array in two different
    subsystems.

    --
    Pali Rohár
    pali.rohar@gmail.com

    \
     
     \ /
      Last update: 2018-02-13 16:00    [W:4.500 / U:0.036 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site