[U-Boot] [PATCH] fm-eth: Add ability for board code to disable a port
Kumar Gala
galak at kernel.crashing.org
Thu Sep 15 07:27:13 CEST 2011
On Sep 15, 2011, at 12:11 AM, Wolfgang Denk wrote:
> Dear Kumar Gala,
>
> In message <D144BA6D-B90C-46CD-BE7F-6197015676BB at kernel.crashing.org> you wrote:
>>
>> Now you could say that we should deal with this via #defines. Which is
>> true, however our reference boards allow for running in hundreds if not
>> thousands of various possible HW configurations and we've tried to avoid
>> having different builds for such things unless completely unavoidable.
>
> Understood and agreed.
>
>> So this gives the option to the board code to disable things if it knows
>> based on some other information. In the specific case for the P3060QDS
>> board, we have "add-on" cards that provide 4-ports of 1-gig SGMII. We
>> can detect if one of these cards is in a slot. If the card is missing
>> we can 'disable' the ports associated with the slot.
>
> Well, can you not turn this logic around, and come up in a
> configuration with all ports disabled, and then enable only those
> ports that are actually present? That appears to make much more sense
> to me. Eventually it is even more efficient in terms of things
> likepower cinsumption etc. ?
Unfortuantely not. The HW makes the assumption you turn things off, not on. Once we turn something 'off' in the HW we can't turn it back 'on' as the SoC will gate the power to the block and only a hard reset will bring it back up.
> [In the long run (maybe not so long actually) you can even do this
> device tree based …]
- k
More information about the U-Boot
mailing list