This small series add LEDs support for qca808x.
Qca808x apply on PHY reset a strange polarity settings and require
some tweak to apply a more common configuration found on devices.
On adding support for it, it was pointed out that a similar
feature is also being implemented for a marvell PHY where
LED polarity is set per LED (and not global) and also have
a special mode where the LED is tristated.
The first 2 patch are to generalize this as we expect more PHY
in the future to have a similar configuration.
The implementation is extensible to support additional special
mode in the future with minimal changes and don't create regression
on already implemented PHY drivers.
(changelog present in single patch)
Christian Marangi (4):
dt-bindings: net: phy: Document new LEDs polarity property
net: phy: add support for PHY LEDs polarity modes
dt-bindings: net: Document QCA808x PHYs
net: phy: at803x: add LED support for qca808x
.../devicetree/bindings/net/ethernet-phy.yaml | 11 +
.../devicetree/bindings/net/qca,qca808x.yaml | 54 +++
drivers/net/phy/at803x.c | 308 ++++++++++++++++++
drivers/net/phy/phy_device.c | 45 +++
include/linux/phy.h | 25 ++
5 files changed, 443 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/qca,qca808x.yaml
--
2.40.1
Document new LEDs polarity property to define what mode the LED needs to
be put to turn it on.
Currently supported modes are:
- active-low
- active-high
- active-low-tristate
- active-high-tristate
Mode is optional and if it's not defined, a default value is chosed by
the driver.
Signed-off-by: Christian Marangi <[email protected]>
---
Changes v4:
- Drop support for global active-low
- Rework to polarity option (for marvell10g series support)
Changes v3:
- Out of RFC
Changes v2:
- Add this patch
.../devicetree/bindings/net/ethernet-phy.yaml | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/ethernet-phy.yaml b/Documentation/devicetree/bindings/net/ethernet-phy.yaml
index 8fb2a6ee7e5b..282bf18f50fd 100644
--- a/Documentation/devicetree/bindings/net/ethernet-phy.yaml
+++ b/Documentation/devicetree/bindings/net/ethernet-phy.yaml
@@ -225,6 +225,17 @@ properties:
driver dependent and required for ports that define multiple
LED for the same port.
+ polarity:
+ description: |
+ Electrical polarity and drive type for the LED to turn it
+ on.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum:
+ - active-low
+ - active-high
+ - active-low-tristate
+ - active-high-tristate
+
required:
- reg
--
2.40.1
Add support for PHY LEDs polarity modes. Some device might require
special polarity mode for the LED to correctly work and those mode
doesn't reflect what the PHY sets by default.
An example is a PHY device that set LED to active high but the attached
LEDs require to be active low to correctly work (and turn on when
actually requested)
PHY driver needs to declare .led_polarity_set() to configure LED
polarity. Index of the LED is passed and the polarity mode in the enum.
If a polarity is not set in DT and .led_polarity_set() is declared,
PHY_LED_POLARITY_DEFAULT is passed as polarity mode to let the PHY
driver decide a default polarity mode for the attached LEDs.
This is needed for PHY that sets active high on reset and the common
configuration is LEDs with active low polarity.
Signed-off-by: Christian Marangi <[email protected]>
---
Changes v4:
- Drop for global active-low
- Rework to polarity option (for marvell10g series support)
Changes v3:
- Out of RFC
Changes v2:
- Add this patch
drivers/net/phy/phy_device.c | 45 ++++++++++++++++++++++++++++++++++++
include/linux/phy.h | 25 ++++++++++++++++++++
2 files changed, 70 insertions(+)
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index d8e9335d415c..b35b7a8717cc 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -43,6 +43,13 @@ MODULE_DESCRIPTION("PHY library");
MODULE_AUTHOR("Andy Fleming");
MODULE_LICENSE("GPL");
+static const char * const phy_led_polarity_mode_strings[] = {
+ [PHY_LED_POLARITY_ACTIVE_LOW] = "active-low",
+ [PHY_LED_POLARITY_ACTIVE_HIGH] = "active-high",
+ [PHY_LED_POLARITY_ACTIVE_LOW_TRISTATED] = "active-low-tristated",
+ [PHY_LED_POLARITY_ACTIVE_HIGH_TRISTATED] = "active-low-tristated",
+};
+
__ETHTOOL_DECLARE_LINK_MODE_MASK(phy_basic_features) __ro_after_init;
EXPORT_SYMBOL_GPL(phy_basic_features);
@@ -3086,6 +3093,40 @@ static void phy_leds_unregister(struct phy_device *phydev)
}
}
+static int of_phy_set_led_polarity(struct phy_device *phydev,
+ struct device_node *led, u32 index)
+{
+ const char *polarity_str;
+ int i, err;
+
+ err = of_property_read_string(led, "polarity", &polarity_str);
+ if (err) {
+ if (err != -EINVAL)
+ return err;
+
+ /* Nothing to do, polarity setting not supported */
+ if (!phydev->drv->led_polarity_set)
+ return 0;
+
+ /* Apply default polarity if supported */
+ return phydev->drv->led_polarity_set(phydev, index,
+ PHY_LED_POLARITY_DEFAULT);
+ }
+
+ for (i = 0; i < ARRAY_SIZE(phy_led_polarity_mode_strings); i++)
+ if (!strcmp(phy_led_polarity_mode_strings[i], polarity_str)) {
+ if (!phydev->drv->led_polarity_set) {
+ phydev_warn(phydev, "Ignoring LED polarity in DT. Setting polarity not supported\n");
+ return 0;
+ }
+
+ return phydev->drv->led_polarity_set(phydev, index, i);
+ }
+
+ /* Unknown polarity mode declared */
+ return -EINVAL;
+}
+
static int of_phy_led(struct phy_device *phydev,
struct device_node *led)
{
@@ -3109,6 +3150,10 @@ static int of_phy_led(struct phy_device *phydev,
if (index > U8_MAX)
return -EINVAL;
+ err = of_phy_set_led_polarity(phydev, led, index);
+ if (err)
+ return err;
+
phyled->index = index;
if (phydev->drv->led_brightness_set)
cdev->brightness_set_blocking = phy_led_set_brightness;
diff --git a/include/linux/phy.h b/include/linux/phy.h
index 6e7ebcc50b85..88ff4195bc4f 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -852,6 +852,16 @@ struct phy_plca_status {
bool pst;
};
+enum phy_led_polarity_modes {
+ PHY_LED_POLARITY_ACTIVE_LOW,
+ PHY_LED_POLARITY_ACTIVE_HIGH,
+ PHY_LED_POLARITY_ACTIVE_LOW_TRISTATED,
+ PHY_LED_POLARITY_ACTIVE_HIGH_TRISTATED,
+
+ /* PHY driver apply a default value */
+ PHY_LED_POLARITY_DEFAULT,
+};
+
/**
* struct phy_led: An LED driven by the PHY
*
@@ -1145,6 +1155,21 @@ struct phy_driver {
int (*led_hw_control_get)(struct phy_device *dev, u8 index,
unsigned long *rules);
+ /**
+ * @led_polarity_set: Set the LED polarity mode
+ * @dev: PHY device which has the LED
+ * @index: Which LED of the PHY device
+ * @polarity_mode: LED polarity mode from enum
+ *
+ * Set PHY to requested LED polarity mode.
+ *
+ * If polarity mode PHY_LED_POLARITY_DEFAULT is passed,
+ * PHY driver should apply a default LED polarity mode.
+ *
+ * Returns 0, or an error code.
+ */
+ int (*led_polarity_set)(struct phy_device *dev, int index,
+ enum phy_led_polarity_modes polarity_mode);
};
#define to_phy_driver(d) container_of(to_mdio_common_driver(d), \
struct phy_driver, mdiodrv)
--
2.40.1
Add Documentation for QCA808x PHYs for the additional LED configuration
for this PHY.
Signed-off-by: Christian Marangi <[email protected]>
Reviewed-by: Rob Herring <[email protected]>
---
Changes v4:
- Add Reviewed-by tag
Changes v3:
- Use compatible instead of select
- Out of RFC
Changes v2:
- Fix License warning from checkpatch
- Drop redundant Description phrase
- Improve commit tile
- Drop special property (generalized)
.../devicetree/bindings/net/qca,qca808x.yaml | 54 +++++++++++++++++++
1 file changed, 54 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/qca,qca808x.yaml
diff --git a/Documentation/devicetree/bindings/net/qca,qca808x.yaml b/Documentation/devicetree/bindings/net/qca,qca808x.yaml
new file mode 100644
index 000000000000..e2552655902a
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/qca,qca808x.yaml
@@ -0,0 +1,54 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/qca,qca808x.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Atheros QCA808X PHY
+
+maintainers:
+ - Christian Marangi <[email protected]>
+
+description:
+ QCA808X PHYs can have up to 3 LEDs attached.
+ All 3 LEDs are disabled by default.
+ 2 LEDs have dedicated pins with the 3rd LED having the
+ double function of Interrupt LEDs/GPIO or additional LED.
+
+ By default this special PIN is set to LED function.
+
+allOf:
+ - $ref: ethernet-phy.yaml#
+
+properties:
+ compatible:
+ enum:
+ - ethernet-phy-id004d.d101
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/leds/common.h>
+
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethernet-phy@0 {
+ compatible = "ethernet-phy-id004d.d101";
+ reg = <0>;
+
+ leds {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ led@0 {
+ reg = <0>;
+ color = <LED_COLOR_ID_GREEN>;
+ function = LED_FUNCTION_WAN;
+ default-state = "keep";
+ };
+ };
+ };
+ };
--
2.40.1
Add LED support for QCA8081 PHY.
Documentation for this LEDs PHY is very scarce even with NDA access
to Documentation for OEMs. Only the blink pattern are documented and are
very confusing most of the time. No documentation is present about
forcing the LED on/off or to always blink.
Those settings were reversed by poking the regs and trying to find the
correct bits to trigger these modes. Some bits mode are not clear and
maybe the documentation option are not 100% correct. For the sake of LED
support the reversed option are enough to add support for current LED
APIs.
Supported HW control modes are:
- tx
- rx
- link10
- link100
- link1000
- half_duplex
- full_duplex
Also add support for LED polarity set to set LED polarity to active
high or low. QSDK sets this value to high by default but PHY reset value
doesn't have this enabled by default.
QSDK also sets 2 additional bits but their usage is not clear, info about
this is added in the header. It was verified that for correct function
of the LED if active high is needed, only BIT 6 is needed.
Signed-off-by: Christian Marangi <[email protected]>
---
Changes v4:
- Rework to polarity option (for marvell10g series support)
- Rework logic to enforce single PHY polarity mode
Changes v3:
- Out of RFC
- Drop link_25000 and add TODO commends waiting for the
netdev trigger thing to be merged (I will take care of
sending a followup patch later)
Changes v2:
- Move to new led_polarity_set implementation
- Drop special probe
drivers/net/phy/at803x.c | 308 +++++++++++++++++++++++++++++++++++++++
1 file changed, 308 insertions(+)
diff --git a/drivers/net/phy/at803x.c b/drivers/net/phy/at803x.c
index b9d3a26cf6dc..d36d3bea4739 100644
--- a/drivers/net/phy/at803x.c
+++ b/drivers/net/phy/at803x.c
@@ -272,6 +272,69 @@
#define QCA808X_CDT_STATUS_STAT_OPEN 2
#define QCA808X_CDT_STATUS_STAT_SHORT 3
+#define QCA808X_MMD7_LED2_CTRL 0x8074
+#define QCA808X_MMD7_LED2_FORCE_CTRL 0x8075
+#define QCA808X_MMD7_LED1_CTRL 0x8076
+#define QCA808X_MMD7_LED1_FORCE_CTRL 0x8077
+#define QCA808X_MMD7_LED0_CTRL 0x8078
+#define QCA808X_MMD7_LED_CTRL(x) (0x8078 - ((x) * 2))
+
+/* LED hw control pattern is the same for every LED */
+#define QCA808X_LED_PATTERN_MASK GENMASK(15, 0)
+#define QCA808X_LED_SPEED2500_ON BIT(15)
+#define QCA808X_LED_SPEED2500_BLINK BIT(14)
+/* Follow blink trigger even if duplex or speed condition doesn't match */
+#define QCA808X_LED_BLINK_CHECK_BYPASS BIT(13)
+#define QCA808X_LED_FULL_DUPLEX_ON BIT(12)
+#define QCA808X_LED_HALF_DUPLEX_ON BIT(11)
+#define QCA808X_LED_TX_BLINK BIT(10)
+#define QCA808X_LED_RX_BLINK BIT(9)
+#define QCA808X_LED_TX_ON_10MS BIT(8)
+#define QCA808X_LED_RX_ON_10MS BIT(7)
+#define QCA808X_LED_SPEED1000_ON BIT(6)
+#define QCA808X_LED_SPEED100_ON BIT(5)
+#define QCA808X_LED_SPEED10_ON BIT(4)
+#define QCA808X_LED_COLLISION_BLINK BIT(3)
+#define QCA808X_LED_SPEED1000_BLINK BIT(2)
+#define QCA808X_LED_SPEED100_BLINK BIT(1)
+#define QCA808X_LED_SPEED10_BLINK BIT(0)
+
+#define QCA808X_MMD7_LED0_FORCE_CTRL 0x8079
+#define QCA808X_MMD7_LED_FORCE_CTRL(x) (0x8079 - ((x) * 2))
+
+/* LED force ctrl is the same for every LED
+ * No documentation exist for this, not even internal one
+ * with NDA as QCOM gives only info about configuring
+ * hw control pattern rules and doesn't indicate any way
+ * to force the LED to specific mode.
+ * These define comes from reverse and testing and maybe
+ * lack of some info or some info are not entirely correct.
+ * For the basic LED control and hw control these finding
+ * are enough to support LED control in all the required APIs.
+ */
+#define QCA808X_LED_FORCE_MASK GENMASK(15, 13)
+#define QCA808X_LED_FORCE_BLINK_8HZ FIELD_PREP(QCA808X_LED_FORCE_MASK, 0x7)
+#define QCA808X_LED_FORCE_BLINK_4HZ FIELD_PREP(QCA808X_LED_FORCE_MASK, 0x6)
+#define QCA808X_LED_FORCE_ON FIELD_PREP(QCA808X_LED_FORCE_MASK, 0x5)
+#define QCA808X_LED_FORCE_OFF FIELD_PREP(QCA808X_LED_FORCE_MASK, 0x4)
+/* HW control option are confusing:
+ * - 0x3 is 50% on 50% off at 4hz
+ * - 0x2 is 75% on 25% off at 4hz
+ * - 0x1 is 25% on 75% off at 4hz
+ * - 0x0 is 50% on 50% off at 8hz and is set by default
+ * This comes from visual check and may not be 100% correct.
+ */
+#define QCA808X_LED_HW_CONTROL_50_50_4HZ FIELD_PREP(QCA808X_LED_FORCE_MASK, 0x3)
+#define QCA808X_LED_HW_CONTROL_75_25 FIELD_PREP(QCA808X_LED_FORCE_MASK, 0x2)
+#define QCA808X_LED_HW_CONTROL_25_75 FIELD_PREP(QCA808X_LED_FORCE_MASK, 0x1)
+#define QCA808X_LED_HW_CONTROL_50_50_8HZ FIELD_PREP(QCA808X_LED_FORCE_MASK, 0x0)
+
+#define QCA808X_MMD7_LED_POLARITY_CTRL 0x901a
+/* QSDK sets by default 0x46 to this reg that sets BIT 6 for
+ * LED to active high. It's not clear what BIT 3 and BIT 4 does.
+ */
+#define QCA808X_LED_ACTIVE_HIGH BIT(6)
+
/* QCA808X 1G chip type */
#define QCA808X_PHY_MMD7_CHIP_TYPE 0x901d
#define QCA808X_PHY_CHIP_TYPE_1G BIT(0)
@@ -312,6 +375,7 @@ struct at803x_priv {
struct regulator_dev *vddio_rdev;
struct regulator_dev *vddh_rdev;
u64 stats[ARRAY_SIZE(qca83xx_hw_stats)];
+ int led_polarity_mode;
};
struct at803x_context {
@@ -672,6 +736,9 @@ static int at803x_probe(struct phy_device *phydev)
if (!priv)
return -ENOMEM;
+ /* Init LED polarity mode to -1 */
+ priv->led_polarity_mode = -1;
+
phydev->priv = priv;
ret = at803x_parse_dt(phydev);
@@ -2128,6 +2195,241 @@ static void qca808x_link_change_notify(struct phy_device *phydev)
QCA8081_PHY_FIFO_RSTN, phydev->link ? QCA8081_PHY_FIFO_RSTN : 0);
}
+static int qca808x_led_parse_netdev(struct phy_device *phydev, unsigned long rules,
+ u16 *offload_trigger)
+{
+ /* TODO: add link_2500 when added to netdev trigger */
+ /* Parsing specific to netdev trigger */
+ if (test_bit(TRIGGER_NETDEV_TX, &rules))
+ *offload_trigger |= QCA808X_LED_TX_BLINK;
+ if (test_bit(TRIGGER_NETDEV_RX, &rules))
+ *offload_trigger |= QCA808X_LED_RX_BLINK;
+ if (test_bit(TRIGGER_NETDEV_LINK_10, &rules))
+ *offload_trigger |= QCA808X_LED_SPEED10_ON;
+ if (test_bit(TRIGGER_NETDEV_LINK_100, &rules))
+ *offload_trigger |= QCA808X_LED_SPEED100_ON;
+ if (test_bit(TRIGGER_NETDEV_LINK_1000, &rules))
+ *offload_trigger |= QCA808X_LED_SPEED1000_ON;
+ if (test_bit(TRIGGER_NETDEV_HALF_DUPLEX, &rules))
+ *offload_trigger |= QCA808X_LED_HALF_DUPLEX_ON;
+ if (test_bit(TRIGGER_NETDEV_FULL_DUPLEX, &rules))
+ *offload_trigger |= QCA808X_LED_FULL_DUPLEX_ON;
+
+ if (rules && !*offload_trigger)
+ return -EOPNOTSUPP;
+
+ /* Enable BLINK_CHECK_BYPASS by default to make the LED
+ * blink even with duplex or speed mode not enabled.
+ */
+ *offload_trigger |= QCA808X_LED_BLINK_CHECK_BYPASS;
+
+ return 0;
+}
+
+static int qca808x_led_hw_control_enable(struct phy_device *phydev, u8 index)
+{
+ u16 reg;
+
+ if (index > 2)
+ return -EINVAL;
+
+ reg = QCA808X_MMD7_LED_FORCE_CTRL(index);
+
+ return phy_clear_bits_mmd(phydev, MDIO_MMD_AN, reg,
+ QCA808X_LED_FORCE_MASK);
+}
+
+static int qca808x_led_hw_is_supported(struct phy_device *phydev, u8 index,
+ unsigned long rules)
+{
+ u16 offload_trigger = 0;
+
+ if (index > 2)
+ return -EINVAL;
+
+ return qca808x_led_parse_netdev(phydev, rules, &offload_trigger);
+}
+
+static int qca808x_led_hw_control_set(struct phy_device *phydev, u8 index,
+ unsigned long rules)
+{
+ u16 reg, offload_trigger = 0;
+ int ret;
+
+ if (index > 2)
+ return -EINVAL;
+
+ reg = QCA808X_MMD7_LED_CTRL(index);
+
+ ret = qca808x_led_parse_netdev(phydev, rules, &offload_trigger);
+ if (ret)
+ return ret;
+
+ ret = qca808x_led_hw_control_enable(phydev, index);
+ if (ret)
+ return ret;
+
+ return phy_modify_mmd(phydev, MDIO_MMD_AN, reg,
+ QCA808X_LED_PATTERN_MASK,
+ offload_trigger);
+}
+
+static bool qca808x_led_hw_control_status(struct phy_device *phydev, u8 index)
+{
+ u16 reg;
+ int val;
+
+ if (index > 2)
+ return false;
+
+ reg = QCA808X_MMD7_LED_FORCE_CTRL(index);
+
+ val = phy_read_mmd(phydev, MDIO_MMD_AN, reg);
+
+ return !(val & QCA808X_LED_FORCE_MASK);
+}
+
+static int qca808x_led_hw_control_get(struct phy_device *phydev, u8 index,
+ unsigned long *rules)
+{
+ u16 reg;
+ int val;
+
+ if (index > 2)
+ return -EINVAL;
+
+ /* Check if we have hw control enabled */
+ if (qca808x_led_hw_control_status(phydev, index))
+ return -EINVAL;
+
+ reg = QCA808X_MMD7_LED_CTRL(index);
+
+ /* TODO: add link_2500 when added to netdev trigger */
+ val = phy_read_mmd(phydev, MDIO_MMD_AN, reg);
+ if (val & QCA808X_LED_TX_BLINK)
+ set_bit(TRIGGER_NETDEV_TX, rules);
+ if (val & QCA808X_LED_RX_BLINK)
+ set_bit(TRIGGER_NETDEV_RX, rules);
+ if (val & QCA808X_LED_SPEED10_ON)
+ set_bit(TRIGGER_NETDEV_LINK_10, rules);
+ if (val & QCA808X_LED_SPEED100_ON)
+ set_bit(TRIGGER_NETDEV_LINK_100, rules);
+ if (val & QCA808X_LED_SPEED1000_ON)
+ set_bit(TRIGGER_NETDEV_LINK_1000, rules);
+ if (val & QCA808X_LED_HALF_DUPLEX_ON)
+ set_bit(TRIGGER_NETDEV_HALF_DUPLEX, rules);
+ if (val & QCA808X_LED_FULL_DUPLEX_ON)
+ set_bit(TRIGGER_NETDEV_FULL_DUPLEX, rules);
+
+ return 0;
+}
+
+static int qca808x_led_hw_control_reset(struct phy_device *phydev, u8 index)
+{
+ u16 reg;
+
+ if (index > 2)
+ return -EINVAL;
+
+ reg = QCA808X_MMD7_LED_CTRL(index);
+
+ return phy_clear_bits_mmd(phydev, MDIO_MMD_AN, reg,
+ QCA808X_LED_PATTERN_MASK);
+}
+
+static int qca808x_led_brightness_set(struct phy_device *phydev,
+ u8 index, enum led_brightness value)
+{
+ u16 reg;
+ int ret;
+
+ if (index > 2)
+ return -EINVAL;
+
+ if (!value) {
+ ret = qca808x_led_hw_control_reset(phydev, index);
+ if (ret)
+ return ret;
+ }
+
+ reg = QCA808X_MMD7_LED_FORCE_CTRL(index);
+
+ return phy_modify_mmd(phydev, MDIO_MMD_AN, reg,
+ QCA808X_LED_FORCE_MASK,
+ value ? QCA808X_LED_FORCE_ON :
+ QCA808X_LED_FORCE_OFF);
+}
+
+static int qca808x_led_blink_set(struct phy_device *phydev, u8 index,
+ unsigned long *delay_on,
+ unsigned long *delay_off)
+{
+ u16 reg;
+ int ret;
+
+ if (index > 2)
+ return -EINVAL;
+
+ reg = QCA808X_MMD7_LED_FORCE_CTRL(index);
+
+ ret = phy_modify_mmd(phydev, MDIO_MMD_AN, reg,
+ QCA808X_LED_FORCE_MASK,
+ QCA808X_LED_FORCE_BLINK_4HZ);
+ if (ret)
+ return ret;
+
+ /* We set blink to 4Hz, aka 250ms */
+ *delay_on = 250 / 2;
+ *delay_off = 250 / 2;
+
+ return 0;
+}
+
+static int qca808x_led_polarity_set(struct phy_device *phydev, int index,
+ enum phy_led_polarity_modes polarity_mode)
+{
+ struct at803x_priv *priv = phydev->priv;
+ bool active_low;
+ int ret;
+
+ switch (polarity_mode) {
+ case PHY_LED_POLARITY_ACTIVE_LOW:
+ active_low = true;
+ break;
+ case PHY_LED_POLARITY_ACTIVE_HIGH:
+ case PHY_LED_POLARITY_DEFAULT:
+ active_low = false;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ /* PHY polarity is global and can't be set per LED.
+ * To detect this, check if last requested polarity mode
+ * match the new one.
+ */
+ if (priv->led_polarity_mode >= 0 &&
+ priv->led_polarity_mode != active_low) {
+ phydev_err(phydev, "PHY polarity is global. Mismatched polarity on different LED\n");
+ return -EINVAL;
+ }
+
+ /* Save the last PHY polarity mode */
+ priv->led_polarity_mode = active_low;
+
+ if (active_low) {
+ ret = phy_clear_bits_mmd(phydev, MDIO_MMD_AN,
+ QCA808X_MMD7_LED_POLARITY_CTRL,
+ QCA808X_LED_ACTIVE_HIGH);
+ } else {
+ ret = phy_set_bits_mmd(phydev, MDIO_MMD_AN,
+ QCA808X_MMD7_LED_POLARITY_CTRL,
+ QCA808X_LED_ACTIVE_HIGH);
+ }
+
+ return ret;
+}
+
static struct phy_driver at803x_driver[] = {
{
/* Qualcomm Atheros AR8035 */
@@ -2304,6 +2606,12 @@ static struct phy_driver at803x_driver[] = {
.cable_test_start = qca808x_cable_test_start,
.cable_test_get_status = qca808x_cable_test_get_status,
.link_change_notify = qca808x_link_change_notify,
+ .led_brightness_set = qca808x_led_brightness_set,
+ .led_blink_set = qca808x_led_blink_set,
+ .led_hw_is_supported = qca808x_led_hw_is_supported,
+ .led_hw_control_set = qca808x_led_hw_control_set,
+ .led_hw_control_get = qca808x_led_hw_control_get,
+ .led_polarity_set = qca808x_led_polarity_set,
}, };
module_phy_driver(at803x_driver);
--
2.40.1
On Fri, Dec 15, 2023 at 10:22:41PM +0100, Christian Marangi wrote:
> Document new LEDs polarity property to define what mode the LED needs to
> be put to turn it on.
>
> Currently supported modes are:
>
> - active-low
> - active-high
> - active-low-tristate
> - active-high-tristate
Why is having a polarity unique to LEDs on ethernet PHYs? It's not. We
already have 'active-low' established on several LED bindings. Please
move the definition to leds/common.yaml and extend it. I would simply
add an 'inactive-tristate' boolean property (if there's an actual user).
I do worry this continues to evolve until we've re-created the pinctrl
binding...
Rob
On Wed, Dec 20, 2023 at 09:22:09AM -0600, Rob Herring wrote:
> On Fri, Dec 15, 2023 at 10:22:41PM +0100, Christian Marangi wrote:
> > Document new LEDs polarity property to define what mode the LED needs to
> > be put to turn it on.
> >
> > Currently supported modes are:
> >
> > - active-low
> > - active-high
> > - active-low-tristate
> > - active-high-tristate
>
> Why is having a polarity unique to LEDs on ethernet PHYs? It's not. We
> already have 'active-low' established on several LED bindings. Please
> move the definition to leds/common.yaml and extend it. I would simply
> add an 'inactive-tristate' boolean property (if there's an actual user).
>
Should I also drop the active-low from the current schema that have it?
Also we have led-active-low. (should we support both?)
On the marvell10g series we are discussing of using tristate or not. We
notice tristate might be confusing, would it be better to use
inactive-high-impedance ?
> I do worry this continues to evolve until we've re-created the pinctrl
> binding...
>
--
Ansuel
> I do worry this continues to evolve until we've re-created the pinctrl
> binding...
Hi Rob
What is you opinion of the pinctrl binding? Should we just copy parts
of it?
Andrew
> On the marvell10g series we are discussing of using tristate or not. We
> notice tristate might be confusing, would it be better to use
> inactive-high-impedance ?
The pincfg-node.yaml binding has:
drive-open-drain:
oneOf:
- type: boolean
- $ref: /schemas/types.yaml#/definitions/uint32
const: 1 # No known cases of 0
deprecated: true
description: drive with open drain
drive-open-source:
type: boolean
description: drive with open source
I'm not sure what the deprecated means. Is it that a value is
deprecated, not the property as a whole?
Andrew
On Thu, Dec 21, 2023 at 10:43:17AM +0100, Andrew Lunn wrote:
> > On the marvell10g series we are discussing of using tristate or not. We
> > notice tristate might be confusing, would it be better to use
> > inactive-high-impedance ?
>
> The pincfg-node.yaml binding has:
>
> drive-open-drain:
> oneOf:
> - type: boolean
> - $ref: /schemas/types.yaml#/definitions/uint32
> const: 1 # No known cases of 0
> deprecated: true
> description: drive with open drain
>
> drive-open-source:
> type: boolean
> description: drive with open source
>
> I'm not sure what the deprecated means. Is it that a value is
> deprecated, not the property as a whole?
Yeah, it means that only the boolean form of this property should be
used going forward.
The comment suggests that the value had no meaning in the first place,
and that testing for presence alone has been sufficient all along.
On Thu, Dec 21, 2023 at 10:34:41AM +0100, Andrew Lunn wrote:
> > I do worry this continues to evolve until we've re-created the pinctrl
> > binding...
>
> Hi Rob
>
> What is you opinion of the pinctrl binding? Should we just copy parts
> of it?
>
Hi,
I have the new series ready but I'm not sure pincfg-node have useful
property.
What we should use from there? From what I can see only output-low would
be useful to us. I didn't find a way to handle the inactive mode.
Should I send the new series so we can continue the discussion there or
better to wait for Rob feedback?
--
Ansuel