From: Ira Weiny <ira.weiny@intel.com>
To: Dan Williams <dan.j.williams@intel.com>,
Ira Weiny <ira.weiny@intel.com>,
Dave Jiang <dave.jiang@intel.com>,
Jonathan Cameron <jonathan.cameron@huawei.com>,
Smita Koralahalli <Smita.KoralahalliChannabasappa@amd.com>,
Shiju Jose <shiju.jose@huawei.com>
Cc: Dan Carpenter <dan.carpenter@linaro.org>,
Yazen Ghannam <yazen.ghannam@amd.com>,
Davidlohr Bueso <dave@stgolabs.net>,
"Alison Schofield" <alison.schofield@intel.com>,
Vishal Verma <vishal.l.verma@intel.com>,
Ard Biesheuvel <ardb@kernel.org>, <linux-efi@vger.kernel.org>,
<linux-kernel@vger.kernel.org>, <linux-cxl@vger.kernel.org>,
Ira Weiny <ira.weiny@intel.com>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Tony Luck <tony.luck@intel.com>, "Borislav Petkov" <bp@alien8.de>
Subject: RE: [PATCH v2 1/3] acpi/ghes: Process CXL Component Events
Date: Mon, 22 Apr 2024 20:47:12 -0700 [thread overview]
Message-ID: <66272f40420e6_bbee62945d@iweiny-mobl.notmuch> (raw)
In-Reply-To: <6626f8c9404f2_690a294d8@dwillia2-xfh.jf.intel.com.notmuch>
Dan Williams wrote:
> Ira Weiny wrote:
[snip]
> >
> > [0]
> > Link: https://lore.kernel.org/all/cover.1711598777.git.alison.schofield@intel.com/
> > [1]
> > Link: https://lore.kernel.org/all/65d111eb87115_6c745294ac@dwillia2-xfh.jf.intel.com.notmuch/
> > [2]
> > Link: https://lore.kernel.org/all/b963c490-2c13-4b79-bbe7-34c6568423c7@moroto.mountain/
>
> Minor, but this can be reformatted a bit cleaner:
>
> Link: http://lore.kernel.org/r/cover.1711598777.git.alison.schofield@intel.com [0]
> Link: http://lore.kernel.org/r/65d111eb87115_6c745294ac@dwillia2-xfh.jf.intel.com.notmuch [1]
> Link: http://lore.kernel.org/r/b963c490-2c13-4b79-bbe7-34c6568423c7@moroto.mountain [2]
>
Sure.
[snip]
> > +/*
> > + * Memory Module Event Record
> > + * CXL rev 3.0 section 8.2.9.2.1.3; Table 8-45
> > + */
> > +#define CPER_SEC_CXL_MEM_MODULE_GUID \
> > + GUID_INIT(0xfe927475, 0xdd59, 0x4339, \
> > + 0xa5, 0x86, 0x79, 0xba, 0xb1, 0x13, 0xb7, 0x74)
> > +
> > +struct cxl_cper_work_data {
> > + enum cxl_event_type event_type;
> > + struct cxl_cper_event_rec rec;
> > +};
> > +
> > +DEFINE_KFIFO(cxl_cper_fifo, struct cxl_cper_work_data, 32);
>
> Any comment on where that "32" comes from?
If anyone has any better queue depth I'm open. It is just a guess.
>
> > +static DEFINE_SPINLOCK(cxl_cper_work_lock);
>
> Needs a comment on what it is specifically protecting.
Ok.
>
> > +static cxl_cper_callback cper_callback;
> > +static void cxl_cper_cb_fn(struct work_struct *work)
> > +{
> > + struct cxl_cper_work_data wd;
> > +
> > + while (kfifo_get(&cxl_cper_fifo, &wd))
> > + cper_callback(wd.event_type, &wd.rec);
> > +}
> > +static DECLARE_WORK(cxl_cb_work, cxl_cper_cb_fn);
> > +struct work_struct *cxl_cper_work = NULL;
>
> Initializing global data to NULL is redundant, however this feels like
> one too many dynamic things registered.
>
> cxl_cper_work and cper_callback are dynamic, but from the GHES
> perspective all it cares about is checking if work is registered and if
> so put the data in the kfifo and trigger that work func.
>
> It need not care about what happens after the work is queued. So, lets
> just have the CXL driver register its own cxl_cper_work instance and
> skip defining one locally here. Export cxl_cper_fifo for the driver to
> optionally reference.
Ok I thought we had decided not to do that. If I recall exporting the
fifo had some difficulties but it may have been my unfamiliarity with it.
Ira
[snip]
next prev parent reply other threads:[~2024-04-23 3:47 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-22 22:25 [PATCH v2 0/3] efi/cxl-cper: Report CXL CPER events through tracing Ira Weiny
2024-04-22 22:25 ` [PATCH v2 1/3] acpi/ghes: Process CXL Component Events Ira Weiny
2024-04-22 23:54 ` Dan Williams
2024-04-23 3:47 ` Ira Weiny [this message]
2024-04-23 4:16 ` Ira Weiny
2024-04-22 22:25 ` [PATCH v2 2/3] cxl/pci: Process CPER events Ira Weiny
2024-04-22 22:25 ` [PATCH v2 3/3] ras/events: Trace CXL CPER events without CXL stack Ira Weiny
2024-04-23 0:16 ` Dan Williams
2024-04-23 4:10 ` Ira Weiny
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=66272f40420e6_bbee62945d@iweiny-mobl.notmuch \
--to=ira.weiny@intel.com \
--cc=Smita.KoralahalliChannabasappa@amd.com \
--cc=alison.schofield@intel.com \
--cc=ardb@kernel.org \
--cc=bp@alien8.de \
--cc=dan.carpenter@linaro.org \
--cc=dan.j.williams@intel.com \
--cc=dave.jiang@intel.com \
--cc=dave@stgolabs.net \
--cc=jonathan.cameron@huawei.com \
--cc=linux-cxl@vger.kernel.org \
--cc=linux-efi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rafael@kernel.org \
--cc=shiju.jose@huawei.com \
--cc=tony.luck@intel.com \
--cc=vishal.l.verma@intel.com \
--cc=yazen.ghannam@amd.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.