user-mode-linux-devel

Re: [uml-devel] current_thread_info() returns invalid pointer in early UML boot code

[Richard W. <ric...@gm...>]

On Sat, May 21, 2016 at 3:51 PM, Vegard Nossum <veg...@gm...> wrote:
> Hi people,
>
> I'm having some trouble with using current_thread_info() during UML
> early boot. Sometimes it works just fine, but often I get segfaults
> because current_thread_info() is returning an invalid pointer. It
> looks random: 0x202118, 0x1003e0003, 0xd33b90b3, 0x6db043, etc.

Where do you use it?
Can you rule out a bad compiler optimization?
(We had such an issue a few years ago)

> Does anybody understand fully what's going on here, why it returns
> those invalid (seemingly random) values? If the problem is that we're
> on a wrong stack, can we switch stacks earlier during boot or
> something to make current_thread_info() always return a valid
> thread_info pointer?

Can't say much without more details.

-- 
Thanks,
//richard

Re: [uml-devel] current_thread_info() returns invalid pointer in early UML boot code

[Thomas M. <th...@m3...>]

Hi,

Mhh. Strange. Do you have a stack trace to call to current thread info which ends up with a wrong value. I wonder from were it originates.

With kind regards 
Thomas


With kind regards
Thomas

> Am 21.05.2016 um 15:51 schrieb Vegard Nossum <veg...@gm...>:
> 
> Hi people,
> 
> I'm having some trouble with using current_thread_info() during UML
> early boot. Sometimes it works just fine, but often I get segfaults
> because current_thread_info() is returning an invalid pointer. It
> looks random: 0x202118, 0x1003e0003, 0xd33b90b3, 0x6db043, etc.
> 
> I found an earlier thread which described the same problem:
> http://permalink.gmane.org/gmane.linux.uml.devel/14642
> 
> However, I think the patch there is a bit hacky/papers over an
> underlying bug, since it just uses is_kernel_addr() before deciding
> whether to return the pointer from current_thread_info() or not. The
> fact that the crash is random leads me to think it's some sort of race
> during the UML boot.
> 
> Does anybody understand fully what's going on here, why it returns
> those invalid (seemingly random) values? If the problem is that we're
> on a wrong stack, can we switch stacks earlier during boot or
> something to make current_thread_info() always return a valid
> thread_info pointer?
> 
> Thanks,
> 
> 
> Vegard
> 
> ------------------------------------------------------------------------------
> Mobile security can be enabling, not merely restricting. Employees who
> bring their own devices (BYOD) to work are irked by the imposition of MDM
> restrictions. Mobile Device Manager Plus allows you to control only the
> apps on BYO-devices by containerizing them, leaving personal data untouched!
> https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
> _______________________________________________
> User-mode-linux-devel mailing list
> Use...@li...
> https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

[uml-devel] [PATCH v2] um: support kcov

[Vegard N. <veg...@or...>]

This adds support for kcov to UML.

There is a small problem where UML will randomly segfault during boot;
this is because current_thread_info() occasionally returns an invalid
(non-NULL) pointer and we try to dereference it in
__sanitizer_cov_trace_pc(). I consider this a bug in UML itself and this
patch merely exposes it.

[v2: disable instrumentation in UML-specific code]

Cc: Quentin Casasnovas <que...@or...>
Cc: Richard Weinberger <ri...@no...>
Cc: Thomas Meyer <th...@m3...>
Cc: user-mode-linux-devel <use...@li...>
Cc: Dmitry Vyukov <dv...@go...>
Signed-off-by: Vegard Nossum <veg...@or...>
---
 arch/um/Kconfig.common    | 1 +
 arch/um/kernel/Makefile   | 5 +++++
 arch/um/os-Linux/Makefile | 3 +++
 arch/x86/um/vdso/Makefile | 3 +++
 4 files changed, 12 insertions(+)

diff --git a/arch/um/Kconfig.common b/arch/um/Kconfig.common
index cc00134..64c1d46 100644
--- a/arch/um/Kconfig.common
+++ b/arch/um/Kconfig.common
@@ -1,6 +1,7 @@
 config UML
 	bool
 	default y
+	select ARCH_HAS_KCOV
 	select HAVE_ARCH_AUDITSYSCALL
 	select HAVE_ARCH_SECCOMP_FILTER
 	select HAVE_UID16
diff --git a/arch/um/kernel/Makefile b/arch/um/kernel/Makefile
index a6a5e42..2f36d51 100644
--- a/arch/um/kernel/Makefile
+++ b/arch/um/kernel/Makefile
@@ -3,6 +3,11 @@
 # Licensed under the GPL
 #
 
+# Don't instrument UML-specific code; without this, we may crash when
+# accessing the instrumentation buffer for the first time from the
+# kernel.
+KCOV_INSTRUMENT                := n
+
 CPPFLAGS_vmlinux.lds := -DSTART=$(LDS_START)		\
                         -DELF_ARCH=$(LDS_ELF_ARCH)	\
                         -DELF_FORMAT=$(LDS_ELF_FORMAT)	\
diff --git a/arch/um/os-Linux/Makefile b/arch/um/os-Linux/Makefile
index 08ff509..ada473b 100644
--- a/arch/um/os-Linux/Makefile
+++ b/arch/um/os-Linux/Makefile
@@ -3,6 +3,9 @@
 # Licensed under the GPL
 #
 
+# Don't instrument UML-specific code
+KCOV_INSTRUMENT                := n
+
 obj-y = aio.o execvp.o file.o helper.o irq.o main.o mem.o process.o \
 	registers.o sigio.o signal.o start_up.o time.o tty.o \
 	umid.o user_syms.o util.o drivers/ skas/
diff --git a/arch/x86/um/vdso/Makefile b/arch/x86/um/vdso/Makefile
index 6c803ca..d72dec4 100644
--- a/arch/x86/um/vdso/Makefile
+++ b/arch/x86/um/vdso/Makefile
@@ -2,6 +2,9 @@
 # Building vDSO images for x86.
 #
 
+# Prevents link failures: __sanitizer_cov_trace_pc() is not linked in.
+KCOV_INSTRUMENT                := n
+
 VDSO64-y		:= y
 
 vdso-install-$(VDSO64-y)	+= vdso.so
-- 
1.9.1

Re: [uml-devel] [PATCH] um: support kcov

[Vegard N. <veg...@or...>]

On 05/21/2016 04:05 PM, Dmitry Vyukov wrote:
> On Sat, May 21, 2016 at 4:03 PM, Vegard Nossum <veg...@or...
> <mailto:veg...@or...>> wrote:
>
>     This adds support for kcov to UML.
>
[...]
> Acked-by: Dmitry Vyukov <dv...@go... <mailto:dv...@go...>>
>
> Cool! How do you plan to use it?

We have a patch for kcov itself adding the AFL mode coming up very soon
:-) We've been doing almost all our filesystem (and other) AFL fuzzing
in UML instances as we found it gave a really big performance boost over
KVM.


Vegard

[uml-devel] [PATCH] um: support kcov

[Vegard N. <veg...@or...>]

This adds support for kcov to UML.

There is a small problem where UML will randomly segfault during boot;
this is because current_thread_info() occasionally returns an invalid
(non-NULL) pointer and we try to dereference it in
__sanitizer_cov_trace_pc(). I consider this a bug in UML itself and this
patch merely exposes it.

Cc: Quentin Casasnovas <que...@or...>
Cc: Richard Weinberger <ri...@no...>
Cc: Thomas Meyer <th...@m3...>
Cc: user-mode-linux-devel <use...@li...>
Cc: Dmitry Vyukov <dv...@go...>
Signed-off-by: Vegard Nossum <veg...@or...>
---
 arch/um/Kconfig.common    | 1 +
 arch/x86/um/vdso/Makefile | 3 +++
 2 files changed, 4 insertions(+)

diff --git a/arch/um/Kconfig.common b/arch/um/Kconfig.common
index cc00134..64c1d46 100644
--- a/arch/um/Kconfig.common
+++ b/arch/um/Kconfig.common
@@ -1,6 +1,7 @@
 config UML
 	bool
 	default y
+	select ARCH_HAS_KCOV
 	select HAVE_ARCH_AUDITSYSCALL
 	select HAVE_ARCH_SECCOMP_FILTER
 	select HAVE_UID16
diff --git a/arch/x86/um/vdso/Makefile b/arch/x86/um/vdso/Makefile
index 6c803ca..d72dec4 100644
--- a/arch/x86/um/vdso/Makefile
+++ b/arch/x86/um/vdso/Makefile
@@ -2,6 +2,9 @@
 # Building vDSO images for x86.
 #
 
+# Prevents link failures: __sanitizer_cov_trace_pc() is not linked in.
+KCOV_INSTRUMENT                := n
+
 VDSO64-y		:= y
 
 vdso-install-$(VDSO64-y)	+= vdso.so
