netdev - Re: [PATCH v16 05/22] cxl: Add function for type2 cxl regs setup

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: <682f835fba701_3e70100a5@dwillia2-xfh.jf.intel.com.notmuch>
Date: Thu, 22 May 2025 13:04:47 -0700
From: Dan Williams <dan.j.williams@...el.com>
To: Alejandro Lucero Palau <alucerop@....com>, Dan Williams
	<dan.j.williams@...el.com>, <alejandro.lucero-palau@....com>,
	<linux-cxl@...r.kernel.org>, <netdev@...r.kernel.org>, <edward.cree@....com>,
	<davem@...emloft.net>, <kuba@...nel.org>, <pabeni@...hat.com>,
	<edumazet@...gle.com>, <dave.jiang@...el.com>
CC: Ben Cheatham <benjamin.cheatham@....com>, Jonathan Cameron
	<Jonathan.Cameron@...wei.com>
Subject: Re: [PATCH v16 05/22] cxl: Add function for type2 cxl regs setup

Alejandro Lucero Palau wrote:
[..]
> > The driver should know in advance if calling:
> >
> >      cxl_pci_setup_regs(pdev, CXL_REGLOC_RBI_MEMDEV, &map);
> >
> > ...will fail. Put that logic where it belongs in the probe function of
> > the type-2 driver directly. This helper is not helping, it is just
> > obfuscating.
> 
> 
> As I said in the previous email, I disagree. The CXL API should be 
> handling all this. A client only cares about certain things, let's say 
> manageable things like capabilities, without going deep into CXL specs 
> about how all that needs to be implemented. This patch introduces a 
> function embedding different calls for those innerworkings which should 
> only be handled by the CXL core.

No. Please keep this policy out of the core. Do not invent a new
"capabilities" contract that the CXL core needs to maintain, and do not
add thin "cxl_pci_accel_" helpers that just wrap existing core
functionality. Call existing core functions directly and only augment
them at the point where fundamental assumptions are violated between
the "Type-3" and "Type-2" device models.

If the fundamental assumption violation boils down to a policy
difference between Type-2 and Type-3 then move that policy out of the
core. For example, register discovery is a mechanism, what the client
does with the result of that mechanism is policy and belongs in the
leaf/client. It was an accident of implementation that mandatory Type-3
register blocks were validated in the core not in cxl_pci from the
outset.