On 3/30/22 14:16, Marek Behún wrote:
On Wed, 30 Mar 2022 10:38:25 +0200
Stefan Roese <s...@denx.de> wrote:
This patch adds support for the "marvell,reg-init" DT property, which
is used to describe board specific Marvell PHY register configurations
in the board dts file. This DT property is supported in the Linux Kernel
since a longer time. Adding it to U-Boot now, enables the boards which
describe the register settings in their DT files here as well.
I've included calling this marvell_of_reg_init() to all foo_config()
functions in this patch as well. If CONFIG_DM_ETH is not set, there is
no ofnode, or no "marvell,reg-init" property, the PHY initialization is
unchanged.
The function marvell_of_reg_init() is a port of the Linux version.
Please note that I explicitly did not add error checking and handling
to the U-Boot version, as this is basically not done for phy_read/write
in this Marvell PHY code.
This will be used by the upcoming ethernet support on the MIPS
Octeon EBB 7304 board.
Signed-off-by: Stefan Roese <s...@denx.de>
Cc: Ramon Fried <rfried....@gmail.com>
Cc: Joe Hershberger <joe.hershber...@ni.com>
Cc: Aaron Williams <awilli...@marvell.com>
Cc: Chandrakala Chavva <ccha...@marvell.com>
Hi Stefan, I know this property is used also in kernel, but what do you
want to use it for?
Frankly, I do not know exactly. It's part of the MIPS Octeon ethernet
support in mainline U-Boot, which also uses this DT property on the
EBB7304 board. I've not analyzed the register settings in detail to
check which register is being configured to which value to see, why this
might be the case. Dropping these register settings might have resulted
in problems not directly spotted on the board. So my plan was to
integrate these as well.
For reference, I've added the current DT reg-init setting below [1].
This is for the 88e1240 PHY, and taking a quick look in the manual,
this seems to be LED related (see below).
Because in kernel the idea is to deprecate it.
This is new to me.
It is used for example to confiure INT pin, but that should have it's
own property once someone implements it. It is also used to configure
LEDs, and that is hopefully gonna be obsoleted by supporting the LEDs
via the LED subsystem, so afterwards we will write
ethernet-phy@1 {
leds {
led@0 {
color = ...;
};
};
};
That would be very cool indeed. Even though it's not possible "right
now".
So how to continue? Add this "reg-init" "feature" for now? And perhaps
drop it once this LED configuration is possible via the way you describe
above? Or drop it once it's also dropped in the Kernel? My personal
feeling is, that supporting "reg-init" does not "hurt" and might even be
handy for some testing / debugging of network PHY setups.
Perhaps Ramon and/or Joe also have some comments on this.
Thanks,
Stefan
[1] marvell,reg-init = <3 0x10 0 0x8665>,
<3 0x11 0 0x00aa>,
<3 0x12 0 0x4105>,
<3 0x13 0 0x8a08>;