-- 
1.9.1

[uml-devel] current_thread_info() returns invalid pointer in early UML boot code

[Vegard N. <veg...@gm...>]

Hi people,

I'm having some trouble with using current_thread_info() during UML
early boot. Sometimes it works just fine, but often I get segfaults
because current_thread_info() is returning an invalid pointer. It
looks random: 0x202118, 0x1003e0003, 0xd33b90b3, 0x6db043, etc.

I found an earlier thread which described the same problem:
http://permalink.gmane.org/gmane.linux.uml.devel/14642

However, I think the patch there is a bit hacky/papers over an
underlying bug, since it just uses is_kernel_addr() before deciding
whether to return the pointer from current_thread_info() or not. The
fact that the crash is random leads me to think it's some sort of race
during the UML boot.

Does anybody understand fully what's going on here, why it returns
those invalid (seemingly random) values? If the problem is that we're
on a wrong stack, can we switch stacks earlier during boot or
something to make current_thread_info() always return a valid
thread_info pointer?

Thanks,


Vegard

Re: [uml-devel] [PATCH 0263/1529] Fix typo

[Anton I. <ai...@Br...>]

On 21/05/16 13:11, Andrea Gelmini wrote:
> Signed-off-by: Andrea Gelmini <and...@ge...>
> ---
>   arch/um/os-Linux/time.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/um/os-Linux/time.c b/arch/um/os-Linux/time.c
> index 0e39b99..6caa556 100644
> --- a/arch/um/os-Linux/time.c
> +++ b/arch/um/os-Linux/time.c
> @@ -91,7 +91,7 @@ int os_timer_set_interval(void* timer, void* i)
>   /**
>    * os_timer_remain() - returns the remaining nano seconds of the given interval
>    *                     timer
> - * Because this is the remaining time of an interval timer, which correspondends
> + * Because this is the remaining time of an interval timer, which correspondences

corresponds.

>    * to HZ, this value can never be bigger than one second. Just
>    * the nanosecond part of the timer is returned.
>    * The returned time is relative to the start time of the interval timer.

[uml-devel] [PATCH 0263/1529] Fix typo

[Andrea G. <and...@ge...>]

Signed-off-by: Andrea Gelmini <and...@ge...>
---
 arch/um/os-Linux/time.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/um/os-Linux/time.c b/arch/um/os-Linux/time.c
index 0e39b99..6caa556 100644
--- a/arch/um/os-Linux/time.c
+++ b/arch/um/os-Linux/time.c
@@ -91,7 +91,7 @@ int os_timer_set_interval(void* timer, void* i)
 /**
  * os_timer_remain() - returns the remaining nano seconds of the given interval
  *                     timer
- * Because this is the remaining time of an interval timer, which correspondends
+ * Because this is the remaining time of an interval timer, which correspondences
  * to HZ, this value can never be bigger than one second. Just
  * the nanosecond part of the timer is returned.
  * The returned time is relative to the start time of the interval timer.
-- 
2.8.2.534.g1f66975

Re: [uml-devel] [PATCH v3 0/3] um: fix and extend FPU support

[Richard W. <ri...@no...>]

Am 20.05.2016 17:31 schrieb Eli Cooper <eli...@gm...>:
>
> On 2016/4/5 5:42, Richard Weinberger wrote: 
> > Sorry for my late response. 
> > I'll put this now into -next and give it some testing. 
>
> Ping? 
>
> It has been some time but I don't see this in -next yet. 

Sorry, I'm late. It will hit next tomorrow.

Re: [uml-devel] [PATCH v3 0/3] um: fix and extend FPU support

[Eli C. <eli...@gm...>]

On 2016/4/5 5:42, Richard Weinberger wrote:
> Sorry for my late response.
> I'll put this now into -next and give it some testing.

Ping?

It has been some time but I don't see this in -next yet.

Re: [uml-devel] [PATCH] hostfs: fix opening file with overlayfs

[Richard W. <ri...@no...>]

CC'ing VFS folks

Am 01.05.2016 um 11:02 schrieb Toshikuni Fukaya:
> If a file on overlayfs using hostfs as a lowerdir is opened, it would
> be failed by ENOENT because hostfs resolves a host path by a host root
> path stored on the hostfs superblock referred by file->f_path.dentry,
> but it is replaced with overlayfs's one starting from the
> commit 4bacc9c9234c ("overlayfs: Make f_path always point to the
> overlay and f_inode to the underlay").
> 
> We replace using file->f_path.dentry directly with calling
> "file_dentry" from a commit d101a125954e ("fs: add file_dentry()") to
> fix the issue.

Is there a reason why not all instances of file->f_path.dentry have
been replaced by file_dentry()?
I smell more fallout...

Thanks,
//richard

> Signed-off-by: Toshikuni Fukaya <to...@gm...>
> ---
>  fs/hostfs/hostfs_kern.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/fs/hostfs/hostfs_kern.c b/fs/hostfs/hostfs_kern.c
> index 7016653..26a9f43 100644
> --- a/fs/hostfs/hostfs_kern.c
> +++ b/fs/hostfs/hostfs_kern.c
> @@ -284,7 +284,7 @@ static int hostfs_readdir(struct file *file, struct dir_context *ctx)
>  	int error, len;
>  	unsigned int type;
>  
> -	name = dentry_name(file->f_path.dentry);
> +	name = dentry_name(file_dentry(file));
>  	if (name == NULL)
>  		return -ENOMEM;
>  	dir = open_dir(name, &error);
> @@ -323,7 +323,7 @@ retry:
>  	if (mode & FMODE_WRITE)
>  		r = w = 1;
>  
> -	name = dentry_name(file->f_path.dentry);
> +	name = dentry_name(file_dentry(file));
>  	if (name == NULL)
>  		return -ENOMEM;
>  
> 

Re: [uml-devel] [PATCH v3 0/3] um: fix and extend FPU support

[Richard W. <ri...@no...>]

Am 19.03.2016 um 17:58 schrieb Eli Cooper:
> This series first fixes a bug that results in corrupted FPU state after
> invoking signal handlers. It also adds support for the extended processor
> state (XSTATE) for x86_64 UML, especially the YMM registers used by AVX(2)
> instructions.
> 
> Tested with a minimal multi-threaded FPU-intensive test program (see below).
> This series supersedes the previous sigreturn fix as that one is incorrect
> when the process is multi-threaded.
> 
> Changes since v2:
>  - Add an improved sigreturn fix to this series
>  - Merge the ptrace changes into the last commit
>  - Make the selftest program multi-threaded
> 
> Changes since v1:
>  - Refactor functions with oversized stack frame
>  - Add a tiny selftest program to the cover letter
> 
> Eli Cooper (3):
>   um: fix FPU state preservation around signal handlers
>   um: extend fpstate to _xstate to support YMM registers
>   um: add extended processor state save/restore support

Sorry for my late response.
I'll put this now into -next and give it some testing.

Thanks a lot for fixing!
//richard

Re: [uml-devel] [PATCH 1/2] asm-generic/io.h: provide default ioremap/iounmap for !HAS_IOMEM

[Geert U. <ge...@li...>]

Hi Rob,

On Wed, Mar 30, 2016 at 11:20 PM, Rob Herring <ro...@ke...> wrote:
> On Wed, Mar 30, 2016 at 3:08 PM, Geert Uytterhoeven
> <ge...@li...> wrote:
>> On Tue, Mar 29, 2016 at 10:13 PM, Rob Herring <ro...@ke...> wrote:
>>> Ewww. Why do the opposite of what we do for every other Kconfig symbol
>>> which is provide empty functions? It really only functions as a
>>> disable on UML flag which runs counter to enabling drivers to build
>>> for all arches.
>>
>> Usually the empty function fall into one of two classes:
>>   1. They return an error, so drivers will abort their initialization,
>>   2. They are a plain no-op, for functions with harmless side-effects.
>>
>> The !MMU versions are not dummies, but assume a transparent translation.
>> This may lead to drivers continuing their initialization and crashing the
>> system.
>
> I thought about this, but how could you even get to the point of
> having some physical address passed to the driver? Perhaps some old
> ISA driver, but I'm not sure memory ranges were ever fixed (only i/o).
> We're really only talking about UML here.

Hmm, perhaps it indeed can't happen.

>>> I actually started a patch to remove the HAS_IOMEM dependency
>>> everywhere (or just the per driver cases). It didn't break as bad as I
>>> expected, but became more than I wanted to fix. Mainly, all the devm_
>>> variants also need empty versions or to be always enabled.
>>
>> Should these dependencies on HAS_IOMEM be changed to "HAS_IOMEM ||
>> COMPILE_TEST"?
>
> Why? Most are either HAS_IOMEM or HAS_IOMEM && COMPILE_TEST.

COMPILE_TEST is meant to enable drivers that are not useful, due to missing
infrastructure.
Without having it enabled, you don't want to include useless drivers.
If you have dummies, you still want the HAS_IOMEM dependency to avoid
compiling useless drivers. I.e. it's a hint for distros, who don't want to ship
useless drivers.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [uml-devel] [PATCH 1/2] asm-generic/io.h: provide default ioremap/iounmap for !HAS_IOMEM

[Arnd B. <ar...@ar...>]

On Wednesday 30 March 2016 22:35:37 Richard Weinberger wrote:
> Am 30.03.2016 um 22:08 schrieb Geert Uytterhoeven:
> >> I actually started a patch to remove the HAS_IOMEM dependency
> >> everywhere (or just the per driver cases). It didn't break as bad as I
> >> expected, but became more than I wanted to fix. Mainly, all the devm_
> >> variants also need empty versions or to be always enabled.
> > 
> > Should these dependencies on HAS_IOMEM be changed to "HAS_IOMEM ||
> > COMPILE_TEST"?
> 
> Another idea, the issue with COMPILE_TEST is that it is automatically selected
> by make targets such as allyesconfig or allmodconfig.
> Couldn't we make COMPILE_TEST just harder to select?
> i.e. that with allyesconfig it is still disabled and if someone really wants to
> do a compile test of anything we could issue something like "make allyesconfig COMPILE_TEST=y"
> to have COMPILE_TEST selected?
> 

I think it's essential for allmodconfig and allyesconfig to enable
COMPILE_TEST: the only reason for ever building those configurations
is for compile tests.

	Arnd

Re: [uml-devel] [PATCH 1/2] asm-generic/io.h: provide default ioremap/iounmap for !HAS_IOMEM

[Richard W. <ri...@no...>]

Am 30.03.2016 um 22:08 schrieb Geert Uytterhoeven:
>> I actually started a patch to remove the HAS_IOMEM dependency
>> everywhere (or just the per driver cases). It didn't break as bad as I
>> expected, but became more than I wanted to fix. Mainly, all the devm_
>> variants also need empty versions or to be always enabled.
> 
> Should these dependencies on HAS_IOMEM be changed to "HAS_IOMEM ||
> COMPILE_TEST"?

Another idea, the issue with COMPILE_TEST is that it is automatically selected
by make targets such as allyesconfig or allmodconfig.
Couldn't we make COMPILE_TEST just harder to select?
i.e. that with allyesconfig it is still disabled and if someone really wants to
do a compile test of anything we could issue something like "make allyesconfig COMPILE_TEST=y"
to have COMPILE_TEST selected?

Thanks,
//richard

Re: [uml-devel] [PATCH 1/2] asm-generic/io.h: provide default ioremap/iounmap for !HAS_IOMEM

[Geert U. <ge...@li...>]

Hi Rob,

On Tue, Mar 29, 2016 at 10:13 PM, Rob Herring <ro...@ke...> wrote:
> On Tue, Mar 29, 2016 at 2:37 PM, Arnd Bergmann <ar...@ar...> wrote:
>> On Tuesday 29 March 2016 13:23:00 Rob Herring wrote:
>>> Drivers shouldn't have to care about HAS_IOMEM to compile and having to
>>> causes a Kconfig mess:
>>>
>>> warning: (MEDIA_SUBDRV_AUTOSELECT && VIDEO_CX231XX && INV_MPU6050_I2C) selects I2C_MUX which has unmet direct dependencies (I2C && HAS_IOMEM)
>>> warning: (ST_IRQCHIP && STMMAC_PLATFORM && DWMAC_IPQ806X && DWMAC_LPC18XX && DWMAC_ROCKCHIP && DWMAC_SOCFPGA && DWMAC_STI && TI_CPSW && PINCTRL_ROCKCHIP && PINCTRL_DOVE && POWER_RESET_KEYSTONE && S3C2410_WATCHDOG && VIDEO_OMAP3 && VIDEO_S5P_FIMC && USB_XHCI_MTK && RTC_DRV_AT91SAM9 && LPC18XX_DMAMUX && VIDEO_OMAP4 && HWSPINLOCK_QCOM && ATMEL_ST && QCOM_GSBI && PHY_HI6220_USB) selects MFD_SYSCON which has unmet direct dependencies (HAS_IOMEM)
>>>
>>> Reuse the !MMU variants for !HAS_IOMEM as they are sufficient for our
>>> needs. This fixes build errors for UM allyesconfig:
>>>
>>> drivers/mfd/syscon.c:89:2: error: implicit declaration of function 'iounmap' [-Werror=implicit-function-declaration]
>>>      iounmap(base);
>>>
>>> Reported-by: Fengguang Wu <fen...@in...>
>>> Cc: Arnd Bergmann <ar...@ar...>
>>> Cc: lin...@vg...
>>> Signed-off-by: Rob Herring <ro...@ke...>
>>
>> (adding Richard and the UML list to cc)
>>
>> I actually prototyped a patch that did the opposite: remove the readl/writel/...
>> definitions when HAS_IOMEM is unset. I didn't get far enough to submit it,
>> but see below for what I did.
>
> Ewww. Why do the opposite of what we do for every other Kconfig symbol
> which is provide empty functions? It really only functions as a
> disable on UML flag which runs counter to enabling drivers to build
> for all arches.

Usually the empty function fall into one of two classes:
  1. They return an error, so drivers will abort their initialization,
  2. They are a plain no-op, for functions with harmless side-effects.

The !MMU versions are not dummies, but assume a transparent translation.
This may lead to drivers continuing their initialization and crashing the
system.

> I actually started a patch to remove the HAS_IOMEM dependency
> everywhere (or just the per driver cases). It didn't break as bad as I
> expected, but became more than I wanted to fix. Mainly, all the devm_
> variants also need empty versions or to be always enabled.

Should these dependencies on HAS_IOMEM be changed to "HAS_IOMEM ||
COMPILE_TEST"?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [uml-devel] [PATCH 1/2] asm-generic/io.h: provide default ioremap/iounmap for !HAS_IOMEM

[Arnd B. <ar...@ar...>]

On Wednesday 30 March 2016 08:29:45 Rob Herring wrote:
> On Wed, Mar 30, 2016 at 5:03 AM, Arnd Bergmann <ar...@ar...> wrote:
> > On Wednesday 30 March 2016 10:13:53 Richard Weinberger wrote:
> >>
> >> I fully understand your point of view. COMPILE_TEST is a monster that
> >> can do the heavy lifting for you, but monsters also have claws and fangs.
> >>
> >> Having COMPILE_TEST having depend on !UML works for me. But don't
> >> we have other archs without io mem? At least a few years ago while
> >> porting nandsim to UML I found s390 that lacks of io mem too.
> >
> > s390 gained IOMEM support when they started having PCI attachments.
> 
> I'm confused how s390 defines HAS_IOMEM and includes it from lib/Kconfig though.

Kconfig can define the same symbol multiple times, which is really
confusing. I only checked for NO_IOMEM, which s390 no longer defines,
but I have not checked what actually happens in case of two conflicting
definitions, where the one lib/Kconfig defaults to 'y' and the one in
arch/s390 defaults to CONFIG_PCI.

	Arnd

Re: [uml-devel] [PATCH 1/2] asm-generic/io.h: provide default ioremap/iounmap for !HAS_IOMEM

[Arnd B. <ar...@ar...>]

On Wednesday 30 March 2016 10:13:53 Richard Weinberger wrote:
> 
> I fully understand your point of view. COMPILE_TEST is a monster that
> can do the heavy lifting for you, but monsters also have claws and fangs. 
> 
> Having COMPILE_TEST having depend on !UML works for me. But don't
> we have other archs without io mem? At least a few years ago while
> porting nandsim to UML I found s390 that lacks of io mem too.

s390 gained IOMEM support when they started having PCI attachments.

arch/score selects NO_IOMEM, though they do in fact use MMIO, and
I'm sure their architecture has lots of other problems with build
testing that nobody cares about.

arch/tile can select NO_IOMEM when PCI is disabled, they might
care about this, though I think they also have other build-time
issues.

> Maybe we depend COMPILE_TEST on HAS_IOMEM?

That sounds fine with me as well.

	Arnd

Re: [uml-devel] [PATCH 1/2] asm-generic/io.h: provide default ioremap/iounmap for !HAS_IOMEM

[Richard W. <ri...@no...>]

Am 30.03.2016 um 10:04 schrieb Arnd Bergmann:
> On Wednesday 30 March 2016 09:50:22 Richard Weinberger wrote:
>> Am 29.03.2016 um 22:13 schrieb Rob Herring:
>>>>> Reuse the !MMU variants for !HAS_IOMEM as they are sufficient for our
>>>>> needs. This fixes build errors for UM allyesconfig:
>>>>>
>>>>> drivers/mfd/syscon.c:89:2: error: implicit declaration of function 'iounmap' [-Werror=implicit-function-declaration]
>>>>>      iounmap(base);
>>>>>
>>>>> Reported-by: Fengguang Wu <fen...@in...>
>>>>> Cc: Arnd Bergmann <ar...@ar...>
>>>>> Cc: lin...@vg...
>>>>> Signed-off-by: Rob Herring <ro...@ke...>
>>>>
>>>> (adding Richard and the UML list to cc)
>>>>
>>>> I actually prototyped a patch that did the opposite: remove the readl/writel/...
>>>> definitions when HAS_IOMEM is unset. I didn't get far enough to submit it,
>>>> but see below for what I did.
>>>
>>> Ewww. Why do the opposite of what we do for every other Kconfig symbol
>>> which is provide empty functions? It really only functions as a
>>> disable on UML flag which runs counter to enabling drivers to build
>>> for all arches.
>>>
>>> I actually started a patch to remove the HAS_IOMEM dependency
>>> everywhere (or just the per driver cases). It didn't break as bad as I
>>> expected, but became more than I wanted to fix. Mainly, all the devm_
>>> variants also need empty versions or to be always enabled.
>>
>> The root cause of the problem is COMPILE_TEST. People who use it need to
>> get forced to think about the consequences.
>> COMPILE_TEST means that the driver will also be build on not so fancy archs
>> like UML, s390 and m68k where you don't have IOMEM or also DMA in every
>> possible configuration.
>> So a quick build test on x86 is not sufficient.
>>
>> This is why I'm absolutely not a fan of having stubs for iounmap() an friends
>> for UML. It only tries to bypass the root cause.
>> What is next? Stubs for DMA? PCI? For everything else that does not build?
>>
>> With COMPILE_TEST we have created a monster and now we have to deal with it in terms of
>> having correct dependencies when COMPILE_TEST is being used.
>>
> 
> One way out of this would be accept that UML is just too different
> from the other architectures, and make COMPILE_TEST itself depend
> on !UML.
> 
> COMPILE_TEST is highly valuable for me, because it means that all the
> ARM specific drivers can now be build-tested on x86 and they show up
> for anyone doing allmodconfig builds. If we introduce a regression
> in any of the drivers, it gets caught much quicker because many
> subsystem maintainers run an x86 allmodconfig build after pulling
> downstream maintainer trees. There is also stuff like Coverity that
> only ever runs on x86.
> 
> It does make sense to have COMPILE_TEST imply that we are able
> to build things on all architectures, not just x86 in addition to
> the platform a driver is meant for, but the value of compile-testing
> a random driver with UML in particular approaches zero, and instead
> causes lots of work.

I fully understand your point of view. COMPILE_TEST is a monster that
can do the heavy lifting for you, but monsters also have claws and fangs. ;-)

Having COMPILE_TEST having depend on !UML works for me. But don't
we have other archs without io mem? At least a few years ago while
porting nandsim to UML I found s390 that lacks of io mem too.

Maybe we depend COMPILE_TEST on HAS_IOMEM?

Thanks,
//richard

Re: [uml-devel] [PATCH 1/2] asm-generic/io.h: provide default ioremap/iounmap for !HAS_IOMEM

[Arnd B. <ar...@ar...>]

On Wednesday 30 March 2016 09:50:22 Richard Weinberger wrote:
> Am 29.03.2016 um 22:13 schrieb Rob Herring:
> >>> Reuse the !MMU variants for !HAS_IOMEM as they are sufficient for our
> >>> needs. This fixes build errors for UM allyesconfig:
> >>>
> >>> drivers/mfd/syscon.c:89:2: error: implicit declaration of function 'iounmap' [-Werror=implicit-function-declaration]
> >>>      iounmap(base);
> >>>
> >>> Reported-by: Fengguang Wu <fen...@in...>
> >>> Cc: Arnd Bergmann <ar...@ar...>
> >>> Cc: lin...@vg...
> >>> Signed-off-by: Rob Herring <ro...@ke...>
> >>
> >> (adding Richard and the UML list to cc)
> >>
> >> I actually prototyped a patch that did the opposite: remove the readl/writel/...
> >> definitions when HAS_IOMEM is unset. I didn't get far enough to submit it,
> >> but see below for what I did.
> > 
> > Ewww. Why do the opposite of what we do for every other Kconfig symbol
> > which is provide empty functions? It really only functions as a
> > disable on UML flag which runs counter to enabling drivers to build
> > for all arches.
> > 
> > I actually started a patch to remove the HAS_IOMEM dependency
> > everywhere (or just the per driver cases). It didn't break as bad as I
> > expected, but became more than I wanted to fix. Mainly, all the devm_
> > variants also need empty versions or to be always enabled.
> 
> The root cause of the problem is COMPILE_TEST. People who use it need to
> get forced to think about the consequences.
> COMPILE_TEST means that the driver will also be build on not so fancy archs
> like UML, s390 and m68k where you don't have IOMEM or also DMA in every
> possible configuration.
> So a quick build test on x86 is not sufficient.
> 
> This is why I'm absolutely not a fan of having stubs for iounmap() an friends
> for UML. It only tries to bypass the root cause.
> What is next? Stubs for DMA? PCI? For everything else that does not build?
> 
> With COMPILE_TEST we have created a monster and now we have to deal with it in terms of
> having correct dependencies when COMPILE_TEST is being used.
> 

One way out of this would be accept that UML is just too different
from the other architectures, and make COMPILE_TEST itself depend
on !UML.

COMPILE_TEST is highly valuable for me, because it means that all the
ARM specific drivers can now be build-tested on x86 and they show up
for anyone doing allmodconfig builds. If we introduce a regression
in any of the drivers, it gets caught much quicker because many
subsystem maintainers run an x86 allmodconfig build after pulling
downstream maintainer trees. There is also stuff like Coverity that
only ever runs on x86.

It does make sense to have COMPILE_TEST imply that we are able
to build things on all architectures, not just x86 in addition to
the platform a driver is meant for, but the value of compile-testing
a random driver with UML in particular approaches zero, and instead
causes lots of work.

	Arnd

Re: [uml-devel] [PATCH 1/2] asm-generic/io.h: provide default ioremap/iounmap for !HAS_IOMEM

[Richard W. <ri...@no...>]

Am 29.03.2016 um 22:13 schrieb Rob Herring:
>>> Reuse the !MMU variants for !HAS_IOMEM as they are sufficient for our
>>> needs. This fixes build errors for UM allyesconfig:
>>>
>>> drivers/mfd/syscon.c:89:2: error: implicit declaration of function 'iounmap' [-Werror=implicit-function-declaration]
>>>      iounmap(base);
>>>
>>> Reported-by: Fengguang Wu <fen...@in...>
>>> Cc: Arnd Bergmann <ar...@ar...>
>>> Cc: lin...@vg...
>>> Signed-off-by: Rob Herring <ro...@ke...>
>>
>> (adding Richard and the UML list to cc)
>>
>> I actually prototyped a patch that did the opposite: remove the readl/writel/...
>> definitions when HAS_IOMEM is unset. I didn't get far enough to submit it,
>> but see below for what I did.
> 
> Ewww. Why do the opposite of what we do for every other Kconfig symbol
> which is provide empty functions? It really only functions as a
> disable on UML flag which runs counter to enabling drivers to build
> for all arches.
> 
> I actually started a patch to remove the HAS_IOMEM dependency
> everywhere (or just the per driver cases). It didn't break as bad as I
> expected, but became more than I wanted to fix. Mainly, all the devm_
> variants also need empty versions or to be always enabled.

The root cause of the problem is COMPILE_TEST. People who use it need to
get forced to think about the consequences.
COMPILE_TEST means that the driver will also be build on not so fancy archs
like UML, s390 and m68k where you don't have IOMEM or also DMA in every
possible configuration.
So a quick build test on x86 is not sufficient.

This is why I'm absolutely not a fan of having stubs for iounmap() an friends
for UML. It only tries to bypass the root cause.
What is next? Stubs for DMA? PCI? For everything else that does not build?

With COMPILE_TEST we have created a monster and now we have to deal with it in terms of
having correct dependencies when COMPILE_TEST is being used.

Thanks,
//richard

Re: [uml-devel] [PATCH 1/2] asm-generic/io.h: provide default ioremap/iounmap for !HAS_IOMEM

[Richard W. <ri...@no...>]

Am 29.03.2016 um 21:37 schrieb Arnd Bergmann:
> On Tuesday 29 March 2016 13:23:00 Rob Herring wrote:
>> Drivers shouldn't have to care about HAS_IOMEM to compile and having to
>> causes a Kconfig mess:
>>
>> warning: (MEDIA_SUBDRV_AUTOSELECT && VIDEO_CX231XX && INV_MPU6050_I2C) selects I2C_MUX which has unmet direct dependencies (I2C && HAS_IOMEM)
>> warning: (ST_IRQCHIP && STMMAC_PLATFORM && DWMAC_IPQ806X && DWMAC_LPC18XX && DWMAC_ROCKCHIP && DWMAC_SOCFPGA && DWMAC_STI && TI_CPSW && PINCTRL_ROCKCHIP && PINCTRL_DOVE && POWER_RESET_KEYSTONE && S3C2410_WATCHDOG && VIDEO_OMAP3 && VIDEO_S5P_FIMC && USB_XHCI_MTK && RTC_DRV_AT91SAM9 && LPC18XX_DMAMUX && VIDEO_OMAP4 && HWSPINLOCK_QCOM && ATMEL_ST && QCOM_GSBI && PHY_HI6220_USB) selects MFD_SYSCON which has unmet direct dependencies (HAS_IOMEM)
>>
>> Reuse the !MMU variants for !HAS_IOMEM as they are sufficient for our
>> needs. This fixes build errors for UM allyesconfig:
>>
>> drivers/mfd/syscon.c:89:2: error: implicit declaration of function 'iounmap' [-Werror=implicit-function-declaration]
>>      iounmap(base);
>>
>> Reported-by: Fengguang Wu <fen...@in...>
>> Cc: Arnd Bergmann <ar...@ar...>
>> Cc: lin...@vg...
>> Signed-off-by: Rob Herring <ro...@ke...>
> 
> (adding Richard and the UML list to cc)

For the above error I've sent already a fix:
https://lkml.org/lkml/2016/3/25/321

> I actually prototyped a patch that did the opposite: remove the readl/writel/...
> definitions when HAS_IOMEM is unset. I didn't get far enough to submit it,
> but see below for what I did.
> 
> I think it makes sense to do either one or the other.
> 
> 	Arnd
> 
> diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig
> index a043107..f6dc17a 100644
> --- a/drivers/char/Kconfig
> +++ b/drivers/char/Kconfig
> @@ -8,6 +8,7 @@ source "drivers/tty/Kconfig"
>  
>  config DEVMEM
>  	bool "/dev/mem virtual device support"
> +	depends on HAS_IOMEM

Hmm, this means no /dev/mem device for UML? (And some s390 variants).
Not sure if this a good idea.
But I like it more than having ioremap/iounmap stubs for !HAS_IOMEM. :)

Thanks,
//richard

Re: [uml-devel] [PATCH 1/2] asm-generic/io.h: provide default ioremap/iounmap for !HAS_IOMEM

[Arnd B. <ar...@ar...>]

On Tuesday 29 March 2016 13:23:00 Rob Herring wrote:
> Drivers shouldn't have to care about HAS_IOMEM to compile and having to
> causes a Kconfig mess:
> 
> warning: (MEDIA_SUBDRV_AUTOSELECT && VIDEO_CX231XX && INV_MPU6050_I2C) selects I2C_MUX which has unmet direct dependencies (I2C && HAS_IOMEM)
> warning: (ST_IRQCHIP && STMMAC_PLATFORM && DWMAC_IPQ806X && DWMAC_LPC18XX && DWMAC_ROCKCHIP && DWMAC_SOCFPGA && DWMAC_STI && TI_CPSW && PINCTRL_ROCKCHIP && PINCTRL_DOVE && POWER_RESET_KEYSTONE && S3C2410_WATCHDOG && VIDEO_OMAP3 && VIDEO_S5P_FIMC && USB_XHCI_MTK && RTC_DRV_AT91SAM9 && LPC18XX_DMAMUX && VIDEO_OMAP4 && HWSPINLOCK_QCOM && ATMEL_ST && QCOM_GSBI && PHY_HI6220_USB) selects MFD_SYSCON which has unmet direct dependencies (HAS_IOMEM)
> 
> Reuse the !MMU variants for !HAS_IOMEM as they are sufficient for our
> needs. This fixes build errors for UM allyesconfig:
> 
> drivers/mfd/syscon.c:89:2: error: implicit declaration of function 'iounmap' [-Werror=implicit-function-declaration]
>      iounmap(base);
> 
> Reported-by: Fengguang Wu <fen...@in...>
> Cc: Arnd Bergmann <ar...@ar...>
> Cc: lin...@vg...
> Signed-off-by: Rob Herring <ro...@ke...>

(adding Richard and the UML list to cc)

I actually prototyped a patch that did the opposite: remove the readl/writel/...
definitions when HAS_IOMEM is unset. I didn't get far enough to submit it,
but see below for what I did.

I think it makes sense to do either one or the other.

	Arnd

diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig
index a043107..f6dc17a 100644
--- a/drivers/char/Kconfig
+++ b/drivers/char/Kconfig
@@ -8,6 +8,7 @@ source "drivers/tty/Kconfig"
 
 config DEVMEM
 	bool "/dev/mem virtual device support"
+	depends on HAS_IOMEM
 	default y
 	help
 	  Say Y here if you want to support the /dev/mem device.
@@ -17,6 +18,7 @@ config DEVMEM
 
 config DEVKMEM
 	bool "/dev/kmem virtual device support"
+	depends on HAS_IOMEM
 	default y
 	help
 	  Say Y here if you want to support the /dev/kmem device. The
@@ -94,6 +96,7 @@ config BFIN_OTP_WRITE_ENABLE
 config PRINTER
 	tristate "Parallel printer support"
 	depends on PARPORT
+	depends on HAS_IOPORT
 	---help---
 	  If you intend to attach a printer to the parallel port of your Linux
 	  box (as opposed to using a serial printer; if the connector at the
diff --git a/drivers/char/mem.c b/drivers/char/mem.c
index 4f6f94c..eedd129 100644
--- a/drivers/char/mem.c
+++ b/drivers/char/mem.c
@@ -91,6 +91,7 @@ void __weak unxlate_dev_mem_ptr(phys_addr_t phys, void *addr)
 }
 #endif
 
+#ifdef CONFIG_DEVMEM
 /*
  * This funcion reads the *physical* memory. The f_pos points directly to the
  * memory location.
@@ -219,6 +220,7 @@ static ssize_t write_mem(struct file *file, const char __user *buf,
 	*ppos += written;
 	return written;
 }
+#endif
 
 int __weak phys_mem_access_prot_allowed(struct file *file,
 	unsigned long pfn, unsigned long size, pgprot_t *vma_prot)
@@ -312,6 +314,7 @@ static inline int private_mapping_ok(struct vm_area_struct *vma)
 }
 #endif
 
+#ifdef CONFIG_DEVMEM
 static const struct vm_operations_struct mmap_mem_ops = {
 #ifdef CONFIG_HAVE_IOREMAP_PROT
 	.access = generic_access_phys
@@ -351,7 +354,9 @@ static int mmap_mem(struct file *file, struct vm_area_struct *vma)
 	}
 	return 0;
 }
+#endif
 
+#ifdef CONFIG_DEVKMEM
 static int mmap_kmem(struct file *file, struct vm_area_struct *vma)
 {
 	unsigned long pfn;
@@ -552,7 +557,9 @@ static ssize_t write_kmem(struct file *file, const char __user *buf,
 	*ppos = p;
 	return virtr + wrote ? : err;
 }
+#endif
 
+#ifdef CONFIG_DEVPORT
 static ssize_t read_port(struct file *file, char __user *buf,
 			 size_t count, loff_t *ppos)
 {
@@ -594,6 +601,7 @@ static ssize_t write_port(struct file *file, const char __user *buf,
 	*ppos = i;
 	return tmp-buf;
 }
+#endif
 
 static ssize_t read_null(struct file *file, char __user *buf,
 			 size_t count, loff_t *ppos)
@@ -710,10 +718,12 @@ static loff_t memory_lseek(struct file *file, loff_t offset, int orig)
 	return ret;
 }
 
+#ifdef CONFIG_DEVPORT
 static int open_port(struct inode *inode, struct file *filp)
 {
 	return capable(CAP_SYS_RAWIO) ? 0 : -EPERM;
 }
+#endif
 
 #define zero_lseek	null_lseek
 #define full_lseek      null_lseek
@@ -722,6 +732,7 @@ static int open_port(struct inode *inode, struct file *filp)
 #define open_mem	open_port
 #define open_kmem	open_mem
 
+#ifdef CONFIG_DEVMEM
 static const struct file_operations __maybe_unused mem_fops = {
 	.llseek		= memory_lseek,
 	.read		= read_mem,
@@ -733,7 +744,9 @@ static const struct file_operations __maybe_unused mem_fops = {
 	.mmap_capabilities = memory_mmap_capabilities,
 #endif
 };
+#endif
 
+#ifdef CONFIG_DEVKMEM
 static const struct file_operations __maybe_unused kmem_fops = {
 	.llseek		= memory_lseek,
 	.read		= read_kmem,
@@ -745,6 +758,7 @@ static const struct file_operations __maybe_unused kmem_fops = {
 	.mmap_capabilities = memory_mmap_capabilities,
 #endif
 };
+#endif
 
 static const struct file_operations null_fops = {
 	.llseek		= null_lseek,
@@ -755,12 +769,14 @@ static const struct file_operations null_fops = {
 	.splice_write	= splice_write_null,
 };
 
+#ifdef CONFIG_DEVPORT
 static const struct file_operations __maybe_unused port_fops = {
 	.llseek		= memory_lseek,
 	.read		= read_port,
 	.write		= write_port,
 	.open		= open_port,
 };
+#endif
 
 static const struct file_operations zero_fops = {
 	.llseek		= zero_lseek,
diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index 33db740..6b58974 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -38,6 +38,7 @@ config DIGICOLOR_TIMER
 config DW_APB_TIMER
 	bool "DW APB timer driver" if COMPILE_TEST
 	depends on GENERIC_CLOCKEVENTS
+	depends on HAS_IOMEM
 	help
 	  Enables the support for the dw_apb timer.
 
@@ -64,6 +65,7 @@ config ARMADA_370_XP_TIMER
 config MESON6_TIMER
 	bool "Meson6 timer driver" if COMPILE_TEST
 	depends on GENERIC_CLOCKEVENTS
+	depends on HAS_IOMEM
 	select CLKSRC_MMIO
 	help
 	  Enables the support for the Meson6 timer driver.
@@ -114,6 +116,7 @@ config CADENCE_TTC_TIMER
 config ASM9260_TIMER
 	bool "ASM9260 timer driver" if COMPILE_TEST
 	depends on GENERIC_CLOCKEVENTS
+	depends on HAS_IOMEM
 	select CLKSRC_MMIO
 	select CLKSRC_OF
 	help
diff --git a/drivers/fmc/Kconfig b/drivers/fmc/Kconfig
index 3a75f42..adf1391 100644
--- a/drivers/fmc/Kconfig
+++ b/drivers/fmc/Kconfig
@@ -4,6 +4,7 @@
 
 menuconfig FMC
 	tristate "FMC support"
+	depends on HAS_IOMEM
 	help
 
 	  FMC (FPGA Mezzanine Carrier) is a mechanical and electrical
diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
index c9b9fdf..36c54af 100644
--- a/drivers/fpga/Kconfig
+++ b/drivers/fpga/Kconfig
@@ -21,6 +21,7 @@ config FPGA_MGR_SOCFPGA
 
 config FPGA_MGR_ZYNQ_FPGA
 	tristate "Xilinx Zynq FPGA"
+	depends on HAS_IOMEM
 	help
 	  FPGA manager driver support for Xilinx Zynq FPGAs.
 
diff --git a/drivers/hwtracing/intel_th/Kconfig b/drivers/hwtracing/intel_th/Kconfig
index b7a9073..467dae9 100644
--- a/drivers/hwtracing/intel_th/Kconfig
+++ b/drivers/hwtracing/intel_th/Kconfig
@@ -1,5 +1,6 @@
 config INTEL_TH
 	tristate "Intel(R) Trace Hub controller"
+	depends on HAS_IOMEM
 	help
 	  Intel(R) Trace Hub (TH) is a set of hardware blocks (subdevices) that
 	  produce, switch and output trace data from multiple hardware and
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 9ca66de..6ff6246 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -999,6 +999,7 @@ config MFD_SUN6I_PRCM
 
 config MFD_SYSCON
 	bool "System Controller Register R/W Based on Regmap"
+	depends on HAS_IOMEM
 	select REGMAP_MMIO
 	help
 	  Select this option to enable accessing system control registers
diff --git a/drivers/misc/altera-stapl/Kconfig b/drivers/misc/altera-stapl/Kconfig
index 7f01d8e..c7e4c77 100644
--- a/drivers/misc/altera-stapl/Kconfig
+++ b/drivers/misc/altera-stapl/Kconfig
@@ -2,7 +2,7 @@ comment "Altera FPGA firmware download module"
 
 config ALTERA_STAPL
 	tristate "Altera FPGA firmware download module"
-	depends on I2C
+	depends on I2C && HAS_IOPORT
 	default n
 	help
 	  An Altera FPGA module. Say Y when you want to support this tool.
diff --git a/drivers/mtd/chips/Kconfig b/drivers/mtd/chips/Kconfig
index 3b3dabc..189ddce 100644
--- a/drivers/mtd/chips/Kconfig
+++ b/drivers/mtd/chips/Kconfig
@@ -3,6 +3,7 @@ menu "RAM/ROM/Flash chip drivers"
 
 config MTD_CFI
 	tristate "Detect flash chips by Common Flash Interface (CFI) probe"
+	depends on HAS_IOMEM
 	select MTD_GEN_PROBE
 	select MTD_CFI_UTIL
 	help
@@ -15,6 +16,7 @@ config MTD_CFI
 
 config MTD_JEDECPROBE
 	tristate "Detect non-CFI AMD/JEDEC-compatible flash chips"
+	depends on HAS_IOMEM
 	select MTD_GEN_PROBE
 	select MTD_CFI_UTIL
 	help
@@ -207,12 +209,14 @@ config MTD_CFI_UTIL
 
 config MTD_RAM
 	tristate "Support for RAM chips in bus mapping"
+	depends on HAS_IOMEM
 	help
 	  This option enables basic support for RAM chips accessed through
 	  a bus mapping driver.
 
 config MTD_ROM
 	tristate "Support for ROM chips in bus mapping"
+	depends on HAS_IOMEM
 	help
 	  This option enables basic support for ROM chips accessed through
 	  a bus mapping driver.
diff --git a/drivers/mtd/lpddr/Kconfig b/drivers/mtd/lpddr/Kconfig
index 3a19cbe..07dd95a 100644
--- a/drivers/mtd/lpddr/Kconfig
+++ b/drivers/mtd/lpddr/Kconfig
@@ -4,6 +4,7 @@ menu "LPDDR & LPDDR2 PCM memory drivers"
 config MTD_LPDDR
 	tristate "Support for LPDDR flash chips"
 	select MTD_QINFO_PROBE
+	depends on HAS_IOMEM
 	help
 	  This option enables support of LPDDR (Low power double data rate)
 	  flash chips. Synonymous with Mobile-DDR. It is a new standard for
diff --git a/drivers/mtd/maps/Kconfig b/drivers/mtd/maps/Kconfig
index 7c95a65..86a9604 100644
--- a/drivers/mtd/maps/Kconfig
+++ b/drivers/mtd/maps/Kconfig
@@ -3,7 +3,8 @@ menu "Mapping drivers for chip access"
 	depends on HAS_IOMEM
 
 config MTD_COMPLEX_MAPPINGS
-	bool "Support non-linear mappings of flash chips"
+	bool "Support non-linear mappings of flash chips" if HAS_IOMEM
+	default !HAS_IOMEM
 	help
 	  This causes the chip drivers to allow for complicated
 	  paged mappings of flash chips.
diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index 20f01b3..6ed3de7 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -12,7 +12,7 @@ config MTD_NAND_ECC_SMC
 
 menuconfig MTD_NAND
 	tristate "NAND Device Support"
-	depends on MTD
+	depends on MTD && HAS_IOMEM
 	select MTD_NAND_IDS
 	select MTD_NAND_ECC
 	help
diff --git a/drivers/mtd/spi-nor/Kconfig b/drivers/mtd/spi-nor/Kconfig
index 0dc9275..83befab 100644
--- a/drivers/mtd/spi-nor/Kconfig
+++ b/drivers/mtd/spi-nor/Kconfig
@@ -9,6 +9,7 @@ if MTD_SPI_NOR
 
 config MTD_MT81xx_NOR
 	tristate "Mediatek MT81xx SPI NOR flash controller"
+	depends on HAS_IOMEM
 	help
 	  This enables access to SPI NOR flash, using MT81xx SPI NOR flash
 	  controller. This controller does not support generic SPI BUS, it only
diff --git a/drivers/net/can/Kconfig b/drivers/net/can/Kconfig
index 6d04183..b1e268b 100644
--- a/drivers/net/can/Kconfig
+++ b/drivers/net/can/Kconfig
@@ -132,6 +132,7 @@ config CAN_RCAR
 config CAN_SUN4I
 	tristate "Allwinner A10 CAN controller"
 	depends on MACH_SUN4I || MACH_SUN7I || COMPILE_TEST
+	depends on HAS_IOMEM
 	---help---
 	  Say Y here if you want to use CAN controller found on Allwinner
 	  A10/A20 SoCs.
diff --git a/drivers/net/hamradio/Kconfig b/drivers/net/hamradio/Kconfig
index bf5e596..507f7a5 100644
--- a/drivers/net/hamradio/Kconfig
+++ b/drivers/net/hamradio/Kconfig
@@ -113,7 +113,8 @@ config SCC_TRXECHO
 
 config BAYCOM_SER_FDX
 	tristate "BAYCOM ser12 fullduplex driver for AX.25"
-	depends on AX25 && !S390
+	depends on AX25
+	depends on HAS_IOPORT
 	select CRC_CCITT
 	---help---
 	  This is one of two drivers for Baycom style simple amateur radio
@@ -133,7 +134,8 @@ config BAYCOM_SER_FDX
 
 config BAYCOM_SER_HDX
 	tristate "BAYCOM ser12 halfduplex driver for AX.25"
-	depends on AX25 && !S390
+	depends on AX25
+	depends on HAS_IOPORT
 	select CRC_CCITT
 	---help---
 	  This is one of two drivers for Baycom style simple amateur radio
@@ -181,7 +183,8 @@ config BAYCOM_EPP
 
 config YAM
 	tristate "YAM driver for AX.25"
-	depends on AX25 && !S390
+	depends on AX25
+	depends on HAS_IOPORT
 	help
 	  The YAM is a modem for packet radio which connects to the serial
 	  port and includes some of the functions of a Terminal Node
diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig
index bc4ea58..6ef3d0a 100644
--- a/drivers/nvmem/Kconfig
+++ b/drivers/nvmem/Kconfig
@@ -1,6 +1,7 @@
 menuconfig NVMEM
 	tristate "NVMEM Support"
 	select REGMAP
+	depends on HAS_IOMEM
 	help
 	  Support for NVMEM(Non Volatile Memory) devices like EEPROM, EFUSES...
 
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index e7e117d..d2216df 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -30,9 +30,10 @@ config PHY_BERLIN_SATA
 	  Enable this to support the SATA PHY on Marvell Berlin SoCs.
 
 config ARMADA375_USBCLUSTER_PHY
-	def_bool y
-	depends on MACH_ARMADA_375 || COMPILE_TEST
+	bool "ARMADA 375 USB cluster PHY driver" if COMPILE_TEST && !MACH_ARMADA_375
+	def_bool MACH_ARMADA_375
 	depends on OF
+	depends on HAS_IOMEM
 	select GENERIC_PHY
 
 config PHY_DM816X_USB
@@ -128,6 +129,7 @@ config PHY_RCAR_GEN3_USB2
 config OMAP_CONTROL_PHY
 	tristate "OMAP CONTROL PHY Driver"
 	depends on ARCH_OMAP2PLUS || COMPILE_TEST
+	depends on HAS_IOMEM
 	help
 	  Enable this to add support for the PHY part present in the control
 	  module. This driver has API to power on the USB2 PHY and to write to
@@ -224,6 +226,8 @@ config PHY_MT65XX_USB3
 
 config PHY_HI6220_USB
 	tristate "hi6220 USB PHY support"
+	depends on ARM64 || COMPILE_TEST
+	depends on HAS_IOMEM
 	select GENERIC_PHY
 	select MFD_SYSCON
 	help
@@ -401,6 +405,7 @@ config PHY_CYGNUS_PCIE
 	tristate "Broadcom Cygnus PCIe PHY driver"
 	depends on OF && (ARCH_BCM_CYGNUS || COMPILE_TEST)
 	select GENERIC_PHY
+	depends on HAS_IOMEM
 	default ARCH_BCM_CYGNUS
 	help
 	  Enable this to support the Broadcom Cygnus PCIe PHY.
diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig
index 1131cf7..bb5bd1b 100644
--- a/drivers/power/reset/Kconfig
+++ b/drivers/power/reset/Kconfig
@@ -41,7 +41,7 @@ config POWER_RESET_AXXIA
 config POWER_RESET_BRCMSTB
 	bool "Broadcom STB reset driver"
 	depends on ARM || MIPS || COMPILE_TEST
-	depends on MFD_SYSCON
+	depends on MFD_SYSCON && HAS_IOMEM
 	default ARCH_BRCMSTB
 	help
 	  This driver provides restart support for Broadcom STB boards.
@@ -148,6 +148,7 @@ config POWER_RESET_KEYSTONE
 config POWER_RESET_SYSCON
 	bool "Generic SYSCON regmap reset driver"
 	depends on OF
+	depends on HAS_IOMEM
 	select MFD_SYSCON
 	help
 	  Reboot support for generic SYSCON mapped register reset.
@@ -155,6 +156,7 @@ config POWER_RESET_SYSCON
 config POWER_RESET_SYSCON_POWEROFF
 	bool "Generic SYSCON regmap poweroff driver"
 	depends on OF
+	depends on HAS_IOMEM
 	select MFD_SYSCON
 	help
 	  Poweroff support for generic SYSCON mapped register poweroff.
diff --git a/drivers/staging/comedi/Kconfig b/drivers/staging/comedi/Kconfig
index e7255f8..e1ba4aa 100644
--- a/drivers/staging/comedi/Kconfig
+++ b/drivers/staging/comedi/Kconfig
@@ -67,6 +67,7 @@ config COMEDI_TEST
 
 config COMEDI_PARPORT
 	tristate "Parallel port support"
+	depends on HAS_IOPORT
 	---help---
 	  Enable support for the standard parallel port.
 	  A cheap and easy way to get a few more digital I/O lines. Steal
@@ -87,6 +88,7 @@ config COMEDI_SERIAL2002
 config COMEDI_SSV_DNP
 	tristate "SSV Embedded Systems DIL/Net-PC support"
 	depends on X86_32 || COMPILE_TEST
+	depends on HAS_IOPORT
 	---help---
 	  Enable support for SSV Embedded Systems DIL/Net-PC
 
@@ -97,6 +99,7 @@ endif # COMEDI_MISC_DRIVERS
 
 menuconfig COMEDI_ISA_DRIVERS
 	bool "Comedi ISA and PC/104 drivers"
+	depends on HAS_IOPORT
 	---help---
 	  Enable comedi ISA and PC/104 drivers to be built
 
@@ -1110,7 +1113,7 @@ endif # COMEDI_PCI_DRIVERS
 
 menuconfig COMEDI_PCMCIA_DRIVERS
 	tristate "Comedi PCMCIA drivers"
-	depends on PCMCIA
+	depends on PCMCIA && HAS_IOPORT
 	---help---
 	  Enable support for comedi PCMCIA drivers.
 
@@ -1262,6 +1265,7 @@ config COMEDI_8255
 config COMEDI_8255_SA
 	tristate "Standalone 8255 support"
 	select COMEDI_8255
+	depends on HAS_IOPORT
 	---help---
 	  Enable support for 8255 digital I/O as a standalone driver.
 
diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index 8cc4ac6..31ae027 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -178,6 +178,7 @@ config THERMAL_EMULATION
 config HISI_THERMAL
 	tristate "Hisilicon thermal driver"
 	depends on (ARCH_HISI && CPU_THERMAL && OF) || COMPILE_TEST
+	depends on HAS_IOMEM
 	help
 	  Enable this to plug hisilicon's thermal sensor driver into the Linux
 	  thermal framework. cpufreq is used as the cooling device to throttle
@@ -198,6 +199,7 @@ config SPEAR_THERMAL
 	bool "SPEAr thermal sensor driver"
 	depends on PLAT_SPEAR || COMPILE_TEST
 	depends on OF
+	depends on HAS_IOMEM
 	help
 	  Enable this to plug the SPEAr thermal sensor driver into the Linux
 	  thermal framework.
@@ -206,6 +208,7 @@ config ROCKCHIP_THERMAL
 	tristate "Rockchip thermal driver"
 	depends on ARCH_ROCKCHIP || COMPILE_TEST
 	depends on RESET_CONTROLLER
+	depends on HAS_IOMEM
 	help
 	  Rockchip thermal driver provides support for Temperature sensor
 	  ADC (TS-ADC) found on Rockchip SoCs. It supports one critical
@@ -216,6 +219,7 @@ config RCAR_THERMAL
 	tristate "Renesas R-Car thermal driver"
 	depends on ARCH_SHMOBILE || COMPILE_TEST
 	depends on HAS_IOMEM
+	depends on HAS_IOMEM
 	help
 	  Enable this to plug the R-Car thermal sensor driver into the Linux
 	  thermal framework.
@@ -223,6 +227,7 @@ config RCAR_THERMAL
 config KIRKWOOD_THERMAL
 	tristate "Temperature sensor on Marvell Kirkwood SoCs"
 	depends on MACH_KIRKWOOD || COMPILE_TEST
+	depends on HAS_IOMEM
 	depends on OF
 	help
 	  Support for the Kirkwood thermal sensor driver into the Linux thermal
@@ -231,6 +236,7 @@ config KIRKWOOD_THERMAL
 config DOVE_THERMAL
 	tristate "Temperature sensor on Marvell Dove SoCs"
 	depends on ARCH_DOVE || MACH_DOVE || COMPILE_TEST
+	depends on HAS_IOMEM
 	depends on OF
 	help
 	  Support for the Dove thermal sensor driver in the Linux thermal
@@ -249,6 +255,7 @@ config DB8500_THERMAL
 config ARMADA_THERMAL
 	tristate "Armada 370/XP thermal management"
 	depends on ARCH_MVEBU || COMPILE_TEST
+	depends on HAS_IOMEM
 	depends on OF
 	help
 	  Enable this option if you want to have support for thermal management
@@ -366,12 +373,12 @@ config INTEL_PCH_THERMAL
 	  programmable trip points and other information.
 
 menu "Texas Instruments thermal drivers"
-depends on ARCH_HAS_BANDGAP || COMPILE_TEST
+depends on ARCH_HAS_BANDGAP || (COMPILE_TEST && HAS_IOMEM)
 source "drivers/thermal/ti-soc-thermal/Kconfig"
 endmenu
 
 menu "Samsung thermal drivers"
-depends on ARCH_EXYNOS || COMPILE_TEST
+depends on ARCH_EXYNOS || (COMPILE_TEST && HAS_IOMEM)
 source "drivers/thermal/samsung/Kconfig"
 endmenu
 
diff --git a/include/linux/irq.h b/include/linux/irq.h
index 3c1c967..a5d0f12 100644
--- a/include/linux/irq.h
+++ b/include/linux/irq.h
@@ -916,6 +916,7 @@ static inline void irq_gc_lock(struct irq_chip_generic *gc) { }
 static inline void irq_gc_unlock(struct irq_chip_generic *gc) { }
 #endif
 
+#ifdef CONFIG_HAS_IOMEM
 static inline void irq_reg_writel(struct irq_chip_generic *gc,
 				  u32 val, int reg_offset)
 {
@@ -933,5 +934,6 @@ static inline u32 irq_reg_readl(struct irq_chip_generic *gc,
 	else
 		return readl(gc->reg_base + reg_offset);
 }
+#endif
 
 #endif /* _LINUX_IRQ_H */
