netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Greg Ungerer <gerg@linux-m68k.org>
To: Andy Duan <fugang.duan@nxp.com>, Andrew Lunn <andrew@lunn.ch>
Cc: Chris Heally <cphealy@gmail.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>
Subject: Re: [EXT] Re: [PATCH] net: ethernet: fec: Replace interrupt driven MDIO with polled IO
Date: Wed, 21 Oct 2020 12:37:10 +1000	[thread overview]
Message-ID: <bdf3f11b-a62e-405c-fb7a-bcd7491937fd@linux-m68k.org> (raw)
In-Reply-To: <AM8PR04MB73153FA5CF4C0B88CE65EF87FF1C0@AM8PR04MB7315.eurprd04.prod.outlook.com>

Hi Andy,

On 21/10/20 12:19 pm, Andy Duan wrote:
> From: Greg Ungerer <gerg@linux-m68k.org> Sent: Wednesday, October 21, 2020 9:52 AM
>> Hi Andrew,
>>
>> Thanks for the quick response.
>>
>>
>> On 20/10/20 12:40 pm, Andrew Lunn wrote:
>>> On Tue, Oct 20, 2020 at 12:14:04PM +1000, Greg Ungerer wrote:
>>>> Hi Andrew,
>>>>
>>>> Commit f166f890c8f0 ("[PATCH] net: ethernet: fec: Replace interrupt
>>>> driven MDIO with polled IO") breaks the FEC driver on at least one of
>>>> the ColdFire platforms (the 5208). Maybe others, that is all I have
>>>> tested on so far.
>>>>
>>>> Specifically the driver no longer finds any PHY devices when it
>>>> probes the MDIO bus at kernel start time.
>>>>
>>>> I have pinned the problem down to this one specific change in this commit:
>>>>
>>>>> @@ -2143,8 +2142,21 @@ static int fec_enet_mii_init(struct
>> platform_device *pdev)
>>>>>      if (suppress_preamble)
>>>>>              fep->phy_speed |= BIT(7);
>>>>> +   /* Clear MMFR to avoid to generate MII event by writing MSCR.
>>>>> +    * MII event generation condition:
>>>>> +    * - writing MSCR:
>>>>> +    *      - mmfr[31:0]_not_zero & mscr[7:0]_is_zero &
>>>>> +    *        mscr_reg_data_in[7:0] != 0
>>>>> +    * - writing MMFR:
>>>>> +    *      - mscr[7:0]_not_zero
>>>>> +    */
>>>>> +   writel(0, fep->hwp + FEC_MII_DATA);
>>>>
>>>> At least by removing this I get the old behavior back and everything
>>>> works as it did before.
>>>>
>>>> With that write of the FEC_MII_DATA register in place it seems that
>>>> subsequent MDIO operations return immediately (that is FEC_IEVENT is
>>>> set) - even though it is obvious the MDIO transaction has not completed yet.
>>>>
>>>> Any ideas?
>>>
>>> Hi Greg
>>>
>>> This has come up before, but the discussion fizzled out without a
>>> final patch fixing the issue. NXP suggested this
>>>
>>> writel(0, fep->hwp + FEC_MII_DATA);
>>>
>>> Without it, some other FEC variants break because they do generate an
>>> interrupt at the wrong time causing all following MDIO transactions to
>>> fail.
>>>
>>> At the moment, we don't seem to have a clear understanding of the
>>> different FEC versions, and how their MDIO implementations vary.
>>
>> Based on Andy and Chris' comments is something like the attached patch what
>> we need?
> 
> Greg, imx28 platform also requires the flag.

Got it, thanks. I will update the patch. I won't resend a v2 just yet, 
wait and see if there is any other comments.

Regards
Greg



  reply	other threads:[~2020-10-21  2:37 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-20  2:14 [PATCH] net: ethernet: fec: Replace interrupt driven MDIO with polled IO Greg Ungerer
2020-10-20  2:40 ` Andrew Lunn
2020-10-20  3:02   ` [EXT] " Andy Duan
2020-10-20 13:06     ` Chris Healy
2020-10-20 13:52       ` Andy Duan
2020-10-20 13:08     ` Andrew Lunn
2020-10-21  1:51   ` Greg Ungerer
2020-10-21  2:19     ` [EXT] " Andy Duan
2020-10-21  2:37       ` Greg Ungerer [this message]
2020-10-21 13:37     ` Andrew Lunn
2020-10-22  1:14       ` Greg Ungerer
2020-10-22  2:39         ` [EXT] " Andy Duan
2020-10-22  9:04         ` Andy Duan
2020-10-27  0:17           ` Greg Ungerer
2020-10-27  1:33             ` Andy Duan
  -- strict thread matches above, loose matches on Subject: below --
2020-04-14  0:45 Andrew Lunn
2020-04-27 15:19 ` Leonard Crestez
2020-04-27 16:46   ` Andrew Lunn
2020-04-27 17:48     ` [EXT] " Andy Duan
2020-04-27 20:00     ` Leonard Crestez
2020-04-27 20:13       ` Andrew Lunn
2020-04-28  7:50         ` [EXT] " Andy Duan
2020-04-28 13:34           ` Andrew Lunn
2020-04-28 13:50             ` Andy Duan
2020-04-28 14:29               ` Andrew Lunn

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=bdf3f11b-a62e-405c-fb7a-bcd7491937fd@linux-m68k.org \
    --to=gerg@linux-m68k.org \
    --cc=andrew@lunn.ch \
    --cc=cphealy@gmail.com \
    --cc=fugang.duan@nxp.com \
    --cc=netdev@vger.kernel.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 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).