From: Lukas Wunner <lukas@wunner.de>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: Mariusz Tkaczyk <mariusz.tkaczyk@linux.intel.com>,
linux-pci@vger.kernel.org, linux-leds@vger.kernel.org,
Stuart Hayes <stuart.w.hayes@gmail.com>,
Dan Williams <dan.j.williams@intel.com>
Subject: Re: [PATCH 2/2] PCI/NPEM: Add Native PCIe Enclosure Management support
Date: Thu, 7 Mar 2024 13:25:42 +0100 [thread overview]
Message-ID: <ZemyRj63v07Rj4Vu@wunner.de> (raw)
In-Reply-To: <20240306224008.GA554220@bhelgaas>
On Wed, Mar 06, 2024 at 04:40:08PM -0600, Bjorn Helgaas wrote:
> On Thu, Feb 15, 2024 at 03:23:45PM +0100, Mariusz Tkaczyk wrote:
> > The interface is ready to support enclosures where patterns are not
> > mutually exclusive, driver may clear other LEDs if they cannot be enabled
> > together.
>
> I don't think this code does anything like "clearing other LEDs," does
> it? I agree that this code doesn't impose any constraints about
> indications being mutually exclusive, etc. It merely sets or clears
> indication bits, and the hardware implementation is free to interpret
> that as it sees fit.
I guess the paragraph needs to be rephrased. The point is that
if this NPEM driver sets bit A and another bit B is already set,
and the hardware is incapable of lighting up whatever is controlled
by these two bits *simultaneously*, the hardware might clear bit B
when setting bit A. The driver can cope with that because
npem_set() reads back the register contents with npem_read_reg()
after calling npem_set_active_patterns().
> > + /*
> > + * For the case where a NPEM command has not completed immediately,
> > + * it is recommended that software not continuously ???spin??? on polling
> > + * the status register, but rather poll under interrupt at a reduced
> > + * rate; for example at 10 ms intervals.
> > + *
> > + * PCIe r6.1 sec 6.28 "Implementation Note: Software Polling of NPEM
> > + * Command Completed"
>
> The implementation note also recommends reversing the order, i.e.,
> polling for completion of previous command and then writing a new
> command, but it looks like we don't use that strategy?
I think the leds subsystem expects the LED to be lit up by the time
the ->brightness_set_blocking() callback returns. If the driver waited
for command completion *before* setting a bit instead of afterwards,
it could happen that npem_set() (the ->brightness_set_blocking() callback)
returns even though the command hasn't completed yet and the LED thus
isn't lit up yet.
Thanks,
Lukas
next prev parent reply other threads:[~2024-03-07 12:25 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-15 14:23 [PATCH 0/2] Native PCIe Enclosure Management Mariusz Tkaczyk
2024-02-15 14:23 ` [PATCH 1/2] leds: Init leds class earlier Mariusz Tkaczyk
2024-02-15 14:23 ` [PATCH 2/2] PCI/NPEM: Add Native PCIe Enclosure Management support Mariusz Tkaczyk
2024-03-06 22:40 ` Bjorn Helgaas
2024-03-07 12:25 ` Lukas Wunner [this message]
2024-03-11 9:47 ` Mariusz Tkaczyk
2024-03-11 22:13 ` Bjorn Helgaas
[not found] ` <CAL5oW00nSZV=oAjWPbYTwVGZ9OS1hW9hyZ5C0yzWbMjAstAA2g@mail.gmail.com>
2024-03-12 9:08 ` Mariusz Tkaczyk
2024-03-22 19:56 ` Bjorn Helgaas
2024-03-22 21:30 ` Dan Williams
2024-03-22 21:42 ` Bjorn Helgaas
2024-03-22 21:51 ` Dan Williams
2024-03-23 5:09 ` Lukas Wunner
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=ZemyRj63v07Rj4Vu@wunner.de \
--to=lukas@wunner.de \
--cc=dan.j.williams@intel.com \
--cc=helgaas@kernel.org \
--cc=linux-leds@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=mariusz.tkaczyk@linux.intel.com \
--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 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.