netdev - Re: [net-next PATCH 0/3] Adding phy register fixup in DT

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] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 24 Apr 2013 14:12:30 +0530
From:	Mugunthan V N <mugunthanvnm@...com>
To:	Sascha Hauer <s.hauer@...gutronix.de>
CC:	<netdev@...r.kernel.org>, <devicetree-discuss@...ts.ozlabs.org>,
	<linux-omap@...r.kernel.org>, <davem@...emloft.net>
Subject: Re: [net-next PATCH 0/3] Adding phy register fixup in DT

On 4/23/2013 1:32 PM, Sascha Hauer wrote:
> On Mon, Apr 22, 2013 at 11:50:35PM +0530, Mugunthan V N wrote:
>> In earlier days phy fixup was added to phy frame work in board files.
>> As there won't be any board files here after the same has to be done in DT
>> This patch series adds the following features
>> * support for adding phy resigter fixup via DT
>> * adds phy id for EVMsk n DTS file
>> * adds phy fixup for AM335x EVM and EVMsk
>>
>> Mugunthan V N (3):
>>    drivers: of: add phy fixup support in DT
>>    ARM: dts: AM33XX: Add CPSW phy_id device tree data to am335x-evmsk
>>    ARM: dts: AM33XX: add phy fixup for evm and evmsk boards
> I generally do not offend to phy fixups from the devicetree. I see
> though that becomes more and more common that we have to configure
> the tx delays in phys.
>
> The current way seems to be to hardcode register values for each board
> which seems not very flexible and forces us to read phy datasheets
> each time for a new board.
>
> Wouldn't it make more sense to configure the actual delays (in ns) and
> let the phy drivers figure out how to turn this into register values?
>
> Not that I volunteer to write such things... :-/
>
There is no calculation done for enabling RGMII Tx internal delay. Its all
pre-calculated in Hardware (Either in Phy or EMAC)
In this patch as CPSW IP in AM335x doesn't support internal delay inside
SoC, so enabling the same in Phy and it is just a bit set in the phy debug
registers

Regards
Mugunthan V N
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html