2022-01-28 03:05:02 -03:00
|
|
|
// SPDX-License-Identifier: GPL-2.0+
|
|
|
|
/* Realtek MDIO interface driver
|
|
|
|
*
|
|
|
|
* ASICs we intend to support with this driver:
|
|
|
|
*
|
|
|
|
* RTL8366 - The original version, apparently
|
|
|
|
* RTL8369 - Similar enough to have the same datsheet as RTL8366
|
|
|
|
* RTL8366RB - Probably reads out "RTL8366 revision B", has a quite
|
|
|
|
* different register layout from the other two
|
|
|
|
* RTL8366S - Is this "RTL8366 super"?
|
|
|
|
* RTL8367 - Has an OpenWRT driver as well
|
|
|
|
* RTL8368S - Seems to be an alternative name for RTL8366RB
|
|
|
|
* RTL8370 - Also uses SMI
|
|
|
|
*
|
|
|
|
* Copyright (C) 2017 Linus Walleij <linus.walleij@linaro.org>
|
|
|
|
* Copyright (C) 2010 Antti Seppälä <a.seppala@gmail.com>
|
|
|
|
* Copyright (C) 2010 Roman Yeryomin <roman@advem.lv>
|
|
|
|
* Copyright (C) 2011 Colin Leitner <colin.leitner@googlemail.com>
|
|
|
|
* Copyright (C) 2009-2010 Gabor Juhos <juhosg@openwrt.org>
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <linux/module.h>
|
2023-07-24 15:18:58 -06:00
|
|
|
#include <linux/of.h>
|
2023-03-23 11:37:35 +01:00
|
|
|
#include <linux/overflow.h>
|
2022-01-28 03:05:02 -03:00
|
|
|
#include <linux/regmap.h>
|
|
|
|
|
|
|
|
#include "realtek.h"
|
2024-02-09 02:03:39 -03:00
|
|
|
#include "realtek-mdio.h"
|
2022-01-28 03:05:02 -03:00
|
|
|
|
|
|
|
/* Read/write via mdiobus */
|
|
|
|
#define REALTEK_MDIO_CTRL0_REG 31
|
|
|
|
#define REALTEK_MDIO_START_REG 29
|
|
|
|
#define REALTEK_MDIO_CTRL1_REG 21
|
|
|
|
#define REALTEK_MDIO_ADDRESS_REG 23
|
|
|
|
#define REALTEK_MDIO_DATA_WRITE_REG 24
|
|
|
|
#define REALTEK_MDIO_DATA_READ_REG 25
|
|
|
|
|
|
|
|
#define REALTEK_MDIO_START_OP 0xFFFF
|
|
|
|
#define REALTEK_MDIO_ADDR_OP 0x000E
|
|
|
|
#define REALTEK_MDIO_READ_OP 0x0001
|
|
|
|
#define REALTEK_MDIO_WRITE_OP 0x0003
|
|
|
|
|
|
|
|
static int realtek_mdio_write(void *ctx, u32 reg, u32 val)
|
|
|
|
{
|
|
|
|
struct realtek_priv *priv = ctx;
|
|
|
|
struct mii_bus *bus = priv->bus;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
mutex_lock(&bus->mdio_lock);
|
|
|
|
|
|
|
|
ret = bus->write(bus, priv->mdio_addr, REALTEK_MDIO_CTRL0_REG, REALTEK_MDIO_ADDR_OP);
|
|
|
|
if (ret)
|
|
|
|
goto out_unlock;
|
|
|
|
|
|
|
|
ret = bus->write(bus, priv->mdio_addr, REALTEK_MDIO_ADDRESS_REG, reg);
|
|
|
|
if (ret)
|
|
|
|
goto out_unlock;
|
|
|
|
|
|
|
|
ret = bus->write(bus, priv->mdio_addr, REALTEK_MDIO_DATA_WRITE_REG, val);
|
|
|
|
if (ret)
|
|
|
|
goto out_unlock;
|
|
|
|
|
|
|
|
ret = bus->write(bus, priv->mdio_addr, REALTEK_MDIO_CTRL1_REG, REALTEK_MDIO_WRITE_OP);
|
|
|
|
|
|
|
|
out_unlock:
|
|
|
|
mutex_unlock(&bus->mdio_lock);
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int realtek_mdio_read(void *ctx, u32 reg, u32 *val)
|
|
|
|
{
|
|
|
|
struct realtek_priv *priv = ctx;
|
|
|
|
struct mii_bus *bus = priv->bus;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
mutex_lock(&bus->mdio_lock);
|
|
|
|
|
|
|
|
ret = bus->write(bus, priv->mdio_addr, REALTEK_MDIO_CTRL0_REG, REALTEK_MDIO_ADDR_OP);
|
|
|
|
if (ret)
|
|
|
|
goto out_unlock;
|
|
|
|
|
|
|
|
ret = bus->write(bus, priv->mdio_addr, REALTEK_MDIO_ADDRESS_REG, reg);
|
|
|
|
if (ret)
|
|
|
|
goto out_unlock;
|
|
|
|
|
|
|
|
ret = bus->write(bus, priv->mdio_addr, REALTEK_MDIO_CTRL1_REG, REALTEK_MDIO_READ_OP);
|
|
|
|
if (ret)
|
|
|
|
goto out_unlock;
|
|
|
|
|
|
|
|
ret = bus->read(bus, priv->mdio_addr, REALTEK_MDIO_DATA_READ_REG);
|
|
|
|
if (ret >= 0) {
|
|
|
|
*val = ret;
|
|
|
|
ret = 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
out_unlock:
|
|
|
|
mutex_unlock(&bus->mdio_lock);
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
net: dsa: realtek: allow subdrivers to externally lock regmap
Currently there is no way for Realtek DSA subdrivers to serialize
consecutive regmap accesses. In preparation for a bugfix relating to
indirect PHY register access - which involves a series of regmap
reads and writes - add a facility for subdrivers to serialize their
regmap access.
Specifically, a mutex is added to the driver private data structure and
the standard regmap is initialized with custom lock/unlock ops which use
this mutex. Then, a "nolock" variant of the regmap is added, which is
functionally equivalent to the existing regmap except that regmap
locking is disabled. Functions that wish to serialize a sequence of
regmap accesses may then lock the newly introduced driver-owned mutex
before using the nolock regmap.
Doing things this way means that subdriver code that doesn't care about
serialized register access - i.e. the vast majority of code - needn't
worry about synchronizing register access with an external lock: it can
just continue to use the original regmap.
Another advantage of this design is that, while regmaps with locking
disabled do not expose a debugfs interface for obvious reasons, there
still exists the original regmap which does expose this interface. This
interface remains safe to use even combined with driver codepaths that
use the nolock regmap, because said codepaths will use the same mutex
to synchronize access.
With respect to disadvantages, it can be argued that having
near-duplicate regmaps is confusing. However, the naming is rather
explicit, and examples will abound.
Finally, while we are at it, rename realtek_smi_mdio_regmap_config to
realtek_smi_regmap_config. This makes it consistent with the naming
realtek_mdio_regmap_config in realtek-mdio.c.
Signed-off-by: Alvin Šipraga <alsi@bang-olufsen.dk>
Reviewed-by: Vladimir Oltean <olteanv@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-21 19:46:30 +01:00
|
|
|
static void realtek_mdio_lock(void *ctx)
|
|
|
|
{
|
|
|
|
struct realtek_priv *priv = ctx;
|
|
|
|
|
|
|
|
mutex_lock(&priv->map_lock);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void realtek_mdio_unlock(void *ctx)
|
|
|
|
{
|
|
|
|
struct realtek_priv *priv = ctx;
|
|
|
|
|
|
|
|
mutex_unlock(&priv->map_lock);
|
|
|
|
}
|
|
|
|
|
2022-01-28 03:05:02 -03:00
|
|
|
static const struct regmap_config realtek_mdio_regmap_config = {
|
|
|
|
.reg_bits = 10, /* A4..A0 R4..R0 */
|
|
|
|
.val_bits = 16,
|
|
|
|
.reg_stride = 1,
|
|
|
|
/* PHY regs are at 0x8000 */
|
|
|
|
.max_register = 0xffff,
|
|
|
|
.reg_format_endian = REGMAP_ENDIAN_BIG,
|
|
|
|
.reg_read = realtek_mdio_read,
|
|
|
|
.reg_write = realtek_mdio_write,
|
|
|
|
.cache_type = REGCACHE_NONE,
|
net: dsa: realtek: allow subdrivers to externally lock regmap
Currently there is no way for Realtek DSA subdrivers to serialize
consecutive regmap accesses. In preparation for a bugfix relating to
indirect PHY register access - which involves a series of regmap
reads and writes - add a facility for subdrivers to serialize their
regmap access.
Specifically, a mutex is added to the driver private data structure and
the standard regmap is initialized with custom lock/unlock ops which use
this mutex. Then, a "nolock" variant of the regmap is added, which is
functionally equivalent to the existing regmap except that regmap
locking is disabled. Functions that wish to serialize a sequence of
regmap accesses may then lock the newly introduced driver-owned mutex
before using the nolock regmap.
Doing things this way means that subdriver code that doesn't care about
serialized register access - i.e. the vast majority of code - needn't
worry about synchronizing register access with an external lock: it can
just continue to use the original regmap.
Another advantage of this design is that, while regmaps with locking
disabled do not expose a debugfs interface for obvious reasons, there
still exists the original regmap which does expose this interface. This
interface remains safe to use even combined with driver codepaths that
use the nolock regmap, because said codepaths will use the same mutex
to synchronize access.
With respect to disadvantages, it can be argued that having
near-duplicate regmaps is confusing. However, the naming is rather
explicit, and examples will abound.
Finally, while we are at it, rename realtek_smi_mdio_regmap_config to
realtek_smi_regmap_config. This makes it consistent with the naming
realtek_mdio_regmap_config in realtek-mdio.c.
Signed-off-by: Alvin Šipraga <alsi@bang-olufsen.dk>
Reviewed-by: Vladimir Oltean <olteanv@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-21 19:46:30 +01:00
|
|
|
.lock = realtek_mdio_lock,
|
|
|
|
.unlock = realtek_mdio_unlock,
|
|
|
|
};
|
|
|
|
|
|
|
|
static const struct regmap_config realtek_mdio_nolock_regmap_config = {
|
|
|
|
.reg_bits = 10, /* A4..A0 R4..R0 */
|
|
|
|
.val_bits = 16,
|
|
|
|
.reg_stride = 1,
|
|
|
|
/* PHY regs are at 0x8000 */
|
|
|
|
.max_register = 0xffff,
|
|
|
|
.reg_format_endian = REGMAP_ENDIAN_BIG,
|
|
|
|
.reg_read = realtek_mdio_read,
|
|
|
|
.reg_write = realtek_mdio_write,
|
|
|
|
.cache_type = REGCACHE_NONE,
|
|
|
|
.disable_locking = true,
|
2022-01-28 03:05:02 -03:00
|
|
|
};
|
|
|
|
|
2024-02-09 02:03:39 -03:00
|
|
|
/**
|
|
|
|
* realtek_mdio_probe() - Probe a platform device for an MDIO-connected switch
|
|
|
|
* @mdiodev: mdio_device to probe on.
|
|
|
|
*
|
|
|
|
* This function should be used as the .probe in an mdio_driver. It
|
|
|
|
* initializes realtek_priv and read data from the device-tree node. The switch
|
|
|
|
* is hard reset if a method is provided. It checks the switch chip ID and,
|
|
|
|
* finally, a DSA switch is registered.
|
|
|
|
*
|
|
|
|
* Context: Can sleep. Takes and releases priv->map_lock.
|
|
|
|
* Return: Returns 0 on success, a negative error on failure.
|
|
|
|
*/
|
|
|
|
int realtek_mdio_probe(struct mdio_device *mdiodev)
|
2022-01-28 03:05:02 -03:00
|
|
|
{
|
|
|
|
struct realtek_priv *priv;
|
|
|
|
struct device *dev = &mdiodev->dev;
|
|
|
|
const struct realtek_variant *var;
|
net: dsa: realtek: allow subdrivers to externally lock regmap
Currently there is no way for Realtek DSA subdrivers to serialize
consecutive regmap accesses. In preparation for a bugfix relating to
indirect PHY register access - which involves a series of regmap
reads and writes - add a facility for subdrivers to serialize their
regmap access.
Specifically, a mutex is added to the driver private data structure and
the standard regmap is initialized with custom lock/unlock ops which use
this mutex. Then, a "nolock" variant of the regmap is added, which is
functionally equivalent to the existing regmap except that regmap
locking is disabled. Functions that wish to serialize a sequence of
regmap accesses may then lock the newly introduced driver-owned mutex
before using the nolock regmap.
Doing things this way means that subdriver code that doesn't care about
serialized register access - i.e. the vast majority of code - needn't
worry about synchronizing register access with an external lock: it can
just continue to use the original regmap.
Another advantage of this design is that, while regmaps with locking
disabled do not expose a debugfs interface for obvious reasons, there
still exists the original regmap which does expose this interface. This
interface remains safe to use even combined with driver codepaths that
use the nolock regmap, because said codepaths will use the same mutex
to synchronize access.
With respect to disadvantages, it can be argued that having
near-duplicate regmaps is confusing. However, the naming is rather
explicit, and examples will abound.
Finally, while we are at it, rename realtek_smi_mdio_regmap_config to
realtek_smi_regmap_config. This makes it consistent with the naming
realtek_mdio_regmap_config in realtek-mdio.c.
Signed-off-by: Alvin Šipraga <alsi@bang-olufsen.dk>
Reviewed-by: Vladimir Oltean <olteanv@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-21 19:46:30 +01:00
|
|
|
struct regmap_config rc;
|
2022-01-28 03:05:02 -03:00
|
|
|
struct device_node *np;
|
net: dsa: realtek: allow subdrivers to externally lock regmap
Currently there is no way for Realtek DSA subdrivers to serialize
consecutive regmap accesses. In preparation for a bugfix relating to
indirect PHY register access - which involves a series of regmap
reads and writes - add a facility for subdrivers to serialize their
regmap access.
Specifically, a mutex is added to the driver private data structure and
the standard regmap is initialized with custom lock/unlock ops which use
this mutex. Then, a "nolock" variant of the regmap is added, which is
functionally equivalent to the existing regmap except that regmap
locking is disabled. Functions that wish to serialize a sequence of
regmap accesses may then lock the newly introduced driver-owned mutex
before using the nolock regmap.
Doing things this way means that subdriver code that doesn't care about
serialized register access - i.e. the vast majority of code - needn't
worry about synchronizing register access with an external lock: it can
just continue to use the original regmap.
Another advantage of this design is that, while regmaps with locking
disabled do not expose a debugfs interface for obvious reasons, there
still exists the original regmap which does expose this interface. This
interface remains safe to use even combined with driver codepaths that
use the nolock regmap, because said codepaths will use the same mutex
to synchronize access.
With respect to disadvantages, it can be argued that having
near-duplicate regmaps is confusing. However, the naming is rather
explicit, and examples will abound.
Finally, while we are at it, rename realtek_smi_mdio_regmap_config to
realtek_smi_regmap_config. This makes it consistent with the naming
realtek_mdio_regmap_config in realtek-mdio.c.
Signed-off-by: Alvin Šipraga <alsi@bang-olufsen.dk>
Reviewed-by: Vladimir Oltean <olteanv@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-21 19:46:30 +01:00
|
|
|
int ret;
|
2022-01-28 03:05:02 -03:00
|
|
|
|
|
|
|
var = of_device_get_match_data(dev);
|
|
|
|
if (!var)
|
|
|
|
return -EINVAL;
|
|
|
|
|
2023-03-23 11:37:35 +01:00
|
|
|
priv = devm_kzalloc(&mdiodev->dev,
|
|
|
|
size_add(sizeof(*priv), var->chip_data_sz),
|
|
|
|
GFP_KERNEL);
|
2022-01-28 03:05:02 -03:00
|
|
|
if (!priv)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
net: dsa: realtek: allow subdrivers to externally lock regmap
Currently there is no way for Realtek DSA subdrivers to serialize
consecutive regmap accesses. In preparation for a bugfix relating to
indirect PHY register access - which involves a series of regmap
reads and writes - add a facility for subdrivers to serialize their
regmap access.
Specifically, a mutex is added to the driver private data structure and
the standard regmap is initialized with custom lock/unlock ops which use
this mutex. Then, a "nolock" variant of the regmap is added, which is
functionally equivalent to the existing regmap except that regmap
locking is disabled. Functions that wish to serialize a sequence of
regmap accesses may then lock the newly introduced driver-owned mutex
before using the nolock regmap.
Doing things this way means that subdriver code that doesn't care about
serialized register access - i.e. the vast majority of code - needn't
worry about synchronizing register access with an external lock: it can
just continue to use the original regmap.
Another advantage of this design is that, while regmaps with locking
disabled do not expose a debugfs interface for obvious reasons, there
still exists the original regmap which does expose this interface. This
interface remains safe to use even combined with driver codepaths that
use the nolock regmap, because said codepaths will use the same mutex
to synchronize access.
With respect to disadvantages, it can be argued that having
near-duplicate regmaps is confusing. However, the naming is rather
explicit, and examples will abound.
Finally, while we are at it, rename realtek_smi_mdio_regmap_config to
realtek_smi_regmap_config. This makes it consistent with the naming
realtek_mdio_regmap_config in realtek-mdio.c.
Signed-off-by: Alvin Šipraga <alsi@bang-olufsen.dk>
Reviewed-by: Vladimir Oltean <olteanv@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-21 19:46:30 +01:00
|
|
|
mutex_init(&priv->map_lock);
|
|
|
|
|
|
|
|
rc = realtek_mdio_regmap_config;
|
|
|
|
rc.lock_arg = priv;
|
|
|
|
priv->map = devm_regmap_init(dev, NULL, priv, &rc);
|
2022-01-28 03:05:02 -03:00
|
|
|
if (IS_ERR(priv->map)) {
|
|
|
|
ret = PTR_ERR(priv->map);
|
|
|
|
dev_err(dev, "regmap init failed: %d\n", ret);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
net: dsa: realtek: allow subdrivers to externally lock regmap
Currently there is no way for Realtek DSA subdrivers to serialize
consecutive regmap accesses. In preparation for a bugfix relating to
indirect PHY register access - which involves a series of regmap
reads and writes - add a facility for subdrivers to serialize their
regmap access.
Specifically, a mutex is added to the driver private data structure and
the standard regmap is initialized with custom lock/unlock ops which use
this mutex. Then, a "nolock" variant of the regmap is added, which is
functionally equivalent to the existing regmap except that regmap
locking is disabled. Functions that wish to serialize a sequence of
regmap accesses may then lock the newly introduced driver-owned mutex
before using the nolock regmap.
Doing things this way means that subdriver code that doesn't care about
serialized register access - i.e. the vast majority of code - needn't
worry about synchronizing register access with an external lock: it can
just continue to use the original regmap.
Another advantage of this design is that, while regmaps with locking
disabled do not expose a debugfs interface for obvious reasons, there
still exists the original regmap which does expose this interface. This
interface remains safe to use even combined with driver codepaths that
use the nolock regmap, because said codepaths will use the same mutex
to synchronize access.
With respect to disadvantages, it can be argued that having
near-duplicate regmaps is confusing. However, the naming is rather
explicit, and examples will abound.
Finally, while we are at it, rename realtek_smi_mdio_regmap_config to
realtek_smi_regmap_config. This makes it consistent with the naming
realtek_mdio_regmap_config in realtek-mdio.c.
Signed-off-by: Alvin Šipraga <alsi@bang-olufsen.dk>
Reviewed-by: Vladimir Oltean <olteanv@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2022-02-21 19:46:30 +01:00
|
|
|
rc = realtek_mdio_nolock_regmap_config;
|
|
|
|
priv->map_nolock = devm_regmap_init(dev, NULL, priv, &rc);
|
|
|
|
if (IS_ERR(priv->map_nolock)) {
|
|
|
|
ret = PTR_ERR(priv->map_nolock);
|
|
|
|
dev_err(dev, "regmap init failed: %d\n", ret);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2022-01-28 03:05:02 -03:00
|
|
|
priv->mdio_addr = mdiodev->addr;
|
|
|
|
priv->bus = mdiodev->bus;
|
|
|
|
priv->dev = &mdiodev->dev;
|
|
|
|
priv->chip_data = (void *)priv + sizeof(*priv);
|
|
|
|
|
2024-02-09 02:03:40 -03:00
|
|
|
priv->variant = var;
|
2022-01-28 03:05:02 -03:00
|
|
|
priv->ops = var->ops;
|
|
|
|
|
|
|
|
priv->write_reg_noack = realtek_mdio_write;
|
|
|
|
|
|
|
|
np = dev->of_node;
|
|
|
|
|
|
|
|
dev_set_drvdata(dev, priv);
|
|
|
|
|
|
|
|
/* TODO: if power is software controlled, set up any regulators here */
|
|
|
|
priv->leds_disabled = of_property_read_bool(np, "realtek,disable-leds");
|
|
|
|
|
2022-02-13 23:20:12 -03:00
|
|
|
priv->reset = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_LOW);
|
|
|
|
if (IS_ERR(priv->reset)) {
|
|
|
|
dev_err(dev, "failed to get RESET GPIO\n");
|
|
|
|
return PTR_ERR(priv->reset);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (priv->reset) {
|
|
|
|
gpiod_set_value(priv->reset, 1);
|
|
|
|
dev_dbg(dev, "asserted RESET\n");
|
|
|
|
msleep(REALTEK_HW_STOP_DELAY);
|
|
|
|
gpiod_set_value(priv->reset, 0);
|
|
|
|
msleep(REALTEK_HW_START_DELAY);
|
|
|
|
dev_dbg(dev, "deasserted RESET\n");
|
|
|
|
}
|
|
|
|
|
2022-01-28 03:05:02 -03:00
|
|
|
ret = priv->ops->detect(priv);
|
|
|
|
if (ret) {
|
|
|
|
dev_err(dev, "unable to detect switch\n");
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
priv->ds = devm_kzalloc(dev, sizeof(*priv->ds), GFP_KERNEL);
|
|
|
|
if (!priv->ds)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
priv->ds->dev = dev;
|
|
|
|
priv->ds->num_ports = priv->num_ports;
|
|
|
|
priv->ds->priv = priv;
|
|
|
|
priv->ds->ops = var->ds_ops_mdio;
|
|
|
|
|
|
|
|
ret = dsa_register_switch(priv->ds);
|
|
|
|
if (ret) {
|
|
|
|
dev_err(priv->dev, "unable to register switch ret = %d\n", ret);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
2024-02-09 02:03:39 -03:00
|
|
|
EXPORT_SYMBOL_NS_GPL(realtek_mdio_probe, REALTEK_DSA);
|
2022-01-28 03:05:02 -03:00
|
|
|
|
2024-02-09 02:03:39 -03:00
|
|
|
/**
|
|
|
|
* realtek_mdio_remove() - Remove the driver of an MDIO-connected switch
|
|
|
|
* @mdiodev: mdio_device to be removed.
|
|
|
|
*
|
|
|
|
* This function should be used as the .remove_new in an mdio_driver. First
|
|
|
|
* it unregisters the DSA switch and cleans internal data. If a method is
|
|
|
|
* provided, the hard reset is asserted to avoid traffic leakage.
|
|
|
|
*
|
|
|
|
* Context: Can sleep.
|
|
|
|
* Return: Nothing.
|
|
|
|
*/
|
|
|
|
void realtek_mdio_remove(struct mdio_device *mdiodev)
|
2022-01-28 03:05:02 -03:00
|
|
|
{
|
|
|
|
struct realtek_priv *priv = dev_get_drvdata(&mdiodev->dev);
|
|
|
|
|
|
|
|
if (!priv)
|
|
|
|
return;
|
|
|
|
|
|
|
|
dsa_unregister_switch(priv->ds);
|
|
|
|
|
2022-02-13 23:20:12 -03:00
|
|
|
/* leave the device reset asserted */
|
|
|
|
if (priv->reset)
|
|
|
|
gpiod_set_value(priv->reset, 1);
|
2022-01-28 03:05:02 -03:00
|
|
|
}
|
2024-02-09 02:03:39 -03:00
|
|
|
EXPORT_SYMBOL_NS_GPL(realtek_mdio_remove, REALTEK_DSA);
|
2022-01-28 03:05:02 -03:00
|
|
|
|
2024-02-09 02:03:39 -03:00
|
|
|
/**
|
|
|
|
* realtek_mdio_shutdown() - Shutdown the driver of a MDIO-connected switch
|
|
|
|
* @mdiodev: mdio_device shutting down.
|
|
|
|
*
|
|
|
|
* This function should be used as the .shutdown in an mdio_driver. It shuts
|
|
|
|
* down the DSA switch and cleans the platform driver data, to prevent
|
|
|
|
* realtek_mdio_remove() from running afterwards, which is possible if the
|
|
|
|
* parent bus implements its own .shutdown() as .remove().
|
|
|
|
*
|
|
|
|
* Context: Can sleep.
|
|
|
|
* Return: Nothing.
|
|
|
|
*/
|
|
|
|
void realtek_mdio_shutdown(struct mdio_device *mdiodev)
|
2022-01-28 03:05:02 -03:00
|
|
|
{
|
|
|
|
struct realtek_priv *priv = dev_get_drvdata(&mdiodev->dev);
|
|
|
|
|
|
|
|
if (!priv)
|
|
|
|
return;
|
|
|
|
|
|
|
|
dsa_switch_shutdown(priv->ds);
|
|
|
|
|
|
|
|
dev_set_drvdata(&mdiodev->dev, NULL);
|
|
|
|
}
|
2024-02-09 02:03:39 -03:00
|
|
|
EXPORT_SYMBOL_NS_GPL(realtek_mdio_shutdown, REALTEK_DSA);
|
2022-01-28 03:05:02 -03:00
|
|
|
|
|
|
|
MODULE_AUTHOR("Luiz Angelo Daros de Luca <luizluca@gmail.com>");
|
|
|
|
MODULE_DESCRIPTION("Driver for Realtek ethernet switch connected via MDIO interface");
|
|
|
|
MODULE_LICENSE("GPL");
|
2024-02-09 02:03:38 -03:00
|
|
|
MODULE_IMPORT_NS(REALTEK_DSA);
|