[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <64f0d7dbf05f6_31c2db2948e@dwillia2-xfh.jf.intel.com.notmuch>
Date: Thu, 31 Aug 2023 11:11:40 -0700
From: Dan Williams <dan.j.williams@...el.com>
To: Terry Bowman <terry.bowman@....com>, <alison.schofield@...el.com>,
<vishal.l.verma@...el.com>, <ira.weiny@...el.com>,
<bwidawsk@...nel.org>, <dan.j.williams@...el.com>,
<dave.jiang@...el.com>, <Jonathan.Cameron@...wei.com>,
<linux-cxl@...r.kernel.org>
CC: <terry.bowman@....com>, <rrichter@....com>,
<linux-kernel@...r.kernel.org>, <bhelgaas@...gle.com>
Subject: RE: [PATCH v9 02/15] cxl/regs: Prepare for multiple users of
register mappings
Terry Bowman wrote:
> From: Robert Richter <rrichter@....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.
Powered by blists - more mailing lists