All the mail mirrored from lore.kernel.org
 help / color / mirror / Atom feed
From: "Arınç ÜNAL via B4 Relay" <devnull+arinc.unal.arinc9.com@kernel.org>
To: Daniel Golle <daniel@makrotopia.org>,
	DENG Qingfang <dqfext@gmail.com>,
	 Sean Wang <sean.wang@mediatek.com>, Andrew Lunn <andrew@lunn.ch>,
	 Florian Fainelli <f.fainelli@gmail.com>,
	 Vladimir Oltean <olteanv@gmail.com>,
	 "David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	 Jakub Kicinski <kuba@kernel.org>,
	Paolo Abeni <pabeni@redhat.com>,
	 Matthias Brugger <matthias.bgg@gmail.com>,
	 AngeloGioacchino Del Regno
	<angelogioacchino.delregno@collabora.com>,
	 Russell King <linux@armlinux.org.uk>
Cc: "Bartel Eerdekens" <bartel.eerdekens@constell8.be>,
	mithat.guner@xeront.com, erkin.bozoglu@xeront.com,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-mediatek@lists.infradead.org,
	"Arınç ÜNAL" <arinc.unal@arinc9.com>
Subject: [PATCH net-next v2 01/15] net: dsa: mt7530: disable EEE abilities on failure on MT7531 and MT7988
Date: Mon, 22 Apr 2024 10:15:08 +0300	[thread overview]
Message-ID: <20240422-for-netnext-mt7530-improvements-4-v2-1-a75157ba76ad@arinc9.com> (raw)
In-Reply-To: <20240422-for-netnext-mt7530-improvements-4-v2-0-a75157ba76ad@arinc9.com>

From: Arınç ÜNAL <arinc.unal@arinc9.com>

The MT7531_FORCE_EEE1G and MT7531_FORCE_EEE100 bits let the
PMCR_FORCE_EEE1G and PMCR_FORCE_EEE100 bits determine the 1G/100 EEE
abilities of the MAC. If MT7531_FORCE_EEE1G and MT7531_FORCE_EEE100 are
unset, the abilities are left to be determined by PHY auto polling.

The commit 40b5d2f15c09 ("net: dsa: mt7530: Add support for EEE features")
made it so that the PMCR_FORCE_EEE1G and PMCR_FORCE_EEE100 bits are set on
mt753x_phylink_mac_link_up(). But it did not set the MT7531_FORCE_EEE1G and
MT7531_FORCE_EEE100 bits. Because of this, the EEE abilities will be
determined by PHY auto polling, regardless of the result of phy_init_eee().

Define these bits and add them to the MT7531_FORCE_MODE mask which is set
in mt7531_setup_common(). With this, there won't be any EEE abilities set
when phy_init_eee() returns a negative value.

Thanks to Russell for explaining when phy_init_eee() could return a
negative value below.

Looking at phy_init_eee(), it could return a negative value when:

1. phydev->drv is NULL
2. if genphy_c45_eee_is_active() returns negative
3. if genphy_c45_eee_is_active() returns zero, it returns -EPROTONOSUPPORT
4. if phy_set_bits_mmd() fails (e.g. communication error with the PHY)

If we then look at genphy_c45_eee_is_active(), then:

genphy_c45_read_eee_adv() and genphy_c45_read_eee_lpa() propagate their
non-zero return values, otherwise this function returns zero or positive
integer.

If we then look at genphy_c45_read_eee_adv(), then a failure of
phy_read_mmd() would cause a negative value to be returned.

Looking at genphy_c45_read_eee_lpa(), the same is true.

So, it can be summarised as:

- phydev->drv is NULL
- there is a communication error accessing the PHY
- EEE is not active

otherwise, it returns zero on success.

If one wishes to determine whether an error occurred vs EEE not being
supported through negotiation for the negotiated speed, if it returns
-EPROTONOSUPPORT in the latter case. Other error codes mean either the
driver has been unloaded or communication error.

