From: Lukas Wunner <lukas@wunner.de>
To: Dan Williams <dan.j.williams@intel.com>
Cc: Mariusz Tkaczyk <mariusz.tkaczyk@linux.intel.com>,
linux-pci@vger.kernel.org, Arnd Bergmann <arnd@arndb.de>,
Bjorn Helgaas <bhelgaas@google.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Ilpo Jarvinen <ilpo.jarvinen@linux.intel.com>,
Keith Busch <kbusch@kernel.org>, Marek Behun <marek.behun@nic.cz>,
Pavel Machek <pavel@ucw.cz>, Randy Dunlap <rdunlap@infradead.org>,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
Stuart Hayes <stuart.w.hayes@gmail.com>
Subject: Re: [PATCH v2 2/3] PCI/NPEM: Add Native PCIe Enclosure Management support
Date: Wed, 29 May 2024 11:38:12 +0200 [thread overview]
Message-ID: <Zlb3hGR45SWJ1KuL@wunner.de> (raw)
In-Reply-To: <6656bb4654a65_16687294c0@dwillia2-mobl3.amr.corp.intel.com.notmuch>
On Tue, May 28, 2024 at 10:21:10PM -0700, Dan Williams wrote:
> Mariusz Tkaczyk wrote:
> > +config PCI_NPEM
> > + bool "Native PCIe Enclosure Management"
> > + depends on LEDS_CLASS=y
>
> I would have expected
>
> depends on NEW_LEDS
> select LEDS_CLASS
Hm, a quick "git grep -C 2 'depends on NEW_LEDS'" shows that noone else
does that. Everyone else either selects both NEW_LEDS and LEDS_CLASS
or depends on both or depends on just LEDS_CLASS.
(Since LEDS_CLASS is constrained to "if NEW_LEDS", depending on both
seems pointless, so I'm not sure why some people do that.)
I guess it would be good to get guidance from leds maintainers what
the preferred modus operandi is.
> > +#define for_each_indication(ind, inds) \
> > + for (ind = inds; ind->bit; ind++)
> > +
> > +/* To avoid confusion, do not keep any special bits in indications */
>
> I am confused by this comment. What "special bits" is this referring to?
I think it's referring to bit 0 in the Status and Control register,
which is a master "NPEM Capable" and "NPEM Enable" bit.
> > +struct npem_ops {
> > + const struct indication *inds;
>
> @inds is not an operation, it feels like something that belongs as
> another member in 'struct npem'. What drove this data to join 'struct
> npem_ops'?
The native NPEM register interface supports enclosure-specific indications
which the DSM interface does not support. So those indications are
present in the native npem_ops->inds and not present in the DSM
npem_ops->inds.
> > --- a/include/uapi/linux/pci_regs.h
> > +++ b/include/uapi/linux/pci_regs.h
[...]
> > +#define PCI_NPEM_IND_SPEC_0 0x00800000
> > +#define PCI_NPEM_IND_SPEC_1 0x01000000
> > +#define PCI_NPEM_IND_SPEC_2 0x02000000
> > +#define PCI_NPEM_IND_SPEC_3 0x04000000
> > +#define PCI_NPEM_IND_SPEC_4 0x08000000
> > +#define PCI_NPEM_IND_SPEC_5 0x10000000
> > +#define PCI_NPEM_IND_SPEC_6 0x20000000
> > +#define PCI_NPEM_IND_SPEC_7 0x40000000
>
> Given no other driver needs this, I would define them locally in
> drivers/pci/npem.c.
This is a uapi header, so could be used not just by other drivers
but by user space.
It's common to add spec-defined register bits to this header file
even if they're only used by a single source file in the kernel.
Thanks,
Lukas
next prev parent reply other threads:[~2024-05-29 9:38 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-28 13:19 [PATCH v2 0/3] PCIe Enclosure LED Management Mariusz Tkaczyk
2024-05-28 13:19 ` [PATCH v2 1/3] leds: Init leds class earlier Mariusz Tkaczyk
2024-05-29 4:22 ` Dan Williams
2024-06-14 14:08 ` Lukas Wunner
2024-06-14 14:13 ` Greg Kroah-Hartman
2024-05-28 13:19 ` [PATCH v2 2/3] PCI/NPEM: Add Native PCIe Enclosure Management support Mariusz Tkaczyk
2024-05-28 13:55 ` Ilpo Järvinen
2024-06-14 13:40 ` Mariusz Tkaczyk
2024-05-29 5:21 ` Dan Williams
2024-05-29 9:38 ` Lukas Wunner [this message]
2024-06-12 11:40 ` Mariusz Tkaczyk
2024-06-13 16:11 ` stuart hayes
2024-06-19 14:28 ` Mariusz Tkaczyk
2024-06-14 21:06 ` stuart hayes
2024-06-15 10:33 ` Lukas Wunner
2024-06-18 8:56 ` Mariusz Tkaczyk
2024-06-18 17:13 ` Lukas Wunner
2024-06-18 18:50 ` stuart hayes
2024-06-18 19:32 ` Dan Williams
2024-06-19 9:08 ` Lukas Wunner
2024-06-19 12:07 ` Mariusz Tkaczyk
2024-05-28 13:19 ` [PATCH v2 3/3] PCI/NPEM: Add _DSM PCIe SSD status LED management Mariusz Tkaczyk
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=Zlb3hGR45SWJ1KuL@wunner.de \
--to=lukas@wunner.de \
--cc=andriy.shevchenko@linux.intel.com \
--cc=arnd@arndb.de \
--cc=bhelgaas@google.com \
--cc=dan.j.williams@intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=ilpo.jarvinen@linux.intel.com \
--cc=kbusch@kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=marek.behun@nic.cz \
--cc=mariusz.tkaczyk@linux.intel.com \
--cc=pavel@ucw.cz \
--cc=rdunlap@infradead.org \
--cc=stuart.w.hayes@gmail.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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox