On Tue, May 20, 2014 at 05:35:03PM +0200, Thomas Petazzoni wrote:

Currently CONFIG_SMP_ON_UP is used when CONFIG_SMP is enabled to allow
a SMP kernel to boot on UP platforms that do not support certain
aspects of SMP platforms.

However, some of the SMP characteristics are needed on platforms that
have SMP capabilities but are single core, and use their SMP
capabilities to provide hardware I/O coherency. This is for example
the case on Marvell Armada platforms.

Instead of special casing these platforms to enable the SMP and TLB
broadcast bit and use shareable pages, this patch proposes to simply
allow CONFIG_SMP_ON_UP to be enabled even on non-SMP
configurations. When CONFIG_SMP_ON_UP is enabled in a !CONFIG_SMP
configuration, it will check that the processor is SMP capable, and if
yes use all the SMP characteristics (SMP and TLB broadcast bit,
shareable pages, etc.). It will not support multiprocessing of course,
but it will have sufficient capabilities to allow hardware I/O
coherency to work.

Signed-off-by: Thomas Petazzoni <redacted>
---
Of course, the name of CONFIG_SMP_ON_UP is maybe no longer
appropriate. Suggestions are welcome to change this: this patch is
really the minimal set of changes to get things to work.

We could also decide to completely get rid of CONFIG_SMP_ON_UP and
make it always on. Suggestions welcome.

This feels very wrong - while you may need a SCU for coherency, which
implies that you have a SMP capable CPU, this feels very much like
overloading a currently well-defined facility with a well-defined
purpose (which gets used for a lot of things) with a new purpose, which
is going to be painful in the future if we ever need to separate the
two things.  So no, I really don't like this.

If we need to change things here, make the change properly even if it
means that it takes more time, and don't do quick sticky-plasters like
this - the quick sticky-plaster method ultimately makes stuff less
maintainable.

Secondly, doesn't this make your first patch redundant - if you need the
SMP instructions, then is_smp() returns true, which then forces WBWA
cache mode.

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.