All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Lunn <andrew@lunn.ch>
To: Russell King - ARM Linux <linux@armlinux.org.uk>
Cc: Florian Fainelli <f.fainelli@gmail.com>, netdev@vger.kernel.org
Subject: Re: [PATCH RFC 0/4] Fixes for Marvell MII paged register access races
Date: Fri, 8 Dec 2017 17:17:14 +0100	[thread overview]
Message-ID: <20171208161714.GC30846@lunn.ch> (raw)
In-Reply-To: <20171208154756.GF10595@n2100.armlinux.org.uk>

Hi Russell

> There is an open question whether there should be generic helpers for
> this.  Generic helpers would mean:
> 
> - Additional couple of function pointers in phy_driver to read/write the
>   paging register.  This has the restriction that there must only be one
>   paging register.

I must be missing something. I don't see why there is this
restriction. Don't we just need

int phy_get_page(phydev);
int phy_set_page(phydev, page);

We might even be able to do without phy_get_page(), if we assume page
0 should be selected by default, and all paged reads/write return to
page 0 afterwards.

> - The helpers become more expensive, and because they're in a separate
>   compilation unit, the compiler will be unable to optimise them by
>   inlining the static functions.

The mdio bus is slow. Often there is a completion function triggered
by an interrupt etc. Worst case it is bit-banging. I suspect the gains
from inlining are just noise in the bigger picture.

> - The helpers would be re-usable, saving replications of that code, and
>   making it more likely for phy authors to safely access the PHY.

This is the key point for me. This has likely to of been broken for
years. If it is obviously broken, driver writers are more likely to
get it right. Here it is not obvious, so we should take it out of the
driver writers hands and do it in the core.

> Another potential question is whether using the mdiobus lock (which
> excludes all other MII bus access) is best - while it has the advantage
> of also ensuring atomicity with userspace accesses, it means that no one
> else can access an independent PHY on the same bus while a paged access
> is on-going.  It feels like a big hammer, but I'm not convinced that we
> will see a lot of contention on it.

I think you are right about there being little contention on the lock.
I suspect most paged accesses are performed during initial setup and
configuration. I guess the once per second poll does not need to use
paged registers. And the weight of that hammer can be reduced a lot by
using interrupts instead of polling.

      Andrew

  parent reply	other threads:[~2017-12-08 16:17 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-08 15:47 [PATCH RFC 0/4] Fixes for Marvell MII paged register access races Russell King - ARM Linux
2017-12-08 15:48 ` [PATCH RFC 1/4] net: mdiobus: add unlocked accessors Russell King
2017-12-09 18:20   ` Florian Fainelli
2017-12-08 15:48 ` [PATCH RFC 2/4] net: phy: use unlocked accessors for indirect MMD accesses Russell King
2017-12-09 18:21   ` Florian Fainelli
2017-12-08 15:48 ` [PATCH RFC 3/4] net: phy: add unlocked accessors Russell King
2017-12-09 18:22   ` Florian Fainelli
2017-12-09 23:11     ` Russell King - ARM Linux
2017-12-08 15:48 ` [PATCH RFC 4/4] net: phy: marvell: fix paged access races Russell King
2017-12-08 16:17 ` Andrew Lunn [this message]
2017-12-08 16:44   ` [PATCH RFC 0/4] Fixes for Marvell MII paged register " Russell King - ARM Linux
2017-12-09 18:22     ` Florian Fainelli
2017-12-09 23:49       ` Russell King - ARM Linux
2017-12-10  0:19         ` Andrew Lunn
2017-12-09 18:19 ` Florian Fainelli
2017-12-09 19:06   ` 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=20171208161714.GC30846@lunn.ch \
    --to=andrew@lunn.ch \
    --cc=f.fainelli@gmail.com \
    --cc=linux@armlinux.org.uk \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.