From: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
To: Andrew Lunn <andrew@lunn.ch>
Cc: <netdev@vger.kernel.org>, "David S. Miller" <davem@davemloft.net>,
Florian Fainelli <f.fainelli@gmail.com>,
Rob Herring <robh+dt@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
<linux-arm-kernel@lists.infradead.org>,
<linux-kernel@vger.kernel.org>, <devicetree@vger.kernel.org>,
Masahiro Yamada <yamada.masahiro@socionext.com>,
Masami Hiramatsu <masami.hiramatsu@linaro.org>,
Jassi Brar <jaswinder.singh@linaro.org>
Subject: Re: [PATCH net-next 2/3] net: ethernet: socionext: add AVE ethernet driver
Date: Tue, 12 Sep 2017 18:24:01 +0900 [thread overview]
Message-ID: <20170912182400.180E.4A936039@socionext.com> (raw)
In-Reply-To: <20170911120009.GA24174@lunn.ch>
Hi Andrew,
On Mon, 11 Sep 2017 14:00:09 +0200 Andrew Lunn <andrew@lunn.ch> wrote:
> > > > +static irqreturn_t ave_interrupt(int irq, void *netdev)
> > > > +{
> > > > + struct net_device *ndev = (struct net_device *)netdev;
> > > > + struct ave_private *priv = netdev_priv(ndev);
> > > > + u32 gimr_val, gisr_val;
> > > > +
> > > > + gimr_val = ave_irq_disable_all(ndev);
> > > > +
> > > > + /* get interrupt status */
> > > > + gisr_val = ave_r32(ndev, AVE_GISR);
> > > > +
> > > > + /* PHY */
> > > > + if (gisr_val & AVE_GI_PHY) {
> > > > + ave_w32(ndev, AVE_GISR, AVE_GI_PHY);
> > > > + if (priv->internal_phy_interrupt)
> > > > + phy_mac_interrupt(ndev->phydev, ndev->phydev->link);
> > >
> > > Humm. I don't think this is correct. You are supposed to give it the
> > > new link state, not the old.
> > >
> > > What does a PHY interrupt mean here?
> >
> > In the general case, I think PHY events like changing link state are transmitted
> > to CPU as interrupt via interrupt controller, then PHY driver itself can handle
> > the interrupt.
> >
> > And in this case, PHY events are transmitted to MAC as one of its interrupt factor,
> > then I thought that MAC driver had to tell the events to PHY.
>
> Could this be in-band SGMI signalling from the PHY to the MAC? Does
> the documentation give examples of when this interrupt will happen?
>
> Andrew
Unfortunately this MAC doesn't support SGMII.
And there aren't any examples of when this interrupt will happen.
This interrupt happens after ave_open() is called and link is established.
However, I found that auto negotiation didn't start when this interrupt wasn't handled.
Although ave_init() calls phy_start_aneg(), it doesn't make sense
because phy driver doesn't start yet.
And according to Florian's comment in ave_init(),
> + phy_start_interrupts(phydev);
> +
> + phy_start_aneg(phydev);
>
> No, no, phy_start() would take care of all of that correctly for you,
> you don't have have to do it just there because ave_open() eventually
> calls phy_start() for you, so just drop these two calls.
When moving phy_start_aneg() to ave_open(), the handler doesn't need to call
phy_mac_interrupt() and I can remove it from the handler.
---
Best Regards,
Kunihiko Hayashi
next prev parent reply other threads:[~2017-09-12 9:24 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-08 13:02 [PATCH net-next 0/3] add UniPhier AVE ethernet support Kunihiko Hayashi
2017-09-08 13:02 ` [PATCH net-next 1/3] dt-bindings: net: add DT bindings for Socionext UniPhier AVE Kunihiko Hayashi
2017-09-08 14:03 ` Andrew Lunn
2017-09-11 7:11 ` Kunihiko Hayashi
2017-09-08 18:54 ` Florian Fainelli
2017-09-11 7:11 ` Kunihiko Hayashi
2017-09-08 13:02 ` [PATCH net-next 2/3] net: ethernet: socionext: add AVE ethernet driver Kunihiko Hayashi
2017-09-08 13:50 ` Andrew Lunn
2017-09-11 6:50 ` Kunihiko Hayashi
2017-09-11 12:00 ` Andrew Lunn
2017-09-12 9:24 ` Kunihiko Hayashi [this message]
2017-09-08 14:44 ` Masahiro Yamada
2017-09-11 6:51 ` Kunihiko Hayashi
2017-09-08 19:31 ` Florian Fainelli
2017-09-11 6:55 ` Kunihiko Hayashi
2017-09-21 12:27 ` Kunihiko Hayashi
2017-09-09 16:30 ` Florian Fainelli
2017-09-11 6:56 ` Kunihiko Hayashi
2017-09-08 13:02 ` [PATCH net-next 3/3] net: phy: realtek: add RTL8201F phy-id and functions Kunihiko Hayashi
2017-09-08 13:57 ` Andrew Lunn
2017-09-08 18:51 ` Florian Fainelli
2017-09-09 3:33 ` Jassi Brar
2017-09-09 15:55 ` Andrew Lunn
2017-09-11 7:48 ` Kunihiko Hayashi
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=20170912182400.180E.4A936039@socionext.com \
--to=hayashi.kunihiko@socionext.com \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=devicetree@vger.kernel.org \
--cc=f.fainelli@gmail.com \
--cc=jaswinder.singh@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=masami.hiramatsu@linaro.org \
--cc=netdev@vger.kernel.org \
--cc=robh+dt@kernel.org \
--cc=yamada.masahiro@socionext.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®