From: sergei.shtylyov@cogentembedded.com (Sergei Shtylyov)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v8 2/3] net: hisilicon: new hip04 MDIO driver
Date: Mon, 21 Apr 2014 22:21:50 +0400 [thread overview]
Message-ID: <535561BE.9070303@cogentembedded.com> (raw)
In-Reply-To: <CAGVrzcb8Ykxi72x3iBStjTL+OO1BhDc_yZnnPq8ZHra+mtrBEA@mail.gmail.com>
On 04/21/2014 10:03 PM, Florian Fainelli wrote:
>>> Hisilicon hip04 platform mdio driver
>>> Reuse Marvell phy drivers/net/phy/marvell.c
>>> Signed-off-by: Zhangfei Gao <zhangfei.gao@linaro.org>
>> [...]
>>> diff --git a/drivers/net/ethernet/hisilicon/hip04_mdio.c
>>> b/drivers/net/ethernet/hisilicon/hip04_mdio.c
>>> new file mode 100644
>>> index 0000000..19826a3
>>> --- /dev/null
>>> +++ b/drivers/net/ethernet/hisilicon/hip04_mdio.c
>>> @@ -0,0 +1,185 @@
[...]
>>> +static int hip04_mdio_reset(struct mii_bus *bus)
>>> +{
>>> + int temp, err, i;
>>> +
>>> + for (i = 0; i < PHY_MAX_ADDR; i++) {
>>> + hip04_mdio_write(bus, i, 22, 0);
>> Why? What kind of a register this is? <uapi/linux/mii.h> tells me it's
>> MII_SREVISION...
> I think this rather means clause 22 as opposed to clause 45.
No, the corresponding hip04_mdio_write()'s parameter is a register #, so
this is a write of 0 to register #22. A comment certainly wouldn't hurt here...
>>> + temp = hip04_mdio_read(bus, i, MII_BMCR);
>> You're not checking for error...
>>> + temp |= BMCR_RESET;
>>> + err = hip04_mdio_write(bus, i, MII_BMCR, temp);
>> Hmm, why you're open coding BMCR reset? There's phy_init_hw() doing this
>> correctly...
> Except that this runs way before we have created the PHY driver, so we
> can't use that function just yet.
Ah, you're right.
> I already asked about this, and he
> explained that this was because the PHY devices he uses are not
> responding correcty to MII_PHYSID1/2 reads.
So, this manual reset loop helps with reading the ID registers? A comment
wouldn't hurt either...
>>> + if (err < 0)
>>> + return err;
I'm not at all sure we want to leave the reset loop on a first write error.
>>> + }
>>> +
>>> + mdelay(500);
I'm not sure this is enough, given that in phy_init_hw() we poll for 600
ms + 1 ms.
>>> + return 0;
>>> +}
>>> +
>>> +static int hip04_mdio_probe(struct platform_device *pdev)
>>> +{
>>> + struct resource *r;
>>> + struct mii_bus *bus;
>>> + struct hip04_mdio_priv *priv;
>>> + int ret;
>>> +
>>> + bus = mdiobus_alloc_size(sizeof(struct hip04_mdio_priv));
>>> + if (!bus) {
>>> + dev_err(&pdev->dev, "Cannot allocate MDIO bus\n");
>>> + return -ENOMEM;
>>> + }
>>> +
>>> + bus->name = "hip04_mdio_bus";
>>> + bus->read = hip04_mdio_read;
>>> + bus->write = hip04_mdio_write;
>>> + bus->reset = hip04_mdio_reset;
>> Ah... However I don't think it a good implementation of that bus
>> method...
I assumed this method exists to do a hardware reset of the whole bus, not
to do a loop of soft-resetting all PHYs...
WBR, Sergei
WARNING: multiple messages have this Message-ID (diff)
From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
To: Florian Fainelli <f.fainelli@gmail.com>
Cc: Zhangfei Gao <zhangfei.gao@linaro.org>,
David Miller <davem@davemloft.net>,
Russell King <linux@arm.linux.org.uk>,
Arnd Bergmann <arnd@arndb.de>,
Mark Rutland <mark.rutland@arm.com>,
David Laight <David.Laight@aculab.com>,
Eric Dumazet <eric.dumazet@gmail.com>,
xuwei5@hisilicon.com,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
netdev <netdev@vger.kernel.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>
Subject: Re: [PATCH v8 2/3] net: hisilicon: new hip04 MDIO driver
Date: Mon, 21 Apr 2014 22:21:50 +0400 [thread overview]
Message-ID: <535561BE.9070303@cogentembedded.com> (raw)
In-Reply-To: <CAGVrzcb8Ykxi72x3iBStjTL+OO1BhDc_yZnnPq8ZHra+mtrBEA@mail.gmail.com>
On 04/21/2014 10:03 PM, Florian Fainelli wrote:
>>> Hisilicon hip04 platform mdio driver
>>> Reuse Marvell phy drivers/net/phy/marvell.c
>>> Signed-off-by: Zhangfei Gao <zhangfei.gao@linaro.org>
>> [...]
>>> diff --git a/drivers/net/ethernet/hisilicon/hip04_mdio.c
>>> b/drivers/net/ethernet/hisilicon/hip04_mdio.c
>>> new file mode 100644
>>> index 0000000..19826a3
>>> --- /dev/null
>>> +++ b/drivers/net/ethernet/hisilicon/hip04_mdio.c
>>> @@ -0,0 +1,185 @@
[...]
>>> +static int hip04_mdio_reset(struct mii_bus *bus)
>>> +{
>>> + int temp, err, i;
>>> +
>>> + for (i = 0; i < PHY_MAX_ADDR; i++) {
>>> + hip04_mdio_write(bus, i, 22, 0);
>> Why? What kind of a register this is? <uapi/linux/mii.h> tells me it's
>> MII_SREVISION...
> I think this rather means clause 22 as opposed to clause 45.
No, the corresponding hip04_mdio_write()'s parameter is a register #, so
this is a write of 0 to register #22. A comment certainly wouldn't hurt here...
>>> + temp = hip04_mdio_read(bus, i, MII_BMCR);
>> You're not checking for error...
>>> + temp |= BMCR_RESET;
>>> + err = hip04_mdio_write(bus, i, MII_BMCR, temp);
>> Hmm, why you're open coding BMCR reset? There's phy_init_hw() doing this
>> correctly...
> Except that this runs way before we have created the PHY driver, so we
> can't use that function just yet.
Ah, you're right.
> I already asked about this, and he
> explained that this was because the PHY devices he uses are not
> responding correcty to MII_PHYSID1/2 reads.
So, this manual reset loop helps with reading the ID registers? A comment
wouldn't hurt either...
>>> + if (err < 0)
>>> + return err;
I'm not at all sure we want to leave the reset loop on a first write error.
>>> + }
>>> +
>>> + mdelay(500);
I'm not sure this is enough, given that in phy_init_hw() we poll for 600
ms + 1 ms.
>>> + return 0;
>>> +}
>>> +
>>> +static int hip04_mdio_probe(struct platform_device *pdev)
>>> +{
>>> + struct resource *r;
>>> + struct mii_bus *bus;
>>> + struct hip04_mdio_priv *priv;
>>> + int ret;
>>> +
>>> + bus = mdiobus_alloc_size(sizeof(struct hip04_mdio_priv));
>>> + if (!bus) {
>>> + dev_err(&pdev->dev, "Cannot allocate MDIO bus\n");
>>> + return -ENOMEM;
>>> + }
>>> +
>>> + bus->name = "hip04_mdio_bus";
>>> + bus->read = hip04_mdio_read;
>>> + bus->write = hip04_mdio_write;
>>> + bus->reset = hip04_mdio_reset;
>> Ah... However I don't think it a good implementation of that bus
>> method...
I assumed this method exists to do a hardware reset of the whole bus, not
to do a loop of soft-resetting all PHYs...
WBR, Sergei
next prev parent reply other threads:[~2014-04-21 18:21 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-19 1:12 [PATCH v8 0/3] add hisilicon hip04 ethernet driver Zhangfei Gao
2014-04-19 1:12 ` Zhangfei Gao
2014-04-19 1:12 ` [PATCH v8 1/3] Documentation: add Device tree bindings for Hisilicon hip04 ethernet Zhangfei Gao
2014-04-19 1:12 ` Zhangfei Gao
2014-04-19 1:12 ` [PATCH v8 2/3] net: hisilicon: new hip04 MDIO driver Zhangfei Gao
2014-04-19 1:12 ` Zhangfei Gao
2014-04-21 17:58 ` Sergei Shtylyov
2014-04-21 17:58 ` Sergei Shtylyov
2014-04-21 18:03 ` Florian Fainelli
2014-04-21 18:03 ` Florian Fainelli
2014-04-21 18:21 ` Sergei Shtylyov [this message]
2014-04-21 18:21 ` Sergei Shtylyov
2014-04-22 6:03 ` zhangfei
2014-04-22 6:03 ` zhangfei
2014-04-22 8:22 ` Arnd Bergmann
2014-04-22 8:22 ` Arnd Bergmann
2014-04-22 14:16 ` zhangfei
2014-04-22 14:16 ` zhangfei
2014-04-22 14:30 ` Arnd Bergmann
2014-04-22 14:30 ` Arnd Bergmann
2014-04-22 14:58 ` zhangfei
2014-04-22 14:58 ` zhangfei
2014-04-24 12:28 ` Arnd Bergmann
2014-04-24 12:28 ` Arnd Bergmann
2014-04-24 13:00 ` zhangfei
2014-04-24 13:00 ` zhangfei
2014-04-19 1:13 ` [PATCH v8 3/3] net: hisilicon: new hip04 ethernet driver Zhangfei Gao
2014-04-19 1:13 ` Zhangfei Gao
2014-12-07 0:42 ` Alexander Graf
2014-12-07 0:42 ` Alexander Graf
2014-12-07 3:28 ` Ding Tianhong
2014-12-07 3:28 ` Ding Tianhong
2014-12-07 3:28 ` Ding Tianhong
2014-12-07 9:49 ` Alexander Graf
2014-12-07 9:49 ` Alexander Graf
2014-12-07 20:09 ` Arnd Bergmann
2014-12-07 20:09 ` Arnd Bergmann
2014-12-08 1:48 ` Ding Tianhong
2014-12-08 1:48 ` Ding Tianhong
2014-12-10 3:51 ` Ding Tianhong
2014-12-10 3:51 ` Ding Tianhong
2014-12-10 3:51 ` Ding Tianhong
2014-12-10 6:45 ` Ding Tianhong
2014-12-10 6:45 ` Ding Tianhong
2014-12-10 6:45 ` Ding Tianhong
2014-12-10 9:35 ` Arnd Bergmann
2014-12-10 9:35 ` Arnd Bergmann
2014-12-10 16:07 ` David Miller
2014-12-10 16:07 ` David Miller
2014-12-10 16:36 ` Arnd Bergmann
2014-12-10 16:36 ` Arnd Bergmann
2014-12-10 17:02 ` David Miller
2014-12-10 17:02 ` David Miller
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=535561BE.9070303@cogentembedded.com \
--to=sergei.shtylyov@cogentembedded.com \
--cc=linux-arm-kernel@lists.infradead.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.