[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:10:10 EDT 2013


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.

@JasonC: To avoid rebase mess again, where do you want it based against?

Sebastian




More information about the linux-arm-kernel mailing list