From: Ferruh Yigit <ferruh.yigit@amd.com>
To: 王颢 <howard_wang@realsil.com.cn>, "dev@dpdk.org" <dev@dpdk.org>
Cc: "pro_nic_dpdk@realtek.com" <pro_nic_dpdk@realtek.com>
Subject: Re: 答复: [PATCH v6 01/17] net/r8169: add PMD driver skeleton
Date: Mon, 11 Nov 2024 09:08:34 +0000 [thread overview]
Message-ID: <e76c7a8f-5221-4930-93c9-16ff97d59a91@amd.com> (raw)
In-Reply-To: <2a6d7c1303ec43f6a00dbbf0924c1bdd@realsil.com.cn>
On 11/11/2024 3:46 AM, 王颢 wrote:
> Dear Ferruh,
>
> I apologize for the issues that have arisen during the process of splitting a complete driver into several small patches.
>
> On 11/8/2024 12:11 PM, Howard Wang wrote:
>> Meson build infrastructure, r8169_ethdev minimal skeleton, header with
>> Realtek NIC device and vendor IDs.
>>
>> Signed-off-by: Howard Wang <howard_wang@realsil.com.cn>
>
> <...>
>
> ===> I referred to Atlantic’s approach for this, and as a matter of fact, his first commit message was done in this manner.
> I will think again about how it should be modified.
>
No problem with the commit splits and orders, thanks for the update there.
Only comment in this patch is 'RTL_DEV_PRIVATE' macro is not used in the
patch and it can be added when you use the macro, so this is a simple issue.
Also I have a comment that build fails after some patchs, this also does
not require changing how patch split done, just fix build after each patch.
I am not sure if there is a misunderstanding but change requests are
mostly simple ones, I expect they can be fixed in one or two days, and I
am hopping to merge the driver in -rc2 or -rc3 at worst.
> net/atlantic: add PMD driver skeleton
> Makefile/meson build infrastructure, atl_ethdev minimal skeleton,
> header with aquantia aQtion NIC device and vendor IDs.
>
> Signed-off-by: Igor Russkikh <igor.russkikh@aquantia.com>
> Signed-off-by: Pavel Belous <pavel.belous@aquantia.com>
>
>
>
> What do you think to add macros for the PCI device IDs, naming them makes it easier to know which devices are supported.
>
> ===> Regarding the device ID, for 0x8125, the supported device is indeed called 8125. So, should we name a macro like DEVICE_ID_RTL8125 to replace it?
>
Ahh, I see, matching is simple for 8125, device id and product number is
same :), is it same for all supported devices?
{ RTE_PCI_DEVICE(PCI_VENDOR_ID_REALTEK, 0x8125) },
{ RTE_PCI_DEVICE(PCI_VENDOR_ID_REALTEK, 0x8162) },
{ RTE_PCI_DEVICE(PCI_VENDOR_ID_REALTEK, 0x8126) },
{ RTE_PCI_DEVICE(PCI_VENDOR_ID_REALTEK, 0x5000) },
>
> Best regards,
> Howard Wang
>
> -----邮件原件-----
> 发件人: Ferruh Yigit <ferruh.yigit@amd.com>
> 发送时间: 2024年11月11日 8:15
> 收件人: 王颢 <howard_wang@realsil.com.cn>; dev@dpdk.org
> 抄送: pro_nic_dpdk@realtek.com
> 主题: Re: [PATCH v6 01/17] net/r8169: add PMD driver skeleton
>
>
> External mail.
>
>
>
> On 11/8/2024 12:11 PM, Howard Wang wrote:
>> Meson build infrastructure, r8169_ethdev minimal skeleton, header with
>> Realtek NIC device and vendor IDs.
>>
>> Signed-off-by: Howard Wang <howard_wang@realsil.com.cn>
>
> <...>
>
>> +/*
>> + * The set of PCI devices this driver supports */ static const
>> +struct rte_pci_id pci_id_r8169_map[] = {
>> + { RTE_PCI_DEVICE(PCI_VENDOR_ID_REALTEK, 0x8125) },
>> + { RTE_PCI_DEVICE(PCI_VENDOR_ID_REALTEK, 0x8162) },
>> + { RTE_PCI_DEVICE(PCI_VENDOR_ID_REALTEK, 0x8126) },
>> + { RTE_PCI_DEVICE(PCI_VENDOR_ID_REALTEK, 0x5000) },
>>
>
> What do you think to add macros for the PCI device IDs, naming them makes it easier to know which devices are supported.
>
> <...>
>
>> +
>> +#define RTL_DEV_PRIVATE(eth_dev) \
>> + ((struct rtl_adapter *)((eth_dev)->data->dev_private))
>> +
>>
>
> This macro is only used a few patches later, what do you think to add this macro when used?
>
>
next prev parent reply other threads:[~2024-11-11 9:08 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-08 12:11 [PATCH v6 00/17] Modify code as suggested by the maintainer Howard Wang
2024-11-08 12:11 ` [PATCH v6 01/17] net/r8169: add PMD driver skeleton Howard Wang
2024-11-08 15:58 ` Stephen Hemminger
2024-11-11 0:14 ` Ferruh Yigit
2024-11-11 3:46 ` 答复: " 王颢
2024-11-11 9:08 ` Ferruh Yigit [this message]
2024-11-11 9:24 ` 答复: " 王颢
2024-11-11 9:31 ` Ferruh Yigit
2024-11-08 12:11 ` [PATCH v6 02/17] net/r8169: add logging structure Howard Wang
2024-11-08 12:11 ` [PATCH v6 03/17] net/r8169: add hardware registers access routines Howard Wang
2024-11-08 12:11 ` [PATCH v6 04/17] net/r8169: implement core logic for Tx/Rx Howard Wang
2024-11-08 12:11 ` [PATCH v6 05/17] net/r8169: add support for hw config Howard Wang
2024-11-11 0:15 ` Ferruh Yigit
2024-11-11 9:44 ` 答复: " 王颢
2024-11-08 12:11 ` [PATCH v6 06/17] net/r8169: add phy registers access routines Howard Wang
2024-11-08 12:11 ` [PATCH v6 07/17] net/r8169: add support for hardware operations Howard Wang
2024-11-08 12:11 ` [PATCH v6 08/17] net/r8169: add support for phy configuration Howard Wang
2024-11-11 0:16 ` Ferruh Yigit
2024-11-11 8:18 ` 答复: " 王颢
2024-11-11 9:21 ` Ferruh Yigit
2024-11-08 12:11 ` [PATCH v6 09/17] net/r8169: add support for hw initialization Howard Wang
2024-11-11 0:16 ` Ferruh Yigit
2024-11-08 12:11 ` [PATCH v6 10/17] net/r8169: add link status and interrupt management Howard Wang
2024-11-08 12:11 ` [PATCH v6 11/17] net/r8169: implement Rx path Howard Wang
2024-11-11 0:20 ` Ferruh Yigit
2024-11-08 12:11 ` [PATCH v6 12/17] net/r8169: implement Tx path Howard Wang
2024-11-11 0:20 ` Ferruh Yigit
2024-11-08 12:11 ` [PATCH v6 13/17] net/r8169: implement device statistics Howard Wang
2024-11-11 0:21 ` Ferruh Yigit
2024-11-08 12:11 ` [PATCH v6 14/17] net/r8169: implement promisc and allmulti modes Howard Wang
2024-11-08 12:11 ` [PATCH v6 15/17] net/r8169: implement MTU configuration Howard Wang
2024-11-08 12:11 ` [PATCH v6 16/17] net/r8169: add support for getting fw version Howard Wang
2024-11-08 12:11 ` [PATCH v6 17/17] net/r8169: add driver_start and driver_stop Howard Wang
2024-11-11 0:26 ` [PATCH v6 00/17] Modify code as suggested by the maintainer Ferruh Yigit
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e76c7a8f-5221-4930-93c9-16ff97d59a91@amd.com \
--to=ferruh.yigit@amd.com \
--cc=dev@dpdk.org \
--cc=howard_wang@realsil.com.cn \
--cc=pro_nic_dpdk@realtek.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.