netdev - Re: [PATCH v17 04/22] cxl: allow Type2 drivers to map cxl component regs

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: <d56b1bda-14b7-4d48-a999-68e4e4d8c06b@amd.com>
Date: Wed, 6 Aug 2025 10:43:53 +0100
From: Alejandro Lucero Palau <alucerop@....com>
To: Dave Jiang <dave.jiang@...el.com>, 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
Subject: Re: [PATCH v17 04/22] cxl: allow Type2 drivers to map cxl component
 regs


On 7/28/25 17:23, Dave Jiang wrote:
>
> On 7/25/25 3:55 PM, dan.j.williams@...el.com wrote:
>> alejandro.lucero-palau@ wrote:
>>> From: Alejandro Lucero <alucerop@....com>
>>>
>>> Export cxl core functions for a Type2 driver being able to discover and
>>> map the device component registers.
>> I would squash this with patch5, up to Dave.
> I would prefer that. In general I'd prefer to see the enabling code going with where it's being used to see how it gets utilized. It makes reviewing a bit easier. Thanks!


It was recommended to have sfc changes isolated for facilitating someone 
testing the type2 support with another driver. But I think it should not 
be a big issue for anyone to squash some of them, so I'll do so.


Thanks


> DJ
>>> Signed-off-by: Alejandro Lucero <alucerop@....com>
>>> ---
>>>   drivers/cxl/core/port.c |  1 +
>>>   drivers/cxl/cxl.h       |  7 -------
>>>   drivers/cxl/cxlpci.h    | 12 ------------
>>>   include/cxl/cxl.h       |  8 ++++++++
>>>   include/cxl/pci.h       | 15 +++++++++++++++
>>>   5 files changed, 24 insertions(+), 19 deletions(-)
>>>
>> [..]
>>> diff --git a/include/cxl/cxl.h b/include/cxl/cxl.h
>>> index 9c1a82c8af3d..0810c18d7aef 100644
>>> --- a/include/cxl/cxl.h
>>> +++ b/include/cxl/cxl.h
>>> @@ -70,6 +70,10 @@ struct cxl_regs {
>>>   	);
>>>   };
>>>   
>>> +#define   CXL_CM_CAP_CAP_ID_RAS 0x2
>>> +#define   CXL_CM_CAP_CAP_ID_HDM 0x5
>>> +#define   CXL_CM_CAP_CAP_HDM_VERSION 1
>>> +
>>>   struct cxl_reg_map {
>>>   	bool valid;
>>>   	int id;
>>> @@ -223,4 +227,8 @@ struct cxl_dev_state *_devm_cxl_dev_state_create(struct device *dev,
>>>   		(drv_struct *)_devm_cxl_dev_state_create(parent, type, serial, dvsec,	\
>>>   						      sizeof(drv_struct), mbox);	\
>>>   	})
>>> +
>>> +int cxl_map_component_regs(const struct cxl_register_map *map,
>>> +			   struct cxl_component_regs *regs,
>>> +			   unsigned long map_mask);
>> With this function now becoming public it really wants some kdoc, and a
>> rename to add devm_ so that readers are not suprised by hidden devres
>> behavior behind this API.
>>
>> It was ok previously because it was private to drivers/cxl/ where
>> everything is devres managed.