[PATCH 3/4] clk: kirkwood: Add CLK_IGNORE_UNUSED to ethernet ge0 and ge1 clocks
Sebastian Hesselbarth
sebastian.hesselbarth at gmail.com
Tue Oct 1 15:15:44 EDT 2013
On 10/01/2013 09:10 PM, Sebastian Hesselbarth wrote:
> On 10/01/2013 06:45 PM, Jason Gunthorpe wrote:
>> On Tue, Oct 01, 2013 at 04:43:54PM +0200, Sebastian Hesselbarth wrote:
>>
>>> The local-mac-address property is a placeholder for the real mac
>>> address. Also, mv643xx_eth calls of_get_mac_address which fails for
>>> the invalid local-mac-address value of [00 00 00 00 00 00].
>>>
>>> If you manage to setup local-mac-address in your bootloader, everything
>>> should be fine.
>>
>> FWIW, my environment is like this, and it works fine (this is recent,
>> 3.10 didn't work). The driver now properly sets the MAC from the DT.
>>
>> The driver will also need an update to call of_get_phy_mode and set
>> the interface properly, and the board files will need update to
>> specify the phy-mode property. I'm guessing things are working for
>> most people because the POR value happens to match the board?
>>
>>> If we have a DT fixup that takes care of the above for non-DT
>>> bootloaders, everything should be fine.
>>
>> Exactly, the problem is a broken DT on input to the kernel, the proper
>> action, IMHO, is to correct the DT in the kernel, so the hacking is
>> contained. Similar to how pci-fixups.c centralizes fixing of broken
>> firmware for PCI, and how CONFIG_ARM_ATAG_DTB_COMPAT centralizes it
>> for ATAG conversion.
>>
>> BTW, why doesn't CONFIG_ARM_ATAG_DTB_COMPAT fix this? Do the boot
>> loaders on these systems not pass the mac at all??
>>
>>> I still prefer Jason's approach and would give it a try on LAKML and
>>> devtree ML: Backup register contents if of_get_mac_address does not
>>> contain a valid address, and gate clocks.
>>
>> FWIW, I would not use the language of 'backup' - this is a fixup
>> correcting an unsupported input DT.
>>
>> IMHO, when this code triggers it should also:
>>
>> printk(KERN_ERROR FW_BUG "local-mac-address is not set");
>
> Ezequiel,
>
> before you jump to prepare a patch for the above, I made one based on
> my previous work and JasonG's suggestions above. Testing it right now,
> looks promising.
And works:
Uncompressing Linux... done, booting the kernel.
[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Linux version 3.12.0-rc3-dirty (hesselba at edge) (gcc
version 4.4.6 (Debian 4.4.6-14) ) #9 PREEMPT Tue Oct 1 21:01:34 CEST 2013
...
[ 0.100128] [Firmware Bug]:
/ocp at f1000000/ethernet-controller at 72000/ethernet0-port at 0:
local-mac-address is not set
...
# cat /sys/kernel/debug/clk/clk_summary
clock enable_cnt prepare_cnt rate
---------------------------------------------------------------------
...
tclk 6 6 200000000
...
ge1 0 0 200000000
...
ge0 0 0 200000000
# insmod mvmdio.ko
[ 172.888802] libphy: orion_mdio_bus: probed
# insmod mv643xx_eth.ko
[ 175.790366] mv643xx_eth: MV-643xx 10/100/1000 ethernet driver version 1.4
[ 176.811888] mv643xx_eth_port mv643xx_eth_port.0 eth0: port 0 with MAC
address 02:50:43:19:fd:e2
> @JasonC: To avoid rebase mess again, where do you want it based against?
More information about the linux-arm-kernel
mailing list