From: Ray Jui <rjui@broadcom.com>
To: Florian Fainelli <f.fainelli@gmail.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 19:12:41 -0800 [thread overview]
Message-ID: <54B9D329.2050201@broadcom.com> (raw)
In-Reply-To: <54B9BF16.2020608@gmail.com>
On 1/16/2015 5:47 PM, Florian Fainelli wrote:
> 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.
>
Thanks, Florian. This makes sense to me.
Note this means I'll need to create public headers under include/linux
for the mdio library. But yes, having a shared mdio library and
protected with spinlock is the only way to guarantee serialized access
to the mdio controller.
Ray
prev parent reply other threads:[~2015-01-17 3:12 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
2015-01-17 3:12 ` Ray Jui [this message]
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=54B9D329.2050201@broadcom.com \
--to=rjui@broadcom.com \
--cc=f.fainelli@gmail.com \
--cc=kishon@ti.com \
--cc=linux-kernel@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.