From: Dan Williams <dan.j.williams@intel.com>
To: Terry Bowman <terry.bowman@amd.com>, <alison.schofield@intel.com>,
<vishal.l.verma@intel.com>, <ira.weiny@intel.com>,
<bwidawsk@kernel.org>, <dan.j.williams@intel.com>,
<dave.jiang@intel.com>, <Jonathan.Cameron@huawei.com>,
<linux-cxl@vger.kernel.org>
Cc: <terry.bowman@amd.com>, <rrichter@amd.com>,
<linux-kernel@vger.kernel.org>, <bhelgaas@google.com>
Subject: RE: [PATCH v9 02/15] cxl/regs: Prepare for multiple users of register mappings
Date: Thu, 31 Aug 2023 11:11:40 -0700 [thread overview]
Message-ID: <64f0d7dbf05f6_31c2db2948e@dwillia2-xfh.jf.intel.com.notmuch> (raw)
In-Reply-To: <20230825233211.3029825-3-terry.bowman@amd.com>
Terry Bowman wrote:
> From: Robert Richter <rrichter@amd.com>
>
> The function devm_cxl_iomap_block() is used to map register mappings
> of CXL component or device registers. A @dev is used to unmap the IO
> regions during device removal.
>
> Now, there are multiple devices using the register mappings. E.g. the
> RAS cap of the Component Registers is used by cxl_pci, the HDM cap
> used in cxl_mem. This could cause IO blocks not being freed and a
> subsequent reinitialization to fail if the same device is used for
> both.
>
> To prevent that, expand cxl_map_component_regs() to pass a @dev to be
> used with devm to IO unmap. This allows to pass the device that
> actually is creating and using the IO region.
>
> For symmetry also change the function i/f of cxl_map_device_regs().
I think @dev is too ambiguous as a name. I.e. when does @dev refer to
the 'struct device *' instance that the registers belong, and when does
@dev refer to the 'struct device *' instance hosting the mapping for
devm operations?
One of the ways I have tried to disambiguate that distinction is using
the name @host to explicitly refer to the context of devm operations,
and @dev is only for context for dev_dbg() operations. Can you clarify
this patch by using @host everywhere that the devm context is being
handled?
This would also satisfy Jonathan's concern. I think it needs to be the
case that @map is explicit about when it is conveying some @dev context for
dev_dbg() messages and when it is conveying the @host for devm
operations because those are 2 different concepts.
It looks like @dev argument you are plumbing here is for when @map->dev
cannot be used for devm operations, so at a minimum use @host as the
variable name to make that clear...
...or always make it the case that @map carries an @host parameter which
would mean that ports would need their own copy of the comp_map versus
directly reusing the one in the cxlds since those 2 mapping instances
need different @host parameters. That feels cleaner to me then
"sometimes map->dev can be used for devm and sometimes not". @map->host
is always the devm context.
next prev parent reply other threads:[~2023-08-31 18:11 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-25 23:31 [PATCH v9 00/15] cxl/pci: Add support for RCH RAS error handling Terry Bowman
2023-08-25 23:31 ` [PATCH v9 01/15] cxl/port: Pre-initialize component register mappings Terry Bowman
2023-08-29 13:38 ` Jonathan Cameron
2023-08-31 12:22 ` Robert Richter
2023-09-01 9:06 ` Jonathan Cameron
2023-08-25 23:31 ` [PATCH v9 02/15] cxl/regs: Prepare for multiple users of " Terry Bowman
2023-08-29 13:52 ` Jonathan Cameron
2023-08-31 12:43 ` Robert Richter
2023-09-01 9:08 ` Jonathan Cameron
2023-08-31 18:11 ` Dan Williams [this message]
2023-09-01 9:10 ` Jonathan Cameron
2023-08-25 23:31 ` [PATCH v9 03/15] cxl/pci: Store the endpoint's Component Register mappings in struct cxl_dev_state Terry Bowman
2023-08-25 23:32 ` [PATCH v9 04/15] cxl/hdm: Use stored Component Register mappings to map HDM decoder capability Terry Bowman
2023-08-25 23:32 ` [PATCH v9 05/15] cxl/pci: Remove Component Register base address from struct cxl_dev_state Terry Bowman
2023-08-25 23:32 ` [PATCH v9 06/15] cxl/port: Remove Component Register base address from struct cxl_port Terry Bowman
2023-08-25 23:32 ` [PATCH v9 07/15] cxl/pci: Add RCH downstream port AER register discovery Terry Bowman
2023-08-25 23:32 ` [PATCH v9 08/15] PCI/AER: Refactor cper_print_aer() for use by CXL driver module Terry Bowman
2023-08-25 23:32 ` [PATCH v9 09/15] cxl/pci: Update CXL error logging to use RAS register address Terry Bowman
2023-08-25 23:32 ` [PATCH v9 10/15] cxl/pci: Map RCH downstream AER registers for logging protocol errors Terry Bowman
2023-08-25 23:32 ` [PATCH v9 11/15] cxl/pci: Add RCH downstream port error logging Terry Bowman
2023-08-25 23:32 ` [PATCH v9 12/15] cxl/pci: Disable root port interrupts in RCH mode Terry Bowman
2023-08-25 23:32 ` [PATCH v9 13/15] PCI/AER: Forward RCH downstream port-detected errors to the CXL.mem dev handler Terry Bowman
2023-08-25 23:32 ` [PATCH v9 14/15] PCI/AER: Unmask RCEC internal errors to enable RCH downstream port error handling Terry Bowman
2023-08-25 23:32 ` [PATCH v9 15/15] cxl/core/regs: Rename phys_addr in cxl_map_component_regs() Terry Bowman
2023-08-29 13:54 ` Jonathan Cameron
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=64f0d7dbf05f6_31c2db2948e@dwillia2-xfh.jf.intel.com.notmuch \
--to=dan.j.williams@intel.com \
--cc=Jonathan.Cameron@huawei.com \
--cc=alison.schofield@intel.com \
--cc=bhelgaas@google.com \
--cc=bwidawsk@kernel.org \
--cc=dave.jiang@intel.com \
--cc=ira.weiny@intel.com \
--cc=linux-cxl@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rrichter@amd.com \
--cc=terry.bowman@amd.com \
--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