In conclusion, determining the EEE abilities by PHY auto polling shouldn't
result in having any EEE abilities enabled, when one of the last two
situations in the summary happens. And it seems that if phydev->drv is
NULL, there would be bigger problems with the device than a broken link. So
this is not a bugfix.

Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com>
---
 drivers/net/dsa/mt7530.h | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/net/dsa/mt7530.h b/drivers/net/dsa/mt7530.h
index 94932c3dbde9..f7c5355c1642 100644
--- a/drivers/net/dsa/mt7530.h
+++ b/drivers/net/dsa/mt7530.h
@@ -328,11 +328,15 @@ enum mt7530_vlan_port_acc_frm {
 #define  MT7531_FORCE_DPX		BIT(29)
 #define  MT7531_FORCE_RX_FC		BIT(28)
 #define  MT7531_FORCE_TX_FC		BIT(27)
+#define  MT7531_FORCE_EEE100		BIT(26)
+#define  MT7531_FORCE_EEE1G		BIT(25)
 #define  MT7531_FORCE_MODE		(MT7531_FORCE_LNK | \
 					 MT7531_FORCE_SPD | \
 					 MT7531_FORCE_DPX | \
 					 MT7531_FORCE_RX_FC | \
-					 MT7531_FORCE_TX_FC)
+					 MT7531_FORCE_TX_FC | \
+					 MT7531_FORCE_EEE100 | \
+					 MT7531_FORCE_EEE1G)
 #define  PMCR_LINK_SETTINGS_MASK	(PMCR_TX_EN | PMCR_FORCE_SPEED_1000 | \
 					 PMCR_RX_EN | PMCR_FORCE_SPEED_100 | \
 					 PMCR_TX_FC_EN | PMCR_RX_FC_EN | \

-- 
2.40.1



WARNING: multiple messages have this Message-ID (diff)
From: "Arınç ÜNAL via B4 Relay" <devnull+arinc.unal.arinc9.com@kernel.org>
To: Daniel Golle <daniel@makrotopia.org>,
	DENG Qingfang <dqfext@gmail.com>,
	 Sean Wang <sean.wang@mediatek.com>, Andrew Lunn <andrew@lunn.ch>,
	 Florian Fainelli <f.fainelli@gmail.com>,
	 Vladimir Oltean <olteanv@gmail.com>,
	 "David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	 Jakub Kicinski <kuba@kernel.org>,
	Paolo Abeni <pabeni@redhat.com>,
	 Matthias Brugger <matthias.bgg@gmail.com>,
	 AngeloGioacchino Del Regno
	<angelogioacchino.delregno@collabora.com>,
	 Russell King <linux@armlinux.org.uk>
Cc: "Bartel Eerdekens" <bartel.eerdekens@constell8.be>,
	mithat.guner@xeront.com, erkin.bozoglu@xeront.com,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-mediatek@lists.infradead.org,
	"Arınç ÜNAL" <arinc.unal@arinc9.com>
Subject: [PATCH net-next v2 01/15] net: dsa: mt7530: disable EEE abilities on failure on MT7531 and MT7988
Date: Mon, 22 Apr 2024 10:15:08 +0300	[thread overview]
Message-ID: <20240422-for-netnext-mt7530-improvements-4-v2-1-a75157ba76ad@arinc9.com> (raw)
In-Reply-To: <20240422-for-netnext-mt7530-improvements-4-v2-0-a75157ba76ad@arinc9.com>

From: Arınç ÜNAL <arinc.unal@arinc9.com>

The MT7531_FORCE_EEE1G and MT7531_FORCE_EEE100 bits let the
PMCR_FORCE_EEE1G and PMCR_FORCE_EEE100 bits determine the 1G/100 EEE
abilities of the MAC. If MT7531_FORCE_EEE1G and MT7531_FORCE_EEE100 are
unset, the abilities are left to be determined by PHY auto polling.

