* Arnd Bergmann arnd@arndb.de [150123 05:32]:
On Friday 23 January 2015 13:08:37 Russell King - ARM Linux wrote:
Hi Arnd,
On Fri, Oct 24, 2014 at 5:46 PM, Arnd Bergmann arnd@arndb.de wrote:
There is still a related bug that we should also fix, but I'd say let's take your current patches first and then add whatever is missing on top. Specifically, a snippet like this
default 0xd4017000 if DEBUG_MMP_UART2 default 0xd4018000 if DEBUG_MMP_UART3 default 0xe0000000 if ARCH_SPEAR13XX default 0xe4007000 if DEBUG_HIP04_UART default 0xf0000be0 if ARCH_EBSA110still means you get the wrong default when you build a multiplatform kernel that you want to boot on HIP04 and you set DEBUG_HIP04_UART but you happen to also have ARCH_SPEAR13XX enabled.
I have a patch that I use locally for randconfig builds that tries to fix this. It has some overlaps with your work but most parts are distinct. See below.
This is still desperately needed for anyone who wants to enable DEBUG_LL on other platforms using multi_v7_defconfig.
I'd actually prefer to kill all these defaults and let people enter the value they want - for exactly this reason.
I think it almost works right and seems fixable, but I agree with your long-term direction.
However, I realise that would not be popular, because removing them means that people have to refer to some kind of documentation to find the correct value, and that's hassle.
So, the existing defaulting behaviour is my compromise, but as I say, I'd much prefer the unpopular move of killing the entire set of defaults.
We can probably remove the defaults after we have had working earlycon support for at least one kernel release. My feeling is that a lot of people just enable debug_ll for normal kernels (and pass earlyprintk in the DTB-provided command line!) because the normal console support is just too late to spot when things go wrong, and debug_ll is convenient enough despite the downsides.
earlycon avoids the need for hard configuration and mostly solves the problem of the normal console being initialized too late, so I think we should migrate platforms to use that over time. It's not a problem for backwards compatibility because old dtbs will still work, just without working earlycon when there is no "stdout-path" property.
With that in place, we can put debug_ll back into its destined place, which is to debug the extremely early boot stages before earlycon, and anyone who needs to do that can pick the correct physical addresses themselves. Picking the right virtual address seems to be harder for a lot of people, and everyone gets stuck on this when they first try it. Maybe we can avoid this problem by finding a page into which to put the mapping by default. The fixmap support we need for earlycon should make this easier too.
Totally agree, let's make debug_ll use super limited.
The reasons for why people need debug_ll are currently because of all the custom initcall levels. So far for all the cases I've seen, there should not be any need for custom initcall levels any longer with the deferred probe. The existing cases are all for legacy reasons and should not be needed at all on anything done over past five years or so.
The solution to removing the dependency to debug_ll is SoC specific earlyprintk support. And to initialize everything else later, not earlier.
Cheers,
Tony