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"
|
2024-02-09 02:03:41 -03:00
|
|
|
#include "rtl83xx.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;
|
|
|
|
}
|
|
|
|
|
2024-02-09 02:03:41 -03:00
|
|
|
static const struct realtek_interface_info realtek_mdio_info = {
|
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
|
|
|
.reg_read = realtek_mdio_read,
|
|
|
|
.reg_write = realtek_mdio_write,
|
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.
|
|
|
|
*
|
2024-02-09 02:03:41 -03:00
|
|
|
* This function should be used as the .probe in an mdio_driver. After
|
|
|
|
* calling the common probe function for both interfaces, it initializes the
|
|
|
|
* values specific for MDIO-connected devices. Finally, it calls a common
|
|
|
|
* function to register the DSA switch.
|
2024-02-09 02:03:39 -03:00
|
|
|
*
|
|
|
|
* 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 device *dev = &mdiodev->dev;
|
2024-02-09 02:03:41 -03:00
|
|
|
struct realtek_priv *priv;
|
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
|
|
|
|
2024-02-09 02:03:41 -03:00
|
|
|
priv = rtl83xx_probe(dev, &realtek_mdio_info);
|
|
|
|
if (IS_ERR(priv))
|
|
|
|
return PTR_ERR(priv);
|
2022-01-28 03:05:02 -03:00
|
|
|
|
|
|
|
priv->bus = mdiodev->bus;
|
2024-02-09 02:03:41 -03:00
|
|
|
priv->mdio_addr = mdiodev->addr;
|
2022-01-28 03:05:02 -03:00
|
|
|
priv->write_reg_noack = realtek_mdio_write;
|
|
|
|
|
2024-02-09 02:03:41 -03:00
|
|
|
ret = rtl83xx_register_switch(priv);
|
2022-01-28 03:05:02 -03:00
|
|
|
if (ret) {
|
2024-02-09 02:03:41 -03:00
|
|
|
rtl83xx_remove(priv);
|
2022-01-28 03:05:02 -03:00
|
|
|
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
|
2024-02-09 02:03:41 -03:00
|
|
|
* it unregisters the DSA switch and then it calls the common remove function.
|
2024-02-09 02:03:39 -03:00
|
|
|
*
|
|
|
|
* 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;
|
|
|
|
|
2024-02-09 02:03:41 -03:00
|
|
|
rtl83xx_unregister_switch(priv);
|
2022-01-28 03:05:02 -03:00
|
|
|
|
2024-02-09 02:03:41 -03:00
|
|
|
rtl83xx_remove(priv);
|
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.
|
|
|
|
*
|
2024-02-09 02:03:41 -03:00
|
|
|
* This function should be used as the .shutdown in a platform_driver. It calls
|
|
|
|
* the common shutdown function.
|
2024-02-09 02:03:39 -03:00
|
|
|
*
|
|
|
|
* 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;
|
|
|
|
|
2024-02-09 02:03:41 -03:00
|
|
|
rtl83xx_shutdown(priv);
|
2022-01-28 03:05:02 -03:00
|
|
|
}
|
2024-02-09 02:03:39 -03:00
|
|
|
EXPORT_SYMBOL_NS_GPL(realtek_mdio_shutdown, REALTEK_DSA);
|