The commit 40b5d2f15c09 ("net: dsa: mt7530: Add support for EEE features")
made it so that the PMCR_FORCE_EEE1G and PMCR_FORCE_EEE100 bits are set on
mt753x_phylink_mac_link_up(). But it did not set the MT7531_FORCE_EEE1G and
MT7531_FORCE_EEE100 bits. Because of this, the EEE abilities will be
determined by PHY auto polling, regardless of the result of phy_init_eee().

Define these bits and add them to the MT7531_FORCE_MODE mask which is set
in mt7531_setup_common(). With this, there won't be any EEE abilities set
when phy_init_eee() returns a negative value.

Thanks to Russell for explaining when phy_init_eee() could return a
negative value below.

Looking at phy_init_eee(), it could return a negative value when:

1. phydev->drv is NULL
2. if genphy_c45_eee_is_active() returns negative
3. if genphy_c45_eee_is_active() returns zero, it returns -EPROTONOSUPPORT
4. if phy_set_bits_mmd() fails (e.g. communication error with the PHY)

If we then look at genphy_c45_eee_is_active(), then:

genphy_c45_read_eee_adv() and genphy_c45_read_eee_lpa() propagate their
non-zero return values, otherwise this function returns zero or positive
integer.

If we then look at genphy_c45_read_eee_adv(), then a failure of
phy_read_mmd() would cause a negative value to be returned.

Looking at genphy_c45_read_eee_lpa(), the same is true.

So, it can be summarised as:

- phydev->drv is NULL
- there is a communication error accessing the PHY
- EEE is not active

otherwise, it returns zero on success.

If one wishes to determine whether an error occurred vs EEE not being
supported through negotiation for the negotiated speed, if it returns
-EPROTONOSUPPORT in the latter case. Other error codes mean either the
driver has been unloaded or communication error.

In conclusion, determining the EEE abilities by PHY auto polling shouldn't
result in having any EEE abilities enabled, when one of the last two
situations in the summary happens. And it seems that if phydev->drv is
NULL, there would be bigger problems with the device than a broken link. So
this is not a bugfix.

Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com>
---
 drivers/net/dsa/mt7530.h | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/net/dsa/mt7530.h b/drivers/net/dsa/mt7530.h
index 94932c3dbde9..f7c5355c1642 100644
--- a/drivers/net/dsa/mt7530.h
+++ b/drivers/net/dsa/mt7530.h
@@ -328,11 +328,15 @@ enum mt7530_vlan_port_acc_frm {
 #define  MT7531_FORCE_DPX		BIT(29)
 #define  MT7531_FORCE_RX_FC		BIT(28)
 #define  MT7531_FORCE_TX_FC		BIT(27)
+#define  MT7531_FORCE_EEE100		BIT(26)
+#define  MT7531_FORCE_EEE1G		BIT(25)
 #define  MT7531_FORCE_MODE		(MT7531_FORCE_LNK | \
 					 MT7531_FORCE_SPD | \
 					 MT7531_FORCE_DPX | \
 					 MT7531_FORCE_RX_FC | \
-					 MT7531_FORCE_TX_FC)
+					 MT7531_FORCE_TX_FC | \
+					 MT7531_FORCE_EEE100 | \
+					 MT7531_FORCE_EEE1G)
 #define  PMCR_LINK_SETTINGS_MASK	(PMCR_TX_EN | PMCR_FORCE_SPEED_1000 | \
 					 PMCR_RX_EN | PMCR_FORCE_SPEED_100 | \
 					 PMCR_TX_FC_EN | PMCR_RX_FC_EN | \

-- 
2.40.1



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID (diff)
From: "Arınç ÜNAL" <arinc.unal@arinc9.com>
To: Daniel Golle <daniel@makrotopia.org>,
	DENG Qingfang <dqfext@gmail.com>,
	 Sean Wang <sean.wang@mediatek.com>, Andrew Lunn <andrew@lunn.ch>,
	 Florian Fainelli <f.fainelli@gmail.com>,
	 Vladimir Oltean <olteanv@gmail.com>,
	 "David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	 Jakub Kicinski <kuba@kernel.org>,
	Paolo Abeni <pabeni@redhat.com>,
	 Matthias Brugger <matthias.bgg@gmail.com>,
	 AngeloGioacchino Del Regno
	<angelogioacchino.delregno@collabora.com>,
	 Russell King <linux@armlinux.org.uk>
Cc: "Bartel Eerdekens" <bartel.eerdekens@constell8.be>,
	mithat.guner@xeront.com, erkin.bozoglu@xeront.com,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-mediatek@lists.infradead.org,
	"Arınç ÜNAL" <arinc.unal@arinc9.com>
Subject: [PATCH net-next v2 01/15] net: dsa: mt7530: disable EEE abilities on failure on MT7531 and MT7988
Date: Mon, 22 Apr 2024 10:15:08 +0300	[thread overview]
Message-ID: <20240422-for-netnext-mt7530-improvements-4-v2-1-a75157ba76ad@arinc9.com> (raw)
In-Reply-To: <20240422-for-netnext-mt7530-improvements-4-v2-0-a75157ba76ad@arinc9.com>

The MT7531_FORCE_EEE1G and MT7531_FORCE_EEE100 bits let the
PMCR_FORCE_EEE1G and PMCR_FORCE_EEE100 bits determine the 1G/100 EEE
abilities of the MAC. If MT7531_FORCE_EEE1G and MT7531_FORCE_EEE100 are
unset, the abilities are left to be determined by PHY auto polling.

The commit 40b5d2f15c09 ("net: dsa: mt7530: Add support for EEE features")
made it so that the PMCR_FORCE_EEE1G and PMCR_FORCE_EEE100 bits are set on
mt753x_phylink_mac_link_up(). But it did not set the MT7531_FORCE_EEE1G and
MT7531_FORCE_EEE100 bits. Because of this, the EEE abilities will be
determined by PHY auto polling, regardless of the result of phy_init_eee().

Define these bits and add them to the MT7531_FORCE_MODE mask which is set
in mt7531_setup_common(). With this, there won't be any EEE abilities set
when phy_init_eee() returns a negative value.

Thanks to Russell for explaining when phy_init_eee() could return a
negative value below.

Looking at phy_init_eee(), it could return a negative value when:

1. phydev->drv is NULL
2. if genphy_c45_eee_is_active() returns negative
3. if genphy_c45_eee_is_active() returns zero, it returns -EPROTONOSUPPORT
4. if phy_set_bits_mmd() fails (e.g. communication error with the PHY)

If we then look at genphy_c45_eee_is_active(), then:

genphy_c45_read_eee_adv() and genphy_c45_read_eee_lpa() propagate their
non-zero return values, otherwise this function returns zero or positive
integer.

If we then look at genphy_c45_read_eee_adv(), then a failure of
phy_read_mmd() would cause a negative value to be returned.

Looking at genphy_c45_read_eee_lpa(), the same is true.

So, it can be summarised as:

- phydev->drv is NULL
- there is a communication error accessing the PHY
- EEE is not active

otherwise, it returns zero on success.

If one wishes to determine whether an error occurred vs EEE not being
supported through negotiation for the negotiated speed, if it returns
-EPROTONOSUPPORT in the latter case. Other error codes mean either the
driver has been unloaded or communication error.

In conclusion, determining the EEE abilities by PHY auto polling shouldn't
result in having any EEE abilities enabled, when one of the last two
situations in the summary happens. And it seems that if phydev->drv is
NULL, there would be bigger problems with the device than a broken link. So
this is not a bugfix.

Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com>
---
 drivers/net/dsa/mt7530.h | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/net/dsa/mt7530.h b/drivers/net/dsa/mt7530.h
