From: Andy Shevchenko <andy.shevchenko@gmail.com> To: Daniel Scally <djrscally@gmail.com> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>, Laurent Pinchart <laurent.pinchart@ideasonboard.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>, Platform Driver <platform-driver-x86@vger.kernel.org>, devel@acpica.org, "Rafael J. Wysocki" <rjw@rjwysocki.net>, Len Brown <lenb@kernel.org>, Andy Shevchenko <andy@kernel.org>, Mika Westerberg <mika.westerberg@linux.intel.com>, Linus Walleij <linus.walleij@linaro.org>, Bartosz Golaszewski <bgolaszewski@baylibre.com>, Wolfram Sang <wsa@kernel.org>, Lee Jones <lee.jones@linaro.org>, Hans de Goede <hdegoede@redhat.com>, Mark Gross <mgross@linux.intel.com>, Robert Moore <robert.moore@intel.com>, Erik Kaneda <erik.kaneda@intel.com>, Sakari Ailus <sakari.ailus@linux.intel.com>, kieran.bingham@ideasonboard.com Subject: Re: [PATCH v2 6/7] platform: x86: Add intel_skl_int3472 driver Date: Sun, 7 Feb 2021 13:56:27 +0200 [thread overview] Message-ID: <CAHp75VeF_tZdi8+fMYGtuzMH_jWit4cHy6kHM2OVuBkDA4+=uA@mail.gmail.com> (raw) In-Reply-To: <2f85ec6d-b47e-6d86-02bc-5563cff7576d@gmail.com> On Sun, Feb 7, 2021 at 1:00 PM Daniel Scally <djrscally@gmail.com> wrote: > On 21/01/2021 00:18, Daniel Scally wrote: > > On 20/01/2021 12:57, Andy Shevchenko wrote: ... > > I'm not sure that one's better than the other, to be honest. Either the > > multi-function device functionality lives in the conventional place, or > > else _all_ of the int3472 handling code lives together in one module. > Can we come to a consensus on this? I would rather be in agreement than > leave it hanging...I do see the argument that it's better not to rebirth > the MFD driver away from that subsystem, but at the moment I lean > towards the view that having all the code handling this particular _HID > in one place is probably preferable, if only to make it easier for > anyone coming in the future to understand what's happening. That said; > I'm not particularly precious about it, I'd just like to agree an > approach so I can move forward with the next version So, my priorities of rejection (first is higher) - open-coding MFD subsystem (that said, if you shuffle the code, at least leave it as an MFD driver) - moving out from MFD (although I understand intentions) Summarize, go ahead with your view (leaving it as an MFD driver) and look forward to what maintainer(s) will say. -- 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 v2 6/7] platform: x86: Add intel_skl_int3472 driver Date: Sun, 07 Feb 2021 13:56:27 +0200 [thread overview] Message-ID: <CAHp75VeF_tZdi8+fMYGtuzMH_jWit4cHy6kHM2OVuBkDA4+=uA@mail.gmail.com> (raw) In-Reply-To: 2f85ec6d-b47e-6d86-02bc-5563cff7576d@gmail.com [-- Attachment #1: Type: text/plain, Size: 1346 bytes --] On Sun, Feb 7, 2021 at 1:00 PM Daniel Scally <djrscally(a)gmail.com> wrote: > On 21/01/2021 00:18, Daniel Scally wrote: > > On 20/01/2021 12:57, Andy Shevchenko wrote: ... > > I'm not sure that one's better than the other, to be honest. Either the > > multi-function device functionality lives in the conventional place, or > > else _all_ of the int3472 handling code lives together in one module. > Can we come to a consensus on this? I would rather be in agreement than > leave it hanging...I do see the argument that it's better not to rebirth > the MFD driver away from that subsystem, but at the moment I lean > towards the view that having all the code handling this particular _HID > in one place is probably preferable, if only to make it easier for > anyone coming in the future to understand what's happening. That said; > I'm not particularly precious about it, I'd just like to agree an > approach so I can move forward with the next version So, my priorities of rejection (first is higher) - open-coding MFD subsystem (that said, if you shuffle the code, at least leave it as an MFD driver) - moving out from MFD (although I understand intentions) Summarize, go ahead with your view (leaving it as an MFD driver) and look forward to what maintainer(s) will say. -- With Best Regards, Andy Shevchenko
next prev parent reply other threads:[~2021-02-07 11:57 UTC|newest] Thread overview: 107+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-01-18 0:34 [PATCH v2 0/7] Introduce intel_skl_int3472 driver Daniel Scally 2021-01-18 0:34 ` [PATCH v2 1/7] acpi: utils: move acpi_lpss_dep() to utils Daniel Scally 2021-01-18 7:24 ` Laurent Pinchart 2021-01-18 8:31 ` Daniel Scally 2021-01-18 12:29 ` Andy Shevchenko 2021-01-18 12:35 ` Daniel Scally 2021-01-18 12:28 ` Andy Shevchenko 2021-01-18 16:06 ` Rafael J. Wysocki 2021-01-18 16:06 ` [Devel] " Rafael J. Wysocki 2021-01-18 16:42 ` Andy Shevchenko 2021-01-18 0:34 ` [PATCH v2 2/7] acpi: utils: Add function to fetch dependent acpi_devices Daniel Scally 2021-01-18 7:34 ` Laurent Pinchart 2021-01-18 8:37 ` Daniel Scally 2021-01-18 12:33 ` Andy Shevchenko 2021-01-18 13:37 ` Daniel Scally 2021-01-18 16:14 ` Rafael J. Wysocki 2021-01-18 16:14 ` [Devel] " Rafael J. Wysocki 2021-01-18 20:51 ` Daniel Scally 2021-01-19 13:15 ` Rafael J. Wysocki 2021-01-19 13:15 ` [Devel] " Rafael J. Wysocki 2021-01-19 13:28 ` Daniel Scally 2021-01-21 9:47 ` Daniel Scally 2021-01-21 11:58 ` Rafael J. Wysocki 2021-01-21 11:58 ` [Devel] " Rafael J. Wysocki 2021-01-21 12:04 ` Daniel Scally 2021-01-21 14:39 ` Rafael J. Wysocki 2021-01-21 14:39 ` [Devel] " Rafael J. Wysocki 2021-01-21 16:34 ` Daniel Scally 2021-01-21 18:08 ` Rafael J. Wysocki 2021-01-21 18:08 ` [Devel] " Rafael J. Wysocki 2021-01-21 21:06 ` Daniel Scally 2021-02-02 9:58 ` Daniel Scally 2021-02-02 11:27 ` Andy Shevchenko 2021-02-02 14:02 ` Rafael J. Wysocki 2021-02-02 14:02 ` [Devel] " Rafael J. Wysocki 2021-01-18 0:34 ` [PATCH v2 3/7] i2c: i2c-core-base: Use format macro in i2c_dev_set_name() Daniel Scally 2021-01-18 7:28 ` Laurent Pinchart 2021-01-18 12:41 ` Andy Shevchenko 2021-01-18 9:41 ` Sakari Ailus 2021-01-18 9:42 ` Sakari Ailus 2021-01-18 9:48 ` Wolfram Sang 2021-01-18 12:39 ` Andy Shevchenko 2021-01-18 0:34 ` [PATCH v2 4/7] i2c: i2c-core-acpi: Add i2c_acpi_dev_name() Daniel Scally 2021-01-18 9:18 ` Laurent Pinchart 2021-01-18 13:41 ` Andy Shevchenko 2021-01-19 13:19 ` Rafael J. Wysocki 2021-01-19 13:19 ` [Devel] " Rafael J. Wysocki 2021-01-28 9:00 ` Wolfram Sang 2021-01-28 9:15 ` Daniel Scally 2021-01-28 9:17 ` Wolfram Sang 2021-01-28 9:22 ` Daniel Scally 2021-01-18 13:39 ` Andy Shevchenko 2021-01-18 18:43 ` Joe Perches 2021-01-18 18:56 ` Andy Shevchenko 2021-01-18 19:00 ` Joe Perches 2021-01-18 19:01 ` Andy Shevchenko 2021-01-18 0:34 ` [PATCH v2 5/7] gpio: gpiolib-acpi: Export acpi_get_gpiod() Daniel Scally 2021-01-18 7:37 ` Laurent Pinchart 2021-01-18 13:45 ` Andy Shevchenko 2021-01-18 13:46 ` Andy Shevchenko 2021-01-18 21:32 ` Daniel Scally 2021-01-18 0:34 ` [PATCH v2 6/7] platform: x86: Add intel_skl_int3472 driver Daniel Scally 2021-01-18 9:15 ` Laurent Pinchart 2021-01-18 14:46 ` Andy Shevchenko 2021-01-18 21:19 ` Daniel Scally 2021-01-19 0:11 ` Daniel Scally 2021-01-19 6:21 ` Laurent Pinchart 2021-01-19 9:35 ` Andy Shevchenko 2021-01-19 16:49 ` Laurent Pinchart 2021-01-19 9:33 ` Andy Shevchenko 2021-01-19 9:34 ` Daniel Scally 2021-01-19 16:36 ` Laurent Pinchart 2021-01-19 17:43 ` Andy Shevchenko 2021-01-20 4:18 ` Laurent Pinchart 2021-01-20 11:44 ` Andy Shevchenko 2021-01-21 21:08 ` Daniel Scally 2021-01-19 9:24 ` Andy Shevchenko 2021-01-19 10:40 ` Daniel Scally 2021-01-19 11:08 ` Andy Shevchenko 2021-01-19 16:48 ` Laurent Pinchart 2021-01-19 17:51 ` Andy Shevchenko 2021-01-20 4:21 ` Laurent Pinchart 2021-01-20 12:57 ` Andy Shevchenko 2021-01-21 0:18 ` Daniel Scally 2021-02-07 11:00 ` Daniel Scally 2021-02-07 11:56 ` Andy Shevchenko [this message] 2021-02-07 11:56 ` [Devel] " Andy Shevchenko 2021-01-18 20:46 ` Daniel Scally 2021-01-19 6:19 ` Laurent Pinchart 2021-01-19 8:43 ` Daniel Scally 2021-01-19 16:33 ` Laurent Pinchart 2021-01-18 11:12 ` Barnabás Pőcze 2021-01-18 13:51 ` andriy.shevchenko 2021-01-18 14:51 ` Barnabás Pőcze 2021-01-18 15:23 ` andriy.shevchenko 2021-01-18 15:32 ` Hans de Goede 2021-01-18 15:48 ` andriy.shevchenko 2021-01-18 16:00 ` Daniel Scally 2021-01-18 16:03 ` Hans de Goede 2021-01-18 17:05 ` Laurent Pinchart 2021-01-19 10:56 ` Kieran Bingham 2021-01-19 11:11 ` Andy Shevchenko 2021-01-19 11:12 ` Daniel Scally 2021-01-18 0:34 ` [PATCH v2 7/7] mfd: Remove tps68470 MFD driver Daniel Scally 2021-01-18 7:42 ` Laurent Pinchart 2021-01-18 13:53 ` Andy Shevchenko 2021-01-18 20:07 ` Joe Perches
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='CAHp75VeF_tZdi8+fMYGtuzMH_jWit4cHy6kHM2OVuBkDA4+=uA@mail.gmail.com' \ --to=andy.shevchenko@gmail.com \ --cc=andriy.shevchenko@linux.intel.com \ --cc=andy@kernel.org \ --cc=bgolaszewski@baylibre.com \ --cc=devel@acpica.org \ --cc=djrscally@gmail.com \ --cc=erik.kaneda@intel.com \ --cc=hdegoede@redhat.com \ --cc=kieran.bingham@ideasonboard.com \ --cc=laurent.pinchart@ideasonboard.com \ --cc=lee.jones@linaro.org \ --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=mgross@linux.intel.com \ --cc=mika.westerberg@linux.intel.com \ --cc=platform-driver-x86@vger.kernel.org \ --cc=rjw@rjwysocki.net \ --cc=robert.moore@intel.com \ --cc=sakari.ailus@linux.intel.com \ --cc=wsa@kernel.org \ /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.