linux-kernel - Re: [PATCH v3 07/11] cxl: Introduce callback to translate a decoder's HPA to the next parent port

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aMpvXmmbons8PIxA@rric.localdomain>
Date: Wed, 17 Sep 2025 10:20:46 +0200
From: Robert Richter <rrichter@....com>
To: Dave Jiang <dave.jiang@...el.com>
Cc: Alison Schofield <alison.schofield@...el.com>,
	Vishal Verma <vishal.l.verma@...el.com>,
	Ira Weiny <ira.weiny@...el.com>,
	Dan Williams <dan.j.williams@...el.com>,
	Jonathan Cameron <Jonathan.Cameron@...wei.com>,
	Davidlohr Bueso <dave@...olabs.net>, linux-cxl@...r.kernel.org,
	linux-kernel@...r.kernel.org, Gregory Price <gourry@...rry.net>,
	"Fabio M. De Francesco" <fabio.m.de.francesco@...ux.intel.com>,
	Terry Bowman <terry.bowman@....com>,
	Joshua Hahn <joshua.hahnjy@...il.com>
Subject: Re: [PATCH v3 07/11] cxl: Introduce callback to translate a
 decoder's HPA to the next parent port

On 15.09.25 13:22:14, Dave Jiang wrote:
> On 9/12/25 7:45 AM, Robert Richter wrote:

> > @@ -619,6 +631,7 @@ struct cxl_port {
> >  	struct cxl_dport *parent_dport;
> >  	struct ida decoder_ida;
> >  	struct cxl_register_map reg_map;
> > +	cxl_to_hpa_fn to_hpa;
> 

> The more I look at this, the more I feel the callback should be part
> of 'struct cxl_rd_ops' and not under each port. While this provides
> flexibility in a general case if there is a need to translate at
> each level, the actual use case in the field today only requires
> translation at the top as far as I can tell. And the translate
> functionality should be part of a decoder and not a port. And in
> this case, the root decoder would suffice.

Ok, I see the tendence to handle this in a more specific use case.  A
change of the implementation should be possible, will change that.

Thanks,

-Robert