public inbox for linux-acpi@vger.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
To: Dan Williams <dan.j.williams@intel.com>
Cc: Ben Cheatham <Benjamin.Cheatham@amd.com>, <dave@stogolabs.net>,
	<dave.jiang@intel.com>, <alison.schofield@intel.com>,
	<vishal.l.verma@intel.com>, <ira.weiny@intel.com>,
	<rafael@kernel.org>, <linux-cxl@vger.kernel.org>,
	<linux-acpi@vger.kernel.org>
Subject: Re: [PATCH v8 2/5] ACPI, APEI, EINJ: Add wrapper __init function
Date: Tue, 19 Dec 2023 15:39:55 +0000	[thread overview]
Message-ID: <20231219153955.0000473d@Huawei.com> (raw)
In-Reply-To: <6580dcd03b49c_7154929487@dwillia2-mobl3.amr.corp.intel.com.notmuch>

On Mon, 18 Dec 2023 15:59:12 -0800
Dan Williams <dan.j.williams@intel.com> wrote:

> Ben Cheatham wrote:
> > The CXL core module should be able to load regardless of whether the
> > EINJ module initializes correctly. Instead of porting the EINJ module to
> > a library module, add a wrapper __init function around einj_init() to  
> 
> Small quibble with this wording... the larger EINJ module refactoring
> would be separating module_init() from EINJ probe(). As is this simple
> introduction of an einit_init() wrapper *is* refactoring this module to
> be used as a module dependency.
> 
> > pin the EINJ module even if it does not initialize correctly. This
> > should be fine since the EINJ module is only ever unloaded manually.
> > 
> > One note: since the CXL core will be calling into the EINJ module
> > directly, even though it may not have initialized, all CXL helper
> > functions *have* to check if the EINJ module is initialized before
> > doing any work.  
> 
> Another small quibble here, perhaps s/may not have initialized/may not
> have successfully initialized/? Because initialization will have
> definitely completed one way or the other, but callers need to abort if
> it completed in error.
> 
> > Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>  
> 
> Did Jonathan really get in and review this new patch in the series
> before me? If yes, apologies I missed it, if no I think it is best
> practice to not carry forward series Reviewed-by's if new patches appear
> in the series between revisions.

I'm not keen on the solution as it's esoteric and to me seems fragile.
I've looked at discussion on v7 and can see why you ended up with this
but I'd have preferred to see the 'violent' approach :)

I don't mind if there is consensus on this, but not reviewed by from
me for this one.

> 
> 
> > Signed-off-by: Ben Cheatham <Benjamin.Cheatham@amd.com>  
> 
> With above fixups, feel free to add:
> 
> Co-developed-by: Dan Williams <dan.j.williams@intel.com>
> Signed-off-by: Dan Williams <dan.j.williams@intel.com>


  reply	other threads:[~2023-12-19 15:40 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-13 22:36 [PATCH v8 0/5] CXL, ACPI, APEI, EINJ: Update EINJ for CXL error types Ben Cheatham
2023-12-13 22:36 ` [PATCH v8 1/5] cxl, ACPI, APEI, EINJ: Add CXL_EINJ Kconfig option Ben Cheatham
2023-12-18 23:48   ` Dan Williams
2024-01-10 20:31     ` Ben Cheatham
2023-12-13 22:36 ` [PATCH v8 2/5] ACPI, APEI, EINJ: Add wrapper __init function Ben Cheatham
2023-12-18 23:59   ` Dan Williams
2023-12-19 15:39     ` Jonathan Cameron [this message]
2023-12-19 20:48       ` Dan Williams
2023-12-20 14:37         ` Ben Cheatham
2023-12-20 23:51           ` Dan Williams
2023-12-20 14:33       ` Ben Cheatham
2023-12-13 22:37 ` [PATCH v8 3/5] ACPI: Add CXL protocol error defines Ben Cheatham
2023-12-19  5:09   ` Dan Williams
2023-12-13 22:37 ` [PATCH v8 4/5] cxl/core, EINJ: Add CXL debugfs files and EINJ functions Ben Cheatham
2023-12-19  4:47   ` Dan Williams
2024-01-10 20:31     ` Ben Cheatham
2024-01-10 22:10       ` Dan Williams
2024-01-10 22:17         ` Ben Cheatham
2023-12-13 22:37 ` [PATCH v8 5/5] EINJ, Documentation: Update EINJ kernel doc Ben Cheatham

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=20231219153955.0000473d@Huawei.com \
    --to=jonathan.cameron@huawei.com \
    --cc=Benjamin.Cheatham@amd.com \
    --cc=alison.schofield@intel.com \
    --cc=dan.j.williams@intel.com \
    --cc=dave.jiang@intel.com \
    --cc=dave@stogolabs.net \
    --cc=ira.weiny@intel.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-cxl@vger.kernel.org \
    --cc=rafael@kernel.org \
    --cc=vishal.l.verma@intel.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