Re: How to handle access to multiple PHYs through MDIO

2015-01-16 Thread Ray Jui


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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: How to handle access to multiple PHYs through MDIO

2015-01-16 Thread Florian Fainelli
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


How to handle access to multiple PHYs through MDIO

2015-01-16 Thread Ray Jui
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?

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/*).

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

Thanks,

Ray
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


How to handle access to multiple PHYs through MDIO

2015-01-16 Thread Ray Jui
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?

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/*).

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

Thanks,

Ray
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: How to handle access to multiple PHYs through MDIO

2015-01-16 Thread Florian Fainelli
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
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: How to handle access to multiple PHYs through MDIO

2015-01-16 Thread Ray Jui


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
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/