lkml.org 
[lkml]   [2022]   [Dec]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v2 6/9] net: phy: motorcomm: Add YT8531 phy support
> Signed-off-by: Yanhong Wang <yanhong.wang@starfivetech.com>
> ---
> drivers/net/phy/Kconfig | 3 +-
> drivers/net/phy/motorcomm.c | 202 ++++++++++++++++++++++++++++++++++++
> 2 files changed, 204 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
> index c57a0262fb64..86399254d9ff 100644
> --- a/drivers/net/phy/Kconfig
> +++ b/drivers/net/phy/Kconfig
> @@ -258,9 +258,10 @@ config MICROSEMI_PHY
>
> config MOTORCOMM_PHY
> tristate "Motorcomm PHYs"
> + default SOC_STARFIVE

Please don't do this. Look at the other PHY drivers. How many have a
default like this?

Generally, if you are doing something which no other driver does, you
are doing something wrong.

> --- a/drivers/net/phy/motorcomm.c
> +++ b/drivers/net/phy/motorcomm.c
> @@ -3,13 +3,17 @@
> * Driver for Motorcomm PHYs
> *
> * Author: Peter Geis <pgwipeout@gmail.com>
> + *
> */

Please avoid changes like this. It distracts from the real code
changes.

>
> +#include <linux/bitops.h>
> #include <linux/kernel.h>
> #include <linux/module.h>
> +#include <linux/of.h>
> #include <linux/phy.h>
>
> #define PHY_ID_YT8511 0x0000010a
> +#define PHY_ID_YT8531 0x4f51e91b
>
> #define YT8511_PAGE_SELECT 0x1e
> #define YT8511_PAGE 0x1f
> @@ -17,6 +21,10 @@
> #define YT8511_EXT_DELAY_DRIVE 0x0d
> #define YT8511_EXT_SLEEP_CTRL 0x27
>
> +#define YTPHY_EXT_SMI_SDS_PHY 0xa000
> +#define YTPHY_EXT_CHIP_CONFIG 0xa001
> +#define YTPHY_EXT_RGMII_CONFIG1 0xa003
> +
> /* 2b00 25m from pll
> * 2b01 25m from xtl *default*
> * 2b10 62.m from pll
> @@ -38,6 +46,51 @@
> #define YT8511_DELAY_FE_TX_EN (0xf << 12)
> #define YT8511_DELAY_FE_TX_DIS (0x2 << 12)
>
> +struct ytphy_reg_field {
> + char *name;
> + u32 mask;
> + u8 dflt; /* Default value */
> +};

This should be next to where it is used. But once you have delay in
ps, i suspect you will throw this away.

>
> +static int ytphy_config_init(struct phy_device *phydev)

Is this specific to the 8531? If so, put 8531 in the function name?

Do any of these delay configurations also apply to the 8511?

> +{
> + struct device_node *of_node;
> + u32 val;
> + u32 mask;
> + u32 cfg;
> + int ret;
> + int i = 0;

Reverse Christmas tree. i needs to be earlier, val needs to be later.

> + of_node = phydev->mdio.dev.of_node;
> + if (of_node) {
> + ret = of_property_read_u32(of_node, ytphy_rxden_grp[0].name, &cfg);
> + if (!ret) {
> + mask = ytphy_rxden_grp[0].mask;
> + val = ytphy_read_ext(phydev, YTPHY_EXT_CHIP_CONFIG);
> +
> + /* check the cfg overflow or not */
> + cfg = cfg > mask >> (ffs(mask) - 1) ? mask : cfg;
> +
> + val &= ~mask;
> + val |= FIELD_PREP(mask, cfg);
> + ytphy_write_ext(phydev, YTPHY_EXT_CHIP_CONFIG, val);
> + }
> +
> + val = ytphy_read_ext(phydev, YTPHY_EXT_RGMII_CONFIG1);
> + for (i = 0; i < ARRAY_SIZE(ytphy_rxtxd_grp); i++) {
> + ret = of_property_read_u32(of_node, ytphy_rxtxd_grp[i].name, &cfg);
> + if (!ret) {
> + mask = ytphy_rxtxd_grp[i].mask;
> +
> + /* check the cfg overflow or not */
> + cfg = cfg > mask >> (ffs(mask) - 1) ? mask : cfg;
> +
> + val &= ~mask;
> + val |= cfg << (ffs(mask) - 1);
> + }
> + }
> + return ytphy_write_ext(phydev, YTPHY_EXT_RGMII_CONFIG1, val);
> + }
> +
> + phydev_err(phydev, "Get of node fail\n");

What about the case of the PHY is used on a board without device tree?
ACPI could be used, or there could be nothing because it is on a USB
dongle etc.

You should of defined in your device tree binding what the defaults
are when properties are missing. So apply them when there is no DT
available. Then we at least have the PHY in a known state.

Andrew

\
 
 \ /
  Last update: 2023-03-26 23:15    [W:0.117 / U:0.244 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site