* [PATCH net-next 2/2] net: phy: aquantia: add hwmon support
From: Heiner Kallweit @ 2019-02-24 20:09 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, David Miller; +Cc: netdev@vger.kernel.org
In-Reply-To: <0a05279a-ab9e-a978-df4d-f09869c3bba2@gmail.com>
This adds HWMON support for the temperature sensor and the related
alarms on the 107/108/109 chips. This patch is based on work from
Nikita and Andrew. I added:
- support for changing alarm thresholds via sysfs
- move HWMON code to a separate source file to improve maintainability
- smaller changes like using IS_REACHABLE instead of ifdef
(avoids problems if PHY driver is built in and HWMON is a module)
Signed-off-by: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
drivers/net/phy/Makefile | 2 +-
drivers/net/phy/aquantia_hwmon.c | 263 +++++++++++++++++++++++++++++++
drivers/net/phy/aquantia_hwmon.h | 15 ++
drivers/net/phy/aquantia_main.c | 4 +
4 files changed, 283 insertions(+), 1 deletion(-)
create mode 100644 drivers/net/phy/aquantia_hwmon.c
create mode 100644 drivers/net/phy/aquantia_hwmon.h
diff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile
index b0845adaf..c48596626 100644
--- a/drivers/net/phy/Makefile
+++ b/drivers/net/phy/Makefile
@@ -45,7 +45,7 @@ sfp-obj-$(CONFIG_SFP) += sfp-bus.o
obj-y += $(sfp-obj-y) $(sfp-obj-m)
obj-$(CONFIG_AMD_PHY) += amd.o
-aquantia-objs += aquantia_main.o
+aquantia-objs += aquantia_main.o aquantia_hwmon.o
obj-$(CONFIG_AQUANTIA_PHY) += aquantia.o
obj-$(CONFIG_ASIX_PHY) += asix.o
obj-$(CONFIG_AT803X_PHY) += at803x.o
diff --git a/drivers/net/phy/aquantia_hwmon.c b/drivers/net/phy/aquantia_hwmon.c
new file mode 100644
index 000000000..c0dd695f6
--- /dev/null
+++ b/drivers/net/phy/aquantia_hwmon.c
@@ -0,0 +1,263 @@
+// SPDX-License-Identifier: GPL-2.0
+/* HWMON driver for Aquantia PHY
+ *
+ * Author: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
+ * Author: Andrew Lunn <andrew@lunn.ch>
+ * Author: Heiner Kallweit <hkallweit1@gmail.com>
+ */
+
+#include <linux/phy.h>
+#include <linux/device.h>
+#include <linux/ctype.h>
+#include <linux/hwmon.h>
+
+#include "aquantia_hwmon.h"
+
+/* Vendor specific 1, MDIO_MMD_VEND1 */
+#define VEND1_THERMAL_PROV_HIGH_TEMP_FAIL 0xc421
+#define VEND1_THERMAL_PROV_LOW_TEMP_FAIL 0xc422
+#define VEND1_THERMAL_PROV_HIGH_TEMP_WARN 0xc423
+#define VEND1_THERMAL_PROV_LOW_TEMP_WARN 0xc424
+#define VEND1_THERMAL_STAT1 0xc820
+#define VEND1_THERMAL_STAT2 0xc821
+#define VEND1_THERMAL_STAT2_VALID BIT(0)
+#define VEND1_GENERAL_STAT1 0xc830
+#define VEND1_GENERAL_STAT1_HIGH_TEMP_FAIL BIT(14)
+#define VEND1_GENERAL_STAT1_LOW_TEMP_FAIL BIT(13)
+#define VEND1_GENERAL_STAT1_HIGH_TEMP_WARN BIT(12)
+#define VEND1_GENERAL_STAT1_LOW_TEMP_WARN BIT(11)
+
+struct aqr_priv {
+ struct device *hwmon_dev;
+ char *hwmon_name;
+};
+
+#if IS_REACHABLE(CONFIG_HWMON)
+
+static umode_t aqr_hwmon_is_visible(const void *data,
+ enum hwmon_sensor_types type,
+ u32 attr, int channel)
+{
+ if (type != hwmon_temp)
+ return 0;
+
+ switch (attr) {
+ case hwmon_temp_input:
+ case hwmon_temp_min_alarm:
+ case hwmon_temp_max_alarm:
+ case hwmon_temp_lcrit_alarm:
+ case hwmon_temp_crit_alarm:
+ return 0444;
+ case hwmon_temp_min:
+ case hwmon_temp_max:
+ case hwmon_temp_lcrit:
+ case hwmon_temp_crit:
+ return 0644;
+ default:
+ return 0;
+ }
+}
+
+static int aqr_hwmon_get(struct phy_device *phydev, int reg, long *value)
+{
+ int temp = phy_read_mmd(phydev, MDIO_MMD_VEND1, reg);
+
+ if (temp < 0)
+ return temp;
+
+ /* register value is 2's complement with LSB = 1/256th degree Celsius */
+ if (temp > 0x8000)
+ temp -= 0x10000;
+
+ *value = temp * 1000 / 256;
+
+ return 0;
+}
+
+static int aqr_hwmon_set(struct phy_device *phydev, int reg, long value)
+{
+ int temp;
+
+ if (value >= 128000 || value < -128000)
+ return -ERANGE;
+
+ temp = value * 256 / 1000;
+
+ if (temp < 0)
+ temp += 0x10000;
+
+ return phy_write_mmd(phydev, MDIO_MMD_VEND1, reg, temp);
+}
+
+static int aqr_hwmon_status1(struct phy_device *phydev, int bit, long *value)
+{
+ int reg = phy_read_mmd(phydev, MDIO_MMD_VEND1, VEND1_GENERAL_STAT1);
+
+ if (reg < 0)
+ return reg;
+
+ *value = !!(reg & bit);
+
+ return 0;
+}
+
+static int aqr_hwmon_read(struct device *dev, enum hwmon_sensor_types type,
+ u32 attr, int channel, long *value)
+{
+ struct phy_device *phydev = dev_get_drvdata(dev);
+ int reg;
+
+ if (type != hwmon_temp)
+ return -EOPNOTSUPP;
+
+ switch (attr) {
+ case hwmon_temp_input:
+ reg = phy_read_mmd(phydev, MDIO_MMD_VEND1,
+ VEND1_THERMAL_STAT2);
+ if (reg < 0)
+ return reg;
+ if (!(reg & VEND1_THERMAL_STAT2_VALID))
+ return -EIO;
+
+ return aqr_hwmon_get(phydev, VEND1_THERMAL_STAT1, value);
+
+ case hwmon_temp_lcrit:
+ return aqr_hwmon_get(phydev, VEND1_THERMAL_PROV_LOW_TEMP_FAIL,
+ value);
+ case hwmon_temp_min:
+ return aqr_hwmon_get(phydev, VEND1_THERMAL_PROV_LOW_TEMP_WARN,
+ value);
+ case hwmon_temp_max:
+ return aqr_hwmon_get(phydev, VEND1_THERMAL_PROV_HIGH_TEMP_WARN,
+ value);
+ case hwmon_temp_crit:
+ return aqr_hwmon_get(phydev, VEND1_THERMAL_PROV_HIGH_TEMP_FAIL,
+ value);
+ case hwmon_temp_lcrit_alarm:
+ return aqr_hwmon_status1(phydev,
+ VEND1_GENERAL_STAT1_LOW_TEMP_FAIL,
+ value);
+ case hwmon_temp_min_alarm:
+ return aqr_hwmon_status1(phydev,
+ VEND1_GENERAL_STAT1_LOW_TEMP_WARN,
+ value);
+ case hwmon_temp_max_alarm:
+ return aqr_hwmon_status1(phydev,
+ VEND1_GENERAL_STAT1_HIGH_TEMP_WARN,
+ value);
+ case hwmon_temp_crit_alarm:
+ return aqr_hwmon_status1(phydev,
+ VEND1_GENERAL_STAT1_HIGH_TEMP_FAIL,
+ value);
+ default:
+ return -EOPNOTSUPP;
+ }
+}
+
+static int aqr_hwmon_write(struct device *dev, enum hwmon_sensor_types type,
+ u32 attr, int channel, long value)
+{
+ struct phy_device *phydev = dev_get_drvdata(dev);
+
+ if (type != hwmon_temp)
+ return -EOPNOTSUPP;
+
+ switch (attr) {
+ case hwmon_temp_lcrit:
+ return aqr_hwmon_set(phydev, VEND1_THERMAL_PROV_LOW_TEMP_FAIL,
+ value);
+ case hwmon_temp_min:
+ return aqr_hwmon_set(phydev, VEND1_THERMAL_PROV_LOW_TEMP_WARN,
+ value);
+ case hwmon_temp_max:
+ return aqr_hwmon_set(phydev, VEND1_THERMAL_PROV_HIGH_TEMP_WARN,
+ value);
+ case hwmon_temp_crit:
+ return aqr_hwmon_set(phydev, VEND1_THERMAL_PROV_HIGH_TEMP_FAIL,
+ value);
+ default:
+ return -EOPNOTSUPP;
+ }
+}
+
+static const struct hwmon_ops aqr_hwmon_ops = {
+ .is_visible = aqr_hwmon_is_visible,
+ .read = aqr_hwmon_read,
+ .write = aqr_hwmon_write,
+};
+
+static u32 aqr_hwmon_chip_config[] = {
+ HWMON_C_REGISTER_TZ,
+ 0,
+};
+
+static const struct hwmon_channel_info aqr_hwmon_chip = {
+ .type = hwmon_chip,
+ .config = aqr_hwmon_chip_config,
+};
+
+static u32 aqr_hwmon_temp_config[] = {
+ HWMON_T_INPUT |
+ 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,
+ 0,
+};
+
+static const struct hwmon_channel_info aqr_hwmon_temp = {
+ .type = hwmon_temp,
+ .config = aqr_hwmon_temp_config,
+};
+
+static const struct hwmon_channel_info *aqr_hwmon_info[] = {
+ &aqr_hwmon_chip,
+ &aqr_hwmon_temp,
+ NULL,
+};
+
+static const struct hwmon_chip_info aqr_hwmon_chip_info = {
+ .ops = &aqr_hwmon_ops,
+ .info = aqr_hwmon_info,
+};
+
+static int aqr_hwmon_really_probe(struct phy_device *phydev)
+{
+ struct device *dev = &phydev->mdio.dev;
+ struct aqr_priv *priv = phydev->priv;
+ int i, j;
+
+ priv->hwmon_name = devm_kstrdup(dev, dev_name(dev), GFP_KERNEL);
+ if (!priv->hwmon_name)
+ return -ENOMEM;
+
+ for (i = j = 0; priv->hwmon_name[i]; i++) {
+ if (isalnum(priv->hwmon_name[i])) {
+ if (i != j)
+ priv->hwmon_name[j] = priv->hwmon_name[i];
+ j++;
+ }
+ }
+ priv->hwmon_name[j] = '\0';
+
+ priv->hwmon_dev = devm_hwmon_device_register_with_info(dev,
+ priv->hwmon_name, phydev,
+ &aqr_hwmon_chip_info, NULL);
+
+ return PTR_ERR_OR_ZERO(priv->hwmon_dev);
+}
+
+int aqr_hwmon_probe(struct phy_device *phydev)
+{
+ struct aqr_priv *priv;
+
+ priv = devm_kzalloc(&phydev->mdio.dev, sizeof(*priv), GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
+
+ phydev->priv = priv;
+
+ return aqr_hwmon_really_probe(phydev);
+}
+
+#endif
diff --git a/drivers/net/phy/aquantia_hwmon.h b/drivers/net/phy/aquantia_hwmon.h
new file mode 100644
index 000000000..607e68758
--- /dev/null
+++ b/drivers/net/phy/aquantia_hwmon.h
@@ -0,0 +1,15 @@
+/* SPDX-License-Identifier: GPL-2.0
+ * HWMON driver for Aquantia PHY
+ *
+ * Author: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
+ * Author: Andrew Lunn <andrew@lunn.ch>
+ * Author: Heiner Kallweit <hkallweit1@gmail.com>
+ */
+
+#include <linux/phy.h>
+
+#if IS_REACHABLE(CONFIG_HWMON)
+int aqr_hwmon_probe(struct phy_device *phydev);
+#else
+static inline int aqr_hwmon_probe(struct phy_device *phydev) { return 0; }
+#endif
diff --git a/drivers/net/phy/aquantia_main.c b/drivers/net/phy/aquantia_main.c
index 0f0eb5682..af6dc3588 100644
--- a/drivers/net/phy/aquantia_main.c
+++ b/drivers/net/phy/aquantia_main.c
@@ -12,6 +12,8 @@
#include <linux/delay.h>
#include <linux/phy.h>
+#include "aquantia_hwmon.h"
+
#define PHY_ID_AQ1202 0x03a1b445
#define PHY_ID_AQ2104 0x03a1b460
#define PHY_ID_AQR105 0x03a1b4a2
@@ -231,6 +233,7 @@ static struct phy_driver aqr_driver[] = {
.name = "Aquantia AQR107",
.aneg_done = genphy_c45_aneg_done,
.get_features = genphy_c45_pma_read_abilities,
+ .probe = aqr_hwmon_probe,
.config_aneg = aqr_config_aneg,
.config_intr = aqr_config_intr,
.ack_interrupt = aqr_ack_interrupt,
@@ -241,6 +244,7 @@ static struct phy_driver aqr_driver[] = {
.name = "Aquantia AQCS109",
.aneg_done = genphy_c45_aneg_done,
.get_features = genphy_c45_pma_read_abilities,
+ .probe = aqr_hwmon_probe,
.config_init = aqcs109_config_init,
.config_aneg = aqr_config_aneg,
.config_intr = aqr_config_intr,
--
2.20.1
^ permalink raw reply related
* Re: [PATCH] Documentation: networking: switchdev: Update port parent ID section
From: David Miller @ 2019-02-24 20:13 UTC (permalink / raw)
To: f.fainelli; +Cc: netdev, andrew, vivien.didelot, idosch, jiri
In-Reply-To: <20190224.112630.1072776894762356933.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Sun, 24 Feb 2019 11:26:30 -0800 (PST)
> From: Florian Fainelli <f.fainelli@gmail.com>
> Date: Sun, 24 Feb 2019 08:46:59 -0800
>
>> Looks like you applied this to the "net" tree, and I missed prefixing
>> the patch to indicate this was targeted at the "net-next" tree. Are you
>> planning a merge from "net" to "net-next" anytime soon?
>
> Yes, I am working on that right now.
This is now done.
^ permalink raw reply
* marvell10g.c merge into net-next
From: David Miller @ 2019-02-24 20:15 UTC (permalink / raw)
To: hkallweit1; +Cc: netdev
Heiner, please look at net-next which I just merged net into.
Net had a bug fix wherein the MDIO_AN_10GBT_CTRL_ADV_NBT_MASK
bits are cleared in the 10gbt control register to work around
a problem with some marvell10g phy chips.
In the merge I preserved your usage of the generic c45 helpers
in this area, but I suspect part of that will have to be undone
in order to accomodate the above fix.
Thanks.
^ permalink raw reply
* Re: [PATCH net-next 2/2] net: phy: aquantia: add hwmon support
From: Andrew Lunn @ 2019-02-24 20:29 UTC (permalink / raw)
To: Heiner Kallweit; +Cc: Florian Fainelli, David Miller, netdev@vger.kernel.org
In-Reply-To: <590d1e26-999e-3b09-fcd9-6d570cadb3bf@gmail.com>
> diff --git a/drivers/net/phy/aquantia_hwmon.c b/drivers/net/phy/aquantia_hwmon.c
> new file mode 100644
> index 000000000..c0dd695f6
> --- /dev/null
> +++ b/drivers/net/phy/aquantia_hwmon.c
> @@ -0,0 +1,263 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/* HWMON driver for Aquantia PHY
> + *
> + * Author: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
> + * Author: Andrew Lunn <andrew@lunn.ch>
> + * Author: Heiner Kallweit <hkallweit1@gmail.com>
> + */
> +
> +#include <linux/phy.h>
> +#include <linux/device.h>
> +#include <linux/ctype.h>
> +#include <linux/hwmon.h>
> +
> +#include "aquantia_hwmon.h"
> +
> +/* Vendor specific 1, MDIO_MMD_VEND1 */
> +#define VEND1_THERMAL_PROV_HIGH_TEMP_FAIL 0xc421
> +#define VEND1_THERMAL_PROV_LOW_TEMP_FAIL 0xc422
> +#define VEND1_THERMAL_PROV_HIGH_TEMP_WARN 0xc423
> +#define VEND1_THERMAL_PROV_LOW_TEMP_WARN 0xc424
> +#define VEND1_THERMAL_STAT1 0xc820
> +#define VEND1_THERMAL_STAT2 0xc821
> +#define VEND1_THERMAL_STAT2_VALID BIT(0)
> +#define VEND1_GENERAL_STAT1 0xc830
> +#define VEND1_GENERAL_STAT1_HIGH_TEMP_FAIL BIT(14)
> +#define VEND1_GENERAL_STAT1_LOW_TEMP_FAIL BIT(13)
> +#define VEND1_GENERAL_STAT1_HIGH_TEMP_WARN BIT(12)
> +#define VEND1_GENERAL_STAT1_LOW_TEMP_WARN BIT(11)
> +
> +struct aqr_priv {
> + struct device *hwmon_dev;
> + char *hwmon_name;
> +};
Hi Heiner
It seems a bit odd having the driver private structure here. I expect
with time we are going to need other things in it which are not
HWMON. e.g many of the statistics counters are clear on read. So we
need to keep the running totals somewhere.
I would keep the probe code and the allocation of this structure in
the main driver file.
Andrew
^ permalink raw reply
* Re: [PATCH 5/5] net: dsa: fix a leaked reference by adding missing of_node_put
From: David Miller @ 2019-02-24 20:32 UTC (permalink / raw)
To: wen.yang99
Cc: linus.walleij, andrew, vivien.didelot, f.fainelli, netdev,
linux-kernel, alexandre.belloni, UNGLinuxDriver, nbd,
lorenzo.bianconi83, kvalo, matthias.bgg, linux-wireless,
linux-arm-kernel, linux-mediatek, anirudh, John.Linn,
michal.simek, wang.yi59
In-Reply-To: <1550819742-32155-5-git-send-email-wen.yang99@zte.com.cn>
From: Wen Yang <wen.yang99@zte.com.cn>
Date: Fri, 22 Feb 2019 15:15:42 +0800
> diff --git a/net/dsa/dsa2.c b/net/dsa/dsa2.c
> index 8c431e0..89823f0 100644
> --- a/net/dsa/dsa2.c
> +++ b/net/dsa/dsa2.c
> @@ -613,7 +613,7 @@ static int dsa_switch_parse_ports_of(struct dsa_switch *ds,
> struct device_node *ports, *port;
> struct dsa_port *dp;
> u32 reg;
> - int err;
> + int err = 0;
Please preserve the reverse christmas tree ordering of variables here.
Thank you.
^ permalink raw reply
* Re: [PATCH ethtool] ethtool: Add support for 200Gbps (50Gbps per lane) link mode
From: Michal Kubecek @ 2019-02-24 20:33 UTC (permalink / raw)
To: Andrew Lunn
Cc: Tariq Toukan, John W. Linville, netdev, Eran Ben Elisha,
Aya Levin
In-Reply-To: <20190224194015.GM26626@lunn.ch>
On Sun, Feb 24, 2019 at 08:40:15PM +0100, Andrew Lunn wrote:
> > > This is getting less friendly all the time, and it was never very
> > > friendly to start with. We have the strings which represent these link
> > > modes in the table used for dumping caps. How about allowing the user
> > > to list a comma separate list of modes.
> > >
> > > ethtool -s lan42 advertise 100000baseKR2/Full,100000baseSR2/Full,100000baseCR2/Full
> >
> > In my preliminary netlink patchset, I'm adding support for e.g.
> >
> > ethtool -s eth0 advertise 100baseT/Half off 1000baseT/Full on
> >
> > I'm not sure what would be more useful, if switching individual modes or
> > listing the whole set. After all, we can also support both. But I fully
> > agree that the numeric bitmaps are already too inconvenient.
>
> Hi Michal
>
> So are you doing a read/modify/write? In that case, off/on makes
> sense. For a pure write, i don't see the need for off/on.
When using netlink interface, the read/modify/write cycle is limited to
kernel code and is done under rtnl_lock. The netlink interface allows
userspace to send only attributes it wants to change and for bit sets
(like link modes) to tell kernel which bits it wants to change so that
there is no need to read current values first (and open a race window).
When using ioctl interface, ethtool does read the value first even now
as ETHTOOL_SLINKSETTINGS command uses struct ethtool_link_usettings
which has also other members and there is no way to say we only want to
change advertised link modes.
Michal
^ permalink raw reply
* Re: stmmac / meson8b-dwmac
From: Simon Huelck @ 2019-02-24 20:34 UTC (permalink / raw)
To: Sebastian Gottschall, Jerome Brunet, Jose Abreu,
Martin Blumenstingl
Cc: linux-amlogic, Gpeppe.cavallaro, alexandre.torgue,
Emiliano Ingrassia, netdev
In-Reply-To: <f08f2659-dde0-41ec-9233-6b4d5f375ffe@newmedia-net.de>
Am 24.02.2019 um 20:42 schrieb Sebastian Gottschall:
> vice are you talking about? its not your windows pc. if its a ipq8064
> based device or something like that you should look
> on a very different location. this platform like the r7800 has stmac
> performance problems since the kernel clk code for this device is lets
> say "very wrong".
> so alot of clocks arent correct and so the ethernet performance will
> suffer.
>
> i can tell you that i'm able to get 930 mbit on a stmmac based device.
> but as i said. the kernel needs other numerous fixes to get a good
> performance
Hi,
the topic is about ODROID C2 / Amlogic S905X since the start. we have a
performance regression since 4.14.
regards,
Simon
^ permalink raw reply
* Re: [PATCH net-next] net: phy: let genphy_c45_read_abilities also check aneg capability
From: David Miller @ 2019-02-24 20:35 UTC (permalink / raw)
To: hkallweit1; +Cc: andrew, f.fainelli, netdev, maxime.chevallier
In-Reply-To: <a798f789-94a9-f1ac-1cba-276a2c517089@gmail.com>
From: Heiner Kallweit <hkallweit1@gmail.com>
Date: Fri, 22 Feb 2019 08:23:04 +0100
> When using genphy_c45_read_abilities() as get_features callback we
> also have to set the autoneg capability in phydev->supported.
>
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: marvell10g.c merge into net-next
From: Heiner Kallweit @ 2019-02-24 20:35 UTC (permalink / raw)
To: David Miller, Maxime Chevallier; +Cc: netdev
In-Reply-To: <20190224.121517.833334110230552517.davem@davemloft.net>
On 24.02.2019 21:15, David Miller wrote:
>
> Heiner, please look at net-next which I just merged net into.
>
> Net had a bug fix wherein the MDIO_AN_10GBT_CTRL_ADV_NBT_MASK
> bits are cleared in the 10gbt control register to work around
> a problem with some marvell10g phy chips.
>
> In the merge I preserved your usage of the generic c45 helpers
> in this area, but I suspect part of that will have to be undone
> in order to accomodate the above fix.
>
Thanks for the info. Let me add Maxime as author of the fix.
I think we talk about his one "net: phy: marvell10g:
Fix Multi-G advertisement to only advertise 10G" and we talk
about net-next.
IMO the proper way to fix this is removing the unsupported
modes from phydev->advertising in config_init.
Then mv3310_config_aneg doesn't have to be touched.
A similar exercise I did here:
0974f1f03b07 ("net: phy: aquantia: remove false 5G and 10G speed ability for AQCS109")
> Thanks.
>
Heiner
^ permalink raw reply
* Re: [PATCH][net-next] net: Use RCU_INIT_POINTER() to set sk_wq
From: David Miller @ 2019-02-24 20:37 UTC (permalink / raw)
To: lirongqing; +Cc: netdev
In-Reply-To: <1550826502-15554-1-git-send-email-lirongqing@baidu.com>
From: Li RongQing <lirongqing@baidu.com>
Date: Fri, 22 Feb 2019 17:08:22 +0800
> This pointer is RCU protected, so proper primitives should be used.
>
> Signed-off-by: Zhang Yu <zhangyu31@baidu.com>
> Signed-off-by: Li RongQing <lirongqing@baidu.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next v2 1/2] net: phylink: update mac_config() documentation
From: David Miller @ 2019-02-24 20:39 UTC (permalink / raw)
To: rmk+kernel; +Cc: linux-doc, netdev
In-Reply-To: <E1gx93N-00046w-6j@rmk-PC.armlinux.org.uk>
From: Russell King <rmk+kernel@armlinux.org.uk>
Date: Fri, 22 Feb 2019 11:31:41 +0000
> A detail for mac_config() had been missed in the documentation for the
> method - it is expected that the method will update the MAC to the
> settings, rather than completely reprogram the MAC on each call.
> Update the documentation for this method for this detail.
>
> Reviewed-by: Andrew Lunn <andrew@lunn.ch>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Applied.
^ permalink raw reply
* Re: [PATCH net-next v2 2/2] doc: add phylink documentation to the networking book
From: David Miller @ 2019-02-24 20:40 UTC (permalink / raw)
To: rmk+kernel; +Cc: linux-doc, netdev, corbet
In-Reply-To: <E1gx93S-00047E-CW@rmk-PC.armlinux.org.uk>
From: Russell King <rmk+kernel@armlinux.org.uk>
Date: Fri, 22 Feb 2019 11:31:46 +0000
> Add some phylink documentation to the networking book detailing how
> to convert network drivers from phylib to phylink.
>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
> ---
> v2: updated with comments from Randy and updated to apply to net-next
Applied.
^ permalink raw reply
* Re: [PATCH net-next] net: Skip GSO length estimation if transport header is not set
From: David Miller @ 2019-02-24 20:41 UTC (permalink / raw)
To: maximmi; +Cc: willemb, saeedm, jasowang, edumazet, netdev, eranbe, tariqt
In-Reply-To: <20190222125457.8509-1-maximmi@mellanox.com>
From: Maxim Mikityanskiy <maximmi@mellanox.com>
Date: Fri, 22 Feb 2019 12:55:22 +0000
> qdisc_pkt_len_init expects transport_header to be set for GSO packets.
> Patch [1] skips transport_header validation for GSO packets that don't
> have network_header set at the moment of calling virtio_net_hdr_to_skb,
> and allows them to pass into the stack. After patch [2] no placeholder
> value is assigned to transport_header if dissection fails, so this patch
> adds a check to the place where the value of transport_header is used.
>
> [1] https://patchwork.ozlabs.org/patch/1044429/
> [2] https://patchwork.ozlabs.org/patch/1046122/
>
> Signed-off-by: Maxim Mikityanskiy <maximmi@mellanox.com>
Applied, thanks Maxim.
^ permalink raw reply
* Re: [PATCH ethtool] ethtool: Add support for 200Gbps (50Gbps per lane) link mode
From: Andrew Lunn @ 2019-02-24 20:43 UTC (permalink / raw)
To: Michal Kubecek
Cc: Tariq Toukan, John W. Linville, netdev, Eran Ben Elisha,
Aya Levin
In-Reply-To: <20190224203333.GC1914@unicorn.suse.cz>
> > Hi Michal
> >
> > So are you doing a read/modify/write? In that case, off/on makes
> > sense. For a pure write, i don't see the need for off/on.
>
> When using netlink interface, the read/modify/write cycle is limited to
> kernel code and is done under rtnl_lock. The netlink interface allows
> userspace to send only attributes it wants to change and for bit sets
> (like link modes) to tell kernel which bits it wants to change so that
> there is no need to read current values first (and open a race window).
Nice.
But it would still be good to get feedback from people who use this
more often. I guess that is top of rack switches with all these odd
link modes.
Andrew
^ permalink raw reply
* Re: [PATCH net-next 0/8] Add tests for unlocked flower classifier implementation
From: David Miller @ 2019-02-24 20:50 UTC (permalink / raw)
To: vladbu
Cc: netdev, jhs, xiyou.wangcong, shuah, batuhanosmantaskaya, lucasb,
dcaratti, marcelo.leitner, chrism
In-Reply-To: <20190222140047.13215-1-vladbu@mellanox.com>
From: Vlad Buslov <vladbu@mellanox.com>
Date: Fri, 22 Feb 2019 16:00:39 +0200
> Implement tests for tdc testsuite to verify concurrent rules update with
> rtnl-unlocked flower classifier implementation. The goal of these tests
> is to verify general flower classifier correctness by updating filters
> on same classifier instance in parallel and to verify its atomicity by
> concurrently updating filters in same handle range. All three filter
> update operations (add, replace, delete) are tested.
>
> Existing script tdc_batch.py is re-used for batch file generation. It is
> extended with several optional CLI arguments that are needed for
> concurrency tests. Thin wrapper tdc_multibatch.py is implemented on top
> of tdc_batch.py to simplify its usage when generating multiple batch
> files for several test configurations.
>
> Parallelism in tests is implemented by running multiple instances of tc
> in batch mode with xargs tool. Xargs is chosen for its ease of use and
> because it is available by default on most modern Linux distributions.
Series applied, thanks Vlad.
^ permalink raw reply
* 32-bit Amlogic SoCs: avoid using Ethernet MAC addresses
From: Martin Blumenstingl @ 2019-02-24 20:55 UTC (permalink / raw)
To: linux.amoon, linux-amlogic; +Cc: netdev
I have seen Anand's your question in [0]:
> only issue is I have is the each time their is random MAC address so I
> get new IP from dhcp server.
> How can I avoid this. I have tried to enable eFuse driver but with no success.
u-boot on the 64-bit SoCs can read the MAC address from the eFuse and
pass it (via the .dtb) to the kernel.
This requires an ethernet0 alias in the mainline .dts though, see [1]
for and example.
I'm not sure if this also works with the older u-boot on the 32-bit SoCs.
if it doesn't then there's a nvmem-cells binding for all Ethernet
controllers: [2] (please note that the function implementing this
binding was recently renamed: [3])
as far as I can tell the stmmac driver doesn't support the nvmem-cells
based binding yet
Anand, if you want to work on this: feel free to do so!
I have the SDHC MMC driver and a discussion about the power-domain
drivers on my TODO-list, so I'm pretty busy at the moment.
Regards
Martin
[0] http://lists.infradead.org/pipermail/linux-amlogic/2019-February/010464.html
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f7c36209c46c4d162202b65eed2e66962ad8c3c1
[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9217e566bdee4583d0a9ea4879c8f5e004886eac
[3] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=afa64a72b862a7a9d04f8d07fba632eaf06b23f8
^ permalink raw reply
* Re: marvell10g.c merge into net-next
From: Maxime Chevallier @ 2019-02-24 20:56 UTC (permalink / raw)
To: Heiner Kallweit; +Cc: David Miller, netdev
In-Reply-To: <d6f79c5a-57c6-87e2-5408-b778f58838b3@gmail.com>
Hello Dave, Heiner,
On Sun, 24 Feb 2019 21:35:11 +0100
Heiner Kallweit <hkallweit1@gmail.com> wrote:
>On 24.02.2019 21:15, David Miller wrote:
>>
>> Heiner, please look at net-next which I just merged net into.
>>
>> Net had a bug fix wherein the MDIO_AN_10GBT_CTRL_ADV_NBT_MASK
>> bits are cleared in the 10gbt control register to work around
>> a problem with some marvell10g phy chips.
>>
>> In the merge I preserved your usage of the generic c45 helpers
>> in this area, but I suspect part of that will have to be undone
>> in order to accomodate the above fix.
>>
>Thanks for the info. Let me add Maxime as author of the fix.
>I think we talk about his one "net: phy: marvell10g:
>Fix Multi-G advertisement to only advertise 10G" and we talk
>about net-next.
>
>IMO the proper way to fix this is removing the unsupported
>modes from phydev->advertising in config_init.
>Then mv3310_config_aneg doesn't have to be touched.
>
>A similar exercise I did here:
>0974f1f03b07 ("net: phy: aquantia: remove false 5G and 10G speed ability for AQCS109")
From what I've seen and tested, the issue itself doesn't appear in
net-next, since mv3310_config_aneg calls the newly introduced
genphy_c45_an_config_aneg() which clears the 2.5G/5G advertising bits.
So the use of the generic C45 helpers should be enough to prevent the
issue from happening. The only difference really is that the -net patch
also masks the 2.5/5G Fast Retrain abilities, but this should make no
difference given that 2.5/5G are masked-out in both cases.
I'm sorry for the confusion, I wasn't sure how to deal with such a
scenario.
Thanks,
Maxime
--
Maxime Chevallier, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH net-next 0/3] net: protodown support for macvlan and vxlan
From: David Miller @ 2019-02-24 21:01 UTC (permalink / raw)
To: aroulin; +Cc: netdev, roopa
In-Reply-To: <20190222180638.10904-1-aroulin@cumulusnetworks.com>
From: Andy Roulin <aroulin@cumulusnetworks.com>
Date: Fri, 22 Feb 2019 18:06:35 +0000
> This patch series adds dev_change_proto_down_generic, a generic
> implementation of ndo_change_proto_down, which sets the netdev carrier
> state according to the new proto_down value.
>
> This handler adds the ability to set protodown on macvlan and vxlan
> interfaces in a generic way for use by control protocols like VRRPD.
>
> Patch (1) introduces the handler in net/code/dev.c. Patch (2) and (3) add
> support for change_proto_down in macvlan and vxlan drivers, respectively,
> using the new function.
Series applied.
^ permalink raw reply
* Re: [PATCH net-next 2/2] net: phy: aquantia: add hwmon support
From: Heiner Kallweit @ 2019-02-24 21:14 UTC (permalink / raw)
To: Andrew Lunn; +Cc: Florian Fainelli, David Miller, netdev@vger.kernel.org
In-Reply-To: <20190224202952.GA20855@lunn.ch>
On 24.02.2019 21:29, Andrew Lunn wrote:
>> diff --git a/drivers/net/phy/aquantia_hwmon.c b/drivers/net/phy/aquantia_hwmon.c
>> new file mode 100644
>> index 000000000..c0dd695f6
>> --- /dev/null
>> +++ b/drivers/net/phy/aquantia_hwmon.c
>> @@ -0,0 +1,263 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/* HWMON driver for Aquantia PHY
>> + *
>> + * Author: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
>> + * Author: Andrew Lunn <andrew@lunn.ch>
>> + * Author: Heiner Kallweit <hkallweit1@gmail.com>
>> + */
>> +
>> +#include <linux/phy.h>
>> +#include <linux/device.h>
>> +#include <linux/ctype.h>
>> +#include <linux/hwmon.h>
>> +
>> +#include "aquantia_hwmon.h"
>> +
>> +/* Vendor specific 1, MDIO_MMD_VEND1 */
>> +#define VEND1_THERMAL_PROV_HIGH_TEMP_FAIL 0xc421
>> +#define VEND1_THERMAL_PROV_LOW_TEMP_FAIL 0xc422
>> +#define VEND1_THERMAL_PROV_HIGH_TEMP_WARN 0xc423
>> +#define VEND1_THERMAL_PROV_LOW_TEMP_WARN 0xc424
>> +#define VEND1_THERMAL_STAT1 0xc820
>> +#define VEND1_THERMAL_STAT2 0xc821
>> +#define VEND1_THERMAL_STAT2_VALID BIT(0)
>> +#define VEND1_GENERAL_STAT1 0xc830
>> +#define VEND1_GENERAL_STAT1_HIGH_TEMP_FAIL BIT(14)
>> +#define VEND1_GENERAL_STAT1_LOW_TEMP_FAIL BIT(13)
>> +#define VEND1_GENERAL_STAT1_HIGH_TEMP_WARN BIT(12)
>> +#define VEND1_GENERAL_STAT1_LOW_TEMP_WARN BIT(11)
>> +
>> +struct aqr_priv {
>> + struct device *hwmon_dev;
>> + char *hwmon_name;
>> +};
>
> Hi Heiner
>
> It seems a bit odd having the driver private structure here. I expect
> with time we are going to need other things in it which are not
> HWMON. e.g many of the statistics counters are clear on read. So we
> need to keep the running totals somewhere.
>
> I would keep the probe code and the allocation of this structure in
> the main driver file.
>
I just see that we don't need struct aqr_priv at all for hwmon
because it uses device-managed versions of the relevant functions.
So we can add such a struct when it's actually needed.
> Andrew
>
Heiner
^ permalink raw reply
* Re: No traffic with Marvell switch and latest linux-next
From: Florian Fainelli @ 2019-02-24 21:26 UTC (permalink / raw)
To: Andrew Lunn
Cc: Russell King - ARM Linux admin, Heiner Kallweit,
netdev@vger.kernel.org
In-Reply-To: <20190224170455.GH26626@lunn.ch>
On February 24, 2019 9:04:55 AM PST, Andrew Lunn <andrew@lunn.ch> wrote:
>> The added difficulty here and the reason why Andrew went with the
>> approach that is used by the code currently is because neither do the
>> CPU or DSA ports are backed by a net_device. It is somewhere on my
>TODO
>> to permit the use of PHYLINK without the need of a net_device to
>cover
>> those specific DSA cases unless we just brute force the whole thing
>and
>> allocate a net_device structure but not register that net_device? Yes
>in
>> fact, why don't we do that?
>
>Hi Florian
>
>At the moment, we are using a phydev which is not connected to a
>MAC. That is rather odd, but the phylib maintainers mostly know about
>this, and keep an eye out for changes which might break any
>assumptions. And the phylib API is quite small.
I would argue that this very thread is a proof against your argument since we all failed to predict that Heiner's changes would change those assumptions. Having a certain of assumptions is fine but given all the recent PHYLIB helpers that have been added I am not sure how well that will scale.
>
>How many assumptions are going to break with a netdev which is not
>registered? The API is much bigger, more people hack on it, and it is
>going to be much harder to review changes to make sure assumptions are
>not changed.
A non registered net_device appears easier to manage and debug since there is state tracking all over the network stack for those cases.
>
>If we are going to do something odd, we should keep the scope as small
>as possible.
Hence my suggestion to allocate a dummy net_device object just so calls to netif_carrier_{on,off} (and possibly more in the future) do nothing. I don't think that teaching either PHYLIB or PHYLINK about a NULL net_device is going to scale really well over time nor make it easier for respective maintainers. If we make the net_device optional, it will be harder to review changes as well as make sure that we do not create locking/object interactions issues.
Another approach could be to define a minimal network port object (struct devlink, maybe?) which could be used independently from a net_device, or a lightweight net_device with no visibility into existing namespaces. None of these ideas are new though and would probably require several cycles to get done right.
Heiner, Russell, which approach would you take?
--
Florian
^ permalink raw reply
* [PATCH net-next v2 0/2] net: phy: aquantia: add hwmon support
From: Heiner Kallweit @ 2019-02-24 21:34 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, David Miller; +Cc: netdev@vger.kernel.org
This series adds HWMON support for the temperature sensor and the
related alarms on the 107/108/109 chips.
v2:
- remove struct aqr_priv
- rename header file to aquantia.h
Heiner Kallweit (2):
net: phy: aquantia: rename aquantia.c to aquantia_main.c
net: phy: aquantia: add hwmon support
drivers/net/phy/Makefile | 1 +
drivers/net/phy/aquantia.h | 16 ++
drivers/net/phy/aquantia_hwmon.c | 245 ++++++++++++++++++
.../net/phy/{aquantia.c => aquantia_main.c} | 4 +
4 files changed, 266 insertions(+)
create mode 100644 drivers/net/phy/aquantia.h
create mode 100644 drivers/net/phy/aquantia_hwmon.c
rename drivers/net/phy/{aquantia.c => aquantia_main.c} (99%)
--
2.20.1
^ permalink raw reply
* [PATCH net-next v2 1/2] net: phy: aquantia: rename aquantia.c to aquantia_main.c
From: Heiner Kallweit @ 2019-02-24 21:35 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, David Miller; +Cc: netdev@vger.kernel.org
In-Reply-To: <a12e48d8-f274-c4e0-3232-ee8d32975a65@gmail.com>
Rename aquantia.c to aquantia_main.c to be prepared for adding new
functionality to separate source code files.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
drivers/net/phy/Makefile | 1 +
drivers/net/phy/{aquantia.c => aquantia_main.c} | 0
2 files changed, 1 insertion(+)
rename drivers/net/phy/{aquantia.c => aquantia_main.c} (100%)
diff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile
index 5805c0b7d..b0845adaf 100644
--- a/drivers/net/phy/Makefile
+++ b/drivers/net/phy/Makefile
@@ -45,6 +45,7 @@ sfp-obj-$(CONFIG_SFP) += sfp-bus.o
obj-y += $(sfp-obj-y) $(sfp-obj-m)
obj-$(CONFIG_AMD_PHY) += amd.o
+aquantia-objs += aquantia_main.o
obj-$(CONFIG_AQUANTIA_PHY) += aquantia.o
obj-$(CONFIG_ASIX_PHY) += asix.o
obj-$(CONFIG_AT803X_PHY) += at803x.o
diff --git a/drivers/net/phy/aquantia.c b/drivers/net/phy/aquantia_main.c
similarity index 100%
rename from drivers/net/phy/aquantia.c
rename to drivers/net/phy/aquantia_main.c
--
2.20.1
^ permalink raw reply related
* [PATCH net-next v2 2/2] net: phy: aquantia: add hwmon support
From: Heiner Kallweit @ 2019-02-24 21:36 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, David Miller; +Cc: netdev@vger.kernel.org
In-Reply-To: <a12e48d8-f274-c4e0-3232-ee8d32975a65@gmail.com>
This adds HWMON support for the temperature sensor and the related
alarms on the 107/108/109 chips. This patch is based on work from
Nikita and Andrew. I added:
- support for changing alarm thresholds via sysfs
- move HWMON code to a separate source file to improve maintainability
- smaller changes like using IS_REACHABLE instead of ifdef
(avoids problems if PHY driver is built in and HWMON is a module)
v2:
- remove struct aqr_priv
- rename header file to aquantia.h
Signed-off-by: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
drivers/net/phy/Makefile | 2 +-
drivers/net/phy/aquantia.h | 16 ++
drivers/net/phy/aquantia_hwmon.c | 245 +++++++++++++++++++++++++++++++
drivers/net/phy/aquantia_main.c | 4 +
4 files changed, 266 insertions(+), 1 deletion(-)
create mode 100644 drivers/net/phy/aquantia.h
create mode 100644 drivers/net/phy/aquantia_hwmon.c
diff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile
index b0845adaf..c48596626 100644
--- a/drivers/net/phy/Makefile
+++ b/drivers/net/phy/Makefile
@@ -45,7 +45,7 @@ sfp-obj-$(CONFIG_SFP) += sfp-bus.o
obj-y += $(sfp-obj-y) $(sfp-obj-m)
obj-$(CONFIG_AMD_PHY) += amd.o
-aquantia-objs += aquantia_main.o
+aquantia-objs += aquantia_main.o aquantia_hwmon.o
obj-$(CONFIG_AQUANTIA_PHY) += aquantia.o
obj-$(CONFIG_ASIX_PHY) += asix.o
obj-$(CONFIG_AT803X_PHY) += at803x.o
diff --git a/drivers/net/phy/aquantia.h b/drivers/net/phy/aquantia.h
new file mode 100644
index 000000000..5a16caab7
--- /dev/null
+++ b/drivers/net/phy/aquantia.h
@@ -0,0 +1,16 @@
+/* SPDX-License-Identifier: GPL-2.0
+ * HWMON driver for Aquantia PHY
+ *
+ * Author: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
+ * Author: Andrew Lunn <andrew@lunn.ch>
+ * Author: Heiner Kallweit <hkallweit1@gmail.com>
+ */
+
+#include <linux/device.h>
+#include <linux/phy.h>
+
+#if IS_REACHABLE(CONFIG_HWMON)
+int aqr_hwmon_probe(struct phy_device *phydev);
+#else
+static inline int aqr_hwmon_probe(struct phy_device *phydev) { return 0; }
+#endif
diff --git a/drivers/net/phy/aquantia_hwmon.c b/drivers/net/phy/aquantia_hwmon.c
new file mode 100644
index 000000000..9c77d149e
--- /dev/null
+++ b/drivers/net/phy/aquantia_hwmon.c
@@ -0,0 +1,245 @@
+// SPDX-License-Identifier: GPL-2.0
+/* HWMON driver for Aquantia PHY
+ *
+ * Author: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
+ * Author: Andrew Lunn <andrew@lunn.ch>
+ * Author: Heiner Kallweit <hkallweit1@gmail.com>
+ */
+
+#include <linux/phy.h>
+#include <linux/device.h>
+#include <linux/ctype.h>
+#include <linux/hwmon.h>
+
+#include "aquantia.h"
+
+/* Vendor specific 1, MDIO_MMD_VEND2 */
+#define VEND1_THERMAL_PROV_HIGH_TEMP_FAIL 0xc421
+#define VEND1_THERMAL_PROV_LOW_TEMP_FAIL 0xc422
+#define VEND1_THERMAL_PROV_HIGH_TEMP_WARN 0xc423
+#define VEND1_THERMAL_PROV_LOW_TEMP_WARN 0xc424
+#define VEND1_THERMAL_STAT1 0xc820
+#define VEND1_THERMAL_STAT2 0xc821
+#define VEND1_THERMAL_STAT2_VALID BIT(0)
+#define VEND1_GENERAL_STAT1 0xc830
+#define VEND1_GENERAL_STAT1_HIGH_TEMP_FAIL BIT(14)
+#define VEND1_GENERAL_STAT1_LOW_TEMP_FAIL BIT(13)
+#define VEND1_GENERAL_STAT1_HIGH_TEMP_WARN BIT(12)
+#define VEND1_GENERAL_STAT1_LOW_TEMP_WARN BIT(11)
+
+#if IS_REACHABLE(CONFIG_HWMON)
+
+static umode_t aqr_hwmon_is_visible(const void *data,
+ enum hwmon_sensor_types type,
+ u32 attr, int channel)
+{
+ if (type != hwmon_temp)
+ return 0;
+
+ switch (attr) {
+ case hwmon_temp_input:
+ case hwmon_temp_min_alarm:
+ case hwmon_temp_max_alarm:
+ case hwmon_temp_lcrit_alarm:
+ case hwmon_temp_crit_alarm:
+ return 0444;
+ case hwmon_temp_min:
+ case hwmon_temp_max:
+ case hwmon_temp_lcrit:
+ case hwmon_temp_crit:
+ return 0644;
+ default:
+ return 0;
+ }
+}
+
+static int aqr_hwmon_get(struct phy_device *phydev, int reg, long *value)
+{
+ int temp = phy_read_mmd(phydev, MDIO_MMD_VEND1, reg);
+
+ if (temp < 0)
+ return temp;
+
+ /* register value is 2's complement with LSB = 1/256th degree Celsius */
+ if (temp > 0x8000)
+ temp -= 0x10000;
+
+ *value = temp * 1000 / 256;
+
+ return 0;
+}
+
+static int aqr_hwmon_set(struct phy_device *phydev, int reg, long value)
+{
+ int temp;
+
+ if (value >= 128000 || value < -128000)
+ return -ERANGE;
+
+ temp = value * 256 / 1000;
+
+ if (temp < 0)
+ temp += 0x10000;
+
+ return phy_write_mmd(phydev, MDIO_MMD_VEND1, reg, temp);
+}
+
+static int aqr_hwmon_status1(struct phy_device *phydev, int bit, long *value)
+{
+ int reg = phy_read_mmd(phydev, MDIO_MMD_VEND1, VEND1_GENERAL_STAT1);
+
+ if (reg < 0)
+ return reg;
+
+ *value = !!(reg & bit);
+
+ return 0;
+}
+
+static int aqr_hwmon_read(struct device *dev, enum hwmon_sensor_types type,
+ u32 attr, int channel, long *value)
+{
+ struct phy_device *phydev = dev_get_drvdata(dev);
+ int reg;
+
+ if (type != hwmon_temp)
+ return -EOPNOTSUPP;
+
+ switch (attr) {
+ case hwmon_temp_input:
+ reg = phy_read_mmd(phydev, MDIO_MMD_VEND1,
+ VEND1_THERMAL_STAT2);
+ if (reg < 0)
+ return reg;
+ if (!(reg & VEND1_THERMAL_STAT2_VALID))
+ return -EIO;
+
+ return aqr_hwmon_get(phydev, VEND1_THERMAL_STAT1, value);
+
+ case hwmon_temp_lcrit:
+ return aqr_hwmon_get(phydev, VEND1_THERMAL_PROV_LOW_TEMP_FAIL,
+ value);
+ case hwmon_temp_min:
+ return aqr_hwmon_get(phydev, VEND1_THERMAL_PROV_LOW_TEMP_WARN,
+ value);
+ case hwmon_temp_max:
+ return aqr_hwmon_get(phydev, VEND1_THERMAL_PROV_HIGH_TEMP_WARN,
+ value);
+ case hwmon_temp_crit:
+ return aqr_hwmon_get(phydev, VEND1_THERMAL_PROV_HIGH_TEMP_FAIL,
+ value);
+ case hwmon_temp_lcrit_alarm:
+ return aqr_hwmon_status1(phydev,
+ VEND1_GENERAL_STAT1_LOW_TEMP_FAIL,
+ value);
+ case hwmon_temp_min_alarm:
+ return aqr_hwmon_status1(phydev,
+ VEND1_GENERAL_STAT1_LOW_TEMP_WARN,
+ value);
+ case hwmon_temp_max_alarm:
+ return aqr_hwmon_status1(phydev,
+ VEND1_GENERAL_STAT1_HIGH_TEMP_WARN,
+ value);
+ case hwmon_temp_crit_alarm:
+ return aqr_hwmon_status1(phydev,
+ VEND1_GENERAL_STAT1_HIGH_TEMP_FAIL,
+ value);
+ default:
+ return -EOPNOTSUPP;
+ }
+}
+
+static int aqr_hwmon_write(struct device *dev, enum hwmon_sensor_types type,
+ u32 attr, int channel, long value)
+{
+ struct phy_device *phydev = dev_get_drvdata(dev);
+
+ if (type != hwmon_temp)
+ return -EOPNOTSUPP;
+
+ switch (attr) {
+ case hwmon_temp_lcrit:
+ return aqr_hwmon_set(phydev, VEND1_THERMAL_PROV_LOW_TEMP_FAIL,
+ value);
+ case hwmon_temp_min:
+ return aqr_hwmon_set(phydev, VEND1_THERMAL_PROV_LOW_TEMP_WARN,
+ value);
+ case hwmon_temp_max:
+ return aqr_hwmon_set(phydev, VEND1_THERMAL_PROV_HIGH_TEMP_WARN,
+ value);
+ case hwmon_temp_crit:
+ return aqr_hwmon_set(phydev, VEND1_THERMAL_PROV_HIGH_TEMP_FAIL,
+ value);
+ default:
+ return -EOPNOTSUPP;
+ }
+}
+
+static const struct hwmon_ops aqr_hwmon_ops = {
+ .is_visible = aqr_hwmon_is_visible,
+ .read = aqr_hwmon_read,
+ .write = aqr_hwmon_write,
+};
+
+static u32 aqr_hwmon_chip_config[] = {
+ HWMON_C_REGISTER_TZ,
+ 0,
+};
+
+static const struct hwmon_channel_info aqr_hwmon_chip = {
+ .type = hwmon_chip,
+ .config = aqr_hwmon_chip_config,
+};
+
+static u32 aqr_hwmon_temp_config[] = {
+ HWMON_T_INPUT |
+ 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,
+ 0,
+};
+
+static const struct hwmon_channel_info aqr_hwmon_temp = {
+ .type = hwmon_temp,
+ .config = aqr_hwmon_temp_config,
+};
+
+static const struct hwmon_channel_info *aqr_hwmon_info[] = {
+ &aqr_hwmon_chip,
+ &aqr_hwmon_temp,
+ NULL,
+};
+
+static const struct hwmon_chip_info aqr_hwmon_chip_info = {
+ .ops = &aqr_hwmon_ops,
+ .info = aqr_hwmon_info,
+};
+
+int aqr_hwmon_probe(struct phy_device *phydev)
+{
+ struct device *dev = &phydev->mdio.dev;
+ struct device *hwmon_dev;
+ char *hwmon_name;
+ int i, j;
+
+ hwmon_name = devm_kstrdup(dev, dev_name(dev), GFP_KERNEL);
+ if (!hwmon_name)
+ return -ENOMEM;
+
+ for (i = j = 0; hwmon_name[i]; i++) {
+ if (isalnum(hwmon_name[i])) {
+ if (i != j)
+ hwmon_name[j] = hwmon_name[i];
+ j++;
+ }
+ }
+ hwmon_name[j] = '\0';
+
+ hwmon_dev = devm_hwmon_device_register_with_info(dev, hwmon_name,
+ phydev, &aqr_hwmon_chip_info, NULL);
+
+ return PTR_ERR_OR_ZERO(hwmon_dev);
+}
+
+#endif
diff --git a/drivers/net/phy/aquantia_main.c b/drivers/net/phy/aquantia_main.c
index 0f0eb5682..37218e5d7 100644
--- a/drivers/net/phy/aquantia_main.c
+++ b/drivers/net/phy/aquantia_main.c
@@ -12,6 +12,8 @@
#include <linux/delay.h>
#include <linux/phy.h>
+#include "aquantia.h"
+
#define PHY_ID_AQ1202 0x03a1b445
#define PHY_ID_AQ2104 0x03a1b460
#define PHY_ID_AQR105 0x03a1b4a2
@@ -231,6 +233,7 @@ static struct phy_driver aqr_driver[] = {
.name = "Aquantia AQR107",
.aneg_done = genphy_c45_aneg_done,
.get_features = genphy_c45_pma_read_abilities,
+ .probe = aqr_hwmon_probe,
.config_aneg = aqr_config_aneg,
.config_intr = aqr_config_intr,
.ack_interrupt = aqr_ack_interrupt,
@@ -241,6 +244,7 @@ static struct phy_driver aqr_driver[] = {
.name = "Aquantia AQCS109",
.aneg_done = genphy_c45_aneg_done,
.get_features = genphy_c45_pma_read_abilities,
+ .probe = aqr_hwmon_probe,
.config_init = aqcs109_config_init,
.config_aneg = aqr_config_aneg,
.config_intr = aqr_config_intr,
--
2.20.1
^ permalink raw reply related
* Re: No traffic with Marvell switch and latest linux-next
From: Heiner Kallweit @ 2019-02-24 21:42 UTC (permalink / raw)
To: Florian Fainelli, Andrew Lunn
Cc: Russell King - ARM Linux admin, netdev@vger.kernel.org
In-Reply-To: <2B512084-E971-482D-81FC-B3CEEC1C26C5@gmail.com>
On 24.02.2019 22:26, Florian Fainelli wrote:
>
>
> On February 24, 2019 9:04:55 AM PST, Andrew Lunn <andrew@lunn.ch> wrote:
>>> The added difficulty here and the reason why Andrew went with the
>>> approach that is used by the code currently is because neither do the
>>> CPU or DSA ports are backed by a net_device. It is somewhere on my
>> TODO
>>> to permit the use of PHYLINK without the need of a net_device to
>> cover
>>> those specific DSA cases unless we just brute force the whole thing
>> and
>>> allocate a net_device structure but not register that net_device? Yes
>> in
>>> fact, why don't we do that?
>>
>> Hi Florian
>>
>> At the moment, we are using a phydev which is not connected to a
>> MAC. That is rather odd, but the phylib maintainers mostly know about
>> this, and keep an eye out for changes which might break any
>> assumptions. And the phylib API is quite small.
>
> I would argue that this very thread is a proof against your argument since we all failed to predict that Heiner's changes would change those assumptions. Having a certain of assumptions is fine but given all the recent PHYLIB helpers that have been added I am not sure how well that will scale.
>
>>
>> How many assumptions are going to break with a netdev which is not
>> registered? The API is much bigger, more people hack on it, and it is
>> going to be much harder to review changes to make sure assumptions are
>> not changed.
>
> A non registered net_device appears easier to manage and debug since there is state tracking all over the network stack for those cases.
>
>>
>> If we are going to do something odd, we should keep the scope as small
>> as possible.
>
> Hence my suggestion to allocate a dummy net_device object just so calls to netif_carrier_{on,off} (and possibly more in the future) do nothing. I don't think that teaching either PHYLIB or PHYLINK about a NULL net_device is going to scale really well over time nor make it easier for respective maintainers. If we make the net_device optional, it will be harder to review changes as well as make sure that we do not create locking/object interactions issues.
>
> Another approach could be to define a minimal network port object (struct devlink, maybe?) which could be used independently from a net_device, or a lightweight net_device with no visibility into existing namespaces. None of these ideas are new though and would probably require several cycles to get done right.
>
> Heiner, Russell, which approach would you take?
>
Given my 2 days of experience with DSA (feels like 3 already) I would like to spend few more minutes on thinking before I answer.
Heiner
^ permalink raw reply
* Re: [PATCH net-next 2/2] net: phy: aquantia: add hwmon support
From: Andrew Lunn @ 2019-02-24 21:46 UTC (permalink / raw)
To: Heiner Kallweit; +Cc: Florian Fainelli, David Miller, netdev@vger.kernel.org
In-Reply-To: <d934bb9a-5edc-6a51-3012-aab9c7d40768@gmail.com>
> I just see that we don't need struct aqr_priv at all for hwmon
> because it uses device-managed versions of the relevant functions.
> So we can add such a struct when it's actually needed.
Hi Heiner
Yes, i had not noticed that.
Andrew
^ permalink raw reply
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