index 94932c3dbde9..f7c5355c1642 100644
--- a/drivers/net/dsa/mt7530.h
+++ b/drivers/net/dsa/mt7530.h
@@ -328,11 +328,15 @@ enum mt7530_vlan_port_acc_frm {
 #define  MT7531_FORCE_DPX		BIT(29)
 #define  MT7531_FORCE_RX_FC		BIT(28)
 #define  MT7531_FORCE_TX_FC		BIT(27)
+#define  MT7531_FORCE_EEE100		BIT(26)
+#define  MT7531_FORCE_EEE1G		BIT(25)
 #define  MT7531_FORCE_MODE		(MT7531_FORCE_LNK | \
 					 MT7531_FORCE_SPD | \
 					 MT7531_FORCE_DPX | \
 					 MT7531_FORCE_RX_FC | \
-					 MT7531_FORCE_TX_FC)
+					 MT7531_FORCE_TX_FC | \
+					 MT7531_FORCE_EEE100 | \
+					 MT7531_FORCE_EEE1G)
 #define  PMCR_LINK_SETTINGS_MASK	(PMCR_TX_EN | PMCR_FORCE_SPEED_1000 | \
 					 PMCR_RX_EN | PMCR_FORCE_SPEED_100 | \
 					 PMCR_TX_FC_EN | PMCR_RX_FC_EN | \

