From: "Wells Lu 呂芳騰" <wells.lu@sunplus.com>
To: Florian Fainelli <f.fainelli@gmail.com>,
Wells Lu <wellslutw@gmail.com>,
"davem@davemloft.net" <davem@davemloft.net>,
"kuba@kernel.org" <kuba@kernel.org>,
"robh+dt@kernel.org" <robh+dt@kernel.org>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"p.zabel@pengutronix.de" <p.zabel@pengutronix.de>
Cc: "Vincent Shih 施錕鴻" <vincent.shih@sunplus.com>
Subject: RE: [PATCH v2 2/2] net: ethernet: Add driver for Sunplus SP7021
Date: Sun, 14 Nov 2021 18:59:48 +0000 [thread overview]
Message-ID: <e06c11ec6dec4d379f5cda27c9f47c43@sphcmbx02.sunplus.com.tw> (raw)
In-Reply-To: <a8c656b8-a564-6aa6-7ca4-50e7a0bd65a1@gmail.com>
Hi,
> On 11/11/21 1:04 AM, Wells Lu wrote:
> > Add driver for Sunplus SP7021.
> >
> > Signed-off-by: Wells Lu <wells.lu@sunplus.com>
> > ---
>
> [snip]
>
> > +u32 mdio_read(struct sp_mac *mac, u32 phy_id, u16 regnum) {
> > + int ret;
> > +
> > + ret = hal_mdio_access(mac, MDIO_READ_CMD, phy_id, regnum, 0);
> > + if (ret < 0)
> > + return -EOPNOTSUPP;
> > +
> > + return ret;
> > +}
> > +
> > +u32 mdio_write(struct sp_mac *mac, u32 phy_id, u32 regnum, u16 val) {
> > + int ret;
> > +
> > + ret = hal_mdio_access(mac, MDIO_WRITE_CMD, phy_id, regnum, val);
> > + if (ret < 0)
> > + return -EOPNOTSUPP;
> > +
> > + return 0;
> > +}
>
> You should not be exposing these functions, if you do, that means another part of your
> code performs MDIO bus read/write operations without using the appropriate layer, so no.
Yes, I'll re-declare the two functions as static functions.
> > +
> > +static int mii_read(struct mii_bus *bus, int phy_id, int regnum) {
> > + struct sp_mac *mac = bus->priv;
> > +
> > + return mdio_read(mac, phy_id, regnum); }
> > +
> > +static int mii_write(struct mii_bus *bus, int phy_id, int regnum, u16
> > +val) {
> > + struct sp_mac *mac = bus->priv;
> > +
> > + return mdio_write(mac, phy_id, regnum, val); }
> > +
> > +u32 mdio_init(struct platform_device *pdev, struct net_device *ndev)
>
> Those function names need to be prefixed with sp_ to denote the driver local scope, this
> applies for your entire patch set.
Yes, I'll add vendor-specified prefix to the two functions and all the other functions in
the drivers.
> [snip]
>
> > diff --git a/drivers/net/ethernet/sunplus/sp_mdio.h
> > b/drivers/net/ethernet/sunplus/sp_mdio.h
> > new file mode 100644
> > index 0000000..d708624
> > --- /dev/null
> > +++ b/drivers/net/ethernet/sunplus/sp_mdio.h
> > @@ -0,0 +1,20 @@
> > +/* SPDX-License-Identifier: GPL-2.0 */
> > +/* Copyright Sunplus Technology Co., Ltd.
> > + * All rights reserved.
> > + */
> > +
> > +#ifndef __SP_MDIO_H__
> > +#define __SP_MDIO_H__
> > +
> > +#include "sp_define.h"
> > +#include "sp_hal.h"
> > +
> > +#define MDIO_READ_CMD 0x02
> > +#define MDIO_WRITE_CMD 0x01
> > +
> > +u32 mdio_read(struct sp_mac *mac, u32 phy_id, u16 regnum);
> > +u32 mdio_write(struct sp_mac *mac, u32 phy_id, u32 regnum, u16 val);
>
> Please scope your functions better, and name them sp_mdio_read, etc.
> because mdio_read() is way too generic. Also, can you please follow the same prototype
> as what include/linux/mdio.h has for the mdiobus->read and ->write calls, that is phy_id
> is int, regnum is u32, etc.
Yes, I'll re-declare the two functions, mdio_read() and mdio_write(), as static
functions and add vendor-specified prefix to them.
The wrong declaration of the two functions will be removed from the header file.
> > +u32 mdio_init(struct platform_device *pdev, struct net_device
> > +*ndev); void mdio_remove(struct net_device *ndev);
> > +
> > +#endif
> > diff --git a/drivers/net/ethernet/sunplus/sp_phy.c
> > b/drivers/net/ethernet/sunplus/sp_phy.c
> > new file mode 100644
> > index 0000000..df6df3a
> > --- /dev/null
> > +++ b/drivers/net/ethernet/sunplus/sp_phy.c
> > @@ -0,0 +1,64 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/* Copyright Sunplus Technology Co., Ltd.
> > + * All rights reserved.
> > + */
> > +
> > +#include "sp_phy.h"
> > +#include "sp_mdio.h"
> > +
> > +static void mii_linkchange(struct net_device *netdev) { }
>
> Does your MAC fully auto-configure based on the PHY's link parameters, if so, how does
> it do it? You most certainly need to act on duplex changes, or speed changes no?
Yes, it does. SP7021 MAC communicates with PHY automatically.
It reads link status (half- or full-duplex, 10M or 100M) from PHY
and sets itself automatically.
It also reads port status (link up or down) and generates
interrupt to driver.
> > +
> > +int sp_phy_probe(struct net_device *ndev) {
> > + struct sp_mac *mac = netdev_priv(ndev);
> > + struct phy_device *phydev;
> > + int i;
> > +
> > + phydev = of_phy_connect(ndev, mac->phy_node, mii_linkchange,
> > + 0, mac->phy_mode);
> > + if (!phydev) {
> > + netdev_err(ndev, "\"%s\" failed to connect to phy!\n", ndev->name);
> > + return -ENODEV;
> > + }
> > +
> > + for (i = 0; i < sizeof(phydev->supported) / sizeof(long); i++)
> > + phydev->advertising[i] = phydev->supported[i];
> > +
> > + phydev->irq = PHY_MAC_INTERRUPT;
> > + mac->phy_dev = phydev;
> > +
> > + // Bug workaround:
> > + // Flow-control of phy should be enabled. MAC flow-control will refer
> > + // to the bit to decide to enable or disable flow-control.
> > + mdio_write(mac, mac->phy_addr, 4, mdio_read(mac, mac->phy_addr, 4) |
> > +(1 << 10));
>
> This is a layering violation, and you should not be doing those things here, if you need
> to advertise flow control, then please set ADVERTISE_PAUSE_CAP and/or ADVERTISE_PAUSE_ASYM
> accordingly, see whether
> phy_set_asym_pause() can do what you need it to.
Yes, I'll remove the statement, instead, use phy_set_asym_pause().
> > +
> > + return 0;
> > +}
> > +
> > +void sp_phy_start(struct net_device *ndev) {
> > + struct sp_mac *mac = netdev_priv(ndev);
> > +
> > + if (mac->phy_dev)
> > + phy_start(mac->phy_dev);
> > +}
> > +
> > +void sp_phy_stop(struct net_device *ndev) {
> > + struct sp_mac *mac = netdev_priv(ndev);
> > +
> > + if (mac->phy_dev)
> > + phy_stop(mac->phy_dev);
> > +}
> > +
> > +void sp_phy_remove(struct net_device *ndev) {
> > + struct sp_mac *mac = netdev_priv(ndev);
> > +
> > + if (mac->phy_dev) {
> > + phy_disconnect(mac->phy_dev);
> > + mac->phy_dev = NULL;
> > + }
>
> The net_device structure already contains a phy_device pointer, you don't need to have
> one in your sp_mac structure, too.
Yes, I'll remove phy_device from struct sp_mac.
> --
> Florian
Thank you very much for your review.
next prev parent reply other threads:[~2021-11-14 19:00 UTC|newest]
Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-03 11:02 [PATCH 0/2] This is a patch series of ethernet driver for Sunplus SP7021 SoC Wells Lu
2021-11-03 11:02 ` [PATCH 1/2] devicetree: bindings: net: Add bindings doc for Sunplus SP7021 Wells Lu
2021-11-03 11:02 ` [PATCH 2/2] net: ethernet: Add driver " Wells Lu
2021-11-03 12:05 ` Denis Kirjanov
2021-11-03 14:08 ` Wells Lu 呂芳騰
2021-11-03 12:10 ` Philipp Zabel
2021-11-03 15:11 ` Wells Lu 呂芳騰
2021-11-03 15:52 ` Randy Dunlap
2021-11-03 18:08 ` Wells Lu 呂芳騰
2021-11-03 19:30 ` Andrew Lunn
2021-11-04 5:31 ` Wells Lu 呂芳騰
2021-11-04 12:59 ` Andrew Lunn
2021-11-04 14:55 ` Randy Dunlap
2021-11-04 17:51 ` Wells Lu 呂芳騰
2021-11-04 17:46 ` Wells Lu 呂芳騰
2021-11-04 18:21 ` Andrew Lunn
2021-11-04 19:03 ` Wells Lu 呂芳騰
2021-11-03 20:26 ` Randy Dunlap
2021-11-03 16:51 ` Andrew Lunn
2021-11-05 11:25 ` Wells Lu 呂芳騰
2021-11-05 13:37 ` Andrew Lunn
2021-11-08 9:37 ` Wells Lu 呂芳騰
2021-11-08 13:15 ` Andrew Lunn
2021-11-08 14:26 ` Wells Lu 呂芳騰
2021-11-08 14:52 ` Andrew Lunn
2021-11-08 16:47 ` Wells Lu 呂芳騰
2021-11-08 17:32 ` Andrew Lunn
2021-11-09 14:39 ` Wells Lu 呂芳騰
2021-11-09 15:32 ` Andrew Lunn
2021-11-09 17:05 ` Wells Lu 呂芳騰
2021-11-14 19:19 ` Pavel Skripkin
2021-11-17 9:28 ` Wells Lu 呂芳騰
2021-11-03 11:27 ` [PATCH 0/2] This is a patch series of ethernet driver for Sunplus SP7021 SoC Denis Kirjanov
2021-11-11 9:04 ` [PATCH v2 0/2] This is a patch series for pinctrl " Wells Lu
2021-11-11 9:04 ` [PATCH v2 1/2] devicetree: bindings: net: Add bindings doc for Sunplus SP7021 Wells Lu
2021-11-11 14:57 ` Rob Herring
2021-11-12 2:57 ` Wells Lu 呂芳騰
2021-11-11 18:23 ` Andrew Lunn
2021-11-12 2:50 ` Wells Lu 呂芳騰
2021-11-11 9:04 ` [PATCH v2 2/2] net: ethernet: Add driver " Wells Lu
2021-11-11 11:31 ` Denis Kirjanov
2021-11-13 14:22 ` Wells Lu 呂芳騰
2021-11-13 15:34 ` Andrew Lunn
2021-11-18 8:15 ` Wells Lu 呂芳騰
2021-11-12 17:42 ` kernel test robot
2021-11-12 23:16 ` Florian Fainelli
2021-11-12 23:24 ` Andrew Lunn
2021-11-15 14:38 ` Wells Lu 呂芳騰
2021-11-14 18:59 ` Wells Lu 呂芳騰 [this message]
2021-11-12 23:58 ` Andrew Lunn
2021-11-16 17:09 ` Wells Lu 呂芳騰
2021-11-16 22:15 ` Andrew Lunn
2021-11-18 8:22 ` Wells Lu 呂芳騰
2021-11-25 11:28 ` Wells Lu 呂芳騰
2021-11-25 15:20 ` Andrew Lunn
2021-11-26 3:56 ` Wells Lu 呂芳騰
2021-11-26 14:38 ` Andrew Lunn
2021-11-26 16:12 ` Wells Lu 呂芳騰
2021-11-26 18:07 ` Andrew Lunn
2021-11-26 19:13 ` Wells Lu 呂芳騰
2021-11-26 19:32 ` Andrew Lunn
2021-11-29 11:16 ` Wells Lu 呂芳騰
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e06c11ec6dec4d379f5cda27c9f47c43@sphcmbx02.sunplus.com.tw \
--to=wells.lu@sunplus.com \
--cc=davem@davemloft.net \
--cc=devicetree@vger.kernel.org \
--cc=f.fainelli@gmail.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=p.zabel@pengutronix.de \
--cc=robh+dt@kernel.org \
--cc=vincent.shih@sunplus.com \
--cc=wellslutw@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®