All of lore.kernel.org
 help / color / mirror / Atom feed
From: Florian Fainelli <f.fainelli@gmail.com>
To: Ray Jui <rjui@broadcom.com>,
	Kishon Vijay Abraham I <kishon@ti.com>,
	linux-kernel@vger.kernel.org
Subject: Re: How to handle access to multiple PHYs through MDIO
Date: Fri, 16 Jan 2015 17:47:02 -0800	[thread overview]
Message-ID: <54B9BF16.2020608@gmail.com> (raw)
In-Reply-To: <54B9B66C.70308@broadcom.com>

Hi Ray,

On 16/01/15 17:10, Ray Jui wrote:
> Hi,
> 
> Our SoC, Cygnus, uses a generic MDC/MDIO controller to talk to various
> PHYs, including 2 x Ethernet GPHY, 2 x PCIe Serdes, and 3 x USB PHYs. In
> this case, how should I work out a generic PHY driver to handle this?

Interesting, I have typically seen separate MDIO controllers for at
least Ethernet and USB/PCIe/SATA.

> 
> I notice that most generic PHY drivers are in drivers/phy/*, but
> Ethernet seems to have its own interface of talking to a PHY through
> MDIO (drivers/net/phy/*).

That's right, the Ethernet PHY library predates the generic PHY library
from Kishon and they have little to no common ground.

> 
> I need a single driver to handle these so there isn't any race condition
> for this single MDIO access in our system.

How about the following design:

- you create a MDIO bus controller library in e.g:
drivers/phy/cygnus-mdio.c which offers generic generic read/write
operations with a prototype looking like this:

	int mdio_read(void *device, enum device_type, int reg, int addr);
	- int mdio_write(void *device, enum device_type, int reg, int addr, int
value)
	- where device_type is MDIO_DEV_SERDES or MDIO_DEV_GPHY

	- these reads and writes are protected by a local spinlock which is not
exposed to the caller, it just needs to know that it gets serialized
access to the controller

- you write a MDIO controller in drivers/phy/ for the USB and PCIe PHYs
which uses this library and interfaces with Kishon's PHY Library operations

- you create a MDIO bus controller driver in drivers/net/phy/ which also
uses this library and registers with Linux using mdiobus_register()

This is imho the easiest way to achieve what you want here, however, you
could also stash all of what I describe above in a single MDIO bus
driver in drivers/phy/ and ifdef out what is relevant based on your
kernel configuration, up to you, there could be some tricky dependencies
to solve though.
-- 
Florian

  reply	other threads:[~2015-01-17  1:47 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-17  1:10 How to handle access to multiple PHYs through MDIO Ray Jui
2015-01-17  1:47 ` Florian Fainelli [this message]
2015-01-17  3:12   ` Ray Jui

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=54B9BF16.2020608@gmail.com \
    --to=f.fainelli@gmail.com \
    --cc=kishon@ti.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rjui@broadcom.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 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.