linux-kernel - Re: [PATCH kernel v2] pci/doe: Support discovery version

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: <089cddf1-3686-4403-a480-07fddd66ab4b@amd.com>
Date: Tue, 5 Mar 2024 17:02:27 +1100
From: Alexey Kardashevskiy <aik@....com>
To: Lukas Wunner <lukas@...ner.de>
Cc: linux-pci@...r.kernel.org, linux-kernel@...r.kernel.org,
 Bjorn Helgaas <bhelgaas@...gle.com>, Dan Williams
 <dan.j.williams@...el.com>, Jonathan Cameron <Jonathan.Cameron@...wei.com>,
 Ira Weiny <ira.weiny@...el.com>
Subject: Re: [PATCH kernel v2] pci/doe: Support discovery version



On 28/2/24 07:41, Lukas Wunner wrote:
> On Mon, Feb 26, 2024 at 02:31:14PM +1100, Alexey Kardashevskiy wrote:
>> Does PCI_DOE_DATA_OBJECT_DISC_REQ_3_DISCOVER_VER need to be in pci-regs.h?
> 
> Yes that's fine.
> 
> 
>> --- a/include/uapi/linux/pci_regs.h
>> +++ b/include/uapi/linux/pci_regs.h
>> @@ -1144,6 +1144,7 @@
>>   #define PCI_DOE_DATA_OBJECT_HEADER_2_LENGTH		0x0003ffff
>>   
>>   #define PCI_DOE_DATA_OBJECT_DISC_REQ_3_INDEX		0x000000ff
>> +#define PCI_DOE_DATA_OBJECT_DISC_REQ_3_DISCOVER_VER	0x0000ff00
>>   #define PCI_DOE_DATA_OBJECT_DISC_RSP_3_VID		0x0000ffff
>>   #define PCI_DOE_DATA_OBJECT_DISC_RSP_3_PROTOCOL		0x00ff0000
>>   #define PCI_DOE_DATA_OBJECT_DISC_RSP_3_NEXT_INDEX	0xff000000
> 
> "DISCOVER" duplicates the preceding "DISC", maybe just
> "PCI_DOE_DATA_OBJECT_DISC_REQ_3_VERSION" for simplicity?

Well, mostly because the PCIe spec specifically says "discovery" in the 
field description, not just "version", but ok, I'll drop it.

btw "DISC" is just confusing, it has nothing to do with discs. _PROTOCOL 
is not even correct anymore, now, in PCIe r6.1 it is called "type", 
lovely :) s/PCI_DOE_DATA_OBJECT_DISC_/PCI_DOE_DISCOVERY_/ (because 
DO==DATA_OBJECT) imho would do better but may be some other day.

> 
> 
>> -static int pci_doe_discovery(struct pci_doe_mb *doe_mb, u8 *index, u16 *vid,
>> +static int pci_doe_discovery(struct pci_doe_mb *doe_mb, u8 capver, u8 *index, u16 *vid,
>>   			     u8 *protocol)
>>   {
>> +	u32 disver = FIELD_PREP(PCI_DOE_DATA_OBJECT_DISC_REQ_3_DISCOVER_VER,
>> +				(capver >= 2) ? 2 : 0);
>>   	u32 request_pl = FIELD_PREP(PCI_DOE_DATA_OBJECT_DISC_REQ_3_INDEX,
>> -				    *index);
>> +				    *index) | disver;
> 
> Hm, why use a separate "disver" variable?  This could be combined
> into a single statement.


Less ugly since we want to keep it 80 chars long (do we, still?). Like 
this looks meh:


{ 

         u32 request_pl = 
FIELD_PREP(PCI_DOE_DATA_OBJECT_DISC_REQ_3_INDEX,
                                     *index) |
FIELD_PREP(PCI_DOE_DATA_OBJECT_DISC_REQ_3_DISCOVER_VER,
                                     (capver >= 2) ? 2 : 0); 

         __le32 request_pl_le = cpu_to_le32(request_pl); 



If we did 100 chars, I could do:

{ 

         u32 request_pl = 
FIELD_PREP(PCI_DOE_DATA_OBJECT_DISC_REQ_3_INDEX, *index) |
                          FIELD_PREP(PCI_DOE_DATA_OBJECT_DISC_REQ_3_VER, 
(capver >= 2) ? 2 : 0);
         __le32 request_pl_le = cpu_to_le32(request_pl); 




> 
> Subject should probably be "PCI/DOE: Support discovery version 2".

> Otherwise LGTM.

Thanks! I'll repost soon.

> 
> Thanks,
> 
> Lukas

-- 
Alexey