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: <83e0b340-521e-4d60-90bb-92d2ca6f5abe@microchip.com>
Date: Thu, 7 Mar 2024 07:04:20 +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 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)

Could you clarify? or do I have any misunderstanding here?
> 
>> +static int oa_tc6_check_ctrl_read_reply(struct oa_tc6 *tc6, u8 size)
>> +{
>> +     u32 *tx_buf = tc6->spi_ctrl_tx_buf;
>> +     u32 *rx_buf = tc6->spi_ctrl_rx_buf + OA_TC6_CTRL_IGNORED_SIZE;
>> +
>> +     /* The echoed control read header must match with the one that was
>> +      * transmitted.
>> +      */
>> +     if (*tx_buf != *rx_buf)
>> +             return -ENODEV;
> 
> Another case where -EPROTO might be better?
Yes, I will use -EPROTO in the next version as it is likely "Protocol error"

Best regards,
Parthiban V
> 
>          Andrew
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