[dpdk-dev] [PATCH v3 02/11] baseband/acc100: add register definition file

[Ferruh Yigit]

On 9/3/2020 3:15 AM, Xu, Rosen wrote:
> Hi,
> 
>> -----Original Message-----
>> From: Chautru, Nicolas <nicolas.chautru at intel.com>
>> Sent: Sunday, August 30, 2020 1:40
>> To: Xu, Rosen <rosen.xu at intel.com>; dev at dpdk.org; akhil.goyal at nxp.com
>> Cc: Richardson, Bruce <bruce.richardson at intel.com>
>> Subject: RE: [dpdk-dev] [PATCH v3 02/11] baseband/acc100: add register
>> definition file
>>
>> Hi Rosen,
>>
>>> From: Xu, Rosen <rosen.xu at intel.com>
>>>
>>> Hi,
>>>
>>>> -----Original Message-----
>>>> From: dev <dev-bounces at dpdk.org> On Behalf Of Nicolas Chautru
>>>> Sent: Wednesday, August 19, 2020 8:25
>>>> To: dev at dpdk.org; akhil.goyal at nxp.com
>>>> Cc: Richardson, Bruce <bruce.richardson at intel.com>; Chautru, Nicolas
>>>> <nicolas.chautru at intel.com>
>>>> Subject: [dpdk-dev] [PATCH v3 02/11] baseband/acc100: add register
>>>> definition file
>>>>
>>>> Add in the list of registers for the device and related
>>>> HW specs definitions.
>>>>
>>>> Signed-off-by: Nicolas Chautru <nicolas.chautru at intel.com>

<...>

>>>> @@ -0,0 +1,1068 @@
>>>> +/* SPDX-License-Identifier: BSD-3-Clause
>>>> + * Copyright(c) 2017 Intel Corporation
>>>> + */
>>>> +
>>>> +#ifndef ACC100_PF_ENUM_H
>>>> +#define ACC100_PF_ENUM_H
>>>> +
>>>> +/*
>>>> + * ACC100 Register mapping on PF BAR0
>>>> + * This is automatically generated from RDL, format may change with
>> new
>>>> RDL
>>>> + * Release.
>>>> + * Variable names are as is
>>>> + */
>>>> +enum {
>>>> +	HWPfQmgrEgressQueuesTemplate          =  0x0007FE00,
>>>> +	HWPfQmgrIngressAq                     =  0x00080000,
>>>> +	HWPfQmgrArbQAvail                     =  0x00A00010,

<...>

>>>> +	HwPfPcieGpexPexPioArcacheControl      =  0x00D9C304,
>>>> +	HwPfPcieGpexPabObSizeControlVc0       =  0x00D9C310
>>>> +};
>>>
>>> Why not macro definition but enum?
>>>
>>
>> Well both would "work". The main reason really is that this long enum is
>> automatically generated from RDL output from the chip design.
>> But still in that case I would argue enum is cleaner so that to put all these
>> incremental addresses together.
>> This can also helps when debugging as this is kept post compilation as both
>> value and enum var.
>> Any concern or any BKM from other PMDs?
> 
> Can you read DPDK coding style firstly?
> https://doc.dpdk.org/guides-16.11/contributing/coding_style.html
> It's not make sense to define HW address in your way.

Both works as Nicolas said, and I agree enum is better for the reasons Nicolas
mentioned.

Also coding style says:
"
Wherever possible, enums and inline functions should be preferred to macros,
since they provide additional degrees of type-safety and can allow compilers to
emit extra warnings about unsafe code.
"

What is the concern to have enum instead of macro?