can someone explain this CONFIG_COMMANDS, CFG_CMD thing?
i'm looking at some of the stuff sascha commented on earlier, like:
$ grep -r CONFIG_MII drivers drivers/net/Makefile:obj-$(CONFIG_MIIPHY) += miiphy.o drivers/net/at91_ether.c:#if defined(CONFIG_MII) || (CONFIG_COMMANDS & CFG_CMD_MII) drivers/net/at91_ether.c:#endif /* defined(CONFIG_MII) || (CONFIG_COMMANDS & CFG_CMD_MII) */ drivers/net/at91_ether.c:#if defined(CONFIG_MII) || (CONFIG_COMMANDS & CFG_CMD_MII) $
and i'd like to clarify what any of that is *supposed* to mean.
first, what means "CONFIG_COMMANDS"? that is, in the sense that
you're *bitwise* or'ing it with something else? is that supposed to be a test that a command has been selected for inclusion? surely there's a cleaner way to do that.
and what would the difference be between CONFIG_MII and CFG_CMD_MII?
as i read it (and i could be totally out to lunch), something like CONFIG_MII would be selecting a particular *feature* to build in, while CFG_CMD_MII would be selecting the actual "mii" command, is that it?
but should those two selections be independently selectable?
possibly -- i can imagine an argument that that should be true. but in a perfect world, how should all this be done? personally, i can imagine selecting *features* one by one and, for each feature, selecting any of the relevant and associated commands.
so (as a random example), i might first select MII support withCONFIG_MII, then separately select to include the "mii" command with CONFIG_CMD_MII. and commands should be Kconfig dependent on their associated feature, so that there would be no need to test
#if defined(CONFIG_MII) && defined(CONFIG_CMD_MII)
it would be sufficient to test
#if defined(CONFIG_CMD_MII)
or am i completely misreading what should be happening here?
rday
--
========================================================================
Robert P. J. Day Waterloo, Ontario, CANADA
Linux Consulting, Training and Kernel Pedantry.
Web page: http://crashcourse.ca Twitter: http://twitter.com/rpjday
========================================================================
_______________________________________________
barebox mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/barebox
Quoted 10 lines · Robert P. J. Day
i'm looking at some of the stuff sascha commented on earlier, like:
$ grep -r CONFIG_MII drivers drivers/net/Makefile:obj-$(CONFIG_MIIPHY) += miiphy.o drivers/net/at91_ether.c:#if defined(CONFIG_MII) || (CONFIG_COMMANDS & CFG_CMD_MII) drivers/net/at91_ether.c:#endif /* defined(CONFIG_MII) || (CONFIG_COMMANDS & CFG_CMD_MII) */ drivers/net/at91_ether.c:#if defined(CONFIG_MII) || (CONFIG_COMMANDS & CFG_CMD_MII) $
Quoted 6 lines
and i'd like to clarify what any of that is *supposed* to mean.
first, what means "
CONFIG_COMMANDS"? that is, in the sense that
you're *bitwise* or'ing it with something else? is that supposed to be a test that a command has been selected for inclusion? surely there's a cleaner way to do that.
Forget about CONFIG_COMMANDS. This is from old U-Boot and is a bitmask for the available commands. CFG_CMD_MII was one bit of this command mask. Someday they realized that they want to support more than 32 commands and got rid of it.
The parts you are referring to should simply be
#if defined(CONFIG_MII)
Hm, looking closer at it this part of the at91 ethernet driver is outdated. Compare to the other ethernet drivers to get an idea how phys are handled now. Maybe I'll fix this after christmas.
Sascha
Signature · 9 lines
Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | _______________________________________________ barebox mailing list [email protected] http://lists.infradead.org/mailman/listinfo/barebox