[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <036f740c-480c-425d-82b4-2e21522524d7@loongson.cn>
Date: Mon, 8 Jul 2024 15:31:29 +0800
From: Yanteng Si <siyanteng@...ngson.cn>
To: Huacai Chen <chenhuacai@...nel.org>, Serge Semin <fancer.lancer@...il.com>
Cc: andrew@...n.ch, hkallweit1@...il.com, peppe.cavallaro@...com,
alexandre.torgue@...s.st.com, joabreu@...opsys.com, Jose.Abreu@...opsys.com,
linux@...linux.org.uk, guyinggang@...ngson.cn, netdev@...r.kernel.org,
chris.chenfeiyang@...il.com, si.yanteng@...ux.dev
Subject: Re: [PATCH net-next v13 14/15] net: stmmac: dwmac-loongson: Add
Loongson GNET support
在 2024/7/7 21:57, Huacai Chen 写道:
> On Sun, Jul 7, 2024 at 6:51 PM Serge Semin <fancer.lancer@...il.com> wrote:
>> On Sat, Jul 06, 2024 at 06:36:06PM +0800, Huacai Chen wrote:
>>> On Sat, Jul 6, 2024 at 6:31 PM Yanteng Si <siyanteng@...ngson.cn> wrote:
>>>>
>>>> 在 2024/7/5 20:17, Serge Semin 写道:
>>>>> On Fri, Jul 05, 2024 at 08:06:32PM +0800, Yanteng Si wrote:
>>>>>>>>> But if you aren't comfortable with such naming we can change the
>>>>>>>>> macro to something like:
>>>>>>>>> #define DWMAC_CORE_LOONGSON_MULTI_CH 0x10
>>>>>>>> Maybe DWMAC_CORE_LOONGSON_MULTICHAN or DWMAC_CORE_LOONGSON_MULTI_CHAN
>>>>>>>> is a little better?
>>>>>>>>
>>>>>>> Well, I don't have a strong opinion about that in this case.
>>>>>>> Personally I prefer to have the shortest and still readable version.
>>>>>>> It decreases the probability of the lines splitting in case of the
>>>>>>> long-line statements or highly indented code. From that perspective
>>>>>>> something like DWMAC_CORE_LS_MULTI_CH would be even better. But seeing
>>>>>>> the driver currently don't have such cases, we can use any of those
>>>>>>> name. But it's better to be of such length so the code lines the name
>>>>>>> is utilized in wouldn't exceed +80 chars.
>>>>>> Okay.
>>>>>>
>>>>>> I added an indent before 0xXX and left three Spaces before the comment,
>>>>>>
>>>>>> which uses huacai's MULTICHAN and doesn't exceed 80 chars.
>>>>> I meant that it's better to have the length of the macro name so
>>>>> !the code where it's utilized!
>>>>> wouldn't exceed +80 chars. That's the criteria for the upper length
>>>>> boundary I normally follow in such cases.
>>>>>
>>>> Oh, I see!
>>>>
>>>> Hmm, let's compare the two options:
>>>>
>>>> DWMAC_CORE_LS_MULTI_CH
>>>>
>>>> DWMAC_CORE_LS_MULTICHAN
>>>>
>>>> With just one more char, the increased readability seems to be
>>>> worth it.
>>> If you really like short names, please use DWMAC_CORE_MULTICHAN. LS
>>> has no valuable meaning in this loongson-specific file.
>> At least some version of the Loongson vendor name should be in the
>> macro. Omitting it may cause a confusion since the name would turn to
>> a too generic form. Seeing the multi DMA-channels feature is the
>> Synopsys invention, should you meet the macro like DWMAC_CORE_MULTI_CH
>> in the code that may cause an impression that there is a special
>> Synopsys DW MAC ID for that. Meanwhile in fact the custom ID is
>> specific for the Loongson GMAC/GNET controllers only.
> Well,
> I prefer
> DWMAC_CORE_LOONGSON_MULTI_CHAN / DWMAC_CORE_LOONGSON_MULTICHAN /
> DWMAC_CORE_LOONGSON_MCH / DWMAC_CORE_MULTICHAN,
> But I also accept DWMAC_CORE_LS_MULTI_CHAN / DWMAC_CORE_LS_MULTICHAN,
> But I can't accept DWMAC_CORE_LS2K2000.
>
I'll use DWMAC_CORE_LS_MULTICHAN for now, Let's continue discussing
this macro in v14 (If necessary).
Thanks,
Yanteng
Powered by blists - more mailing lists