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]
Message-ID: <51779AF6.8060808@ti.com>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