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
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