From: Andrew Lunn <andrew@lunn.ch>
To: biao huang <biao.huang@mediatek.com>
Cc: jianguo.zhang@mediatek.com,
Alexandre Torgue <alexandre.torgue@st.com>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com, yt.shen@mediatek.com,
Jose Abreu <joabreu@synopsys.com>,
linux-mediatek@lists.infradead.org,
Maxime Coquelin <mcoquelin.stm32@gmail.com>,
Matthias Brugger <matthias.bgg@gmail.com>,
Giuseppe Cavallaro <peppe.cavallaro@st.com>,
davem@davemloft.net, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 5/6] net: stmmac: add mdio clause 45 access from mac device for dwmac4
Date: Mon, 29 Apr 2019 15:23:27 +0200 [thread overview]
Message-ID: <20190429132327.GF10772@lunn.ch> (raw)
In-Reply-To: <1556517925.24897.17.camel@mhfsdcap03>
> > Hi Biao
> >
> > readl_poll_timeout() returns an error code. It is better to return
> > that, than make up some other error code. Yes, i know the C22 read
> > returns EBUSY, but we don't need to copy that behaviour into C45.
> >
> OK, will return error code here.
> > > +
> > > + value = 0;
> > > + value |= (prtad << priv->hw->mii.cl45_reg_shift)
> > > + & priv->hw->mii.cl45_reg_mask;
> > > + writel(value, priv->ioaddr + mii_data);
> > > +
> > > + /* delay 2ms to avoid error value of get_phy_c45_devs_in_pkg */
> > > + mdelay(2);
> >
> > Please could you explain this a bit more?
> when of_mdiobus_register is invoked,
> the C22 PHY addr information will be obtained in device tree(reg = xx,
> no need through mdiobus),
> but C45 PHY addr should be got through mdiobus->read according to
> current flow.
> of_mdiobus_register -->
> of_mdiobus_register_phy -->
> get_phy_device -->
> get_phy_id -->
> get_phy_c45_ids -->
> get_phy_c45_devs_in_pkg
>
> In my platform, mdio bus read will return 0xffff or 0x0000 for C45 in
> of_mdiobus_register callstack, and that's not the expected value.
> So that the mdiobus register fails.
>
> We took some time to find that only after adding 2ms delay here,
> the read action will be stable and return the expected value.
>
> did you try C45 support in your platform? I can't tell whether it's a
> common or specified issue.
It sounds like you need to put a logic analyser on the bus and see if
it performs a C22 transaction, or an invalid transaction, without the
2ms pause.
This sounds like a 'silicon' bug. There should not be a need to pause
here. And the comment should talk about this silicon bug, not
get_phy_c45_devs_in_pkg(). It will fail for all accesses, not just
those for get_phy_c45_devs_in_pkg().
Andrew
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2019-04-29 13:23 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-28 6:30 [PATCH 0/6] fix some bugs and add some features in stmmac Biao Huang
2019-04-28 6:30 ` [PATCH 1/6] net: stmmac: update rx tail pointer register to fix rx dma hang issue Biao Huang
2019-04-28 6:30 ` [PATCH 2/6] net: stmmac: fix csr_clk can't be zero issue Biao Huang
2019-04-29 7:18 ` Alexandre Torgue
2019-04-29 8:09 ` biao huang
2019-04-29 8:26 ` Alexandre Torgue
2019-04-30 9:15 ` biao huang
2019-04-30 9:43 ` Alexandre Torgue
2019-04-28 6:30 ` [PATCH 3/6] net: stmmac: write the modified value back to MTL_OPERATION_MODE Biao Huang
2019-04-28 6:30 ` [PATCH 4/6] net: stmmac: add support for hash table size 128/256 in dwmac4 Biao Huang
2019-04-28 6:30 ` [PATCH 5/6] net: stmmac: add mdio clause 45 access from mac device for dwmac4 Biao Huang
2019-04-28 16:37 ` Andrew Lunn
2019-04-29 6:05 ` biao huang
2019-04-29 13:23 ` Andrew Lunn [this message]
2019-04-28 6:30 ` [PATCH 6/6] stmmac: dwmac-mediatek: modify csr_clk value to fix mdio read/write fail Biao Huang
2019-04-28 12:48 ` [PATCH 0/6] fix some bugs and add some features in stmmac 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=20190429132327.GF10772@lunn.ch \
--to=andrew@lunn.ch \
--cc=alexandre.torgue@st.com \
--cc=biao.huang@mediatek.com \
--cc=davem@davemloft.net \
--cc=jianguo.zhang@mediatek.com \
--cc=joabreu@synopsys.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=linux-stm32@st-md-mailman.stormreply.com \
--cc=matthias.bgg@gmail.com \
--cc=mcoquelin.stm32@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=peppe.cavallaro@st.com \
--cc=yt.shen@mediatek.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;
as well as URLs for NNTP newsgroup(s).