All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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: link
Be 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.