All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lee Jones <lee.jones@linaro.org>
To: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Hans de Goede <hdegoede@redhat.com>,
	"david.e.box@linux.intel.com" <david.e.box@linux.intel.com>,
	"mgross@linux.intel.com" <mgross@linux.intel.com>,
	"bhelgaas@google.com" <bhelgaas@google.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"platform-driver-x86@vger.kernel.org" 
	<platform-driver-x86@vger.kernel.org>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>
Subject: Re: [PATCH 2/4] MFD: intel_pmt: Remove OOBMSM device
Date: Thu, 1 Jul 2021 13:06:25 +0100	[thread overview]
Message-ID: <YN2vwT+7sVRvz8iS@dell> (raw)
In-Reply-To: <CAHp75Vfn6GKSj6USUPEWiPdhWRYcJbirqhU6aOeB4gruekmocg@mail.gmail.com>

On Thu, 01 Jul 2021, Andy Shevchenko wrote:

> On Thursday, July 1, 2021, Lee Jones <lee.jones@linaro.org> wrote:
> 
> > On Thu, 01 Jul 2021, Hans de Goede wrote:
> >
> > > Hi,
> > >
> > > On 6/30/21 11:11 PM, David E. Box wrote:
> > > > On Wed, 2021-06-30 at 11:15 +0100, Lee Jones wrote:
> > > >> On Thu, 17 Jun 2021, David E. Box wrote:
> > > >>
> > > >>> Unlike the other devices in intel_pmt, the Out of Band Management
> > > >>> Services
> > > >>> Module (OOBMSM) is actually not a PMT dedicated device. It can also
> > > >>> be used
> > > >>> to describe non-PMT capabilities. Like PMT, these capabilities are
> > > >>> also
> > > >>> enumerated using PCIe Vendor Specific registers in config space. In
> > > >>> order
> > > >>> to better support these devices without the confusion of a
> > > >>> dependency on
> > > >>> MFD_INTEL_PMT, remove the OOBMSM device from intel_pmt so that it
> > > >>> can be
> > > >>> later placed in its own driver. Since much of the same code will be
> > > >>> used by
> > > >>> intel_pmt and the new driver, create a new file with symbols to be
> > > >>> used by
> > > >>> both.
> > > >>>
> > > >>> While performing this split we need to also handle the creation of
> > > >>> platform
> > > >>> devices for the non-PMT capabilities. Currently PMT devices are
> > > >>> named by
> > > >>> their capability (e.g. pmt_telemetry). Instead, generically name
> > > >>> them by
> > > >>> their capability ID (e.g. intel_extnd_cap_2). This allows the IDs
> > > >>> to be
> > > >>> created automatically.  However, to ensure that unsupported devices
> > > >>> aren't
> > > >>> created, use an allow list to specify supported capabilities.
> > > >>>
> > > >>> Signed-off-by: David E. Box <david.e.box@linux.intel.com>
> > > >>> ---
> > > >>>  MAINTAINERS                                |   1 +
> > > >>>  drivers/mfd/Kconfig                        |   4 +
> > > >>>  drivers/mfd/Makefile                       |   1 +
> > > >>>  drivers/mfd/intel_extended_caps.c          | 208
> > > >>> +++++++++++++++++++++
> > > >>
> > > >> Please consider moving this <whatever this is> out to either
> > > >> drivers/pci or drivers/platform/x86.
> > > >
> > > > None of the cell drivers are in MFD, only the PCI drivers from which
> > > > the cells are created. I understood that these should be in MFD. But
> > > > moving it to drivers/platform/x86 would be fine with me. That keeps the
> > > > code together in the same subsystem. Comment from Hans or Andy?
> > >
> > > I'm fine with moving everything to drivers/platform/x86, but AFAIK
> > > usually the actual code which has the MFD cells and creates the
> > > child devices usually lives under drivers/mfd
> >
> > Correct.  It must.
> 
> It’s definitely not the first time you are talking about, but it may be the
> first time I asked why it’s not enforced overall. Last time I have checked
> it was like 5-7 MFD uses outside the MFD folder. Are you going to fix that?

Because I can't NACK patches that weren't sent to me. :)

I'll probably look into 'fixing' it when I get some free time.

> > No MFD API users outside of drivers/mfd please.

-- 
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog

  parent reply	other threads:[~2021-07-01 12:06 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-17 21:54 [PATCH 0/4] MFD: intel_pmt: Split OOBMSM from intel_pmt driver David E. Box
2021-06-17 21:54 ` [PATCH 1/4] PCI: Add #defines for accessing PCIE DVSEC fields David E. Box
2021-06-22 15:04   ` Bjorn Helgaas
2021-06-17 21:54 ` [PATCH 2/4] MFD: intel_pmt: Remove OOBMSM device David E. Box
2021-06-30 10:15   ` Lee Jones
2021-06-30 21:11     ` David E. Box
2021-07-01  8:01       ` Lee Jones
2021-07-01  8:39       ` Hans de Goede
2021-07-01 11:23         ` Lee Jones
     [not found]           ` <CAHp75Vfn6GKSj6USUPEWiPdhWRYcJbirqhU6aOeB4gruekmocg@mail.gmail.com>
2021-07-01 12:06             ` Lee Jones [this message]
     [not found]               ` <CAHp75VdmnRJKSBZ8dmU=7XsGOZ-wX6EpZhtC3X6JEE0mz-UJNg@mail.gmail.com>
2021-07-01 12:26                 ` Lee Jones
2021-07-01 22:41           ` David E. Box
2021-07-01  9:43       ` Andy Shevchenko
2021-06-17 21:54 ` [PATCH 3/4] MFD: Intel Out of Band Management Services Module (OOBMSM) driver David E. Box
2021-06-30 10:17   ` Lee Jones
2021-06-17 21:54 ` [PATCH 4/4] MFD: intel-extended-cap: Add support for PCIe VSEC structures David E. Box

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=YN2vwT+7sVRvz8iS@dell \
    --to=lee.jones@linaro.org \
    --cc=andy.shevchenko@gmail.com \
    --cc=bhelgaas@google.com \
    --cc=david.e.box@linux.intel.com \
    --cc=hdegoede@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=mgross@linux.intel.com \
    --cc=platform-driver-x86@vger.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.