* [PATCH net-next] net: phy: sfp: Add labels to hwmon sensors
From: Andrew Lunn @ 2019-08-24 23:04 UTC (permalink / raw)
To: David Miller
Cc: Russell King, Guenter Roeck, Chris Healy, netdev, Andrew Lunn
SFPs can report two different power values, the transmit power and the
receive power. Add labels to make it clear which is which. Also add
labels to the other sensors, VCC power supply, bias and module
temperature.
sensors(1) now shows:
sff2-isa-0000
Adapter: ISA adapter
VCC: +3.23 V
temperature: +33.4 C
TX_power: 276.00 uW
RX_power: 20.00 uW
bias: +0.01 A
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
---
drivers/net/phy/sfp.c | 73 ++++++++++++++++++++++++++++++++++++++++---
1 file changed, 68 insertions(+), 5 deletions(-)
diff --git a/drivers/net/phy/sfp.c b/drivers/net/phy/sfp.c
index e36c04c26866..272d5773573e 100644
--- a/drivers/net/phy/sfp.c
+++ b/drivers/net/phy/sfp.c
@@ -429,6 +429,7 @@ static umode_t sfp_hwmon_is_visible(const void *data,
return 0;
/* fall through */
case hwmon_temp_input:
+ case hwmon_temp_label:
return 0444;
default:
return 0;
@@ -447,6 +448,7 @@ static umode_t sfp_hwmon_is_visible(const void *data,
return 0;
/* fall through */
case hwmon_in_input:
+ case hwmon_in_label:
return 0444;
default:
return 0;
@@ -465,6 +467,7 @@ static umode_t sfp_hwmon_is_visible(const void *data,
return 0;
/* fall through */
case hwmon_curr_input:
+ case hwmon_curr_label:
return 0444;
default:
return 0;
@@ -492,6 +495,7 @@ static umode_t sfp_hwmon_is_visible(const void *data,
return 0;
/* fall through */
case hwmon_power_input:
+ case hwmon_power_label:
return 0444;
default:
return 0;
@@ -987,9 +991,63 @@ static int sfp_hwmon_read(struct device *dev, enum hwmon_sensor_types type,
}
}
+static const char *const sfp_hwmon_power_labels[] = {
+ "TX_power",
+ "RX_power",
+};
+
+static int sfp_hwmon_read_string(struct device *dev,
+ enum hwmon_sensor_types type,
+ u32 attr, int channel, const char **str)
+{
+ switch (type) {
+ case hwmon_curr:
+ switch (attr) {
+ case hwmon_curr_label:
+ *str = "bias";
+ return 0;
+ default:
+ return -EOPNOTSUPP;
+ }
+ break;
+ case hwmon_temp:
+ switch (attr) {
+ case hwmon_temp_label:
+ *str = "temperature";
+ return 0;
+ default:
+ return -EOPNOTSUPP;
+ }
+ break;
+ case hwmon_in:
+ switch (attr) {
+ case hwmon_in_label:
+ *str = "VCC";
+ return 0;
+ default:
+ return -EOPNOTSUPP;
+ }
+ break;
+ case hwmon_power:
+ switch (attr) {
+ case hwmon_power_label:
+ *str = sfp_hwmon_power_labels[channel];
+ return 0;
+ default:
+ return -EOPNOTSUPP;
+ }
+ break;
+ default:
+ return -EOPNOTSUPP;
+ }
+
+ return -EOPNOTSUPP;
+}
+
static const struct hwmon_ops sfp_hwmon_ops = {
.is_visible = sfp_hwmon_is_visible,
.read = sfp_hwmon_read,
+ .read_string = sfp_hwmon_read_string,
};
static u32 sfp_hwmon_chip_config[] = {
@@ -1007,7 +1065,8 @@ static u32 sfp_hwmon_temp_config[] = {
HWMON_T_MAX | HWMON_T_MIN |
HWMON_T_MAX_ALARM | HWMON_T_MIN_ALARM |
HWMON_T_CRIT | HWMON_T_LCRIT |
- HWMON_T_CRIT_ALARM | HWMON_T_LCRIT_ALARM,
+ HWMON_T_CRIT_ALARM | HWMON_T_LCRIT_ALARM |
+ HWMON_T_LABEL,
0,
};
@@ -1021,7 +1080,8 @@ static u32 sfp_hwmon_vcc_config[] = {
HWMON_I_MAX | HWMON_I_MIN |
HWMON_I_MAX_ALARM | HWMON_I_MIN_ALARM |
HWMON_I_CRIT | HWMON_I_LCRIT |
- HWMON_I_CRIT_ALARM | HWMON_I_LCRIT_ALARM,
+ HWMON_I_CRIT_ALARM | HWMON_I_LCRIT_ALARM |
+ HWMON_I_LABEL,
0,
};
@@ -1035,7 +1095,8 @@ static u32 sfp_hwmon_bias_config[] = {
HWMON_C_MAX | HWMON_C_MIN |
HWMON_C_MAX_ALARM | HWMON_C_MIN_ALARM |
HWMON_C_CRIT | HWMON_C_LCRIT |
- HWMON_C_CRIT_ALARM | HWMON_C_LCRIT_ALARM,
+ HWMON_C_CRIT_ALARM | HWMON_C_LCRIT_ALARM |
+ HWMON_C_LABEL,
0,
};
@@ -1050,13 +1111,15 @@ static u32 sfp_hwmon_power_config[] = {
HWMON_P_MAX | HWMON_P_MIN |
HWMON_P_MAX_ALARM | HWMON_P_MIN_ALARM |
HWMON_P_CRIT | HWMON_P_LCRIT |
- HWMON_P_CRIT_ALARM | HWMON_P_LCRIT_ALARM,
+ HWMON_P_CRIT_ALARM | HWMON_P_LCRIT_ALARM |
+ HWMON_P_LABEL,
/* Receive power */
HWMON_P_INPUT |
HWMON_P_MAX | HWMON_P_MIN |
HWMON_P_MAX_ALARM | HWMON_P_MIN_ALARM |
HWMON_P_CRIT | HWMON_P_LCRIT |
- HWMON_P_CRIT_ALARM | HWMON_P_LCRIT_ALARM,
+ HWMON_P_CRIT_ALARM | HWMON_P_LCRIT_ALARM |
+ HWMON_P_LABEL,
0,
};
--
2.23.0.rc1
^ permalink raw reply related
* Re: Regresion with dsa_port_disable
From: Vivien Didelot @ 2019-08-24 23:12 UTC (permalink / raw)
To: Andrew Lunn; +Cc: netdev
In-Reply-To: <20190824225306.GA15986@lunn.ch>
Hi Andrew,
On Sun, 25 Aug 2019 00:53:06 +0200, Andrew Lunn <andrew@lunn.ch> wrote:
> I just booted a ZII devel C and got a new warning splat.
>
> WARNING: CPU: 0 PID: 925 at kernel/irq/manage.c:1708 __free_irq+0xc8/0x2c4
> Trying to free already-free IRQ 0
> Modules linked in:
> CPU: 0 PID: 925 Comm: kworker/0:2 Not tainted 5.3.0-rc5-01151-g7ff758fcdf65 #231
> Hardware name: Freescale Vybrid VF5xx/VF6xx (Device Tree)
> Workqueue: events deferred_probe_work_func
> Backtrace:
> [<8010d9e4>] (dump_backtrace) from [<8010dd9c>] (show_stack+0x20/0x24)
> r7:8016edf8 r6:00000009 r5:00000000 r4:9ec67944
> [<8010dd7c>] (show_stack) from [<8083b03c>] (dump_stack+0x24/0x28)
> [<8083b018>] (dump_stack) from [<8011c108>] (__warn.part.3+0xcc/0xf8)
> [<8011c03c>] (__warn.part.3) from [<8011c1ac>] (warn_slowpath_fmt+0x78/0x94)
> r6:000006ac r5:80a8cbf0 r4:80d07088
> [<8011c138>] (warn_slowpath_fmt) from [<8016edf8>] (__free_irq+0xc8/0x2c4)
> r3:00000000 r2:80a8cca8
> r7:9f486668 r6:9ee25268 r5:9f486600 r4:9ee25268
> [<8016ed30>] (__free_irq) from [<8016f07c>] (free_irq+0x38/0x74)
> r10:9eeb3600 r9:9e412040 r8:00000009 r7:9ee26040 r6:9ee2404c r5:9ee242c8
> r4:9ee25268 r3:00000c00
> [<8016f044>] (free_irq) from [<805a244c>] (mv88e6390x_serdes_irq_free+0x68/0x98)
> r5:9ee242c8 r4:9ee24040
> [<805a23e4>] (mv88e6390x_serdes_irq_free) from [<8059bc94>] (mv88e6xxx_port_disable+0x58/0x98)
> r7:9ee26040 r6:00000009 r5:9ee2404c r4:9ee24040
> [<8059bc3c>] (mv88e6xxx_port_disable) from [<80806f70>] (dsa_port_disable+0x44/0x50)
> r7:9ee26040 r6:9ee26d74 r5:00000009 r4:9ee26040
> [<80806f2c>] (dsa_port_disable) from [<80805df0>] (dsa_register_switch+0x964/0xab8)
> r5:9efe194c r4:9ee26d38
> [<8080548c>] (dsa_register_switch) from [<8059b734>] (mv88e6xxx_probe+0x730/0x778)
> r10:80943e64 r9:9fbf77d0 r8:00000000 r7:80d07088 r6:9e410040 r5:00000000
> r4:9e40e800
> [<8059b004>] (mv88e6xxx_probe) from [<80582da8>] (mdio_probe+0x40/0x64)
> r10:00000012 r9:80d5eccc r8:00000000 r7:00000000 r6:8141f358 r5:9e40e800
> r4:80d5eccc
> [<80582d68>] (mdio_probe) from [<80518858>] (really_probe+0x100/0x2d8)
> r5:9e40e800 r4:8141f354
>
> The previous code was careful to balance mv88e6352_serdes_irq_setup()
> with mv88e6390x_serdes_irq_free(). I _think_ your change broke this
> balance, and we now try to free an interrupt which was never
> allocated.
What do you mean by "balance mv88e6352_serdes_irq_setup() with
mv88e6390x_serdes_irq_free()"?
Vivien
^ permalink raw reply
* Re: Regresion with dsa_port_disable
From: Andrew Lunn @ 2019-08-24 23:16 UTC (permalink / raw)
To: Vivien Didelot; +Cc: netdev
In-Reply-To: <20190824191220.GB1808@t480s.localdomain>
On Sat, Aug 24, 2019 at 07:12:20PM -0400, Vivien Didelot wrote:
> Hi Andrew,
>
> On Sun, 25 Aug 2019 00:53:06 +0200, Andrew Lunn <andrew@lunn.ch> wrote:
> > I just booted a ZII devel C and got a new warning splat.
> >
> > WARNING: CPU: 0 PID: 925 at kernel/irq/manage.c:1708 __free_irq+0xc8/0x2c4
> > Trying to free already-free IRQ 0
> > Modules linked in:
> > CPU: 0 PID: 925 Comm: kworker/0:2 Not tainted 5.3.0-rc5-01151-g7ff758fcdf65 #231
> > Hardware name: Freescale Vybrid VF5xx/VF6xx (Device Tree)
> > Workqueue: events deferred_probe_work_func
> > Backtrace:
> > [<8010d9e4>] (dump_backtrace) from [<8010dd9c>] (show_stack+0x20/0x24)
> > r7:8016edf8 r6:00000009 r5:00000000 r4:9ec67944
> > [<8010dd7c>] (show_stack) from [<8083b03c>] (dump_stack+0x24/0x28)
> > [<8083b018>] (dump_stack) from [<8011c108>] (__warn.part.3+0xcc/0xf8)
> > [<8011c03c>] (__warn.part.3) from [<8011c1ac>] (warn_slowpath_fmt+0x78/0x94)
> > r6:000006ac r5:80a8cbf0 r4:80d07088
> > [<8011c138>] (warn_slowpath_fmt) from [<8016edf8>] (__free_irq+0xc8/0x2c4)
> > r3:00000000 r2:80a8cca8
> > r7:9f486668 r6:9ee25268 r5:9f486600 r4:9ee25268
> > [<8016ed30>] (__free_irq) from [<8016f07c>] (free_irq+0x38/0x74)
> > r10:9eeb3600 r9:9e412040 r8:00000009 r7:9ee26040 r6:9ee2404c r5:9ee242c8
> > r4:9ee25268 r3:00000c00
> > [<8016f044>] (free_irq) from [<805a244c>] (mv88e6390x_serdes_irq_free+0x68/0x98)
> > r5:9ee242c8 r4:9ee24040
> > [<805a23e4>] (mv88e6390x_serdes_irq_free) from [<8059bc94>] (mv88e6xxx_port_disable+0x58/0x98)
> > r7:9ee26040 r6:00000009 r5:9ee2404c r4:9ee24040
> > [<8059bc3c>] (mv88e6xxx_port_disable) from [<80806f70>] (dsa_port_disable+0x44/0x50)
> > r7:9ee26040 r6:9ee26d74 r5:00000009 r4:9ee26040
> > [<80806f2c>] (dsa_port_disable) from [<80805df0>] (dsa_register_switch+0x964/0xab8)
> > r5:9efe194c r4:9ee26d38
> > [<8080548c>] (dsa_register_switch) from [<8059b734>] (mv88e6xxx_probe+0x730/0x778)
> > r10:80943e64 r9:9fbf77d0 r8:00000000 r7:80d07088 r6:9e410040 r5:00000000
> > r4:9e40e800
> > [<8059b004>] (mv88e6xxx_probe) from [<80582da8>] (mdio_probe+0x40/0x64)
> > r10:00000012 r9:80d5eccc r8:00000000 r7:00000000 r6:8141f358 r5:9e40e800
> > r4:80d5eccc
> > [<80582d68>] (mdio_probe) from [<80518858>] (really_probe+0x100/0x2d8)
> > r5:9e40e800 r4:8141f354
> >
> > The previous code was careful to balance mv88e6352_serdes_irq_setup()
> > with mv88e6390x_serdes_irq_free(). I _think_ your change broke this
> > balance, and we now try to free an interrupt which was never
> > allocated.
>
> What do you mean by "balance mv88e6352_serdes_irq_setup() with
> mv88e6390x_serdes_irq_free()"?
Hi Vivien
It never called mv88e6390x_serdes_irq_free() unless
mv88e6352_serdes_irq_setup() had been called first.
mv88e6390x_serdes_irq_free() makes the assumption there actually is an
interrupt to free. I suspect your changes now call
mv88e6390x_serdes_irq_free() unconditionally.
Andrew
^ permalink raw reply
* Re: [PATCH net-next] MAINTAINERS: Add phylink keyword to SFF/SFP/SFP+ MODULE SUPPORT
From: David Miller @ 2019-08-24 23:15 UTC (permalink / raw)
To: andrew; +Cc: rmk+kernel, netdev
In-Reply-To: <20190824223454.15932-1-andrew@lunn.ch>
From: Andrew Lunn <andrew@lunn.ch>
Date: Sun, 25 Aug 2019 00:34:54 +0200
> Russell king maintains phylink, as part of the SFP module support.
> However, much of the review work is about drivers swapping from phylib
> to phylink. Such changes don't make changes to the phylink core, and
> so the F: rules in MAINTAINERS don't match. Add a K:, keywork rule,
> which hopefully get_maintainers will match against for patches to MAC
> drivers swapping to phylink.
>
> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Applied to 'net', as I like to keep MAINTAINERS as uptodate as widely
as possible.
Thanks.
^ permalink raw reply
* Re: [PATCH net-next v2 3/3] net: dsa: mt7530: Add support for port 5
From: David Miller @ 2019-08-24 23:19 UTC (permalink / raw)
To: opensource
Cc: sean.wang, andrew, vivien.didelot, f.fainelli, matthias.bgg,
netdev, linux-arm-kernel, linux-mediatek, john, linux-mips,
frank-w
In-Reply-To: <20190821144547.15113-4-opensource@vdorst.com>
From: René van Dorst <opensource@vdorst.com>
Date: Wed, 21 Aug 2019 16:45:47 +0200
> + dev_info(ds->dev, "Setup P5, HWTRAP=0x%x, intf_sel=%s, phy-mode=%s\n",
> + val, p5_intf_modes(priv->p5_intf_sel), phy_modes(interface));
This is debugging, at best. Please make this a debugging message or
remove it entirely.
^ permalink raw reply
* Re: [PATCH net-next] net: hns3: Fix -Wunused-const-variable warning
From: David Miller @ 2019-08-24 23:24 UTC (permalink / raw)
To: yuehaibing
Cc: yisen.zhuang, salil.mehta, lipeng321, tanhuazhong, shenjian15,
linyunsheng, liuzhongzhu, huangguangbin2, liweihang, netdev,
linux-kernel
In-Reply-To: <20190822144937.75884-1-yuehaibing@huawei.com>
From: YueHaibing <yuehaibing@huawei.com>
Date: Thu, 22 Aug 2019 22:49:37 +0800
> drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.h:542:30:
> warning: meta_data_key_info defined but not used [-Wunused-const-variable=]
> drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.h:553:30:
> warning: tuple_key_info defined but not used [-Wunused-const-variable=]
>
> The two variable is only used in hclge_main.c,
> so just move the definition over there.
>
> Reported-by: Hulk Robot <hulkci@huawei.com>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Applied, thanks.
^ permalink raw reply
* Re: [pull request][net 0/4] Mellanox, mlx5 fixes 2019-08-22
From: David Miller @ 2019-08-24 23:27 UTC (permalink / raw)
To: saeedm; +Cc: netdev
In-Reply-To: <20190822204121.16954-1-saeedm@mellanox.com>
From: Saeed Mahameed <saeedm@mellanox.com>
Date: Thu, 22 Aug 2019 20:41:34 +0000
> This series introduces some fixes to mlx5 driver.
>
> 1) Form Moshe, two fixes for firmware health reporter
> 2) From Eran, two ktls fixes.
>
> Please pull and let me know if there is any problem.
>
> No -stable this time :) ..
:) Pulled, thanks!
^ permalink raw reply
* Re: [pull request][net-next 0/8] Mellanox, mlx5 updates 2019-08-22
From: David Miller @ 2019-08-24 23:31 UTC (permalink / raw)
To: saeedm; +Cc: netdev
In-Reply-To: <20190822233514.31252-1-saeedm@mellanox.com>
From: Saeed Mahameed <saeedm@mellanox.com>
Date: Thu, 22 Aug 2019 23:35:45 +0000
> This series provides some misc updates to mlx5 driver.
> For more information please see tag log below.
>
> Please pull and let me know if there is any problem.
>
> Please note that the series starts with a merge of mlx5-next branch,
> to resolve and avoid dependency with rdma tree.
I agree with Jakub that the new statistic can probably have a more
descriptive name.
Thanks.
^ permalink raw reply
* Re: [PATCH] [PATCH v3] sock: fix potential memory leak in proto_register()
From: David Miller @ 2019-08-24 23:33 UTC (permalink / raw)
To: zhang.lin16
Cc: ast, daniel, kafai, songliubraving, yhs, willemb, edumazet,
deepa.kernel, arnd, dh.herrmann, gnault, netdev, linux-kernel,
bpf, xue.zhihong, wang.yi59, jiang.xuexin
In-Reply-To: <1566522851-24018-1-git-send-email-zhang.lin16@zte.com.cn>
From: zhanglin <zhang.lin16@zte.com.cn>
Date: Fri, 23 Aug 2019 09:14:11 +0800
> If protocols registered exceeded PROTO_INUSE_NR, prot will be
> added to proto_list, but no available bit left for prot in
> proto_inuse_idx.
>
> Changes since v2:
> * Propagate the error code properly
>
> Signed-off-by: zhanglin <zhang.lin16@zte.com.cn>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] bnxt_en: Fix allocation of zero statistics block size regression.
From: David Miller @ 2019-08-24 23:35 UTC (permalink / raw)
To: michael.chan; +Cc: jonathan.lemon, netdev
In-Reply-To: <1566539501-5884-1-git-send-email-michael.chan@broadcom.com>
From: Michael Chan <michael.chan@broadcom.com>
Date: Fri, 23 Aug 2019 01:51:41 -0400
> Recent commit added logic to determine the appropriate statistics block
> size to allocate and the size is stored in bp->hw_ring_stats_size. But
> if the firmware spec is older than 1.6.0, it is 0 and not initialized.
> This causes the allocation to fail with size 0 and bnxt_open() to
> abort. Fix it by always initializing bp->hw_ring_stats_size to the
> legacy default size value.
>
> Fixes: 4e7485066373 ("bnxt_en: Allocate the larger per-ring statistics block for 57500 chips.")
> Reported-by: Jonathan Lemon <jonathan.lemon@gmail.com>
> Signed-off-by: Michael Chan <michael.chan@broadcom.com>
Applied.
^ permalink raw reply
* Re: [PATCH net] s390/qeth: reject oversized SNMP requests
From: David Miller @ 2019-08-24 23:35 UTC (permalink / raw)
To: jwi; +Cc: netdev, linux-s390, heiko.carstens, raspl, ubraun
In-Reply-To: <20190823092923.8507-1-jwi@linux.ibm.com>
From: Julian Wiedmann <jwi@linux.ibm.com>
Date: Fri, 23 Aug 2019 11:29:23 +0200
> Commit d4c08afafa04 ("s390/qeth: streamline SNMP cmd code") removed
> the bounds checking for req_len, under the assumption that the check in
> qeth_alloc_cmd() would suffice.
>
> But that code path isn't sufficiently robust to handle a user-provided
> data_length, which could overflow (when adding the cmd header overhead)
> before being checked against QETH_BUFSIZE. We end up allocating just a
> tiny iob, and the subsequent copy_from_user() writes past the end of
> that iob.
>
> Special-case this path and add a coarse bounds check, to protect against
> maliciuous requests. This let's the subsequent code flow do its normal
> job and precise checking, without risk of overflow.
>
> Fixes: d4c08afafa04 ("s390/qeth: streamline SNMP cmd code")
> Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
> Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com>
> Reviewed-by: Ursula Braun <ubraun@linux.ibm.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 0/7] s390/qeth: updates 2019-08-23
From: David Miller @ 2019-08-24 23:39 UTC (permalink / raw)
To: jwi; +Cc: netdev, linux-s390, heiko.carstens, raspl, ubraun
In-Reply-To: <20190823094853.63814-1-jwi@linux.ibm.com>
From: Julian Wiedmann <jwi@linux.ibm.com>
Date: Fri, 23 Aug 2019 11:48:46 +0200
> please apply one more round of qeth patches. These implement support for
> a bunch of TX-related features - namely TX NAPI, BQL and xmit_more.
>
> Note that this includes two qdio patches which lay the necessary
> groundwork, and have been acked by Vasily.
Series applied, thanks.
^ permalink raw reply
* Re: [net-next 00/14][pull request] 100GbE Intel Wired LAN Driver Updates 2019-08-23
From: David Miller @ 2019-08-24 23:47 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, nhorman, sassmann
In-Reply-To: <20190823233750.7997-1-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Fri, 23 Aug 2019 16:37:36 -0700
> This series contains updates to ice driver only.
Pulled, thanks Jeff.
^ permalink raw reply
* Re: [net-next 07/14] ice: Rename ethtool private flag for lldp
From: David Miller @ 2019-08-24 23:47 UTC (permalink / raw)
To: jakub.kicinski
Cc: jeffrey.t.kirsher, david.m.ertman, netdev, nhorman, sassmann,
andrewx.bowers
In-Reply-To: <20190823183111.509e176c@cakuba.netronome.com>
From: Jakub Kicinski <jakub.kicinski@netronome.com>
Date: Fri, 23 Aug 2019 18:31:11 -0700
> On Fri, 23 Aug 2019 16:37:43 -0700, Jeff Kirsher wrote:
>> From: Dave Ertman <david.m.ertman@intel.com>
>>
>> The current flag name of "enable-fw-lldp" is a bit cumbersome.
>>
>> Change priv-flag name to "fw-lldp-agent" with a value of on or
>> off. This is more straight-forward in meaning.
>>
>> Signed-off-by: Dave Ertman <david.m.ertman@intel.com>
>> Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
>> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
>
> Just flagging this for Dave, it was introduced in v5.2 by:
So should we backport the rename into 'net'? Is this a bug fix or just
making life easier for people?
^ permalink raw reply
* Re: [net PATCH] net: route dump netlink NLM_F_MULTI flag missing
From: David Miller @ 2019-08-24 23:50 UTC (permalink / raw)
To: john.fastabend; +Cc: sbrivio, dsahern, netdev
In-Reply-To: <156660549861.5753.7912871726096518275.stgit@john-XPS-13-9370>
From: John Fastabend <john.fastabend@gmail.com>
Date: Fri, 23 Aug 2019 17:11:38 -0700
> An excerpt from netlink(7) man page,
>
> In multipart messages (multiple nlmsghdr headers with associated payload
> in one byte stream) the first and all following headers have the
> NLM_F_MULTI flag set, except for the last header which has the type
> NLMSG_DONE.
>
> but, after (ee28906) there is a missing NLM_F_MULTI flag in the middle of a
> FIB dump. The result is user space applications following above man page
> excerpt may get confused and may stop parsing msg believing something went
> wrong.
>
> In the golang netlink lib [0] the library logic stops parsing believing the
> message is not a multipart message. Found this running Cilium[1] against
> net-next while adding a feature to auto-detect routes. I noticed with
> multiple route tables we no longer could detect the default routes on net
> tree kernels because the library logic was not returning them.
>
> Fix this by handling the fib_dump_info_fnhe() case the same way the
> fib_dump_info() handles it by passing the flags argument through the
> call chain and adding a flags argument to rt_fill_info().
>
> Tested with Cilium stack and auto-detection of routes works again. Also
> annotated libs to dump netlink msgs and inspected NLM_F_MULTI and
> NLMSG_DONE flags look correct after this.
>
> Note: In inet_rtm_getroute() pass rt_fill_info() '0' for flags the same
> as is done for fib_dump_info() so this looks correct to me.
>
> [0] https://github.com/vishvananda/netlink/
> [1] https://github.com/cilium/
>
> Fixes: ee28906fd7a14 ("ipv4: Dump route exceptions if requested")
> Signed-off-by: John Fastabend <john.fastabend@gmail.com>
Applied, thanks John.
^ permalink raw reply
* Re: [PATCHv2 1/1] net: rds: add service level support in rds-info
From: David Miller @ 2019-08-24 23:58 UTC (permalink / raw)
To: yanjun.zhu; +Cc: santosh.shilimkar, netdev, linux-rdma, rds-devel, gerd.rausch
In-Reply-To: <1566608656-30836-1-git-send-email-yanjun.zhu@oracle.com>
From: Zhu Yanjun <yanjun.zhu@oracle.com>
Date: Fri, 23 Aug 2019 21:04:16 -0400
> diff --git a/include/uapi/linux/rds.h b/include/uapi/linux/rds.h
> index fd6b5f6..cba368e 100644
> --- a/include/uapi/linux/rds.h
> +++ b/include/uapi/linux/rds.h
> @@ -250,6 +250,7 @@ struct rds_info_rdma_connection {
> __u32 rdma_mr_max;
> __u32 rdma_mr_size;
> __u8 tos;
> + __u8 sl;
> __u32 cache_allocs;
> };
I'm applying this, but I am once again severely disappointed in how
RDS development is being handled.
From the Fixes: commit:
Since rds.h in rds-tools is not related with the kernel rds.h,
the change in kernel rds.h does not affect rds-tools.
This is the height of arrogance and shows a lack of understanding of
what user ABI requirements are all about.
It is possible for other userland components to be built by other
people, outside of your controlled eco-system and tools, that use
these interfaces.
And you cannot control that.
Therefore you cannot make arbitrary changes to UABI data strucures
just because the tool you use and maintain is not effected by it.
Please stop making these incredibly incompatible user interface
changes in the RDS stack.
I am, from this point forward, going to be extra strict on RDS stack
changes especially in this area.
^ permalink raw reply
* Re: [PATCH] r8152: Set memory to all 0xFFs on failed reg reads
From: David Miller @ 2019-08-25 0:00 UTC (permalink / raw)
To: pmalani; +Cc: hayeswang, grundler, netdev
In-Reply-To: <20190824083619.69139-1-pmalani@chromium.org>
From: Prashant Malani <pmalani@chromium.org>
Date: Sat, 24 Aug 2019 01:36:19 -0700
> get_registers() blindly copies the memory written to by the
> usb_control_msg() call even if the underlying urb failed.
>
> This could lead to junk register values being read by the driver, since
> some indirect callers of get_registers() ignore the return values. One
> example is:
> ocp_read_dword() ignores the return value of generic_ocp_read(), which
> calls get_registers().
>
> So, emulate PCI "Master Abort" behavior by setting the buffer to all
> 0xFFs when usb_control_msg() fails.
>
> This patch is copied from the r8152 driver (v2.12.0) published by
> Realtek (www.realtek.com).
>
> Signed-off-by: Prashant Malani <pmalani@chromium.org>
Hayes, please review.
^ permalink raw reply
* Re: [PATCH net-next] net: phy: sfp: Add labels to hwmon sensors
From: David Miller @ 2019-08-25 0:02 UTC (permalink / raw)
To: andrew; +Cc: rmk+kernel, linux, Chris.Healy, netdev
In-Reply-To: <20190824230417.17657-1-andrew@lunn.ch>
From: Andrew Lunn <andrew@lunn.ch>
Date: Sun, 25 Aug 2019 01:04:17 +0200
> SFPs can report two different power values, the transmit power and the
> receive power. Add labels to make it clear which is which. Also add
> labels to the other sensors, VCC power supply, bias and module
> temperature.
>
> sensors(1) now shows:
>
> sff2-isa-0000
> Adapter: ISA adapter
> VCC: +3.23 V
> temperature: +33.4 C
> TX_power: 276.00 uW
> RX_power: 20.00 uW
> bias: +0.01 A
>
> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Applied, thanks Andrew.
^ permalink raw reply
* Re: [net-next 07/14] ice: Rename ethtool private flag for lldp
From: Kirsher, Jeffrey T @ 2019-08-25 0:04 UTC (permalink / raw)
To: David Miller
Cc: jakub.kicinski@netronome.com, Ertman, David M,
netdev@vger.kernel.org, nhorman@redhat.com, sassmann@redhat.com,
Bowers, AndrewX
In-Reply-To: <20190824.164726.357731088137490877.davem@davemloft.net>
> On Aug 24, 2019, at 16:47, David Miller <davem@davemloft.net> wrote:
>
> From: Jakub Kicinski <jakub.kicinski@netronome.com>
> Date: Fri, 23 Aug 2019 18:31:11 -0700
>
>>> On Fri, 23 Aug 2019 16:37:43 -0700, Jeff Kirsher wrote:
>>> From: Dave Ertman <david.m.ertman@intel.com>
>>>
>>> The current flag name of "enable-fw-lldp" is a bit cumbersome.
>>>
>>> Change priv-flag name to "fw-lldp-agent" with a value of on or
>>> off. This is more straight-forward in meaning.
>>>
>>> Signed-off-by: Dave Ertman <david.m.ertman@intel.com>
>>> Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
>>> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
>>
>> Just flagging this for Dave, it was introduced in v5.2 by:
>
> So should we backport the rename into 'net'? Is this a bug fix or just
> making life easier for people?
IMHO, no need to backport.
^ permalink raw reply
* Re: Regresion with dsa_port_disable
From: Vivien Didelot @ 2019-08-25 0:53 UTC (permalink / raw)
To: Andrew Lunn; +Cc: netdev
In-Reply-To: <20190824231653.GA17726@lunn.ch>
Hi Andrew,
On Sun, 25 Aug 2019 01:16:53 +0200, Andrew Lunn <andrew@lunn.ch> wrote:
> On Sat, Aug 24, 2019 at 07:12:20PM -0400, Vivien Didelot wrote:
> > Hi Andrew,
> >
> > On Sun, 25 Aug 2019 00:53:06 +0200, Andrew Lunn <andrew@lunn.ch> wrote:
> > > I just booted a ZII devel C and got a new warning splat.
> > >
> > > WARNING: CPU: 0 PID: 925 at kernel/irq/manage.c:1708 __free_irq+0xc8/0x2c4
> > > Trying to free already-free IRQ 0
> > > Modules linked in:
> > > CPU: 0 PID: 925 Comm: kworker/0:2 Not tainted 5.3.0-rc5-01151-g7ff758fcdf65 #231
> > > Hardware name: Freescale Vybrid VF5xx/VF6xx (Device Tree)
> > > Workqueue: events deferred_probe_work_func
> > > Backtrace:
> > > [<8010d9e4>] (dump_backtrace) from [<8010dd9c>] (show_stack+0x20/0x24)
> > > r7:8016edf8 r6:00000009 r5:00000000 r4:9ec67944
> > > [<8010dd7c>] (show_stack) from [<8083b03c>] (dump_stack+0x24/0x28)
> > > [<8083b018>] (dump_stack) from [<8011c108>] (__warn.part.3+0xcc/0xf8)
> > > [<8011c03c>] (__warn.part.3) from [<8011c1ac>] (warn_slowpath_fmt+0x78/0x94)
> > > r6:000006ac r5:80a8cbf0 r4:80d07088
> > > [<8011c138>] (warn_slowpath_fmt) from [<8016edf8>] (__free_irq+0xc8/0x2c4)
> > > r3:00000000 r2:80a8cca8
> > > r7:9f486668 r6:9ee25268 r5:9f486600 r4:9ee25268
> > > [<8016ed30>] (__free_irq) from [<8016f07c>] (free_irq+0x38/0x74)
> > > r10:9eeb3600 r9:9e412040 r8:00000009 r7:9ee26040 r6:9ee2404c r5:9ee242c8
> > > r4:9ee25268 r3:00000c00
> > > [<8016f044>] (free_irq) from [<805a244c>] (mv88e6390x_serdes_irq_free+0x68/0x98)
> > > r5:9ee242c8 r4:9ee24040
> > > [<805a23e4>] (mv88e6390x_serdes_irq_free) from [<8059bc94>] (mv88e6xxx_port_disable+0x58/0x98)
> > > r7:9ee26040 r6:00000009 r5:9ee2404c r4:9ee24040
> > > [<8059bc3c>] (mv88e6xxx_port_disable) from [<80806f70>] (dsa_port_disable+0x44/0x50)
> > > r7:9ee26040 r6:9ee26d74 r5:00000009 r4:9ee26040
> > > [<80806f2c>] (dsa_port_disable) from [<80805df0>] (dsa_register_switch+0x964/0xab8)
> > > r5:9efe194c r4:9ee26d38
> > > [<8080548c>] (dsa_register_switch) from [<8059b734>] (mv88e6xxx_probe+0x730/0x778)
> > > r10:80943e64 r9:9fbf77d0 r8:00000000 r7:80d07088 r6:9e410040 r5:00000000
> > > r4:9e40e800
> > > [<8059b004>] (mv88e6xxx_probe) from [<80582da8>] (mdio_probe+0x40/0x64)
> > > r10:00000012 r9:80d5eccc r8:00000000 r7:00000000 r6:8141f358 r5:9e40e800
> > > r4:80d5eccc
> > > [<80582d68>] (mdio_probe) from [<80518858>] (really_probe+0x100/0x2d8)
> > > r5:9e40e800 r4:8141f354
> > >
> > > The previous code was careful to balance mv88e6352_serdes_irq_setup()
> > > with mv88e6390x_serdes_irq_free(). I _think_ your change broke this
> > > balance, and we now try to free an interrupt which was never
> > > allocated.
> >
> > What do you mean by "balance mv88e6352_serdes_irq_setup() with
> > mv88e6390x_serdes_irq_free()"?
>
> Hi Vivien
>
> It never called mv88e6390x_serdes_irq_free() unless
> mv88e6352_serdes_irq_setup() had been called first.
> mv88e6390x_serdes_irq_free() makes the assumption there actually is an
> interrupt to free. I suspect your changes now call
> mv88e6390x_serdes_irq_free() unconditionally.
OK I think you meant info->ops->serdes_irq_free and
info->ops->serdes_irq_setup, otherwise it's confusing.
I think I know what's going on, I'll look into it soon.
Thanks!
^ permalink raw reply
* [PATCH net-next v3 1/6] net: dsa: mv88e6xxx: support 2500base-x in SGMII IRQ handler
From: Marek Behún @ 2019-08-25 3:59 UTC (permalink / raw)
To: netdev
Cc: Andrew Lunn, Vivien Didelot, Florian Fainelli, Vladimir Oltean,
Marek Behún
In-Reply-To: <20190825035915.13112-1-marek.behun@nic.cz>
The mv88e6390_serdes_irq_link_sgmii IRQ handler reads the SERDES PHY
status register to determine speed, among other things. If cmode of the
port is set to 2500base-x, though, the PHY still reports 1000 Mbps (the
PHY register itself does not differentiate between 1000 Mbps and 2500
Mbps - it thinks it is running at 1000 Mbps, although clock is 2.5x
faster).
Look at the cmode and set SPEED_2500 if cmode is set to 2500base-x.
Also tell mv88e6xxx_port_setup_mac the PHY interface mode corresponding
to current cmode in terms of phy_interface_t.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Florian Fainelli <f.fainelli@gmail.com>
Cc: Vladimir Oltean <olteanv@gmail.com>
Cc: Vivien Didelot <vivien.didelot@gmail.com>
---
drivers/net/dsa/mv88e6xxx/serdes.c | 23 +++++++++++++++++++++--
1 file changed, 21 insertions(+), 2 deletions(-)
diff --git a/drivers/net/dsa/mv88e6xxx/serdes.c b/drivers/net/dsa/mv88e6xxx/serdes.c
index 20c526c2a9ee..678aaba3d019 100644
--- a/drivers/net/dsa/mv88e6xxx/serdes.c
+++ b/drivers/net/dsa/mv88e6xxx/serdes.c
@@ -505,9 +505,11 @@ int mv88e6390x_serdes_power(struct mv88e6xxx_chip *chip, int port, bool on)
static void mv88e6390_serdes_irq_link_sgmii(struct mv88e6xxx_chip *chip,
int port, int lane)
{
+ u8 cmode = chip->ports[port].cmode;
struct dsa_switch *ds = chip->ds;
int duplex = DUPLEX_UNKNOWN;
int speed = SPEED_UNKNOWN;
+ phy_interface_t mode;
int link, err;
u16 status;
@@ -527,7 +529,10 @@ static void mv88e6390_serdes_irq_link_sgmii(struct mv88e6xxx_chip *chip,
switch (status & MV88E6390_SGMII_PHY_STATUS_SPEED_MASK) {
case MV88E6390_SGMII_PHY_STATUS_SPEED_1000:
- speed = SPEED_1000;
+ if (cmode == MV88E6XXX_PORT_STS_CMODE_2500BASEX)
+ speed = SPEED_2500;
+ else
+ speed = SPEED_1000;
break;
case MV88E6390_SGMII_PHY_STATUS_SPEED_100:
speed = SPEED_100;
@@ -541,8 +546,22 @@ static void mv88e6390_serdes_irq_link_sgmii(struct mv88e6xxx_chip *chip,
}
}
+ switch (cmode) {
+ case MV88E6XXX_PORT_STS_CMODE_SGMII:
+ mode = PHY_INTERFACE_MODE_SGMII;
+ break;
+ case MV88E6XXX_PORT_STS_CMODE_1000BASE_X:
+ mode = PHY_INTERFACE_MODE_1000BASEX;
+ break;
+ case MV88E6XXX_PORT_STS_CMODE_2500BASEX:
+ mode = PHY_INTERFACE_MODE_2500BASEX;
+ break;
+ default:
+ mode = PHY_INTERFACE_MODE_NA;
+ }
+
err = mv88e6xxx_port_setup_mac(chip, port, link, speed, duplex,
- PAUSE_OFF, PHY_INTERFACE_MODE_NA);
+ PAUSE_OFF, mode);
if (err)
dev_err(chip->dev, "can't propagate PHY settings to MAC: %d\n",
err);
--
2.21.0
^ permalink raw reply related
* [PATCH net-next v3 0/6] net: dsa: mv88e6xxx: Peridot/Topaz SERDES changes
From: Marek Behún @ 2019-08-25 3:59 UTC (permalink / raw)
To: netdev
Cc: Andrew Lunn, Vivien Didelot, Florian Fainelli, Vladimir Oltean,
Marek Behún
Hello,
this is the third version of changes for the Topaz/Peridot family of
switches. The patches apply on net-next.
Changes since v2:
- per Vivien's request I merged the three different patches operating
on code for hidden registers into one patch (second in this series)
- also per Vivien's request I changed the serdes_get_lane method: its
return value is now used only if error's occur, as the rest of this
drivers functions do. Lane number is put into a place pointed to
by the s8 *lane argument. The error semantics also changed: if there
is no lane on a port, the function should still return 0 and should
put -1 into *lane. Negative error value should be returned only if
a real error occurs, for example when a MDIO read operation failed.
- also per Vivien's request the mv88e6xxx_serdes_get_lane function was
put into serdes.h as static inline, since it is just a wrapper
- the patch that simplified SERDES code for Topaz and Peridot families
was merged into one patch
Marek
Marek Behún (6):
net: dsa: mv88e6xxx: support 2500base-x in SGMII IRQ handler
net: dsa: mv88e6xxx: update code operating on hidden registers
net: dsa: mv88e6xxx: create serdes_get_lane chip operation
net: dsa: mv88e6xxx: simplify SERDES code for Topaz and Peridot
net: dsa: mv88e6xxx: rename port cmode macro
net: dsa: mv88e6xxx: fully support SERDES on Topaz family
drivers/net/dsa/mv88e6xxx/Makefile | 1 +
drivers/net/dsa/mv88e6xxx/chip.c | 88 +++-----
drivers/net/dsa/mv88e6xxx/chip.h | 3 +
drivers/net/dsa/mv88e6xxx/port.c | 98 ++++++---
drivers/net/dsa/mv88e6xxx/port.h | 30 ++-
drivers/net/dsa/mv88e6xxx/port_hidden.c | 70 ++++++
drivers/net/dsa/mv88e6xxx/serdes.c | 275 +++++++++++-------------
drivers/net/dsa/mv88e6xxx/serdes.h | 27 ++-
8 files changed, 333 insertions(+), 259 deletions(-)
create mode 100644 drivers/net/dsa/mv88e6xxx/port_hidden.c
--
2.21.0
^ permalink raw reply
* [PATCH net-next v3 5/6] net: dsa: mv88e6xxx: rename port cmode macro
From: Marek Behún @ 2019-08-25 3:59 UTC (permalink / raw)
To: netdev
Cc: Andrew Lunn, Vivien Didelot, Florian Fainelli, Vladimir Oltean,
Marek Behún
In-Reply-To: <20190825035915.13112-1-marek.behun@nic.cz>
This is a cosmetic update. We are removing the last underscore from
macros MV88E6XXX_PORT_STS_CMODE_100BASE_X and
MV88E6XXX_PORT_STS_CMODE_1000BASE_X. The 2500base-x version does not
have that underscore. Also PHY_INTERFACE_MODE_ macros do not have it
there.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
---
drivers/net/dsa/mv88e6xxx/port.c | 4 +--
drivers/net/dsa/mv88e6xxx/port.h | 4 +--
drivers/net/dsa/mv88e6xxx/serdes.c | 48 +++++++++++++++---------------
3 files changed, 28 insertions(+), 28 deletions(-)
diff --git a/drivers/net/dsa/mv88e6xxx/port.c b/drivers/net/dsa/mv88e6xxx/port.c
index d20be5327640..7183c94a92ec 100644
--- a/drivers/net/dsa/mv88e6xxx/port.c
+++ b/drivers/net/dsa/mv88e6xxx/port.c
@@ -411,7 +411,7 @@ int mv88e6390x_port_set_cmode(struct mv88e6xxx_chip *chip, int port,
switch (mode) {
case PHY_INTERFACE_MODE_1000BASEX:
- cmode = MV88E6XXX_PORT_STS_CMODE_1000BASE_X;
+ cmode = MV88E6XXX_PORT_STS_CMODE_1000BASEX;
break;
case PHY_INTERFACE_MODE_SGMII:
cmode = MV88E6XXX_PORT_STS_CMODE_SGMII;
@@ -618,7 +618,7 @@ int mv88e6352_port_link_state(struct mv88e6xxx_chip *chip, int port,
else
state->interface = PHY_INTERFACE_MODE_RGMII;
break;
- case MV88E6XXX_PORT_STS_CMODE_1000BASE_X:
+ case MV88E6XXX_PORT_STS_CMODE_1000BASEX:
state->interface = PHY_INTERFACE_MODE_1000BASEX;
break;
case MV88E6XXX_PORT_STS_CMODE_SGMII:
diff --git a/drivers/net/dsa/mv88e6xxx/port.h b/drivers/net/dsa/mv88e6xxx/port.h
index 64c73fd171ee..04550cb3c3b3 100644
--- a/drivers/net/dsa/mv88e6xxx/port.h
+++ b/drivers/net/dsa/mv88e6xxx/port.h
@@ -43,8 +43,8 @@
#define MV88E6XXX_PORT_STS_FLOW_CTL 0x0010
#define MV88E6XXX_PORT_STS_CMODE_MASK 0x000f
#define MV88E6XXX_PORT_STS_CMODE_RGMII 0x0007
-#define MV88E6XXX_PORT_STS_CMODE_100BASE_X 0x0008
-#define MV88E6XXX_PORT_STS_CMODE_1000BASE_X 0x0009
+#define MV88E6XXX_PORT_STS_CMODE_100BASEX 0x0008
+#define MV88E6XXX_PORT_STS_CMODE_1000BASEX 0x0009
#define MV88E6XXX_PORT_STS_CMODE_SGMII 0x000a
#define MV88E6XXX_PORT_STS_CMODE_2500BASEX 0x000b
#define MV88E6XXX_PORT_STS_CMODE_XAUI 0x000c
diff --git a/drivers/net/dsa/mv88e6xxx/serdes.c b/drivers/net/dsa/mv88e6xxx/serdes.c
index 1946ccb6694c..5bb3aea8a008 100644
--- a/drivers/net/dsa/mv88e6xxx/serdes.c
+++ b/drivers/net/dsa/mv88e6xxx/serdes.c
@@ -73,8 +73,8 @@ static bool mv88e6352_port_has_serdes(struct mv88e6xxx_chip *chip, int port)
{
u8 cmode = chip->ports[port].cmode;
- if ((cmode == MV88E6XXX_PORT_STS_CMODE_100BASE_X) ||
- (cmode == MV88E6XXX_PORT_STS_CMODE_1000BASE_X) ||
+ if ((cmode == MV88E6XXX_PORT_STS_CMODE_100BASEX) ||
+ (cmode == MV88E6XXX_PORT_STS_CMODE_1000BASEX) ||
(cmode == MV88E6XXX_PORT_STS_CMODE_SGMII))
return true;
@@ -295,7 +295,7 @@ int mv88e6341_serdes_get_lane(struct mv88e6xxx_chip *chip, int port, s8 *lane)
if (port != 5)
return 0;
- if (cmode == MV88E6XXX_PORT_STS_CMODE_1000BASE_X ||
+ if (cmode == MV88E6XXX_PORT_STS_CMODE_1000BASEX ||
cmode == MV88E6XXX_PORT_STS_CMODE_SGMII ||
cmode == MV88E6XXX_PORT_STS_CMODE_2500BASEX)
*lane = MV88E6341_PORT5_LANE;
@@ -311,13 +311,13 @@ int mv88e6390_serdes_get_lane(struct mv88e6xxx_chip *chip, int port, s8 *lane)
switch (port) {
case 9:
- if (cmode == MV88E6XXX_PORT_STS_CMODE_1000BASE_X ||
+ if (cmode == MV88E6XXX_PORT_STS_CMODE_1000BASEX ||
cmode == MV88E6XXX_PORT_STS_CMODE_SGMII ||
cmode == MV88E6XXX_PORT_STS_CMODE_2500BASEX)
*lane = MV88E6390_PORT9_LANE0;
break;
case 10:
- if (cmode == MV88E6XXX_PORT_STS_CMODE_1000BASE_X ||
+ if (cmode == MV88E6XXX_PORT_STS_CMODE_1000BASEX ||
cmode == MV88E6XXX_PORT_STS_CMODE_SGMII ||
cmode == MV88E6XXX_PORT_STS_CMODE_2500BASEX)
*lane = MV88E6390_PORT10_LANE0;
@@ -341,53 +341,53 @@ int mv88e6390x_serdes_get_lane(struct mv88e6xxx_chip *chip, int port, s8 *lane)
switch (port) {
case 2:
- if (cmode_port9 == MV88E6XXX_PORT_STS_CMODE_1000BASE_X ||
+ if (cmode_port9 == MV88E6XXX_PORT_STS_CMODE_1000BASEX ||
cmode_port9 == MV88E6XXX_PORT_STS_CMODE_SGMII ||
cmode_port9 == MV88E6XXX_PORT_STS_CMODE_2500BASEX)
- if (cmode_port == MV88E6XXX_PORT_STS_CMODE_1000BASE_X)
+ if (cmode_port == MV88E6XXX_PORT_STS_CMODE_1000BASEX)
*lane = MV88E6390_PORT9_LANE1;
break;
case 3:
- if (cmode_port9 == MV88E6XXX_PORT_STS_CMODE_1000BASE_X ||
+ if (cmode_port9 == MV88E6XXX_PORT_STS_CMODE_1000BASEX ||
cmode_port9 == MV88E6XXX_PORT_STS_CMODE_SGMII ||
cmode_port9 == MV88E6XXX_PORT_STS_CMODE_2500BASEX ||
cmode_port9 == MV88E6XXX_PORT_STS_CMODE_RXAUI)
- if (cmode_port == MV88E6XXX_PORT_STS_CMODE_1000BASE_X)
+ if (cmode_port == MV88E6XXX_PORT_STS_CMODE_1000BASEX)
*lane = MV88E6390_PORT9_LANE2;
break;
case 4:
- if (cmode_port9 == MV88E6XXX_PORT_STS_CMODE_1000BASE_X ||
+ if (cmode_port9 == MV88E6XXX_PORT_STS_CMODE_1000BASEX ||
cmode_port9 == MV88E6XXX_PORT_STS_CMODE_SGMII ||
cmode_port9 == MV88E6XXX_PORT_STS_CMODE_2500BASEX ||
cmode_port9 == MV88E6XXX_PORT_STS_CMODE_RXAUI)
- if (cmode_port == MV88E6XXX_PORT_STS_CMODE_1000BASE_X)
+ if (cmode_port == MV88E6XXX_PORT_STS_CMODE_1000BASEX)
*lane = MV88E6390_PORT9_LANE3;
break;
case 5:
- if (cmode_port10 == MV88E6XXX_PORT_STS_CMODE_1000BASE_X ||
+ if (cmode_port10 == MV88E6XXX_PORT_STS_CMODE_1000BASEX ||
cmode_port10 == MV88E6XXX_PORT_STS_CMODE_SGMII ||
cmode_port10 == MV88E6XXX_PORT_STS_CMODE_2500BASEX)
- if (cmode_port == MV88E6XXX_PORT_STS_CMODE_1000BASE_X)
+ if (cmode_port == MV88E6XXX_PORT_STS_CMODE_1000BASEX)
*lane = MV88E6390_PORT10_LANE1;
break;
case 6:
- if (cmode_port10 == MV88E6XXX_PORT_STS_CMODE_1000BASE_X ||
+ if (cmode_port10 == MV88E6XXX_PORT_STS_CMODE_1000BASEX ||
cmode_port10 == MV88E6XXX_PORT_STS_CMODE_SGMII ||
cmode_port10 == MV88E6XXX_PORT_STS_CMODE_2500BASEX ||
cmode_port10 == MV88E6XXX_PORT_STS_CMODE_RXAUI)
- if (cmode_port == MV88E6XXX_PORT_STS_CMODE_1000BASE_X)
+ if (cmode_port == MV88E6XXX_PORT_STS_CMODE_1000BASEX)
*lane = MV88E6390_PORT10_LANE2;
break;
case 7:
- if (cmode_port10 == MV88E6XXX_PORT_STS_CMODE_1000BASE_X ||
+ if (cmode_port10 == MV88E6XXX_PORT_STS_CMODE_1000BASEX ||
cmode_port10 == MV88E6XXX_PORT_STS_CMODE_SGMII ||
cmode_port10 == MV88E6XXX_PORT_STS_CMODE_2500BASEX ||
cmode_port10 == MV88E6XXX_PORT_STS_CMODE_RXAUI)
- if (cmode_port == MV88E6XXX_PORT_STS_CMODE_1000BASE_X)
+ if (cmode_port == MV88E6XXX_PORT_STS_CMODE_1000BASEX)
*lane = MV88E6390_PORT10_LANE3;
break;
case 9:
- if (cmode_port9 == MV88E6XXX_PORT_STS_CMODE_1000BASE_X ||
+ if (cmode_port9 == MV88E6XXX_PORT_STS_CMODE_1000BASEX ||
cmode_port9 == MV88E6XXX_PORT_STS_CMODE_SGMII ||
cmode_port9 == MV88E6XXX_PORT_STS_CMODE_2500BASEX ||
cmode_port9 == MV88E6XXX_PORT_STS_CMODE_XAUI ||
@@ -395,7 +395,7 @@ int mv88e6390x_serdes_get_lane(struct mv88e6xxx_chip *chip, int port, s8 *lane)
*lane = MV88E6390_PORT9_LANE0;
break;
case 10:
- if (cmode_port10 == MV88E6XXX_PORT_STS_CMODE_1000BASE_X ||
+ if (cmode_port10 == MV88E6XXX_PORT_STS_CMODE_1000BASEX ||
cmode_port10 == MV88E6XXX_PORT_STS_CMODE_SGMII ||
cmode_port10 == MV88E6XXX_PORT_STS_CMODE_2500BASEX ||
cmode_port10 == MV88E6XXX_PORT_STS_CMODE_XAUI ||
@@ -476,7 +476,7 @@ int mv88e6390_serdes_power(struct mv88e6xxx_chip *chip, int port, bool on)
switch (cmode) {
case MV88E6XXX_PORT_STS_CMODE_SGMII:
- case MV88E6XXX_PORT_STS_CMODE_1000BASE_X:
+ case MV88E6XXX_PORT_STS_CMODE_1000BASEX:
case MV88E6XXX_PORT_STS_CMODE_2500BASEX:
return mv88e6390_serdes_power_sgmii(chip, lane, on);
case MV88E6XXX_PORT_STS_CMODE_XAUI:
@@ -535,7 +535,7 @@ static void mv88e6390_serdes_irq_link_sgmii(struct mv88e6xxx_chip *chip,
case MV88E6XXX_PORT_STS_CMODE_SGMII:
mode = PHY_INTERFACE_MODE_SGMII;
break;
- case MV88E6XXX_PORT_STS_CMODE_1000BASE_X:
+ case MV88E6XXX_PORT_STS_CMODE_1000BASEX:
mode = PHY_INTERFACE_MODE_1000BASEX;
break;
case MV88E6XXX_PORT_STS_CMODE_2500BASEX:
@@ -578,7 +578,7 @@ int mv88e6390_serdes_irq_enable(struct mv88e6xxx_chip *chip, int port,
switch (cmode) {
case MV88E6XXX_PORT_STS_CMODE_SGMII:
- case MV88E6XXX_PORT_STS_CMODE_1000BASE_X:
+ case MV88E6XXX_PORT_STS_CMODE_1000BASEX:
case MV88E6XXX_PORT_STS_CMODE_2500BASEX:
err = mv88e6390_serdes_irq_enable_sgmii(chip, lane);
}
@@ -594,7 +594,7 @@ int mv88e6390_serdes_irq_disable(struct mv88e6xxx_chip *chip, int port,
switch (cmode) {
case MV88E6XXX_PORT_STS_CMODE_SGMII:
- case MV88E6XXX_PORT_STS_CMODE_1000BASE_X:
+ case MV88E6XXX_PORT_STS_CMODE_1000BASEX:
case MV88E6XXX_PORT_STS_CMODE_2500BASEX:
err = mv88e6390_serdes_irq_disable_sgmii(chip, lane);
}
@@ -629,7 +629,7 @@ static irqreturn_t mv88e6390_serdes_thread_fn(int irq, void *dev_id)
switch (cmode) {
case MV88E6XXX_PORT_STS_CMODE_SGMII:
- case MV88E6XXX_PORT_STS_CMODE_1000BASE_X:
+ case MV88E6XXX_PORT_STS_CMODE_1000BASEX:
case MV88E6XXX_PORT_STS_CMODE_2500BASEX:
err = mv88e6390_serdes_irq_status_sgmii(chip, lane, &status);
if (err)
--
2.21.0
^ permalink raw reply related
* [PATCH net-next v3 2/6] net: dsa: mv88e6xxx: update code operating on hidden registers
From: Marek Behún @ 2019-08-25 3:59 UTC (permalink / raw)
To: netdev
Cc: Andrew Lunn, Vivien Didelot, Florian Fainelli, Vladimir Oltean,
Marek Behún
In-Reply-To: <20190825035915.13112-1-marek.behun@nic.cz>
This patch moves the functions operating on the hidden debug registers
into it's own file, port_hidden.c. The functions prefix is renamed from
mv88e6390_hidden_ to mv88e6xxx_port_hidden_, to be consistent with the
rest of this driver. The macros are prefixed with MV88E6XXX_ prefix, and
are changed not to use the BIT() macro nor bit shifts, since the rest of
the port.h file does not use it.
We also add the support for setting the Block Address field when
operating hidden registers. Marvell's mdio examples for SERDES settings
on Topaz use Block Address 0x7 when reading/writing hidden registers,
and although the specification says that block must be set to 0xf, those
settings are reachable only with Block Address 0x7.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
---
drivers/net/dsa/mv88e6xxx/Makefile | 1 +
drivers/net/dsa/mv88e6xxx/chip.c | 58 +-------------------
drivers/net/dsa/mv88e6xxx/port.h | 22 +++++---
drivers/net/dsa/mv88e6xxx/port_hidden.c | 70 +++++++++++++++++++++++++
4 files changed, 87 insertions(+), 64 deletions(-)
create mode 100644 drivers/net/dsa/mv88e6xxx/port_hidden.c
diff --git a/drivers/net/dsa/mv88e6xxx/Makefile b/drivers/net/dsa/mv88e6xxx/Makefile
index e85755dde90b..aa645ff86f64 100644
--- a/drivers/net/dsa/mv88e6xxx/Makefile
+++ b/drivers/net/dsa/mv88e6xxx/Makefile
@@ -10,6 +10,7 @@ mv88e6xxx-$(CONFIG_NET_DSA_MV88E6XXX_GLOBAL2) += global2_scratch.o
mv88e6xxx-$(CONFIG_NET_DSA_MV88E6XXX_PTP) += hwtstamp.o
mv88e6xxx-objs += phy.o
mv88e6xxx-objs += port.o
+mv88e6xxx-objs += port_hidden.o
mv88e6xxx-$(CONFIG_NET_DSA_MV88E6XXX_PTP) += ptp.o
mv88e6xxx-objs += serdes.o
mv88e6xxx-objs += smi.o
diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index d0bf98c10b2b..ec4274d71145 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -2317,60 +2317,6 @@ static int mv88e6xxx_stats_setup(struct mv88e6xxx_chip *chip)
return mv88e6xxx_g1_stats_clear(chip);
}
-/* The mv88e6390 has some hidden registers used for debug and
- * development. The errata also makes use of them.
- */
-static int mv88e6390_hidden_write(struct mv88e6xxx_chip *chip, int port,
- int reg, u16 val)
-{
- u16 ctrl;
- int err;
-
- err = mv88e6xxx_port_write(chip, PORT_RESERVED_1A_DATA_PORT,
- PORT_RESERVED_1A, val);
- if (err)
- return err;
-
- ctrl = PORT_RESERVED_1A_BUSY | PORT_RESERVED_1A_WRITE |
- PORT_RESERVED_1A_BLOCK | port << PORT_RESERVED_1A_PORT_SHIFT |
- reg;
-
- return mv88e6xxx_port_write(chip, PORT_RESERVED_1A_CTRL_PORT,
- PORT_RESERVED_1A, ctrl);
-}
-
-static int mv88e6390_hidden_wait(struct mv88e6xxx_chip *chip)
-{
- int bit = __bf_shf(PORT_RESERVED_1A_BUSY);
-
- return mv88e6xxx_wait_bit(chip, PORT_RESERVED_1A_CTRL_PORT,
- PORT_RESERVED_1A, bit, 0);
-}
-
-
-static int mv88e6390_hidden_read(struct mv88e6xxx_chip *chip, int port,
- int reg, u16 *val)
-{
- u16 ctrl;
- int err;
-
- ctrl = PORT_RESERVED_1A_BUSY | PORT_RESERVED_1A_READ |
- PORT_RESERVED_1A_BLOCK | port << PORT_RESERVED_1A_PORT_SHIFT |
- reg;
-
- err = mv88e6xxx_port_write(chip, PORT_RESERVED_1A_CTRL_PORT,
- PORT_RESERVED_1A, ctrl);
- if (err)
- return err;
-
- err = mv88e6390_hidden_wait(chip);
- if (err)
- return err;
-
- return mv88e6xxx_port_read(chip, PORT_RESERVED_1A_DATA_PORT,
- PORT_RESERVED_1A, val);
-}
-
/* Check if the errata has already been applied. */
static bool mv88e6390_setup_errata_applied(struct mv88e6xxx_chip *chip)
{
@@ -2379,7 +2325,7 @@ static bool mv88e6390_setup_errata_applied(struct mv88e6xxx_chip *chip)
u16 val;
for (port = 0; port < mv88e6xxx_num_ports(chip); port++) {
- err = mv88e6390_hidden_read(chip, port, 0, &val);
+ err = mv88e6xxx_port_hidden_read(chip, 0xf, port, 0, &val);
if (err) {
dev_err(chip->dev,
"Error reading hidden register: %d\n", err);
@@ -2412,7 +2358,7 @@ static int mv88e6390_setup_errata(struct mv88e6xxx_chip *chip)
}
for (port = 0; port < mv88e6xxx_num_ports(chip); port++) {
- err = mv88e6390_hidden_write(chip, port, 0, 0x01c0);
+ err = mv88e6xxx_port_hidden_write(chip, 0xf, port, 0, 0x01c0);
if (err)
return err;
}
diff --git a/drivers/net/dsa/mv88e6xxx/port.h b/drivers/net/dsa/mv88e6xxx/port.h
index 1abf5ea033e2..64c73fd171ee 100644
--- a/drivers/net/dsa/mv88e6xxx/port.h
+++ b/drivers/net/dsa/mv88e6xxx/port.h
@@ -261,14 +261,14 @@
#define MV88E6095_PORT_IEEE_PRIO_REMAP_4567 0x19
/* Offset 0x1a: Magic undocumented errata register */
-#define PORT_RESERVED_1A 0x1a
-#define PORT_RESERVED_1A_BUSY BIT(15)
-#define PORT_RESERVED_1A_WRITE BIT(14)
-#define PORT_RESERVED_1A_READ 0
-#define PORT_RESERVED_1A_PORT_SHIFT 5
-#define PORT_RESERVED_1A_BLOCK (0xf << 10)
-#define PORT_RESERVED_1A_CTRL_PORT 4
-#define PORT_RESERVED_1A_DATA_PORT 5
+#define MV88E6XXX_PORT_RESERVED_1A 0x1a
+#define MV88E6XXX_PORT_RESERVED_1A_BUSY 0x8000
+#define MV88E6XXX_PORT_RESERVED_1A_WRITE 0x4000
+#define MV88E6XXX_PORT_RESERVED_1A_READ 0x0000
+#define MV88E6XXX_PORT_RESERVED_1A_PORT_SHIFT 5
+#define MV88E6XXX_PORT_RESERVED_1A_BLOCK_SHIFT 10
+#define MV88E6XXX_PORT_RESERVED_1A_CTRL_PORT 0x04
+#define MV88E6XXX_PORT_RESERVED_1A_DATA_PORT 0x05
int mv88e6xxx_port_read(struct mv88e6xxx_chip *chip, int port, int reg,
u16 *val);
@@ -353,4 +353,10 @@ int mv88e6095_port_set_upstream_port(struct mv88e6xxx_chip *chip, int port,
int mv88e6xxx_port_disable_learn_limit(struct mv88e6xxx_chip *chip, int port);
int mv88e6xxx_port_disable_pri_override(struct mv88e6xxx_chip *chip, int port);
+int mv88e6xxx_port_hidden_write(struct mv88e6xxx_chip *chip, int block,
+ int port, int reg, u16 val);
+int mv88e6xxx_port_hidden_wait(struct mv88e6xxx_chip *chip);
+int mv88e6xxx_port_hidden_read(struct mv88e6xxx_chip *chip, int block, int port,
+ int reg, u16 *val);
+
#endif /* _MV88E6XXX_PORT_H */
diff --git a/drivers/net/dsa/mv88e6xxx/port_hidden.c b/drivers/net/dsa/mv88e6xxx/port_hidden.c
new file mode 100644
index 000000000000..fc0a45cb4f68
--- /dev/null
+++ b/drivers/net/dsa/mv88e6xxx/port_hidden.c
@@ -0,0 +1,70 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Marvell 88E6xxx Switch Hidden Registers support
+ *
+ * Copyright (c) 2008 Marvell Semiconductor
+ *
+ * Copyright (c) 2019 Andrew Lunn <andrew@lunn.ch>
+ */
+
+#include <linux/bitfield.h>
+
+#include "chip.h"
+#include "port.h"
+
+/* The mv88e6390 and mv88e6341 have some hidden registers used for debug and
+ * development. The errata also makes use of them.
+ */
+int mv88e6xxx_port_hidden_write(struct mv88e6xxx_chip *chip, int block,
+ int port, int reg, u16 val)
+{
+ u16 ctrl;
+ int err;
+
+ err = mv88e6xxx_port_write(chip, MV88E6XXX_PORT_RESERVED_1A_DATA_PORT,
+ MV88E6XXX_PORT_RESERVED_1A, val);
+ if (err)
+ return err;
+
+ ctrl = MV88E6XXX_PORT_RESERVED_1A_BUSY |
+ MV88E6XXX_PORT_RESERVED_1A_WRITE |
+ block << MV88E6XXX_PORT_RESERVED_1A_BLOCK_SHIFT |
+ port << MV88E6XXX_PORT_RESERVED_1A_PORT_SHIFT |
+ reg;
+
+ return mv88e6xxx_port_write(chip, MV88E6XXX_PORT_RESERVED_1A_CTRL_PORT,
+ MV88E6XXX_PORT_RESERVED_1A, ctrl);
+}
+
+int mv88e6xxx_port_hidden_wait(struct mv88e6xxx_chip *chip)
+{
+ int bit = __bf_shf(MV88E6XXX_PORT_RESERVED_1A_BUSY);
+
+ return mv88e6xxx_wait_bit(chip, MV88E6XXX_PORT_RESERVED_1A_CTRL_PORT,
+ MV88E6XXX_PORT_RESERVED_1A, bit, 0);
+}
+
+int mv88e6xxx_port_hidden_read(struct mv88e6xxx_chip *chip, int block, int port,
+ int reg, u16 *val)
+{
+ u16 ctrl;
+ int err;
+
+ ctrl = MV88E6XXX_PORT_RESERVED_1A_BUSY |
+ MV88E6XXX_PORT_RESERVED_1A_READ |
+ block << MV88E6XXX_PORT_RESERVED_1A_BLOCK_SHIFT |
+ port << MV88E6XXX_PORT_RESERVED_1A_PORT_SHIFT |
+ reg;
+
+ err = mv88e6xxx_port_write(chip, MV88E6XXX_PORT_RESERVED_1A_CTRL_PORT,
+ MV88E6XXX_PORT_RESERVED_1A, ctrl);
+ if (err)
+ return err;
+
+ err = mv88e6xxx_port_hidden_wait(chip);
+ if (err)
+ return err;
+
+ return mv88e6xxx_port_read(chip, MV88E6XXX_PORT_RESERVED_1A_DATA_PORT,
+ MV88E6XXX_PORT_RESERVED_1A, val);
+}
--
2.21.0
^ permalink raw reply related
* [PATCH net-next v3 4/6] net: dsa: mv88e6xxx: simplify SERDES code for Topaz and Peridot
From: Marek Behún @ 2019-08-25 3:59 UTC (permalink / raw)
To: netdev
Cc: Andrew Lunn, Vivien Didelot, Florian Fainelli, Vladimir Oltean,
Marek Behún
In-Reply-To: <20190825035915.13112-1-marek.behun@nic.cz>
By adding an additional serdes_get_lane implementation (for Topaz), we
can merge the implementations of other SERDES functions (powering and
IRQs). We can skip checking port numbers, since the serdes_get_lane()
methods inform if there is no lane on a port or if the lane cannot be
used for given cmode.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
---
drivers/net/dsa/mv88e6xxx/chip.c | 18 ++---
drivers/net/dsa/mv88e6xxx/port.c | 4 +-
drivers/net/dsa/mv88e6xxx/serdes.c | 104 ++++++++---------------------
drivers/net/dsa/mv88e6xxx/serdes.h | 7 +-
4 files changed, 42 insertions(+), 91 deletions(-)
diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index 5a3fff1971b9..202ccce65b1c 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -2927,7 +2927,8 @@ static const struct mv88e6xxx_ops mv88e6141_ops = {
.reset = mv88e6352_g1_reset,
.vtu_getnext = mv88e6352_g1_vtu_getnext,
.vtu_loadpurge = mv88e6352_g1_vtu_loadpurge,
- .serdes_power = mv88e6341_serdes_power,
+ .serdes_power = mv88e6390_serdes_power,
+ .serdes_get_lane = mv88e6341_serdes_get_lane,
.gpio_ops = &mv88e6352_gpio_ops,
.phylink_validate = mv88e6341_phylink_validate,
};
@@ -3301,10 +3302,10 @@ static const struct mv88e6xxx_ops mv88e6190x_ops = {
.rmu_disable = mv88e6390_g1_rmu_disable,
.vtu_getnext = mv88e6390_g1_vtu_getnext,
.vtu_loadpurge = mv88e6390_g1_vtu_loadpurge,
- .serdes_power = mv88e6390x_serdes_power,
+ .serdes_power = mv88e6390_serdes_power,
.serdes_get_lane = mv88e6390x_serdes_get_lane,
- .serdes_irq_setup = mv88e6390x_serdes_irq_setup,
- .serdes_irq_free = mv88e6390x_serdes_irq_free,
+ .serdes_irq_setup = mv88e6390_serdes_irq_setup,
+ .serdes_irq_free = mv88e6390_serdes_irq_free,
.gpio_ops = &mv88e6352_gpio_ops,
.phylink_validate = mv88e6390x_phylink_validate,
};
@@ -3621,7 +3622,8 @@ static const struct mv88e6xxx_ops mv88e6341_ops = {
.reset = mv88e6352_g1_reset,
.vtu_getnext = mv88e6352_g1_vtu_getnext,
.vtu_loadpurge = mv88e6352_g1_vtu_loadpurge,
- .serdes_power = mv88e6341_serdes_power,
+ .serdes_power = mv88e6390_serdes_power,
+ .serdes_get_lane = mv88e6341_serdes_get_lane,
.gpio_ops = &mv88e6352_gpio_ops,
.avb_ops = &mv88e6390_avb_ops,
.ptp_ops = &mv88e6352_ptp_ops,
@@ -3854,10 +3856,10 @@ static const struct mv88e6xxx_ops mv88e6390x_ops = {
.rmu_disable = mv88e6390_g1_rmu_disable,
.vtu_getnext = mv88e6390_g1_vtu_getnext,
.vtu_loadpurge = mv88e6390_g1_vtu_loadpurge,
- .serdes_power = mv88e6390x_serdes_power,
+ .serdes_power = mv88e6390_serdes_power,
.serdes_get_lane = mv88e6390x_serdes_get_lane,
- .serdes_irq_setup = mv88e6390x_serdes_irq_setup,
- .serdes_irq_free = mv88e6390x_serdes_irq_free,
+ .serdes_irq_setup = mv88e6390_serdes_irq_setup,
+ .serdes_irq_free = mv88e6390_serdes_irq_free,
.gpio_ops = &mv88e6352_gpio_ops,
.avb_ops = &mv88e6390_avb_ops,
.ptp_ops = &mv88e6352_ptp_ops,
diff --git a/drivers/net/dsa/mv88e6xxx/port.c b/drivers/net/dsa/mv88e6xxx/port.c
index 6a1fa5c72fdb..d20be5327640 100644
--- a/drivers/net/dsa/mv88e6xxx/port.c
+++ b/drivers/net/dsa/mv88e6xxx/port.c
@@ -445,7 +445,7 @@ int mv88e6390x_port_set_cmode(struct mv88e6xxx_chip *chip, int port,
return err;
}
- err = mv88e6390x_serdes_power(chip, port, false);
+ err = mv88e6390_serdes_power(chip, port, false);
if (err)
return err;
}
@@ -470,7 +470,7 @@ int mv88e6390x_port_set_cmode(struct mv88e6xxx_chip *chip, int port,
if (err)
return err;
- err = mv88e6390x_serdes_power(chip, port, true);
+ err = mv88e6390_serdes_power(chip, port, true);
if (err)
return err;
diff --git a/drivers/net/dsa/mv88e6xxx/serdes.c b/drivers/net/dsa/mv88e6xxx/serdes.c
index a9209465e06b..1946ccb6694c 100644
--- a/drivers/net/dsa/mv88e6xxx/serdes.c
+++ b/drivers/net/dsa/mv88e6xxx/serdes.c
@@ -286,6 +286,23 @@ void mv88e6352_serdes_irq_free(struct mv88e6xxx_chip *chip, int port)
chip->ports[port].serdes_irq = 0;
}
+int mv88e6341_serdes_get_lane(struct mv88e6xxx_chip *chip, int port, s8 *lane)
+{
+ u8 cmode = chip->ports[port].cmode;
+
+ *lane = -1;
+
+ if (port != 5)
+ return 0;
+
+ if (cmode == MV88E6XXX_PORT_STS_CMODE_1000BASE_X ||
+ cmode == MV88E6XXX_PORT_STS_CMODE_SGMII ||
+ cmode == MV88E6XXX_PORT_STS_CMODE_2500BASEX)
+ *lane = MV88E6341_PORT5_LANE;
+
+ return 0;
+}
+
int mv88e6390_serdes_get_lane(struct mv88e6xxx_chip *chip, int port, s8 *lane)
{
u8 cmode = chip->ports[port].cmode;
@@ -445,26 +462,9 @@ static int mv88e6390_serdes_power_sgmii(struct mv88e6xxx_chip *chip, s8 lane,
return err;
}
-static int mv88e6390_serdes_power_lane(struct mv88e6xxx_chip *chip, int port,
- s8 lane, bool on)
-{
- u8 cmode = chip->ports[port].cmode;
-
- switch (cmode) {
- case MV88E6XXX_PORT_STS_CMODE_SGMII:
- case MV88E6XXX_PORT_STS_CMODE_1000BASE_X:
- case MV88E6XXX_PORT_STS_CMODE_2500BASEX:
- return mv88e6390_serdes_power_sgmii(chip, lane, on);
- case MV88E6XXX_PORT_STS_CMODE_XAUI:
- case MV88E6XXX_PORT_STS_CMODE_RXAUI:
- return mv88e6390_serdes_power_10g(chip, lane, on);
- }
-
- return 0;
-}
-
int mv88e6390_serdes_power(struct mv88e6xxx_chip *chip, int port, bool on)
{
+ u8 cmode = chip->ports[port].cmode;
s8 lane;
int err;
@@ -474,30 +474,14 @@ int mv88e6390_serdes_power(struct mv88e6xxx_chip *chip, int port, bool on)
if (lane < 0)
return 0;
- switch (port) {
- case 9 ... 10:
- return mv88e6390_serdes_power_lane(chip, port, lane, on);
- }
-
- return 0;
-}
-
-int mv88e6390x_serdes_power(struct mv88e6xxx_chip *chip, int port, bool on)
-{
- s8 lane;
- int err;
-
- err = mv88e6xxx_serdes_get_lane(chip, port, &lane);
- if (err)
- return err;
- if (lane < 0)
- return 0;
-
- switch (port) {
- case 2 ... 4:
- case 5 ... 7:
- case 9 ... 10:
- return mv88e6390_serdes_power_lane(chip, port, lane, on);
+ switch (cmode) {
+ case MV88E6XXX_PORT_STS_CMODE_SGMII:
+ case MV88E6XXX_PORT_STS_CMODE_1000BASE_X:
+ case MV88E6XXX_PORT_STS_CMODE_2500BASEX:
+ return mv88e6390_serdes_power_sgmii(chip, lane, on);
+ case MV88E6XXX_PORT_STS_CMODE_XAUI:
+ case MV88E6XXX_PORT_STS_CMODE_RXAUI:
+ return mv88e6390_serdes_power_10g(chip, lane, on);
}
return 0;
@@ -662,7 +646,7 @@ static irqreturn_t mv88e6390_serdes_thread_fn(int irq, void *dev_id)
return ret;
}
-int mv88e6390x_serdes_irq_setup(struct mv88e6xxx_chip *chip, int port)
+int mv88e6390_serdes_irq_setup(struct mv88e6xxx_chip *chip, int port)
{
int err;
s8 lane;
@@ -700,15 +684,7 @@ int mv88e6390x_serdes_irq_setup(struct mv88e6xxx_chip *chip, int port)
return mv88e6390_serdes_irq_enable(chip, port, lane);
}
-int mv88e6390_serdes_irq_setup(struct mv88e6xxx_chip *chip, int port)
-{
- if (port < 9)
- return 0;
-
- return mv88e6390x_serdes_irq_setup(chip, port);
-}
-
-void mv88e6390x_serdes_irq_free(struct mv88e6xxx_chip *chip, int port)
+void mv88e6390_serdes_irq_free(struct mv88e6xxx_chip *chip, int port)
{
int err;
s8 lane;
@@ -732,27 +708,3 @@ void mv88e6390x_serdes_irq_free(struct mv88e6xxx_chip *chip, int port)
chip->ports[port].serdes_irq = 0;
}
-
-void mv88e6390_serdes_irq_free(struct mv88e6xxx_chip *chip, int port)
-{
- if (port < 9)
- return;
-
- mv88e6390x_serdes_irq_free(chip, port);
-}
-
-int mv88e6341_serdes_power(struct mv88e6xxx_chip *chip, int port, bool on)
-{
- u8 cmode = chip->ports[port].cmode;
-
- if (port != 5)
- return 0;
-
- if (cmode == MV88E6XXX_PORT_STS_CMODE_1000BASE_X ||
- cmode == MV88E6XXX_PORT_STS_CMODE_SGMII ||
- cmode == MV88E6XXX_PORT_STS_CMODE_2500BASEX)
- return mv88e6390_serdes_power_sgmii(chip, MV88E6341_ADDR_SERDES,
- on);
-
- return 0;
-}
diff --git a/drivers/net/dsa/mv88e6xxx/serdes.h b/drivers/net/dsa/mv88e6xxx/serdes.h
index 1ddb8fb3aab9..7fded708b05d 100644
--- a/drivers/net/dsa/mv88e6xxx/serdes.h
+++ b/drivers/net/dsa/mv88e6xxx/serdes.h
@@ -28,7 +28,7 @@
#define MV88E6352_SERDES_INT_STATUS 0x13
-#define MV88E6341_ADDR_SERDES 0x15
+#define MV88E6341_PORT5_LANE 0x15
#define MV88E6390_PORT9_LANE0 0x09
#define MV88E6390_PORT9_LANE1 0x12
@@ -87,16 +87,13 @@ static inline int mv88e6xxx_serdes_get_lane(struct mv88e6xxx_chip *chip,
return chip->info->ops->serdes_get_lane(chip, port, lane);
}
+int mv88e6341_serdes_get_lane(struct mv88e6xxx_chip *chip, int port, s8 *lane);
int mv88e6390_serdes_get_lane(struct mv88e6xxx_chip *chip, int port, s8 *lane);
int mv88e6390x_serdes_get_lane(struct mv88e6xxx_chip *chip, int port, s8 *lane);
-int mv88e6341_serdes_power(struct mv88e6xxx_chip *chip, int port, bool on);
int mv88e6352_serdes_power(struct mv88e6xxx_chip *chip, int port, bool on);
int mv88e6390_serdes_power(struct mv88e6xxx_chip *chip, int port, bool on);
-int mv88e6390x_serdes_power(struct mv88e6xxx_chip *chip, int port, bool on);
int mv88e6390_serdes_irq_setup(struct mv88e6xxx_chip *chip, int port);
void mv88e6390_serdes_irq_free(struct mv88e6xxx_chip *chip, int port);
-int mv88e6390x_serdes_irq_setup(struct mv88e6xxx_chip *chip, int port);
-void mv88e6390x_serdes_irq_free(struct mv88e6xxx_chip *chip, int port);
int mv88e6352_serdes_get_sset_count(struct mv88e6xxx_chip *chip, int port);
int mv88e6352_serdes_get_strings(struct mv88e6xxx_chip *chip,
int port, uint8_t *data);
--
2.21.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox