From: Andrew Lunn <andrew@lunn.ch>
To: Charles-Antoine Couret <charles-antoine.couret@nexvision.fr>
Cc: netdev <netdev@vger.kernel.org>, Florian Fainelli <f.fainelli@gmail.com>
Subject: Re: [PATCH v3] Marvell phy: add fiber status check and configuration for some phys
Date: Wed, 13 Jul 2016 15:26:32 +0200 [thread overview]
Message-ID: <20160713132632.GA6667@lunn.ch> (raw)
In-Reply-To: <843ddd47-0394-88ee-39d9-f50bb7256225@nexvision.fr>
On Wed, Jul 13, 2016 at 11:14:21AM +0200, Charles-Antoine Couret wrote:
Hi Charles-Antoine
> >> +#define LPA_FIBER_1000HALF 0x40
> >> +#define LPA_FIBER_1000FULL 0x20
> >> +
> >> +#define LPA_PAUSE_FIBER 0x180
> >> +#define LPA_PAUSE_ASYM_FIBER 0x100
> >> +
> >> +#define ADVERTISE_FIBER_1000HALF 0x40
> >> +#define ADVERTISE_FIBER_1000FULL 0x20
> >> +
> >> +#define ADVERTISE_PAUSE_FIBER 0x180
> >> +#define ADVERTISE_PAUSE_ASYM_FIBER 0x100
> >
> > Are these standardised anywhere? If they are following a standard,
> > they should be put into include/uapi/linux/mii.h.
> I don't find any standard about this, I think it should be Marvell specific.
O.K.
> >> +static inline u32 ethtool_adv_to_fiber_adv_t(u32 ethadv)
> >> +{
> >> + u32 result = 0;
> >> +
> >> + if (ethadv & ADVERTISED_1000baseT_Half)
> >> + result |= ADVERTISE_FIBER_1000HALF;
> >
> > Dumb question: Does 1000baseT_Half even make sense for fibre? Can you
> > do half duplex? Would that not mean you have a single fibre, both
> > ends are using the same laser frequency, and you are doing some form
> > of CSMA/CD?
>
> It's strange, I agree, but the register about that exists in the datasheet and the value is not fixed.
> In practice, I don't have a component to test this case correctly.
O.K, just implement it according to the data sheet.
> >> *
> >> * Generic status code does not detect Fiber correctly!
> >> @@ -906,12 +1070,17 @@ static int marvell_read_status(struct phy_device *phydev)
> >> int lpa;
> >> int lpagb;
> >> int status = 0;
> >> + int page, fiber;
> >>
> >> - /* Update the link, but return if there
> >> + /* Detect and update the link, but return if there
> >> * was an error */
> >> - err = genphy_update_link(phydev);
> >> - if (err)
> >> - return err;
> >> + page = phy_read(phydev, MII_MARVELL_PHY_PAGE);
> >> + if (page == MII_M1111_FIBER)
> >> + fiber = 1;
> >> + else
> >> + fiber = 0;
> >
> > This read is expensive, since the MDIO bus is slow. It would be better
> > just to pass fibre as a parameter.
>
> But this function is used for other Marvell's phy, without fiber link for example.
> And this function should has only the struct phy_device as parameter.
>
> I don't have idea to avoid that, without create a custom function for that which would be very similar to this function.
> Or used a phy_device field for that? I think it's awful idea...
So i would have
static int marvell_read_status_page(struct phy_device *phydev, int page)
{}
basically doing what you have above, but without the read.
static int marvell_read_status(struct phy_device *phydev)
{
if (phydev->supported & SUPPORTED_FIBRE) {
marvell_read_status_page(phydev, MII_M1111_FIBER);
if (phydev->link)
return;
return marvell_read_status_page(phydev, MII_M1111_COPPER);
}
> > I think it would be better to look for SUPPORTED_FIBRE in
> > drv->features, rather than have two different functions.
> >
> > In fact, i would do that in general, rather than add your _fibre()
> > functions.
>
> So, you suggest to do that in genphy_* functions or create marvell_* functions with this condition?
> I'm agree with the second suggestion.
The second.
>
> >> +
> >> +/* marvell_resume_fiber
> >> + *
> >> + * Some Marvell's phys have two modes: fiber and copper.
> >> + * Both need to be resumed
> >> + */
> >> +static int marvell_resume_fiber(struct phy_device *phydev)
> >> +{
> >> + int err;
> >> +
> >> + /* Resume the fiber mode first */
> >> + err = phy_write(phydev, MII_MARVELL_PHY_PAGE, MII_M1111_FIBER);
> >> + if (err < 0)
> >> + goto error;
> >> +
> >> + err = genphy_resume(phydev);
> >> + if (err < 0)
> >> + goto error;
> >> +
> >> + /* Then, the copper link */
> >> + err = phy_write(phydev, MII_MARVELL_PHY_PAGE, MII_M1111_COPPER);
> >> + if (err < 0)
> >> + goto error;
> >> +
> >> + return genphy_resume(phydev);
> >
> > Should it be resumed twice? Or just once at the end? Same question
> > for suspend.
>
> I don't understand your question.
You call genphy_resume(phydev) twice. Once is sufficient.
Andrew
next prev parent reply other threads:[~2016-07-13 13:26 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-04 13:25 FWD: [PATCH v2] Marvell phy: add fiber status check for some components Andrew Lunn
2016-04-08 15:45 ` Charles-Antoine Couret
2016-04-11 19:47 ` Florian Fainelli
2016-04-13 9:27 ` Charles-Antoine Couret
2016-04-29 8:28 ` Charles-Antoine Couret
2016-05-27 9:23 ` Charles-Antoine Couret
2016-06-02 14:56 ` Andrew Lunn
2016-07-12 15:00 ` [PATCH v3] Marvell phy: add fiber status check and configuration for some phys Charles-Antoine Couret
2016-07-12 15:18 ` Andrew Lunn
2016-07-12 15:34 ` Charles-Antoine Couret
2016-07-12 15:57 ` Andrew Lunn
2016-07-13 9:14 ` Charles-Antoine Couret
2016-07-13 13:26 ` Andrew Lunn [this message]
2016-07-13 13:46 ` Charles-Antoine Couret
2016-07-13 15:39 ` 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=20160713132632.GA6667@lunn.ch \
--to=andrew@lunn.ch \
--cc=charles-antoine.couret@nexvision.fr \
--cc=f.fainelli@gmail.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).