From: Simon Horman <horms@kernel.org>
To: Justin Lai <justinlai0215@realtek.com>
Cc: kuba@kernel.org, davem@davemloft.net, edumazet@google.com,
pabeni@redhat.com, andrew+netdev@lunn.ch,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
pkshih@realtek.com, larry.chiu@realtek.com
Subject: Re: [PATCH net-next 1/2] rtase: Add support for RTL907XD-VA PCIe port
Date: Tue, 12 Nov 2024 13:57:09 +0000 [thread overview]
Message-ID: <20241112135709.GO4507@kernel.org> (raw)
In-Reply-To: <20241111025532.291735-2-justinlai0215@realtek.com>
On Mon, Nov 11, 2024 at 10:55:31AM +0800, Justin Lai wrote:
> Add RTL907XD-VA hardware version and modify the speed reported by
> .get_link_ksettings in ethtool_ops.
>
> Signed-off-by: Justin Lai <justinlai0215@realtek.com>
Hi Justin,
this seems to be doing several things:
1) Adding defines for existing values
2) Correcting the speed for RTL907XD-V1
3) Adding support for RTL907XD-VA
I think these would be best handled as 3 patches.
And I wonder if 2) is a bug fix for net rather than an
enhancement for net-next.
> ---
> drivers/net/ethernet/realtek/rtase/rtase.h | 10 +++++--
> .../net/ethernet/realtek/rtase/rtase_main.c | 26 ++++++++++++++-----
> 2 files changed, 28 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/net/ethernet/realtek/rtase/rtase.h b/drivers/net/ethernet/realtek/rtase/rtase.h
> index 583c33930f88..2bbfcad613ab 100644
> --- a/drivers/net/ethernet/realtek/rtase/rtase.h
> +++ b/drivers/net/ethernet/realtek/rtase/rtase.h
> @@ -9,7 +9,11 @@
> #ifndef RTASE_H
> #define RTASE_H
>
> -#define RTASE_HW_VER_MASK 0x7C800000
> +#define RTASE_HW_VER_MASK 0x7C800000
> +#define RTASE_HW_VER_906X_7XA 0x00800000
> +#define RTASE_HW_VER_906X_7XC 0x04000000
> +#define RTASE_HW_VER_907XD_V1 0x04800000
> +#define RTASE_HW_VER_907XD_VA 0x08000000
>
> #define RTASE_RX_DMA_BURST_256 4
> #define RTASE_TX_DMA_BURST_UNLIMITED 7
> @@ -170,7 +174,7 @@ enum rtase_registers {
> RTASE_INT_MITI_TX = 0x0A00,
> RTASE_INT_MITI_RX = 0x0A80,
>
> - RTASE_VLAN_ENTRY_0 = 0xAC80,
> + RTASE_VLAN_ENTRY_0 = 0xAC80,
This change doesn't seem related to the rest of the patch.
> };
>
> enum rtase_desc_status_bit {
> @@ -327,6 +331,8 @@ struct rtase_private {
> u16 int_nums;
> u16 tx_int_mit;
> u16 rx_int_mit;
> +
> + u32 hw_ver;
> };
>
> #define RTASE_LSO_64K 64000
> diff --git a/drivers/net/ethernet/realtek/rtase/rtase_main.c b/drivers/net/ethernet/realtek/rtase/rtase_main.c
> index f8777b7663d3..73ebdf0bc376 100644
> --- a/drivers/net/ethernet/realtek/rtase/rtase_main.c
> +++ b/drivers/net/ethernet/realtek/rtase/rtase_main.c
> @@ -1714,10 +1714,22 @@ static int rtase_get_settings(struct net_device *dev,
> struct ethtool_link_ksettings *cmd)
> {
> u32 supported = SUPPORTED_MII | SUPPORTED_Pause | SUPPORTED_Asym_Pause;
> + const struct rtase_private *tp = netdev_priv(dev);
>
> ethtool_convert_legacy_u32_to_link_mode(cmd->link_modes.supported,
> supported);
> - cmd->base.speed = SPEED_5000;
> +
> + switch (tp->hw_ver) {
> + case RTASE_HW_VER_906X_7XA:
> + case RTASE_HW_VER_906X_7XC:
> + cmd->base.speed = SPEED_5000;
> + break;
> + case RTASE_HW_VER_907XD_V1:
> + case RTASE_HW_VER_907XD_VA:
> + cmd->base.speed = SPEED_10000;
> + break;
> + }
> +
> cmd->base.duplex = DUPLEX_FULL;
> cmd->base.port = PORT_MII;
> cmd->base.autoneg = AUTONEG_DISABLE;
> @@ -1974,13 +1986,15 @@ static void rtase_init_software_variable(struct pci_dev *pdev,
>
> static bool rtase_check_mac_version_valid(struct rtase_private *tp)
> {
> - u32 hw_ver = rtase_r32(tp, RTASE_TX_CONFIG_0) & RTASE_HW_VER_MASK;
> bool known_ver = false;
>
> - switch (hw_ver) {
> - case 0x00800000:
> - case 0x04000000:
> - case 0x04800000:
> + tp->hw_ver = rtase_r32(tp, RTASE_TX_CONFIG_0) & RTASE_HW_VER_MASK;
Now that this is setting tp->hw_ver perhaps the name of the function should
be changed? Perhaps rtase_set_mac_version() ? Perhaps a single patch can be
created that reworks this function, preparing for other work, by:
* Changes the name of the function
* Sets tp->hw_ver
* Changes the return type from bool to int
(as is currently done as part of patch 2/2)
Although a refactor, perhaps that could be part of a series for net that
also includes two more patches that depend on it and:
* Correct the speed for RTL907XD-V1
* Corrects error handling in the case where the version is invalid
(as is currently done as part of patch 2/2)
And then any remaning enhancements can be addressed as follow-up
patches for net-next.
> +
> + switch (tp->hw_ver) {
> + case RTASE_HW_VER_906X_7XA:
> + case RTASE_HW_VER_906X_7XC:
> + case RTASE_HW_VER_907XD_V1:
> + case RTASE_HW_VER_907XD_VA:
> known_ver = true;
> break;
> }
> --
> 2.34.1
>
next prev parent reply other threads:[~2024-11-12 13:57 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-11 2:55 [PATCH net-next 0/2] Add support for the RTL907XD-VA and fix a driver warning Justin Lai
2024-11-11 2:55 ` [PATCH net-next 1/2] rtase: Add support for RTL907XD-VA PCIe port Justin Lai
2024-11-12 13:57 ` Simon Horman [this message]
2024-11-14 4:01 ` Justin Lai
2024-11-11 2:55 ` [PATCH net-next 2/2] rtase: Fix error code in rtase_init_one() Justin Lai
2024-11-12 13:40 ` Simon Horman
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=20241112135709.GO4507@kernel.org \
--to=horms@kernel.org \
--cc=andrew+netdev@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=justinlai0215@realtek.com \
--cc=kuba@kernel.org \
--cc=larry.chiu@realtek.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=pkshih@realtek.com \
/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).