netdev - Re: [PATCH net-next v1] idpf: add support for IDPF PCI programming interface

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] [day] [month] [year] [list]
Message-ID: <cd911ad9-b590-4880-b72f-5b65f7d33a52@intel.com>
Date: Tue, 26 Aug 2025 14:06:28 -0700
From: "Linga, Pavan Kumar" <pavan.kumar.linga@...el.com>
To: Przemek Kitszel <przemyslaw.kitszel@...el.com>
CC: <madhu.chittim@...el.com>, <netdev@...r.kernel.org>,
	<intel-wired-lan@...ts.osuosl.org>, Sridhar Samudrala
	<sridhar.samudrala@...el.com>
Subject: Re: [PATCH net-next v1] idpf: add support for IDPF PCI programming
 interface



On 8/26/2025 1:12 PM, Przemek Kitszel wrote:
> On 8/26/25 19:28, Pavan Kumar Linga wrote:
>> At present IDPF supports only 0x1452 and 0x145C as PF and VF device IDs
>> on our current generation hardware. Future hardware exposes a new set of
>> device IDs for each generation. To avoid adding a new device ID for each
>> generation and to make the driver forward and backward compatible,
>> make use of the IDPF PCI programming interface to load the driver.
>>
>> Write and read the VF_ARQBAL mailbox register to find if the current
>> device is a PF or a VF.
>>
>> PCI SIG allocated a new programming interface for the IDPF compliant
>> ethernet network controller devices. It can be found at:
>> https://members.pcisig.com/wg/PCI-SIG/document/20113
>> with the document titled as 'PCI Code and ID Assignment Revision 1.16'
>> or any latest revisions.
>>
>> Reviewed-by: Madhu Chittim <madhu.chittim@...el.com>
>> Reviewed-by: Sridhar Samudrala <sridhar.samudrala@...el.com>
>> Signed-off-by: Pavan Kumar Linga <pavan.kumar.linga@...el.com>
>> ---
>>   drivers/net/ethernet/intel/idpf/idpf.h        |  1 +
>>   drivers/net/ethernet/intel/idpf/idpf_main.c   | 73 ++++++++++++++-----
>>   drivers/net/ethernet/intel/idpf/idpf_vf_dev.c | 37 ++++++++++
>>   3 files changed, 94 insertions(+), 17 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/intel/idpf/idpf.h b/drivers/net/ 
>> ethernet/intel/idpf/idpf.h
>> index 19a248d5b124..4b8e944994cb 100644
>> --- a/drivers/net/ethernet/intel/idpf/idpf.h
>> +++ b/drivers/net/ethernet/intel/idpf/idpf.h
>> @@ -983,6 +983,7 @@ void idpf_mbx_task(struct work_struct *work);
>>   void idpf_vc_event_task(struct work_struct *work);
>>   void idpf_dev_ops_init(struct idpf_adapter *adapter);
>>   void idpf_vf_dev_ops_init(struct idpf_adapter *adapter);
>> +int idpf_is_vf_device(struct pci_dev *pdev, u8 *is_vf);
> 
> please change it to *bool

Sure, will fix it.

> 
>>   int idpf_intr_req(struct idpf_adapter *adapter);
>>   void idpf_intr_rel(struct idpf_adapter *adapter);
>>   u16 idpf_get_max_tx_hdr_size(struct idpf_adapter *adapter);
>> diff --git a/drivers/net/ethernet/intel/idpf/idpf_main.c b/drivers/ 
>> net/ethernet/intel/idpf/idpf_main.c
>> index 8c46481d2e1f..b161715e1168 100644
>> --- a/drivers/net/ethernet/intel/idpf/idpf_main.c
>> +++ b/drivers/net/ethernet/intel/idpf/idpf_main.c
>> @@ -7,11 +7,57 @@
>>   #define DRV_SUMMARY    "Intel(R) Infrastructure Data Path Function 
>> Linux Driver"
>> +#define IDPF_NETWORK_ETHERNET_PROGIF                0x01
>> +#define IDPF_CLASS_NETWORK_ETHERNET_PROGIF            \
>> +    (PCI_CLASS_NETWORK_ETHERNET << 8 | IDPF_NETWORK_ETHERNET_PROGIF)
>> +
> 
> [...]
> 
>> @@ -304,6 +342,7 @@ static int idpf_probe(struct pci_dev *pdev, const 
>> struct pci_device_id *ent)
>>   static const struct pci_device_id idpf_pci_tbl[] = {
>>       { PCI_VDEVICE(INTEL, IDPF_DEV_ID_PF)},
>>       { PCI_VDEVICE(INTEL, IDPF_DEV_ID_VF)},
>> +    { PCI_DEVICE_CLASS(IDPF_CLASS_NETWORK_ETHERNET_PROGIF, 0xffffff)},
> 
> PCI_ANY or ~0 as last param would be closer to what others use,
> in this form it looks like you avoid to be found when someone adds
> a new helper for such usage
> 

That makes sense. Will use ~0.

>>       { /* Sentinel */ }
>>   };
>>   MODULE_DEVICE_TABLE(pci, idpf_pci_tbl);
>> diff --git a/drivers/net/ethernet/intel/idpf/idpf_vf_dev.c b/drivers/ 
>> net/ethernet/intel/idpf/idpf_vf_dev.c
>> index 4cc58c83688c..5bf9d3ccb624 100644
>> --- a/drivers/net/ethernet/intel/idpf/idpf_vf_dev.c
>> +++ b/drivers/net/ethernet/intel/idpf/idpf_vf_dev.c
>> @@ -7,6 +7,43 @@
>>   #define IDPF_VF_ITR_IDX_SPACING        0x40
>> +#define IDPF_VF_TEST_VAL        0xFEED0000
>> +
>> +/**
>> + * idpf_is_vf_device - Helper to find if it is a VF device
>> + * @pdev: PCI device information struct
>> + * @is_vf: used to update VF device status
>> + *
>> + * Return: %0 on success, -%errno on failure.
>> + */
>> +int idpf_is_vf_device(struct pci_dev *pdev, u8 *is_vf)
>> +{
>> +    struct resource mbx_region;
>> +    resource_size_t mbx_start;
>> +    void __iomem *mbx_addr;
>> +    long len;
>> +
>> +    resource_set_range(&mbx_region,    VF_BASE, IDPF_VF_MBX_REGION_SZ);
>> +
>> +    mbx_start = pci_resource_start(pdev, 0) + mbx_region.start;
>> +    len = resource_size(&mbx_region);
>> +
>> +    mbx_addr = ioremap(mbx_start, len);
>> +    if (!mbx_addr)
>> +        return -EIO;
>> +
>> +    writel(IDPF_VF_TEST_VAL, mbx_addr + VF_ARQBAL - VF_BASE);
>> +
>> +    /* Force memory write to complete before reading it back */
>> +    wmb();
>> +
>> +    *is_vf = readl(mbx_addr + VF_ARQBAL - VF_BASE) == IDPF_VF_TEST_VAL;
>> +
>> +    iounmap(mbx_addr);
>> +
>> +    return 0;
>> +}
>> +
>>   /**
>>    * idpf_vf_ctlq_reg_init - initialize default mailbox registers
>>    * @adapter: adapter structure
> 

Thanks,
Pavan