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


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