From: Simon Horman <horms@verge.net.au>
To: linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH/RFC v2 net-next 1/4] phylib: Add phy_set_max_speed helper
Date: Fri, 11 Sep 2015 04:30:11 +0000 [thread overview]
Message-ID: <20150911043011.GA20882@verge.net.au> (raw)
In-Reply-To: <55F2552A.1010509@gmail.com>
On Thu, Sep 10, 2015 at 09:14:34PM -0700, Florian Fainelli wrote:
> Le 09/10/15 19:01, Simon Horman a écrit :
> > Add a helper to allow ethernet drivers to limit the speed of a phy
> > (that they are attached to).
> >
> > This mainly involves factoring out the business-end of
> > of_set_phy_supported() and exporting a new symbol.
> >
> > This code seems to be open coded in several places, in several different
> > variants.
> >
> > This code is envisaged this will be used in situations where setting
> > the "max-speed" property is not appropriate, e.g. because the maximum
> > speed is not a property of the phy hardware.
>
> This looks good to me, one minor comment, see below:
>
> >
> > Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
> >
> > ---
> >
> > v2
> > * First post
> > ---
> > drivers/net/phy/phy_device.c | 52 ++++++++++++++++++++++++++++----------------
> > include/linux/phy.h | 1 +
> > 2 files changed, 34 insertions(+), 19 deletions(-)
> >
> > diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
> > index c0f211127274..d9a020095972 100644
> > --- a/drivers/net/phy/phy_device.c
> > +++ b/drivers/net/phy/phy_device.c
> > @@ -1205,6 +1205,37 @@ static int gen10g_resume(struct phy_device *phydev)
> > return 0;
> > }
> >
> > +static void __set_phy_supported(struct phy_device *phydev, u32 max_speed)
> > +{
> > + if (!IS_ENABLED(CONFIG_OF_MDIO))
> > + return;
>
> I think that part should be moved to of_set_phy_supported(), since your
> are exporting phy_set_max_speed() which should therefore be available
> regardless of whether Device Tree is used.
Yes of course, silly me.
> While you are it, it might be nice to either warn or return -ENOTSUPP if
> the speed does not match 10, 100 or 1000, but that might be worth a
> second patch.
Sure, that sounds reasonable.
next prev parent reply other threads:[~2015-09-11 4:30 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-11 2:01 [PATCH/RFC v2 net-next 0/4] ravb: Add support for r8a7795 SoC Simon Horman
2015-09-11 2:01 ` [PATCH/RFC v2 net-next 1/4] phylib: Add phy_set_max_speed helper Simon Horman
2015-09-11 4:14 ` Florian Fainelli
2015-09-11 4:30 ` Simon Horman [this message]
2015-09-11 13:34 ` Sergei Shtylyov
2015-09-11 2:01 ` [PATCH/RFC v2 net-next 2/4] ravb: Provide dev parameter to DMA API Simon Horman
2015-09-11 2:01 ` [PATCH/RFC v2 net-next 3/4] ravb: Document binding for r8a7795 SoC Simon Horman
2015-09-11 7:12 ` Geert Uytterhoeven
2015-09-11 8:14 ` Simon Horman
2015-09-11 8:41 ` Geert Uytterhoeven
2015-09-11 8:53 ` Simon Horman
2015-09-11 14:25 ` Sergei Shtylyov
2015-09-14 0:42 ` Simon Horman
2015-09-30 18:26 ` Sergei Shtylyov
2015-09-11 2:01 ` [PATCH/RFC v2 net-next 4/4] ravb: Add support " Simon Horman
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=20150911043011.GA20882@verge.net.au \
--to=horms@verge.net.au \
--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 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).