From: Andy Shevchenko <andy.shevchenko@gmail.com> To: Hans de Goede <hdegoede@redhat.com> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>, Laurent Pinchart <laurent.pinchart@ideasonboard.com>, Dan Scally <djrscally@gmail.com>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, ACPI Devel Maling List <linux-acpi@vger.kernel.org>, "open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>, linux-i2c <linux-i2c@vger.kernel.org>, Linux Media Mailing List <linux-media@vger.kernel.org>, devel@acpica.org, "Rafael J. Wysocki" <rjw@rjwysocki.net>, Len Brown <lenb@kernel.org>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Mika Westerberg <mika.westerberg@linux.intel.com>, Linus Walleij <linus.walleij@linaro.org>, Bartosz Golaszewski <bgolaszewski@baylibre.com>, Wolfram Sang <wsa@kernel.org>, Yong Zhi <yong.zhi@intel.com>, Sakari Ailus <sakari.ailus@linux.intel.com>, Bingbu Cao <bingbu.cao@intel.com>, Tian Shu Qiu <tian.shu.qiu@intel.com>, Mauro Carvalho Chehab <mchehab@kernel.org>, Robert Moore <robert.moore@intel.com>, Erik Kaneda <erik.kaneda@intel.com>, Petr Mladek <pmladek@suse.com>, Steven Rostedt <rostedt@goodmis.org>, Sergey Senozhatsky <sergey.senozhatsky@gmail.com>, Rasmus Villemoes <linux@rasmusvillemoes.dk>, kieran.bingham+renesas@ideasonboard.com, Jacopo Mondi <jacopo+renesas@jmondi.org>, laurent.pinchart+renesas@ideasonboard.com, jorhand@linux.microsoft.com, Tsuchiya Yuto <kitakar@gmail.com>, "Krogerus, Heikki" <heikki.krogerus@linux.intel.com> Subject: Re: [PATCH 18/18] ipu3: Add driver for dummy INT3472 ACPI device Date: Tue, 1 Dec 2020 22:46:13 +0200 [thread overview] Message-ID: <CAHp75Vfq1zPxt5RpdD16rKiLOSfda7FwfHsot5JCTd98tXxPdQ@mail.gmail.com> (raw) In-Reply-To: <4831d44a-5bcc-8cf3-964c-c7dca6827458@redhat.com> On Tue, Dec 1, 2020 at 10:39 PM Hans de Goede <hdegoede@redhat.com> wrote: > On 12/1/20 8:21 PM, Andy Shevchenko wrote: > > On Tue, Dec 01, 2020 at 09:06:38PM +0200, Laurent Pinchart wrote: > >> On Tue, Dec 01, 2020 at 09:05:23PM +0200, Andy Shevchenko wrote: > >>> On Tue, Dec 01, 2020 at 08:55:48PM +0200, Laurent Pinchart wrote: > >>>> On Tue, Dec 01, 2020 at 08:54:17PM +0200, Andy Shevchenko wrote: > >>>>> On Tue, Dec 01, 2020 at 08:30:03AM +0000, Dan Scally wrote: > >>>>>> On 30/11/2020 20:07, Andy Shevchenko wrote: ... > >>>>>>>> +static struct int3472_sensor_regulator_map int3472_sensor_regulator_maps[] = { > >>>>>>>> + { "GNDF140809R", 2, miix_510_ov2680 }, > >>>>>>>> + { "YHCU", 2, surface_go2_ov5693 }, > >>>>>>>> + { "MSHW0070", 2, surface_book_ov5693 }, > >>>>>>>> +}; > >>>>>>> > >>>>>>> Hmm... Usual way is to use DMI for that. I'm not sure above will not give us > >>>>>>> false positive matches. > >>>>>> > >>>>>> I considered DMI too, no problem to switch to that if it's a better choice. > >>>>> > >>>>> I prefer DMI as it's a standard way to describe platform quirks in x86 world. > >>>> > >>>> Do you think the Windows driver would use DMI ? > >>> > >>> Linux is using DMI for quirks. > >>> > >>>> That seems quite > >>>> unlikely to me, given how they would have to release a new driver binary > >>>> for every machine. I'm pretty sure that a different mechanism is used to > >>>> identify camera integration, and I think it would make sense to follow > >>>> the same approach. That would allow us to avoid large tables of DMI > >>>> identifiers that would need to be constently updated, potentially making > >>>> user experience better. > >>> > >>> All Surface family can be matched in a way as Apple machines [1]. > >>> > >>> [1]: https://lkml.org/lkml/2020/4/15/1198 > >> > >> But not all Surface machines necessarily have the same camera > >> architecture. My point is that there seems to be identifiers reported in > >> ACPI for the exact purpose of identifying the camera architecture. If we > >> used DMI instead, we would have to handle each machine individually. > > > > With help of DMI we may narrow down the search. > > > > But again, we are talking about uncertainity. It may be your way (a lot of > > platforms that have different settings), or mine (only a few with more or less > > standard sets of settings). > > > > DMI is simply standard in Linux (people usually easier can grep for quirks for > > a specific platform). > > > > I would rather ask Hans' opinion since he has quite an expertise with DMI for > > good and bad. > > So generally there are 2 ways how things like this can go: > > 1) There is sufficient information in the ACPI table and we use data from the > ACPI tables > > 2) There is unsufficient info in the ACPI tables (or we don't know how to > get / interpret the data) and we use DMI quirks > > Although we do often also use a combination, getting what we can from ACPI, > combined with a set of defaults for what we cannot get from ACPI > based on what reference designs use (IOW what most devices seem to have > copy and pasted). Combined with DMI quirks for when the defaults do not > work (which is quite often). > > Depending on if "not working because of wrong defaults" has bad side effects, > another option is also to only allow the driver to load on devices which > have the necessary info provided through a DMI match. > > I hope this helps. Thanks! Yes, it sounds to me as a useful input! -- With Best Regards, Andy Shevchenko
WARNING: multiple messages have this Message-ID (diff)
From: Andy Shevchenko <andy.shevchenko at gmail.com> To: devel@acpica.org Subject: [Devel] Re: [PATCH 18/18] ipu3: Add driver for dummy INT3472 ACPI device Date: Tue, 01 Dec 2020 20:45:25 +0000 [thread overview] Message-ID: <CAHp75Vfq1zPxt5RpdD16rKiLOSfda7FwfHsot5JCTd98tXxPdQ@mail.gmail.com> (raw) In-Reply-To: 4831d44a-5bcc-8cf3-964c-c7dca6827458@redhat.com [-- Attachment #1: Type: text/plain, Size: 3608 bytes --] On Tue, Dec 1, 2020 at 10:39 PM Hans de Goede <hdegoede(a)redhat.com> wrote: > On 12/1/20 8:21 PM, Andy Shevchenko wrote: > > On Tue, Dec 01, 2020 at 09:06:38PM +0200, Laurent Pinchart wrote: > >> On Tue, Dec 01, 2020 at 09:05:23PM +0200, Andy Shevchenko wrote: > >>> On Tue, Dec 01, 2020 at 08:55:48PM +0200, Laurent Pinchart wrote: > >>>> On Tue, Dec 01, 2020 at 08:54:17PM +0200, Andy Shevchenko wrote: > >>>>> On Tue, Dec 01, 2020 at 08:30:03AM +0000, Dan Scally wrote: > >>>>>> On 30/11/2020 20:07, Andy Shevchenko wrote: ... > >>>>>>>> +static struct int3472_sensor_regulator_map int3472_sensor_regulator_maps[] = { > >>>>>>>> + { "GNDF140809R", 2, miix_510_ov2680 }, > >>>>>>>> + { "YHCU", 2, surface_go2_ov5693 }, > >>>>>>>> + { "MSHW0070", 2, surface_book_ov5693 }, > >>>>>>>> +}; > >>>>>>> > >>>>>>> Hmm... Usual way is to use DMI for that. I'm not sure above will not give us > >>>>>>> false positive matches. > >>>>>> > >>>>>> I considered DMI too, no problem to switch to that if it's a better choice. > >>>>> > >>>>> I prefer DMI as it's a standard way to describe platform quirks in x86 world. > >>>> > >>>> Do you think the Windows driver would use DMI ? > >>> > >>> Linux is using DMI for quirks. > >>> > >>>> That seems quite > >>>> unlikely to me, given how they would have to release a new driver binary > >>>> for every machine. I'm pretty sure that a different mechanism is used to > >>>> identify camera integration, and I think it would make sense to follow > >>>> the same approach. That would allow us to avoid large tables of DMI > >>>> identifiers that would need to be constently updated, potentially making > >>>> user experience better. > >>> > >>> All Surface family can be matched in a way as Apple machines [1]. > >>> > >>> [1]: https://lkml.org/lkml/2020/4/15/1198 > >> > >> But not all Surface machines necessarily have the same camera > >> architecture. My point is that there seems to be identifiers reported in > >> ACPI for the exact purpose of identifying the camera architecture. If we > >> used DMI instead, we would have to handle each machine individually. > > > > With help of DMI we may narrow down the search. > > > > But again, we are talking about uncertainity. It may be your way (a lot of > > platforms that have different settings), or mine (only a few with more or less > > standard sets of settings). > > > > DMI is simply standard in Linux (people usually easier can grep for quirks for > > a specific platform). > > > > I would rather ask Hans' opinion since he has quite an expertise with DMI for > > good and bad. > > So generally there are 2 ways how things like this can go: > > 1) There is sufficient information in the ACPI table and we use data from the > ACPI tables > > 2) There is unsufficient info in the ACPI tables (or we don't know how to > get / interpret the data) and we use DMI quirks > > Although we do often also use a combination, getting what we can from ACPI, > combined with a set of defaults for what we cannot get from ACPI > based on what reference designs use (IOW what most devices seem to have > copy and pasted). Combined with DMI quirks for when the defaults do not > work (which is quite often). > > Depending on if "not working because of wrong defaults" has bad side effects, > another option is also to only allow the driver to load on devices which > have the necessary info provided through a DMI match. > > I hope this helps. Thanks! Yes, it sounds to me as a useful input! -- With Best Regards, Andy Shevchenko
next parent reply other threads:[~2020-12-01 20:46 UTC|newest] Thread overview: 159+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-12-01 20:45 Andy Shevchenko [this message] 2020-12-01 20:46 ` [PATCH 18/18] ipu3: Add driver for dummy INT3472 ACPI device Andy Shevchenko -- strict thread matches above, loose matches on Subject: below -- 2020-11-30 13:31 [PATCH 00/18] Add functionality to ipu3-cio2 driver allowing software_node connections to sensors on platforms designed for Windows Daniel Scally 2020-11-30 13:31 ` [PATCH 01/18] property: Return true in fwnode_device_is_available for node types that do not implement this operation Daniel Scally 2020-11-30 16:05 ` Laurent Pinchart 2020-11-30 17:21 ` Andy Shevchenko 2020-12-01 3:12 ` Bingbu Cao 2020-12-01 8:46 ` Dan Scally 2020-11-30 13:31 ` [PATCH 02/18] property: Add support for calling fwnode_graph_get_endpoint_by_id() for fwnode->secondary Daniel Scally 2020-11-30 16:08 ` Laurent Pinchart 2020-11-30 17:29 ` Andy Shevchenko 2020-11-30 17:28 ` Laurent Pinchart 2020-11-30 17:53 ` Andy Shevchenko 2020-11-30 18:41 ` Laurent Pinchart 2020-11-30 19:21 ` Andy Shevchenko 2020-12-02 10:13 ` Dan Scally 2020-11-30 13:31 ` [PATCH 03/18] software_node: Fix failure to put() and get() references to children in software_node_get_next_child() Daniel Scally 2020-11-30 16:10 ` Laurent Pinchart 2020-11-30 17:30 ` Andy Shevchenko 2020-11-30 13:31 ` [PATCH 04/18] software_node: Enforce parent before child ordering of nodes array for software_node_register_nodes() Daniel Scally 2020-11-30 16:11 ` Laurent Pinchart 2020-11-30 16:12 ` Laurent Pinchart 2020-11-30 23:10 ` Dan Scally 2020-11-30 17:35 ` Andy Shevchenko 2020-11-30 17:37 ` Andy Shevchenko 2020-11-30 13:31 ` [PATCH 05/18] software_node: Alter software_node_unregister_nodes() to unregister the array in reverse order Daniel Scally 2020-11-30 16:14 ` Laurent Pinchart 2020-11-30 17:45 ` Andy Shevchenko 2020-12-01 23:36 ` Dan Scally 2020-11-30 13:31 ` [PATCH 06/18] software_node: amend software_node_unregister_node_group() to perform unregistration of array in reverse order to be consistent with software_node_unregister_nodes() Daniel Scally 2020-11-30 16:17 ` Laurent Pinchart 2020-11-30 17:47 ` Andy Shevchenko 2020-12-02 10:04 ` Dan Scally 2020-11-30 17:19 ` kernel test robot 2020-11-30 17:19 ` [Devel] " kernel test robot 2020-11-30 17:19 ` kernel test robot 2020-12-01 18:18 ` Dan Carpenter 2020-12-01 18:18 ` Dan Carpenter 2020-12-01 18:18 ` Dan Carpenter 2020-11-30 13:31 ` [PATCH 07/18] software_node: Add support for fwnode_graph*() family of functions Daniel Scally 2020-11-30 16:25 ` Laurent Pinchart 2020-11-30 23:34 ` Dan Scally 2020-11-30 13:31 ` [PATCH 08/18] lib/test_printf.c: Use helper function to unwind array of software_nodes Daniel Scally 2020-11-30 15:54 ` Sergey Senozhatsky 2020-11-30 16:26 ` Laurent Pinchart 2020-11-30 13:31 ` [PATCH 09/18] ipu3-cio2: Add T: entry to MAINTAINERS Daniel Scally 2020-11-30 13:31 ` [PATCH 10/18] ipu3-cio2: Rename ipu3-cio2.c to allow module to be built from multiple source files retaining ipu3-cio2 name Daniel Scally 2020-12-01 6:56 ` Bingbu Cao 2020-12-01 7:07 ` Bingbu Cao 2020-11-30 13:31 ` [PATCH 11/18] media: v4l2-core: v4l2-async: Check possible match in match_fwnode based on sd->fwnode->secondary Daniel Scally 2020-11-30 16:27 ` Laurent Pinchart 2020-11-30 17:55 ` Andy Shevchenko 2020-11-30 13:31 ` [PATCH 12/18] acpi: Add acpi_dev_get_next_match_dev() and macro to iterate through acpi_devices matching a given _HID Daniel Scally 2020-11-30 17:58 ` Andy Shevchenko 2020-11-30 13:31 ` [PATCH 13/18] ipu3-cio2: Add functionality allowing software_node connections to sensors on platforms designed for Windows Daniel Scally 2020-11-30 16:45 ` kernel test robot 2020-11-30 16:45 ` [Devel] " kernel test robot 2020-11-30 16:45 ` kernel test robot 2020-11-30 17:09 ` Laurent Pinchart 2020-11-30 18:14 ` Andy Shevchenko 2020-12-01 22:08 ` Dan Scally 2020-12-01 22:11 ` Dan Scally 2020-12-01 22:30 ` Laurent Pinchart 2020-12-01 23:15 ` Dan Scally 2020-12-02 10:38 ` Sakari Ailus 2020-12-02 10:53 ` Dan Scally 2020-12-02 12:02 ` Andy Shevchenko 2020-12-02 22:44 ` Dan Scally 2020-12-02 12:01 ` Andy Shevchenko 2020-11-30 20:27 ` kernel test robot 2020-11-30 20:27 ` [Devel] " kernel test robot 2020-11-30 20:27 ` kernel test robot 2020-11-30 20:35 ` Sakari Ailus 2020-12-01 8:13 ` Dan Scally 2020-12-01 15:06 ` Andy Shevchenko 2020-12-15 10:28 ` Daniel Scally 2020-12-15 10:32 ` Daniel Scally 2020-12-15 22:02 ` Sakari Ailus 2020-12-17 14:17 ` Daniel Scally 2020-11-30 13:31 ` [PATCH 14/18] acpi: utils: Add function to fetch dependent acpi_devices Daniel Scally 2020-11-30 18:23 ` Andy Shevchenko 2020-11-30 18:40 ` Laurent Pinchart 2020-11-30 23:54 ` Dan Scally 2020-12-01 15:10 ` Andy Shevchenko 2020-12-01 15:23 ` Dan Scally 2020-11-30 13:31 ` [PATCH 15/18] i2c: i2c-core-acpi: Add i2c_acpi_dev_name() Daniel Scally 2020-11-30 17:11 ` Laurent Pinchart 2020-12-02 22:44 ` Dan Scally 2020-11-30 13:31 ` [PATCH 16/18] i2c: i2c-core-base: Use the new i2c_acpi_dev_name() in i2c_set_dev_name() Daniel Scally 2020-11-30 17:12 ` Laurent Pinchart 2020-11-30 19:18 ` Andy Shevchenko 2020-12-02 9:35 ` Andy Shevchenko 2020-12-02 9:49 ` Dan Scally 2020-12-01 23:50 ` Dan Scally 2020-11-30 13:31 ` [PATCH 17/18] gpio: gpiolib-acpi: Export acpi_get_gpiod() Daniel Scally 2020-11-30 17:02 ` kernel test robot 2020-11-30 17:02 ` [Devel] " kernel test robot 2020-11-30 17:02 ` kernel test robot 2020-11-30 18:04 ` kernel test robot 2020-11-30 18:04 ` [Devel] " kernel test robot 2020-11-30 18:04 ` kernel test robot 2020-11-30 19:20 ` Andy Shevchenko 2020-11-30 13:31 ` [PATCH 18/18] ipu3: Add driver for dummy INT3472 ACPI device Daniel Scally 2020-11-30 16:17 ` Jean-Michel Hautbois 2020-11-30 23:20 ` Dan Scally 2020-12-01 18:31 ` Andy Shevchenko 2020-12-01 18:36 ` Laurent Pinchart 2020-12-01 18:51 ` Andy Shevchenko 2020-11-30 16:29 ` Kieran Bingham 2020-11-30 17:21 ` Laurent Pinchart 2020-11-30 20:07 ` Andy Shevchenko 2020-11-30 23:32 ` Laurent Pinchart 2020-12-01 15:55 ` Sakari Ailus 2020-12-01 18:37 ` Laurent Pinchart 2020-12-02 11:09 ` Sakari Ailus 2020-12-02 12:42 ` Laurent Pinchart 2020-12-02 15:08 ` Andy Shevchenko 2020-12-03 12:37 ` Dan Scally 2020-12-03 12:57 ` Andy Shevchenko 2020-12-01 18:49 ` Andy Shevchenko 2020-12-01 20:59 ` Dan Scally 2020-12-02 9:39 ` Andy Shevchenko 2020-12-02 12:35 ` Laurent Pinchart 2020-12-02 15:11 ` Andy Shevchenko 2020-12-03 12:25 ` Dan Scally 2020-12-13 22:48 ` Daniel Scally 2020-12-14 15:33 ` Andy Shevchenko 2020-12-01 8:30 ` Dan Scally 2020-12-01 18:54 ` Andy Shevchenko 2020-12-01 18:55 ` Laurent Pinchart 2020-12-01 19:05 ` Andy Shevchenko 2020-12-01 19:06 ` Laurent Pinchart 2020-12-01 19:21 ` Andy Shevchenko 2020-12-01 20:34 ` Hans de Goede 2020-12-02 12:48 ` Laurent Pinchart 2020-12-02 15:15 ` Andy Shevchenko 2020-12-01 21:05 ` Dan Scally 2020-12-02 9:42 ` Andy Shevchenko 2021-01-07 23:55 ` Daniel Scally 2021-01-08 12:17 ` [Devel] " Andy Shevchenko 2021-01-08 12:17 ` Andy Shevchenko 2021-01-08 23:24 ` Daniel Scally 2021-01-09 9:17 ` [Devel] " Andy Shevchenko 2021-01-09 9:58 ` Daniel Scally 2021-01-09 0:18 ` Laurent Pinchart 2021-01-09 0:39 ` Daniel Scally 2020-11-30 20:52 ` Sakari Ailus 2020-11-30 23:06 ` Dan Scally 2020-11-30 23:21 ` Laurent Pinchart 2020-12-01 0:05 ` Dan Scally 2020-12-01 6:44 ` Sakari Ailus 2020-12-01 8:08 ` Dan Scally 2020-12-01 8:09 ` Dan Scally 2020-12-01 12:32 ` Sakari Ailus 2020-12-01 12:40 ` Laurent Pinchart 2020-12-01 12:44 ` Sakari Ailus 2020-12-01 12:48 ` Dan Scally 2020-12-01 19:01 ` Andy Shevchenko 2020-12-01 18:55 ` Andy Shevchenko
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=CAHp75Vfq1zPxt5RpdD16rKiLOSfda7FwfHsot5JCTd98tXxPdQ@mail.gmail.com \ --to=andy.shevchenko@gmail.com \ --cc=andriy.shevchenko@linux.intel.com \ --cc=bgolaszewski@baylibre.com \ --cc=bingbu.cao@intel.com \ --cc=devel@acpica.org \ --cc=djrscally@gmail.com \ --cc=erik.kaneda@intel.com \ --cc=gregkh@linuxfoundation.org \ --cc=hdegoede@redhat.com \ --cc=heikki.krogerus@linux.intel.com \ --cc=jacopo+renesas@jmondi.org \ --cc=jorhand@linux.microsoft.com \ --cc=kieran.bingham+renesas@ideasonboard.com \ --cc=kitakar@gmail.com \ --cc=laurent.pinchart+renesas@ideasonboard.com \ --cc=laurent.pinchart@ideasonboard.com \ --cc=lenb@kernel.org \ --cc=linus.walleij@linaro.org \ --cc=linux-acpi@vger.kernel.org \ --cc=linux-gpio@vger.kernel.org \ --cc=linux-i2c@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-media@vger.kernel.org \ --cc=linux@rasmusvillemoes.dk \ --cc=mchehab@kernel.org \ --cc=mika.westerberg@linux.intel.com \ --cc=pmladek@suse.com \ --cc=rjw@rjwysocki.net \ --cc=robert.moore@intel.com \ --cc=rostedt@goodmis.org \ --cc=sakari.ailus@linux.intel.com \ --cc=sergey.senozhatsky@gmail.com \ --cc=tian.shu.qiu@intel.com \ --cc=wsa@kernel.org \ --cc=yong.zhi@intel.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.