linux-kernel - Re: [PATCH net-next v3 03/12] net: ethernet: oa

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: <07d3d73b-c920-4503-ad6a-d59fb1b5458a@microchip.com>
Date: Fri, 8 Mar 2024 07:12:12 +0000
From: <Parthiban.Veerasooran@...rochip.com>
To: <andrew@...n.ch>
CC: <davem@...emloft.net>, <edumazet@...gle.com>, <kuba@...nel.org>,
	<pabeni@...hat.com>, <horms@...nel.org>, <saeedm@...dia.com>,
	<anthony.l.nguyen@...el.com>, <netdev@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>, <corbet@....net>,
	<linux-doc@...r.kernel.org>, <robh+dt@...nel.org>,
	<krzysztof.kozlowski+dt@...aro.org>, <conor+dt@...nel.org>,
	<devicetree@...r.kernel.org>, <Horatiu.Vultur@...rochip.com>,
	<ruanjinjie@...wei.com>, <Steen.Hegelund@...rochip.com>,
	<vladimir.oltean@....com>, <UNGLinuxDriver@...rochip.com>,
	<Thorsten.Kummermehr@...rochip.com>, <Pier.Beruto@...emi.com>,
	<Selvamani.Rajagopal@...emi.com>, <Nicolas.Ferre@...rochip.com>,
	<benjamin.bigler@...nformulastudent.ch>
Subject: Re: [PATCH net-next v3 03/12] net: ethernet: oa_tc6: implement
 register read operation

Hi Andrew,

On 07/03/24 6:52 pm, Andrew Lunn wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> On Thu, Mar 07, 2024 at 07:04:20AM +0000, Parthiban.Veerasooran@...rochip.com wrote:
>> Hi Andrew,
>>
>> On 07/03/24 5:49 am, Andrew Lunn wrote:
>>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>>>
>>>>    enum oa_tc6_register_op {
>>>> +     OA_TC6_CTRL_REG_READ = 0,
>>>>         OA_TC6_CTRL_REG_WRITE = 1,
>>>>    };
>>>
>>> I thought it looked a little odd when the enum was added in the
>>> previous patch with the first value of 1, and only one value. Now it
>>> makes more sense.
>> Ok.
>>>
>>> The actual value appears to not matter? It is always
>>>
>>>> +     if (reg_op == OA_TC6_CTRL_REG_WRITE)
>>>
>>> So i would drop the numbering, and leave it to the compiler. The
>>> patches will then look less odd.
>> "drop the numbering", do you refer to this patch alone or previous patch
>> also? If it is for this patch alone then it makes sense as they are
>> going to be 0 and 1 anyway. But if we drop the numbering in the previous
>> patch it will become 0 which will create an issue in the below line as
>> it needs 1,
>>
>> FIELD_PREP(OA_TC6_CTRL_HEADER_WRITE, reg_op)
> 
> That is why i asked:
> 
>> The actual value appears to not matter? It is always
>>
>> +     if (reg_op == OA_TC6_CTRL_REG_WRITE)
> 
> So the actual value does matter, so keep it in the previous patch.
> Does the value of OA_TC6_CTRL_REG_READ matter? Is it also used in
> FIELD_PREP etc? If not, taking away the = 0 will emphasise that
> OA_TC6_CTRL_REG_WRITE has to be 1.
Sorry, I have done a mistake here that's confusing. The define name 
OA_TC6_CTRL_HEADER_WRITE in the FIELD_PREP is supposed to be 
OA_TC6_CTRL_HEADER_WRITE_NOT_READ. This bit field in the control command 
header differentiates the type of operation. If it is 0, then register 
read command and if it is 1, then register write command. So regop in 
the FIELD_PREP actually sets the type of operation.

The values of both OA_TC6_CTRL_REG_READ and OA_TC6_CTRL_REG_WRITE are 
matters here. So let's keep the numbering for both as it is now. But I 
will change the bit field define name as 
OA_TC6_CTRL_HEADER_WRITE_NOT_READ in the next version. Hope you are fine 
with it?

Best regards,
Parthiban V
> 
>          Andrew
>