[PATCH 11/22] mtd: Fix dependencies for !HAS_IOMEM archs

[Richard Weinberger]

Not every arch has io memory.
So, unbreak the build by fixing the dependencies.

Signed-off-by: Richard Weinberger 
---
 drivers/mtd/nand/Kconfig| 2 ++
 drivers/mtd/spi-nor/Kconfig | 1 +
 2 files changed, 3 insertions(+)

diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index 20f01b3..545d82b 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -74,6 +74,7 @@ config MTD_NAND_DENALI_SCRATCH_REG_ADDR
 config MTD_NAND_GPIO
tristate "GPIO assisted NAND Flash driver"
depends on GPIOLIB || COMPILE_TEST
+   depends on HAS_IOMEM
help
  This enables a NAND flash driver where control signals are
  connected to GPIO pins, and commands and data are communicated
@@ -463,6 +464,7 @@ config MTD_NAND_MPC5121_NFC
 config MTD_NAND_VF610_NFC
tristate "Support for Freescale NFC for VF610/MPC5125"
depends on (SOC_VF610 || COMPILE_TEST)
+   depends on HAS_IOMEM
help
  Enables support for NAND Flash Controller on some Freescale
  processors like the VF610, MPC5125, MCF54418 or Kinetis K70.
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
-- 
1.8.4.5

[PATCH 12/22] nvmem: Fix dependencies for !HAS_IOMEM archs

[Richard Weinberger]

Not every arch has io memory.
So, unbreak the build by fixing the dependencies.

Signed-off-by: Richard Weinberger 
---
 drivers/nvmem/Kconfig | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig
index bc4ea58..c675ee9 100644
--- a/drivers/nvmem/Kconfig
+++ b/drivers/nvmem/Kconfig
@@ -28,6 +28,7 @@ config NVMEM_IMX_OCOTP
 config NVMEM_MXS_OCOTP
tristate "Freescale MXS On-Chip OTP Memory Support"
depends on ARCH_MXS || COMPILE_TEST
+   depends on HAS_IOMEM
help
  If you say Y here, you will get readonly access to the
  One Time Programmable memory pages that are stored
@@ -39,6 +40,7 @@ config NVMEM_MXS_OCOTP
 config QCOM_QFPROM
tristate "QCOM QFPROM Support"
depends on ARCH_QCOM || COMPILE_TEST
+   depends on HAS_IOMEM
select REGMAP_MMIO
help
  Say y here to enable QFPROM support. The QFPROM provides access
@@ -50,6 +52,7 @@ config QCOM_QFPROM
 config ROCKCHIP_EFUSE
tristate "Rockchip eFuse Support"
depends on ARCH_ROCKCHIP || COMPILE_TEST
+   depends on HAS_IOMEM
help
  This is a simple drive to dump specified values of Rockchip SoC
  from eFuse, such as cpu-leakage.
@@ -71,6 +74,7 @@ config NVMEM_SUNXI_SID
 config NVMEM_VF610_OCOTP
tristate "VF610 SoC OCOTP support"
depends on SOC_VF610 || COMPILE_TEST
+   depends on HAS_IOMEM
help
  This is a driver for the 'OCOTP' peripheral available on Vybrid
  devices like VF5xx and VF6xx.
-- 
1.8.4.5

[PATCH 05/22] hw_random: Fix dependencies for !HAS_IOMEM archs

[Richard Weinberger]

Not every arch has io memory.
So, unbreak the build by fixing the dependencies.

Signed-off-by: Richard Weinberger 
---
 drivers/char/hw_random/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/char/hw_random/Kconfig b/drivers/char/hw_random/Kconfig
index dbf2271..ff00331 100644
--- a/drivers/char/hw_random/Kconfig
+++ b/drivers/char/hw_random/Kconfig
@@ -372,6 +372,7 @@ config HW_RANDOM_XGENE
 config HW_RANDOM_STM32
tristate "STMicroelectronics STM32 random number generator"
depends on HW_RANDOM && (ARCH_STM32 || COMPILE_TEST)
+   depends on HAS_IOMEM
help
  This driver provides kernel-side support for the Random Number
  Generator hardware found on STM32 microcontrollers.
-- 
1.8.4.5

[PATCH 08/22] hwtracing: Fix dependencies for !HAS_IOMEM archs

[Richard Weinberger]

Not every arch has io memory.
So, unbreak the build by fixing the dependencies.

Signed-off-by: Richard Weinberger 
---
 drivers/hwtracing/intel_th/Kconfig | 1 +
 1 file changed, 1 insertion(+)

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
-- 
1.8.4.5

[PATCH] Revert "um: Fix get_signal() usage"

[Richard Weinberger]

Commit db2f24dc240856fb1d78005307f1523b7b3c121b
was plain wrong. I did not realize the we are
allowed to loop here.
In fact we have to loop and must not return to userspace
before all SIGSEGVs have been delivered.
Other archs do this directly in their entry code, UML
does it here.

Reported-by: Al Viro 
Signed-off-by: Richard Weinberger 

diff --git a/arch/um/kernel/signal.c b/arch/um/kernel/signal.c
index fc8be0e..57acbd6 100644
--- a/arch/um/kernel/signal.c
+++ b/arch/um/kernel/signal.c
@@ -69,7 +69,7 @@ void do_signal(struct pt_regs *regs)
struct ksignal ksig;
int handled_sig = 0;
 
-   if (get_signal()) {
+   while (get_signal()) {
handled_sig = 1;
/* Whee!  Actually deliver the signal.  */
handle_signal(, regs);
-- 
1.8.4.5

Re: [PATCH v3 3/3] MIPS: VDSO: Add implementations of gettimeofday() and clock_gettime()

[Hauke Mehrtens]

On 10/21/2015 10:57 AM, Markos Chandras wrote:
> From: Alex Smith 
> 
> Add user-mode implementations of gettimeofday() and clock_gettime() to
> the VDSO. This is currently usable with 2 clocksources: the CP0 count
> register, which is accessible to user-mode via RDHWR on R2 and later
> cores, or the MIPS Global Interrupt Controller (GIC) timer, which
> provides a "user-mode visible" section containing a mirror of its
> counter registers. This section must be mapped into user memory, which
> is done below the VDSO data page.
> 
> When a supported clocksource is not in use, the VDSO functions will
> return -ENOSYS, which causes libc to fall back on the standard syscall
> path.
> 
> When support for neither of these clocksources is compiled into the
> kernel at all, the VDSO still provides clock_gettime(), as the coarse
> realtime/monotonic clocks can still be implemented. However,
> gettimeofday() is not provided in this case as nothing can be done
> without a suitable clocksource. This causes the symbol lookup to fail
> in libc and it will then always use the standard syscall path.
> 
> This patch includes a workaround for a bug in QEMU which results in
> RDHWR on the CP0 count register always returning a constant (incorrect)
> value. A fix for this has been submitted, and the workaround can be
> removed after the fix has been in stable releases for a reasonable
> amount of time.
> 
> A simple performance test which calls gettimeofday() 1000 times in a
> loop and calculates the average execution time gives the following
> results on a Malta + I6400 (running at 20MHz):
> 
>  - Syscall:~31000 ns
>  - VDSO (GIC): ~15000 ns
>  - VDSO (CP0): ~9500 ns
> 
> [markos.chand...@imgtec.com:
> - Minor code re-arrangements in order for mappings to be made
> in the order they appear to the process' address space.
> - Move do_{monotonic, realtime} outside of the MIPS_CLOCK_VSYSCALL ifdef
> - Use gic_get_usm_range so we can do the GIC mapping in the
> arch/mips/kernel/vdso instead of the GIC irqchip driver]
> 
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Alex Smith 
> Signed-off-by: Markos Chandras 
> ---
> Changes since v2:
> - Do not export VDSO symbols if the toolchain does not have proper support
> for the VDSO.
> 
> Changes since v1:
> - Use gic_get_usm_range so we can do the GIC mapping in the
> arch/mips/kernel/vdso instead of the GIC irqchip driver
> ---
>  arch/mips/Kconfig|   5 +
>  arch/mips/include/asm/clocksource.h  |  29 +
>  arch/mips/include/asm/vdso.h |  68 +-
>  arch/mips/kernel/csrc-r4k.c  |  44 +++
>  arch/mips/kernel/vdso.c  |  71 ++-
>  arch/mips/vdso/gettimeofday.c| 232 
> +++
>  arch/mips/vdso/vdso.h|   9 ++
>  arch/mips/vdso/vdso.lds.S|   5 +
>  drivers/clocksource/mips-gic-timer.c |   7 +-
>  9 files changed, 460 insertions(+), 10 deletions(-)
>  create mode 100644 arch/mips/include/asm/clocksource.h
>  create mode 100644 arch/mips/vdso/gettimeofday.c
> 



> +
> +int __vdso_clock_gettime(clockid_t clkid, struct timespec *ts)
> +{
> + const union mips_vdso_data *data = get_vdso_data();
> + int ret;
> +
> + switch (clkid) {
> + case CLOCK_REALTIME_COARSE:
> + ret = do_realtime_coarse(ts, data);
> + break;
> + case CLOCK_MONOTONIC_COARSE:
> + ret = do_monotonic_coarse(ts, data);
> + break;
> + case CLOCK_REALTIME:
> + ret = do_realtime(ts, data);
> + break;
> + case CLOCK_MONOTONIC:
> + ret = do_monotonic(ts, data);
> + break;
> + default:
> + ret = -ENOSYS;
> + break;
> + }
> +
> + /* If we return -ENOSYS libc should fall back to a syscall. */

This comment is important.

The other architectures (checked arm64, tile, x86) are calling the
original syscall instead of returning -ENOSYS here. This will confuse
people trying to use this feature like me.

When the libc does not call the normal syscall this will cause problems.

> + return ret;
> +}

Hauke

Re: [PATCH] Revert "regmap-mmio: Use native endianness for read/write"

[Mark Brown]

On Mon, Jan 25, 2016 at 11:07:55PM +0100, Johannes Berg wrote:
> This reverts commit 29bb45f25ff3051354ed330c0d0f10418a2b8c7c.

Sorry, this just turned up now - must've got delayed somewhere along the
line.


signature.asc
Description: PGP signature

Re: [PATCH] autofs: show pipe inode in mount options

[Stephen Rothwell]

Hi Ian,

On Sat, 23 Jan 2016 08:30:17 +0800 Ian Kent  wrote:
>
> I haven't had anything significant enough for autofs to warrant
> maintaining a tree and sending push requests so I'll need to ask
> Stephen what I need to do (perhaps you could offer some advise on that
> now Stephen, please).

I guess if its just a few patches every now and then, then Andrew
Morton may be the best person to shepherd them upstream.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

Re: [PATCH] ALSA: bebob: Use a signed return type for get_formation_index

[Takashi Sakamoto]

On Jan 26 2016 06:30, Lucas Tanure wrote:
> The return type "unsigned int" was used by the get_formation_index function
> despite of the aspect that it will eventually return a negative   error 
> code.
> So, change to signed int and get index by reference in the parameters.
> 
> Done with the help of Coccinelle.
> 
> Signed-off-by: Lucas Tanure 
> ---
>  sound/firewire/bebob/bebob_stream.c | 11 +++
>  1 file changed, 7 insertions(+), 4 deletions(-)
> 
> diff --git a/sound/firewire/bebob/bebob_stream.c 
> b/sound/firewire/bebob/bebob_stream.c
> index 926e5dc..79940e3 100644
> --- a/sound/firewire/bebob/bebob_stream.c
> +++ b/sound/firewire/bebob/bebob_stream.c
> @@ -47,14 +47,15 @@ static const unsigned int bridgeco_freq_table[] = {
>   [6] = 0x07,
>  };
>  
> -static unsigned int
> -get_formation_index(unsigned int rate)
> +static int
> +get_formation_index(unsigned int rate, unsigned int *index)
>  {
>   unsigned int i;
>  
>   for (i = 0; i < ARRAY_SIZE(snd_bebob_rate_table); i++) {
>   if (snd_bebob_rate_table[i] == rate)
> - return i;
> + *index = i;
> + return 0;
>   }
>   return -EINVAL;
>  }
> @@ -425,7 +426,9 @@ make_both_connections(struct snd_bebob *bebob, unsigned 
> int rate)
>   goto end;
>  
>   /* confirm params for both streams */
> - index = get_formation_index(rate);
> + err = get_formation_index(rate, );
> + if (err < 0)
> + goto end;
>   pcm_channels = bebob->tx_stream_formations[index].pcm;
>   midi_channels = bebob->tx_stream_formations[index].midi;
>   err = amdtp_am824_set_parameters(>tx_stream, rate,

Indeed, it's my mistake.

Reviewed-by: Takashi Sakamoto 
Tested-by: Takashi Sakamoto 

This should go for -stable and 4.5-rc2.
CC: sta...@vger.kernel.org


Regards

Takashi Sakamoto

Re: [PATCH 0/2] sysctl: allow CLONE_NEWUSER to be disabled

[Andy Lutomirski]

On Mon, Jan 25, 2016 at 2:34 PM, Kees Cook  wrote:
> On Mon, Jan 25, 2016 at 11:33 AM, Eric W. Biederman
>  wrote:
>> Kees Cook  writes:
>>>
>>> Well, I don't know about less weird, but it would leave a unneeded
>>> hole in the permission checks.
>>
>> To be clear the current patch has my:
>>
>> Nacked-by: "Eric W. Biederman" 
>>
>> The code is buggy, and poorly thought through.  Your lack of interest in
>> fixing the bugs in your patch is distressing.
>
> I'm not sure where you see me having a "lack of interest". The
> existing cap-checking sysctls have a corner-case bug, which is
> orthogonal to this change.
>
>> So broken code, not willing to fix.  No. We are not merging this sysctl.
>
> I think you're jumping to conclusions. :)
>
> This feature is already implemented by two distros, and likely wanted
> by others. We cannot ignore that. The sysctl default doesn't change
> the existing behavior, so this doesn't get in your way at all. Can you
> please respond to my earlier email where I rebutted each of your
> arguments against it? Just saying "no" and putting words in my mouth
> isn't very productive.
>
> Andy, given your interest in this feature, and my explanation of the
> CAP_SYSADMIN check, what are your thoughts?
>

I think the sysctl sucks, but I don't have a better idea, so I think
it should go in.  There's clearly demand.

A better change would be to have an option to tighten up what
namespaces can be manipulated in which manner.  If anyone wants to
step up and do that, it sounds useful.  Denying CAP_NET_ADMIN in an
unprivileged user ns would address one piece of attack surface.  There
are probably others.

*However*, I think that trying to protect against a hypothetical
attacker with uid == global root who has procfs access but doesn't
have CAP_SYS_ADMIN isn't important enough to be worth introducing yet
another bad capable() call.

Whoever wants to tilt at the windmill of fixng sysctl permissions can
address all of them, and then maybe this sysctl would be worth
tightening up.

--Andy

Re: [kernel-hardening] [RFC][PATCH 3/3] mm/page_poisoning.c: Allow for zero poisoning

[Kees Cook]

On Mon, Jan 25, 2016 at 12:16 PM, Dave Hansen  wrote:
> Thanks for doing this!  It all looks pretty straightforward.
>
> On 01/25/2016 08:55 AM, Laura Abbott wrote:
>> By default, page poisoning uses a poison value (0xaa) on free. If this
>> is changed to 0, the page is not only sanitized but zeroing on alloc
>> with __GFP_ZERO can be skipped as well. The tradeoff is that detecting
>> corruption from the poisoning is harder to detect. This feature also
>> cannot be used with hibernation since pages are not guaranteed to be
>> zeroed after hibernation.
>
> Ugh, that's a good point about hibernation.  I'm not sure how widely it
> gets used but it does look pretty widely enabled in distribution kernels.
>
> Is this something that's fixable?  It seems like we could have the
> hibernation code run through and zero all the free lists.  Or, we could
> just disable the optimization at runtime when a hibernation is done.

We can also make hibernation run-time disabled when poisoning is used
(similar to how kASLR disables it).

> Not that we _have_ to do any of this now, but if a runtime knob (like a
> sysctl) could be fun too.  I would be nice for folks to turn it on and
> off if they wanted the added security of "real" poisoning vs. the
> potential performance boost from this optimization.
>
>> +static inline bool should_zero(void)
>> +{
>> + return !IS_ENABLED(CONFIG_PAGE_POISONING_ZERO) ||
>> + !page_poisoning_enabled();
>> +}
>
> I wonder if calling this "free_pages_prezeroed()" would make things a
> bit more clear when we use it in prep_new_page().
>
>>  static int prep_new_page(struct page *page, unsigned int order, gfp_t 
>> gfp_flags,
>>   int 
>> alloc_flags)
>>  {
>> @@ -1401,7 +1407,7 @@ static int prep_new_page(struct page *page, unsigned 
>> int order, gfp_t gfp_flags,
>>   kernel_map_pages(page, 1 << order, 1);
>>   kasan_alloc_pages(page, order);
>>
>> - if (gfp_flags & __GFP_ZERO)
>> + if (should_zero() && gfp_flags & __GFP_ZERO)
>>   for (i = 0; i < (1 << order); i++)
>>   clear_highpage(page + i);
>
> It's probably also worth pointing out that this can be a really nice
> feature to have in virtual machines where memory is being deduplicated.
>  As it stands now, the free lists end up with gunk in them and tend not
> to be easy to deduplicate.  This patch would fix that.

Oh, good point!

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security

Re: [PATCH v3 00/10] usb: host: ehci-sched: cleanup

[Geyslan G. Bem]

2016-01-25 17:40 GMT-03:00 Alan Stern :
> On Mon, 25 Jan 2016, Geyslan G. Bem wrote:
>
>> 2016-01-25 17:08 GMT-03:00 Alan Stern :
>> > On Mon, 25 Jan 2016, Geyslan G. Bem wrote:
>> >
>> >> Ok Greg, there was three patchset versions for this file that would
>> >> count over 40+ emails. This is v3. I didn't find any answer with ack
>> >> for it.
>> >> About sending, there's no problem, I'm here trying to help :-) but in
>> >> order to not increase the noise that I have created I would like to
>> >> wait Alan's answer.
>> >>
>> >> Alan, could you please analyze this?
>> >
>> > How was v3 different from v2?
>>
>> Just an undo: 
>> http://thread.gmane.org/gmane.linux.kernel/2107373/focus=2107376
>>
>> I'm sorry for not put it in the cover letter.
>
> Ah yes, now I remember.  For the whole v3 series:
>
> Acked-by: Alan Stern 

Thank you, I'll merge my branches to resend _everything_ as a single
patchset the way Greg asked:

[PATCH resend 0/9] usb: host: ehci.h cleanup
[PATCH v3 00/16] usb: host: ehci-dbg: cleanup and refactoring
[PATCH] usb: ehci: remove old stub_debug_files definition
[PATCH v3 00/10] usb: host: ehci-sched: cleanup (THIS)

I think that it's all.

>
> Alan Stern
>



-- 
Regards,

Geyslan G. Bem
hackingbits.com

Re: [Xen-devel] [PATCH v1 04/12] xen/hvmlite: Bootstrap HVMlite guest

[Luis R. Rodriguez]

On Sat, Jan 23, 2016 at 02:49:36PM +, Andrew Cooper wrote:
> On 23/01/2016 00:55, Luis R. Rodriguez wrote:
> > On Fri, Jan 22, 2016 at 4:30 PM, Andrew Cooper
> >  wrote:
> >> the DMLite boot
> >> protocol is OS agnostic, and will be staying that way.
> > What's the DMLite boot protocol?
> 
> It is  a statement of the initial state of a DMLite container.

I see.

> > Is that the protocol that is defined by Xen to boot Xen guests and dom0?
> 
> Technically it is toolstack which constructs this initial state, but
> broadly yes.

I see thanks.

> >  Is this well documented somewhere?
> 
> There is a patch out on the list formalising the ABI in writing. (Roger:
> ping?)

Thanks for this.

> > To be clear are you saying that by no means will Xen change to instead
> > of setting a, say zero-page, it would just want to always stuff a xen
> > struct, pass that to the boot entry, and then expect always the guest
> > kernel to always parse this?
> 
> Correct.  Why do you think we should lumber non-Linux guests with a
> Linux-specific boot protocol?

You should by no means do that, agreed, however one should have the
flexibility to support such types of OSes that use page specific
settings for the OS. The way I see it this is an OS feature and
obviously it can vary.

> Quite apart from the fact that Linux is second to the table here
> (FreeBSD was first),

This means little but just history.

> it causes inappropriate linkage between the
> toolstack and the version of Linux wishing to be booted.

There are ways to do it in such a way that it does not create dependency issues
on Linux specific code.


0) The Xen way and EFI way

A generic data structure is passed to the entry point on the kernel to
load the kernel. The kernel in turn must parse this generic specific struct
and interprets it and translate it to the kernel specific values.

1) The qemu way:

One way is to simply not refer to the boot_params data structures but IMHO that
produces really ugly code. The qemu folks did it this way, so qemu does not use
arch/x86/include/uapi/asm/bootparam.h in any way, instead it uses offsets from
a char *header. Refer to load_linux() in hw/i386/pc.c, for instance:

header[0x211] |= 0x80;  /* CAN_USE_HEAP */

2) The grub way:

Another way, which grub uses, is to define their own data structures based
on arch/x86/include/uapi/asm/bootparam.h, with their own data types, and refer
to them in code, for instance refer to grub_cmd_linux() on the grub file
grub-core/loader/i386/pc/linux.c and its copy definition of the header 
definition
in include/grub/i386/linux.h.

lh.loadflags |= GRUB_LINUX_FLAG_CAN_USE_HEAP;

The way lguest does it in the lguest launcher is IMHO the cleanest of course,
but it includes asm/bootparam.h and uses that in code:

/* Boot protocol version: 2.07 supports the fields for lguest. */   
boot->hdr.version = 0x207;  

But that does mean copying over or using the bootparam.h file and using
linux data types.

3) Merge of xen way and using subarch_data

Only set the subarch and subarch_data pointer, and have the kernel then
read the generic data structure and parse it as it used to, the benefit
is sharing a common entry point.

No one uses this yet. But I think its a reasonable compromise.

Perhaps there are other ways as well.

> > If true, then by no means, no matter how hard we try, and no matter
> > what we do on the Linux front to help clean things up will we be able
> > to have a unified bare metal / Xen entry. I'm noting it could be
> > possible though provided we do just set the zero page, the subarch to
> > Xen and subarch_data to the Xen custom data structure.
> 
> All you need is a very small stub which starts per the DMLite ABI, sets
> up an appropriate zero_page, and jumps to the native entrypoint.

Right.

> However, this stub belongs in Linux, not in the Xen toolstack.  That
> way, when the Linux boot protocol is modified, both sides can be updated
> accordingly.

Makes sense the different entry points just seems best avoided if possible.

  Luis

[PATCH 19/22] thermal: Fix dependencies for !HAS_IOMEM archs

[Richard Weinberger]

Not every arch has io memory.
So, unbreak the build by fixing the dependencies.

Signed-off-by: Richard Weinberger 
---
 drivers/thermal/Kconfig| 7 +++
 drivers/thermal/ti-soc-thermal/Kconfig | 1 +
 2 files changed, 8 insertions(+)

diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index 8cc4ac6..8876c7e 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
@@ -224,6 +227,7 @@ config KIRKWOOD_THERMAL
tristate "Temperature sensor on Marvell Kirkwood SoCs"
depends on MACH_KIRKWOOD || COMPILE_TEST
depends on OF
+   depends on HAS_IOMEM
help
  Support for the Kirkwood thermal sensor driver into the Linux thermal
  framework. Only kirkwood 88F6282 and 88F6283 have this sensor.
@@ -232,6 +236,7 @@ config DOVE_THERMAL
tristate "Temperature sensor on Marvell Dove SoCs"
depends on ARCH_DOVE || MACH_DOVE || COMPILE_TEST
depends on OF
+   depends on HAS_IOMEM
help
  Support for the Dove thermal sensor driver in the Linux thermal
  framework.
@@ -250,6 +255,7 @@ config ARMADA_THERMAL
tristate "Armada 370/XP thermal management"
depends on ARCH_MVEBU || COMPILE_TEST
depends on OF
+   depends on HAS_IOMEM
help
  Enable this option if you want to have support for thermal management
  controller present in Armada 370 and Armada XP SoC.
@@ -372,6 +378,7 @@ endmenu
 
 menu "Samsung thermal drivers"
 depends on ARCH_EXYNOS || COMPILE_TEST
+depends on HAS_IOMEM
 source "drivers/thermal/samsung/Kconfig"
 endmenu
 
diff --git a/drivers/thermal/ti-soc-thermal/Kconfig 
b/drivers/thermal/ti-soc-thermal/Kconfig
index ea8283f..283d794 100644
--- a/drivers/thermal/ti-soc-thermal/Kconfig
+++ b/drivers/thermal/ti-soc-thermal/Kconfig
@@ -1,5 +1,6 @@
 config TI_SOC_THERMAL
tristate "Texas Instruments SoCs temperature sensor driver"
+   depends on HAS_IOMEM
help
  If you say yes here you get support for the Texas Instruments
  OMAP4460+ on die bandgap temperature sensor support. The register
-- 
1.8.4.5

[PATCH 22/22] um: Export pm_power_off

[Richard Weinberger]

...modules are using this symbol.
Export it like all other archs to.

Signed-off-by: Richard Weinberger 
---
 arch/um/kernel/reboot.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/um/kernel/reboot.c b/arch/um/kernel/reboot.c
index 9bdf67a..b60a9f8 100644
--- a/arch/um/kernel/reboot.c
+++ b/arch/um/kernel/reboot.c
@@ -12,6 +12,7 @@
 #include 
 
 void (*pm_power_off)(void);
