On Wed, 15 Nov 2017 13:16:48 +0100, Mark Brown wrote:
On Wed, Nov 15, 2017 at 12:58:40PM +0100, Takashi Iwai wrote:
Mark Brown wrote:
On Wed, Nov 15, 2017 at 08:34:09AM +0100, Takashi Iwai wrote:
Though transitioning back would probably just create more misery. It's a real shame that ACPI doesn't have standards for the machine descriptions here like DT does, it'd cut down on the amount of stuff that needs configuring.
True. Although I don't think ACPI is the center of the mess in this case, but rather too many kconfigs is it.
It's the source of all the individual board Kconfigs - we can't just have an equivalent of the of-graph card - and then the explosion of board configs then pushes to have more of the other options user selectable to let people make the list more manageable.
OK, point taken.
We should begin with thinking of which entries (and layer) to be selectable, and which not.
I'd say either just all the individual machines like it was or all the SoCs. If it's the SoCs it prevents people making really tiny configs, though I'm not sure who cares. If it's the machines then you get a lot of options but I don't know that this is a problem, it's not like end users are routinely configuring their kernel.
It might sound contradicting to my previous statement, but the number of selections itself isn't a big problem. The problem is rather that multiple options have to be selected for reaching to the point to enable one feature on your machine. So, I agree that these two representations would be suitable, and the usual solution is the firmer, to expose *only* individual machine drivers as selectable. (Or, at most, we can have kconfig entries just filtering in addition.)
Takashi