linux-kernel - Re: [PATCH] Add Broadcom PHY support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Tue, 5 Dec 2006 13:50:22 -0600
From:	Andy Fleming <afleming@...escale.com>
To:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
Cc:	Amy Fong <amy.fong@...driver.com>, linux-kernel@...r.kernel.org,
	netdev@...r.kernel.org, jeff@...zik.org
Subject: Re: [PATCH] Add Broadcom PHY support

On Dec 5, 2006, at 00:03, Benjamin Herrenschmidt wrote:

>
>> I believe that this fiber enabling can be done by defining  
>> config_init in the phy_driver struct.
>>
>> struct phy_driver {
>> <snip>
>>         /* Called to initialize the PHY,
>> 	 * including after a reset */
>> 	int (*config_init)(struct phy_device *phydev);
>> <snip>
>> };
>
> Well... I don't know for sure... thing is, enabling the fiber mode  
> is a
> rather platform specific thing. So it's the MAC driver that knows  
> wether
> it wants it on a PHY and should call into the driver.
>
> It's difficult to abstract all possible PHY config options tho... some
> MACs might want to enable low power, some don't because they have  
> issues
> with it, that sort of thing, though.
>
> Not sure what the best solution is at this point... Maybe an ascii
> string to pass the PHY driver is the most flexible, though a bit  
> yucky,
> or we try to have a list of all the possible configuration options in
> phy.h and people just add new ones that they need as they add support
> for them...
>
> Sounds grossly like an in-kernel ioctl tho...

Each phy_device structure now has a dev_flags field that can be  
modified by the controller's code upon connecting.  The PHY driver  
can then check that field for PHY-specific, platform-specific  
interactions.  For instance, on the newer CDS, there's a Marvell PHY  
which requires configurable resistance changes to work in RGMII  
mode.  So there's a flag for that.  Basically, each PHY driver  
specifies its own flags, and the platform code is currently  
responsible for setting those flags appropriately.  A string might be  
more flexible, but I'm operating on the hope that there shouldn't be  
too many of these.

For Fiber mode, or other such changes, we might want to add another  
field, like the interface field, to describe standard external  
interfaces.  The call to phy_connect() is beginning to get a bit  
long, though.

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