From: "Jiawen Wu" <jiawenwu@trustnetic.com>
To: "'Vadim Fedorenko'" <vadim.fedorenko@linux.dev>,
<netdev@vger.kernel.org>, "'Andrew Lunn'" <andrew+netdev@lunn.ch>,
"'David S. Miller'" <davem@davemloft.net>,
"'Eric Dumazet'" <edumazet@google.com>,
"'Jakub Kicinski'" <kuba@kernel.org>,
"'Paolo Abeni'" <pabeni@redhat.com>,
"'Russell King'" <linux@armlinux.org.uk>,
"'Simon Horman'" <horms@kernel.org>,
"'Jacob Keller'" <jacob.e.keller@intel.com>,
<netdev@vger.kernel.org>, "'Andrew Lunn'" <andrew+netdev@lunn.ch>,
"'David S. Miller'" <davem@davemloft.net>,
"'Eric Dumazet'" <edumazet@google.com>,
"'Jakub Kicinski'" <kuba@kernel.org>,
"'Paolo Abeni'" <pabeni@redhat.com>,
"'Russell King'" <linux@armlinux.org.uk>,
"'Simon Horman'" <horms@kernel.org>,
"'Jacob Keller'" <jacob.e.keller@intel.com>
Cc: "'Mengyuan Lou'" <mengyuanlou@net-swift.com>,
"'Mengyuan Lou'" <mengyuanlou@net-swift.com>
Subject: RE: [PATCH net-next 5/5] net: txgbe: support getting module EEPROM by page
Date: Thu, 13 Nov 2025 10:21:39 +0800 [thread overview]
Message-ID: <001401dc5444$3e897f60$bb9c7e20$@trustnetic.com> (raw)
In-Reply-To: <b7702efc-9994-4656-9d4e-29c2c8145ab3@linux.dev>
On Wed, Nov 12, 2025 8:49 PM, Vadim Fedorenko wrote:
> On 12/11/2025 05:58, Jiawen Wu wrote:
> > Getting module EEPROM has been supported in TXGBE SP devices, since SFP
> > driver has already implemented it.
> >
> > Now add support to read module EEPROM for AML devices. Towards this, add
> > a new firmware mailbox command to get the page data.
> >
> > Signed-off-by: Jiawen Wu <jiawenwu@trustnetic.com>
> > ---
> > .../net/ethernet/wangxun/txgbe/txgbe_aml.c | 37 +++++++++++++++++++
> > .../net/ethernet/wangxun/txgbe/txgbe_aml.h | 3 ++
> > .../ethernet/wangxun/txgbe/txgbe_ethtool.c | 30 +++++++++++++++
> > .../net/ethernet/wangxun/txgbe/txgbe_type.h | 11 ++++++
> > 4 files changed, 81 insertions(+)
> >
> > diff --git a/drivers/net/ethernet/wangxun/txgbe/txgbe_aml.c b/drivers/net/ethernet/wangxun/txgbe/txgbe_aml.c
> > index 3b6ea456fbf7..12900abfa91a 100644
> > --- a/drivers/net/ethernet/wangxun/txgbe/txgbe_aml.c
> > +++ b/drivers/net/ethernet/wangxun/txgbe/txgbe_aml.c
> > @@ -73,6 +73,43 @@ int txgbe_test_hostif(struct wx *wx)
> > WX_HI_COMMAND_TIMEOUT, true);
> > }
> >
> > +int txgbe_read_eeprom_hostif(struct wx *wx,
> > + struct txgbe_hic_i2c_read *buffer,
> > + u32 length, u8 *data)
> > +{
> > + u32 buf_size = sizeof(struct txgbe_hic_i2c_read) - sizeof(u8);
> > + u32 total_len = buf_size + length;
> > + u32 dword_len, value, i;
> > + u8 local_data[256];
> > + int err;
> > +
> > + if (total_len > sizeof(local_data))
> > + return -EINVAL;
>
> if it's really possible? SFF pages are 128 bytes, you reserve 256 bytes
> of local buffer. What are you protecting from?
It can be changed to 128 + sizeof(struct txgbe_hic_i2c_read).
>
> > +
> > + buffer->hdr.cmd = FW_READ_EEPROM_CMD;
> > + buffer->hdr.buf_len = sizeof(struct txgbe_hic_i2c_read) -
> > + sizeof(struct wx_hic_hdr);
> > + buffer->hdr.cmd_or_resp.cmd_resv = FW_CEM_CMD_RESERVED;
> > +
> > + err = wx_host_interface_command(wx, (u32 *)buffer,
> > + sizeof(struct txgbe_hic_i2c_read),
> > + WX_HI_COMMAND_TIMEOUT, false);
> > + if (err != 0)
> > + return err;
> > +
> > + dword_len = (total_len + 3) / 4;
>
> round_up()?
>
> > +
> > + 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.
>
> > +
> > + memcpy(data, &local_data[buf_size], length);
> > + return 0;
> > +}
> > +
> > static int txgbe_identify_module_hostif(struct wx *wx,
> > struct txgbe_hic_get_module_info *buffer)
> > {
> > diff --git a/drivers/net/ethernet/wangxun/txgbe/txgbe_aml.h b/drivers/net/ethernet/wangxun/txgbe/txgbe_aml.h
> > index 7c8fa48e68d3..4f6df0ee860b 100644
> > --- a/drivers/net/ethernet/wangxun/txgbe/txgbe_aml.h
> > +++ b/drivers/net/ethernet/wangxun/txgbe/txgbe_aml.h
> > @@ -7,6 +7,9 @@
> > void txgbe_gpio_init_aml(struct wx *wx);
> > irqreturn_t txgbe_gpio_irq_handler_aml(int irq, void *data);
> > int txgbe_test_hostif(struct wx *wx);
> > +int txgbe_read_eeprom_hostif(struct wx *wx,
> > + struct txgbe_hic_i2c_read *buffer,
> > + u32 length, u8 *data);
> > int txgbe_set_phy_link(struct wx *wx);
> > int txgbe_identify_module(struct wx *wx);
> > void txgbe_setup_link(struct wx *wx);
> > diff --git a/drivers/net/ethernet/wangxun/txgbe/txgbe_ethtool.c b/drivers/net/ethernet/wangxun/txgbe/txgbe_ethtool.c
> > index f553ec5f8238..1f60121fe73c 100644
> > --- a/drivers/net/ethernet/wangxun/txgbe/txgbe_ethtool.c
> > +++ b/drivers/net/ethernet/wangxun/txgbe/txgbe_ethtool.c
> > @@ -10,6 +10,7 @@
> > #include "../libwx/wx_lib.h"
> > #include "txgbe_type.h"
> > #include "txgbe_fdir.h"
> > +#include "txgbe_aml.h"
> > #include "txgbe_ethtool.h"
> >
> > int txgbe_get_link_ksettings(struct net_device *netdev,
> > @@ -534,6 +535,34 @@ static int txgbe_set_rxnfc(struct net_device *dev, struct ethtool_rxnfc *cmd)
> > return ret;
> > }
> >
> > +static int
> > +txgbe_get_module_eeprom_by_page(struct net_device *netdev,
> > + const struct ethtool_module_eeprom *page_data,
> > + struct netlink_ext_ack *extack)
> > +{
> > + struct wx *wx = netdev_priv(netdev);
> > + struct txgbe_hic_i2c_read buffer;
> > + int err;
> > +
> > + if (!test_bit(WX_FLAG_SWFW_RING, wx->flags))
> > + return -EOPNOTSUPP;
> > +
> > + buffer.length = (__force u32)cpu_to_be32(page_data->length);
> > + buffer.offset = (__force u32)cpu_to_be32(page_data->offset);
>
> maybe txgbe_hic_i2c_read::length and txgbe_hic_i2c_read::offset should
> be __be32 ?
Sure.
>
> > + buffer.page = page_data->page;
> > + buffer.bank = page_data->bank;
> > + buffer.i2c_address = page_data->i2c_address;
> > +
> > + err = txgbe_read_eeprom_hostif(wx, &buffer, page_data->length,
> > + page_data->data);
> > + if (err) {
> > + wx_err(wx, "Failed to read module EEPROM\n");
> > + return err;
> > + }
> > +
> > + return page_data->length;
> > +}
> > +
> > static const struct ethtool_ops txgbe_ethtool_ops = {
> > .supported_coalesce_params = ETHTOOL_COALESCE_USECS |
> > ETHTOOL_COALESCE_TX_MAX_FRAMES_IRQ |
> > @@ -568,6 +597,7 @@ static const struct ethtool_ops txgbe_ethtool_ops = {
> > .set_msglevel = wx_set_msglevel,
> > .get_ts_info = wx_get_ts_info,
> > .get_ts_stats = wx_get_ptp_stats,
> > + .get_module_eeprom_by_page = txgbe_get_module_eeprom_by_page,
> > };
> >
> > void txgbe_set_ethtool_ops(struct net_device *netdev)
> > diff --git a/drivers/net/ethernet/wangxun/txgbe/txgbe_type.h b/drivers/net/ethernet/wangxun/txgbe/txgbe_type.h
> > index e72edb9ef084..3d1bec39d74c 100644
> > --- a/drivers/net/ethernet/wangxun/txgbe/txgbe_type.h
> > +++ b/drivers/net/ethernet/wangxun/txgbe/txgbe_type.h
> > @@ -353,6 +353,7 @@ void txgbe_do_reset(struct net_device *netdev);
> > #define FW_PHY_GET_LINK_CMD 0xC0
> > #define FW_PHY_SET_LINK_CMD 0xC1
> > #define FW_GET_MODULE_INFO_CMD 0xC5
> > +#define FW_READ_EEPROM_CMD 0xC6
> >
> > struct txgbe_sff_id {
> > u8 identifier; /* A0H 0x00 */
> > @@ -394,6 +395,16 @@ struct txgbe_hic_ephy_getlink {
> > u8 resv[6];
> > };
> >
> > +struct txgbe_hic_i2c_read {
> > + struct wx_hic_hdr hdr;
> > + u32 offset;
> > + u32 length;
> > + u8 page;
> > + u8 bank;
> > + u8 i2c_address;
> > + u8 data;
> > +};
> you removed struct txgbe_hic_i2c_read in the patch 2 just to introduce
> it in this patch?
Yes, the name of these structure would be more appropriate.
>
> > +
> > #define NODE_PROP(_NAME, _PROP) \
> > (const struct software_node) { \
> > .name = _NAME, \
>
>
next prev parent reply other threads:[~2025-11-13 2:24 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-12 5:58 [PATCH net-next 0/5] TXGBE support more modules Jiawen Wu
2025-11-12 5:58 ` [PATCH net-next 1/5] net: txgbe: support CR modules for AML devices Jiawen Wu
2025-11-12 5:58 ` [PATCH net-next 2/5] net: txgbe: rename the SFP related Jiawen Wu
2025-11-12 5:58 ` [PATCH net-next 3/5] net: txgbe: improve functions of AML 40G devices Jiawen Wu
2025-11-12 5:58 ` [PATCH net-next 4/5] net: txgbe: delay to identify modules in .ndo_open Jiawen Wu
2025-11-12 5:58 ` [PATCH net-next 5/5] net: txgbe: support getting module EEPROM by page Jiawen Wu
2025-11-12 12:48 ` Vadim Fedorenko
2025-11-13 2:21 ` Jiawen Wu [this message]
2025-11-13 11:57 ` Vadim Fedorenko
2025-11-17 6:26 ` Jiawen Wu
2025-11-13 22:18 ` Andrew Lunn
2025-11-17 6:14 ` Jiawen Wu
2025-11-17 13:58 ` Andrew Lunn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='001401dc5444$3e897f60$bb9c7e20$@trustnetic.com' \
--to=jiawenwu@trustnetic.com \
--cc=andrew+netdev@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=jacob.e.keller@intel.com \
--cc=kuba@kernel.org \
--cc=linux@armlinux.org.uk \
--cc=mengyuanlou@net-swift.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=vadim.fedorenko@linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).