diff --git a/include/linux/mtd/cfi.h b/include/linux/mtd/cfi.h
index 9b57a9b..d5db153 100644
--- a/include/linux/mtd/cfi.h
+++ b/include/linux/mtd/cfi.h
@@ -310,6 +310,7 @@ uint32_t cfi_send_gen_cmd(u_char cmd, uint32_t cmd_addr, uint32_t base,
 				struct map_info *map, struct cfi_private *cfi,
 				int type, map_word *prev_val);
 
+#ifdef CONFIG_HAS_IOMEM
 static inline uint8_t cfi_read_query(struct map_info *map, uint32_t addr)
 {
 	map_word val = map_read(map, addr);
@@ -341,6 +342,7 @@ static inline uint16_t cfi_read_query16(struct map_info *map, uint32_t addr)
 		return cfi32_to_cpu(map, val.x[0]);
 	}
 }
+#endif
 
 void cfi_udelay(int us);
 
diff --git a/include/linux/mtd/map.h b/include/linux/mtd/map.h
index 58f3ba7..07c0d497 100644
--- a/include/linux/mtd/map.h
+++ b/include/linux/mtd/map.h
@@ -410,6 +410,7 @@ static inline map_word map_word_ff(struct map_info *map)
 	return r;
 }
 
+#ifdef CONFIG_HAS_IOMEM
 static inline map_word inline_map_read(struct map_info *map, unsigned long ofs)
 {
 	map_word r;
@@ -463,6 +464,7 @@ static inline void inline_map_copy_to(struct map_info *map, unsigned long to, co
 {
 	memcpy_toio(map->virt + to, from, len);
 }
+#endif
 
 #ifdef CONFIG_MTD_COMPLEX_MAPPINGS
 #define map_read(map, ofs) (map)->read(map, ofs)
diff --git a/kernel/resource.c b/kernel/resource.c
index 09c0597..efd5c9e 100644
--- a/kernel/resource.c
+++ b/kernel/resource.c
@@ -29,7 +29,9 @@
 struct resource ioport_resource = {
 	.name	= "PCI IO",
 	.start	= 0,
+#ifdef CONFIG_HAS_IOPORT
 	.end	= IO_SPACE_LIMIT,
+#endif
 	.flags	= IORESOURCE_IO,
 };
 EXPORT_SYMBOL(ioport_resource);
diff --git a/lib/Kconfig b/lib/Kconfig
index 133ebc0..38ff36d 100644
--- a/lib/Kconfig
+++ b/lib/Kconfig
@@ -382,9 +382,14 @@ config HAS_IOMEM
 	select GENERIC_IO
 	default y
 
+config HAS_IOPORT
+	bool
+	depends on HAS_IOMEM && !NO_IOPORT
+	default y
+
 config HAS_IOPORT_MAP
 	bool
-	depends on HAS_IOMEM && !NO_IOPORT_MAP
+	depends on HAS_IOMEM && HAS_IOPORT && !NO_IOPORT_MAP
 	default y
 
 config HAS_DMA
diff --git a/mm/bootmem.c b/mm/bootmem.c
index 91e32bc..3471237 100644
--- a/mm/bootmem.c
+++ b/mm/bootmem.c
@@ -99,7 +99,7 @@ static unsigned long __init init_bootmem_core(bootmem_data_t *bdata,
 	unsigned long mapsize;
 
 	mminit_validate_memmodel_limits(&start, &end);
-	bdata->node_bootmem_map = phys_to_virt(PFN_PHYS(mapstart));
+	bdata->node_bootmem_map = __va(PFN_PHYS(mapstart));
 	bdata->node_min_pfn = start;
 	bdata->node_low_pfn = end;
 	link_bootmem(bdata);
@@ -585,7 +585,7 @@ find_block:
 				PFN_UP(end_off), BOOTMEM_EXCLUSIVE))
 			BUG();
 
-		region = phys_to_virt(PFN_PHYS(bdata->node_min_pfn) +
+		region = __va(PFN_PHYS(bdata->node_min_pfn) +
 				start_off);
 		memset(region, 0, size);
 		/*

Re: [uml-devel] [PATCH v2 09/10] tty: Consolidate noctty checks in tty_open()

[Peter H. <pe...@hu...>]

Hi Richard,

On 03/26/2016 10:58 AM, Richard Weinberger wrote:
> On Sun, Jan 10, 2016 at 6:13 AM, Peter Hurley <pe...@hu...> wrote:
>> Evaluate the conditions which prevent this tty being the controlling
>> terminal in one place, just before setting the controlling terminal.
>>
>> Signed-off-by: Peter Hurley <pe...@hu...>
>> ---
>>  drivers/tty/tty_io.c | 17 ++++++++---------
>>  1 file changed, 8 insertions(+), 9 deletions(-)
> 
> Peter,
> 
> This commit breaks existing userspace.
> I noticed that on UserModeLinux with Debian Squeeze as userspace, getty does not
> give me a controlling tty upon login.
> It does not seem to happen on newer distros. But still this needs
> further investigation.
> 
> Please me know what debug information you need.

Sorry about that; I hadn't considered the implications of UML console.
Can you test the blob below?

Regards,
Peter Hurley

--- >% ---
diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c
index 608beb6..a361c61 100644
--- a/drivers/tty/tty_io.c
+++ b/drivers/tty/tty_io.c
@@ -2158,7 +2157,9 @@ retry_open:
 	read_lock(&tasklist_lock);
 	spin_lock_irq(&current->sighand->siglock);
 	noctty = (filp->f_flags & O_NOCTTY) ||
+#ifdef CONFIG_VT
 			device == MKDEV(TTY_MAJOR, 0) ||
+#endif
 			device == MKDEV(TTYAUX_MAJOR, 1) ||
 			(tty->driver->type == TTY_DRIVER_TYPE_PTY &&
 			 tty->driver->subtype == PTY_TYPE_MASTER);

Re: [uml-devel] [PATCH v2 09/10] tty: Consolidate noctty checks in tty_open()

[Richard W. <ri...@no...>]

Peter,

Am 26.03.2016 um 20:06 schrieb Peter Hurley:
> Sorry about that; I hadn't considered the implications of UML console.
> Can you test the blob below?

Yep, works like a charm. :-)

Thanks,
//richard