+EXPORT_SYMBOL(pm_power_off);
 
 static void kill_off_processes(void)
 {
-- 
1.8.4.5

[PATCH 18/22] irqchip: Fix dependencies for !HAS_IOMEM archs

[Richard Weinberger]

Not every arch has io memory.
So, unbreak the build by fixing the dependencies.

Signed-off-by: Richard Weinberger 
---
 drivers/irqchip/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index 715923d..fb50911 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -159,6 +159,7 @@ config TB10X_IRQC
 config TS4800_IRQ
tristate "TS-4800 IRQ controller"
select IRQ_DOMAIN
+   depends on HAS_IOMEM
help
  Support for the TS-4800 FPGA IRQ controller
 
-- 
1.8.4.5

[PATCH 17/22] media: Fix dependencies for !HAS_IOMEM archs

[Richard Weinberger]

Not every arch has io memory.
While the driver has correct dependencies the select statement
will bypass the HAS_IOMEM dependency.
So, unbreak the build by rendering it into a real dependency.

Signed-off-by: Richard Weinberger 
---
 drivers/media/Kconfig | 3 +--
 drivers/media/usb/cx231xx/Kconfig | 2 +-
 2 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/media/Kconfig b/drivers/media/Kconfig
index a8518fb..5553cb1 100644
--- a/drivers/media/Kconfig
+++ b/drivers/media/Kconfig
@@ -187,8 +187,7 @@ config MEDIA_SUBDRV_AUTOSELECT
bool "Autoselect ancillary drivers (tuners, sensors, i2c, frontends)"
depends on MEDIA_ANALOG_TV_SUPPORT || MEDIA_DIGITAL_TV_SUPPORT || 
MEDIA_CAMERA_SUPPORT || MEDIA_SDR_SUPPORT
depends on HAS_IOMEM
-   select I2C
-   select I2C_MUX
+   depends on I2C_MUX && I2C
default y
help
  By default, a media driver auto-selects all possible ancillary
diff --git a/drivers/media/usb/cx231xx/Kconfig 
b/drivers/media/usb/cx231xx/Kconfig
index 0cced3e..30ae67d 100644
--- a/drivers/media/usb/cx231xx/Kconfig
+++ b/drivers/media/usb/cx231xx/Kconfig
@@ -1,13 +1,13 @@
 config VIDEO_CX231XX
tristate "Conexant cx231xx USB video capture support"
depends on VIDEO_DEV && I2C
+   depends on I2C_MUX
select VIDEO_TUNER
select VIDEO_TVEEPROM
depends on RC_CORE
select VIDEOBUF_VMALLOC
select VIDEO_CX25840
select VIDEO_CX2341X
-   select I2C_MUX
 
---help---
  This is a video4linux driver for Conexant 231xx USB based TV cards.
-- 
1.8.4.5

Re: [PATCH] Revert "regmap-mmio: Use native endianness for read/write"

[Arnd Bergmann]

On Monday 25 January 2016 23:07:55 Johannes Berg wrote:
> This reverts commit 29bb45f25ff3051354ed330c0d0f10418a2b8c7c.
> 
> Clearly, using "native" endianness is a terrible idea when
> devices are involved, since those devices are different hw
> from the CPU, won't change, and the CPU might be able to
> run in both big and little endian, like ARM and PowerPC can.
> Therefore, "native" endian doesn't really exist.
> 
> Consequently, this commit broke my HummingBoard i.MX6 in big
> endian mode since it would now try to talk to the little
> endian hardware with a big endian CPU without conversion.
> 
> What the patch really would have to do is introduce some kind
> of "device-endian" readl/writel, that takes the endianness of
> the device as an argument. That seems a bit overkill though,
> and would likely not generate any better code than the double
> byte-swaps that MIPS is getting now.
> 
> Therefore, simply revert the commit to fix the breakage.
> 
> Fixes: 29bb45f25ff3 ("regmap-mmio: Use native endianness for read/write")
> Signed-off-by: Johannes Berg 

I think it's more complicated than this unfortunately:

Most architectures behave the same way you explain: all I/O registers
are fixed-endian, and the CPU may also be fixed-endian or may
support both using a runtime switch, which we abstract using the
readl/writel etc helpers in Linux.

On MIPS, the CPU endianess is set at through an input signal
on the CPU core, and this cannot change during runtime but can
change between SoCs or can be configurable with a hardware jumper.
Some SoC vendors (notably Broadcom) decided to use the same signal
to control whether there is a byteswap on the device bus or not,
so the on-chip MMIO registers are always the same endianess as
the CPU itself. 

This means that the devices are in fact CPU-endian, and we need
some way for Linux to represent this. The patch to
drivers/base/regmap/regmap-mmio.c is clearly wrong, as we
must never use __raw_*() accessors in an architecture independent
driver (for a number of reasons), but we still need a fix for
MIPS so it can specify a way to do the double-swap without
faking the endianess of the registers.

Also, defaulting syscon to "native-endian" when nothing else is
specified sounds like a bad idea, but we may already be stuck there
with the precedent in existing bindings after 6a55244e897d
("regmap: mmio: request native endian formatting"), we'll have
to think about that some more.

Arnd

[PATCH 20/22] clocksource: Fix dependencies for !HAS_IOMEM archs

[Richard Weinberger]

Not every arch has io memory.
So, unbreak the build by fixing the dependencies.

[rw: Found these linker issues after
resolving a pile of other build issues.]
Signed-off-by: Richard Weinberger 
---
 drivers/clocksource/Kconfig | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index 56777f0..224841e 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -30,6 +30,7 @@ config CLKSRC_MMIO
 config DIGICOLOR_TIMER
bool "Digicolor timer driver" if COMPILE_TEST
depends on GENERIC_CLOCKEVENTS
+   depends on HAS_IOMEM
help
  Enables the support for the digicolor timer driver.
 
@@ -76,6 +77,7 @@ config ORION_TIMER
 config SUN4I_TIMER
bool "Sun4i timer driver" if COMPILE_TEST
depends on GENERIC_CLOCKEVENTS
+   depends on HAS_IOMEM
select CLKSRC_MMIO
help
  Enables support for the Sun4i timer.
@@ -96,6 +98,7 @@ config TEGRA_TIMER
 config VT8500_TIMER
bool "VT8500 timer driver" if COMPILE_TEST
depends on GENERIC_CLOCKEVENTS
+   depends on HAS_IOMEM
help
  Enables support for the VT8500 driver.
 
@@ -131,6 +134,7 @@ config CLKSRC_NOMADIK_MTU_SCHED_CLOCK
 config CLKSRC_DBX500_PRCMU
bool "Clocksource PRCMU Timer" if COMPILE_TEST
depends on GENERIC_CLOCKEVENTS
+   depends on HAS_IOMEM
help
  Use the always on PRCMU Timer as clocksource
 
@@ -248,6 +252,7 @@ config CLKSRC_EXYNOS_MCT
 config CLKSRC_SAMSUNG_PWM
bool "PWM timer drvier for Samsung S3C, S5P" if COMPILE_TEST
depends on GENERIC_CLOCKEVENTS
+   depends on HAS_IOMEM
help
  This is a new clocksource driver for the PWM timer found in
  Samsung S3C, S5P and Exynos SoCs, replacing an earlier driver
@@ -257,6 +262,7 @@ config CLKSRC_SAMSUNG_PWM
 config FSL_FTM_TIMER
bool "Freescale FlexTimer Module driver" if COMPILE_TEST
depends on GENERIC_CLOCKEVENTS
+   depends on HAS_IOMEM
select CLKSRC_MMIO
help
  Support for Freescale FlexTimer Module (FTM) timer.
@@ -360,6 +366,7 @@ config CLKSRC_TANGO_XTAL
 config CLKSRC_PXA
bool "Clocksource for PXA or SA-11x0 platform" if COMPILE_TEST
depends on GENERIC_CLOCKEVENTS
+   depends on HAS_IOMEM
select CLKSRC_MMIO
help
  This enables OST0 support available on PXA and SA-11x0
-- 
1.8.4.5

[PATCH 21/22] mtd: cs553x: Fix dependencies for !HAS_IOMEM archs

[Richard Weinberger]

Not every arch has io memory nor can this driver ever work
on UML/i386.
So, unbreak the build by fixing the dependencies.

Signed-off-by: Richard Weinberger 
---
 drivers/mtd/nand/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index 545d82b..b253654 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -311,6 +311,7 @@ config MTD_NAND_CAFE
 config MTD_NAND_CS553X
tristate "NAND support for CS5535/CS5536 (AMD Geode companion chip)"
depends on X86_32
+   depends on !UML && HAS_IOMEM
help
  The CS553x companion chips for the AMD Geode processor
  include NAND flash controllers with built-in hardware ECC
-- 
1.8.4.5

Re: [PATCH 14/22] pwm: Fix dependencies for !HAS_IOMEM archs

[Richard Weinberger]

Am 25.01.2016 um 23:24 schrieb Richard Weinberger:
> Not every arch has io memory.
> So, unbreak the build by fixing the dependencies.
> 
> Signed-off-by: Richard Weinberger 
> ---
>  drivers/pwm/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
> index 8cf0dae..e83aa94 100644
> --- a/drivers/pwm/Kconfig
> +++ b/drivers/pwm/Kconfig
> @@ -150,6 +150,7 @@ config PWM_FSL_FTM
>   tristate "Freescale FlexTimer Module (FTM) PWM support"
>   depends on HAS_IOMEM
>   depends on OF
> + depends on HAS_IOMEM

Please drop this patch.

It was created before:
commit 36d5be4bc9059f8123e818c8b63a4049cf1d0e0f
Author: Vegard Nossum 
Date:   Sat Jan 2 14:02:07 2016 +0100

pwm: add HAS_IOMEM dependency to PWM_FSL_FTM

git am did not notice^^

Thanks,
//richard

Re: N900 sleep mode (in 4.5-rc0, if that matters)

[Tony Lindgren]

* Pavel Machek  [160125 14:24]:
> Hi!
> 
> First, thanks for the help!
> 
> > > So far, the LEDs stubbornly stay on :-(. Machine is booted off
> > > sd-card, and I'm connected to it over wifi. GSM is active, X is
> > > running.
> > 
> > If LEDs stay on, you're not entering deeper idle states.
> 
> Yes... Strange thing is, I'm not entering deeper idle states, and it still 
> breaks my wifi ;-).
> 
> > > 64 bytes from 192.168.43.15: icmp_seq=427 ttl=64 time=178 ms
> > 
> > Latencies of several hundred ms are expected when hitting off
> > mode during idle as the latency for power off the system during
> > idle is long. It could also be that there's a wakeirq config
> > missing somewhere. Does the WLAN have a separate GPIO irq?
> 
> Fair enough.
> 
> wl1251_pins: pinmux_wl1251 {
>  pinctrl-single,pins = < 0x0ce (PIN_OUTPUT | 
> MUX_MODE4)
>  /* gpio 87 => w\ l1251 enable */
>  0x05a (PIN_INPUT | 
> MUX_MODE4)
>  /* gpio 42 => w\ l1251 irq */
>  >;
>  };
> 
> Aha. wl1251 is on the spi bus, too.
> 
>  {
> pinctrl-names = "default";
>   pinctrl-0 = <_pins>;
> 
> wl1251@0 {
>   ...
>   interrupt-parent = <>;
>   interrupts = <10 IRQ_TYPE_NONE>; /* 
> gpio line 42 */
> };
> 
> And yes, it has a GPIO irq -- irq 42. What should be configured to
> make gpio 42 wake the system from deep idle?

We should do dev_pm_set_dedicated_wake_irq() on the pin related
to gpio42 in the WLAN driver. That way the pinctrl interrupt will
wake up the system and the GPIO interrupt should show up as it
presumably is a level interrupt. The interrupt probably should be
requested by wlcore as the SDIO chips also can have a GPIO interrupt.
That's the interrupts-extended entries we already have for 8250 and
MMC etc.

> > The workaround for now is to mux those pins permanently with
> > PIN_INPUT_PULLUP | MUX_MODE7 to keep them high using the
> > internal pull. So in this case, maybe give a try for adding
> > a pinctrl entry for tsc2005 for gpio104 to have it always
> > in PIN_INPUT_PULLUP | MUX_MODE7.
> 
> So the glitches on the GPIOs reset the tsc2005, even when it should be
> operational? That would explain stuff.

Yeah.

> I'll try to figure out the pinmux stuff. ... but I guess touchscreen
> is not really usable with screen off.

Could still wake up the system I guess if configured.

> > Typically you need at least USB disconnected and LCD blanked
> > to start hitting the deeper idle states :)
> 
> Right. So I was able to get SD-card to work, so USB was disconnected,
> but I was watching power consumption figures in a GTK window... on a
> LCD. Ok. I guess I can monitor the power consumption over the wlan.

Yeah in the long run initramfs + ssh over WLAN is probably the best
to develop with if you don't have a serial console wired up. That
allows hitting idle states with mosh at least working OK as long as
the WLAN wakeirq works properly.

Regards,

Tony

Re: [RESEND][PATCH v2] block: partition: Add partition specific uevent callbacks for partition info

[Kees Cook]

On Fri, Dec 18, 2015 at 8:07 PM, John Stultz  wrote:
> On Thu, Dec 10, 2015 at 12:00 PM, John Stultz  wrote:
>> From: San Mehat 
>>
>> This patch has been carried in the Android tree for quite some
>> time and is one of the few patches required to get a mainline
>> kernel up and running with an exsiting Android userspace. So I
>> wanted to submit it for review and consideration if it should
>> be merged.
>>
>> For partitions, add new uevent parameters 'PARTN' which
>> specifies the partitions index in the table, and 'PARTNAME',
>> which specifies PARTNAME specifices the partition name of a
>> partition device.
>>
>> Android's userspace uses this for creating device node links from the
>> partition name and number: ie:
>> /dev/block/platform/soc/by-name/system
>> or
>> /dev/block/platform/soc/by-num/p1
>>
>> One can see its usage here:
>> https://android.googlesource.com/platform/system/core/+/master/init/devices.cpp#355
>> and
>> https://android.googlesource.com/platform/system/core/+/master/init/devices.cpp#494
>>
>> Cc: Jens Axboe 
>> Cc: Rom Lemarchand 
>> Cc: Android Kernel Team 
>> Cc: Jeff Moyer 
>> Cc: har...@redhat.com
>> Cc: k...@redhat.com
>> Signed-off-by: Dima Zavin 
>> [Dropped NPARTS and reworded commit message for context]
>> Signed-off-by: John Stultz 
>
>
> Ping? Any thoughts on this? Am I missing someone on the CC list I
> should be including?
>
> thanks
> -john
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Hi Jens,

Are you able to take this into your tree? Should akpm carry it instead?

Thanks!

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security

Re: [Xen-devel] [PATCH v1 04/12] xen/hvmlite: Bootstrap HVMlite guest

[Boris Ostrovsky]

On 01/25/2016 05:19 PM, Luis R. Rodriguez wrote:

On Sat, Jan 23, 2016 at 02:49:36PM +, Andrew Cooper wrote:



it causes inappropriate linkage between the
toolstack and the version of Linux wishing to be booted.

There are ways to do it in such a way that it does not create dependency issues
on Linux specific code.


0) The Xen way and EFI way

A generic data structure is passed to the entry point on the kernel to
load the kernel. The kernel in turn must parse this generic specific struct
and interprets it and translate it to the kernel specific values.

1) The qemu way:

One way is to simply not refer to the boot_params data structures but IMHO that
produces really ugly code. The qemu folks did it this way, so qemu does not use
arch/x86/include/uapi/asm/bootparam.h in any way, instead it uses offsets from
a char *header. Refer to load_linux() in hw/i386/pc.c, for instance:

header[0x211] |= 0x80;  /* CAN_USE_HEAP */

2) The grub way:

Another way, which grub uses, is to define their own data structures based
on arch/x86/include/uapi/asm/bootparam.h, with their own data types, and refer
to them in code, for instance refer to grub_cmd_linux() on the grub file
grub-core/loader/i386/pc/linux.c and its copy definition of the header 
definition
in include/grub/i386/linux.h.

lh.loadflags |= GRUB_LINUX_FLAG_CAN_USE_HEAP;

The way lguest does it in the lguest launcher is IMHO the cleanest of course,
but it includes asm/bootparam.h and uses that in code:

/* Boot protocol version: 2.07 supports the fields for lguest. */
boot->hdr.version = 0x207;

But that does mean copying over or using the bootparam.h file and using
linux data types.

3) Merge of xen way and using subarch_data

Only set the subarch and subarch_data pointer, and have the kernel then
read the generic data structure and parse it as it used to, the benefit
is sharing a common entry point.

No one uses this yet. But I think its a reasonable compromise.

Perhaps there are other ways as well.


If true, then by no means, no matter how hard we try, and no matter
what we do on the Linux front to help clean things up will we be able
to have a unified bare metal / Xen entry. I'm noting it could be
possible though provided we do just set the zero page, the subarch to
Xen and subarch_data to the Xen custom data structure.

All you need is a very small stub which starts per the DMLite ABI, sets
up an appropriate zero_page, and jumps to the native entrypoint.

Right.



I am trying to understand what your objection is to what is proposed in 
this patch. It is the size of the stub? If yes -- what would you like to 
leave out to be done later?



-boris




However, this stub belongs in Linux, not in the Xen toolstack.  That
way, when the Linux boot protocol is modified, both sides can be updated
accordingly.

Makes sense the different entry points just seems best avoided if possible.

   Luis

[RESEND][RFC][PATCH] vsock: Fix blocking ops call in prepare_to_wait

[Laura Abbott]

We receoved a bug report from someone using vmware:

WARNING: CPU: 3 PID: 660 at kernel/sched/core.c:7389
__might_sleep+0x7d/0x90()
do not call blocking ops when !TASK_RUNNING; state=1 set at
[] prepare_to_wait+0x2d/0x90
Modules linked in: vmw_vsock_vmci_transport vsock snd_seq_midi
snd_seq_midi_event snd_ens1371 iosf_mbi gameport snd_rawmidi
snd_ac97_codec ac97_bus snd_seq coretemp snd_seq_device snd_pcm
snd_timer snd soundcore ppdev crct10dif_pclmul crc32_pclmul
ghash_clmulni_intel vmw_vmci vmw_balloon i2c_piix4 shpchp parport_pc
parport acpi_cpufreq nfsd auth_rpcgss nfs_acl lockd grace sunrpc btrfs
xor raid6_pq 8021q garp stp llc mrp crc32c_intel serio_raw mptspi vmwgfx
drm_kms_helper ttm drm scsi_transport_spi mptscsih e1000 ata_generic
mptbase pata_acpi
CPU: 3 PID: 660 Comm: vmtoolsd Not tainted
4.2.0-0.rc1.git3.1.fc23.x86_64 #1
Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop
Reference Platform, BIOS 6.00 05/20/2014
  49e617f3 88006ac37ac8 818641f5
  88006ac37b20 88006ac37b08 810ab446
 880068009f40 81c63bc0 0061 
Call Trace:
 [] dump_stack+0x4c/0x65
 [] warn_slowpath_common+0x86/0xc0
 [] warn_slowpath_fmt+0x55/0x70
 [] ? debug_lockdep_rcu_enabled+0x1d/0x20
 [] ? prepare_to_wait+0x2d/0x90
 [] ? prepare_to_wait+0x2d/0x90
 [] __might_sleep+0x7d/0x90
 [] __might_fault+0x43/0xa0
 [] copy_from_iter+0x87/0x2a0
 [] __qp_memcpy_to_queue+0x9a/0x1b0 [vmw_vmci]
 [] ? qp_memcpy_to_queue+0x20/0x20 [vmw_vmci]
 [] qp_memcpy_to_queue_iov+0x17/0x20 [vmw_vmci]
 [] qp_enqueue_locked+0xa0/0x140 [vmw_vmci]
 [] vmci_qpair_enquev+0x4f/0xd0 [vmw_vmci]
 [] vmci_transport_stream_enqueue+0x1b/0x20
[vmw_vsock_vmci_transport]
 [] vsock_stream_sendmsg+0x2c5/0x320 [vsock]
 [] ? wake_atomic_t_function+0x70/0x70
 [] sock_sendmsg+0x38/0x50
 [] SYSC_sendto+0x104/0x190
 [] ? vfs_read+0x8a/0x140
 [] SyS_sendto+0xe/0x10
 [] entry_SYSCALL_64_fastpath+0x12/0x76

transport->stream_enqueue may call copy_to_user so it should
not be called inside a prepare_to_wait. Narrow the scope of
the prepare_to_wait to avoid the bad call.

Signed-off-by: Laura Abbott 
---
Resending since I never heard back. This has been reported by
a couple of times again but nobody ever gets back to me about
whether this actually works. Still seems to be an issue as well.
---
 net/vmw_vsock/af_vsock.c | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/net/vmw_vsock/af_vsock.c b/net/vmw_vsock/af_vsock.c
