There's no reason for a board without HyperTransport to compile it in. This patch removes it (saving 1K after compression.)
I would have liked to set HYPERTRANSPORT_PLUGIN_SUPPORT the same way, but couldn't figure out how. I don't think plugin support for HT makes sense...
kbuildall tested.
Signed-off-by: Myles Watson mylesgw@gmail.com
Thanks, Myles
mylesgw wrote:
+config HT_CHAIN_UNITID_BASE
- hex
- default 0x0
- depends on BOARD_ASUS_M2V_MX_SE
..
+config SB_HT_CHAIN_UNITID_OFFSET_ONLY +config SB_HT_CHAIN_ON_BUS0 +config HT_CHAIN_END_UNITID_BASE
..
Does it make sense to try to keep these out of board-specific Kconfigs?
Are they typically always different on all boards?
I'm thinking that it would be nice to have the board just set CONFIG_HYPERTRANSPORT and nothing else, and have the individual values included when that is set.
But for that to make sense each board should not need to override most of these values.
//Peter
On Thu, Sep 24, 2009 at 8:34 AM, Peter Stuge peter@stuge.se wrote:
mylesgw wrote:
+config HT_CHAIN_UNITID_BASE
hex
default 0x0
depends on BOARD_ASUS_M2V_MX_SE
..
+config SB_HT_CHAIN_UNITID_OFFSET_ONLY +config SB_HT_CHAIN_ON_BUS0 +config HT_CHAIN_END_UNITID_BASE
..
Does it make sense to try to keep these out of board-specific Kconfigs?
I don't think they should be handled by Kconfig at all, but the current HT code needs them defined, and they are very board-specific (actually most of the time they are HT chain specific). I think the best way would be to specify each HT chain's values in the device tree.
Thanks, Myles
mylesgw wrote:
Does it make sense to try to keep these out of board-specific Kconfigs?
I don't think they should be handled by Kconfig at all, but the current HT code needs them defined, and they are very board-specific
Ok.
I think the best way would be to specify each HT chain's values in the device tree.
I like that. Values "belonging" to the source code is kept in the device tree, Kconfig is closer to the user who builds the code.
//Peter