netdev - RE: [PATCH net-next 5/5] net: txgbe: support getting module EEPROM by page

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <012901dc578b$1683cf80$438b6e80$@trustnetic.com>
Date: Mon, 17 Nov 2025 14:26:20 +0800
From: Jiawen Wu <jiawenwu@...stnetic.com>
To: "'Vadim Fedorenko'" <vadim.fedorenko@...ux.dev>,
	<netdev@...r.kernel.org>,
	"'Andrew Lunn'" <andrew+netdev@...n.ch>,
	"'David S. Miller'" <davem@...emloft.net>,
	"'Eric Dumazet'" <edumazet@...gle.com>,
	"'Jakub Kicinski'" <kuba@...nel.org>,
	"'Paolo Abeni'" <pabeni@...hat.com>,
	"'Russell King'" <linux@...linux.org.uk>,
	"'Simon Horman'" <horms@...nel.org>,
	"'Jacob Keller'" <jacob.e.keller@...el.com>,
	<netdev@...r.kernel.org>,
	"'Andrew Lunn'" <andrew+netdev@...n.ch>,
	"'David S. Miller'" <davem@...emloft.net>,
	"'Eric Dumazet'" <edumazet@...gle.com>,
	"'Jakub Kicinski'" <kuba@...nel.org>,
	"'Paolo Abeni'" <pabeni@...hat.com>,
	"'Russell King'" <linux@...linux.org.uk>,
	"'Simon Horman'" <horms@...nel.org>,
	"'Jacob Keller'" <jacob.e.keller@...el.com>
Cc: "'Mengyuan Lou'" <mengyuanlou@...-swift.com>,
	"'Mengyuan Lou'" <mengyuanlou@...-swift.com>
Subject: RE: [PATCH net-next 5/5] net: txgbe: support getting module EEPROM by page

> >>> +
> >>> +	for (i = 0; i < dword_len; i++) {
> >>> +		value = rd32a(wx, WX_FW2SW_MBOX, i);
> >>> +		le32_to_cpus(&value);
> >>> +
> >>> +		memcpy(&local_data[i * 4], &value, 4);
> >>> +	}
> >>
> >> the logic here is not clear from the first read of the code. effectively
> >> in the reply you have the same txgbe_hic_i2c_read struct but without
> >> data field, which is obviously VLA, but then you simply skip the result
> >> of read of txgbe_hic_i2c_read and only provide the real data back to the
> >> caller. Maybe you can organize the code the way it can avoid double copying?
> >
> > Because the length of real data is variable, now it could be 1 or 128. But the total
> > length of the command buffer is DWORD aligned. So we designed only a 1-byte
> > data field in struct txgbe_hic_i2c_read, to avoid redundant reading and writing
> > during the SW-FW interaction.
> >
> > For 1-byte data, wx_host_interface_command() can be used to set 'return_data'
> > to true, then page->data = buffer->data. For other cases, I think it would be more
> > convenient to read directly from the mailbox registers.
> 
> With such design you always have your return data starting at offset of
> 15, which is absolutely unaligned. And then it needs more buffer
> dancing.

OK. We could consider redesigning this buffer structure. Return data will start
at offset of 16, and reserve 4 bytes. And longer data will be directly read from
the mailbox register. Is this design more reasonable?