-- 
2.40.1


  reply	other threads:[~2024-04-22  7:15 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-22  7:15 [PATCH net-next v2 00/15] MT7530 DSA Subdriver Improvements Act IV Arınç ÜNAL via B4 Relay
2024-04-22  7:15 ` Arınç ÜNAL
2024-04-22  7:15 ` Arınç ÜNAL via B4 Relay
2024-04-22  7:15 ` Arınç ÜNAL via B4 Relay [this message]
2024-04-22  7:15   ` [PATCH net-next v2 01/15] net: dsa: mt7530: disable EEE abilities on failure on MT7531 and MT7988 Arınç ÜNAL
2024-04-22  7:15   ` Arınç ÜNAL via B4 Relay
2024-04-22  7:15 ` [PATCH net-next v2 02/15] net: dsa: mt7530: refactor MT7530_PMCR_P() Arınç ÜNAL via B4 Relay
2024-04-22  7:15   ` Arınç ÜNAL
2024-04-22  7:15   ` Arınç ÜNAL via B4 Relay
2024-04-22  7:15 ` [PATCH net-next v2 03/15] net: dsa: mt7530: rename p5_intf_sel and use only for MT7530 switch Arınç ÜNAL via B4 Relay
2024-04-22  7:15   ` Arınç ÜNAL
2024-04-22  7:15   ` Arınç ÜNAL via B4 Relay
2024-04-22  7:15 ` [PATCH net-next v2 04/15] net: dsa: mt7530: rename mt753x_bpdu_port_fw enum to mt753x_to_cpu_fw Arınç ÜNAL via B4 Relay
2024-04-22  7:15   ` Arınç ÜNAL
2024-04-22  7:15   ` Arınç ÜNAL via B4 Relay
2024-04-22  7:15 ` [PATCH net-next v2 05/15] net: dsa: mt7530: refactor MT7530_MFC and MT7531_CFC, add MT7531_QRY_FFP Arınç ÜNAL via B4 Relay
2024-04-22  7:15   ` Arınç ÜNAL
2024-04-22  7:15   ` Arınç ÜNAL via B4 Relay
2024-04-22  7:15 ` [PATCH net-next v2 06/15] net: dsa: mt7530: refactor MT7530_HWTRAP and MT7530_MHWTRAP Arınç ÜNAL via B4 Relay
2024-04-22  7:15   ` Arınç ÜNAL
2024-04-22  7:15   ` Arınç ÜNAL via B4 Relay
2024-04-22  7:15 ` [PATCH net-next v2 07/15] net: dsa: mt7530: move MT753X_MTRAP operations for MT7530 Arınç ÜNAL via B4 Relay
2024-04-22  7:15   ` Arınç ÜNAL
2024-04-22  7:15   ` Arınç ÜNAL via B4 Relay
2024-04-27  2:24   ` Daniel Golle
2024-04-27  2:24     ` Daniel Golle
2024-04-27 11:40     ` Arınç ÜNAL
2024-04-27 11:40       ` Arınç ÜNAL
2024-04-22  7:15 ` [PATCH net-next v2 08/15] net: dsa: mt7530: return mt7530_setup_mdio & mt7531_setup_common on error Arınç ÜNAL via B4 Relay
2024-04-22  7:15   ` Arınç ÜNAL
2024-04-22  7:15   ` Arınç ÜNAL via B4 Relay
2024-04-22  7:15 ` [PATCH net-next v2 09/15] net: dsa: mt7530: define MAC speed capabilities per switch model Arınç ÜNAL via B4 Relay
2024-04-22  7:15   ` Arınç ÜNAL
2024-04-22  7:15   ` Arınç ÜNAL via B4 Relay
2024-04-22  7:15 ` [PATCH net-next v2 10/15] net: dsa: mt7530: get rid of function sanity check Arınç ÜNAL via B4 Relay
2024-04-22  7:15   ` Arınç ÜNAL
2024-04-22  7:15   ` Arınç ÜNAL via B4 Relay
2024-04-22  7:15 ` [PATCH net-next v2 11/15] net: dsa: mt7530: refactor MT7530_PMEEECR_P() Arınç ÜNAL via B4 Relay
2024-04-22  7:15   ` Arınç ÜNAL
2024-04-22  7:15   ` Arınç ÜNAL via B4 Relay
2024-04-22  7:15 ` [PATCH net-next v2 12/15] net: dsa: mt7530: get rid of mac_port_validate member of mt753x_info Arınç ÜNAL via B4 Relay
2024-04-22  7:15   ` Arınç ÜNAL
2024-04-22  7:15   ` Arınç ÜNAL via B4 Relay
2024-04-22  7:15 ` [PATCH net-next v2 13/15] net: dsa: mt7530: use priv->ds->num_ports instead of MT7530_NUM_PORTS Arınç ÜNAL via B4 Relay
2024-04-22  7:15   ` Arınç ÜNAL
2024-04-22  7:15   ` Arınç ÜNAL via B4 Relay
2024-04-22  7:15 ` [PATCH net-next v2 14/15] net: dsa: mt7530: do not pass port variable to mt7531_rgmii_setup() Arınç ÜNAL via B4 Relay
2024-04-22  7:15   ` Arınç ÜNAL
2024-04-22  7:15   ` Arınç ÜNAL via B4 Relay
2024-04-22  7:15 ` [PATCH net-next v2 15/15] net: dsa: mt7530: explain exposing MDIO bus of MT7531AE better Arınç ÜNAL via B4 Relay
2024-04-22  7:15   ` Arınç ÜNAL
2024-04-22  7:15   ` Arınç ÜNAL via B4 Relay
2024-04-24 11:10 ` [PATCH net-next v2 00/15] MT7530 DSA Subdriver Improvements Act IV patchwork-bot+netdevbpf
2024-04-24 11:10   ` patchwork-bot+netdevbpf
2024-04-25 12:49 ` Daniel Golle
2024-04-25 12:49   ` Daniel Golle

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=20240422-for-netnext-mt7530-improvements-4-v2-1-a75157ba76ad@arinc9.com \
    --to=devnull+arinc.unal.arinc9.com@kernel.org \
    --cc=andrew@lunn.ch \
    --cc=angelogioacchino.delregno@collabora.com \
    --cc=arinc.unal@arinc9.com \
    --cc=bartel.eerdekens@constell8.be \
    --cc=daniel@makrotopia.org \
    --cc=davem@davemloft.net \
    --cc=dqfext@gmail.com \
    --cc=edumazet@google.com \
    --cc=erkin.bozoglu@xeront.com \
    --cc=f.fainelli@gmail.com \
    --cc=kuba@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=linux@armlinux.org.uk \
    --cc=matthias.bgg@gmail.com \
    --cc=mithat.guner@xeront.com \
    --cc=netdev@vger.kernel.org \
    --cc=olteanv@gmail.com \
    --cc=pabeni@redhat.com \
    --cc=sean.wang@mediatek.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.