index df5fc6b..fd68c88 100644
--- a/net/vmw_vsock/af_vsock.c
+++ b/net/vmw_vsock/af_vsock.c
@@ -1558,8 +1558,6 @@ static int vsock_stream_sendmsg(struct socket *sock, 
struct msghdr *msg,
if (err < 0)
goto out;
 
-   prepare_to_wait(sk_sleep(sk), , TASK_INTERRUPTIBLE);
-
while (total_written < len) {
ssize_t written;
 
@@ -1579,7 +1577,9 @@ static int vsock_stream_sendmsg(struct socket *sock, 
struct msghdr *msg,
goto out_wait;
 
release_sock(sk);
+   prepare_to_wait(sk_sleep(sk), , 
TASK_INTERRUPTIBLE);
timeout = schedule_timeout(timeout);
+   finish_wait(sk_sleep(sk), );
lock_sock(sk);
if (signal_pending(current)) {
err = sock_intr_errno(timeout);
@@ -1589,8 +1589,6 @@ static int vsock_stream_sendmsg(struct socket *sock, 
struct msghdr *msg,
goto out_wait;
}
 
-   prepare_to_wait(sk_sleep(sk), ,
-   TASK_INTERRUPTIBLE);
}
 
/* These checks occur both as part of and after the loop
@@ -1636,7 +1634,6 @@ static int vsock_stream_sendmsg(struct socket *sock, 
struct msghdr *msg,
 out_wait:
if (total_written > 0)
err = total_written;
-   finish_wait(sk_sleep(sk), );
 out:
release_sock(sk);
return err;
-- 
2.4.3

Re: [PATCH] proc: revert /proc//maps [stack:TID] annotation

[Kirill A. Shutemov]

On Mon, Jan 25, 2016 at 01:30:00PM -0800, Colin Cross wrote:
> On Tue, Jan 19, 2016 at 3:30 PM, Kirill A. Shutemov
>  wrote:
> > On Tue, Jan 19, 2016 at 02:14:30PM -0800, Andrew Morton wrote:
> >> On Tue, 19 Jan 2016 13:02:39 -0500 Johannes Weiner  
> >> wrote:
> >>
> >> > b764375 ("procfs: mark thread stack correctly in proc//maps")
> >> > added [stack:TID] annotation to /proc//maps. Finding the task of
> >> > a stack VMA requires walking the entire thread list, turning this into
> >> > quadratic behavior: a thousand threads means a thousand stacks, so the
> >> > rendering of /proc//maps needs to look at a million threads. The
> >> > cost is not in proportion to the usefulness as described in the patch.
> >> >
> >> > Drop the [stack:TID] annotation to make /proc//maps (and
> >> > /proc//numa_maps) usable again for higher thread counts.
> >> >
> >> > The [stack] annotation inside /proc//task//maps is retained,
> >> > as identifying the stack VMA there is an O(1) operation.
> >>
> >> Four years ago, ouch.
> >>
> >> Any thoughts on the obvious back-compatibility concerns?  ie, why did
> >> Siddhesh implement this in the first place?  My bad for not ensuring
> >> that the changelog told us this.
> >>
> >> https://lkml.org/lkml/2012/1/14/25 has more info:
> >>
> >> : Memory mmaped by glibc for a thread stack currently shows up as a
> >> : simple anonymous map, which makes it difficult to differentiate between
> >> : memory usage of the thread on stack and other dynamic allocation.
> >> : Since glibc already uses MAP_STACK to request this mapping, the
> >> : attached patch uses this flag to add additional VM_STACK_FLAGS to the
> >> : resulting vma so that the mapping is treated as a stack and not any
> >> : regular anonymous mapping.  Also, one may use vm_flags to decide if a
> >> : vma is a stack.
> >>
> >> But even that doesn't really tell us what the actual *value* of the
> >> patch is to end-users.
> >
> > I doubt it can be very useful as it's unreliable: if two stacks are
> > allocated end-to-end (which is not good idea, but still) it can only
> > report [stack:XXX] for the first one as they are merged into one VMA.
> > Any other anon VMA merged with the stack will be also claimed as stack,
> > which is not always correct.
> >
> > I think report the VMA as anon is the best we can know about it,
> > everything else just rather expensive guesses.
> 
> An alternative to guessing is the anonymous VMA naming patch used on
> Android, https://lkml.org/lkml/2013/10/30/518.  It allows userspace to
> name anonymous memory however it wishes, and prevents vma merging
> adjacent regions with different names.  Android uses it to label
> native heap memory, but it would work well for stacks too.

I don't think preventing vma merging is fair price for the feature: you
would pay extra in every find_vma() (meaning all page faults).

I think it would be nice to have a way to store this kind of sideband info
without impacting critical code path.

One other use case I see for such sideband info is storing hits from
MADV_HUGEPAGE/MADV_NOHUGEPAGE: need to split vma just for these hints is
unfortunate.

-- 
 Kirill A. Shutemov

[PATCH] acpi: fix platform_no_drv_owner.cocci warnings

[kbuild test robot]

drivers/acpi/evged.c:152:3-8: No need to set .owner here. The core will do it.

 Remove .owner field if calls are used which set it automatically

Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci

CC: Sinan Kaya 
Signed-off-by: Fengguang Wu 
---

 evged.c |1 -
 1 file changed, 1 deletion(-)

--- a/drivers/acpi/evged.c
+++ b/drivers/acpi/evged.c
@@ -149,7 +149,6 @@ static struct platform_driver ged_driver
.probe = ged_probe,
.driver = {
.name = MODULE_NAME,
-   .owner = THIS_MODULE,
.acpi_match_table = ACPI_PTR(ged_acpi_ids),
},
 };

Re: [PATCH] acpi: implement Generic Event Device

[kbuild test robot]

Hi Sinan,

[auto build test WARNING on pm/linux-next]
[also build test WARNING on v4.5-rc1 next-20160125]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improving the system]

url:
https://github.com/0day-ci/linux/commits/Sinan-Kaya/acpi-implement-Generic-Event-Device/20160126-053245
base:   https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git 
linux-next


coccinelle warnings: (new ones prefixed by >>)

>> drivers/acpi/evged.c:152:3-8: No need to set .owner here. The core will do 
>> it.

Please review and possibly fold the followup patch.

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation

[PATCH 1/4] kernel-doc: add support for asciidoc output

[Jonathan Corbet]

From: Jani Nikula 

Add new -asciidoc option to produce asciidoc output from kernel-doc. The
output is formatted internally, with no dependencies on external
tools. Any asciidoc formatting present in kernel-doc will naturally be
present in the resulting asciidoc as well.

Highlighting of functions(),  structures,  enumerations,
@parameters, etc. will be done by means of asciidoc. Anchors and
cross-references are added as well, providing hyperlinking support in
the result processed by asciidoc(1).

This support is non-conflicting and orthogonal to the patches adding
asciidoc support to the kernel-doc DocBook output [1]. Those patches
bolt on to the current document generation pipeline; there is currently
none for native asciidoc in the kernel (though ideas have been discussed
[2]). At this time, this patch should be considered a worthwhile
standalone improvement to kernel-doc, independent of the rest.

[1] 
http://mid.gmane.org/1448471279-19748-1-git-send-email-daniel.vet...@ffwll.ch
[2] http://mid.gmane.org/20160114131823.2ff43...@lwn.net

Cc: Jonathan Corbet 
Cc: Daniel Vetter 
Signed-off-by: Jani Nikula 
Signed-off-by: Jonathan Corbet 
---
 scripts/kernel-doc | 237 +
 1 file changed, 237 insertions(+)

diff --git a/scripts/kernel-doc b/scripts/kernel-doc
index c37255b..06f1649 100755
--- a/scripts/kernel-doc
+++ b/scripts/kernel-doc
@@ -201,6 +201,8 @@ my $type_param = '\@(\w+)';
 my $type_struct = '\&((struct\s*)*[_\w]+)';
 my $type_struct_xml = '\\((struct\s*)*[_\w]+)';
 my $type_env = '(\$\w+)';
+my $type_enum_full = '\&(enum)\s*([_\w]+)';
+my $type_struct_full = '\&(struct)\s*([_\w]+)';
 
 # Output conversion substitutions.
 #  One for each output format
@@ -266,6 +268,17 @@ my @highlights_text = (
  );
 my $blankline_text = "";
 
+# asciidoc-mode
+my @highlights_asciidoc = (
+   [$type_constant, "`\$1`"],
+   [$type_func, "<>"],
+   [$type_struct_full, "<<\$1_\$2,`\$1 \$2`>>"],
+   [$type_enum_full, "<<\$1_\$2,`\$1 \$2`>>"],
+   [$type_struct, "<>"],
+   [$type_param, "*\$1*"]
+ );
+my $blankline_asciidoc = "\n";
+
 # list mode
 my @highlights_list = (
[$type_constant, "\$1"],
@@ -402,6 +415,10 @@ while ($ARGV[0] =~ m/^-(.*)/) {
$output_mode = "text";
@highlights = @highlights_text;
$blankline = $blankline_text;
+} elsif ($cmd eq "-asciidoc") {
+   $output_mode = "asciidoc";
+   @highlights = @highlights_asciidoc;
+   $blankline = $blankline_asciidoc;
 } elsif ($cmd eq "-docbook") {
$output_mode = "xml";
@highlights = @highlights_xml;
@@ -1713,6 +1730,214 @@ sub output_blockhead_text(%) {
 }
 }
 
+##
+# output in asciidoc
+sub output_highlight_asciidoc {
+my $contents = join "\n",@_;
+my $line;
+
+# undo the evil effects of xml_escape() earlier
+$contents = xml_unescape($contents);
+
+eval $dohighlight;
+die $@ if $@;
+
+foreach $line (split "\n", $contents) {
+   if ($line eq "") {
+   print $lineprefix, $blankline;
+   } else {
+   $line =~ s/\\/\&/g;
+   print $lineprefix, $line;
+   }
+   print "\n";
+}
+}
+
+sub output_function_asciidoc(%) {
+my %args = %{$_[0]};
+my ($parameter, $section);
+my $start;
+
+print "[[func_$args{'function'}]]\n";
+print "=== " . $args{'function'} . " ===\n";
+print $args{'purpose'} . "\n\n";
+
+print "--\n";
+if ($args{'functiontype'} ne "") {
+   $start = $args{'functiontype'} . " " . $args{'function'} . " (";
+} else {
+   $start = $args{'function'} . " (";
+}
+print $start;
+
+my $count = 0;
+foreach my $parameter (@{$args{'parameterlist'}}) {
+   $type = $args{'parametertypes'}{$parameter};
+   if ($type =~ m/([^\(]*\(\*)\s*\)\s*\(([^\)]*)\)/) {
+   # pointer-to-function
+   print $1 . $parameter . ") (" . $2;
+   } else {
+   print $type . " " . $parameter;
+   }
+   if ($count != $#{$args{'parameterlist'}}) {
+   $count++;
+   print ",\n";
+   print " " x length($start);
+   } else {
+   print ");\n\n";
+   }
+}
+print "--\n";
+
+print ".Parameters\n";
+print "[horizontal]\n";
+foreach $parameter (@{$args{'parameterlist'}}) {
+   my $parameter_name = $parameter;
+   $parameter_name =~ s/\[.*//;
+   $type = $args{'parametertypes'}{$parameter};
+
+   print "`$type $parameter`::\n";
+   if ($args{'parameterdescs'}{$parameter_name} ne $undescribed) {
+   $blankline = "+";
+   output_highlight_asciidoc($args{'parameterdescs'}{$parameter_name});
+ 

[PATCH 2/4] docproc: handle asciidoc templates

[Jonathan Corbet]

There's really nothing different that needs to be done except for invoking
kernel-doc with the -asciidoc argument.  Look at the input file name to
recognize asciidoc templates, so no special command-line flags are needed.

Signed-off-by: Jonathan Corbet 
---
 scripts/docproc.c | 25 -
 1 file changed, 20 insertions(+), 5 deletions(-)

diff --git a/scripts/docproc.c b/scripts/docproc.c
index e267e621..89284b5 100644
--- a/scripts/docproc.c
+++ b/scripts/docproc.c
@@ -68,12 +68,15 @@ FILELINE * docsection;
 #define KERNELDOCPATH "scripts/"
 #define KERNELDOC "kernel-doc"
 #define DOCBOOK   "-docbook"
+#define ASCIIDOC  "-asciidoc"
 #define LIST  "-list"
 #define FUNCTION  "-function"
 #define NOFUNCTION"-nofunction"
 #define NODOCSECTIONS "-no-doc-sections"
 #define SHOWNOTFOUND  "-show-not-found"
 
+static char *doc_format = DOCBOOK;
+
 static char *srctree, *kernsrctree;
 
 static char **all_list = NULL;
@@ -242,7 +245,7 @@ static void find_export_symbols(char * filename)
 /*
  * Document all external or internal functions in a file.
  * Call kernel-doc with following parameters:
- * kernel-doc -docbook -nofunction function_name1 filename
+ * kernel-doc [-docbook|-asciidoc] -nofunction function_name1 filename
  * Function names are obtained from all the src files
  * by find_export_symbols.
  * intfunc uses -nofunction
@@ -263,7 +266,7 @@ static void docfunctions(char * filename, char * type)
exit(1);
}
vec[idx++] = KERNELDOC;
-   vec[idx++] = DOCBOOK;
+   vec[idx++] = doc_format;
vec[idx++] = NODOCSECTIONS;
for (i=0; i < symfilecnt; i++) {
struct symfile * sym = [i];
@@ -275,7 +278,7 @@ static void docfunctions(char * filename, char * type)
}
vec[idx++] = filename;
vec[idx] = NULL;
-   printf("\n", filename);
+   /* printf("\n", filename); */
exec_kernel_doc(vec);
fflush(stdout);
free(vec);
@@ -294,7 +297,7 @@ static void singfunc(char * filename, char * line)
int i, idx = 0;
int startofsym = 1;
vec[idx++] = KERNELDOC;
-   vec[idx++] = DOCBOOK;
+   vec[idx++] = doc_format;
vec[idx++] = SHOWNOTFOUND;
 
/* Split line up in individual parameters preceded by FUNCTION */
@@ -343,7 +346,7 @@ static void docsect(char *filename, char *line)
free(s);
 
vec[0] = KERNELDOC;
-   vec[1] = DOCBOOK;
+   vec[1] = doc_format;
vec[2] = SHOWNOTFOUND;
vec[3] = FUNCTION;
vec[4] = line;
@@ -497,6 +500,16 @@ static void parse_file(FILE *infile)
fflush(stdout);
 }
 
+/*
+ * Is this an asciidoc template?  Answer the question by seeing if its
+ * name ends in ".adt".
+ */
+static int is_asciidoc(const char *file)
+{
+   int len = strlen(file);
+
+   return len > 4 && ! strcmp(file + len - 4, ".adt");
+}
 
 int main(int argc, char *argv[])
 {
@@ -520,6 +533,8 @@ int main(int argc, char *argv[])
perror(argv[2]);
exit(2);
}
+   if (is_asciidoc(argv[2]))
+   doc_format = ASCIIDOC;
 
if (strcmp("doc", argv[1]) == 0) {
/* Need to do this in two passes.
-- 
2.7.0

Re: [PATCH v3] watchdog: Add watchdog timer support for the WinSystems EBC-C384

[William Breathitt Gray]

On 01/25/2016 03:42 PM, Guenter Roeck wrote:
> On 01/25/2016 11:28 AM, One Thousand Gnomes wrote:
>> If ask for 299 seconds surely I should get 300 not 240 ?
>> (Whether to round off or round up is an interesting question for the
>> middle range - does it go off early or late - I'd have said late but...)
>>
> 
> Matter of endless discussion. Some argue that the value should be rounded
> up, some argue that it should be rounded down, some argue that it should
> be rounded to the closest match. Each camp has its own valid arguments.
> I usually leave it up to the driver's author to decide, with a slight
> preference to never select a value larger than requested.

I implemented it to round down simply because it was the simplest
solution (i.e. integer truncation). Although I see merit in an   
implementation that rounds to the closest valid value, I'll keep the 
current implementation for now due to its simplicity; if enough users of 
the driver prefer a different implementation, then I'll add it in a  
later patch.

>> Is there no ACPI entry for it ?
>>
> Same here. As long as the board is identified, I tend to leave it up
> to the driver author to decide _how_ to identify it.
> 
> Only question for me would be if the watchdog timer is implemented
> in a Super-IO chip, and if so, if it would be possible to use the chip
> identification instead of a DMI (or ACPI) entry to instantiate the driver.

I do not believe there is an ACPI entry for it. Interestingly, the   
watchdog timer BIOS configuration option for this motherboard is listed  
under the Super I/O menu; perhaps this watchdog timer is implemented in  
the Super I/O chip.  
 
The manual for this motherboard does not provide much information about  
the Super I/O chip (no model number, etc.), and neither sensors-detect
nor superiotool was able to detect it. I've sent an email to the 
motherboard company (WinSystems) requesting further information about
the Super I/O chip and whether the watchdog timer is built-in to the 
Super I/O chip.  
 
William Breathitt Gray

Re: [PATCH] drm/exynos: fix building without CONFIG_PM_SLEEP

[Krzysztof Kozlowski]

2015-11-18 0:08 GMT+09:00 Arnd Bergmann :
> The runtime PM operations use the suspend/resume functions
> even when CONFIG_PM_SLEEP is not set, but this now fails
> for the exynos DRM driver:
>
> exynos_mixer.c:1289:61: error: 'exynos_mixer_resume' undeclared here (not in 
> a function)
>   SET_RUNTIME_PM_OPS(exynos_mixer_suspend, exynos_mixer_resume, NULL)
>
> This removes the #ifdef and instead marks the functions as
> __maybe_unused, which does the right thing in all cases and
> also looks nicer.
>
> Signed-off-by: Arnd Bergmann 
> Fixes:   ("drm/exynos: add pm_runtime to Mixer")

Dear Inki,

Ping? On 4.5-rc1 this is still broken. Can you apply this for fixes
for current rc-cycle?

Reviewed-by: Krzysztof Kozlowski 

Best regards,
Krzysztof


>
> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
> b/drivers/gpu/drm/exynos/exynos_mixer.c
> index 7498c6e76a53..fcaf71df77c1 100644
> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
> @@ -1230,8 +1230,7 @@ static int mixer_remove(struct platform_device *pdev)
> return 0;
>  }
>
> -#ifdef CONFIG_PM_SLEEP
> -static int exynos_mixer_suspend(struct device *dev)
> +static int __maybe_unused exynos_mixer_suspend(struct device *dev)
>  {
> struct mixer_context *ctx = dev_get_drvdata(dev);
> struct mixer_resources *res = >mixer_res;
> @@ -1247,7 +1246,7 @@ static int exynos_mixer_suspend(struct device *dev)
> return 0;
>  }
>
> -static int exynos_mixer_resume(struct device *dev)
> +static int __maybe_unused exynos_mixer_resume(struct device *dev)
>  {
> struct mixer_context *ctx = dev_get_drvdata(dev);
> struct mixer_resources *res = >mixer_res;
> @@ -1283,7 +1282,6 @@ static int exynos_mixer_resume(struct device *dev)
>
> return 0;
>  }
> -#endif
>
>  static const struct dev_pm_ops exynos_mixer_pm_ops = {
> SET_RUNTIME_PM_OPS(exynos_mixer_suspend, exynos_mixer_resume, NULL)
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 4/6] f2fs: avoid multiple node page writes due to inline_data

[Jaegeuk Kim]

The sceanrio is:
1. create fully node blocks
2. flush node blocks
3. write inline_data for all the node blocks again
4. flush node blocks redundantly

So, this patch tries to flush inline_data when flushing node blocks.

Signed-off-by: Jaegeuk Kim 
---
 fs/f2fs/data.c   |  1 +
 fs/f2fs/inline.c |  2 ++
 fs/f2fs/node.c   | 39 +++
 fs/f2fs/node.h   | 15 +++
 4 files changed, 57 insertions(+)

diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index 89a37ba..260c0eb 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -1463,6 +1463,7 @@ restart:
if (pos + len <= MAX_INLINE_DATA) {
read_inline_data(page, ipage);
set_inode_flag(F2FS_I(inode), FI_DATA_EXIST);
+   set_inline_node(ipage);
sync_inode_page();
} else {
err = f2fs_convert_inline_page(, page);
diff --git a/fs/f2fs/inline.c b/fs/f2fs/inline.c
index 8df13e5..fc4d298 100644
--- a/fs/f2fs/inline.c
+++ b/fs/f2fs/inline.c
@@ -159,6 +159,7 @@ no_update:
 
/* clear inline data and flag after data writeback */
truncate_inline_inode(dn->inode_page, 0);
+   clear_inline_node(dn->inode_page);
 clear_out:
stat_dec_inline_inode(dn->inode);
f2fs_clear_inline_inode(dn->inode);
@@ -233,6 +234,7 @@ int f2fs_write_inline_data(struct inode *inode, struct page 
*page)
set_inode_flag(F2FS_I(inode), FI_DATA_EXIST);
 
sync_inode_page();
+   clear_inline_node(dn.inode_page);
f2fs_put_dnode();
return 0;
 }
diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
index 23b800d..94a6755 100644
--- a/fs/f2fs/node.c
+++ b/fs/f2fs/node.c
@@ -1154,6 +1154,37 @@ void sync_inode_page(struct dnode_of_data *dn)
dn->node_changed = ret ? true: false;
 }
 
+static void flush_inline_data(struct f2fs_sb_info *sbi, nid_t ino)
+{
+   struct inode *inode;
+   struct page *page;
+
+   /* should flush inline_data before evict_inode */
+   inode = ilookup(sbi->sb, ino);
+   if (!inode)
+   return;
+
+   page = pagecache_get_page(inode->i_mapping, 0, FGP_LOCK|FGP_NOWAIT, 0);
+   if (!page)
+   goto iput_out;
+
+   if (!PageUptodate(page))
+   goto page_out;
+
+   if (!PageDirty(page))
+   goto page_out;
+
+   if (!clear_page_dirty_for_io(page))
+   goto page_out;
+
+   if (!f2fs_write_inline_data(inode, page))
+   inode_dec_dirty_pages(inode);
+page_out:
+   f2fs_put_page(page, 1);
+iput_out:
+   iput(inode);
+}
+
 int sync_node_pages(struct f2fs_sb_info *sbi, nid_t ino,
struct writeback_control *wbc)
 {
@@ -1221,6 +1252,14 @@ continue_unlock:
goto continue_unlock;
}
 
+   /* flush inline_data */
+   if (!ino && is_inline_node(page)) {
+   clear_inline_node(page);
+   unlock_page(page);
+   flush_inline_data(sbi, ino_of_node(page));
+   continue;
+   }
+
if (!clear_page_dirty_for_io(page))
goto continue_unlock;
 
diff --git a/fs/f2fs/node.h b/fs/f2fs/node.h
index 23bd992..1f4f9d4 100644
--- a/fs/f2fs/node.h
+++ b/fs/f2fs/node.h
@@ -379,6 +379,21 @@ static inline int is_node(struct page *page, int type)
 #define is_fsync_dnode(page)   is_node(page, FSYNC_BIT_SHIFT)
 #define is_dent_dnode(page)is_node(page, DENT_BIT_SHIFT)
 
+static inline int is_inline_node(struct page *page)
+{
+   return PageChecked(page);
+}
+
+static inline void set_inline_node(struct page *page)
+{
+   SetPageChecked(page);
+}
+
+static inline void clear_inline_node(struct page *page)
+{
+   ClearPageChecked(page);
+}
+
 static inline void set_cold_node(struct inode *inode, struct page *page)
 {
struct f2fs_node *rn = F2FS_NODE(page);
-- 
2.6.3

[PATCH 5/6] f2fs: don't need to sync node page at every time

[Jaegeuk Kim]

In write_end, we don't need to sync inode page at every time.
Instead, we can expect f2fs_write_inode will update later.

Signed-off-by: Jaegeuk Kim 
---
 fs/f2fs/data.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index 260c0eb..a6a6f08 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -1627,7 +1627,6 @@ static int f2fs_write_end(struct file *file,
if (pos + copied > i_size_read(inode)) {
i_size_write(inode, pos + copied);
mark_inode_dirty(inode);
-   update_inode_page(inode);
}
 
f2fs_put_page(page, 1);
-- 
2.6.3

[PATCH 6/6] f2fs: avoid needless sync_inode_page when reading inline_data

[Jaegeuk Kim]

In write_begin, if there is an inline_data, f2fs loads it into 0'th data page.
Since it's the read path, we don't need to sync its inode page.

Signed-off-by: Jaegeuk Kim 
---
 fs/f2fs/data.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index a6a6f08..4e992bf 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -1464,7 +1464,6 @@ restart:
read_inline_data(page, ipage);
set_inode_flag(F2FS_I(inode), FI_DATA_EXIST);
set_inline_node(ipage);
-   sync_inode_page();
} else {
err = f2fs_convert_inline_page(, page);
if (err)
-- 
2.6.3

[PATCH 13/22] net: Fix dependencies for !HAS_IOMEM archs

[Richard Weinberger]

Not every arch has io memory.
So, unbreak the build by fixing the dependencies.

Signed-off-by: Richard Weinberger 
---
 drivers/net/ethernet/ezchip/Kconfig | 1 +
 drivers/net/phy/Kconfig | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/net/ethernet/ezchip/Kconfig 
b/drivers/net/ethernet/ezchip/Kconfig
index 48ecbc8..b423ad3 100644
--- a/drivers/net/ethernet/ezchip/Kconfig
+++ b/drivers/net/ethernet/ezchip/Kconfig
@@ -18,6 +18,7 @@ if NET_VENDOR_EZCHIP
 config EZCHIP_NPS_MANAGEMENT_ENET
tristate "EZchip NPS management enet support"
depends on OF_IRQ && OF_NET
+   depends on HAS_IOMEM
---help---
  Simple LAN device for debug or management purposes.
  Device supports interrupts for RX and TX(completion).
diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
index 60994a8..f0a7702 100644
--- a/drivers/net/phy/Kconfig
+++ b/drivers/net/phy/Kconfig
@@ -186,6 +186,7 @@ config MDIO_GPIO
 config MDIO_OCTEON
tristate "Support for MDIO buses on Octeon and ThunderX SOCs"
depends on 64BIT
+   depends on HAS_IOMEM
help
 
  This module provides a driver for the Octeon and ThunderX MDIO
-- 
1.8.4.5

[PATCH 15/22] watchdog: Fix dependencies for !HAS_IOMEM archs

[Richard Weinberger]

Not every arch has io memory.
So, unbreak the build by fixing the dependencies.

Signed-off-by: Richard Weinberger 
---
 drivers/watchdog/Kconfig | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 4f0e7be..0bd559a 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -146,6 +146,7 @@ config TANGOX_WATCHDOG
tristate "Sigma Designs SMP86xx/SMP87xx watchdog"
select WATCHDOG_CORE
depends on ARCH_TANGOX || COMPILE_TEST
+   depends on HAS_IOMEM
help
  Support for the watchdog in Sigma Designs SMP86xx (tango3)
  and SMP87xx (tango4) family chips.
@@ -618,6 +619,7 @@ config DIGICOLOR_WATCHDOG
 config LPC18XX_WATCHDOG
tristate "LPC18xx/43xx Watchdog"
depends on ARCH_LPC18XX || COMPILE_TEST
+   depends on HAS_IOMEM
select WATCHDOG_CORE
help
  Say Y here if to include support for the watchdog timer
@@ -1374,6 +1376,7 @@ config BCM_KONA_WDT_DEBUG
 config BCM7038_WDT
tristate "BCM7038 Watchdog"
select WATCHDOG_CORE
+   depends on HAS_IOMEM
help
 Watchdog driver for the built-in hardware in Broadcom 7038 SoCs.
 
-- 
1.8.4.5

[PATCH 16/22] iio: imu: Fix dependencies for !HAS_IOMEM archs

[Richard Weinberger]

Not every arch has io memory.
While the driver has correct dependencies the select statement
will bypass the HAS_IOMEM dependency.
So, unbreak the build by rendering it into a real dependency.

Signed-off-by: Richard Weinberger 
---
 drivers/iio/imu/inv_mpu6050/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iio/imu/inv_mpu6050/Kconfig 
b/drivers/iio/imu/inv_mpu6050/Kconfig
index 48fbc0b..8f8d137 100644
--- a/drivers/iio/imu/inv_mpu6050/Kconfig
+++ b/drivers/iio/imu/inv_mpu6050/Kconfig
@@ -5,9 +5,9 @@
 config INV_MPU6050_IIO
tristate "Invensense MPU6050 devices"
depends on I2C && SYSFS
+   depends on I2C_MUX
select IIO_BUFFER
select IIO_TRIGGERED_BUFFER
-   select I2C_MUX
help
  This driver supports the Invensense MPU6050 devices.
  This driver can also support MPU6500 in MPU6050 compatibility mode
-- 
1.8.4.5

[PATCH 14/22] pwm: Fix dependencies for !HAS_IOMEM archs

[Richard Weinberger]

Not every arch has io memory.
So, unbreak the build by fixing the dependencies.

Signed-off-by: Richard Weinberger 
---
 drivers/pwm/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index 8cf0dae..e83aa94 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -150,6 +150,7 @@ config PWM_FSL_FTM
tristate "Freescale FlexTimer Module (FTM) PWM support"
depends on HAS_IOMEM
depends on OF
+   depends on HAS_IOMEM
select REGMAP_MMIO
help
  Generic FTM PWM framework driver for Freescale VF610 and
-- 
1.8.4.5

Re: [PATCH] Revert "regmap-mmio: Use native endianness for read/write"

[Johannes Berg]

On Mon, 2016-01-25 at 23:24 +0100, Arnd Bergmann wrote:
> On Monday 25 January 2016 23:07:55 Johannes Berg wrote:
> > This reverts commit 29bb45f25ff3051354ed330c0d0f10418a2b8c7c.
> > 
> > Clearly, using "native" endianness is a terrible idea when
> > devices are involved, since those devices are different hw
> > from the CPU, won't change, and the CPU might be able to
> > run in both big and little endian, like ARM and PowerPC can.
> > Therefore, "native" endian doesn't really exist.
> > 
> > Consequently, this commit broke my HummingBoard i.MX6 in big
> > endian mode since it would now try to talk to the little
> > endian hardware with a big endian CPU without conversion.
> > 
> > What the patch really would have to do is introduce some kind
> > of "device-endian" readl/writel, that takes the endianness of
> > the device as an argument. That seems a bit overkill though,
> > and would likely not generate any better code than the double
> > byte-swaps that MIPS is getting now.
> > 
> > Therefore, simply revert the commit to fix the breakage.
> > 
> > Fixes: 29bb45f25ff3 ("regmap-mmio: Use native endianness for
> > read/write")
> > Signed-off-by: Johannes Berg 
> 
> I think it's more complicated than this unfortunately:
> 
> Most architectures behave the same way you explain: all I/O registers
> are fixed-endian, and the CPU may also be fixed-endian or may
> support both using a runtime switch, which we abstract using the
> readl/writel etc helpers in Linux.
> 
> On MIPS, the CPU endianess is set at through an input signal
> on the CPU core, and this cannot change during runtime but can
> change between SoCs or can be configurable with a hardware jumper.
> Some SoC vendors (notably Broadcom) decided to use the same signal
> to control whether there is a byteswap on the device bus or not,
> so the on-chip MMIO registers are always the same endianess as
> the CPU itself.   

It's even *more* complicated :)

> This means that the devices are in fact CPU-endian, and we need
> some way for Linux to represent this. The patch to
> drivers/base/regmap/regmap-mmio.c is clearly wrong, as we
> must never use __raw_*() accessors in an architecture independent
> driver (for a number of reasons), but we still need a fix for
> MIPS so it can specify a way to do the double-swap without
> faking the endianess of the registers.

Mark points out that the regmap core (regmap.c) *does* in fact do the
byteswapping correctly, so it's fairly likely that - as odd as this
seems - using the __raw_*() accessors is actually correct.

> Also, defaulting syscon to "native-endian" when nothing else is
> specified sounds like a bad idea, but we may already be stuck there
> with the precedent in existing bindings after 6a55244e897d
> ("regmap: mmio: request native endian formatting"), we'll have
> to think about that some more.
> 

I can also get it back to working by adding "little-endian;" to the
iomuxc-gpr@020e syscon DT node in the dtb that I load, but perhaps
making the default architecture dependent and only using native for
MIPS might be better?

Or, perhaps, the code should just WARN() when endianness is unspecified
(assuming you can actually specify "native-endian;") and we need to fix
all of the instances...

johannes

Re: [PATCH 0/2] sysctl: allow CLONE_NEWUSER to be disabled

[Kees Cook]

On Mon, Jan 25, 2016 at 11:33 AM, Eric W. Biederman
 wrote:
> Kees Cook  writes:
>>
>> Well, I don't know about less weird, but it would leave a unneeded
>> hole in the permission checks.
>
> To be clear the current patch has my:
>
> Nacked-by: "Eric W. Biederman" 
>
> The code is buggy, and poorly thought through.  Your lack of interest in
> fixing the bugs in your patch is distressing.

I'm not sure where you see me having a "lack of interest". The
existing cap-checking sysctls have a corner-case bug, which is
orthogonal to this change.

> So broken code, not willing to fix.  No. We are not merging this sysctl.

I think you're jumping to conclusions. :)

This feature is already implemented by two distros, and likely wanted
by others. We cannot ignore that. The sysctl default doesn't change
the existing behavior, so this doesn't get in your way at all. Can you
please respond to my earlier email where I rebutted each of your
arguments against it? Just saying "no" and putting words in my mouth
isn't very productive.

Andy, given your interest in this feature, and my explanation of the
CAP_SYSADMIN check, what are your thoughts?

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security

Re: [PATCH] numa: fix /proc//numa_maps for hugetlbfs on s390

[Andrew Morton]

On Mon, 25 Jan 2016 17:30:42 +0100 Michael Holzheu  
wrote:

> When working with hugetlbfs ptes (which are actually pmds) is not
> valid to directly use pte functions like pte_present() because the
> hardware bit layout of pmds and ptes can be different. This is the
> case on s390. Therefore we have to convert the hugetlbfs ptes first
> into a valid pte encoding with huge_ptep_get().
> 
> Currently the /proc//numa_maps code uses hugetlbfs ptes without
> huge_ptep_get(). On s390 this leads to the following two problems:
> 
> 1) The pte_present() function returns false (instead of true) for
>PROT_NONE hugetlb ptes. Therefore PROT_NONE vmas are missing
>completely in the "numa_maps" output.
> 
> 2) The pte_dirty() function always returns false for all hugetlb ptes.
>Therefore these pages are reported as "mapped=xxx" instead of
>"dirty=xxx".
> 
> Therefore use huge_ptep_get() to correctly convert the hugetlb ptes.

I'm aiming this at 4.5 only.  Please let me know if you think that a
-stable backport is warranted.

Re: [PATCH 0/8] Goldfish: partial resync with Google tree

[Kees Cook]

On Wed, Jan 6, 2016 at 6:03 AM, Alan  wrote:
> The Goldfish virtual platform has been aligning itself a bit more with
> convenional interfaces. It now uses things like virtio, it uses ACPI in
> preference to a magic goldfish bus interface and slowly gets closer to
> upstream qemu.
>
> These patches pull relevant changes back from the Goldfish Google codebase
> back into upstream.

Consider the series:

Reviewed-by: Kees Cook 

Greg, can you pull these in? It reduces the Android delta. :)

-Kees

>
> ---
>
> Alex Bennée (1):
>   android_pipe: don't be clever with #define offsets
>
> Christoffer Dall (1):
>   android_pipe: Pin pages to memory while copying and other cleanups
>
> Greg Hackmann (3):
>   goldfish: refactor goldfish platform configs
>   platform: goldfish: pipe: add devicetree bindings
>   platform: goldfish: pipe: don't log when dropping PIPE_ERROR_AGAIN
>
> Jason Hu (1):
>   goldfish: Enable ACPI-based enumeration for android pipe
>
> Miodrag Dinic (1):
>   [MIPS] Enable platform support for Goldfish virtual devices
>
> Yu Ning (1):
>   goldfish_pipe: Pass physical addresses to the device if supported
>
>
>  .../devicetree/bindings/goldfish/pipe.txt  |   17 ++
>  drivers/platform/Kconfig   |3
>  drivers/platform/goldfish/Kconfig  |   18 ++
>  drivers/platform/goldfish/Makefile |2
>  drivers/platform/goldfish/goldfish_pipe.c  |  189 
> +---
>  5 files changed, 157 insertions(+), 72 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/goldfish/pipe.txt
>
> --
> "CMS is like a porcupine in a balloon factory"
> --Alan Altmark
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/



-- 
Kees Cook
Chrome OS & Brillo Security

Re: [PATCH] locking/mutex: Allow next waiter lockless wakeup

[Waiman Long]

On 01/24/2016 09:23 PM, Davidlohr Bueso wrote:

Make use of wake_q and enable the wakeup to occur after
releasing the wait_lock. This is similar to what we do
with rtmutex top waiter, slightly shortening the critical
region and allow other waiters to acquire the wait_lock
sooner. In low contention cases it can also help the
recently woken waiter to find the wait_lock available
(fastpath) when it continues execution.

Signed-off-by: Davidlohr Bueso 
---
 kernel/locking/mutex.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/kernel/locking/mutex.c b/kernel/locking/mutex.c
index 0551c21..e364b42 100644
--- a/kernel/locking/mutex.c
+++ b/kernel/locking/mutex.c
@@ -716,6 +716,7 @@ static inline void
 __mutex_unlock_common_slowpath(struct mutex *lock, int nested)
 {
 unsigned long flags;
+WAKE_Q(wake_q);

 /*
  * As a performance measurement, release the lock before doing other
@@ -743,11 +744,11 @@ __mutex_unlock_common_slowpath(struct mutex 
*lock, int nested)

struct mutex_waiter, list);

 debug_mutex_wake_waiter(lock, waiter);
-
-wake_up_process(waiter->task);
+wake_q_add(_q, waiter->task);
 }

 spin_unlock_mutex(>wait_lock, flags);
+wake_up_q(_q);
 }

 /*


This patch looks good to me.

Reviewed-by: Waiman Long 

Re: [PATCH] Revert "regmap-mmio: Use native endianness for read/write"

[Arnd Bergmann]

On Monday 25 January 2016 22:47:10 Mark Brown wrote:
> On Mon, Jan 25, 2016 at 11:24:44PM +0100, Arnd Bergmann wrote:
> > On Monday 25 January 2016 23:07:55 Johannes Berg wrote:
> > > Consequently, this commit broke my HummingBoard i.MX6 in big
> > > endian mode since it would now try to talk to the little
> > > endian hardware with a big endian CPU without conversion.
> 
> What I'd expect to be happening here is that either the driver or the
> DT should be specifying the endianness of the hardware.  If the device
> is always a given endianness then I'd expect that to turn up in the
> driver rather than the DT.
> 
> > > What the patch really would have to do is introduce some kind
> > > of "device-endian" readl/writel, that takes the endianness of
> > > the device as an argument. That seems a bit overkill though,
> > > and would likely not generate any better code than the double
> > > byte-swaps that MIPS is getting now.
> 
> The problem here is that regmap already has that functionality (it needs
> it for non-MMIO buses anyway) and so it knows what's going on really
> wants the I/O accessors to get out of the way.

I think we need to at least document the default behavior for
syscon (without changing behavior on ARM), and allow the DT to
specify cpu-endian as an override (or make MIPS default to that,
but that would be rather inconsistent and a pain to document
in the syscon binding).

> > This means that the devices are in fact CPU-endian, and we need
> > some way for Linux to represent this. The patch to
> > drivers/base/regmap/regmap-mmio.c is clearly wrong, as we
> > must never use __raw_*() accessors in an architecture independent
> > driver (for a number of reasons), but we still need a fix for
> > MIPS so it can specify a way to do the double-swap without
> > faking the endianess of the registers.
> 
> I can't identify *anything* which says we shouldn't use the __raw
> accessors in architecture neutral code with the possible exception of
> the __.  Seriously, how is anyone supposed to use this stuff if we have
> hidden assumptions like this?

I thought everyone knew by now.

> > Also, defaulting syscon to "native-endian" when nothing else is
> > specified sounds like a bad idea, but we may already be stuck there
> > with the precedent in existing bindings after 6a55244e897d
> > ("regmap: mmio: request native endian formatting"), we'll have
> > to think about that some more.
> 
> Yeah, the native endian formatting is causing a lot of trouble.  The
> MIPS folks really should also have come and talked to me rather than
> writing such obvious nonsense in the DT in the first place.

They should also have talked to me as the syscon maintainer...

Arnd

Re: [BUG REPORT] Soft Lockup in smp_call_function_single+0xD8

[Jeff Merkey]

On 1/24/16, Jeff Merkey  wrote:
> On 1/24/16, Jeff Merkey  wrote:
>> If I single step with either kgdb, kgdb, or mdb kernel debuggers over
>> a sysret instruction anywhere in the OS,  the system hard hangs in
>> smp_call_function_single after the debugger releases the system and it
>> resumes normal operation.The specific place the kernel hangs is in
>> the loop below.   The softlockup detector will periodically detect
>> this condition when it occurs, but not always, most of the time the
>> system is just hung and unresponsive.
>>
>> (2)> u smp_call_function_single+d8
>>  hard hang in this loop with EDX=3
>> 0x810fce48 8B55E0  movedx,DWORD PTR
>> [rbp-32]=0xCE037DC0
>> 0x810fce4b 83E201  andedx,0x1
>> 0x810fce4e 75F6jne
>> smp_call_function_single+0xd6 (0x810fce46) (up)
>> <
>> 0x810fce50 EBC3jmp
>> smp_call_function_single+0xa5 (0x810fce15) (up)
>> 0x810fce52 8B05E08EC700moveax,[oops_in_progress]=0x0
>> 0x810fce58 85C0test   eax,eax
>> 0x810fce5a 7585jne
>> smp_call_function_single+0x71 (0x810fcde1) (up)
>> 0x810fce5c 803D8E0C9D  cmp[__warned.20610]=0x00,0x0
>> 0x810fce63 0F8578FFjne
>> smp_call_function_single+0x71 (0x810fcde1) (up)
>> 0x810fce69 BE2401  movesi,0x124
>> 0x810fce6e 48C7C796B08C81  movrdi,0x818cb096
>> 0x810fce75 894DBC  movDWORD PTR [rbp-68]=0x0,ecx
>> 0x810fce78 488955C0movQWORD PTR
>> [rbp-64]=0xFF10,rdx
>> 0x810fce7c E8FF21F8FF  call   warn_slowpath_null
>> 0x810fce81 C605690C9D0001  mov[__warned.20610]=0x00,0x1
>> 0x810fce88 8B4DBC  movecx,DWORD PTR [rbp-68]=0x0
>> 0x810fce8b 488B55C0movrdx,QWORD PTR
>> [rbp-64]=0xFF10
>> 0x810fce8f E94DFF  jmp
>> smp_call_function_single+0x71 (0x810fcde1) (up)
>> 0x810fce94 E8A71EF8FF  call   __stack_chk_fail
>> 0x810fce99 0F1F80  nopDWORD PTR [rax]=0x0
>> (2)> g
>>
>>
>> The stack backtrace when the bug occurs is:
>>
>> smp_call_function_single+0xd8
>> unmap_page_range+0x613
>> flush_tlb_func+0x0
>> smp_call_function_many+215
>> native_flush_tlb_others+0x118
>> flush_tlb_mm_range+0x61
>> tlb_flush_mmu_tlbonly+0x6b
>> tlb_finish_mmu+0x14
>> unmap_region+0xe2
>> vma_rb_erase+0x10f
>> do_unmap+0x217
>> vm_unmap+0x41
>> SyS_munmap+0x22
>> entry_SYSCALL_64_fastpath+0x12
>>
>> I traced through this code a bunch of times in just normal operations
>> without triggering the bug to get a feel for what it normally sees in
>> EDX and it looks like someone has coded a looping function that always
>> has EDX=0 in every case I saw in the except for when this bug occurs.
>>
>> So the exact C code this maps fro objdump of kernel/smp.o is:
>>
>>  469:e8 62 fe ff ff  callq  2d0 
>>  46e:8b 55 e0mov-0x20(%rbp),%edx
>>  * previous function call. For multi-cpu calls its even more interesting
>>  * as we'll have to ensure no other cpu is observing our csd.
>>  */
>> static void csd_lock_wait(struct call_single_data *csd)
>> {
>>  while (smp_load_acquire(>flags) & CSD_FLAG_LOCK)
>>  471:83 e2 01and$0x1,%edx
>>  474:74 cf   je 445 
>> 
>>  476:f3 90   pause
>> <<
>>  478:8b 55 e0mov-0x20(%rbp),%edx
>>  47b:83 e2 01and$0x1,%edx
>>  47e:75 f6   jne476 
>> 
>> <<<
>>  480:eb c3   jmp445 
>> 
>>   * Can deadlock when called with interrupts disabled.
>>   * We allow cpu's that are not yet online though, as no one else can
>>   * send smp call function interrupt to this cpu and as such deadlocks
>>   * can't happen.
>>   */
>>  WARN_ON_ONCE(cpu_online(this_cpu) && irqs_disabled()
>>
>> Each time this bug occurs csd->flags is always set to a value of 3 and
>> never changes.  When the system is just running normally, it seems to
>> be 0 the rest of the time.   Setting EDX=0 from the debugger console
>> clears the hang condition and the system seems to recover except the
>> system reports this error from the console when you attempt to load
>> programs, indicating the ability of the system to load shared objects
>> is fritzed.
>>
>> #
>> # ls -l
>> /lib64/libc.so.6 version GLI not found   << this error and no shared
>> objects will load
>> #
>> #
>>
>> Jeff
>>
>
> I am running down a trace of the MSR values for swapgs.  Looks like it
> got nested somewhere down in the entry_64 code.   If so, then this is
> just a symptom and not the sickness.
>
> 

Re: [PATCH 3/3] tty: hvc_xen: hide xen_console_remove when unused

[Boris Ostrovsky]

On 01/25/2016 04:54 PM, Arnd Bergmann wrote:

xencons_disconnect_backend() is only called from xen_console_remove(),


and also from xencons_probe()/xencons_resume(). But those two are also 
under the

same ifdef.

-boris


which is conditionally compiled, so we get a harmless warning when
CONFIG_HVC_XEN_FRONTEND is unset:

hvc/hvc_xen.c:350:12: error: 'xen_console_remove' defined but not used 
[-Werror=unused-function]

This moves the function down into the same #ifdef section to silence
the warning.

Signed-off-by: Arnd Bergmann 
---
  drivers/tty/hvc/hvc_xen.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/tty/hvc/hvc_xen.c b/drivers/tty/hvc/hvc_xen.c
index fa816b7193b6..11725422dacb 100644
--- a/drivers/tty/hvc/hvc_xen.c
+++ b/drivers/tty/hvc/hvc_xen.c
@@ -323,6 +323,7 @@ void xen_console_resume(void)
}
  }
  
+#ifdef CONFIG_HVC_XEN_FRONTEND

  static void xencons_disconnect_backend(struct xencons_info *info)
  {
if (info->irq > 0)
@@ -363,7 +364,6 @@ static int xen_console_remove(struct xencons_info *info)
return 0;
  }
  
-#ifdef CONFIG_HVC_XEN_FRONTEND

  static int xencons_remove(struct xenbus_device *dev)
  {
return xen_console_remove(dev_get_drvdata(>dev));

Re: [PATCH 07/22] fpga: Fix dependencies for !HAS_IOMEM archs

[Moritz Fischer]

On Mon, Jan 25, 2016 at 11:24 PM, Richard Weinberger  wrote:
> Not every arch has io memory.
> So, unbreak the build by fixing the dependencies.
>
> Signed-off-by: Richard Weinberger 

Acked-by: Moritz Fischer 

Re: module: Fix regression introduced by commit: b0d7290e85a5 "module: clean up RO/NX handling."

[Brian Norris]

On Mon, Jan 25, 2016 at 12:11:51PM +0100, Lothar Wassmann wrote:
> commit b0d7290e85a5 ("module: clean up RO/NX handling.")
> threw away the size checks which were in place before calling the
> set_memory_*() functions.
> This produces a kernel bug upon module load with
> CONFIG_DEBUG_SET_MODULE_RONX=y:
> 
> kernel BUG at mm/memory.c:1898!
> Internal error: Oops - BUG: 0 [#1] ARM
> Modules linked in:
> CPU: 0 PID: 825 Comm: modprobe Not tainted 4.4.0-next-20160121+ #53
> Hardware name: Freescale MXS (Device Tree)
> task: cef6c380 ti: ce93a000 task.ti: ce93a000
> PC is at apply_to_page_range+0x190/0x1bc
> LR is at change_memory_common+0x74/0xcc
> pc : []lr : []psr: 6013
> sp : ce93be40  ip : bf011000  fp : bf012000
> r10: bf012000  r9 : bf0091d4  r8 : ce93be80
> r7 :   r6 : bf012000  r5 : 0001  r4 : bf012000
> r3 : c0011d38  r2 :   r1 : bf012000  r0 : c0633458
> Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
> Control: 0005317f  Table: 4ef0c000  DAC: 0051
> Process modprobe (pid: 825, stack limit = 0xce93a190)
> Stack: (0xce93be40 to 0xce93c000)
> be40: c0633458 bf012000  bf012000 0001 bf012000  0080
> be60: bf0091d4 ce93bef4  c0011ce0 ce93be80  bf0071dc bf0091e4
> be80: 0080  bf009100 ce93bf48 0001 bf00910c bf009100 
> bea0: bf0091d4 c005d2a0  cfbd8de0  0014 007fb980 
> bec0: d0a1d01c bf009250 bf00910c  d0a19000 b6e4b000 0f80 755f6f74
> bee0: 5f726573 bf007024 0032 bf0071b4 0006   
> bf00:        
> bf20: c005da70 306c  b6e4f06c d0a1d06c ce93a000 007fb980 0051
> bf40: 007fbbd8 c005dae0 d0a0a000 0001306c d0a1c98c d0a13c07 d0a177c8 a000
> bf60: cbe0    002a 002b 0020 0024
> bf80: 0018  b6f83228 bec859f8  0080 c000a4e4 ce93a000
> bfa0:  c000a340 b6f83228 bec859f8 b6e3c000 0001306c 007fb980 
> bfc0: b6f83228 bec859f8  0080 007fb980 0008  007fbbd8
> bfe0: b6f1fa70 bec856c8 aab4 b6f1fa80 6010 b6e3c000  
> [] (apply_to_page_range) from [] 
> (change_memory_common+0x74/0xcc)
> [] (change_memory_common) from [] 
> (load_module+0x16c8/0x1e3c)
> [] (load_module) from [] (SyS_init_module+0xcc/0x138)
> [] (SyS_init_module) from [] (ret_fast_syscall+0x0/0x38)
> Code: e0834104 eac3 e5191008 eabb (e7f001f2)
> ---[ end trace fbf287e335e94b28 ]---
> 
> This happens because the set_memory_*() functions are eventually being
> called with a zero  parameter and thus apply_to_page_range() in
> mm/memory.c barfs due to:
>   unsigned long end = addr + size;
> ...
>   BUG_ON(addr >= end);

Hit this BUG_ON() on a mt8173 platform with v4.5-rc1.

> Reinstate the size checks, as they were before the offending commit.
> 
> Signed-off-by: Lothar Waßmann 

Gets me back to a prompt, so:

Tested-by: Brian Norris 

> ---
> kernel/module.c | 15 +--
>  1 file changed, 9 insertions(+), 6 deletions(-)
> 
> diff --git a/kernel/module.c b/kernel/module.c
> index 8358f46..40d8e42 100644
> --- a/kernel/module.c
> +++ b/kernel/module.c
> @@ -1863,8 +1863,9 @@ static void frob_text(const struct module_layout 
> *layout,
>  {
>   BUG_ON((unsigned long)layout->base & (PAGE_SIZE-1));
>   BUG_ON((unsigned long)layout->text_size & (PAGE_SIZE-1));
> - set_memory((unsigned long)layout->base,
> -layout->text_size >> PAGE_SHIFT);
> + if (layout->text_size)
> + set_memory((unsigned long)layout->base,
> + layout->text_size >> PAGE_SHIFT);
>  }
>  
>  static void frob_rodata(const struct module_layout *layout,
> @@ -1873,8 +1874,9 @@ static void frob_rodata(const struct module_layout 
> *layout,
>   BUG_ON((unsigned long)layout->base & (PAGE_SIZE-1));
>   BUG_ON((unsigned long)layout->text_size & (PAGE_SIZE-1));
>   BUG_ON((unsigned long)layout->ro_size & (PAGE_SIZE-1));
> - set_memory((unsigned long)layout->base + layout->text_size,
> -(layout->ro_size - layout->text_size) >> PAGE_SHIFT);
> + if (layout->ro_size > layout->text_size)
> + set_memory((unsigned long)layout->base + layout->text_size,
> + (layout->ro_size - layout->text_size) >> PAGE_SHIFT);
>  }
>  
>  static void frob_writable_data(const struct module_layout *layout,
> @@ -1883,8 +1885,9 @@ static void frob_writable_data(const struct 
> module_layout *layout,
>   BUG_ON((unsigned long)layout->base & (PAGE_SIZE-1));
>   BUG_ON((unsigned long)layout->ro_size & (PAGE_SIZE-1));
>   BUG_ON((unsigned long)layout->size & (PAGE_SIZE-1));
> - set_memory((unsigned long)layout->base + layout->ro_size,
> -(layout->size - layout->ro_size) >> PAGE_SHIFT);
> + if 

Re: [PATCH] kernel-doc: add support for asciidoc output

[Jonathan Corbet]

On Mon, 18 Jan 2016 10:41:17 +0200
Jani Nikula  wrote:

> Add new -asciidoc option to produce asciidoc output from kernel-doc. The
> output is formatted internally, with no dependencies on external
> tools. Any asciidoc formatting present in kernel-doc will naturally be
> present in the resulting asciidoc as well.

As you may have seen, I took this and sort of ran with it - thanks!  I'm
not sure I want to merge this functionality without an in-kernel user, but
we're on the way toward having that now.

> I tested this mostly on drm/i915. I had to drop a few totally bogus
> kernel-doc comments for everything to work cleanly, series at
> http://patchwork.freedesktop.org/series/2581/.

Aside from all of this, could I prevail upon you to submit those?  They
are worth having regardless.

Thanks,

jon

[PATCH 1/6] f2fs: speed up shrinking extent_node cache

[Jaegeuk Kim]

This patch speeds up extent_node shrinker by introducing linked list.

Signed-off-by: Jaegeuk Kim 
---
 fs/f2fs/extent_cache.c | 74 ++
 fs/f2fs/f2fs.h |  2 ++
 2 files changed, 35 insertions(+), 41 deletions(-)

diff --git a/fs/f2fs/extent_cache.c b/fs/f2fs/extent_cache.c
index ccd5c63..18311ff 100644
--- a/fs/f2fs/extent_cache.c
+++ b/fs/f2fs/extent_cache.c
@@ -32,7 +32,9 @@ static struct extent_node *__attach_extent_node(struct 
f2fs_sb_info *sbi,
return NULL;
 
en->ei = *ei;
+   en->et = et;
INIT_LIST_HEAD(>list);
+   INIT_LIST_HEAD(>vlist);
 
rb_link_node(>rb_node, parent, p);
rb_insert_color(>rb_node, >root);
@@ -129,7 +131,7 @@ static struct extent_node *__init_extent_tree(struct 
f2fs_sb_info *sbi,
 }
 
 static unsigned int __free_extent_tree(struct f2fs_sb_info *sbi,
-   struct extent_tree *et, bool free_all)
+   struct extent_tree *et)
 {
struct rb_node *node, *next;
struct extent_node *en;
@@ -137,17 +139,19 @@ static unsigned int __free_extent_tree(struct 
f2fs_sb_info *sbi,
 
node = rb_first(>root);
while (node) {
+   bool need_free = false;
+
next = rb_next(node);
en = rb_entry(node, struct extent_node, rb_node);
 
-   if (free_all) {
-   spin_lock(>extent_lock);
-   if (!list_empty(>list))
-   list_del_init(>list);
-   spin_unlock(>extent_lock);
+   spin_lock(>extent_lock);
+   if (!list_empty(>list)) {
+   list_del_init(>list);
+   need_free = true;
}
+   spin_unlock(>extent_lock);
 
-   if (free_all || list_empty(>list)) {
+   if (need_free) {
__detach_extent_node(sbi, et, en);
kmem_cache_free(extent_node_slab, en);
}
@@ -438,6 +442,7 @@ static unsigned int f2fs_update_extent_tree_range(struct 
inode *inode,
while (en && en->ei.fofs < end) {
unsigned int org_end;
int parts = 0;  /* # of parts current extent split into */
+   bool need_free = false;
 
next_en = en1 = NULL;
 
@@ -493,14 +498,16 @@ static unsigned int f2fs_update_extent_tree_range(struct 
inode *inode,
 
/* update in global extent list */
spin_lock(>extent_lock);
-   if (!parts && !list_empty(>list))
+   if (!parts && !list_empty(>list)) {
list_del(>list);
+   need_free = true;
+   }
if (en1)
list_add_tail(>list, >extent_list);
spin_unlock(>extent_lock);
 
/* release extent node */
-   if (!parts)
+   if (!parts && need_free)
kmem_cache_free(extent_node_slab, en);
 
en = next_en;
@@ -509,6 +516,7 @@ static unsigned int f2fs_update_extent_tree_range(struct 
inode *inode,
/* 3. update extent in extent cache */
if (blkaddr) {
struct extent_node *den = NULL;
+   bool need_free = false;
 
set_extent_info(, fofs, blkaddr, len);
en1 = __try_merge_extent_node(sbi, et, , ,
@@ -532,16 +540,18 @@ static unsigned int f2fs_update_extent_tree_range(struct 
inode *inode,
else
list_move_tail(>list, >extent_list);
}
-   if (den && !list_empty(>list))
+   if (den && !list_empty(>list)) {
list_del(>list);
+   need_free = true;
+   }
spin_unlock(>extent_lock);
 
-   if (den)
+   if (den && need_free)
kmem_cache_free(extent_node_slab, den);
}
 
if (is_inode_flag_set(F2FS_I(inode), FI_NO_EXTENT))
-   __free_extent_tree(sbi, et, true);
+   __free_extent_tree(sbi, et);
 
write_unlock(>lock);
 
@@ -550,14 +560,12 @@ static unsigned int f2fs_update_extent_tree_range(struct 
inode *inode,
 
 unsigned int f2fs_shrink_extent_tree(struct f2fs_sb_info *sbi, int nr_shrink)
 {
-   struct extent_tree *treevec[EXT_TREE_VEC_SIZE];
struct extent_tree *et, *next;
struct extent_node *en, *tmp;
-   unsigned long ino = F2FS_ROOT_INO(sbi);
-   unsigned int found;
unsigned int node_cnt = 0, tree_cnt = 0;
int remained;
bool do_free = false;
+   LIST_HEAD(victim_list);
 
if (!test_opt(sbi, EXTENT_CACHE))
return 0;
@@ -572,7 +580,7 @@ unsigned int f2fs_shrink_extent_tree(struct f2fs_sb_info 
*sbi, 

Re: linux-4.4 bisected: kwin5 stuck on kde5 loading screen with radeon

[Daniel Vetter]

On Mon, Jan 25, 2016 at 10:42 PM, Mario Kleiner
 wrote:
>>
>>> Now the patch i want to try next to fix the drm_vblank_pre/post_modeset
>>> regression in Linux 4.4/4.5 is to add a ...
>>>
>>> if ((diff > 1) && vblank->inmodeset) diff = 1;
>>>
>>> ... to the bottom of drm_update_vblank_count(). That should hopefully
>>> restore the pre/post_modeset behavior as close to the original behavior
>>> as
>>> possible. As a side effect it would also prevent the counter jump caused
>>> by
>>> redundant calls to drm_vblank_off().
>>
>>
>> Hm, can we just frob pre/post_modeset only with some checks? I'd like to
>> not put that kind of "I have no idea about my hw state" hacks into the new
>> helpers. Otherwise not even atomic drivers can start to gain WARN_ONs to
>> enforce correct usage, which would be a real bummer imo.
>> -Daniel
>>
>
> We could check for only (vblank->inmodeset & 0x2) to only apply it to the
> legacy pre/post path, trusting that the drm_vblank_off/on path will be made
> robust in a different way, e.g., by the stuff discussed above and careful
> implementation in each kms driver that uses those. Atm. radeon doesn't use
> off/on, so your enablement patch set can make sure it does the right thing
> from the beginning.
>
> rockchip-kms may need similar treatment to radeon to avoid redundant calls.
>
> Btw. how the patch to drm_update_vblank_count() close to the bottom would
> actually look is more like:
>
> if ((diff > 1) &&
> ((vblank->inmodeset & 0x2) || (flags & DRM_CALLED_FROM_VBLIRQ)))
>  diff = 1;

Yeah I think that should work as a short-term fix for radoen. When you
do that, can you pls do a second patch to give the magic 0x2 and 0x1
some meaning? Otherwise this is super-hard to understand code ...
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Re: [RFC PATCH] codingstyle: improve elisp for a better experience

[Geyslan G. Bem]

2016-01-25 17:01 GMT-03:00 Jonathan Corbet :
> On Thu, 21 Jan 2016 22:18:30 -0300
> "Geyslan G. Bem"  wrote:
>
>> This patch does use of more emacs functionalities which deliver to the
>> user indentation, commenting and white space highlighting.
>
> So perhaps it's just me, but that's an awful lot of elisp code for readers
> to wade through; many of those readers will not be all that interested in
> it.
>
> Can I suggest an alternative?  Make a kernel-dot-emacs.txt in a form that
> interested people can pull it (nearly) directly into their .emacs files,
> then add a reference to the CodingStyle document.  That makes the stuff
> available for interested developers without rubbing everybody's noses in
> it.  Make sense?

Yes, you have a point. I could make the kernel-dot-emacs.txt. Thank
you Jonathan.

About the elisp, the emacs users have any suggestions?
>
> Thanks,
>
> jon



-- 
Regards,

Geyslan G. Bem
hackingbits.com

Re: N900 sleep mode (in 4.5-rc0, if that matters)

[Pavel Machek]

Hi!

First, thanks for the help!

> > So far, the LEDs stubbornly stay on :-(. Machine is booted off
> > sd-card, and I'm connected to it over wifi. GSM is active, X is
> > running.
> 
> If LEDs stay on, you're not entering deeper idle states.

Yes... Strange thing is, I'm not entering deeper idle states, and it still 
breaks my wifi ;-).

> > 64 bytes from 192.168.43.15: icmp_seq=427 ttl=64 time=178 ms
> 
> Latencies of several hundred ms are expected when hitting off
> mode during idle as the latency for power off the system during
> idle is long. It could also be that there's a wakeirq config
> missing somewhere. Does the WLAN have a separate GPIO irq?

Fair enough.

wl1251_pins: pinmux_wl1251 {
   pinctrl-single,pins = < 0x0ce (PIN_OUTPUT | 
MUX_MODE4)
   /* gpio 87 => w\ l1251 enable */
   0x05a (PIN_INPUT | 
MUX_MODE4)
   /* gpio 42 => w\ l1251 irq */
   >;
 };

Aha. wl1251 is on the spi bus, too.

 {
pinctrl-names = "default";
pinctrl-0 = <_pins>;

wl1251@0 {
...
interrupt-parent = <>;
interrupts = <10 IRQ_TYPE_NONE>; /* 
gpio line 42 */
};

And yes, it has a GPIO irq -- irq 42. What should be configured to
make gpio 42 wake the system from deep idle?

> > and touchscreen stops working:
> > 
> > [99480.564910] tsc2005 spi1.0: TSC200X not responding - resetting
...
> This could be because we're still lacking i2c-omap + pinctrl
> handling for erratum 1.158. Without that, any GPIO pins not in
> GPIO bank 1 used for enabling devices may have glitches during
> off-mode.
> 
> The workaround for now is to mux those pins permanently with
> PIN_INPUT_PULLUP | MUX_MODE7 to keep them high using the
> internal pull. So in this case, maybe give a try for adding
> a pinctrl entry for tsc2005 for gpio104 to have it always
> in PIN_INPUT_PULLUP | MUX_MODE7.

So the glitches on the GPIOs reset the tsc2005, even when it should be
operational? That would explain stuff.

I'll try to figure out the pinmux stuff. ... but I guess touchscreen
is not really usable with screen off.

> The long term solution is to do this dynamically for each GPIO
> pin.. I do have some WIP patches for that but those still need
> work before I dare to post them.

No patch is too ugly for testing :-).

> Yes you can dump the idlest regs during idle and see the blockers.
> Below is a hack patch I've been using, that could potentially
> be turned into something we could actually merge. Needs to have
> separate hooks for various SoCs though, this works only on omap3..

Thanks, wil try.

> > Power consumption seems to be in 500mA range, regardless of
> > off_mode. That would mean about 2 hours of battery life, AFAICT.
> 
> Sounds like you have USB connected and charging? You can
> get into just few mW range with the mainline kernel for sure
> on omap3. It's just a quetion of fixing whatever few drivers
> that are still causing issues on n900.
> 
> Typically you need at least USB disconnected and LCD blanked
> to start hitting the deeper idle states :)

Right. So I was able to get SD-card to work, so USB was disconnected,
but I was watching power consumption figures in a GTK window... on a
LCD. Ok. I guess I can monitor the power consumption over the wlan.

Thanks!
Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[PATCH 09/22] leds: Fix dependencies for !HAS_IOMEM archs

[Richard Weinberger]

Not every arch has io memory.
So, unbreak the build by fixing the dependencies.

Signed-off-by: Richard Weinberger 
---
 drivers/leds/Kconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 7f940c2..e76a45c 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -54,6 +54,7 @@ config LEDS_BCM6328
depends on LEDS_CLASS
depends on HAS_IOMEM
depends on OF
+   depends on HAS_IOMEM
help
  This option enables support for LEDs connected to the BCM6328
  LED HW controller accessed via MMIO registers.
@@ -63,6 +64,7 @@ config LEDS_BCM6358
depends on LEDS_CLASS
depends on HAS_IOMEM
depends on OF
+   depends on HAS_IOMEM
help
  This option enables support for LEDs connected to the BCM6358
  LED HW controller accessed via MMIO registers.
-- 
1.8.4.5

[PATCH 06/22] iio: adc: Fix dependencies for !HAS_IOMEM archs

[Richard Weinberger]

Not every arch has io memory.
So, unbreak the build by fixing the dependencies.

Signed-off-by: Richard Weinberger 
---
 drivers/iio/adc/Kconfig | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index 605ff42..283ded7 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -175,6 +175,7 @@ config DA9150_GPADC
 config EXYNOS_ADC
tristate "Exynos ADC driver support"
depends on ARCH_EXYNOS || ARCH_S3C24XX || ARCH_S3C64XX || (OF && 
COMPILE_TEST)
+   depends on HAS_IOMEM
help
  Core support for the ADC block found in the Samsung EXYNOS series
  of SoCs for drivers such as the touchscreen and hwmon to use to share
@@ -207,6 +208,7 @@ config INA2XX_ADC
 config IMX7D_ADC
tristate "IMX7D ADC driver"
depends on ARCH_MXC || COMPILE_TEST
+   depends on HAS_IOMEM
help
  Say yes here to build support for IMX7D ADC.
 
@@ -409,6 +411,7 @@ config TWL6030_GPADC
 config VF610_ADC
tristate "Freescale vf610 ADC driver"
depends on OF
+   depends on HAS_IOMEM
select IIO_BUFFER
select IIO_TRIGGERED_BUFFER
help
-- 
1.8.4.5

[PATCH 10/22] mailbox: Fix dependencies for !HAS_IOMEM archs

[Richard Weinberger]

Not every arch has io memory.
So, unbreak the build by fixing the dependencies.

Signed-off-by: Richard Weinberger 
---
 drivers/mailbox/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
index 546d05f..b2bbe86 100644
--- a/drivers/mailbox/Kconfig
+++ b/drivers/mailbox/Kconfig
@@ -81,6 +81,7 @@ config STI_MBOX
 config MAILBOX_TEST
tristate "Mailbox Test Client"
depends on OF
+   depends on HAS_IOMEM
help
  Test client to help with testing new Controller driver
  implementations.
-- 
1.8.4.5

[PATCH 03/22] scsi: Fix dependencies for !HAS_IOMEM and !HAS_DMA archs

[Richard Weinberger]

Not every arch has io or DMA memory.
So, unbreak the build by fixing the dependencies.

Signed-off-by: Richard Weinberger 
---
 drivers/scsi/hisi_sas/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/scsi/hisi_sas/Kconfig b/drivers/scsi/hisi_sas/Kconfig
index 37a0c71..f9157f4 100644
--- a/drivers/scsi/hisi_sas/Kconfig
+++ b/drivers/scsi/hisi_sas/Kconfig
@@ -2,5 +2,6 @@ config SCSI_HISI_SAS
tristate "HiSilicon SAS"
select SCSI_SAS_LIBSAS
select BLK_DEV_INTEGRITY
+   depends on HAS_IOMEM && HAS_DMA
help
This driver supports HiSilicon's SAS HBA
-- 
1.8.4.5

[PATCH 04/22] staging: iio: Fix dependencies for !HAS_IOMEM archs

[Richard Weinberger]

Not every arch has io memory.
So, unbreak the build by fixing the dependencies.

Signed-off-by: Richard Weinberger 
---
 drivers/staging/iio/adc/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/staging/iio/adc/Kconfig b/drivers/staging/iio/adc/Kconfig
index 58d4517..b9519be 100644
--- a/drivers/staging/iio/adc/Kconfig
+++ b/drivers/staging/iio/adc/Kconfig
@@ -6,6 +6,7 @@ menu "Analog to digital converters"
 config AD7606
tristate "Analog Devices AD7606 ADC driver"
depends on GPIOLIB || COMPILE_TEST
+   depends on HAS_IOMEM
select IIO_BUFFER
select IIO_TRIGGERED_BUFFER
help
-- 
1.8.4.5

[PATCH 01/22] power: reset: Fix dependencies for !HAS_IOMEM archs

[Richard Weinberger]

Not every arch has io memory.
So, unbreak the build by fixing the dependencies.

Signed-off-by: Richard Weinberger 
---
 drivers/power/reset/Kconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig
index 1131cf7..0a6408a 100644
--- a/drivers/power/reset/Kconfig
+++ b/drivers/power/reset/Kconfig
@@ -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.
-- 
1.8.4.5

[no subject]

[Richard Weinberger]

Last few months I was very busy and now I have the mess,
UML allmod/yesconfig does not build at all.
This large and boring patch series fixes a lot of drivers which
cannot work/build on UML.
Fixes are grouped by subsystem such that maintainers can review/pickup them.

Thanks,
//richard

[PATCH 01/22] power: reset: Fix dependencies for !HAS_IOMEM archs
[PATCH 02/22] phy: Fix dependencies for !HAS_IOMEM archs
[PATCH 03/22] scsi: Fix dependencies for !HAS_IOMEM and !HAS_DMA
[PATCH 04/22] staging: iio: Fix dependencies for !HAS_IOMEM archs
[PATCH 05/22] hw_random: Fix dependencies for !HAS_IOMEM archs
[PATCH 06/22] iio: adc: Fix dependencies for !HAS_IOMEM archs
[PATCH 07/22] fpga: Fix dependencies for !HAS_IOMEM archs
[PATCH 08/22] hwtracing: Fix dependencies for !HAS_IOMEM archs
[PATCH 09/22] leds: Fix dependencies for !HAS_IOMEM archs
[PATCH 10/22] mailbox: Fix dependencies for !HAS_IOMEM archs
[PATCH 11/22] mtd: Fix dependencies for !HAS_IOMEM archs
[PATCH 12/22] nvmem: Fix dependencies for !HAS_IOMEM archs
[PATCH 13/22] net: Fix dependencies for !HAS_IOMEM archs
[PATCH 14/22] pwm: Fix dependencies for !HAS_IOMEM archs
[PATCH 15/22] watchdog: Fix dependencies for !HAS_IOMEM archs
[PATCH 16/22] iio: imu: Fix dependencies for !HAS_IOMEM archs
[PATCH 17/22] media: Fix dependencies for !HAS_IOMEM archs
[PATCH 18/22] irqchip: Fix dependencies for !HAS_IOMEM archs
[PATCH 19/22] thermal: Fix dependencies for !HAS_IOMEM archs
[PATCH 20/22] clocksource: Fix dependencies for !HAS_IOMEM archs
[PATCH 21/22] mtd: cs553x: Fix dependencies for !HAS_IOMEM archs
[PATCH 22/22] um: Export pm_power_off

[PATCH 07/22] fpga: Fix dependencies for !HAS_IOMEM archs

[Richard Weinberger]

Not every arch has io memory.
So, unbreak the build by fixing the dependencies.

Signed-off-by: Richard Weinberger 
---
 drivers/fpga/Kconfig | 1 +
 1 file changed, 1 insertion(+)

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.
 
-- 
1.8.4.5

Re: [PATCH 09/22] leds: Fix dependencies for !HAS_IOMEM archs

[Richard Weinberger]

Am 25.01.2016 um 23:24 schrieb Richard Weinberger:
> Not every arch has io memory.
> So, unbreak the build by fixing the dependencies.
> 
> Signed-off-by: Richard Weinberger 
> ---
>  drivers/leds/Kconfig | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
> index 7f940c2..e76a45c 100644
> --- a/drivers/leds/Kconfig
> +++ b/drivers/leds/Kconfig
> @@ -54,6 +54,7 @@ config LEDS_BCM6328
>   depends on LEDS_CLASS
>   depends on HAS_IOMEM
>   depends on OF
> + depends on HAS_IOMEM
>   help
> This option enables support for LEDs connected to the BCM6328
> LED HW controller accessed via MMIO registers.
> @@ -63,6 +64,7 @@ config LEDS_BCM6358
>   depends on LEDS_CLASS
>   depends on HAS_IOMEM
>   depends on OF
> + depends on HAS_IOMEM

Please drop this patch too.
Did not notice that this was fixed already.

Thanks,
//richard

Re: [PATCH] Revert "regmap-mmio: Use native endianness for read/write"

[Mark Brown]

On Mon, Jan 25, 2016 at 11:24:44PM +0100, Arnd Bergmann wrote:
> On Monday 25 January 2016 23:07:55 Johannes Berg wrote:
> > This reverts commit 29bb45f25ff3051354ed330c0d0f10418a2b8c7c.
> > 
> > Clearly, using "native" endianness is a terrible idea when
> > devices are involved, since those devices are different hw

Please send patches to maintainers and please use subject lines
reflecting the style for the subsystem.

> > Consequently, this commit broke my HummingBoard i.MX6 in big
> > endian mode since it would now try to talk to the little
> > endian hardware with a big endian CPU without conversion.

What I'd expect to be happening here is that either the driver or the
DT should be specifying the endianness of the hardware.  If the device
is always a given endianness then I'd expect that to turn up in the
driver rather than the DT.

> > What the patch really would have to do is introduce some kind
> > of "device-endian" readl/writel, that takes the endianness of
> > the device as an argument. That seems a bit overkill though,
> > and would likely not generate any better code than the double
> > byte-swaps that MIPS is getting now.

The problem here is that regmap already has that functionality (it needs
it for non-MMIO buses anyway) and so it knows what's going on really
wants the I/O accessors to get out of the way.

> This means that the devices are in fact CPU-endian, and we need
> some way for Linux to represent this. The patch to
> drivers/base/regmap/regmap-mmio.c is clearly wrong, as we
> must never use __raw_*() accessors in an architecture independent
> driver (for a number of reasons), but we still need a fix for
> MIPS so it can specify a way to do the double-swap without
> faking the endianess of the registers.

I can't identify *anything* which says we shouldn't use the __raw
accessors in architecture neutral code with the possible exception of
the __.  Seriously, how is anyone supposed to use this stuff if we have
hidden assumptions like this?

> Also, defaulting syscon to "native-endian" when nothing else is
> specified sounds like a bad idea, but we may already be stuck there
> with the precedent in existing bindings after 6a55244e897d
> ("regmap: mmio: request native endian formatting"), we'll have
> to think about that some more.

Yeah, the native endian formatting is causing a lot of trouble.  The
MIPS folks really should also have come and talked to me rather than
writing such obvious nonsense in the DT in the first place.


signature.asc
Description: PGP signature

[PATCH 1/1] [V2] irqchip: gicv3-its: Introduce indirect device-ITT table support

[Shanker Donthineni]

Current ITS driver implementation limits the device ID to a few
number of bits depending on memory that has been allocated to a
flat DEV-ITT table. Some of the devices are not usable when device
ID is spread out across a large range of 32 bit values.

This patch covers more DEVID bits by implementing the GIC-ITS indirect
device table. This feature is enabled automatically during driver
probe if the flat table is not adequate to hold all DEVID bits.

Signed-off-by: Shanker Donthineni 
---
[v1]->[v2]:
  -Removed the line "Change-Id: I9c6d005dexxx" from commit message.
  -Fixed the its->max_devid field initialization. 

 drivers/irqchip/irq-gic-v3-its.c   | 79 +++---
 include/linux/irqchip/arm-gic-v3.h |  1 +
 2 files changed, 75 insertions(+), 5 deletions(-)

diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index e23d1d1..408a358 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -41,6 +41,8 @@
 
 #define ITS_FLAGS_CMDQ_NEEDS_FLUSHING  (1ULL << 0)
 #define ITS_FLAGS_WORKAROUND_CAVIUM_22375  (1ULL << 1)
+#define ITS_FLAGS_DEVICE_NEEDS_FLUSHING(1ULL << 2)
+#define ITS_FLAGS_INDIRECT_DEVICE_TABLE(1ULL << 3)
 
 #define RDIST_FLAGS_PROPBASE_NEEDS_FLUSHING(1 << 0)
 
@@ -71,6 +73,10 @@ struct its_node {
struct list_headits_device_list;
u64 flags;
u32 ite_size;
+   u32 dev_table_idx;
+   u32 dev_table_shift;
+   u32 max_devid;
+   u32 order;
 };
 
 #define ITS_ITT_ALIGN  SZ_256
@@ -824,6 +830,8 @@ static int its_alloc_tables(const char *node_name, struct 
its_node *its)
u64 typer;
u32 ids;
 
+#define ITS_DEVICE_MAX_ORDER   min(MAX_ORDER, get_order(SZ_8M))
+
if (its->flags & ITS_FLAGS_WORKAROUND_CAVIUM_22375) {
/*
 * erratum 22375: only alloc 8MB table size
@@ -867,11 +875,12 @@ static int its_alloc_tables(const char *node_name, struct 
its_node *its)
 */
order = max(get_order((1UL << ids) * entry_size),
order);
-   if (order >= MAX_ORDER) {
-   order = MAX_ORDER - 1;
-   pr_warn("%s: Device Table too large, reduce its 
page order to %u\n",
-   node_name, order);
-   }
+   if (order >= ITS_DEVICE_MAX_ORDER) {
+   /* Update flags for two-level setup */
+   its->flags |= ITS_FLAGS_INDIRECT_DEVICE_TABLE;
+   order = ITS_DEVICE_MAX_ORDER - 1;
+   } else
+   its->max_devid =  (1 << ids) - 1;
}
 
alloc_size = (1 << order) * PAGE_SIZE;
@@ -911,6 +920,26 @@ retry_baser:
break;
}
 
+   /* Enable two-level (indirect) device table if it is required */
+   if ((type == GITS_BASER_TYPE_DEVICE) &&
+   (its->flags & ITS_FLAGS_INDIRECT_DEVICE_TABLE)) {
+   u32 shift = ilog2(psz / entry_size);
+   u32 max_ids = ilog2(alloc_size >> 3) + shift;
+
+   if (ids > max_ids) {
+   pr_warn(
+   "ITS: @%pa DEVID too large reduce 
%u->%u\n",
+   >phys_base, ids, max_ids);
+   }
+   its->max_devid =  (1UL << max_ids) - 1;
+   its->order = get_order(psz);
+   its->dev_table_idx = i;
+   its->dev_table_shift = shift;
+   if (!(val & GITS_BASER_SHAREABILITY_MASK))
+   its->flags |= ITS_FLAGS_DEVICE_NEEDS_FLUSHING;
+   val |= GITS_BASER_INDIRECT;
+   }
+
val |= alloc_pages - 1;
 
writeq_relaxed(val, its->base + GITS_BASER + i * 8);
@@ -1134,6 +1163,32 @@ static struct its_device *its_find_device(struct 
its_node *its, u32 dev_id)
return its_dev;
 }
 
+static int its_alloc_device_table(struct its_node *its, u32 dev_id)
+{
+   u64 *devtbl = its->tables[its->dev_table_idx];
+   u32 alloc_size = (1 << its->order) * PAGE_SIZE;
+   u32 idx = dev_id >> its->dev_table_shift;
+   struct page *page;
+
+   /* Do nothing if the level-2 DEV-ITT entry was mapped earlier */
+   if (devtbl[idx])
+   return 0;
+
+   /* Allocate memory for level-2 device table & map to level-1 table */
+   page = alloc_pages(GFP_KERNEL | __GFP_ZERO, its->order);
+   if (!page)
+   

[PATCH 3/4] Docs: Makefile tweaks for asciidoc templates

[Jonathan Corbet]

This is a hatchet job, but it's something to start with.  Generalize some
of the string manipulation to not assume that templates have a ".tmpl"
suffix, and add rules to translate asciidoc templates to HTML.  Nothing for
any other output formats at this point.

Signed-off-by: Jonathan Corbet 
---
 Documentation/DocBook/Makefile | 72 +-
 1 file changed, 43 insertions(+), 29 deletions(-)

diff --git a/Documentation/DocBook/Makefile b/Documentation/DocBook/Makefile
index d70f9b6..f04e8c8 100644
--- a/Documentation/DocBook/Makefile
+++ b/Documentation/DocBook/Makefile
@@ -6,16 +6,16 @@
 # To add a new book the only step required is to add the book to the
 # list of DOCBOOKS.
 
-DOCBOOKS := z8530book.xml device-drivers.xml \
-   kernel-hacking.xml kernel-locking.xml deviceiobook.xml \
-   writing_usb_driver.xml networking.xml \
-   kernel-api.xml filesystems.xml lsm.xml usb.xml kgdb.xml \
-   gadget.xml libata.xml mtdnand.xml librs.xml rapidio.xml \
-   genericirq.xml s390-drivers.xml uio-howto.xml scsi.xml \
-   80211.xml debugobjects.xml sh.xml regulator.xml \
-   alsa-driver-api.xml writing-an-alsa-driver.xml \
-   tracepoint.xml gpu.xml media_api.xml w1.xml \
-   writing_musb_glue_layer.xml crypto-API.xml iio.xml
+DOCBOOKS := z8530book device-drivers \
+   kernel-hacking kernel-locking deviceiobook \
+   writing_usb_driver networking \
+   kernel-api filesystems lsm usb kgdb \
+   gadget libata mtdnand librs rapidio \
+   genericirq s390-drivers uio-howto scsi \
+   80211 debugobjects sh regulator \
+   alsa-driver-api writing-an-alsa-driver \
+   tracepoint gpu media_api w1 \
+   writing_musb_glue_layer crypto-API iio
 
 include Documentation/DocBook/media/Makefile
 
@@ -39,21 +39,21 @@ PHONY += xmldocs sgmldocs psdocs pdfdocs htmldocs mandocs 
installmandocs cleando
 
 targets += $(DOCBOOKS)
 BOOKS := $(addprefix $(obj)/,$(DOCBOOKS))
-xmldocs: $(BOOKS)
+xmldocs: $(addsuffix .xml, $(BOOKS))
 sgmldocs: xmldocs
 
-PS := $(patsubst %.xml, %.ps, $(BOOKS))
+PS := $(addsuffix .ps, $(BOOKS))
 psdocs: $(PS)
 
-PDF := $(patsubst %.xml, %.pdf, $(BOOKS))
+PDF := $(addsuffix .pdf, $(BOOKS))
 pdfdocs: $(PDF)
 
-HTML := $(sort $(patsubst %.xml, %.html, $(BOOKS)))
+HTML := $(sort $(addsuffix .html, $(BOOKS)))
 htmldocs: $(HTML)
$(call cmd,build_main_index)
$(call install_media_images)
 
-MAN := $(patsubst %.xml, %.9, $(BOOKS))
+MAN := $(addsuffix .9, $(BOOKS))
 mandocs: $(MAN)
find $(obj)/man -name '*.9' | xargs gzip -nf
 
@@ -103,6 +103,19 @@ endef
 # Tell kbuild to always build the programs
 always := $(hostprogs-y)
 
+#
+# asciidoc stuff.
+#
+quiet_cmd_ad2html = ASCIIDOC   $@
+  cmd_ad2html = asciidoc -b html $< > $@
+
+%.ad: %.adt $(KERNELDOC) $(DOCPROC) FORCE
+   $(call cmd,docproc)
+
+%.html: %.ad
+   $(call cmd,ad2html)
+
+
 notfoundtemplate = echo "*** You have to install docbook-utils or xmlto ***"; \
   exit 1
 db2xtemplate = db2TYPE -o $(dir $@) $<
@@ -234,22 +247,23 @@ dochelp:
 
 ###
 # Temporary files left by various tools
-clean-files := $(DOCBOOKS) \
-   $(patsubst %.xml, %.dvi, $(DOCBOOKS)) \
-   $(patsubst %.xml, %.aux, $(DOCBOOKS)) \
-   $(patsubst %.xml, %.tex, $(DOCBOOKS)) \
-   $(patsubst %.xml, %.log, $(DOCBOOKS)) \
-   $(patsubst %.xml, %.out, $(DOCBOOKS)) \
-   $(patsubst %.xml, %.ps,  $(DOCBOOKS)) \
-   $(patsubst %.xml, %.pdf, $(DOCBOOKS)) \
-   $(patsubst %.xml, %.html,$(DOCBOOKS)) \
-   $(patsubst %.xml, %.9,   $(DOCBOOKS)) \
-   $(patsubst %.xml, %.aux.xml, $(DOCBOOKS)) \
-   $(patsubst %.xml, %.xml.db,  $(DOCBOOKS)) \
-   $(patsubst %.xml, %.xml, $(DOCBOOKS)) \
+clean-files := \
+   $(addsuffix .dvi, $(DOCBOOKS)) \
+   $(addsuffix .aux, $(DOCBOOKS)) \
+   $(addsuffix .tex, $(DOCBOOKS)) \
+   $(addsuffix .log, $(DOCBOOKS)) \
+   $(addsuffix .out, $(DOCBOOKS)) \
+   $(addsuffix .ps,  $(DOCBOOKS)) \
+   $(addsuffix .pdf, $(DOCBOOKS)) \
+   $(addsuffix .html,$(DOCBOOKS)) \
+   $(addsuffix .9,   $(DOCBOOKS)) \
+   $(addsuffix .aux.xml, $(DOCBOOKS)) \
+   $(addsuffix .xml.db,  $(DOCBOOKS)) \
+   $(addsuffix .xml, $(DOCBOOKS)) \
+   $(addsuffix .ad,  $(DOCBOOKS)) \
$(index)
 
-clean-dirs := $(patsubst %.xml,%,$(DOCBOOKS)) man
+clean-dirs := $(DOCBOOKS) man
 
 cleandocs: cleanmediadocs
$(Q)rm -f $(call objectify, $(clean-files))
-- 
2.7.0

[PATCH 4/4] Docs: add a sample asciidoc template

[Jonathan Corbet]

This is just a copy of tracepoints.tmpl (because it was short!) converted
into asciidoc.

Signed-off-by: Jonathan Corbet 
---
 Documentation/DocBook/Makefile   |  2 +-
 Documentation/DocBook/tpoint.adt | 64 
 2 files changed, 65 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/DocBook/tpoint.adt

diff --git a/Documentation/DocBook/Makefile b/Documentation/DocBook/Makefile
index f04e8c8..2e5195e 100644
--- a/Documentation/DocBook/Makefile
+++ b/Documentation/DocBook/Makefile
@@ -15,7 +15,7 @@ DOCBOOKS := z8530book device-drivers \
80211 debugobjects sh regulator \
alsa-driver-api writing-an-alsa-driver \
tracepoint gpu media_api w1 \
-   writing_musb_glue_layer crypto-API iio
+   writing_musb_glue_layer crypto-API iio tpoint
 
 include Documentation/DocBook/media/Makefile
 
diff --git a/Documentation/DocBook/tpoint.adt b/Documentation/DocBook/tpoint.adt
new file mode 100644
index 000..f93863a
--- /dev/null
+++ b/Documentation/DocBook/tpoint.adt
@@ -0,0 +1,64 @@
+The Linux Kernel Tracepoint API
+===
+Jason Baron, William Cohen
+
+.This document
+
+This documentation is free software; you can redistribute
+it and/or modify it under the terms of the GNU General Public
+License as published by the Free Software Foundation; either
+version 2 of the License, or (at your option) any later
+version.
+
+This program is distributed in the hope that it will be
+useful, but WITHOUT ANY WARRANTY; without even the implied
+warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+See the GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public
+License along with this program; if not, write to the Free
+Software Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+MA 02111-1307 USA
+
+For more details see the file COPYING in the source
+distribution of Linux.
+
+
+Introduction
+
+
+Tracepoints are static probe points that are located in strategic points
+throughout the kernel. 'Probes' register/unregister with tracepoints
+via a callback mechanism. The 'probes' are strictly typed functions that
+are passed a unique set of parameters defined by each tracepoint.
+
+From this simple callback mechanism, 'probes' can be used to profile, debug,
+and understand kernel behavior. There are a number of tools that provide a
+framework for using 'probes'. These tools include Systemtap, ftrace, and
+LTTng.
+
+Tracepoints are defined in a number of header files via various macros. Thus,
+the purpose of this document is to provide a clear accounting of the available
+tracepoints. The intention is to understand not only what tracepoints are
+available but also to understand where future tracepoints might be added.
+
+The API presented has functions of the form:
++trace_tracepointname(function parameters)+. These are the
+tracepoints callbacks that are found throughout the code. Registering and
+unregistering probes with these callback sites is covered in the
+'Documentation/trace/*' directory.
+
+IRQ
+---
+!Iinclude/trace/events/irq.h
+
+SIGNAL
+--
+!Iinclude/trace/events/signal.h
+
+Block IO
+!Iinclude/trace/events/block.h
+
+Workqueue
+-
+!Iinclude/trace/events/workqueue.h
-- 
2.7.0

[RFC] A first shot at asciidoc-based formatted docs

[Jonathan Corbet]

So here is a proof-of-concept series showing how a fully asciidoc-based
toolchain might work.  Lots of hackery here, this isn't meant to be applied
to anything at this point, but it's a good start.  What this series has is:

 - Jani Nikula's patch adding asciidoc output to kernel-doc.  Thanks for
   doing this!  It was the kickstart that was needed to get this process
   going.

 - Tweak docproc to handle asciidoc template files.  If a template ends in
   ".adt", it's an asciidoc template; it's processed pretty much the same
   way, except that kernel-doc gets the -asciidoc argument.

 - Bash on the Makefile to get it to process asciidoc templates into HTML.
   Naturally this was where most of the time got spent.  *Only* HTML output
   works at the moment.

 - Convert tracepoints.html to tpoint.adt as a proof of concept.  It works,
   and the output is much pleasing, IMO.

I'm sure there's a thousand details to deal with, and there is the issue of
the other output formats.  asciidoctor claims to be able to create man
pages, but I've not tried that yet; neither tool will do PDF.  Maybe we
could rely on pandoc to do that.  Otherwise, getting to asciidoc to XML is
straightforward, so it should be possible to use xmlto as is done now.

It's all in the doc/asciidoc branch of git://git.lwn.net/linux.git if
anybody wants to mess with it.

Comments?

jon

Re: [PATCH] brcmfmac: sdio: Increase the default timeouts a bit

[Julian Calaby]

Hi Arend,

On Tue, Jan 26, 2016 at 2:39 AM, Arend van Spriel  wrote:
> On 25-01-16 12:06, Julian Calaby wrote:
>> Hi Sjoerd,
>>
>> On Mon, Jan 25, 2016 at 9:47 PM, Sjoerd Simons
>>  wrote:
>>> On a Radxa Rock2 board with a Ampak AP6335 (Broadcom 4339 core) it seems
>>> the card responds very quickly most of the time, unfortunately during
>>> initialisation it sometimes seems to take just a bit over 2 seconds to
>>> respond.
>>>
>>> This results intialization failing with message like:
>>>   brcmf_c_preinit_dcmds: Retreiving cur_etheraddr failed, -52
>>>   brcmf_bus_start: failed: -52
>>>   brcmf_sdio_firmware_callback: dongle is not responding
>>>
>>> Increasing the timeout to allow for a bit more headroom allows the
>>> card to initialize reliably.
>>>
>>> A quick search online after diagnosing/fixing this showed that Google
>>> has a similar patch in their ChromeOS tree, so this doesn't seem
>>> specific to the board I'm using.
>>>
>>> Signed-off-by: Sjoerd Simons 
>>
>> Looks sane to me.
>>
>> Reviewed-by: Julian Calaby 
>
> Not really a cleanup patch :-p , but thanks for the review.

I'm trying to review any "small" patch from (relatively) new people.

Thanks,

-- 
Julian Calaby

Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/

Re: [PATCH v2 0/3] x86/mm: INVPCID support

[Ingo Molnar]

* Andy Lutomirski  wrote:

> Ingo, before applying this, please apply these two KASAN fixes:
> 
> http://lkml.kernel.org/g/1452516679-32040-2-git-send-email-aryabi...@virtuozzo.com
> http://lkml.kernel.org/g/1452516679-32040-3-git-send-email-aryabi...@virtuozzo.com
> 
> Without those fixes, this series will trigger a KASAN bug.
> 
> This is a straightforward speedup on Ivy Bridge and newer, IIRC.
> (I tested on Skylake.  INVPCID is not available on Sandy Bridge.
> I don't have Ivy Bridge, Haswell or Broadwell to test on, so I
> could be wrong as to when the feature was introduced.)
> 
> I think we should consider these patches separately from the rest
> of the PCID stuff -- they barely interact, and this part is much
> simpler and is useful on its own.
> 
> This is exactly identical to patches 2-4 of the PCID RFC series.
> 
> Andy Lutomirski (3):
>   x86/mm: Add INVPCID helpers
>   x86/mm: Add a noinvpcid option to turn off INVPCID
>   x86/mm: If INVPCID is available, use it to flush global mappings
> 
>  Documentation/kernel-parameters.txt |  2 ++
>  arch/x86/include/asm/tlbflush.h | 50 
> +
>  arch/x86/kernel/cpu/common.c| 16 
>  3 files changed, 68 insertions(+)

Ok, I'll pick these up tomorrow unless there are objections.

Thanks,

Ingo

Re: [PATCH v4 07/22] kthread: Detect when a kthread work is used by more workers

[Tejun Heo]

On Mon, Jan 25, 2016 at 04:44:56PM +0100, Petr Mladek wrote:
> +static void insert_kthread_work_sanity_check(struct kthread_worker *worker,
> +struct kthread_work *work)
> +{
> + lockdep_assert_held(>lock);
> + WARN_ON_ONCE(!irqs_disabled());

Isn't worker->lock gonna be a irq-safe lock?  If so, why would this
need to be tested separately?

> + WARN_ON_ONCE(!list_empty(>node));
> + /* Do not use a work with more workers, see queue_kthread_work() */
> + WARN_ON_ONCE(work->worker && work->worker != worker);
> +}

Is this sanity check function gonna be used from multiple places?

>  /* insert @work before @pos in @worker */
>  static void insert_kthread_work(struct kthread_worker *worker,
> -struct kthread_work *work,
> -struct list_head *pos)
> + struct kthread_work *work,
> + struct list_head *pos)
>  {
> - lockdep_assert_held(>lock);
> + insert_kthread_work_sanity_check(worker, work);
>  
>   list_add_tail(>node, pos);
>   work->worker = worker;
> @@ -717,6 +730,15 @@ static void insert_kthread_work(struct kthread_worker 
> *worker,
>   * Queue @work to work processor @task for async execution.  @task
>   * must have been created with kthread_worker_create().  Returns %true
>   * if @work was successfully queued, %false if it was already pending.
> + *
> + * Never queue a work into a worker when it is being processed by another
> + * one. Otherwise, some operations, e.g. cancel or flush, will not work
> + * correctly or the work might run in parallel. This is not enforced
> + * because it would make the code too complex. There are only warnings
> + * printed when such a situation is detected.

I'm not sure the above paragraph adds much.  It isn't that accurate to
begin with as what's being disallowed is larger scope than the above.
Isn't the paragraph below enough?

> + * Reinitialize the work if it needs to be used by another worker.
> + * For example, when the worker was stopped and started again.
>   */
>  bool queue_kthread_work(struct kthread_worker *worker,
>   struct kthread_work *work)
> -- 
> 1.8.5.6
> 

-- 
tejun

[PATCH 2/2] reset: add a SYSCON based reset driver

[Andrew F. Davis]

Add a reset-controller driver for performing reset management of
various devices present on the SoC, with the reset registers shared
between devices in a common register memory space. This driver uses
the syscon/regmap frameworks to actually implement the various reset
functionalities needed by the reset consumer devices.

Signed-off-by: Andrew F. Davis 
[s-a...@ti.com: add documentation, syscon name change]
Signed-off-by: Suman Anna 
---
 drivers/reset/Kconfig|  10 ++
 drivers/reset/Makefile   |   1 +
 drivers/reset/reset-syscon.c | 259 +++
 3 files changed, 270 insertions(+)
 create mode 100644 drivers/reset/reset-syscon.c

diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
index df37212..5f26755 100644
--- a/drivers/reset/Kconfig
+++ b/drivers/reset/Kconfig
@@ -12,5 +12,15 @@ menuconfig RESET_CONTROLLER
 
  If unsure, say no.
 
+config SYSCON_RESET
+   tristate "SYSCON Reset Driver"
+   depends on RESET_CONTROLLER
+   select MFD_SYSCON
+   help
+ This enables the reset driver support for devices with memory-mapped
+ reset registers as part of a syscon device node. If you wish to use
+ the reset framework for such memory-mapped devices, say Y here.
+ Otherwise, say N.
+
 source "drivers/reset/sti/Kconfig"
 source "drivers/reset/hisilicon/Kconfig"
diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
index 4d7178e..6b3f6e3 100644
--- a/drivers/reset/Makefile
+++ b/drivers/reset/Makefile
@@ -7,3 +7,4 @@ obj-$(CONFIG_ARCH_STI) += sti/
 obj-$(CONFIG_ARCH_HISI) += hisilicon/
 obj-$(CONFIG_ARCH_ZYNQ) += reset-zynq.o
 obj-$(CONFIG_ATH79) += reset-ath79.o
+obj-$(CONFIG_SYSCON_RESET) += reset-syscon.o
diff --git a/drivers/reset/reset-syscon.c b/drivers/reset/reset-syscon.c
new file mode 100644
index 000..48c8c30
--- /dev/null
+++ b/drivers/reset/reset-syscon.c
@@ -0,0 +1,259 @@
+/*
+ * SYSCON regmap reset driver
+ *
+ * Copyright (C) 2015 Texas Instruments Incorporated - http://www.ti.com/
+ * Andrew F. Davis 
+ * Suman Anna 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/**
+ * struct syscon_reset_control - reset control structure
+ * @offset: reset control register offset from syscon base
+ * @reset_bit: reset bit in the reset control register
+ * @assert_high: flag to indicate if setting the bit high asserts the reset
+ * @status_offset: reset status register offset from syscon base
+ * @status_reset_bit: reset status bit in the reset status register
+ * @status_assert_high: flag to indicate if a set bit represents asserted state
+ */
+struct syscon_reset_control {
+   unsigned int offset;
+   unsigned int reset_bit;
+   bool assert_high;
+   unsigned int status_offset;
+   unsigned int status_reset_bit;
+   bool status_assert_high;
+};
+
+/**
+ * struct syscon_reset_data - reset controller information structure
+ * @rcdev: reset controller entity
+ * @dev: reset controller device pointer
+ * @memory: regmap handle containing the memory-mapped reset registers
+ * @idr: idr structure for mapping ids to reset control structures
+ */
+struct syscon_reset_data {
+   struct reset_controller_dev rcdev;
+   struct device *dev;
+   struct regmap *memory;
+   struct idr idr;
+};
+
+#define to_syscon_reset_data(rcdev)\
+   container_of(rcdev, struct syscon_reset_data, rcdev)
+
+/**
+ * syscon_reset_set() - program a device's reset
+ * @rcdev: reset controller entity
+ * @id: ID of the reset to toggle
+ * @assert: boolean flag to indicate assert or deassert
+ *
+ * This is a common internal function used to assert or deassert a device's
+ * reset using the regmap API. The device's reset is asserted if the @assert
+ * argument is true, or deasserted if the @assert argument is false.
+ *
+ * Return: 0 for successful request, else a corresponding error value
+ */
+static int syscon_reset_set(struct reset_controller_dev *rcdev,
+   unsigned long id, bool assert)
+{
+   struct syscon_reset_data *data = to_syscon_reset_data(rcdev);
+   struct syscon_reset_control *control;
+   unsigned int mask, value;
+
+   control = idr_find(>idr, id);
+   if (!control)
+   return -EINVAL;
+
+   mask = BIT(control->reset_bit);
+   value = (assert == control->assert_high) ? mask : 0x0;
+
+   return regmap_update_bits(data->memory, control->offset, mask, 

[PATCH 0/2] Add support for SYSCON reset

[Andrew F. Davis]

Some SoCs contain reset controls for modules that are memory-mapped to
areas shared with other module configuration settings. This requires
synchronization across all drivers accessing this memory area. This
series adds a generic SYSCON reset driver to allow resets toggled
by bits in memory-mapped registers through SYSCON.

Andrew F. Davis (2):
  Documentation: dt: reset: Add syscon reset binding
  reset: add a SYSCON based reset driver

 .../devicetree/bindings/reset/syscon-reset.txt |  84 +++
 drivers/reset/Kconfig  |  10 +
 drivers/reset/Makefile |   1 +
 drivers/reset/reset-syscon.c   | 259 +
 4 files changed, 354 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/reset/syscon-reset.txt
 create mode 100644 drivers/reset/reset-syscon.c

-- 
2.7.0

[PATCH v3] watchdog: Add watchdog timer support for the WinSystems EBC-C384

[William Breathitt Gray]

The WinSystems EBC-C384 has an onboard watchdog timer. The timeout range
supported by the watchdog timer is 1 second to 255 minutes. Timeouts
under 256 seconds have a 1 second resolution, while the rest have a 1
minute resolution.

This driver adds watchdog timer support for this onboard watchdog timer.
The timeout may be configured via the timeout module parameter.

Signed-off-by: William Breathitt Gray 
---
Changes in v3:
  - Remove unnecessary explicit initialization of the timeout parameter
  - Move dmi_match call to beginning of init function
  - Create WATCHDOG_MAX_TIMEOUT define and explain its magic number
  - Use platform_set_drvdata to match later call to platform_get_drvdata
  - Use MODULE_NAME as argument for the platform_device_alloc call
  - Remove duplicate return statement for the init function

 MAINTAINERS |   6 ++
 drivers/watchdog/Kconfig|   9 ++
 drivers/watchdog/Makefile   |   1 +
 drivers/watchdog/ebc-c384_wdt.c | 187 
 4 files changed, 203 insertions(+)
 create mode 100644 drivers/watchdog/ebc-c384_wdt.c

diff --git a/MAINTAINERS b/MAINTAINERS
index b1e3da7..c058abf 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11629,6 +11629,12 @@ M: David Härdeman 
 S: Maintained
 F: drivers/media/rc/winbond-cir.c
 
+WINSYSTEMS EBC-C384 WATCHDOG DRIVER
+M: William Breathitt Gray 
+L: linux-watch...@vger.kernel.org
+S: Maintained
+F: drivers/watchdog/ebc-c384_wdt.c
+
 WIMAX STACK
 M: Inaky Perez-Gonzalez 
 M: linux-wi...@intel.com
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 4f0e7be..b5b1353 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -711,6 +711,15 @@ config ALIM7101_WDT
 
  Most people will say N.
 
+config EBC_C386_WDT
+   tristate "WinSystems EBC-C384 Watchdog Timer"
+   depends on X86
+   select WATCHDOG_CORE
+   help
+ Enables watchdog timer support for the watchdog timer on the
+ WinSystems EBC-C384 motherboard. The timeout may be configured via
+ the timeout module parameter.
+
 config F71808E_WDT
tristate "Fintek F71808E, F71862FG, F71869, F71882FG and F71889FG 
Watchdog"
depends on X86
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index f566753..1522316 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -88,6 +88,7 @@ obj-$(CONFIG_ACQUIRE_WDT) += acquirewdt.o
 obj-$(CONFIG_ADVANTECH_WDT) += advantechwdt.o
 obj-$(CONFIG_ALIM1535_WDT) += alim1535_wdt.o
 obj-$(CONFIG_ALIM7101_WDT) += alim7101_wdt.o
+obj-$(CONFIG_EBC_C386_WDT) += ebc-c384_wdt.o
 obj-$(CONFIG_F71808E_WDT) += f71808e_wdt.o
 obj-$(CONFIG_SP5100_TCO) += sp5100_tco.o
 obj-$(CONFIG_GEODE_WDT) += geodewdt.o
diff --git a/drivers/watchdog/ebc-c384_wdt.c b/drivers/watchdog/ebc-c384_wdt.c
new file mode 100644
index 000..9166b02
--- /dev/null
+++ b/drivers/watchdog/ebc-c384_wdt.c
@@ -0,0 +1,187 @@
+/*
+ * Watchdog timer driver for the WinSystems EBC-C384
+ * Copyright (C) 2016 William Breathitt Gray
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License, version 2, as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define MODULE_NAME "ebc-c384_wdt"
+#define WATCHDOG_TIMEOUT 60
+/* Since the timeout value in minutes must fit in a single byte when sent to 
the
+ * watchdog timer, the maximum timeout possible is 15300 (255 * 60) seconds
+ */
+#define WATCHDOG_MAX_TIMEOUT 15300
+#define BASE_ADDR 0x564
+#define ADDR_EXTENT 5
+#define CFG_ADDR (BASE_ADDR + 1)
+#define PET_ADDR (BASE_ADDR + 2)
+
+static bool nowayout = WATCHDOG_NOWAYOUT;
+module_param(nowayout, bool, 0);
+MODULE_PARM_DESC(nowayout, "Watchdog cannot be stopped once started (default="
+   __MODULE_STRING(WATCHDOG_NOWAYOUT) ")");
+
+static unsigned timeout;
+module_param(timeout, uint, 0);
+MODULE_PARM_DESC(timeout, "Watchdog timeout in seconds (default="
+   __MODULE_STRING(WATCHDOG_TIMEOUT) ")");
+
+static int ebc_c384_wdt_start(struct watchdog_device *wdev)
+{
+   unsigned t = wdev->timeout;
+
+   /* resolution is in minutes for timeouts greater than 255 seconds */
+   if (t > 255)
+   t /= 60;
+
+   outb(t, PET_ADDR);
+
+   return 0;
+}
+
+static int ebc_c384_wdt_stop(struct watchdog_device *wdev)
+{
+   outb(0x00, PET_ADDR);
+
+   return 0;
+}
+
+static int ebc_c384_wdt_set_timeout(struct watchdog_device *wdev, 

Re: [PATCH] signals: work around random wakeups in sigsuspend()

[Oleg Nesterov]

On 01/25, Sasha Levin wrote:
>
> A random wakeup can get us out of sigsuspend() without TIF_SIGPENDING
> being set.

and TIF_RESTORE_SIGMASK is just wrong in this case. I'd say this is the
bugfix, not work-around ;)

> Avoid that by making sure we were signaled, like sys_pause() does.
>
> Signed-off-by: Sasha Levin 

Acked-by: Oleg Nesterov 

Thanks Sasha.


> ---
>  kernel/signal.c |6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/kernel/signal.c b/kernel/signal.c
> index 5da9180..3256c7e 100644
> --- a/kernel/signal.c
> +++ b/kernel/signal.c
> @@ -3528,8 +3528,10 @@ static int sigsuspend(sigset_t *set)
>   current->saved_sigmask = current->blocked;
>   set_current_blocked(set);
>  
> - __set_current_state(TASK_INTERRUPTIBLE);
> - schedule();
> + while (!signal_pending(current)) {
> + __set_current_state(TASK_INTERRUPTIBLE);
> + schedule();
> + }
>   set_restore_sigmask();
>   return -ERESTARTNOHAND;
>  }
> -- 
> 1.7.10.4
> 

Re: [PATCH v3 00/17] Enhance iomem search interfaces and support EINJ to NVDIMM

[Borislav Petkov]

On Tue, Jan 05, 2016 at 11:54:28AM -0700, Toshi Kani wrote:
> This patch-set enhances the iomem table and its search interfacs, and
> then changes EINJ to support NVDIMM.
> 
>  - Patches 1-2 add a new System RAM type, IORESOURCE_SYSTEM_RAM, and
>make the iomem search interfaces work with resource flags with
>modifier bits set.  IORESOURCE_SYSTEM_RAM has IORESOURCE_MEM bit set
>for backward compatibility.
> 
>  - Patch 3 adds a new field, I/O resource descriptor, into struct resource.
>Drivers can assign their unique descritor to a range when they support
>the iomem search interfaces.
> 
>  - Patches 4-9 changes initializations of resource entries.  They set
>the System RAM type to System RAM ranges, set I/O resource descriptors
>to the regions targeted by the iomem search interfaces, and change
>to call kzalloc() where kmalloc() is used to allocate struct resource
>ranges.
> 
>  - Patches 10-14 extend the iomem interfaces to check System RAM ranges
>with the System RAM type and the I/O resource descriptor.
> 
>  - Patch 15-16 remove deprecated walk_iomem_res().
> 
>  - Patch 17 changes the EINJ driver to allow injecting a memory error
>to NVDIMM.

Ok, all applied ontop of 4.5-rc1.

You could take a look if everything's still fine and I haven't botched
anything:

http://git.kernel.org/cgit/linux/kernel/git/bp/bp.git/log/?h=tip-mm

I'll let the build bot chew on it and then test it here and send it out
again to everyone on CC so that people don't act surprised.

Thanks for this cleanup, code looks much better now!

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.

Re: [f2fs-dev] [PATCH 1/2] f2fs: avoid multiple node page writes due to inline_data

[Jaegeuk Kim]

Hi Chao,

On Mon, Jan 25, 2016 at 05:42:40PM +0800, Chao Yu wrote:
> Hi Jaegeuk,
> 
> > -Original Message-
> > From: Jaegeuk Kim [mailto:jaeg...@kernel.org]
> > Sent: Sunday, January 24, 2016 4:16 AM
> > To: linux-kernel@vger.kernel.org; linux-fsde...@vger.kernel.org;
> > linux-f2fs-de...@lists.sourceforge.net
> > Cc: Jaegeuk Kim
> > Subject: [f2fs-dev] [PATCH 1/2] f2fs: avoid multiple node page writes due 
> > to inline_data
> > 
> > The sceanrio is:
> > 1. create fully node blocks
> > 2. flush node blocks
> > 3. write inline_data for all the node blocks again
> > 4. flush node blocks redundantly
> > 
> > Signed-off-by: Jaegeuk Kim 
> > ---
> >  fs/f2fs/data.c | 14 +++---
> >  1 file changed, 11 insertions(+), 3 deletions(-)
> > 
> > diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
> > index 8d0d9ec..011456e 100644
> > --- a/fs/f2fs/data.c
> > +++ b/fs/f2fs/data.c
> > @@ -1622,14 +1622,22 @@ static int f2fs_write_end(struct file *file,
> > 
> > trace_f2fs_write_end(inode, pos, len, copied);
> > 
> > -   set_page_dirty(page);
> > -
> > if (pos + copied > i_size_read(inode)) {
> > i_size_write(inode, pos + copied);
> > mark_inode_dirty(inode);
> > -   update_inode_page(inode);
> > }
> > 
> > +   if (f2fs_has_inline_data(inode) &&
> > +   is_inode_flag_set(F2FS_I(inode), FI_DATA_EXIST)) {
> > +   int err = f2fs_write_inline_data(inode, page);
> 
> Oh, I'm sure this can fix that issue, but IMO:
> a) this implementation has side-effect, it triggers inline data copying
> between data page and node page whenever user write inline datas, so if
> user updates inline data frequently, write-through approach would cause
> memory copy overhead.

Agreed.

> b) inline storm should be a rare case, as we didn't get any report about
> problem for long time until Dave's, and write_end is a hot path, I think
> it's better to be cautious to change our inline data cache policy for
> fixing a rare issue in hot path.
> 
> What about delaying the merge operation? like:
> 1) as I proposed before, merging inline page into inode page when
> detecting free_sections <= (node_secs + 2 * dent_secs + inline_secs).
> 2) merge inline page into inode page before writeback inode page in
> sync_node_pages.

Okay, I'm thinking more general way where we can get rid of every inlien_data
write when we flush node pages.

I've been testing this patch.

>From ebddf607c64da691fef08cf68a8ecadafd5d896b Mon Sep 17 00:00:00 2001
From: Jaegeuk Kim 
Date: Mon, 25 Jan 2016 05:57:05 -0800
Subject: [PATCH] f2fs: avoid multiple node page writes due to inline_data

The sceanrio is:
1. create fully node blocks
2. flush node blocks
3. write inline_data for all the node blocks again
4. flush node blocks redundantly

So, this patch tries to flush inline_data when flushing node blocks.

Signed-off-by: Jaegeuk Kim 
---
 fs/f2fs/data.c   |  1 +
 fs/f2fs/inline.c |  2 ++
 fs/f2fs/node.c   | 35 +++
 fs/f2fs/node.h   | 15 +++
 4 files changed, 53 insertions(+)

diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index 6925c10..9043ecf 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -1464,6 +1464,7 @@ restart:
if (pos + len <= MAX_INLINE_DATA) {
read_inline_data(page, ipage);
set_inode_flag(F2FS_I(inode), FI_DATA_EXIST);
+   set_inline_node(ipage);
sync_inode_page();
} else {
err = f2fs_convert_inline_page(, page);
diff --git a/fs/f2fs/inline.c b/fs/f2fs/inline.c
index 8df13e5..fc4d298 100644
--- a/fs/f2fs/inline.c
+++ b/fs/f2fs/inline.c
@@ -159,6 +159,7 @@ no_update:
 
/* clear inline data and flag after data writeback */
truncate_inline_inode(dn->inode_page, 0);
+   clear_inline_node(dn->inode_page);
 clear_out:
stat_dec_inline_inode(dn->inode);
f2fs_clear_inline_inode(dn->inode);
@@ -233,6 +234,7 @@ int f2fs_write_inline_data(struct inode *inode, struct page 
*page)
set_inode_flag(F2FS_I(inode), FI_DATA_EXIST);
 
sync_inode_page();
+   clear_inline_node(dn.inode_page);
f2fs_put_dnode();
return 0;
 }
diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
index 23b800d..1c5023e 100644
--- a/fs/f2fs/node.c
+++ b/fs/f2fs/node.c
@@ -1154,6 +1154,33 @@ void sync_inode_page(struct dnode_of_data *dn)
dn->node_changed = ret ? true: false;
 }
 
+static void flush_inline_data(struct f2fs_sb_info *sbi, nid_t ino)
+{
+   struct inode *inode;
+   struct page *page;
+
+   inode = ilookup(sbi->sb, ino);
+   if (!inode)
+   return;
+
+   page = find_lock_page(inode->i_mapping, 0);
+   if (!page)
+   goto iput_out;
+
+   if (!PageDirty(page))
+   goto put_page_out;
+
+   if (!clear_page_dirty_for_io(page))
+   goto 

Re: [PATCH/RFC] mm/debug_pagealloc: enable it by default

[Dave Jones]

On Mon, Jan 25, 2016 at 09:21:53AM +0100, Christian Borntraeger wrote:

 > >> Let's go back to the original default and reverse the command
 > >> line parameter to allow disabling the feature.
 > > 
 > > Default disable is requested by Andrew and I agreed that.
 > > 
 > > https://lkml.org/lkml/2014/11/27/3
 > 
 > Well, Andrew's assumption was "I suspect the number of "old users" is one"
 > and this is wrong. I can at least claim, that most of the s390 test were 
 > conducted with CONFIG_DEBUG_PAGEALLOC enabled (at least regularly) - and 
 > about a year ago this was changed to "no longer useful". I have posted 2
 > real bugs that I triggered pretty quickly after I enabled things on the 
 > command line.

Nearly all the fuzz-test runs I've done over the last few years have had this
enabled most the time.  I was wondering why things got faster last year.

 > > I think that default disable is good thing because we can use
 > > the kernel compiled with CONFIG_DEBUG_PAGEALLOC even for production.
 > > Unless boot param is provided, it's runtime cost is nearly zero.
 > > This could help to debug in some situations and make this debugging
 > > feature more useful. But, yes, old users can be surprised
 > > by this change. How about changing Kconfig to ask user for default mode?
 > 
 > A default mode would be ok for me as it makes things obvious. Will send
 > a patch.

The messaging around changing a default like this was really poor.
When we do behaviour changes like this, we typically rename the CONFIG option
to make it obvious that things aren't as they used to be.

ho-hum.

Dave

Re: [PATCH] signals: work around random wakeups in sigsuspend()

[Peter Zijlstra]

On Mon, Jan 25, 2016 at 08:09:15PM +0100, Oleg Nesterov wrote:
> On 01/25, Sasha Levin wrote:
> >
> > A random wakeup can get us out of sigsuspend() without TIF_SIGPENDING
> > being set.
> 
> and TIF_RESTORE_SIGMASK is just wrong in this case. I'd say this is the
> bugfix, not work-around ;)

Agreed!

> > Avoid that by making sure we were signaled, like sys_pause() does.
> >
> > Signed-off-by: Sasha Levin 
> 
> Acked-by: Oleg Nesterov 

Acked-by: Peter Zijlstra (Intel) 

Re: [PATCH v2 1/2] dt-bindings: GPIO: Add generic serializer binding

[Rob Herring]

On Mon, Jan 25, 2016 at 10:37:30AM -0600, Andrew F. Davis wrote:
> Add binding for generic parallel-in/serial-out shift register devices
> used as GPIO.
> 
> Signed-off-by: Andrew F. Davis 
> ---
>  .../devicetree/bindings/gpio/gpio-pisosr.txt   | 34 
> ++
>  1 file changed, 34 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/gpio/gpio-pisosr.txt

One nit, otherwise:

Acked-by: Rob Herring 

> 
> diff --git a/Documentation/devicetree/bindings/gpio/gpio-pisosr.txt 
> b/Documentation/devicetree/bindings/gpio/gpio-pisosr.txt
> new file mode 100644
> index 000..e69e8ec
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/gpio/gpio-pisosr.txt
> @@ -0,0 +1,34 @@
> +Generic Parallel-in/Serial-out Shift Register GPIO Driver
> +
> +This binding describes generic parallel-in/serial-out shift register
> +devices that can be used for GPI (General Purpose Input). This includes
> +SN74165 serial-out shift registers and the SN65HVS88x series of
> +industrial serializers.
> +
> +Required properties:
> + - compatible: Should be "pisosr-gpio".
> + - gpio-controller   : Marks the device node as a GPIO controller.
> + - #gpio-cells   : Should be two. For consumer use see gpio.txt.
> +
> +Optional properties:
> + - ngpios: Number of GPIO lines, default is 8.
> + - load-gpios: GPIO pin specifier attached to load enable, 
> this
> +   pin is pulsed before reading from the device to
> +   load input pin values into the the device.
> +
> +For other required and optional properties of SPI slave
> +nodes please refer to ../spi/spi-bus.txt.
> +
> +Example:
> +
> + sn65hvs882@0 {

should be gpio@0

> + compatible = "pisosr-gpio";
> + gpio-controller;
> + #gpio-cells = <2>;
> +
> + load-gpios = < 23 GPIO_ACTIVE_LOW>;
> +
> + reg = <0>;
> + spi-max-frequency = <100>;
> + spi-cpol;
> + };
> -- 
> 2.7.0
> 

[PATCH 1/8] x86/traps.c: Refactor preemption and interrupt flag handling

[Borislav Petkov]

From: Alexander Kuleshov 

Make the preemption and interrupt flag handling more readable by
removing preempt_conditional_sti() and preempt_conditional_cli() helpers
and using preempt_disable() and preempt_enable_no_resched() instead.

Rename contitional_sti() and conditional_cli() to the more
understandable cond_local_irq_enable() and cond_local_irq_disable()
respectively, while at it.

Signed-off-by: Alexander Kuleshov 
Acked-by: Thomas Gleixner 
Suggested-by: Borislav Petkov 
Cc: Andy Lutomirski 
Cc: Dave Hansen 
Cc: "H Peter Anvin" 
Cc: Ingo Molnar 
Cc: Wang Nan 
Cc: x86-ml 
Link: 
http://lkml.kernel.org/r/1453036184-15077-1-git-send-email-kuleshovm...@gmail.com
[ Boris: massage text. ]
Signed-off-by: Borislav Petkov 
---
 arch/x86/kernel/traps.c | 47 +++
 1 file changed, 19 insertions(+), 28 deletions(-)

diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
index ade185a46b1d..410e8e2700c5 100644
--- a/arch/x86/kernel/traps.c
+++ b/arch/x86/kernel/traps.c
@@ -83,30 +83,16 @@ gate_desc idt_table[NR_VECTORS] __page_aligned_bss;
 DECLARE_BITMAP(used_vectors, NR_VECTORS);
 EXPORT_SYMBOL_GPL(used_vectors);
 
-static inline void conditional_sti(struct pt_regs *regs)
+static inline void cond_local_irq_enable(struct pt_regs *regs)
 {
if (regs->flags & X86_EFLAGS_IF)
local_irq_enable();
 }
 
-static inline void preempt_conditional_sti(struct pt_regs *regs)
-{
-   preempt_count_inc();
-   if (regs->flags & X86_EFLAGS_IF)
-   local_irq_enable();
-}
-
-static inline void conditional_cli(struct pt_regs *regs)
-{
-   if (regs->flags & X86_EFLAGS_IF)
-   local_irq_disable();
-}
-
-static inline void preempt_conditional_cli(struct pt_regs *regs)
+static inline void cond_local_irq_disable(struct pt_regs *regs)
 {
if (regs->flags & X86_EFLAGS_IF)
local_irq_disable();
-   preempt_count_dec();
 }
 
 void ist_enter(struct pt_regs *regs)
@@ -286,7 +272,7 @@ static void do_error_trap(struct pt_regs *regs, long 
error_code, char *str,
 
if (notify_die(DIE_TRAP, str, regs, error_code, trapnr, signr) !=
NOTIFY_STOP) {
-   conditional_sti(regs);
+   cond_local_irq_enable(regs);
do_trap(trapnr, signr, str, regs, error_code,
fill_trap_info(regs, signr, trapnr, ));
}
@@ -368,7 +354,7 @@ dotraplinkage void do_bounds(struct pt_regs *regs, long 
error_code)
if (notify_die(DIE_TRAP, "bounds", regs, error_code,
X86_TRAP_BR, SIGSEGV) == NOTIFY_STOP)
return;
-   conditional_sti(regs);
+   cond_local_irq_enable(regs);
 
if (!user_mode(regs))
die("bounds", regs, error_code);
@@ -443,7 +429,7 @@ do_general_protection(struct pt_regs *regs, long error_code)
struct task_struct *tsk;
 
RCU_LOCKDEP_WARN(!rcu_is_watching(), "entry code didn't wake RCU");
-   conditional_sti(regs);
+   cond_local_irq_enable(regs);
 
if (v8086_mode(regs)) {
local_irq_enable();
@@ -517,9 +503,11 @@ dotraplinkage void notrace do_int3(struct pt_regs *regs, 
long error_code)
 * as we may switch to the interrupt stack.
 */
debug_stack_usage_inc();
-   preempt_conditional_sti(regs);
+   preempt_disable();
+   cond_local_irq_enable(regs);
do_trap(X86_TRAP_BP, SIGTRAP, "int3", regs, error_code, NULL);
-   preempt_conditional_cli(regs);
+   cond_local_irq_disable(regs);
+   preempt_enable_no_resched();
debug_stack_usage_dec();
 exit:
ist_exit(regs);
@@ -648,12 +636,14 @@ dotraplinkage void do_debug(struct pt_regs *regs, long 
error_code)
debug_stack_usage_inc();
 
/* It's safe to allow irq's after DR6 has been saved */
-   preempt_conditional_sti(regs);
+   preempt_disable();
+   cond_local_irq_enable(regs);
 
if (v8086_mode(regs)) {
handle_vm86_trap((struct kernel_vm86_regs *) regs, error_code,
X86_TRAP_DB);
-   preempt_conditional_cli(regs);
+   cond_local_irq_disable(regs);
+   preempt_enable_no_resched();
debug_stack_usage_dec();
goto exit;
}
@@ -673,7 +663,8 @@ dotraplinkage void do_debug(struct pt_regs *regs, long 
error_code)
si_code = get_si_code(tsk->thread.debugreg6);
if (tsk->thread.debugreg6 & (DR_STEP | DR_TRAP_BITS) || user_icebp)
send_sigtrap(tsk, regs, error_code, si_code);
-   preempt_conditional_cli(regs);
+   cond_local_irq_disable(regs);
+   preempt_enable_no_resched();

[PATCH 4/8] x86/mce/AMD: Do not perform shared bank check for future processors

[Borislav Petkov]

From: Aravind Gopalakrishnan 

Fam17h and above should not require a check to see if a bank is shared
or not. For shared banks, there will always be only one core that has
visibility over the MSRs and only that particular core will be allowed
to write to the MSRs.

Fix the code to return early if we have Scalable MCA support. No change
in functionality for earlier processors.

Boris: Fold in fix from kbuild test robot for:

  arch/x86/kernel/cpu/mcheck/mce_amd.c:93:9-10: WARNING: return of 0/1 in 
function 'is_shared_bank' with return type bool
  Generated by: scripts/coccinelle/misc/boolreturn.cocci

Signed-off-by: Aravind Gopalakrishnan 
Cc: linux-edac 
Cc: Tony Luck 
Cc: x86-ml 
Link: 
http://lkml.kernel.org/r/1452901836-27632-3-git-send-email-aravind.gopalakrish...@amd.com
Signed-off-by: Fengguang Wu 
[ Boris: massage text. ]
Signed-off-by: Borislav Petkov 
---
 arch/x86/kernel/cpu/mcheck/mce_amd.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/x86/kernel/cpu/mcheck/mce_amd.c 
b/arch/x86/kernel/cpu/mcheck/mce_amd.c
index e99b15077e94..3068ce25dfa1 100644
--- a/arch/x86/kernel/cpu/mcheck/mce_amd.c
+++ b/arch/x86/kernel/cpu/mcheck/mce_amd.c
@@ -84,6 +84,13 @@ struct thresh_restart {
 
 static inline bool is_shared_bank(int bank)
 {
+   /*
+* Scalable MCA provides for only one core to have access to the MSRs of
+* a shared bank.
+*/
+   if (mce_flags.smca)
+   return false;
+
/* Bank 4 is for northbridge reporting and is thus shared */
return (bank == 4);
 }
-- 
2.3.5

[PATCH 7/8] x86/mce/AMD: Carve out threshold block preparation

[Borislav Petkov]

From: Borislav Petkov 

mce_amd_feature_init() was getting pretty fat, carve out the
threshold_block setup into a separate function in order to simplify flow
and make it more understandable.

No functionality change.

Signed-off-by: Borislav Petkov 
Cc: Aravind Gopalakrishnan 
---
 arch/x86/kernel/cpu/mcheck/mce_amd.c | 88 
 1 file changed, 50 insertions(+), 38 deletions(-)

diff --git a/arch/x86/kernel/cpu/mcheck/mce_amd.c 
b/arch/x86/kernel/cpu/mcheck/mce_amd.c
index 35ca4ec7fc65..e5ac583ae915 100644
--- a/arch/x86/kernel/cpu/mcheck/mce_amd.c
+++ b/arch/x86/kernel/cpu/mcheck/mce_amd.c
@@ -267,14 +267,60 @@ static void deferred_error_interrupt_enable(struct 
cpuinfo_x86 *c)
wrmsr(MSR_CU_DEF_ERR, low, high);
 }
 
+static int
+prepare_threshold_block(unsigned int bank, unsigned int block, u32 addr,
+   int offset, u32 misc_high)
+{
+   unsigned int cpu = smp_processor_id();
+   struct threshold_block b;
+   int new;
+
+   if (!block)
+   per_cpu(bank_map, cpu) |= (1 << bank);
+
+   memset(, 0, sizeof(b));
+   b.cpu   = cpu;
+   b.bank  = bank;
+   b.block = block;
+   b.address   = addr;
+   b.interrupt_capable = lvt_interrupt_supported(bank, misc_high);
+
+   if (!b.interrupt_capable)
+   goto done;
+
+   b.interrupt_enable = 1;
+
+   if (mce_flags.smca) {
+   u32 smca_low, smca_high;
+
+   /* Gather LVT offset for thresholding */
+   if (rdmsr_safe(MSR_CU_DEF_ERR, _low, _high))
+   goto out;
+
+   new = (smca_low & SMCA_THR_LVT_OFF) >> 12;
+   } else {
+   new = (misc_high & MASK_LVTOFF_HI) >> 20;
+   }
+
+   offset = setup_APIC_mce_threshold(offset, new);
+
+   if ((offset == new) &&
+   (mce_threshold_vector != amd_threshold_interrupt))
+   mce_threshold_vector = amd_threshold_interrupt;
+
+done:
+   mce_threshold_block_init(, offset);
+
+out:
+   return offset;
+}
+
 /* cpu init entry point, called from mce.c with preempt off */
 void mce_amd_feature_init(struct cpuinfo_x86 *c)
 {
-   struct threshold_block b;
-   unsigned int cpu = smp_processor_id();
u32 low = 0, high = 0, address = 0;
unsigned int bank, block;
-   int offset = -1, new;
+   int offset = -1;
 
for (bank = 0; bank < mca_cfg.banks; ++bank) {
for (block = 0; block < NR_BLOCKS; ++block) {
@@ -299,41 +345,7 @@ void mce_amd_feature_init(struct cpuinfo_x86 *c)
 (high & MASK_LOCKED_HI))
continue;
 
-   if (!block)
-   per_cpu(bank_map, cpu) |= (1 << bank);
-
-   memset(, 0, sizeof(b));
-   b.cpu   = cpu;
-   b.bank  = bank;
-   b.block = block;
-   b.address   = address;
-   b.interrupt_capable = lvt_interrupt_supported(bank, 
high);
-
-   if (!b.interrupt_capable)
-   goto init;
-
-   b.interrupt_enable = 1;
-
-   if (mce_flags.smca) {
-   u32 smca_low, smca_high;
-
-   /* Gather LVT offset for thresholding */
-   if (rdmsr_safe(MSR_CU_DEF_ERR, _low, 
_high))
-   break;
-
-   new = (smca_low & SMCA_THR_LVT_OFF) >> 12;
-   } else {
-   new = (high & MASK_LVTOFF_HI) >> 20;
-   }
-
-   offset  = setup_APIC_mce_threshold(offset, new);
-
-   if ((offset == new) &&
-   (mce_threshold_vector != amd_threshold_interrupt))
-   mce_threshold_vector = amd_threshold_interrupt;
-
-init:
-   mce_threshold_block_init(, offset);
+   offset = prepare_threshold_block(bank, block, address, 
offset, high);
}
}
 
-- 
2.3.5

Re: 'perf stat --repeat N' oddity/regression

[Arnaldo Carvalho de Melo]

Em Mon, Jan 25, 2016 at 07:35:11PM +0100, Ingo Molnar escreveu:
> 
> So it appears it broke somewhere between v4.0 and v4.1, as the v4.0 install 
> displays:
> 
> 16,244,802,268  instructions   ( +- 23.01% )
> 
>2.108676769 seconds time elapsed   
>( +-  0.86% )
> 
> 
> [a few minutes later]
> 
> Bisected it down to:

Mel Gorman reported this and Jiri provided a patch that Mel tested and
verified that it fixed, checking where it is sitting now...

- Arnaldo
 
>  106a94a0f8c207ef4113ce7e32f34a00b3b174e7 is the first bad commit
>  commit 106a94a0f8c207ef4113ce7e32f34a00b3b174e7
>  Author: Jiri Olsa 
>  Date:   Fri Jun 26 11:29:19 2015 +0200
> 
>  perf stat: Introduce read_counters function
> 
> So this look like to be a regression.
> 
> Thanks,
> 
>   Ingo

[PATCH 2/8] x86/cpufeature: Use enum cpuid_leafs instead of magic numbers

[Borislav Petkov]

From: Huaitong Han 

Most of magic numbers of x86_capability have been converted to enum
cpuid_leafs, and this patch does update the remaining part.

Signed-off-by: Huaitong Han 
Cc: Alexander Kuleshov 
Cc: Andrew Morton 
Cc: Andy Lutomirski 
Cc: Boris Ostrovsky 
Cc: Brian Gerst 
Cc: David Vrabel 
Cc: Denys Vlasenko 
Cc: Hector Marco-Gisbert 
Cc: "H. Peter Anvin" 
Cc: Ingo Molnar 
Cc: Jiang Liu 
Cc: Kees Cook 
Cc: Konrad Rzeszutek Wilk 
Cc: lgu...@lists.ozlabs.org
Cc: Rusty Russell 
Cc: Thomas Gleixner 
Cc: Viresh Kumar 
Cc: x86-ml 
Cc: xen-de...@lists.xenproject.org
Link: 
http://lkml.kernel.org/r/1453374160-4648-1-git-send-email-huaitong@intel.com
Signed-off-by: Borislav Petkov 
---
 arch/x86/include/asm/elf.h | 2 +-
 arch/x86/kernel/mpparse.c  | 2 +-
 arch/x86/lguest/boot.c | 2 +-
 arch/x86/xen/enlighten.c   | 2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/x86/include/asm/elf.h b/arch/x86/include/asm/elf.h
index 1514753fd435..15340e36ddcb 100644
--- a/arch/x86/include/asm/elf.h
+++ b/arch/x86/include/asm/elf.h
@@ -256,7 +256,7 @@ extern int force_personality32;
instruction set this CPU supports.  This could be done in user space,
but it's not easy, and we've already done it here.  */
 
-#define ELF_HWCAP  (boot_cpu_data.x86_capability[0])
+#define ELF_HWCAP  (boot_cpu_data.x86_capability[CPUID_1_EDX])
 
 /* This yields a string that ld.so will use to load implementation
specific libraries for optimization.  This is more specific in
diff --git a/arch/x86/kernel/mpparse.c b/arch/x86/kernel/mpparse.c
index 30ca7607cbbb..97340f2c437c 100644
--- a/arch/x86/kernel/mpparse.c
+++ b/arch/x86/kernel/mpparse.c
@@ -408,7 +408,7 @@ static inline void __init construct_default_ISA_mptable(int 
mpc_default_type)
processor.cpuflag = CPU_ENABLED;
processor.cpufeature = (boot_cpu_data.x86 << 8) |
(boot_cpu_data.x86_model << 4) | boot_cpu_data.x86_mask;
-   processor.featureflag = boot_cpu_data.x86_capability[0];
+   processor.featureflag = boot_cpu_data.x86_capability[CPUID_1_EDX];
processor.reserved[0] = 0;
processor.reserved[1] = 0;
for (i = 0; i < 2; i++) {
diff --git a/arch/x86/lguest/boot.c b/arch/x86/lguest/boot.c
index 4ba229ac3f4f..a9033ae13369 100644
--- a/arch/x86/lguest/boot.c
+++ b/arch/x86/lguest/boot.c
@@ -1535,7 +1535,7 @@ __init void lguest_init(void)
 */
cpu_detect(_cpu_data);
/* head.S usually sets up the first capability word, so do it here. */
-   new_cpu_data.x86_capability[0] = cpuid_edx(1);
+   new_cpu_data.x86_capability[CPUID_1_EDX] = cpuid_edx(1);
 
/* Math is always hard! */
set_cpu_cap(_cpu_data, X86_FEATURE_FPU);
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index d09e4c9d7cc5..2c261082eadf 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -1654,7 +1654,7 @@ asmlinkage __visible void __init xen_start_kernel(void)
cpu_detect(_cpu_data);
set_cpu_cap(_cpu_data, X86_FEATURE_FPU);
new_cpu_data.wp_works_ok = 1;
-   new_cpu_data.x86_capability[0] = cpuid_edx(1);
+   new_cpu_data.x86_capability[CPUID_1_EDX] = cpuid_edx(1);
 #endif
 
if (xen_start_info->mod_start) {
-- 
2.3.5

[PATCH 0/8] tip-queue 2016-01-25

[Borislav Petkov]

From: Borislav Petkov 

Hi,

here's the first pile. It contains mainly the RAS pile for 4.6 and a
couple of small cleanups.

Please apply,
thanks.


Alexander Kuleshov (1):
  x86/traps.c: Refactor preemption and interrupt flag handling

Aravind Gopalakrishnan (5):
  x86/mce: Fix order of AMD MCE init function call
  x86/mce/AMD: Do not perform shared bank check for future processors
  x86/mce/AMD: Reduce number of blocks scanned per bank
  x86/mce/AMD: Fix LVT offset configuration for thresholding
  x86/mce/AMD: Set MCAX Enable bit

Borislav Petkov (1):
  x86/mce/AMD: Carve out threshold block preparation

Huaitong Han (1):
  x86/cpufeature: Use enum cpuid_leafs instead of magic numbers

 arch/x86/include/asm/elf.h   |   2 +-
 arch/x86/include/asm/msr-index.h |   4 ++
 arch/x86/kernel/cpu/mcheck/mce.c |   2 +-
 arch/x86/kernel/cpu/mcheck/mce_amd.c | 112 ++-
 arch/x86/kernel/mpparse.c|   2 +-
 arch/x86/kernel/traps.c  |  47 ++-
 arch/x86/lguest/boot.c   |   2 +-
 arch/x86/xen/enlighten.c |   2 +-
 8 files changed, 113 insertions(+), 60 deletions(-)

-- 
2.3.5

[PATCH 5/8] x86/mce/AMD: Reduce number of blocks scanned per bank

[Borislav Petkov]

From: Aravind Gopalakrishnan 

>From Fam17h onwards, the number of extended MCx_MISC register blocks is
reduced to 4. It is an architectural change from what we had on earlier
processors.

Although theoritically the total number of extended MCx_MISC registers
was 8 in earlier processor families, in practice we only had to use the
extra registers for MC4. And only 2 of those were used. So this change
does not affect older processors. Tested on Fam10h and Fam15h systems.

Signed-off-by: Aravind Gopalakrishnan 
Cc: linux-edac 
Cc: Tony Luck 
Cc: x86-ml 
Link: 
http://lkml.kernel.org/r/1452901836-27632-4-git-send-email-aravind.gopalakrish...@amd.com
Signed-off-by: Borislav Petkov 
---
 arch/x86/kernel/cpu/mcheck/mce_amd.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kernel/cpu/mcheck/mce_amd.c 
b/arch/x86/kernel/cpu/mcheck/mce_amd.c
index 3068ce25dfa1..5982227990c9 100644
--- a/arch/x86/kernel/cpu/mcheck/mce_amd.c
+++ b/arch/x86/kernel/cpu/mcheck/mce_amd.c
@@ -28,7 +28,7 @@
 #include 
 #include 
 
-#define NR_BLOCKS 9
+#define NR_BLOCKS 5
 #define THRESHOLD_MAX 0xFFF
 #define INT_TYPE_APIC 0x0002
 #define MASK_VALID_HI 0x8000
-- 
2.3.5

Re: 'perf stat --repeat N' oddity/regression

[Arnaldo Carvalho de Melo]

Em Mon, Jan 25, 2016 at 04:43:33PM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Mon, Jan 25, 2016 at 07:35:11PM +0100, Ingo Molnar escreveu:
> > 
> > So it appears it broke somewhere between v4.0 and v4.1, as the v4.0 install 
> > displays:
> > 
> > 16,244,802,268  instructions   ( +- 23.01% )
> > 
> >2.108676769 seconds time elapsed 
> >  ( +-  0.86% )
> > 
> > 
> > [a few minutes later]
> > 
> > Bisected it down to:
> 
> Mel Gorman reported this and Jiri provided a patch that Mel tested and
> verified that it fixed, checking where it is sitting now...

I already sent it your way, its:

198 N C 01/21 Arnaldo Carvalh (1.4K) ├─>[PATCH 06/16] perf stat: Do not 
clean event's private stats

Please pull my perf-core-for-mingo tag and you should get it, its an one
liner.

- Arnaldo
 
> - Arnaldo
>  
> >  106a94a0f8c207ef4113ce7e32f34a00b3b174e7 is the first bad commit
> >  commit 106a94a0f8c207ef4113ce7e32f34a00b3b174e7
> >  Author: Jiri Olsa 
> >  Date:   Fri Jun 26 11:29:19 2015 +0200
> > 
> >  perf stat: Introduce read_counters function
> > 
> > So this look like to be a regression.
> > 
> > Thanks,
> > 
> > Ingo

[PATCH] ASoC: wm2000: Use a signed return type for regmap_read

[Lucas Tanure]

The return type "unsigned int" was used by the regmap_read() function despite
of the aspect that it will eventually return a negative error code. So, change
to signed int and get reg by reference in the parameters

Signed-off-by: Lucas Tanure 
---
 sound/soc/codecs/wm2000.c | 25 +
 1 file changed, 9 insertions(+), 16 deletions(-)

diff --git a/sound/soc/codecs/wm2000.c b/sound/soc/codecs/wm2000.c
index a67ea10..990d710 100644
--- a/sound/soc/codecs/wm2000.c
+++ b/sound/soc/codecs/wm2000.c
@@ -88,17 +88,11 @@ static int wm2000_write(struct i2c_client *i2c, unsigned 
int reg,
return regmap_write(wm2000->regmap, reg, value);
 }
 
-static unsigned int wm2000_read(struct i2c_client *i2c, unsigned int r)
+static int wm2000_read(struct i2c_client *i2c, unsigned int reg,
+   unsigned int *value)
 {
struct wm2000_priv *wm2000 = i2c_get_clientdata(i2c);
-   unsigned int val;
-   int ret;
-
-   ret = regmap_read(wm2000->regmap, r, );
-   if (ret < 0)
-   return -1;
-
-   return val;
+   return regmap_read(wm2000->regmap, reg, value);
 }
 
 static void wm2000_reset(struct wm2000_priv *wm2000)
@@ -118,11 +112,10 @@ static int wm2000_poll_bit(struct i2c_client *i2c,
int timeout = 4000;
int val;
 
-   val = wm2000_read(i2c, reg);
-
+   wm2000_read(i2c, reg, );
while (!(val & mask) && --timeout) {
msleep(1);
-   val = wm2000_read(i2c, reg);
+   wm2000_read(i2c, reg, );
}
 
if (timeout == 0)
@@ -213,7 +206,7 @@ static int wm2000_power_up(struct i2c_client *i2c, int 
analogue)
 WM2000_MODE_THERMAL_ENABLE);
}
 
-   ret = wm2000_read(i2c, WM2000_REG_SPEECH_CLARITY);
+   wm2000_read(i2c, WM2000_REG_SPEECH_CLARITY, );
if (wm2000->speech_clarity)
ret |= WM2000_SPEECH_CLARITY;
else
@@ -858,9 +851,9 @@ static int wm2000_i2c_probe(struct i2c_client *i2c,
}
 
/* Verify that this is a WM2000 */
-   reg = wm2000_read(i2c, WM2000_REG_ID1);
+   wm2000_read(i2c, WM2000_REG_ID1, );
id = reg << 8;
-   reg = wm2000_read(i2c, WM2000_REG_ID2);
+   wm2000_read(i2c, WM2000_REG_ID2, );
id |= reg & 0xff;
 
if (id != 0x2000) {
@@ -869,7 +862,7 @@ static int wm2000_i2c_probe(struct i2c_client *i2c,
goto err_supplies;
}
 
-   reg = wm2000_read(i2c, WM2000_REG_REVISON);
+   wm2000_read(i2c, WM2000_REG_REVISON, );
dev_info(>dev, "revision %c\n", reg + 'A');
 
wm2000->mclk = devm_clk_get(>dev, "MCLK");
-- 
2.7.0

Re: [PATCH RESEND v2 00/19] Support fuse mounts in user namespaces

[Seth Forshee]

On Mon, Jan 04, 2016 at 12:03:39PM -0600, Seth Forshee wrote:
> These patches implement support for mounting filesystems in user
> namespaces using fuse. They are based on the patches in the for-testing
> branch of
> git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git,
> but I've rebased them onto 4.4-rc3. I've pushed all of this to:
> 
>  git://git.kernel.org/pub/scm/linux/kernel/git/sforshee/linux.git fuse-userns
> 
> The patches are organized into three high-level groups.
> 
> Patches 1-6 are related to security, adding restrictions for
> unprivileged mounts and updating the LSMs as needed. Patches 1-2
> (checking inode permissions for block device mounts) may not be strictly
> necessary for fuseblk mounts since fuse doesn't do any IO on the block
> device in the kernel, but it still seems like a good idea to fail the
> mount if the user doesn't have the required permissions for the inode
> (though this is a bit misleading with fuse since the mounts are done via
> a suid-root helper).
> 
> Patches 7-14 update most of the vfs to translate ids correctly and deal
> with inodes which may have invalid user/group ids. I've omitted patches
> for anything not used by fuse - quota, fs freezing, some helper
> functions, etc. - but if these are wanted for the sake of completeness I
> can include them.
> 
> Patches 15-18 update fuse to deal with mounts from non-init pid and user
> namespaces and enable mounting from user namespaces.
> 
> Changes since v1:
>  - Drop patch for FIBMAP.
>  - Use current_in_userns in fuse_allow_current_process.
>  - Remove checks for uid/gid validity in fuse. Intead, ids from the
>backing store which do not map into s_user_ns will result in invalid
>ids in the vfs inode. Checks in the vfs will prevent unmappable ids
>from being passed in from above.
>  - Update a couple of commit messages to provide more detail about
>changes.

Now that the merge window is over, I'm wondering whether it might be
possible to get some feedback on these patches this cycle?

Thanks,
Seth

Re: [RFC PATCH] codingstyle: improve elisp for a better experience

[Jonathan Corbet]

On Thu, 21 Jan 2016 22:18:30 -0300
"Geyslan G. Bem"  wrote:

> This patch does use of more emacs functionalities which deliver to the
> user indentation, commenting and white space highlighting.

So perhaps it's just me, but that's an awful lot of elisp code for readers
to wade through; many of those readers will not be all that interested in
it.

Can I suggest an alternative?  Make a kernel-dot-emacs.txt in a form that
interested people can pull it (nearly) directly into their .emacs files,
then add a reference to the CodingStyle document.  That makes the stuff
available for interested developers without rubbing everybody's noses in
it.  Make sense?

Thanks,

jon

sound: use-after-free in _snd_timer_stop

[Dmitry Vyukov]

Hello,

The following program causes use-after-free in  _snd_timer_stop (if
run in a parallel loop):

// autogenerated by syzkaller (http://github.com/google/syzkaller)
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

long r[53];

void* thr(void* arg)
{
  switch ((long)arg) {
  case 0:
r[0] = syscall(SYS_mmap, 0x2000ul, 0x65e000ul, 0x3ul, 0x32ul,
   0xul, 0x0ul);
break;
  case 1:
r[11] = open("/dev/snd/timer", O_RDWR);
break;
  case 2:
*(uint32_t*)0x20653000 = (uint32_t)0x0;
*(uint32_t*)0x20653004 = (uint32_t)0x2;
*(uint32_t*)0x20653008 = (uint32_t)0x0;
*(uint32_t*)0x2065300c = (uint32_t)0x0;
*(uint32_t*)0x20653010 = (uint32_t)0x0;
*(uint8_t*)0x20653014 = (uint8_t)0x0;
*(uint8_t*)0x20653015 = (uint8_t)0x0;
*(uint8_t*)0x20653016 = (uint8_t)0x0;
*(uint8_t*)0x20653017 = (uint8_t)0x0;
*(uint8_t*)0x20653018 = (uint8_t)0x0;
*(uint8_t*)0x20653019 = (uint8_t)0x0;
*(uint8_t*)0x2065301a = (uint8_t)0x0;
*(uint8_t*)0x2065301b = (uint8_t)0x0;
*(uint8_t*)0x2065301c = (uint8_t)0x0;
*(uint8_t*)0x2065301d = (uint8_t)0x0;
*(uint8_t*)0x2065301e = (uint8_t)0x0;
*(uint8_t*)0x2065301f = (uint8_t)0x0;
*(uint8_t*)0x20653020 = (uint8_t)0x0;
*(uint8_t*)0x20653021 = (uint8_t)0x0;
*(uint8_t*)0x20653022 = (uint8_t)0x0;
*(uint8_t*)0x20653023 = (uint8_t)0x0;
*(uint8_t*)0x20653024 = (uint8_t)0x0;
*(uint8_t*)0x20653025 = (uint8_t)0x0;
*(uint8_t*)0x20653026 = (uint8_t)0x0;
*(uint8_t*)0x20653027 = (uint8_t)0x0;
*(uint8_t*)0x20653028 = (uint8_t)0x0;
*(uint8_t*)0x20653029 = (uint8_t)0x0;
*(uint8_t*)0x2065302a = (uint8_t)0x0;
*(uint8_t*)0x2065302b = (uint8_t)0x0;
*(uint8_t*)0x2065302c = (uint8_t)0x0;
*(uint8_t*)0x2065302d = (uint8_t)0x0;
*(uint8_t*)0x2065302e = (uint8_t)0x0;
*(uint8_t*)0x2065302f = (uint8_t)0x0;
*(uint8_t*)0x20653030 = (uint8_t)0x0;
*(uint8_t*)0x20653031 = (uint8_t)0x0;
*(uint8_t*)0x20653032 = (uint8_t)0x0;
*(uint8_t*)0x20653033 = (uint8_t)0x0;
r[49] = syscall(SYS_ioctl, r[11], 0x40345410ul, 0x20653000ul, 0, 0, 0);
break;
  case 3:
r[50] = syscall(SYS_ioctl, r[11], 0x54a2ul, 0, 0, 0, 0);
break;
  case 4:
open("/dev/sequencer", O_RDWR);
break;
  }
  return 0;
}

int main()
{
  long i;
  pthread_t th[5];

  srand(getpid());
  memset(r, -1, sizeof(r));
  for (i = 0; i < 5; i++) {
pthread_create([i], 0, thr, (void*)i);
usleep(1);
  }
  for (i = 0; i < 5; i++) {
pthread_create([i], 0, thr, (void*)i);
if (rand()%2)
  usleep(rand()%1);
  }
  usleep(10);
  return 0;
}


BUG: KASAN: use-after-free in snd_timer_notify1+0x42b/0x460 at addr
8800331c88b8
Read of size 8 by task a.out/7186
=
BUG kmalloc-256 (Tainted: GB   W  ): kasan: bad access detected
-

INFO: Allocated in snd_timer_instance_new+0x52/0x3a0 age=105 cpu=0 pid=7291
[<  none  >] ___slab_alloc+0x4c2/0x500 mm/slub.c:2470
[<  none  >] __slab_alloc+0x66/0xc0 mm/slub.c:2499
[< inline >] slab_alloc_node mm/slub.c:2562
[< inline >] slab_alloc mm/slub.c:2604
[<  none  >] kmem_cache_alloc_trace+0x27a/0x300 mm/slub.c:2621
[< inline >] kmalloc include/linux/slab.h:463
[< inline >] kzalloc include/linux/slab.h:607
[<  none  >] snd_timer_instance_new+0x52/0x3a0 sound/core/timer.c:106
[<  none  >] snd_timer_open+0xbb/0xd20 sound/core/timer.c:251
[< inline >] snd_timer_user_tselect sound/core/timer.c:1572
[< inline >] __snd_timer_user_ioctl sound/core/timer.c:1848
[<  none  >] snd_timer_user_ioctl+0x8db/0x25f0 sound/core/timer.c:1878
[< inline >] vfs_ioctl fs/ioctl.c:43
[<  none  >] do_vfs_ioctl+0x18c/0xfb0 fs/ioctl.c:674
[< inline >] SYSC_ioctl fs/ioctl.c:689
[<  none  >] SyS_ioctl+0x8f/0xc0 fs/ioctl.c:680
[<  none  >] entry_SYSCALL_64_fastpath+0x16/0x7a
arch/x86/entry/entry_64.S:185
INFO: Freed in snd_timer_close+0x55d/0x750 age=10 cpu=0 pid=7333
[<  none  >] __slab_free+0x1fc/0x320 mm/slub.c:2680
[< inline >] slab_free mm/slub.c:2835
[<  none  >] kfree+0x2b7/0x2e0 mm/slub.c:3664
[<  none  >] snd_timer_close+0x55d/0x750 sound/core/timer.c:375
[< inline >] snd_timer_user_tselect sound/core/timer.c:1562
[< inline >] __snd_timer_user_ioctl sound/core/timer.c:1848
[<  none  >] snd_timer_user_ioctl+0x7b6/0x25f0 sound/core/timer.c:1878
[< inline >] vfs_ioctl fs/ioctl.c:43
[<  none  >] do_vfs_ioctl+0x18c/0xfb0 fs/ioctl.c:674
[< inline >] SYSC_ioctl fs/ioctl.c:689
[<  none  >] SyS_ioctl+0x8f/0xc0 fs/ioctl.c:680
[<  none  >] entry_SYSCALL_64_fastpath+0x16/0x7a
arch/x86/entry/entry_64.S:185
INFO: Slab 

[PATCH] coresight: removing bind/unbind options from sysfs

[Mathieu Poirier]

The coresight drivers have absolutely no control over bind and unbind
operations triggered from sysfs. The operations simply can't be
cancelled or denied event when one or several tracing sessions are
under way.  Since the memory associated to individual device is
invariably freed, the end result is a kernel crash when the path from
source to sink is travelled again as demonstrated here[1].

One solution could be to keep track of all the path (i.e tracing
session) that get created and iterate through the elements of those path
looking for the coresight device that is being removed.  This proposition
doesn't scale well since there is no upper bound on the amount of
concurrent trace session that can be created.

With the above in mind, this patch prevent devices from being unbounded
from their driver by using the driver->suppress_bind_attr option.  That way
trace sessions can be managed without fearing to loose devices.

Since device can't be removed anymore the xyz_remove() functions found in
each driver is also removed.

[1]. http://www.spinics.net/lists/arm-kernel/msg474952.html

Reported-by: Rabin Vincent 
Signed-off-by: Mathieu Poirier 
---
 drivers/hwtracing/coresight/coresight-etb10.c   | 11 +--
 drivers/hwtracing/coresight/coresight-etm3x.c   | 13 +
 drivers/hwtracing/coresight/coresight-etm4x.c   | 13 +
 drivers/hwtracing/coresight/coresight-funnel.c  | 10 +-
 drivers/hwtracing/coresight/coresight-replicator-qcom.c | 11 +--
 drivers/hwtracing/coresight/coresight-replicator.c  | 16 +---
 drivers/hwtracing/coresight/coresight-tmc.c | 15 +--
 drivers/hwtracing/coresight/coresight-tpiu.c| 10 +-
 8 files changed, 8 insertions(+), 91 deletions(-)

diff --git a/drivers/hwtracing/coresight/coresight-etb10.c 
b/drivers/hwtracing/coresight/coresight-etb10.c
index 77d0f9c1118d..92969dae739d 100644
--- a/drivers/hwtracing/coresight/coresight-etb10.c
+++ b/drivers/hwtracing/coresight/coresight-etb10.c
@@ -489,15 +489,6 @@ err_misc_register:
return ret;
 }
 
-static int etb_remove(struct amba_device *adev)
-{
-   struct etb_drvdata *drvdata = amba_get_drvdata(adev);
-
-   misc_deregister(>miscdev);
-   coresight_unregister(drvdata->csdev);
-   return 0;
-}
-
 #ifdef CONFIG_PM
 static int etb_runtime_suspend(struct device *dev)
 {
@@ -537,10 +528,10 @@ static struct amba_driver etb_driver = {
.name   = "coresight-etb10",
.owner  = THIS_MODULE,
.pm = _dev_pm_ops,
+   .suppress_bind_attrs = true,
 
},
.probe  = etb_probe,
-   .remove = etb_remove,
.id_table   = etb_ids,
 };
 
diff --git a/drivers/hwtracing/coresight/coresight-etm3x.c 
b/drivers/hwtracing/coresight/coresight-etm3x.c
index d630b7ece735..5981fcc69960 100644
--- a/drivers/hwtracing/coresight/coresight-etm3x.c
+++ b/drivers/hwtracing/coresight/coresight-etm3x.c
@@ -1877,17 +1877,6 @@ err_arch_supported:
return ret;
 }
 
-static int etm_remove(struct amba_device *adev)
-{
-   struct etm_drvdata *drvdata = amba_get_drvdata(adev);
-
-   coresight_unregister(drvdata->csdev);
-   if (--etm_count == 0)
-   unregister_hotcpu_notifier(_cpu_notifier);
-
-   return 0;
-}
-
 #ifdef CONFIG_PM
 static int etm_runtime_suspend(struct device *dev)
 {
@@ -1948,9 +1937,9 @@ static struct amba_driver etm_driver = {
.name   = "coresight-etm3x",
.owner  = THIS_MODULE,
.pm = _dev_pm_ops,
+   .suppress_bind_attrs = true,
},
.probe  = etm_probe,
-   .remove = etm_remove,
.id_table   = etm_ids,
 };
 
diff --git a/drivers/hwtracing/coresight/coresight-etm4x.c 
b/drivers/hwtracing/coresight/coresight-etm4x.c
index 1ec6798b21e8..0edc10b44004 100644
--- a/drivers/hwtracing/coresight/coresight-etm4x.c
+++ b/drivers/hwtracing/coresight/coresight-etm4x.c
@@ -2684,17 +2684,6 @@ err_coresight_register:
return ret;
 }
 
-static int etm4_remove(struct amba_device *adev)
-{
-   struct etmv4_drvdata *drvdata = amba_get_drvdata(adev);
-
-   coresight_unregister(drvdata->csdev);
-   if (--etm4_count == 0)
-   unregister_hotcpu_notifier(_cpu_notifier);
-
-   return 0;
-}
-
 static struct amba_id etm4_ids[] = {
{   /* ETM 4.0 - Qualcomm */
.id = 0x0003b95d,
@@ -2712,9 +2701,9 @@ static struct amba_id etm4_ids[] = {
 static struct amba_driver etm4x_driver = {
.drv = {
.name   = "coresight-etm4x",
+   .suppress_bind_attrs = true,
},
.probe  = etm4_probe,
-   .remove = etm4_remove,
.id_table   = etm4_ids,
 };
 
diff --git a/drivers/hwtracing/coresight/coresight-funnel.c 

Re: [PATCH v4 4/4] iio: health: Add driver for the TI AFE4403 heart monitor

[Peter Meerwald-Stadler]

> Add driver for the TI AFE4403 heart rate monitor and pulse oximeter.
> This device detects reflected LED light fluctuations and presents an ADC
> value to the user space for further signal processing.

some comments below
 
> Data sheet located here:
> http://www.ti.com/product/AFE4403/datasheet
> 
> Signed-off-by: Andrew F. Davis 
> ---
>  drivers/iio/health/Kconfig   |  12 +
>  drivers/iio/health/Makefile  |   1 +
>  drivers/iio/health/afe4403.c | 698 
> +++
>  3 files changed, 711 insertions(+)
>  create mode 100644 drivers/iio/health/afe4403.c
> 
> diff --git a/drivers/iio/health/Kconfig b/drivers/iio/health/Kconfig
> index 632a14b..f0c1977 100644
> --- a/drivers/iio/health/Kconfig
> +++ b/drivers/iio/health/Kconfig
> @@ -7,6 +7,18 @@ menu "Health Sensors"
>  
>  menu "Heart Rate Monitors"
>  
> +config AFE4403
> + tristate "TI AFE4403 Heart Rate Monitor"
> + depends on SPI_MASTER
> + select IIO_BUFFER
> + select IIO_TRIGGERED_BUFFER
> + help
> +   Say yes to choose the Texas Instruments AFE4403
> +   heart rate monitor and low-cost pulse oximeter.
> +
> +   To compile this driver as a module, choose M here: the
> +   module will be called afe4403.
> +
>  config AFE4404
>   tristate "TI AFE4404 heart rate and pulse oximeter sensor"
>   depends on I2C
> diff --git a/drivers/iio/health/Makefile b/drivers/iio/health/Makefile
> index b37c0d5..9955a2a 100644
> --- a/drivers/iio/health/Makefile
> +++ b/drivers/iio/health/Makefile
> @@ -4,5 +4,6 @@
>  
>  # When adding new entries keep the list in alphabetical order
>  
> +obj-$(CONFIG_AFE4403)+= afe4403.o
>  obj-$(CONFIG_AFE4404)+= afe4404.o
>  obj-$(CONFIG_MAX30100)   += max30100.o
> diff --git a/drivers/iio/health/afe4403.c b/drivers/iio/health/afe4403.c
> new file mode 100644
> index 000..2c8565f
> --- /dev/null
> +++ b/drivers/iio/health/afe4403.c
> @@ -0,0 +1,698 @@
> +/*
> + * AFE4403 Heart Rate Monitors and Low-Cost Pulse Oximeters
> + *
> + * Copyright (C) 2015 Texas Instruments Incorporated - http://www.ti.com/
> + *   Andrew F. Davis 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful, but
> + * WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * General Public License for more details.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "afe440x.h"
> +
> +#define AFE4403_DRIVER_NAME  "afe4403"
> +
> +/* AFE4403 Registers */
> +#define AFE4403_TIAGAIN  0x20
> +#define AFE4403_TIA_AMB_GAIN 0x21
> +
> +/* AFE4403 GAIN register fields */
> +#define AFE4403_TIAGAIN_RES_MASK GENMASK(2, 0)
> +#define AFE4403_TIAGAIN_RES_SHIFT0
> +#define AFE4403_TIAGAIN_CAP_MASK GENMASK(7, 3)
> +#define AFE4403_TIAGAIN_CAP_SHIFT3
> +
> +/* AFE4403 LEDCNTRL register fields */
> +#define AFE440X_LEDCNTRL_LED1_MASK   GENMASK(15, 8)

if these defines are generic for AFE440X, they should go to the header 
file; if not, they should be named AFE4403

> +#define AFE440X_LEDCNTRL_LED1_SHIFT  8
> +#define AFE440X_LEDCNTRL_LED2_MASK   GENMASK(7, 0)
> +#define AFE440X_LEDCNTRL_LED2_SHIFT  0
> +#define AFE440X_LEDCNTRL_LED_RANGE_MASK  GENMASK(17, 16)
> +#define AFE440X_LEDCNTRL_LED_RANGE_SHIFT 16
> +
> +/* AFE4403 CONTROL2 register fields */
> +#define AFE440X_CONTROL2_PWR_DWN_TX  BIT(2)
> +#define AFE440X_CONTROL2_EN_SLOW_DIAGBIT(8)
> +#define AFE440X_CONTROL2_DIAG_OUT_TRIBIT(10)
> +#define AFE440X_CONTROL2_TX_BRDG_MOD BIT(11)
> +#define AFE440X_CONTROL2_TX_REF_MASK GENMASK(18, 17)
> +#define AFE440X_CONTROL2_TX_REF_SHIFT17
> +
> +/* AFE4404 NULL fields */
> +#define NULL_MASK0
> +#define NULL_SHIFT   0

needed? prefix?

> +
> +/* AFE4403 LEDCNTRL values */
> +#define AFE440X_LEDCNTRL_RANGE_TX_HALF   0x1
> +#define AFE440X_LEDCNTRL_RANGE_TX_FULL   0x2
> +#define AFE440X_LEDCNTRL_RANGE_TX_OFF0x3
> +
> +/* AFE4403 CONTROL2 values */
> +#define AFE440X_CONTROL2_TX_REF_025  0x0
> +#define AFE440X_CONTROL2_TX_REF_050  0x1
> +#define AFE440X_CONTROL2_TX_REF_100  0x2
> +#define AFE440X_CONTROL2_TX_REF_075  0x3
> +
> +/* AFE4403 CONTROL3 values */
> +#define AFE440X_CONTROL3_CLK_DIV_2   0x0

AFE440X (then move to .h) or AFE4403?

> +#define AFE440X_CONTROL3_CLK_DIV_4   0x2
> +#define AFE440X_CONTROL3_CLK_DIV_6   0x3
> +#define AFE440X_CONTROL3_CLK_DIV_8   0x4
> +#define AFE440X_CONTROL3_CLK_DIV_12  0x5
> +#define 

Re: [PATCH v3] watchdog: Add watchdog timer support for the WinSystems EBC-C384

[Guenter Roeck]

On 01/25/2016 03:36 PM, William Breathitt Gray wrote:

On 01/25/2016 03:42 PM, Guenter Roeck wrote:

On 01/25/2016 11:28 AM, One Thousand Gnomes wrote:

If ask for 299 seconds surely I should get 300 not 240 ?
(Whether to round off or round up is an interesting question for the
middle range - does it go off early or late - I'd have said late but...)



Matter of endless discussion. Some argue that the value should be rounded
up, some argue that it should be rounded down, some argue that it should
be rounded to the closest match. Each camp has its own valid arguments.
I usually leave it up to the driver's author to decide, with a slight
preference to never select a value larger than requested.


I implemented it to round down simply because it was the simplest
solution (i.e. integer truncation). Although I see merit in an
implementation that rounds to the closest valid value, I'll keep the
current implementation for now due to its simplicity; if enough users of
the driver prefer a different implementation, then I'll add it in a
later patch.


Is there no ACPI entry for it ?


Same here. As long as the board is identified, I tend to leave it up
to the driver author to decide _how_ to identify it.

Only question for me would be if the watchdog timer is implemented
in a Super-IO chip, and if so, if it would be possible to use the chip
identification instead of a DMI (or ACPI) entry to instantiate the driver.


I do not believe there is an ACPI entry for it. Interestingly, the
watchdog timer BIOS configuration option for this motherboard is listed
under the Super I/O menu; perhaps this watchdog timer is implemented in
the Super I/O chip.


Normally it is. Question is which one.


The manual for this motherboard does not provide much information about
the Super I/O chip (no model number, etc.), and neither sensors-detect
nor superiotool was able to detect it. I've sent an email to the
motherboard company (WinSystems) requesting further information about
the Super I/O chip and whether the watchdog timer is built-in to the
Super I/O chip.



Ah, I somehow thought you were associated with WinSystems, since you know
how to configure the chip.

Did you get any useful output from sensors-detect or superiotool
(like 'unknown chip '), or did those tools find nothing ?

Thanks,
Guenter

[PATCH] video: fbdev: mxsfb: fix pixelclock polarity

[Stefan Agner]

The PIXDATA flags of the display_flags enum are controller centric,
e.g. NEGEDGE means the controller shall drive the data signals on
pixelclocks negative edge. However, the drivers flag is display
centric: Sample the data on negative (falling) edge.

Therefore, change the if statement to check for the POSEDGE flag
(which is typically not set):
Drive on positive edge => sample on negative edge

Signed-off-by: Stefan Agner 
---
Hi all

Shawn, I would like to have at least your Ack on this before merge.

It seems that this has been wrong since the driver is able to use
the timings from the device tree, introduced with 669406534b4a
("video: mxsfb: get display timings from device tree").

Not sure how many device trees actually specify the wrong pixel clock
polarity due to that. At least the initial flag convertion from the
old platform data structures done with 0d9f8217db15 ("ARM: mxs: move
display timing configurations into device tree") seems to be affected
and would need to be changed accordingly...

Not sure how we should handle this, maybe just invert all
pixelclk-active properties where the mxsfb driver is in use...?

--
Stefan

 drivers/video/fbdev/mxsfb.c | 13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/drivers/video/fbdev/mxsfb.c b/drivers/video/fbdev/mxsfb.c
index 4e6608c..38898a9 100644
--- a/drivers/video/fbdev/mxsfb.c
+++ b/drivers/video/fbdev/mxsfb.c
@@ -150,7 +150,7 @@
 #define STMLCDIF_24BIT 3 /** pixel data bus to the display is of 24 bit width 
*/
 
 #define MXSFB_SYNC_DATA_ENABLE_HIGH_ACT(1 << 6)
-#define MXSFB_SYNC_DOTCLK_FALLING_ACT  (1 << 7) /* negtive edge sampling */
+#define MXSFB_SYNC_DOTCLK_FALLING_ACT  (1 << 7) /* negative edge sampling */
 
 enum mxsfb_devtype {
MXSFB_V3,
@@ -788,7 +788,16 @@ static int mxsfb_init_fbinfo_dt(struct mxsfb_info *host,
 
if (vm.flags & DISPLAY_FLAGS_DE_HIGH)
host->sync |= MXSFB_SYNC_DATA_ENABLE_HIGH_ACT;
-   if (vm.flags & DISPLAY_FLAGS_PIXDATA_NEGEDGE)
+
+   /*
+* The PIXDATA flags of the display_flags enum are controller
+* centric, e.g. NEGEDGE means drive data on negative edge.
+* However, the drivers flag is display centric: Sample the
+* data on negative (falling) edge. Therefore, check for the
+* POSEDGE flag:
+* drive on positive edge => sample on negative edge
+*/
+   if (vm.flags & DISPLAY_FLAGS_PIXDATA_POSEDGE)
host->sync |= MXSFB_SYNC_DOTCLK_FALLING_ACT;
 
 put_display_node:
-- 
2.7.0

Re: [kernel-hardening] [RFC][PATCH 3/3] mm/page_poisoning.c: Allow for zero poisoning

[Laura Abbott]

On 01/25/2016 02:05 PM, Kees Cook wrote:

On Mon, Jan 25, 2016 at 12:16 PM, Dave Hansen  wrote:

Thanks for doing this!  It all looks pretty straightforward.

On 01/25/2016 08:55 AM, Laura Abbott wrote:

By default, page poisoning uses a poison value (0xaa) on free. If this
is changed to 0, the page is not only sanitized but zeroing on alloc
with __GFP_ZERO can be skipped as well. The tradeoff is that detecting
corruption from the poisoning is harder to detect. This feature also
cannot be used with hibernation since pages are not guaranteed to be
zeroed after hibernation.


Ugh, that's a good point about hibernation.  I'm not sure how widely it
gets used but it does look pretty widely enabled in distribution kernels.

Is this something that's fixable?  It seems like we could have the
hibernation code run through and zero all the free lists.  Or, we could
just disable the optimization at runtime when a hibernation is done.


We can also make hibernation run-time disabled when poisoning is used
(similar to how kASLR disables it).



I'll look into the approach kASLR uses to disable hibernation although
having the hibernation code zero the memory could be useful as well.
We can see if there are actual complaints.
 

Not that we _have_ to do any of this now, but if a runtime knob (like a
sysctl) could be fun too.  I would be nice for folks to turn it on and
off if they wanted the added security of "real" poisoning vs. the
potential performance boost from this optimization.


+static inline bool should_zero(void)
+{
+ return !IS_ENABLED(CONFIG_PAGE_POISONING_ZERO) ||
+ !page_poisoning_enabled();
+}


I wonder if calling this "free_pages_prezeroed()" would make things a
bit more clear when we use it in prep_new_page().



Yes that sounds much better


  static int prep_new_page(struct page *page, unsigned int order, gfp_t 
gfp_flags,
   int alloc_flags)
  {
@@ -1401,7 +1407,7 @@ static int prep_new_page(struct page *page, unsigned int 
order, gfp_t gfp_flags,
   kernel_map_pages(page, 1 << order, 1);
   kasan_alloc_pages(page, order);

- if (gfp_flags & __GFP_ZERO)
+ if (should_zero() && gfp_flags & __GFP_ZERO)
   for (i = 0; i < (1 << order); i++)
   clear_highpage(page + i);


It's probably also worth pointing out that this can be a really nice
feature to have in virtual machines where memory is being deduplicated.
  As it stands now, the free lists end up with gunk in them and tend not
to be easy to deduplicate.  This patch would fix that.


Interesting, do you have any benchmarks I could test?



Oh, good point!

-Kees

Re: [PATCH v7 04/10] mfd: axp20x: Add missing copyright notice

[Chen-Yu Tsai]

On Mon, Jan 25, 2016 at 10:39 PM, Lee Jones  wrote:
> On Wed, 13 Jan 2016, Chen-Yu Tsai wrote:
>
>> When the driver was merged, the original author did not include a proper
>> copyright notice. This patch adds the notice, backdated to when the
>> driver was merged.
>
> This is very wordy.
>
> "Supply a backdated copyright notice."

Fine with me. Would you like me to send another version?

ChenYu

>> Cc: Carlo Caione 
>> Signed-off-by: Chen-Yu Tsai 
>> ---
>>
>> New patch in v7.
>>
>> ---
>>  drivers/mfd/axp20x.c | 2 ++
>>  1 file changed, 2 insertions(+)
>
> Patch looks fine though:
>
> Acked-by: Lee Jones 
>
>> diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
>> index 3e186f2dcac3..cec51e689d1d 100644
>> --- a/drivers/mfd/axp20x.c
>> +++ b/drivers/mfd/axp20x.c
>> @@ -5,6 +5,8 @@
>>   * converters, LDOs, multiple 12-bit ADCs of voltage, current and 
>> temperature
>>   * as well as configurable GPIOs.
>>   *
>> + * Copyright (C) 2014 Carlo Caione
>> + *
>>   * Author: Carlo Caione 
>>   *
>>   * This program is free software; you can redistribute it and/or modify
>
> --
> Lee Jones
> Linaro STMicroelectronics Landing Team Lead
> Linaro.org │ Open source software for ARM SoCs
> Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH] Revert "Staging: panel: usleep_range is preferred over udelay"

[Dan Carpenter]

On Tue, Jan 26, 2016 at 08:32:48AM +0800, Huang, Ying wrote:
> Dan Carpenter  writes:
> 
> > On Mon, Jan 25, 2016 at 03:13:21PM +0530, Sudip Mukherjee wrote:
> >> Apart from the mail which Ying Huang sent to me last week for another error
> >> (which actually turned out to be this one), i saw the first report by
> >> Ying Huang on November.
> >> https://lkml.org/lkml/2015/11/2/93
> >
> > Ying, could you CC the subsystem list for these reports?  This one was
> > CC'd to Sirnam, Greg and LKML.  Sirnam is too new to understand what
> > they mean, Greg is too busy, and only Sudip and Alan Cox read LKML.
> 
> Sure.  But what is the best way to find the subsystem list for a patch?
> Now we use author, committer, and the xxx-by: and Cc: list in patch to
> find the recipient.

For this one it's simple.  Get the filename from the git commit and
use ./scripts/get_maintainer.pl -f $file.  That should work generally,
the only issue is maybe some patches affect things across subsystems.

Also I don't know if netdev wants these emails?  Do you guys CC them on
0day warnings?

regards,
dan carpenter

[RESEND][PATCH 2/2] devicetree: Add DTS file to support the Nexus7 2013 (flo) device.

[John Stultz]

This patch adds a dts file to support the Nexus7 2013
device. Its based off of the qcom-apq8064-ifc6410.dts
which is similar hardware.

Also includes some comments and context folded in
from Vinay Simha BN 

Cc: Rob Herring 
Cc: Arnd Bergmann 
Cc: Pawel Moll 
Cc: Mark Rutland 
Cc: Ian Campbell 
Cc: Kumar Gala 
Cc: Andy Gross 
Cc: Russell King 
Cc: Vinay Simha BN 
Cc: Bjorn Andersson 
Cc: devicet...@vger.kernel.org
Signed-off-by: John Stultz 
---
 arch/arm/boot/dts/Makefile |   1 +
 arch/arm/boot/dts/qcom-apq8064-asus-nexus7-flo.dts | 276 +
 2 files changed, 277 insertions(+)
 create mode 100644 arch/arm/boot/dts/qcom-apq8064-asus-nexus7-flo.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index a4a6d70..5b16715 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -524,6 +524,7 @@ dtb-$(CONFIG_ARCH_QCOM) += \
qcom-apq8064-cm-qs600.dtb \
qcom-apq8064-ifc6410.dtb \
qcom-apq8064-sony-xperia-yuga.dtb \
+   qcom-apq8064-asus-nexus7-flo.dts \
qcom-apq8074-dragonboard.dtb \
qcom-apq8084-ifc6540.dtb \
qcom-apq8084-mtp.dtb \
diff --git a/arch/arm/boot/dts/qcom-apq8064-asus-nexus7-flo.dts 
b/arch/arm/boot/dts/qcom-apq8064-asus-nexus7-flo.dts
new file mode 100644
index 000..c535b3f
--- /dev/null
+++ b/arch/arm/boot/dts/qcom-apq8064-asus-nexus7-flo.dts
@@ -0,0 +1,276 @@
+#include "qcom-apq8064-v2.0.dtsi"
+#include 
+#include 
+#include 
+/ {
+   model = "Asus Nexus7(flo)";
+   compatible = "asus,nexus7-flo", "qcom,apq8064";
+
+   aliases {
+   serial0 = _serial;
+   serial1 = _serial;
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+
+   ext_3p3v: regulator-fixed@1 {
+   compatible = "regulator-fixed";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   regulator-name = "ext_3p3v";
+   regulator-type = "voltage";
+   startup-delay-us = <0>;
+   gpio = <_pinmux 77 GPIO_ACTIVE_HIGH>;
+   enable-active-high;
+   regulator-boot-on;
+   };
+
+   gpio-keys {
+   compatible = "gpio-keys";
+   power {
+   label = "Power";
+   gpios = <_pinmux 26 GPIO_ACTIVE_LOW>;
+   linux,code = ;
+   gpio-key,wakeup;
+   };
+   volume_up {
+   label = "Volume Up";
+   gpios = <_gpio 4 GPIO_ACTIVE_HIGH>;
+   linux,code = ;
+   };
+   volume_down {
+   label = "Volume Down";
+   gpios = <_gpio 38 GPIO_ACTIVE_HIGH>;
+   linux,code = ;
+   };
+   };
+
+   soc {
+   rpm@108000 {
+   regulators {
+   vdd_l1_l2_l12_l18-supply = <_s4>;
+   vin_lvs1_3_6-supply = <_s4>;
+   vin_lvs4_5_7-supply = <_s4>;
+
+
+   vdd_l24-supply = <_s1>;
+   vdd_l25-supply = <_s1>;
+   vin_lvs2-supply = <_s1>;
+
+   vdd_l26-supply = <_s7>;
+   vdd_l27-supply = <_s7>;
+   vdd_l28-supply = <_s7>;
+
+   vdd_ncp-supply = <_l6>;
+
+   /* Buck SMPS */
+   s1 {
+   regulator-always-on;
+   regulator-min-microvolt = <1225000>;
+   regulator-max-microvolt = <1225000>;
+   qcom,switch-mode-frequency = <320>;
+   bias-pull-down;
+   };
+
+   /* msm otg HSUSB_VDDCX */
+   s3 {
+   regulator-min-microvolt = <50>;
+   regulator-max-microvolt = <115>;
+   qcom,switch-mode-frequency = <480>;
+   };
+
+   /*
+* msm_sdcc.1-sdc-vdd_io
+* tabla2x-slim-CDC_VDDA_RX
+* tabla2x-slim-CDC_VDDA_TX
+* tabla2x-slim-CDC_VDD_CP
+