Re: [PATCH] parisc: Switch to generic COMPAT_BINFMT_ELF

[Guenter Roeck]

On Fri, Apr 13, 2018 at 09:54:37PM +0200, Helge Deller wrote:
> * Guenter Roeck :
> > On Wed, Apr 11, 2018 at 09:09:53AM +0200, Helge Deller wrote:
> > > Drop our own compat binfmt implementation in
> > > arch/parisc/kernel/binfmt_elf32.c in favour of the generic
> > > implementation with CONFIG_COMPAT_BINFMT_ELF.
> > > 
> > > While cleaning up the dependencies, I noticed that ELF_PLATFORM was 
> > > strangely
> > > defined: On a 32-bit kernel, it was defined to "PARISC", while when 
> > > running in
> > > compat mode on a 64-bit kernel it was defined to "PARISC32". Since it 
> > > doesn't
> > > seem to be used in glibc yet, it's now defined in both cases to "PARISC". 
> > > In
> > > any case, it can be distinguished because it's either a 32-bit or a 
> > > 64-bit ELF
> > > file.
> > > 
> > > Signed-off-by: Helge Deller 
> > 
> > This patch results in:
> > 
> > Building parisc:a500_defconfig ... failed
> > --
> > Error log:
> > make[2]: *** No rule to make target 'arch/parisc/kernel/binfmt_elf32.o', 
> > needed
> > by 'arch/parisc/kernel/built-in.a'.  Stop.
> > make[2]: *** Waiting for unfinished jobs
> > make[1]: *** [arch/parisc/kernel] Error 2
> > make[1]: *** Waiting for unfinished jobs
> > make: *** [sub-make] Error 2
> > --
> > Building parisc:generic-64bit_defconfig ... failed
> > --
> > Error log:
> > make[2]: *** No rule to make target 'arch/parisc/kernel/binfmt_elf32.o', 
> > needed
> > by 'arch/parisc/kernel/built-in.a'.  Stop.
> > 
> > Indeed, arch/parisc/kernel/binfmt_elf32.o is still listed in Makefile
> > for 64-bit builds.
> > 
> > $ git grep binfmt_elf32.o arch/parisc/
> > arch/parisc/kernel/Makefile:obj-$(CONFIG_64BIT) += binfmt_elf32.o 
> > sys_parisc32.o signal32.o
> 
> You are right.
> I got fooled because I still had the binfmt_elf32.o object in my build
> directory and so I didn't faced this build error. And even 0-day builds
> didn't complained...  
> 
> Thanks for testing!
> 
> Patch below fixes it.
> 
> Helge
> ---
> 
> [PATCH] parisc: Fix missing binfmt_elf32.o build error
> 
> Commit 71d577db01a5 ("parisc: Switch to generic COMPAT_BINFMT_ELF")
> removed the binfmt_elf32.c source file, but missed to drop the object
> file from list of object files the Makefile too, which then results in a
> build error.
> 
> Fixes: 71d577db01a5 ("parisc: Switch to generic COMPAT_BINFMT_ELF")
> Reported-by: Guenter Roeck 
> Signed-off-by: Helge Deller 

Tested-by: Guenter Roeck 

> 
> 
> diff --git a/arch/parisc/kernel/Makefile b/arch/parisc/kernel/Makefile
> index eafd06a..e5de34d 100644
> --- a/arch/parisc/kernel/Makefile
> +++ b/arch/parisc/kernel/Makefile
> @@ -23,7 +23,7 @@ obj-$(CONFIG_SMP)   += smp.o
>  obj-$(CONFIG_PA11)   += pci-dma.o
>  obj-$(CONFIG_PCI)+= pci.o
>  obj-$(CONFIG_MODULES)+= module.o
> -obj-$(CONFIG_64BIT)  += binfmt_elf32.o sys_parisc32.o signal32.o
> +obj-$(CONFIG_64BIT)  += sys_parisc32.o signal32.o
>  obj-$(CONFIG_STACKTRACE)+= stacktrace.o
>  obj-$(CONFIG_AUDIT)  += audit.o
>  obj64-$(CONFIG_AUDIT)+= compat_audit.o

Re: [PATCH] sched: support dynamiQ cluster

[Joel Fernandes (Google)]

On Fri, Apr 6, 2018 at 5:58 AM, Morten Rasmussen
 wrote:
> On Thu, Apr 05, 2018 at 06:22:48PM +0200, Vincent Guittot wrote:
>> Hi Morten,
>>
>> On 5 April 2018 at 17:46, Morten Rasmussen  wrote:
>> > On Wed, Apr 04, 2018 at 03:43:17PM +0200, Vincent Guittot wrote:
>> >> On 4 April 2018 at 12:44, Valentin Schneider  
>> >> wrote:
>> >> > Hi,
>> >> >
>> >> > On 03/04/18 13:17, Vincent Guittot wrote:
>> >> >> Hi Valentin,
>> >> >>
>> >> > [...]
>> >> >>>
>> >> >>> I believe ASYM_PACKING behaves better here because the workload is 
>> >> >>> only
>> >> >>> sysbench threads. As stated above, since task utilization is 
>> >> >>> disregarded, I
>> >> >>
>> >> >> It behaves better because it doesn't wait for the task's utilization
>> >> >> to reach a level before assuming the task needs high compute capacity.
>> >> >> The utilization gives an idea of the running time of the task not the
>> >> >> performance level that is needed
>> >> >>
>> >> >
>> >> > [
>> >> > That's my point actually. ASYM_PACKING disregards utilization and moves 
>> >> > those
>> >> > threads to the big cores ASAP, which is good here because it's just 
>> >> > sysbench
>> >> > threads.
>> >> >
>> >> > What I meant was that if the task composition changes, IOW we mix 
>> >> > "small"
>> >> > tasks (e.g. periodic stuff) and "big" tasks (performance-sensitive 
>> >> > stuff like
>> >> > sysbench threads), we shouldn't assume all of those require to run on a 
>> >> > big
>> >> > CPU. The thing is, ASYM_PACKING can't make the difference between 
>> >> > those, so
>> > [Morten]
>> >>
>> >> That's the 1st point where I tend to disagree: why big cores are only
>> >> for long running task and periodic stuff can't need to run on big
>> >> cores to get max compute capacity ?
>> >> You make the assumption that only long running tasks need high compute
>> >> capacity. This patch wants to always provide max compute capacity to
>> >> the system and not only long running task
>> >
>> > There is no way we can tell if a periodic or short-running tasks
>> > requires the compute capacity of a big core or not based on utilization
>> > alone. The utilization can only tell us if a task could potentially use
>> > more compute capacity, i.e. the utilization approaches the compute
>> > capacity of its current cpu.
>> >
>> > How we handle low utilization tasks comes down to how we define
>> > "performance" and if we care about the cost of "performance" (e.g.
>> > energy consumption).
>> >
>> > Placing a low utilization task on a little cpu should always be fine
>> > from _throughput_ point of view. As long as the cpu has spare cycles it
>>
>> [Vincent]
>> I disagree, throughput is not only a matter of spare cycle it's also a
>> matter of how fast you compute the work like with IO activity as an
>> example
>
> [Morten]
> From a cpu centric point of view it is, but I agree that from a
> application/user point of view completion time might impact throughput
> too. For example of if your throughput depends on how fast you can
> offload work to some peripheral device (GPU for example).
>
> However, as I said in the beginning we don't know what the task does.

[Joel]
Just wanted to say about Vincent point of IO loads throughput -
remembering from when I was playing with the iowait boost stuff, that
- say you have a little task that does some IO and blocks and does so
periodically. In the scenario the task will run for little time and is
a little task by way of looking at utilization. However, if we were to
run it on the BIG CPUs, the overall throughput of the I/O activity
would be higher.

For this case, it seems its impossible to specify the "default"
behavior correctly. Like, do we care about performance or energy more?
This seems more like a policy-decision from userspace and not
something the scheduler should necessarily have to decide. Like if I/O
activity is background and not affecting the user experience.

thanks,

- Joel

Re: [PATCH 1/6] fs: use << for MS_* flags

[Greg KH]

On Fri, Apr 13, 2018 at 09:45:01AM -0700, Randy Dunlap wrote:
> On 04/13/2018 09:11 AM, Christian Brauner wrote:
> > Consistenly use << to define MS_* constants.
> > 
> > Signed-off-by: Christian Brauner 
> > ---
> >  include/uapi/linux/fs.h | 33 +
> >  1 file changed, 17 insertions(+), 16 deletions(-)
> > 
> > diff --git a/include/uapi/linux/fs.h b/include/uapi/linux/fs.h
> > index d2a8313fabd7..9662790a657c 100644
> > --- a/include/uapi/linux/fs.h
> > +++ b/include/uapi/linux/fs.h
> > @@ -105,22 +105,23 @@ struct inodes_stat_t {
> >  /*
> >   * These are the fs-independent mount-flags: up to 32 flags are supported
> >   */
> > -#define MS_RDONLY   1  /* Mount read-only */
> > -#define MS_NOSUID   2  /* Ignore suid and sgid bits */
> > -#define MS_NODEV4  /* Disallow access to device special files */
> > -#define MS_NOEXEC   8  /* Disallow program execution */
> > -#define MS_SYNCHRONOUS 16  /* Writes are synced at once */
> > -#define MS_REMOUNT 32  /* Alter flags of a mounted FS */
> > -#define MS_MANDLOCK64  /* Allow mandatory locks on an FS */
> > -#define MS_DIRSYNC 128 /* Directory modifications are synchronous */
> > -#define MS_NOATIME 1024/* Do not update access times. */
> > -#define MS_NODIRATIME  2048/* Do not update directory access times 
> > */
> > -#define MS_BIND4096
> > -#define MS_MOVE8192
> > -#define MS_REC 16384
> > -#define MS_VERBOSE 32768   /* War is peace. Verbosity is silence.
> > -  MS_VERBOSE is deprecated. */
> > -#define MS_SILENT  32768
> > +#define MS_RDONLY  (1<<0)  /* Mount read-only */
> 
> Why not just use BIT(n) instead?
> 
> #include 
> 
> #define MS_RDONLY BIT(0)  /* Mount read-only */

BIT() is not exported to uapi files :(

Re: [PATCH v3 2/4] dt-bindings:power:supply: Add docs for ADP5061 battery charger

[Rob Herring]

On Wed, Apr 11, 2018 at 06:10:15PM +0300, Stefan Popa wrote:
> Document adi,adp5061 properties.
> 
> Signed-off-by: Stefan Popa 
> ---
> Changes in v3:
>   - Split devicetree bindings into a separate patch.
> 
>  .../devicetree/bindings/power/supply/adp5061.txt| 17 
> +
>  MAINTAINERS |  1 +
>  2 files changed, 18 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/power/supply/adp5061.txt
> 
> diff --git a/Documentation/devicetree/bindings/power/supply/adp5061.txt 
> b/Documentation/devicetree/bindings/power/supply/adp5061.txt
> new file mode 100644
> index 000..7447446
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/power/supply/adp5061.txt
> @@ -0,0 +1,17 @@
> +Analog Devices ADP5061 Programmable Linear Battery Charger Driver
> +
> +Required properties:
> +  - compatible:  should be "adi,adp5061"
> +  - reg: i2c address of the device
> +
> +The node for this driver must be a child node of a I2C controller, hence
> +all mandatory properties described in
> +Documentation/devicetree/bindings/i2c/i2c.txt
> +must be specified.
> +
> +Example:
> +
> + adp5061@14 {
> + compatible = "adi,adp5061";
> + reg = <0x14>;

Same question as the last version. This seems awfully simple for a 
charger. Don't you need to know and describe battery parameters.

Rob

Re: [PATCHv4] gpio: Remove VLA from gpiolib

[Laura Abbott]

On 04/12/2018 05:39 PM, Phil Reid wrote:

On 12/04/2018 16:38, Linus Walleij wrote:

On Wed, Apr 11, 2018 at 3:03 AM, Laura Abbott  wrote:


The new challenge is to remove VLAs from the kernel
(see https://lkml.org/lkml/2018/3/7/621) to eventually
turn on -Wvla.

Using a kmalloc array is the easy way to fix this but kmalloc is still
more expensive than stack allocation. Introduce a fast path with a
fixed size stack array to cover most chip with gpios below some fixed
amount. The slow path dynamically allocates an array to cover those
chips with a large number of gpios.

Reviewed-and-tested-by: Lukas Wunner 
Signed-off-by: Lukas Wunner 
Signed-off-by: Laura Abbott 
---
v4: Changed some local variables to avoid coccinelle warnings. Added a
warning if the number of GPIOs exceeds the current fast path define.

Lukas, I kept your Tested-by because the changes were pretty minimal.
Let me know if you want to run the tests again.


This patch is starting to look really good.


+/*
+ * Number of GPIOs to use for the fast path in set array
+ */
+#define FASTPATH_NGPIO 256


There is still some comment about this.

And now that I am also tryint to think I wonder about it, we
have a global ARCH_NR_GPIOS that is typically 512.
Some archs set it up.

This define is something of an abomination, in the ARM
case it comes from arch/arm/include/asm/gpio.h
where #define ARCH_NR_GPIOS CONFIG_ARCH_NR_GPIO
where the latter is a Kconfig option that is mostly 512 for
most ARM systems.

Well, ARM looks like this:

config ARCH_NR_GPIO
 int
 default 2048 if ARCH_SOCFPGA
 default 1024 if ARCH_BRCMSTB || ARCH_SHMOBILE || ARCH_TEGRA || \
 ARCH_ZYNQ
 default 512 if ARCH_EXYNOS || ARCH_KEYSTONE || SOC_OMAP5 || \
 SOC_DRA7XX || ARCH_S3C24XX || ARCH_S3C64XX || ARCH_S5PV210
 default 416 if ARCH_SUNXI
 default 392 if ARCH_U8500
 default 352 if ARCH_VT8500
 default 288 if ARCH_ROCKCHIP
 default 264 if MACH_H4700
 default 0
 help
   Maximum number of GPIOs in the system.

   If unsure, leave the default value.

So if FASTPATH_NGPIO should be anything else than
ARCH_NR_GPIO this has to be established somewhere
as a floor or half or something, but I would just set it as
the same as ARCH_NR_GPIOS...

The main reason this define exist is for this function
from :

/* Convert between the old gpio_ and new gpiod_ interfaces */
struct gpio_desc *gpio_to_desc(unsigned gpio);

Nowadays that fact is a bit obscured since the variable is
only used when assigning the base (in the global GPIO
number space, which is what we want to get rid of but
sigh) in gpiochip_find_base() where it attempts to place
a newly allocated gpiochip in the higher region of this
numberspace since the embedded SoC GPIO base tends
to be 0, on old platforms.

So I don't know about this.

Can't we just use ARCH_NR_GPIOS?

Very few systems have more than 512 assigned global
GPIO numbers and those are FPGA experimental machines.

In the long run obviously I want to get rid of these defines
altogether and only allocate GPIO descriptos dynamically
so as you see I am reluctant to add new numberspace weirdness
around here.

Isn't that for total GPIO's in the system?
And the arrays just need to cater for max per chip?
 From what I can understand of the code which is admittedly limited.




Yeah the switch back to 256 was a mistake on my end (I think I
grabbed an incorrect version for my base). ARCH_NR_GPIOs
is the total number in the system which may be multiple
chips so yes we would be possibly allocating more space
than necessary.

unsigned long fastpath[2 * BITS_TO_LONGS(FASTPATH_NGPIO)]

unsigned long fastpath[2 * BITS_TO_LONGS(512)]
unsigned long fastpath[2 * DIV_ROUND_UP(512, 8 * sizeof(long))]

so we end up with 128 bytes on the stack total assuming I
can do math correctly. I think this a fairly reasonable
amount though, even if we are over-estimating if there are
multiple chips.

Thanks,
Laura

Re: [PATCH] Input: atmel_mxt_ts - add missing compatible strings to OF device table

[Rob Herring]

On Tue, Apr 10, 2018 at 11:53:40AM +0200, Javier Martinez Canillas wrote:
> Commit af503716ac14 ("i2c: core: report OF style module alias for devices
> registered via OF") fixed how the I2C core reports the module alias when
> devices are registered via OF.
> 
> But the atmel_mxt_ts driver only has an "atmel,maxtouch" compatible in its
> OF device ID table, so if a Device Tree is using a different one, autoload
> won't be working for the module (the matching works because the I2C device
> ID table is used as a fallback).
> 
> So add compatible strings for each of the entries in the I2C device table.
> 
> Fixes: af503716ac14 ("i2c: core: report OF style module alias for devices 
> registered via OF")
> Reported-by: Enric Balletbo i Serra 
> Signed-off-by: Javier Martinez Canillas 
> ---
> 
>  Documentation/devicetree/bindings/input/atmel,maxtouch.txt | 6 +-
>  drivers/input/touchscreen/atmel_mxt_ts.c   | 4 
>  2 files changed, 9 insertions(+), 1 deletion(-)

Reviewed-by: Rob Herring 

Re: [PATCH] fs/dcache.c: re-add cond_resched() in shrink_dcache_parent()

[Andrew Morton]

On Fri, 13 Apr 2018 13:28:23 -0700 Khazhismel Kumykov  wrote:

> shrink_dcache_parent may spin waiting for a parallel shrink_dentry_list.
> In this case we may have 0 dentries to dispose, so we will never
> schedule out while waiting for the parallel shrink_dentry_list to
> complete.
> 
> Tested that this fixes syzbot reports of stalls in shrink_dcache_parent()

Well I guess the patch is OK as a stopgap, but things seem fairly
messed up in there.  shrink_dcache_parent() shouldn't be doing a
busywait, waiting for the concurrent shrink_dentry_list().

Either we should be waiting (sleeping) for the concurrent operation to
complete or we should just bail out of shrink_dcache_parent(), perhaps
with 

if (list_empty())
break;

or similar.  Dunno.


That block comment over `struct select_data' is not a good one.  "It
returns zero iff...".  *What* returns zero?  select_collect()?  No it
doesn't, it returns an `enum d_walk_ret'.  Perhaps the comment is
trying to refer to select_data.found.  And the real interpretation of
select_data.found is, umm, hard to describe.  "Counts the number of
dentries which are on a shrink list or which were moved to the dispose
list".  Why?  What's that all about?

This code needs a bit of thought, documentation and perhaps a redo,
I suspect.

Re: [PATCH] fs/dcache.c: re-add cond_resched() in shrink_dcache_parent()

[David Rientjes]

On Fri, 13 Apr 2018, Khazhismel Kumykov wrote:

> shrink_dcache_parent may spin waiting for a parallel shrink_dentry_list.
> In this case we may have 0 dentries to dispose, so we will never
> schedule out while waiting for the parallel shrink_dentry_list to
> complete.
> 
> Tested that this fixes syzbot reports of stalls in shrink_dcache_parent()
> 
> Fixes: 32785c0539b7 ("fs/dcache.c: add cond_resched() in 
> shrink_dentry_list()")
> Reported-by: syzbot+ae80b790eb412884c...@syzkaller.appspotmail.com
> 
> Cc: Nikolay Borisov 
> Cc: Andrew Morton 
> Cc: David Rientjes 
> Cc: Alexander Viro 
> Cc: Goldwyn Rodrigues 
> Cc: Jeff Mahoney 
> Cc: Davidlohr Bueso 
> Cc: Linus Torvalds 
> Signed-off-by: Khazhismel Kumykov 

Acked-by: David Rientjes 

Re: [PATCH] rapidio: fix rio_dma_transfer error handling

[Andrew Morton]

On Fri, 13 Apr 2018 09:09:18 +0200 Ioan Nicu  wrote:

> > > And please remember to always include all information regarding
> > > end-user impact when fixing bugs.
> > > 
> > This bug fix is applicable to versions starting from v4.6
> 
> Actually, this is something I broke with my previous patch where I added a
> kref to the mport_dma_req structure. Before this patch, all the error paths
> were doing kfree(req) instead of kref_put(>refcount, dma_req_free).
> 
> Now that dma_req_free() is called, it dereferences req->dmach, which is
> initialized late in do_dma_request(), so dma_req_free() could be called
> with a NULL req->dmach in some cases.
> 
> Sorry if I did not make this clear enough in the description.

I added

Fixes: bbd876adb8c72 ("rapidio: use a reference count for struct mport_dma_req")

(correct?) and removed cc:stable.

[PATCHv3] drm/amdkfd: Remove vla

[Laura Abbott]

There's an ongoing effort to remove VLAs[1] from the kernel to eventually
turn on -Wvla. Switch to a constant value that covers all hardware.

[1] https://lkml.org/lkml/2018/3/7/621

Reviewed-by: Felix Kuehling 
Acked-by: Christian König 
Signed-off-by: Laura Abbott 
---
v3: Introduced a #define for the max value, switched to pr_err_once to
avoid log flood, switched to sizeof(array) per private suggestion.
---
 drivers/gpu/drm/amd/amdkfd/kfd_interrupt.c | 8 +---
 drivers/gpu/drm/amd/amdkfd/kfd_priv.h  | 2 ++
 2 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_interrupt.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_interrupt.c
index 035c351f47c5..db6d9336b80d 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_interrupt.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_interrupt.c
@@ -139,10 +139,12 @@ static void interrupt_wq(struct work_struct *work)
 {
struct kfd_dev *dev = container_of(work, struct kfd_dev,
interrupt_work);
+   uint32_t ih_ring_entry[KFD_MAX_RING_ENTRY_SIZE];
 
-   uint32_t ih_ring_entry[DIV_ROUND_UP(
-   dev->device_info->ih_ring_entry_size,
-   sizeof(uint32_t))];
+   if (dev->device_info->ih_ring_entry_size > sizeof(ih_ring_entry)) {
+   dev_err_once(kfd_chardev(), "Ring entry too small\n");
+   return;
+   }
 
while (dequeue_ih_ring_entry(dev, ih_ring_entry))
dev->device_info->event_interrupt_class->interrupt_wq(dev,
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_priv.h 
b/drivers/gpu/drm/amd/amdkfd/kfd_priv.h
index 96a9cc0f02c9..a90db05dfe61 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_priv.h
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_priv.h
@@ -39,6 +39,8 @@
 
 #include "amd_shared.h"
 
+#define KFD_MAX_RING_ENTRY_SIZE8
+
 #define KFD_SYSFS_FILE_MODE 0444
 
 #define KFD_MMAP_DOORBELL_MASK 0x8ull
-- 
2.14.3

[PATCHv5] gpio: Remove VLA from gpiolib

[Laura Abbott]

The new challenge is to remove VLAs from the kernel
(see https://lkml.org/lkml/2018/3/7/621) to eventually
turn on -Wvla.

Using a kmalloc array is the easy way to fix this but kmalloc is still
more expensive than stack allocation. Introduce a fast path with a
fixed size stack array to cover most chip with gpios below some fixed
amount. The slow path dynamically allocates an array to cover those
chips with a large number of gpios.

Reviewed-and-tested-by: Lukas Wunner 
Signed-off-by: Lukas Wunner 
Signed-off-by: Laura Abbott 
---
v5: Dropped some outdated comments and extra whitespace. Switched to
ARCH_NR_GPIOS per suggestion of Linus Walleij.
---
 drivers/gpio/gpiolib.c| 76 +--
 drivers/gpio/gpiolib.h|  2 +-
 include/linux/gpio/consumer.h | 10 +++---
 3 files changed, 66 insertions(+), 22 deletions(-)

diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index d66de67ef307..79ec7a29b684 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -61,6 +61,11 @@ static struct bus_type gpio_bus_type = {
.name = "gpio",
 };
 
+/*
+ * Number of GPIOs to use for the fast path in set array
+ */
+#define FASTPATH_NGPIO ARCH_NR_GPIOS
+
 /* gpio_lock prevents conflicts during gpio_desc[] table updates.
  * While any GPIO is requested, its gpio_chip is not removable;
  * each GPIO's "requested" flag serves as a lock and refcount.
@@ -399,12 +404,11 @@ static long linehandle_ioctl(struct file *filep, unsigned 
int cmd,
vals[i] = !!ghd.values[i];
 
/* Reuse the array setting function */
-   gpiod_set_array_value_complex(false,
+   return gpiod_set_array_value_complex(false,
  true,
  lh->numdescs,
  lh->descs,
  vals);
-   return 0;
}
return -EINVAL;
 }
@@ -1192,6 +1196,10 @@ int gpiochip_add_data_with_key(struct gpio_chip *chip, 
void *data,
goto err_free_descs;
}
 
+   if (chip->ngpio > FASTPATH_NGPIO)
+   chip_warn(chip, "line cnt %d is greater than fast path cnt 
%d\n",
+   chip->ngpio, FASTPATH_NGPIO);
+
gdev->label = kstrdup_const(chip->label ?: "unknown", GFP_KERNEL);
if (!gdev->label) {
status = -ENOMEM;
@@ -2662,16 +2670,28 @@ int gpiod_get_array_value_complex(bool raw, bool 
can_sleep,
 
while (i < array_size) {
struct gpio_chip *chip = desc_array[i]->gdev->chip;
-   unsigned long mask[BITS_TO_LONGS(chip->ngpio)];
-   unsigned long bits[BITS_TO_LONGS(chip->ngpio)];
+   unsigned long fastpath[2 * BITS_TO_LONGS(FASTPATH_NGPIO)];
+   unsigned long *mask, *bits;
int first, j, ret;
 
+   if (likely(chip->ngpio <= FASTPATH_NGPIO)) {
+   memset(fastpath, 0, sizeof(fastpath));
+   mask = fastpath;
+   bits = fastpath + BITS_TO_LONGS(FASTPATH_NGPIO);
+   } else {
+   mask = kcalloc(2 * BITS_TO_LONGS(chip->ngpio),
+  sizeof(*mask),
+  can_sleep ? GFP_KERNEL : GFP_ATOMIC);
+   if (!mask)
+   return -ENOMEM;
+   bits = mask + BITS_TO_LONGS(chip->ngpio);
+   }
+
if (!can_sleep)
WARN_ON(chip->can_sleep);
 
/* collect all inputs belonging to the same chip */
first = i;
-   memset(mask, 0, sizeof(mask));
do {
const struct gpio_desc *desc = desc_array[i];
int hwgpio = gpio_chip_hwgpio(desc);
@@ -2682,8 +2702,11 @@ int gpiod_get_array_value_complex(bool raw, bool 
can_sleep,
 (desc_array[i]->gdev->chip == chip));
 
ret = gpio_chip_get_multiple(chip, mask, bits);
-   if (ret)
+   if (ret) {
+   if (mask != fastpath)
+   kfree(mask);
return ret;
+   }
 
for (j = first; j < i; j++) {
const struct gpio_desc *desc = desc_array[j];
@@ -2695,6 +2718,9 @@ int gpiod_get_array_value_complex(bool raw, bool 
can_sleep,
value_array[j] = value;
trace_gpio_value(desc_to_gpio(desc), 1, value);
}
+
+   if (mask != fastpath)
+   kfree(mask);
}
return 0;
 }
@@ -2878,7 +2904,7 @@ static void gpio_chip_set_multiple(struct gpio_chip *chip,
}
 }
 
-void 

Re: [PATCH v3 1/2] dt-bindings: iio: afe: add current-sense-shunt and voltage-divider

[Rob Herring]

On Tue, Apr 10, 2018 at 05:28:01PM +0200, Peter Rosin wrote:
> An ADC is often used to measure other quantities indirectly. These
> bindings describe two cases, a current through a shunt resistor, and
> a "big" voltage measured with the help of a voltage divider.
> 
> Signed-off-by: Peter Rosin 
> ---
>  .../bindings/iio/afe/current-sense-shunt.txt   | 41 
>  .../bindings/iio/afe/voltage-divider.txt   | 45 
> ++
>  MAINTAINERS|  7 
>  3 files changed, 93 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/iio/afe/current-sense-shunt.txt
>  create mode 100644 
> Documentation/devicetree/bindings/iio/afe/voltage-divider.txt

Reviewed-by: Rob Herring 

[RFC PATCH 1/2] RISCV: Register clocksource and events correctly

[Atish Patra]

Currently, timer_probe() is called for every cpu and clocksource
is registered multiple times for each cpu which is wrong.

Probe timer only once during init and register the clock source at
that time. Move the clock event registration cpu online notification
callback. Take this opportunity to remove redundant functions as well.

Signed-off-by: Atish Patra 
---
 arch/riscv/include/asm/smp.h  |  2 +-
 arch/riscv/kernel/time.c  |  9 +---
 drivers/clocksource/riscv_timer.c | 44 ++-
 include/linux/cpuhotplug.h|  1 +
 4 files changed, 32 insertions(+), 24 deletions(-)

diff --git a/arch/riscv/include/asm/smp.h b/arch/riscv/include/asm/smp.h
index 85e4220..01b8df8 100644
--- a/arch/riscv/include/asm/smp.h
+++ b/arch/riscv/include/asm/smp.h
@@ -25,7 +25,7 @@
 #ifdef CONFIG_SMP
 
 /* SMP initialization hook for setup_arch */
-void __init init_clockevent(void);
+void init_clockevent(void);
 
 /* SMP initialization hook for setup_arch */
 void __init setup_smp(void);
diff --git a/arch/riscv/kernel/time.c b/arch/riscv/kernel/time.c
index 67709cb..bcd3e76 100644
--- a/arch/riscv/kernel/time.c
+++ b/arch/riscv/kernel/time.c
@@ -39,13 +39,6 @@ void riscv_timer_interrupt(void)
 #endif
 }
 
-void __init init_clockevent(void)
-{
-   timer_probe();
-   csr_set(sie, SIE_STIE);
-}
-
-
 static long __init timebase_frequency(void)
 {
struct device_node *cpu;
@@ -65,5 +58,5 @@ void __init time_init(void)
 {
riscv_timebase = timebase_frequency();
lpj_fine = riscv_timebase / HZ;
-   init_clockevent();
+   timer_probe();
 }
diff --git a/drivers/clocksource/riscv_timer.c 
b/drivers/clocksource/riscv_timer.c
index 59a734c..8b45af2 100644
--- a/drivers/clocksource/riscv_timer.c
+++ b/drivers/clocksource/riscv_timer.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #define MINDELTA 100
@@ -71,16 +72,6 @@ DEFINE_PER_CPU(struct clocksource, riscv_clocksource) = {
.read = rdtime,
 };
 
-void timer_riscv_init(int cpu_id,
- unsigned long riscv_timebase,
- int (*next)(unsigned long, struct clock_event_device*))
-{
-   struct clock_event_device *ce = per_cpu_ptr(_clock_event, cpu_id);
-
-   ce->cpumask = cpumask_of(cpu_id);
-   clockevents_config_and_register(ce, riscv_timebase, MINDELTA, MAXDELTA);
-}
-
 static int hart_of_timer(struct device_node *dev)
 {
u32 hart;
@@ -100,21 +91,44 @@ static u64 notrace timer_riscv_sched_read(void)
return get_cycles64();
 }
 
+static int timer_riscv_starting_cpu(unsigned int cpu)
+{
+   struct clock_event_device *ce = per_cpu_ptr(_clock_event, cpu);
+
+   ce->cpumask = cpumask_of(cpu);
+   clockevents_config_and_register(ce, riscv_timebase, MINDELTA, MAXDELTA);
+   /* Enable timer interrupt for this cpu */
+   csr_set(sie, SIE_STIE);
+
+   return 0;
+}
+
+static int timer_riscv_dying_cpu(unsigned int cpu)
+{
+   /* Disable timer interrupt for this cpu */
+   csr_clear(sie, SIE_STIE);
+
+   return 0;
+}
+
 static int __init timer_riscv_init_dt(struct device_node *n)
 {
+   int err = 0;
int cpu_id = hart_of_timer(n);
-   struct clock_event_device *ce = per_cpu_ptr(_clock_event, cpu_id);
struct clocksource *cs = per_cpu_ptr(_clocksource, cpu_id);
 
if (cpu_id == smp_processor_id()) {
clocksource_register_hz(cs, riscv_timebase);
sched_clock_register(timer_riscv_sched_read, 64, 
riscv_timebase);
 
-   ce->cpumask = cpumask_of(cpu_id);
-   clockevents_config_and_register(ce, riscv_timebase, MINDELTA, 
MAXDELTA);
+   err = cpuhp_setup_state(CPUHP_AP_RISCV_TIMER_STARTING,
+"clockevents/riscv/timer:starting",
+timer_riscv_starting_cpu, timer_riscv_dying_cpu);
+   if (err)
+   pr_err("RISCV timer register failed [%d] for cpu = 
[%d]\n",
+  err, cpu_id);
}
-
-   return 0;
+   return err;
 }
 
 TIMER_OF_DECLARE(riscv_timer, "riscv", timer_riscv_init_dt);
diff --git a/include/linux/cpuhotplug.h b/include/linux/cpuhotplug.h
index 1a32e55..c68f924 100644
--- a/include/linux/cpuhotplug.h
+++ b/include/linux/cpuhotplug.h
@@ -126,6 +126,7 @@ enum cpuhp_state {
CPUHP_AP_MARCO_TIMER_STARTING,
CPUHP_AP_MIPS_GIC_TIMER_STARTING,
CPUHP_AP_ARC_TIMER_STARTING,
+   CPUHP_AP_RISCV_TIMER_STARTING,
CPUHP_AP_KVM_STARTING,
CPUHP_AP_KVM_ARM_VGIC_INIT_STARTING,
CPUHP_AP_KVM_ARM_VGIC_STARTING,
-- 
2.7.4

[RFC PATCH 2/2] RISCV: Support cpu hotplug.

[Atish Patra]

This patch enable support for cpu hotplug in RISC-V.

In absensece of generic cpu stop functions, WFI is used
to put the cpu in low power state during offline. An IPI
is sent to bring it out of WFI during online operation.

Tested both on QEMU and HighFive Unleashed board with
4 cpus. Test result follows.

$ echo 0 > /sys/devices/system/cpu/cpu2/online
[   31.828562] CPU2: shutdown
$ cat /proc/cpuinfo
hart: 1
isa : rv64imafdc
mmu : sv39
uarch   : sifive,rocket0

hart: 3
isa : rv64imafdc
mmu : sv39
uarch   : sifive,rocket0

hart: 4
isa : rv64imafdc
mmu : sv39
uarch   : sifive,rocket0

$ echo 0 > /sys/devices/system/cpu/cpu4/online
[   52.968495] CPU4: shutdown
$ cat /proc/cpuinfo
hart: 1
isa : rv64imafdc
mmu : sv39
uarch   : sifive,rocket0

hart: 3
isa : rv64imafdc
mmu : sv39
uarch   : sifive,rocket0

$ echo 1 > /sys/devices/system/cpu/cpu4/online
[   64.298250] CPU4: online
$ cat /proc/cpuinfo
hart: 1
isa : rv64imafdc
mmu : sv39
uarch   : sifive,rocket0

hart: 3
isa : rv64imafdc
mmu : sv39
uarch   : sifive,rocket0

hart: 4
isa : rv64imafdc
mmu : sv39
uarch   : sifive,rocket0

Signed-off-by: Atish Patra 
---
 arch/riscv/Kconfig   | 11 ++-
 arch/riscv/include/asm/csr.h |  1 +
 arch/riscv/include/asm/smp.h |  9 --
 arch/riscv/kernel/head.S | 12 
 arch/riscv/kernel/process.c  |  7 +
 arch/riscv/kernel/setup.c| 17 +++
 arch/riscv/kernel/smpboot.c  | 70 ++--
 arch/riscv/kernel/traps.c|  6 ++--
 8 files changed, 123 insertions(+), 10 deletions(-)

diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 578f966..5ae307b 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -14,7 +14,6 @@ config RISCV
select CLONE_BACKWARDS
select COMMON_CLK
select GENERIC_CLOCKEVENTS
-   select GENERIC_CPU_DEVICES
select GENERIC_IRQ_SHOW
select GENERIC_PCI_IOMAP
select GENERIC_STRNCPY_FROM_USER
@@ -178,6 +177,16 @@ config NR_CPUS
depends on SMP
default "8"
 
+config HOTPLUG_CPU
+   bool "Support for hot-pluggable CPUs"
+   select GENERIC_IRQ_MIGRATION
+   help
+
+ Say Y here to experiment with turning CPUs off and on.  CPUs
+ can be controlled through /sys/devices/system/cpu.
+
+ Say N if you want to disable CPU hotplug.
+
 config CPU_SUPPORTS_32BIT_KERNEL
bool
 config CPU_SUPPORTS_64BIT_KERNEL
diff --git a/arch/riscv/include/asm/csr.h b/arch/riscv/include/asm/csr.h
index 421fa35..1baf8e0 100644
--- a/arch/riscv/include/asm/csr.h
+++ b/arch/riscv/include/asm/csr.h
@@ -54,6 +54,7 @@
 /* Interrupt Enable and Interrupt Pending flags */
 #define SIE_SSIE _AC(0x0002, UL) /* Software Interrupt Enable */
 #define SIE_STIE _AC(0x0020, UL) /* Timer Interrupt Enable */
+#define SIE_SEIE _AC(0x00200, UL) /* External Interrupt Enable */
 
 #define EXC_INST_MISALIGNED 0
 #define EXC_INST_ACCESS 1
diff --git a/arch/riscv/include/asm/smp.h b/arch/riscv/include/asm/smp.h
index 01b8df8..e78b7f1 100644
--- a/arch/riscv/include/asm/smp.h
+++ b/arch/riscv/include/asm/smp.h
@@ -25,9 +25,6 @@
 #ifdef CONFIG_SMP
 
 /* SMP initialization hook for setup_arch */
-void init_clockevent(void);
-
-/* SMP initialization hook for setup_arch */
 void __init setup_smp(void);
 
 /* Hook for the generic smp_call_function_many() routine. */
@@ -47,6 +44,12 @@ void arch_send_call_function_single_ipi(int cpu);
 /* Interprocessor interrupt handler */
 irqreturn_t handle_ipi(void);
 
+#ifdef CONFIG_HOTPLUG_CPU
+extern int __cpu_disable(void);
+extern void __cpu_die(unsigned int cpu);
+extern void cpu_play_dead(void);
+extern void boot_sec_cpu(void);
+#endif
 #endif /* CONFIG_SMP */
 
 #endif /* _ASM_RISCV_SMP_H */
diff --git a/arch/riscv/kernel/head.S b/arch/riscv/kernel/head.S
index 226eeb1..63d478d 100644
--- a/arch/riscv/kernel/head.S
+++ b/arch/riscv/kernel/head.S
@@ -149,6 +149,18 @@ relocate:
j .Lsecondary_park
 END(_start)
 
+.section .text
+.global boot_sec_cpu
+
+boot_sec_cpu:
+   /* clear all pending flags */
+   csrw sip, zero
+   /* Mask all interrupts */
+   csrw sie, zero
+   fence
+
+   tail smp_callin
+
 __PAGE_ALIGNED_BSS
/* Empty zero page */
.balign PAGE_SIZE
diff --git a/arch/riscv/kernel/process.c b/arch/riscv/kernel/process.c
index d74d4ad..c5e2234 100644
--- a/arch/riscv/kernel/process.c
+++ b/arch/riscv/kernel/process.c
@@ -42,6 +42,13 @@ void arch_cpu_idle(void)
local_irq_enable();
 }
 
+#ifdef CONFIG_HOTPLUG_CPU
+void arch_cpu_idle_dead(void)
+{
+   cpu_play_dead();
+}
+#endif
+
 void show_regs(struct pt_regs *regs)
 {
show_regs_print_info(KERN_DEFAULT);
diff --git a/arch/riscv/kernel/setup.c b/arch/riscv/kernel/setup.c
index a1d5853..4ef8a8b 100644
--- a/arch/riscv/kernel/setup.c
+++ b/arch/riscv/kernel/setup.c
@@ -81,6 +81,7 @@ 

[RFC PATCH 0/2] Fix timer initialization and Add support hotplug.

[Atish Patra]

The patch (1/2)fixes issues around timer initialization. This fix is
required for CPU hotplug to work. That's why they are clubbed into one
series. I can separate them if required.


Atish Patra (2):
  RISCV: Register clocksource and events correctly
  RISCV: Support cpu hotplug.

 arch/riscv/Kconfig| 11 +-
 arch/riscv/include/asm/csr.h  |  1 +
 arch/riscv/include/asm/smp.h  |  9 +++--
 arch/riscv/kernel/head.S  | 12 +++
 arch/riscv/kernel/process.c   |  7 
 arch/riscv/kernel/setup.c | 17 ++
 arch/riscv/kernel/smpboot.c   | 70 +--
 arch/riscv/kernel/time.c  |  9 +
 arch/riscv/kernel/traps.c |  6 ++--
 drivers/clocksource/riscv_timer.c | 44 +++-
 include/linux/cpuhotplug.h|  1 +
 11 files changed, 154 insertions(+), 33 deletions(-)

-- 
2.7.4

RE: [PATCH v1 4/7] platform: mellanox: add new ODM system types to mlx-platform

[Vadim Pasternak]

> -Original Message-
> From: Darren Hart [mailto:dvh...@infradead.org]
> Sent: Friday, April 13, 2018 7:55 PM
> To: Vadim Pasternak 
> Cc: andy.shevche...@gmail.com; gre...@linuxfoundation.org; linux-
> ker...@vger.kernel.org; platform-driver-...@vger.kernel.org; j...@resnulli.us;
> Michael Shych ; ivec...@redhat.com
> Subject: Re: [PATCH v1 4/7] platform: mellanox: add new ODM system types to
> mlx-platform
> 
> On Tue, Mar 27, 2018 at 10:02:04AM +, Vadim Pasternak wrote:
> > Patch adds new ODM systems, matched according to DMI_BOARD_NAME.
> 
> General nit. When writing your messages, please use the imperative (command)
> form. Rather than:
> 
> "Patch adds" or "It changes" use the same form you use in the subject lines:
> 
> "Add new ODM systems", "Fix struct field documentation", etc.
> 
> Again, I've been rewriting these, but as a regular contributor, this will help
> reduce the overhead of reviewing your patches - good for you, good for me :-)
> 
> > The supported ODM Ids are: VMOD0001, VMOD0002, VMOD0003,
> VMOD0004,
> > VMOD0005. It doesn't introduce new systems, but allows to ODM
> > companies to set DMI_BOARD_VENDOR and DMI_PRODUCT_NAME on their
> own.
> > It assumes that ODM company can't change DMI_BOARD_NAME.
> 
> You said "it assumes that ODM companies can't change DMI_BOARD_NAME". Is
> that an assumption, or is that how ODMs work with Mellanox?

Till now ODM companies didn't care about SMBIOS content.
But now we have two, which want to overwrite BOARD_VENDOR and 
PRODUCT_NAME (and some other fields).
System manufacturing for ODM is provided by Mellanox, so Mellanox
production team is responsible for setting all these fields.

Both don't care about BOARD_NAME and it has been closed with them,
that content of this filed will be defined by Mellanox.

> --
> Darren Hart
> VMware Open Source Technology Center

[PATCH] fs/dcache.c: re-add cond_resched() in shrink_dcache_parent()

[Khazhismel Kumykov]

shrink_dcache_parent may spin waiting for a parallel shrink_dentry_list.
In this case we may have 0 dentries to dispose, so we will never
schedule out while waiting for the parallel shrink_dentry_list to
complete.

Tested that this fixes syzbot reports of stalls in shrink_dcache_parent()

Fixes: 32785c0539b7 ("fs/dcache.c: add cond_resched() in shrink_dentry_list()")
Reported-by: syzbot+ae80b790eb412884c...@syzkaller.appspotmail.com

Cc: Nikolay Borisov 
Cc: Andrew Morton 
Cc: David Rientjes 
Cc: Alexander Viro 
Cc: Goldwyn Rodrigues 
Cc: Jeff Mahoney 
Cc: Davidlohr Bueso 
Cc: Linus Torvalds 
Signed-off-by: Khazhismel Kumykov 
---
 fs/dcache.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/fs/dcache.c b/fs/dcache.c
index 591b34500e41..3507badeb60a 100644
--- a/fs/dcache.c
+++ b/fs/dcache.c
@@ -1489,6 +1489,7 @@ void shrink_dcache_parent(struct dentry *parent)
break;
 
shrink_dentry_list();
+   cond_resched();
}
 }
 EXPORT_SYMBOL(shrink_dcache_parent);
-- 
2.17.0.484.g0c8726318c-goog



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [PATCH] lockdown: fix coordination of kernel module signature verification

[Bruno E. O. Meneguele]

On Fri, Apr 13, 2018 at 11:27:52AM -0400, Mimi Zohar wrote:
> If both IMA-appraisal and sig_enforce are enabled, then both signatures
> are currently required.  If the IMA-appraisal signature verification
> fails, it could rely on the appended signature verification; but with the
> lockdown patch set, the appended signature verification assumes that if
> IMA-appraisal is enabled, it has verified the signature.  Basically each
> signature verification method would be relying on the other to verify the
> kernel module signature.
> 
> This patch addresses the problem of requiring both kernel module signature
> verification methods, when both are enabled, by verifying just the
> appended signature.
> 
> Signed-off-by: Mimi Zohar 
> ---
>  kernel/module.c   | 4 +---
>  security/integrity/ima/ima_main.c | 7 ++-
>  2 files changed, 7 insertions(+), 4 deletions(-)
> 
> diff --git a/kernel/module.c b/kernel/module.c
> index 9c1709a05037..60861eb7bc4d 100644
> --- a/kernel/module.c
> +++ b/kernel/module.c
> @@ -2803,9 +2803,7 @@ static int module_sig_check(struct load_info *info, int 
> flags,
>   if (sig_enforce) {
>   pr_notice("%s is rejected\n", reason);
>   return -EKEYREJECTED;
> - }
> -
> - if (can_do_ima_check && is_ima_appraise_enabled())
> + } else if (can_do_ima_check && is_ima_appraise_enabled())
>   return 0;
>   if (kernel_is_locked_down(reason))
>   return -EPERM;
> diff --git a/security/integrity/ima/ima_main.c 
> b/security/integrity/ima/ima_main.c
> index 754ece08e1c6..2155b1f316a4 100644
> --- a/security/integrity/ima/ima_main.c
> +++ b/security/integrity/ima/ima_main.c
> @@ -480,6 +480,7 @@ static int read_idmap[READING_MAX_ID] = {
>  int ima_post_read_file(struct file *file, void *buf, loff_t size,
>  enum kernel_read_file_id read_id)
>  {
> + bool sig_enforce = is_module_sig_enforced();
>   enum ima_hooks func;
>   u32 secid;
>  
> @@ -490,7 +491,11 @@ int ima_post_read_file(struct file *file, void *buf, 
> loff_t size,
>   return 0;
>   }
>  
> - if (!file && read_id == READING_MODULE) /* MODULE_SIG_FORCE enabled */
> + /*
> +  * If both IMA-appraisal and appended signature verification are
> +  * enabled, rely on the appended signature verification.
> +  */
> + if (sig_enforce && read_id == READING_MODULE)
>   return 0;
>  
>   /* permit signed certs */
> -- 
> 2.7.5
> 

I agree with the solution.

Acked-by: Bruno E. O. Meneguele 


signature.asc
Description: PGP signature

[PATCH] MAINTAINERS: Adding backup maintainers for libnvdimm and DAX

[Dave Jiang]

Adding additional maintainers to libnvdimm related code and DAX.

Signed-off-by: Dave Jiang 
---
 MAINTAINERS |   15 +++
 1 file changed, 15 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 73d83416d852..958f75ad4193 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4246,6 +4246,9 @@ F:include/trace/events/fs_dax.h
 
 DEVICE DIRECT ACCESS (DAX)
 M: Dan Williams 
+M: Dave Jiang 
+M: Ross Zwisler 
+M: Vishal Verma 
 L: linux-nvd...@lists.01.org
 S: Supported
 F: drivers/dax/
@@ -8034,6 +8037,9 @@ F:tools/lib/lockdep/
 
 LIBNVDIMM BLK: MMIO-APERTURE DRIVER
 M: Ross Zwisler 
+M: Dan Williams 
+M: Vishal Verma 
+M: Dave Jiang 
 L: linux-nvd...@lists.01.org
 Q: https://patchwork.kernel.org/project/linux-nvdimm/list/
 S: Supported
@@ -8042,6 +8048,9 @@ F:drivers/nvdimm/region_devs.c
 
 LIBNVDIMM BTT: BLOCK TRANSLATION TABLE
 M: Vishal Verma 
+M: Dan Williams 
+M: Ross Zwisler 
+M: Dave Jiang 
 L: linux-nvd...@lists.01.org
 Q: https://patchwork.kernel.org/project/linux-nvdimm/list/
 S: Supported
@@ -8049,6 +8058,9 @@ F:drivers/nvdimm/btt*
 
 LIBNVDIMM PMEM: PERSISTENT MEMORY DRIVER
 M: Ross Zwisler 
+M: Dan Williams 
+M: Vishal Verma 
+M: Dave Jiang 
 L: linux-nvd...@lists.01.org
 Q: https://patchwork.kernel.org/project/linux-nvdimm/list/
 S: Supported
@@ -8064,6 +8076,9 @@ F:
Documentation/devicetree/bindings/pmem/pmem-region.txt
 
 LIBNVDIMM: NON-VOLATILE MEMORY DEVICE SUBSYSTEM
 M: Dan Williams 
+M: Ross Zwisler 
+M: Vishal Verma 
+M: Dave Jiang 
 L: linux-nvd...@lists.01.org
 Q: https://patchwork.kernel.org/project/linux-nvdimm/list/
 T: git git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm.git

Re: [PATCH] x86/cpufeature: guard asm_volatile_goto usage with CC_HAVE_ASM_GOTO

[Alexei Starovoitov]

On 4/13/18 11:19 AM, Peter Zijlstra wrote:

On Tue, Apr 10, 2018 at 02:28:04PM -0700, Alexei Starovoitov wrote:

Instead of
#ifdef CC_HAVE_ASM_GOTO
we can replace it with
#ifndef __BPF__
or some other name,


I would prefer the BPF specific hack; otherwise we might be encouraging
people to build the kernel proper without asm-goto.



I don't understand this concern.

1.
arch/x86/Makefile does
ifndef CC_HAVE_ASM_GOTO
  $(error Compiler lacks asm-goto support.)
endif

which is pretty strong statement of the kernel direction.

2.
Even with this patch that adds #ifdef CC_HAVE_ASM_GOTO back
the x86 arch still needs asm-goto in the compiler to be built.
As far as I can see there are other places where asm-goto
is open coded.
So there is no 'encouraging'.

Whereas if we do bpf specific marco we'd need to explain that
to all bpf users and they would need to fix their user space scripts.
Amount of user space breakage is unknown at this point.

[PATCH] drm/nouveau: Add missing fb SLCG registers for kepler2

[Lyude Paul]

Somehow I didn't manage to notice this the last time I looked at my
mmiotraces, these seem to be all valid registers.

Forwarding this to stable, as there's a small chance that not having
these could cause clockgating to be unstable.

Signed-off-by: Lyude Paul 
Fixes: a0f79082bd174 ("drm/nouveau: Add support for SLCG for Kepler2")
Cc: sta...@vger.kernel.org
---
 drivers/gpu/drm/nouveau/nvkm/subdev/fb/gk110.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/gk110.c 
b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/gk110.c
index 0695e5dd360e..0d9ad9fa7774 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/gk110.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/gk110.c
@@ -32,6 +32,18 @@
  * PGRAPH registers for clockgating
  
***
  */
+static const struct nvkm_therm_clkgate_init
+gk110_fb_clkgate_slcg_init_bcast_0[] = {
+   { 0x10f280, 1, 0x },
+   {}
+};
+
+static const struct nvkm_therm_clkgate_init
+gk110_fb_clkgate_slcg_init_pxbar_0[] = {
+   { 0x13cafc, 1, 0x007e },
+   { 0x13cbe4, 1, 0x1ffe },
+   {}
+};
 
 static const struct nvkm_therm_clkgate_init
 gk110_fb_clkgate_blcg_init_unk_0[] = {
@@ -45,6 +57,8 @@ gk110_fb_clkgate_blcg_init_unk_0[] = {
 
 static const struct nvkm_therm_clkgate_pack
 gk110_fb_clkgate_pack[] = {
+   { gk110_fb_clkgate_slcg_init_bcast_0 },
+   { gk110_fb_clkgate_slcg_init_pxbar_0 },
{ gk110_fb_clkgate_blcg_init_unk_0 },
{ gk104_fb_clkgate_blcg_init_vm_0 },
{ gk104_fb_clkgate_blcg_init_main_0 },
-- 
2.14.3

Re: [PATCH v3 01/10] bindings: PCI: designware: Example update

[Rob Herring]

On Tue, Apr 10, 2018 at 01:58:33PM +0100, Gustavo Pimentel wrote:
> Replaces "ctrlreg" reg-name by "dbi" to be coherent with similar drivers,
> however it still be compatible with any previous DT that uses the old
> reg-name.
> 
> Replaces the PCIe base address example by a real PCIe base address in use.
> 
> Signed-off-by: Gustavo Pimentel 
> ---
> Changes v1->v2:
>  - Removed any iATU reference or changes to avoid confusion.
>  - Add "snps,dw-pcie" compatible string following Kishon's suggestion.
> Changes v2->v3:
> - Nothing changed, just to follow the patch set version.
> 
>  Documentation/devicetree/bindings/pci/designware-pcie.txt | 14 +++---
>  1 file changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/pci/designware-pcie.txt 
> b/Documentation/devicetree/bindings/pci/designware-pcie.txt
> index 1da7ade..f02cd20 100644
> --- a/Documentation/devicetree/bindings/pci/designware-pcie.txt
> +++ b/Documentation/devicetree/bindings/pci/designware-pcie.txt
> @@ -1,7 +1,8 @@
>  * Synopsys DesignWare PCIe interface
>  
>  Required properties:
> -- compatible: should contain "snps,dw-pcie" to identify the core.
> +- compatible:
> + "snps,dw-pcie-rc", "snps,dw-pcie" for RC mode;

I think adding this compatible is pointless. "snps,dw-pcie" meant RC and 
should continue to mean that. We also have compatibles with the IP 
version number as well as the SoC specific compatible strings. We don't 
need 4 compatible strings here.

Rob

Re: [RFC PATCH 3/4] acpi: apei: Do not panic() in NMI because of GHES messages

[James Morse]

Hi Alex,

On 09/04/18 19:11, Alex G. wrote:
> On 04/06/2018 01:24 PM, James Morse wrote:
> Do you have any ETA on when your SEA patches are going to make it
> upstream? There's not much point in updating my patchset if it's going
> to conflict with your work.

The SEA stuff went in with 7edda0886bc3 ("acpi: apei: handle SEA notification
type for ARMv8"). My series is moving it to use the estatus-queue in the same
way as x86's NOTIFY_NMI does. This lets us safely add the other two NMI-like
notifications. I have no idea on the ETA, it depends on review feedback!


>>> But if on arm64, you can return to firmware,
>>> then we have wildly different constraints.
>>
>> We can't return to firmware, but we can take the error again, causing another
>> trap to firmware.
>>
>> e.g.: If a program accesses a value in the cache and the cache location is
>> discovered to be corrupt/marked-as-poisoned. This causes an 'external abort'
>> exception, which firmware has configured to trap to firmware. Once there, it
>> generates CPER records and sets-up an external-abort-exception for Linux.
>> If linux returns from this external-abort, we return to whatever program
>> accessed the bad-cache-value in the first case, re-run the instruction that
>> generates the external abort, and the same thing happens again, but to 
>> firmware
>> it looks like a second fault at the same address.

> This is a very good example of why we should _not_ panic in NMI.
> Invalidate the cache-line, next load causes a memory round-trip, and
> everyone's happy. Of course, FFS can't do that because it doesn't know
> if it's valid to invalidate (pun intended). But the OS does. So you
> _want_ to reach the error handler downstream of NMI context, and you do
> _not_ want to crash.

This assumes a cache-invalidate will clear the error, which I don't think we're
guaranteed on arm.
It also destroys any adjacent data, "everyone's happy" includes the thread that
got a chunk of someone-else's stack frame, I don't think it will be happy for
very long!

(this is a side issue for AER though)


>>> On x86, you can't return to SMM. You can have a new SMI triggered while
>>> servicing the NMI, but you can't re-enter an SMI that you've returned
>>> from. SMM holds all the cores, and they all leave SMM at roughly the
>>> same time, so you don't deal with coexistence issues. This probably also
>>> avoids the multiple notifications that you are trying to implement on arm.
>>
>> its the new SMI case.
>>
>> (We don't necessarily have all cores pulled into firmware, (although firmware
>> could do that in software), so different CPUs taking NMI-like notifications 
>> is
>> one of the things we have to handle.)

> How does FFS handle race conditions that can occur when accessing HW
> concurrently with the OS? I'm told it's the main reasons why BIOS
> doesn't release unused cores from SMM early.

This is firmware's problem, it depends on whether there is any hardware that is
shared with the OS. Some hardware can be marked 'secure' in which case only
firmware can access it, alternatively firmware can trap or just disable the OS's
access to the shared hardware.

For example, with the v8.2 RAS Extensions, there are some per-cpu error
registers. Firmware can disable these for the OS, so that it always reads 0 from
them. Instead firmware takes the error via FF, reads the registers from
firmware, and dumps CPER records into the OS's memory.

If there is a shared hardware resource that both the OS and firmware may be
accessing, yes firmware needs to pull the other CPUs in, but this depends on the
SoC design, it doesn't necessarily happen.


>>> On quick thought, I think the best way to go for both series is to leave
>>> the entry points arch-specific, and prevent hax86 and harm64 from
>>> stepping on each other's toes. Thoughts?
>>
>> The behaviour should be driven from the standard. I agree there is some 
>> leeway,
>> which linux should handle on all architectures that support GHES.
> 
> "The standard" deals mostly with firmware behavior. While I'm all for
> following specifications in order to ensure smooth interaction and
> integration, Linux is an OS and it deals with a plethora of "standards".
> Its job is to serve user requests. When a "standard" deviates from this,
> such as mandating a crash when one is not required, it's the OS's job to
> _not_ follow this requirement.

Sure, we're quirking our behaviour based on a high level of mistrust for the
firmware. My point here was we shouldn't duplicate the implementation because we
want x86:{AER,CPU,MEM} to behave differently to arm64:{AER,CPU,MEM}. I'd rather
the quirked-behaviour was along the *:{AER} versus *:{CPU,MEM} line. If we have
extra code to spot deferrable errors, we should use it on both architectures.


>> Once in ghes.c all the NMI-like notifications get merged together as the only
>> relevant thing about them is we have to use the estatus-queue, and can't call
>> any of the sleepy recovery helpers.
>>
>> I don't 

Re: [PATCH 21/30] stack-protector: test compiler capability in Kconfig and drop AUTO mode

[Kees Cook]

On Thu, Apr 12, 2018 at 10:06 PM, Masahiro Yamada
 wrote:
> +stackp-flags-$(CONFIG_CC_HAS_STACKPROTECTOR_NONE) := -fno-stack-protector
> +stackp-flags-$(CONFIG_CC_STACKPROTECTOR)  := -fstack-protector
> +stackp-flags-$(CONFIG_CC_STACKPROTECTOR_STRONG)   := -fstack-protector-strong
> +
> +KBUILD_CFLAGS += $(stackp-flags-y)

So, technically, this works just fine. I wonder if it has an overly
confusing result, in that the compiler under normal situations will
see:

gcc ... -fno-stack-protector -fstack-protector -fstack-protector-strong ...

How about something like this instead:

ifdef CONFIG_CC_STACKPROTECTOR_STRONG
KBUILD_CFLAGS += -fstack-protector-strong
else
ifdef CONFIG_CC_STACKPROTECTOR
KBUILD_CFLAGS += -fstack-protector
else
KBUILD_CFLAGS += -fno-stack-protector
endif
endif

-Kees

-- 
Kees Cook
Pixel Security

[PATCH v2 2/2] tracing/events: block: dev_t via driver core for plug and unplug events

[Steffen Maier]

Complements v2.6.31 commit 55782138e47d ("tracing/events: convert block
trace points to TRACE_EVENT()") to be equivalent to traditional blktrace
output. Also this allows event filtering to not always get all (un)plug
events.

NB: The NULL pointer check for q->kobj.parent is certainly racy and
I don't have enough experience if it's good enough for a trace event.
The change did work for my cases (block device read/write I/O on
zfcp-attached SCSI disks and dm-mpath on top).

While I haven't seen any prior art using driver core (parent) relations
for trace events, there are other cases using this when no direct pointer
exists between objects, such as:
 #define to_scsi_target(d)  container_of(d, struct scsi_target, dev)
 static inline struct scsi_target *scsi_target(struct scsi_device *sdev)
 {
return to_scsi_target(sdev->sdev_gendev.parent);
 }

This is the object model we make use of here:

struct gendisk {
struct hd_struct {
struct device {  /*container_of*/
struct kobject kobj; <--+
dev_t  devt; /*deref*/  |
} __dev;|
} part0;|
struct request_queue *queue; ..+|
}  :|
   :|
struct request_queue {  <..+|
/* queue kobject */ |
struct kobject {|
struct kobject *parent; +
} kobj;
}

The parent pointer comes from:
 #define disk_to_dev(disk)  (&(disk)->part0.__dev)
int blk_register_queue(struct gendisk *disk)
struct device *dev = disk_to_dev(disk);
struct request_queue *q = disk->queue;
ret = kobject_add(>kobj, kobject_get(>kobj), "%s", "queue");
^^^parent

$ ls -d /sys/block/sdf/queue
/sys/block/sda/queue
$ cat /sys/block/sdf/dev
80:0

A partition does not have its own request queue:

$ cat /sys/block/sdf/sdf1/dev
8:81
$ ls -d /sys/block/sdf/sdf1/queue
ls: cannot access '/sys/block/sdf/sdf1/queue': No such file or directory

The difference to blktrace parsed output is that block events don't use the
partition's minor number but the containing block device's minor number:

$ dd if=/dev/sdf1 count=1

$ cat /sys/kernel/debug/tracing/trace
block_bio_remap: 8,80 R 2048 + 32 <- (8,81) 0
block_bio_queue: 8,80 R 2048 + 32 [dd]
block_getrq: 8,80 R 2048 + 32 [dd]
block_plug: 8,80 [dd]

block_rq_insert: 8,80 R 16384 () 2048 + 32 [dd]
block_unplug: 8,80 [dd] 1 explicit
  
block_rq_issue: 8,80 R 16384 () 2048 + 32 [dd]
block_rq_complete: 8,80 R () 2048 + 32 [0]

$ btrace /dev/sdf1
  8,80   11 0.0 240240  A   R 2048 + 32 <- (8,81) 0
  8,81   12 0.000220890 240240  Q   R 2048 + 32 [dd]
  8,81   13 0.000229639 240240  G   R 2048 + 32 [dd]
  8,81   14 0.000231805 240240  P   N [dd]
^^
  8,81   15 0.000234671 240240  I   R 2048 + 32 [dd]
  8,81   16 0.000236365 240240  U   N [dd] 1
^^
  8,81   17 0.000238527 240240  D   R 2048 + 32 [dd]
  8,81   22 0.000613741 0  C   R 2048 + 32 [0]

Signed-off-by: Steffen Maier 
---
 include/trace/events/block.h | 13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/include/trace/events/block.h b/include/trace/events/block.h
index e90bb6eb8097..6ea5a3899c2e 100644
--- a/include/trace/events/block.h
+++ b/include/trace/events/block.h
@@ -460,14 +460,18 @@ TRACE_EVENT(block_plug,
TP_ARGS(q),
 
TP_STRUCT__entry(
+   __field( dev_t, dev )
__array( char,  comm,   TASK_COMM_LEN   )
),
 
TP_fast_assign(
+   __entry->dev = q->kobj.parent ?
+   container_of(q->kobj.parent, struct device, kobj)->devt : 0;
memcpy(__entry->comm, current->comm, TASK_COMM_LEN);
),
 
-   TP_printk("[%s]", __entry->comm)
+   TP_printk("%d,%d [%s]",
+ MAJOR(__entry->dev), MINOR(__entry->dev), __entry->comm)
 );
 
 #define show_block_unplug_explicit(val)\
@@ -482,18 +486,23 @@ DECLARE_EVENT_CLASS(block_unplug,
TP_ARGS(q, depth, explicit),
 
TP_STRUCT__entry(
+   __field( dev_t, dev )
__field( int,   nr_rq   )
__field( bool,  explicit)
__array( char,  comm,   TASK_COMM_LEN   )
),
 
TP_fast_assign(
+   __entry->dev   = q->kobj.parent ?
+   container_of(q->kobj.parent, struct device, kobj)->devt : 0;
__entry->nr_rq = depth;
__entry->explicit = explicit;
memcpy(__entry->comm, 

Re: [PATCH v3 2/2] MIPS: io: add a barrier after register read in readX()

[Sinan Kaya]

On 4/13/2018 11:41 AM, David Laight wrote:
> From: James Hogan
>> Sent: 12 April 2018 22:52
>> On Tue, Apr 03, 2018 at 08:55:04AM -0400, Sinan Kaya wrote:
>>> While a barrier is present in writeX() function before the register write,
>>> a similar barrier is missing in the readX() function after the register
>>> read. This could allow memory accesses following readX() to observe
>>> stale data.
>>>
>>> Signed-off-by: Sinan Kaya 
>>> Reported-by: Arnd Bergmann 
>>
>> Both patches look like obvious improvements to me, so I'm happy to apply
>> to my fixes branch.
> 
> Don't you also need at least barrier() between the register write in writeX()
> and the register read in readX()?
> On ppc you probably need eieio.
> Or are drivers expected to insert that one?
> If they need to insert that one then why not all the others??
> 

Good question. The volatile in here should prevent compiler from reordering the
register read or write instructions. 

static inline type pfx##read##bwlq(const volatile void __iomem *mem)

This is the solution all other architectures rely on especially via
__raw_readX() and __raw_writeX() API.

Now, things can get reordered when it leaves the CPU. This is guaranteed by
embedding wmb() and rmb() into the writeX() and readX() functions in other
architectures.

This ordering guarantee has been agreed to be the responsibility of the
architecture not drivers.

-- 
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm 
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux 
Foundation Collaborative Project.

Re: [virtio-dev] Re: [PATCH v2] virtio_balloon: export hugetlb page allocation counts

[Jonathan Helman]

On 04/13/2018 06:44 AM, Michael S. Tsirkin wrote:

On Fri, Apr 13, 2018 at 03:01:11PM +0800, Jason Wang wrote:



On 2018年04月12日 08:24, Jonathan Helman wrote:



On 04/10/2018 08:12 PM, Jason Wang wrote:



On 2018年04月10日 05:11, Jonathan Helman wrote:



On 03/22/2018 07:38 PM, Jason Wang wrote:



On 2018年03月22日 11:10, Michael S. Tsirkin wrote:

On Thu, Mar 22, 2018 at 09:52:18AM +0800, Jason Wang wrote:

On 2018年03月20日 12:26, Jonathan Helman wrote:

On Mar 19, 2018, at 7:31 PM, Jason
Wang wrote:



On 2018年03月20日 06:14, Jonathan Helman wrote:

Export the number of successful and failed hugetlb page
allocations via the virtio balloon driver. These 2 counts
come directly from the vm_events HTLB_BUDDY_PGALLOC and
HTLB_BUDDY_PGALLOC_FAIL.

Signed-off-by: Jonathan Helman

Reviewed-by: Jason Wang

Thanks.


---
    drivers/virtio/virtio_balloon.c | 6 ++
    include/uapi/linux/virtio_balloon.h | 4 +++-
    2 files changed, 9 insertions(+), 1 deletion(-)

diff --git
a/drivers/virtio/virtio_balloon.c
b/drivers/virtio/virtio_balloon.c
index dfe5684..6b237e3 100644
--- a/drivers/virtio/virtio_balloon.c
+++ b/drivers/virtio/virtio_balloon.c
@@ -272,6 +272,12 @@ static unsigned int
update_balloon_stats(struct
virtio_balloon *vb)
pages_to_bytes(events[PSWPOUT]));
    update_stat(vb, idx++,
VIRTIO_BALLOON_S_MAJFLT,
events[PGMAJFAULT]);
    update_stat(vb, idx++,
VIRTIO_BALLOON_S_MINFLT,
events[PGFAULT]);
+#ifdef CONFIG_HUGETLB_PAGE
+    update_stat(vb, idx++, VIRTIO_BALLOON_S_HTLB_PGALLOC,
+    events[HTLB_BUDDY_PGALLOC]);
+    update_stat(vb, idx++, VIRTIO_BALLOON_S_HTLB_PGFAIL,
+    events[HTLB_BUDDY_PGALLOC_FAIL]);
+#endif
    #endif
    update_stat(vb, idx++, VIRTIO_BALLOON_S_MEMFREE,
    pages_to_bytes(i.freeram));
diff --git
a/include/uapi/linux/virtio_balloon.h
b/include/uapi/linux/virtio_balloon.h
index 4e8b830..40297a3 100644
--- a/include/uapi/linux/virtio_balloon.h
+++ b/include/uapi/linux/virtio_balloon.h
@@ -53,7 +53,9 @@ struct virtio_balloon_config {
    #define VIRTIO_BALLOON_S_MEMTOT   5
/* Total amount of memory */
    #define VIRTIO_BALLOON_S_AVAIL    6
/* Available memory as in /proc */
    #define VIRTIO_BALLOON_S_CACHES   7   /* Disk caches */
-#define VIRTIO_BALLOON_S_NR   8
+#define VIRTIO_BALLOON_S_HTLB_PGALLOC
8  /* Hugetlb page allocations */
+#define VIRTIO_BALLOON_S_HTLB_PGFAIL
9  /* Hugetlb page allocation failures
*/
+#define VIRTIO_BALLOON_S_NR   10
  /*
     * Memory statistics structure.

Not for this patch, but it looks to me that
exporting such nr through uapi is fragile.

Sorry, can you explain what you mean here?

Jon

Spec said "Within an output buffer submitted to the
statsq, the device MUST
ignore entries with tag values that it does not
recognize". So exporting
VIRTIO_BALLOON_S_NR seems useless and device
implementation can not depend
on such number in uapi.

Thanks

Suggestions? I don't like to break build for people ...



Didn't have a good idea. But maybe we should keep
VIRTIO_BALLOON_S_NR unchanged, and add a comment here.

Thanks


I think Jason's comment is for a future patch. Didn't see this
patch get applied, so wondering if it could be.

Thanks,
Jon


Hi Jon:

Have you tested new driver with old qemu?


Yes, this testing scenario looks good. Thanks.

Jon


Hi Jon:

I mean e.g compiling qemu with new linux headers. E.g current qemu has:

static const char *balloon_stat_names[] = {
    [VIRTIO_BALLOON_S_SWAP_IN] = "stat-swap-in",
    [VIRTIO_BALLOON_S_SWAP_OUT] = "stat-swap-out",
    [VIRTIO_BALLOON_S_MAJFLT] = "stat-major-faults",
    [VIRTIO_BALLOON_S_MINFLT] = "stat-minor-faults",
    [VIRTIO_BALLOON_S_MEMFREE] = "stat-free-memory",
    [VIRTIO_BALLOON_S_MEMTOT] = "stat-total-memory",
    [VIRTIO_BALLOON_S_AVAIL] = "stat-available-memory",
    [VIRTIO_BALLOON_S_CACHES] = "stat-disk-caches",
    [VIRTIO_BALLOON_S_NR] = NULL
};

I'm afraid it will be broken if VIRTIO_BALLOON_S_NR is 10.

Thanks


Well it is handy for sizing arrays and this isn't the first time we did
this:

commit 4d32029b8ddb7be4d1699c6d8e1675ff5476d149
Author: Tomáš Golembiovský 
Date:   Sun Nov 12 13:05:38 2017 +0100

 virtio_balloon: include disk/file caches memory statistics
 
   


commit 5057dcd0f1aaad57e07e728ba20a99e205c6b9de
Author: Igor Redko 
Date:   Thu Mar 17 14:19:08 2016 -0700

 virtio_balloon: export 'available' memory to balloon statistics
 


how about we give QEMU a hand and just put the list of names in
the header?

I posted a patch like that, pls review.



Sorry, maybe I'm missing something. We have an internal copy of the 
header file in qemu under 
include/standard-headers/linux/virtio_balloon.h, which 
hw/virtio/virtio-balloon.c includes (through including 
hw/virtio/virtio-balloon.h). I thought qemu would use internal header 
files so that it could be compiled on any Linux kernel 

Re: [PATCH RFC 2/8] mm: introduce PG_offline

[Matthew Wilcox]

On Fri, Apr 13, 2018 at 03:16:26PM +0200, David Hildenbrand wrote:
> online_pages()/offline_pages() theoretically allows us to work on
> sub-section sizes. This is especially relevant in the context of
> virtualization. It e.g. allows us to add/remove memory to Linux in a VM in
> 4MB chunks.
> 
> While the whole section is marked as online/offline, we have to know
> the state of each page. E.g. to not read memory that is not online
> during kexec() or to properly mark a section as offline as soon as all
> contained pages are offline.

Can you not use PG_reserved for this purpose?

> + * PG_offline indicates that a page is offline and the backing storage
> + * might already have been removed (virtualization). Don't touch!

 * PG_reserved is set for special pages, which can never be swapped out. Some
 * of them might not even exist...

They seem pretty congruent to me.

Re: [PATCH 2/6] statfs: use << to align with fs header

[Andreas Dilger]

On Apr 13, 2018, at 10:11 AM, Christian Brauner  
wrote:
> 
> Consistenly use << to define ST_* constants. This also aligns them with
> their MS_* counterparts in fs.h

IMHO, using (1 << 10) makes the code harder to debug.  If you see a field
in a structure like 0x8354, it is non-trivial to map this to the ST_*
flags if they are declared in the form (1 << 10) or BIT(10).  If they are
declared in the form 0x100 (as they are now) then it is trivial that the
ST_APPEND flag is set in 0x8354, and easy to understand the other flags.

So, my preference would be to NOT land this or the previous patch.

Cheers, Andreas

> Signed-off-by: Christian Brauner 
> ---
> include/linux/statfs.h | 26 +-
> 1 file changed, 13 insertions(+), 13 deletions(-)
> 
> diff --git a/include/linux/statfs.h b/include/linux/statfs.h
> index 3142e98546ac..b336c04e793c 100644
> --- a/include/linux/statfs.h
> +++ b/include/linux/statfs.h
> @@ -27,18 +27,18 @@ struct kstatfs {
>  * ABI.  The exception is ST_VALID which has the same value as MS_REMOUNT
>  * which doesn't make any sense for statfs.
>  */
> -#define ST_RDONLY0x0001  /* mount read-only */
> -#define ST_NOSUID0x0002  /* ignore suid and sgid bits */
> -#define ST_NODEV 0x0004  /* disallow access to device special files */
> -#define ST_NOEXEC0x0008  /* disallow program execution */
> -#define ST_SYNCHRONOUS   0x0010  /* writes are synced at once */
> -#define ST_VALID 0x0020  /* f_flags support is implemented */
> -#define ST_MANDLOCK  0x0040  /* allow mandatory locks on an FS */
> -/* 0x0080 used for ST_WRITE in glibc */
> -/* 0x0100 used for ST_APPEND in glibc */
> -/* 0x0200 used for ST_IMMUTABLE in glibc */
> -#define ST_NOATIME   0x0400  /* do not update access times */
> -#define ST_NODIRATIME0x0800  /* do not update directory access times 
> */
> -#define ST_RELATIME  0x1000  /* update atime relative to mtime/ctime */
> +#define ST_RDONLY(1<<0) /* mount read-only */
> +#define ST_NOSUID(1<<1) /* ignore suid and sgid bits */
> +#define ST_NODEV (1<<2) /* disallow access to device special files */
> +#define ST_NOEXEC(1<<3) /* disallow program execution */
> +#define ST_SYNCHRONOUS   (1<<4) /* writes are synced at once */
> +#define ST_VALID (1<<5) /* f_flags support is implemented */
> +#define ST_MANDLOCK  (1<<6) /* allow mandatory locks on an FS */
> +/* (1<<7) used for ST_WRITE in glibc */
> +/* (1<<8) used for ST_APPEND in glibc */
> +/* (1<<9) used for ST_IMMUTABLE in glibc */
> +#define ST_NOATIME   (1<<10) /* do not update access times */
> +#define ST_NODIRATIME(1<<11) /* do not update directory access times 
> */
> +#define ST_RELATIME  (1<<12) /* update atime relative to mtime/ctime */
> 
> #endif
> --
> 2.17.0
> 


Cheers, Andreas







signature.asc
Description: Message signed with OpenPGP

Re: Crashes/hung tasks with z3pool under memory pressure

[Guenter Roeck]

On Fri, Apr 13, 2018 at 05:21:02AM +, Vitaly Wool wrote:
> Hi Guenter,
> 
> 
> Den fre 13 apr. 2018 kl 00:01 skrev Guenter Roeck :
> 
> > Hi all,
> 
> > we are observing crashes with z3pool under memory pressure. The kernel
> version
> > used to reproduce the problem is v4.16-11827-g5d1365940a68, but the
> problem was
> > also seen with v4.14 based kernels.
> 
> 
> just before I dig into this, could you please try reproducing the errors
> you see with https://patchwork.kernel.org/patch/10210459/ applied?
> 

As mentioned above, I tested with v4.16-11827-g5d1365940a68, which already
includes this patch.

$ git log --oneline v4.14..5d1365940a68 mm/z3fold.c
8a97ea546bb6 mm/z3fold.c: use gfpflags_allow_blocking
1ec6995d1290 z3fold: fix memory leak
5c9bab592f53 z3fold: limit use of stale list for allocation
f144c390f905 mm: docs: fix parameter names mismatch
5d03a6613957 mm/z3fold.c: use kref to prevent page free/compact race

Guenter

[PATCH v3 2/3] Documentation/i2c: sync docs with current state of i2c-tools

[Sam Hansen]

Currently, Documentation/i2c/dev-interface describes the use of
i2c_smbus_* helper routines as static inlined functions provided by
linux/i2c-dev.h.  Work has been done to refactor the linux/i2c-dev.h file
in the i2c-tools project out into its own library.  As a result, these
docs have become stale.

This patch corrects the discrepancy and directs the reader to the
i2c-tools project for more information.

Signed-off-by: Sam Hansen 
---
No changes from v2.

 Documentation/i2c/dev-interface | 16 +---
 1 file changed, 5 insertions(+), 11 deletions(-)

diff --git a/Documentation/i2c/dev-interface b/Documentation/i2c/dev-interface
index c8737d502791..f92ee1f59914 100644
--- a/Documentation/i2c/dev-interface
+++ b/Documentation/i2c/dev-interface
@@ -23,11 +23,6 @@ First, you need to include these two headers:
   #include 
   #include 
 
-(Please note that there are two files named "i2c-dev.h" out there. One is
-distributed with the Linux kernel and the other one is included in the
-source tree of i2c-tools. They used to be different in content but since 2012
-they're identical. You should use "linux/i2c-dev.h").
-
 Now, you have to decide which adapter you want to access. You should
 inspect /sys/class/i2c-dev/ or run "i2cdetect -l" to decide this.
 Adapter numbers are assigned somewhat dynamically, so you can not
@@ -140,8 +135,8 @@ ioctl(file, I2C_RDWR, struct i2c_rdwr_ioctl_data *msgset)
   set in each message, overriding the values set with the above ioctl's.
 
 ioctl(file, I2C_SMBUS, struct i2c_smbus_ioctl_data *args)
-  Not meant to be called  directly; instead, use the access functions
-  below.
+  If possible, use the provided i2c_smbus_* methods described below instead
+  of issuing direct ioctls.
 
 You can do plain i2c transactions by using read(2) and write(2) calls.
 You do not need to pass the address byte; instead, set it through
@@ -166,10 +161,9 @@ what happened. The 'write' transactions return 0 on 
success; the
 returns the number of values read. The block buffers need not be longer
 than 32 bytes.
 
-The above functions are all inline functions, that resolve to calls to
-the i2c_smbus_access function, that on its turn calls a specific ioctl
-with the data in a specific format. Read the source code if you
-want to know what happens behind the screens.
+The above functions are made available by linking against the libi2c library,
+which is provided by the i2c-tools project.  See:
+https://git.kernel.org/pub/scm/utils/i2c-tools/i2c-tools.git/.
 
 
 Implementation details
-- 
2.17.0.484.g0c8726318c-goog

[PATCH] proc: fix /proc/loadavg regression

[Alexey Dobriyan]

commit 95846ecf9dac5089aed4b144d912225f8ef86ae4
"pid: replace pid bitmap implementation with IDR API"

changed last field of /proc/loadavg (last pid allocated)
to be off by one:

# unshare -p -f --mount-proc cat /proc/loadavg
0.00 0.00 0.00 1/60 2   <===

It should be 1 after first fork into pid namespace.

This is formally a regression but given how useless this field is
I don't think anyone is affected.

Bug was found by /proc testsuite!

Signed-off-by: Alexey Dobriyan 
---

 arch/powerpc/platforms/cell/spufs/sched.c |2 +-
 fs/proc/loadavg.c |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

--- a/arch/powerpc/platforms/cell/spufs/sched.c
+++ b/arch/powerpc/platforms/cell/spufs/sched.c
@@ -1093,7 +1093,7 @@ static int show_spu_loadavg(struct seq_file *s, void 
*private)
LOAD_INT(c), LOAD_FRAC(c),
count_active_contexts(),
atomic_read(_spu_contexts),
-   idr_get_cursor(_active_pid_ns(current)->idr));
+   idr_get_cursor(_active_pid_ns(current)->idr) - 1);
return 0;
 }
 
--- a/fs/proc/loadavg.c
+++ b/fs/proc/loadavg.c
@@ -24,7 +24,7 @@ static int loadavg_proc_show(struct seq_file *m, void *v)
LOAD_INT(avnrun[1]), LOAD_FRAC(avnrun[1]),
LOAD_INT(avnrun[2]), LOAD_FRAC(avnrun[2]),
nr_running(), nr_threads,
-   idr_get_cursor(_active_pid_ns(current)->idr));
+   idr_get_cursor(_active_pid_ns(current)->idr) - 1);
return 0;
 }
 

Re: sparc/ppc/arm compat siginfo ABI regressions: sending SIGFPE via kill() returns wrong values in si_pid and si_uid

[Russell King - ARM Linux]

On Fri, Apr 13, 2018 at 06:08:28PM +0100, Dave Martin wrote:
> On Fri, Apr 13, 2018 at 09:33:17AM -0700, Linus Torvalds wrote:
> > On Fri, Apr 13, 2018 at 2:42 AM, Russell King - ARM Linux
> >  wrote:
> > >
> > > Yes, it does solve the problem at hand with strace - the exact patch I
> > > tested against 4.16 is below.
> > 
> > Ok, good.
> > 
> > > However, FPE_FLTUNK is not defined in older kernels, so while we can
> > > fix it this way for the current merge window, that doesn't help 4.16.
> > 
> > I wonder if we should even bother with FPE_FLTUNK.
> > 
> > I suspect we might as well use FPE_FLTINV, I suspect, and not have
> > this complexity at all. That case is not worth worrying about, since
> > it's a "this shouldn't happen anyway" and the *real* reason will be in
> > the kernel logs due to vfs_panic().
> > 
> > So it's not like this is something that the user should ever care
> > about the si_code about.
> 
> Ack, my intended meaning for FPE_FLTUNK is that the fp exception is
> either spurious or we can't tell easily (or possibly at all) which
> FPE_XXX should be returned.  It's up to userspace to figure it out
> if it really cares.  Previously we were accidentally returning SI_USER
> in si_code for arm64.
> 
> This case on arm looks like a more serious error for which FPE_FLTINV
> may be more appropriate anyway.

No.  The cases where we get to this point are:

1. A trap concerning a coprocessor register transfer instruction (iow, move
   between a VFP register and ARM register.)
2. A trap concerning a coprocessor register load or save instruction.

(In both of these, "concerning" means that the VFP hardware provides
such an instruction as the reason for the fault, *not* that it is the
faulting instruction.)

3. A combination of the exception bits (EX and DEX) on certain VFP
   implementations.

All of these can be summarised as "the hardware went wrong in some way"
rather than "the user program did something wrong."

FPE_FLTINV means "floating point invalid operation".  Does it really
cover the case where hardware has failed, or is it intended to cover
the case where userspace did something wrong and asked for an invalid
operation from the FP hardware?

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

Re: [PATCH 2/6] statfs: use << to align with fs header

[Randy Dunlap]

On 04/13/2018 10:35 AM, Andreas Dilger wrote:
> On Apr 13, 2018, at 10:11 AM, Christian Brauner 
>  wrote:
>>
>> Consistenly use << to define ST_* constants. This also aligns them with
>> their MS_* counterparts in fs.h
> 
> IMHO, using (1 << 10) makes the code harder to debug.  If you see a field
> in a structure like 0x8354, it is non-trivial to map this to the ST_*
> flags if they are declared in the form (1 << 10) or BIT(10).  If they are
> declared in the form 0x100 (as they are now) then it is trivial that the
> ST_APPEND flag is set in 0x8354, and easy to understand the other flags.
> 
> So, my preference would be to NOT land this or the previous patch.

That makes sense to me.

-- 
~Randy

Re: Crashes/hung tasks with z3pool under memory pressure

[Guenter Roeck]

On Fri, Apr 13, 2018 at 05:40:18PM +, Vitaly Wool wrote:
> On Fri, Apr 13, 2018, 7:35 PM Guenter Roeck  wrote:
> 
> > On Fri, Apr 13, 2018 at 05:21:02AM +, Vitaly Wool wrote:
> > > Hi Guenter,
> > >
> > >
> > > Den fre 13 apr. 2018 kl 00:01 skrev Guenter Roeck :
> > >
> > > > Hi all,
> > >
> > > > we are observing crashes with z3pool under memory pressure. The kernel
> > > version
> > > > used to reproduce the problem is v4.16-11827-g5d1365940a68, but the
> > > problem was
> > > > also seen with v4.14 based kernels.
> > >
> > >
> > > just before I dig into this, could you please try reproducing the errors
> > > you see with https://patchwork.kernel.org/patch/10210459/ applied?
> > >
> >
> > As mentioned above, I tested with v4.16-11827-g5d1365940a68, which already
> > includes this patch.
> >
> 
> Bah. Sorry. Expect an update after the weekend.
> 
NP; easy to miss. Thanks a lot for looking into it.

Guenter

Re: [PATCH 2/3] dt-bindings: add binding for at91-usart in spi mode

[Alexandre Belloni]

On 13/04/2018 19:12:54+0200, Nicolas Ferre wrote:
> > > diff --git 
> > > a/Documentation/devicetree/bindings/spi/microchip,at91-usart-spi.txt 
> > > b/Documentation/devicetree/bindings/spi/microchip,at91-usart-spi.txt
> > > new file mode 100644
> > > index ..92d33ccdffae
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/spi/microchip,at91-usart-spi.txt
> > > @@ -0,0 +1,24 @@
> > > +* Universal Synchronous Asynchronous Receiver/Transmitter (USART) in SPI 
> > > mode
> > > +
> > > +Required properties:
> > > +- #size-cells  : Must be <0>
> > > +- #address-cells   : Must be <1>
> > > +- compatible: Should be "microchip,at91sam9g45-usart-spi" or 
> > > "microchip,sama5d2-usart-spi"
> > > +- reg: Should contain registers location and length
> > > +- interrupts: Should contain interrupt
> > > +- clocks: phandles to input clocks.
> > > +- clock-names: tuple listing input clock names.
> > > + Required elements: "usart"
> > > +- cs-gpios: chipselects (internal cs not supported)
> > > +
> > > +Example:
> > > + spi0: spi@f001c000 {
> > > + #address-cells = <1>;
> > > + #size-cells = <0>;
> > > + compatible = "microchip,sama5d2-usart-spi", 
> > > "microchip,at91sam9g45-usart-spi";
> > 
> > I'm pretty sure this will be considered configuration rather than
> > hardware description. Why don't you do something like the flexcom mode
> > selection?
> 
> Because we are not in the same situation as having a glue layer that would
> select one of the already existing peripherals with associated drivers
> above.
> This layout of the hardware is completely different from the USART one and
> it seems to makes sense to address it with a different hardware description
> and so a different compatible string.
> 

But then, you can end up with two drivers trying to use the same IP
because nothing prevents you from writing a DT with both a usart and an
spi node enabled for the same IP. request_mem_region() will not help
here because then the working driver will depend on the probing order.


-- 
Alexandre Belloni, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com

[PATCH] trace_kprobe: Remove warning message "Could not insert probe at..."

[Song Liu]

This warning message is not very helpful, as the return value should
already show information about the error. Also, this message will
flush dmesg if the user space do something silly in a loop, like:

for x in {0..5}
do
echo p:xx xx+$x >> /sys/kernel/debug/tracing/kprobe_events
done

Cc: Ingo Molnar 
Cc: Peter Zijlstra 
Reported-by: Vince Weaver 
Signed-off-by: Song Liu 
---
 kernel/trace/trace_kprobe.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/kernel/trace/trace_kprobe.c b/kernel/trace/trace_kprobe.c
index 1cd3fb4..02aed76 100644
--- a/kernel/trace/trace_kprobe.c
+++ b/kernel/trace/trace_kprobe.c
@@ -512,8 +512,6 @@ static int __register_trace_kprobe(struct trace_kprobe *tk)
if (ret == 0)
tk->tp.flags |= TP_FLAG_REGISTERED;
else {
-   pr_warn("Could not insert probe at %s+%lu: %d\n",
-   trace_kprobe_symbol(tk), trace_kprobe_offset(tk), ret);
if (ret == -ENOENT && trace_kprobe_is_on_module(tk)) {
pr_warn("This probe might be able to register after 
target module is loaded. Continue.\n");
ret = 0;
-- 
2.9.5

Re: [PATCH 00/32] docs/vm: convert to ReST format

[Jonathan Corbet]

Sorry for the silence, I'm pedaling as fast as I can, honest...

On Sun, 1 Apr 2018 09:38:58 +0300
Mike Rapoport  wrote:

> My thinking was to start with mechanical RST conversion and then to start
> working on the contents and ordering of the documentation. Some of the
> existing files, e.g. ksm.txt, can be moved as is into the appropriate
> places, others, like transhuge.txt should be at least split into admin/user
> and developer guides.
> 
> Another problem with many of the existing mm docs is that they are rather
> developer notes and it wouldn't be really straight forward to assign them
> to a particular topic.

All this sounds good.

> I believe that keeping the mm docs together will give better visibility of
> what (little) mm documentation we have and will make the updates easier.
> The documents that fit well into a certain topic could be linked there. For
> instance:

...but this sounds like just the opposite...?  

I've had this conversation with folks in a number of subsystems.
Everybody wants to keep their documentation together in one place - it's
easier for the developers after all.  But for the readers I think it's
objectively worse.  It perpetuates the mess that Documentation/ is, and
forces readers to go digging through all kinds of inappropriate material
in the hope of finding something that tells them what they need to know.

So I would *really* like to split the documentation by audience, as has
been done for a number of other kernel subsystems (and eventually all, I
hope).

I can go ahead and apply the RST conversion, that seems like a step in
the right direction regardless.  But I sure hope we don't really have to
keep it as an unorganized jumble of stuff...

Thanks,

jon

Re: Linux 3.18.105

[Greg KH]

diff --git a/Makefile b/Makefile
index 2eae8b1039aa..ba34e4e77d96 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
 VERSION = 3
 PATCHLEVEL = 18
-SUBLEVEL = 104
+SUBLEVEL = 105
 EXTRAVERSION =
 NAME = Diseased Newt
 
diff --git a/arch/arm/boot/dts/imx6qdl-wandboard.dtsi 
b/arch/arm/boot/dts/imx6qdl-wandboard.dtsi
index 5fb091675582..6052ea7d9d21 100644
--- a/arch/arm/boot/dts/imx6qdl-wandboard.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-wandboard.dtsi
@@ -86,6 +86,7 @@
clocks = < 201>;
VDDA-supply = <_2p5v>;
VDDIO-supply = <_3p3v>;
+   lrclk-strength = <3>;
};
 };
 
diff --git a/arch/arm/include/asm/xen/events.h 
b/arch/arm/include/asm/xen/events.h
index 8b1f37bfeeec..b7aadab9b0e8 100644
--- a/arch/arm/include/asm/xen/events.h
+++ b/arch/arm/include/asm/xen/events.h
@@ -16,7 +16,7 @@ static inline int xen_irqs_disabled(struct pt_regs *regs)
return raw_irqs_disabled_flags(regs->ARM_cpsr);
 }
 
-#define xchg_xen_ulong(ptr, val) atomic64_xchg(container_of((ptr), \
+#define xchg_xen_ulong(ptr, val) atomic64_xchg(container_of((long long*)(ptr),\
atomic64_t, \
counter), (val))
 
diff --git a/arch/arm/mach-davinci/devices-da8xx.c 
b/arch/arm/mach-davinci/devices-da8xx.c
index b85b781b05fd..e83874ba6e6d 100644
--- a/arch/arm/mach-davinci/devices-da8xx.c
+++ b/arch/arm/mach-davinci/devices-da8xx.c
@@ -761,6 +761,8 @@ static struct platform_device da8xx_dsp = {
.resource   = da8xx_rproc_resources,
 };
 
+static bool rproc_mem_inited __initdata;
+
 #if IS_ENABLED(CONFIG_DA8XX_REMOTEPROC)
 
 static phys_addr_t rproc_base __initdata;
@@ -799,6 +801,8 @@ void __init da8xx_rproc_reserve_cma(void)
ret = dma_declare_contiguous(_dsp.dev, rproc_size, rproc_base, 0);
if (ret)
pr_err("%s: dma_declare_contiguous failed %d\n", __func__, ret);
+   else
+   rproc_mem_inited = true;
 }
 
 #else
@@ -813,6 +817,12 @@ int __init da8xx_register_rproc(void)
 {
int ret;
 
+   if (!rproc_mem_inited) {
+   pr_warn("%s: memory not reserved for DSP, not registering DSP 
device\n",
+   __func__);
+   return -ENOMEM;
+   }
+
ret = platform_device_register(_dsp);
if (ret)
pr_err("%s: can't register DSP device: %d\n", __func__, ret);
diff --git a/arch/arm64/include/asm/futex.h b/arch/arm64/include/asm/futex.h
index 5f750dc96e0f..49d057eb93d6 100644
--- a/arch/arm64/include/asm/futex.h
+++ b/arch/arm64/include/asm/futex.h
@@ -44,16 +44,16 @@
: "memory")
 
 static inline int
-futex_atomic_op_inuser (int encoded_op, u32 __user *uaddr)
+futex_atomic_op_inuser(unsigned int encoded_op, u32 __user *uaddr)
 {
int op = (encoded_op >> 28) & 7;
int cmp = (encoded_op >> 24) & 15;
-   int oparg = (encoded_op << 8) >> 20;
-   int cmparg = (encoded_op << 20) >> 20;
+   int oparg = (int)(encoded_op << 8) >> 20;
+   int cmparg = (int)(encoded_op << 20) >> 20;
int oldval = 0, ret, tmp;
 
if (encoded_op & (FUTEX_OP_OPARG_SHIFT << 28))
-   oparg = 1 << oparg;
+   oparg = 1U << (oparg & 0x1f);
 
if (!access_ok(VERIFY_WRITE, uaddr, sizeof(u32)))
return -EFAULT;
diff --git a/arch/mips/include/asm/kprobes.h b/arch/mips/include/asm/kprobes.h
index daba1f9a4f79..174aedce3167 100644
--- a/arch/mips/include/asm/kprobes.h
+++ b/arch/mips/include/asm/kprobes.h
@@ -40,7 +40,8 @@ typedef union mips_instruction kprobe_opcode_t;
 
 #define flush_insn_slot(p) \
 do {   \
-   flush_icache_range((unsigned long)p->addr,  \
+   if (p->addr)\
+   flush_icache_range((unsigned long)p->addr,  \
   (unsigned long)p->addr + \
   (MAX_INSN_SIZE * sizeof(kprobe_opcode_t)));  \
 } while (0)
diff --git a/arch/mips/mm/pgtable-32.c b/arch/mips/mm/pgtable-32.c
index adc6911ba748..b19a3c506b1e 100644
--- a/arch/mips/mm/pgtable-32.c
+++ b/arch/mips/mm/pgtable-32.c
@@ -51,15 +51,15 @@ void __init pagetable_init(void)
/*
 * Fixed mappings:
 */
-   vaddr = __fix_to_virt(__end_of_fixed_addresses - 1) & PMD_MASK;
-   fixrange_init(vaddr, vaddr + FIXADDR_SIZE, pgd_base);
+   vaddr = __fix_to_virt(__end_of_fixed_addresses - 1);
+   fixrange_init(vaddr & PMD_MASK, vaddr + FIXADDR_SIZE, pgd_base);
 
 #ifdef CONFIG_HIGHMEM
/*
 * Permanent kmaps:
 */
vaddr = PKMAP_BASE;
-   fixrange_init(vaddr, vaddr + PAGE_SIZE*LAST_PKMAP, pgd_base);
+   fixrange_init(vaddr & PMD_MASK, vaddr + PAGE_SIZE*LAST_PKMAP, pgd_base);
 

Linux 3.18.105

[Greg KH]

I'm announcing the release of the 3.18.105 kernel.

All users of the 3.18 kernel series must upgrade.

The updated 3.18.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
linux-3.18.y
and can be browsed at the normal kernel.org git web browser:

http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary

thanks,

greg k-h



 Makefile |2 
 arch/arm/boot/dts/imx6qdl-wandboard.dtsi |1 
 arch/arm/include/asm/xen/events.h|2 
 arch/arm/mach-davinci/devices-da8xx.c|   10 +
 arch/arm64/include/asm/futex.h   |8 -
 arch/mips/include/asm/kprobes.h  |3 
 arch/mips/mm/pgtable-32.c|6 -
 arch/powerpc/kernel/time.c   |   14 ++
 arch/powerpc/kvm/book3s_pr_papr.c|   34 +-
 arch/powerpc/platforms/cell/spufs/coredump.c |2 
 arch/s390/kernel/vmlinux.lds.S   |8 +
 arch/sparc/kernel/ldc.c  |7 +
 arch/x86/kernel/tsc.c|2 
 arch/x86/kvm/svm.c   |   24 ++--
 arch/x86/kvm/vmx.c   |7 -
 block/bio-integrity.c|3 
 block/partition-generic.c|4 
 crypto/async_tx/async_pq.c   |5 
 drivers/acpi/acpica/evxfevnt.c   |   18 +++
 drivers/acpi/acpica/psobject.c   |   14 ++
 drivers/ata/libahci_platform.c   |5 
 drivers/char/random.c|   10 +
 drivers/edac/mv64x60_edac.c  |2 
 drivers/gpu/drm/omapdrm/omap_gem.c   |4 
 drivers/iio/magnetometer/st_magn_spi.c   |2 
 drivers/infiniband/ulp/srpt/ib_srpt.c|6 -
 drivers/isdn/mISDN/stack.c   |2 
 drivers/leds/leds-pca955x.c  |2 
 drivers/md/bcache/alloc.c|   19 ++-
 drivers/md/bcache/super.c|6 +
 drivers/media/i2c/cx25840/cx25840-core.c |   36 --
 drivers/media/rc/mceusb.c|9 +
 drivers/net/bonding/bond_main.c  |   84 
 drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c  |   19 ++-
 drivers/net/ethernet/brocade/bna/bfa_ioc.c   |2 
 drivers/net/ethernet/freescale/fsl_pq_mdio.c |9 +
 drivers/net/ethernet/ibm/emac/core.c |   26 -
 drivers/net/ethernet/intel/e1000e/netdev.c   |   17 ++-
 drivers/net/ethernet/marvell/sky2.c  |2 
 drivers/net/ethernet/mellanox/mlx4/mcg.c |   15 ++
 drivers/net/ethernet/mellanox/mlx4/qp.c  |   13 ++
 drivers/net/ethernet/qlogic/netxen/netxen_nic_ctx.c  |2 
 drivers/net/ethernet/qlogic/qlcnic/qlcnic_hw.c   |2 
 drivers/net/ethernet/qlogic/qlge/qlge_dbg.c  |4 
 drivers/net/ethernet/qualcomm/qca_spi.c  |   10 +
 drivers/net/ethernet/realtek/r8169.c |4 
 drivers/net/ethernet/renesas/sh_eth.c|2 
 drivers/net/ethernet/ti/cpsw.c   |   16 +++
 drivers/net/hamradio/hdlcdrv.c   |2 
 drivers/net/phy/phy.c|6 +
 drivers/net/ppp/pptp.c   |1 
 drivers/net/virtio_net.c |   16 ++-
 drivers/net/vmxnet3/vmxnet3_drv.c|5 
 drivers/net/vxlan.c  |2 
 drivers/net/wireless/ath/ath5k/debug.c   |5 
 drivers/net/wireless/ray_cs.c|7 -
 drivers/net/wireless/ti/wl1251/main.c|3 
 drivers/powercap/powercap_sys.c  |1 
 drivers/rtc/interface.c  |9 +
 drivers/scsi/bnx2fc/bnx2fc.h |1 
 drivers/scsi/bnx2fc/bnx2fc_fcoe.c|   10 +
 drivers/scsi/libiscsi.c  |   24 
 drivers/scsi/libsas/sas_expander.c   |4 
 drivers/staging/wlan-ng/prism2mgmt.c |2 
 drivers/tty/n_gsm.c  |   17 ++-
 drivers/tty/serial/sccnxp.c  |   15 +-
 drivers/usb/chipidea/core.c  |   29 -
 drivers/usb/dwc3/dwc3-keystone.c |4 
 drivers/usb/host/xhci-plat.c |1 
 drivers/usb/storage/ene_ub6250.c |   11 +-
 drivers/vhost/vhost.c|3 
 drivers/video/fbdev/vfb.c|   17 +++
 

Linux 4.9.94

[Greg KH]

I'm announcing the release of the 4.9.94 kernel.

All users of the 4.9 kernel series must upgrade.

The updated 4.9.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
linux-4.9.y
and can be browsed at the normal kernel.org git web browser:

http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary

thanks,

greg k-h



 Documentation/devicetree/bindings/clock/amlogic,meson8b-clkc.txt |   11 -
 Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt|   11 -
 Makefile |2 
 arch/arm/boot/dts/imx53-qsrb.dts |2 
 arch/arm/boot/dts/imx6qdl-wandboard.dtsi |1 
 arch/arm/boot/dts/ls1021a.dtsi   |2 
 arch/arm/boot/dts/qcom-ipq4019.dtsi  |4 
 arch/arm/boot/dts/r8a7740-armadillo800eva.dts|2 
 arch/arm/boot/dts/rk322x.dtsi|6 
 arch/arm/include/asm/xen/events.h|2 
 arch/arm/kvm/hyp/switch.c|2 
 arch/arm/mach-davinci/devices-da8xx.c|   10 +
 arch/arm/mach-imx/cpu.c  |3 
 arch/arm/mach-imx/mxc.h  |6 
 arch/arm64/include/asm/futex.h   |8 
 arch/arm64/kernel/pci.c  |4 
 arch/arm64/kernel/perf_event.c   |   23 +-
 arch/arm64/kvm/hyp/switch.c  |1 
 arch/arm64/mm/mmap.c |   19 +
 arch/mips/include/asm/kprobes.h  |3 
 arch/mips/include/asm/pgtable-32.h   |7 
 arch/mips/mm/pgtable-32.c|6 
 arch/powerpc/include/asm/module.h|4 
 arch/powerpc/include/asm/page.h  |   12 +
 arch/powerpc/kernel/time.c   |   14 +
 arch/powerpc/kvm/book3s_pr_papr.c|   34 ++-
 arch/powerpc/platforms/cell/spufs/coredump.c |2 
 arch/powerpc/sysdev/mpc8xx_pic.c |2 
 arch/s390/kernel/vmlinux.lds.S   |8 
 arch/sparc/kernel/ldc.c  |7 
 arch/x86/boot/compressed/error.h |4 
 arch/x86/include/asm/asm.h   |1 
 arch/x86/kernel/tsc.c|2 
 arch/x86/kvm/lapic.c |2 
 arch/x86/kvm/svm.c   |   24 +-
 arch/x86/kvm/vmx.c   |   10 -
 arch/x86/lib/csum-copy_64.S  |   12 -
 arch/x86/lib/kaslr.c |3 
 arch/x86/platform/efi/efi.c  |6 
 block/bio-integrity.c|3 
 block/blk-mq.c   |   11 -
 block/partition-generic.c|4 
 crypto/asymmetric_keys/x509_cert_parser.c|1 
 crypto/async_tx/async_pq.c   |5 
 drivers/acpi/acpi_video.c|   14 +
 drivers/acpi/acpica/evxfevnt.c   |   18 +
 drivers/acpi/acpica/psobject.c   |   14 +
 drivers/acpi/ec.c|2 
 drivers/acpi/ec_sys.c|2 
 drivers/acpi/internal.h  |2 
 drivers/ata/libahci_platform.c   |5 
 drivers/block/loop.c |3 
 drivers/bus/brcmstb_gisb.c   |   42 ++--
 drivers/char/ipmi/ipmi_ssif.c|2 
 drivers/char/random.c|   10 -
 drivers/clk/at91/clk-generated.c |4 
 drivers/clk/clk-conf.c   |2 
 drivers/clk/clk-scpi.c   |6 
 drivers/clk/meson/Kconfig|6 
 drivers/clk/meson/meson8b.c  |5 
 drivers/clk/renesas/clk-rcar-gen2.c  |   23 +-
 drivers/cpuidle/dt_idle_states.c   

Linux 4.4.128

[Greg KH]

I'm announcing the release of the 4.4.128 kernel.

All users of the 4.4 kernel series must upgrade.

The updated 4.4.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
linux-4.4.y
and can be browsed at the normal kernel.org git web browser:

http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary

thanks,

greg k-h



 Makefile  |2 
 arch/arm/boot/dts/imx53-qsrb.dts  |2 
 arch/arm/boot/dts/imx6qdl-wandboard.dtsi  |1 
 arch/arm/boot/dts/ls1021a.dtsi|2 
 arch/arm/include/asm/xen/events.h |2 
 arch/arm/mach-davinci/devices-da8xx.c |   10 +
 arch/arm/mach-imx/cpu.c   |3 
 arch/arm/mach-imx/mxc.h   |6 +
 arch/arm64/include/asm/futex.h|8 -
 arch/mips/include/asm/kprobes.h   |3 
 arch/mips/include/asm/pgtable-32.h|7 +
 arch/mips/mm/pgtable-32.c |6 -
 arch/powerpc/include/asm/page.h   |   12 ++
 arch/powerpc/kernel/time.c|   14 ++
 arch/powerpc/kvm/book3s_pr_papr.c |   34 --
 arch/powerpc/platforms/cell/spufs/coredump.c  |2 
 arch/s390/kernel/vmlinux.lds.S|8 +
 arch/sparc/kernel/ldc.c   |7 +
 arch/x86/kernel/tsc.c |2 
 arch/x86/kvm/svm.c|   24 ++--
 arch/x86/kvm/vmx.c|7 -
 arch/x86/lib/csum-copy_64.S   |   12 +-
 block/bio-integrity.c |3 
 block/blk-mq.c|7 -
 block/partition-generic.c |4 
 crypto/async_tx/async_pq.c|5 
 drivers/acpi/acpica/evxfevnt.c|   18 +++
 drivers/acpi/acpica/psobject.c|   14 ++
 drivers/ata/libahci_platform.c|5 
 drivers/block/loop.c  |3 
 drivers/bus/brcmstb_gisb.c|   42 ---
 drivers/char/ipmi/ipmi_ssif.c |2 
 drivers/char/random.c |   10 +
 drivers/clk/clk-conf.c|2 
 drivers/clk/clk-scpi.c|6 -
 drivers/cpuidle/dt_idle_states.c  |4 
 drivers/dma/imx-sdma.c|   23 +++-
 drivers/edac/mv64x60_edac.c   |2 
 drivers/gpio/gpiolib.c|3 
 drivers/gpu/drm/omapdrm/omap_gem.c|4 
 drivers/hwmon/ina2xx.c|   87 +--
 drivers/iio/adc/hi8435.c  |   27 +++-
 drivers/iio/magnetometer/st_magn_spi.c|2 
 drivers/infiniband/ulp/srpt/ib_srpt.c |6 -
 drivers/input/mouse/elan_i2c_core.c   |7 +
 drivers/input/mouse/elan_i2c_i2c.c|9 +
 drivers/input/mouse/elantech.c|   11 ++
 drivers/isdn/mISDN/stack.c|2 
 drivers/leds/leds-pca955x.c   |2 
 drivers/md/bcache/alloc.c |   19 ++-
 drivers/md/bcache/super.c |6 +
 drivers/md/md-cluster.c   |4 
 drivers/md/raid5.c|   17 +--
 drivers/media/i2c/cx25840/cx25840-core.c  |   36 +++---
 drivers/media/rc/mceusb.c |9 +
 drivers/media/v4l2-core/videobuf2-core.c  |4 
 drivers/misc/vmw_vmci/vmci_queue_pair.c   |   10 +
 drivers/net/bonding/bond_main.c   |   84 ---
 drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c   |   19 ++-
 drivers/net/ethernet/brocade/bna/bfa_ioc.c|2 
 drivers/net/ethernet/chelsio/cxgb4/t4_hw.c|   32 +
 drivers/net/ethernet/chelsio/cxgb4vf/sge.c|   23 +++-
 drivers/net/ethernet/freescale/fsl_pq_mdio.c  |9 +
 drivers/net/ethernet/ibm/emac/core.c  |   26 
 drivers/net/ethernet/intel/e1000e/netdev.c|   17 ++-
 drivers/net/ethernet/marvell/sky2.c   |2 
 drivers/net/ethernet/mellanox/mlx4/mcg.c  |   15 ++
 drivers/net/ethernet/mellanox/mlx4/qp.c   |   19 +++
 drivers/net/ethernet/mellanox/mlx4/resource_tracker.c |   16 ++
 drivers/net/ethernet/mellanox/mlx5/core/main.c|   14 --
 

Re: [PATCH] MAINTAINERS: Adding backup maintainers for libnvdimm and DAX

[Ross Zwisler]

On Fri, Apr 13, 2018 at 01:47:40PM -0700, Dave Jiang wrote:
> Adding additional maintainers to libnvdimm related code and DAX.
> 
> Signed-off-by: Dave Jiang 

This is fine with me:

Acked-by: Ross Zwisler 

[ANNOUNCE] v4.14.34-rt27

[Sebastian Andrzej Siewior]

Dear RT folks!

I'm pleased to announce the v4.14.34-rt27 patch set. 

Changes since v4.14.34-rt26:

  - Two posix-timer related patches and one for the alarmtimer.

  - Backported a kvm patch patch by Christoffer Dall to remove a
BUG_ON() statement which triggers on RT+arm64.

  - Backported a handful patches for AMD's iommu. The series avoids
acquiring sleeping locks in atomic context on -RT. Some of patches
were made by Scott Wood.

  - Inter-event (latency) fixes by Tom Zanussi.

Known issues
 - A warning triggered in "rcu_note_context_switch" originated from
   SyS_timer_gettime(). The issue was always there, it is now
   visible. Reported by Grygorii Strashko and Daniel Wagner.

The delta patch against v4.14.34-rt26 is appended below and can be found here:
 
 
https://cdn.kernel.org/pub/linux/kernel/projects/rt/4.14/incr/patch-4.14.34-rt26-rt27.patch.xz

You can get this release via the git tree at:

git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-rt-devel.git 
v4.14.34-rt27

The RT patch against v4.14.34 can be found here:


https://cdn.kernel.org/pub/linux/kernel/projects/rt/4.14/older/patch-4.14.34-rt27.patch.xz

The split quilt queue is available at:


https://cdn.kernel.org/pub/linux/kernel/projects/rt/4.14/older/patches-4.14.34-rt27.tar.xz

Sebastian

diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
index e97eee1b2e36..b96b8c11a586 100644
--- a/drivers/iommu/amd_iommu.c
+++ b/drivers/iommu/amd_iommu.c
@@ -81,11 +81,12 @@
  */
 #define AMD_IOMMU_PGSIZES  ((~0xFFFUL) & ~(2ULL << 38))
 
-static DEFINE_RWLOCK(amd_iommu_devtable_lock);
+static DEFINE_SPINLOCK(amd_iommu_devtable_lock);
+static DEFINE_SPINLOCK(pd_bitmap_lock);
+static DEFINE_SPINLOCK(iommu_table_lock);
 
 /* List of all available dev_data structures */
-static LIST_HEAD(dev_data_list);
-static DEFINE_SPINLOCK(dev_data_list_lock);
+static LLIST_HEAD(dev_data_list);
 
 LIST_HEAD(ioapic_map);
 LIST_HEAD(hpet_map);
@@ -204,40 +205,33 @@ static struct dma_ops_domain* to_dma_ops_domain(struct 
protection_domain *domain
 static struct iommu_dev_data *alloc_dev_data(u16 devid)
 {
struct iommu_dev_data *dev_data;
-   unsigned long flags;
 
dev_data = kzalloc(sizeof(*dev_data), GFP_KERNEL);
if (!dev_data)
return NULL;
 
dev_data->devid = devid;
-
-   spin_lock_irqsave(_data_list_lock, flags);
-   list_add_tail(_data->dev_data_list, _data_list);
-   spin_unlock_irqrestore(_data_list_lock, flags);
-
ratelimit_default_init(_data->rs);
 
+   llist_add(_data->dev_data_list, _data_list);
return dev_data;
 }
 
 static struct iommu_dev_data *search_dev_data(u16 devid)
 {
struct iommu_dev_data *dev_data;
-   unsigned long flags;
+   struct llist_node *node;
 
-   spin_lock_irqsave(_data_list_lock, flags);
-   list_for_each_entry(dev_data, _data_list, dev_data_list) {
+   if (llist_empty(_data_list))
+   return NULL;
+
+   node = dev_data_list.first;
+   llist_for_each_entry(dev_data, node, dev_data_list) {
if (dev_data->devid == devid)
-   goto out_unlock;
+   return dev_data;
}
 
-   dev_data = NULL;
-
-out_unlock:
-   spin_unlock_irqrestore(_data_list_lock, flags);
-
-   return dev_data;
+   return NULL;
 }
 
 static int __last_alias(struct pci_dev *pdev, u16 alias, void *data)
@@ -311,6 +305,8 @@ static struct iommu_dev_data *find_dev_data(u16 devid)
 
if (dev_data == NULL) {
dev_data = alloc_dev_data(devid);
+   if (!dev_data)
+   return NULL;
 
if (translation_pre_enabled(iommu))
dev_data->defer_attach = true;
@@ -1054,9 +1050,9 @@ static int iommu_queue_command_sync(struct amd_iommu 
*iommu,
unsigned long flags;
int ret;
 
-   spin_lock_irqsave(>lock, flags);
+   raw_spin_lock_irqsave(>lock, flags);
ret = __iommu_queue_command_sync(iommu, cmd, sync);
-   spin_unlock_irqrestore(>lock, flags);
+   raw_spin_unlock_irqrestore(>lock, flags);
 
return ret;
 }
@@ -1082,7 +1078,7 @@ static int iommu_completion_wait(struct amd_iommu *iommu)
 
build_completion_wait(, (u64)>cmd_sem);
 
-   spin_lock_irqsave(>lock, flags);
+   raw_spin_lock_irqsave(>lock, flags);
 
iommu->cmd_sem = 0;
 
@@ -1093,7 +1089,7 @@ static int iommu_completion_wait(struct amd_iommu *iommu)
ret = wait_on_sem(>cmd_sem);
 
 out_unlock:
-   spin_unlock_irqrestore(>lock, flags);
+   raw_spin_unlock_irqrestore(>lock, flags);
 
return ret;
 }
@@ -1602,29 +1598,26 @@ static void del_domain_from_list(struct 
protection_domain *domain)
 
 static u16 domain_id_alloc(void)
 {
-   unsigned long flags;
int id;
 
-   write_lock_irqsave(_iommu_devtable_lock, flags);
+   spin_lock(_bitmap_lock);
id = 

Re: [virtio-dev] Re: [PATCH v2] virtio_balloon: export hugetlb page allocation counts

[Michael S. Tsirkin]

On Fri, Apr 13, 2018 at 10:10:57AM -0700, Jonathan Helman wrote:
> 
> 
> On 04/13/2018 06:44 AM, Michael S. Tsirkin wrote:
> > On Fri, Apr 13, 2018 at 03:01:11PM +0800, Jason Wang wrote:
> > > 
> > > 
> > > On 2018年04月12日 08:24, Jonathan Helman wrote:
> > > > 
> > > > 
> > > > On 04/10/2018 08:12 PM, Jason Wang wrote:
> > > > > 
> > > > > 
> > > > > On 2018年04月10日 05:11, Jonathan Helman wrote:
> > > > > > 
> > > > > > 
> > > > > > On 03/22/2018 07:38 PM, Jason Wang wrote:
> > > > > > > 
> > > > > > > 
> > > > > > > On 2018年03月22日 11:10, Michael S. Tsirkin wrote:
> > > > > > > > On Thu, Mar 22, 2018 at 09:52:18AM +0800, Jason Wang wrote:
> > > > > > > > > On 2018年03月20日 12:26, Jonathan Helman wrote:
> > > > > > > > > > > On Mar 19, 2018, at 7:31 PM, Jason
> > > > > > > > > > > Wang wrote:
> > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > On 2018年03月20日 06:14, Jonathan Helman wrote:
> > > > > > > > > > > > Export the number of successful and failed hugetlb page
> > > > > > > > > > > > allocations via the virtio balloon driver. These 2 
> > > > > > > > > > > > counts
> > > > > > > > > > > > come directly from the vm_events HTLB_BUDDY_PGALLOC and
> > > > > > > > > > > > HTLB_BUDDY_PGALLOC_FAIL.
> > > > > > > > > > > > 
> > > > > > > > > > > > Signed-off-by: Jonathan 
> > > > > > > > > > > > Helman
> > > > > > > > > > > Reviewed-by: Jason Wang
> > > > > > > > > > Thanks.
> > > > > > > > > > 
> > > > > > > > > > > > ---
> > > > > > > > > > > >     drivers/virtio/virtio_balloon.c | 6 ++
> > > > > > > > > > > >     include/uapi/linux/virtio_balloon.h | 4 +++-
> > > > > > > > > > > >     2 files changed, 9 insertions(+), 1 deletion(-)
> > > > > > > > > > > > 
> > > > > > > > > > > > diff --git
> > > > > > > > > > > > a/drivers/virtio/virtio_balloon.c
> > > > > > > > > > > > b/drivers/virtio/virtio_balloon.c
> > > > > > > > > > > > index dfe5684..6b237e3 100644
> > > > > > > > > > > > --- a/drivers/virtio/virtio_balloon.c
> > > > > > > > > > > > +++ b/drivers/virtio/virtio_balloon.c
> > > > > > > > > > > > @@ -272,6 +272,12 @@ static unsigned int
> > > > > > > > > > > > update_balloon_stats(struct
> > > > > > > > > > > > virtio_balloon *vb)
> > > > > > > > > > > > pages_to_bytes(events[PSWPOUT]));
> > > > > > > > > > > >     update_stat(vb, idx++,
> > > > > > > > > > > > VIRTIO_BALLOON_S_MAJFLT,
> > > > > > > > > > > > events[PGMAJFAULT]);
> > > > > > > > > > > >     update_stat(vb, idx++,
> > > > > > > > > > > > VIRTIO_BALLOON_S_MINFLT,
> > > > > > > > > > > > events[PGFAULT]);
> > > > > > > > > > > > +#ifdef CONFIG_HUGETLB_PAGE
> > > > > > > > > > > > +    update_stat(vb, idx++, 
> > > > > > > > > > > > VIRTIO_BALLOON_S_HTLB_PGALLOC,
> > > > > > > > > > > > +    events[HTLB_BUDDY_PGALLOC]);
> > > > > > > > > > > > +    update_stat(vb, idx++, 
> > > > > > > > > > > > VIRTIO_BALLOON_S_HTLB_PGFAIL,
> > > > > > > > > > > > +    events[HTLB_BUDDY_PGALLOC_FAIL]);
> > > > > > > > > > > > +#endif
> > > > > > > > > > > >     #endif
> > > > > > > > > > > >     update_stat(vb, idx++, VIRTIO_BALLOON_S_MEMFREE,
> > > > > > > > > > > >     pages_to_bytes(i.freeram));
> > > > > > > > > > > > diff --git
> > > > > > > > > > > > a/include/uapi/linux/virtio_balloon.h
> > > > > > > > > > > > b/include/uapi/linux/virtio_balloon.h
> > > > > > > > > > > > index 4e8b830..40297a3 100644
> > > > > > > > > > > > --- a/include/uapi/linux/virtio_balloon.h
> > > > > > > > > > > > +++ b/include/uapi/linux/virtio_balloon.h
> > > > > > > > > > > > @@ -53,7 +53,9 @@ struct virtio_balloon_config {
> > > > > > > > > > > >     #define VIRTIO_BALLOON_S_MEMTOT   5
> > > > > > > > > > > > /* Total amount of memory */
> > > > > > > > > > > >     #define VIRTIO_BALLOON_S_AVAIL    6
> > > > > > > > > > > > /* Available memory as in /proc */
> > > > > > > > > > > >     #define VIRTIO_BALLOON_S_CACHES   7   /* Disk 
> > > > > > > > > > > > caches */
> > > > > > > > > > > > -#define VIRTIO_BALLOON_S_NR   8
> > > > > > > > > > > > +#define VIRTIO_BALLOON_S_HTLB_PGALLOC
> > > > > > > > > > > > 8  /* Hugetlb page allocations */
> > > > > > > > > > > > +#define VIRTIO_BALLOON_S_HTLB_PGFAIL
> > > > > > > > > > > > 9  /* Hugetlb page allocation failures
> > > > > > > > > > > > */
> > > > > > > > > > > > +#define VIRTIO_BALLOON_S_NR   10
> > > > > > > > > > > >   /*
> > > > > > > > > > > >      * Memory statistics structure.
> > > > > > > > > > > Not for this patch, but it looks to me that
> > > > > > > > > > > exporting such nr through uapi is fragile.
> > > > > > > > > > Sorry, can you explain what you mean here?
> > > > > > > > > > 
> > > > > > > > > > Jon
> > > > > > > > > Spec said "Within an output buffer submitted to the
> > > > > > > > > statsq, the device MUST
> > > > > > > > > ignore entries with tag values that it does not
> > > > > > > > > recognize". So exporting
> > > > > > > > > 

Re: [PATCH] parisc: Switch to generic COMPAT_BINFMT_ELF

[Helge Deller]

* Guenter Roeck :
> On Wed, Apr 11, 2018 at 09:09:53AM +0200, Helge Deller wrote:
> > Drop our own compat binfmt implementation in
> > arch/parisc/kernel/binfmt_elf32.c in favour of the generic
> > implementation with CONFIG_COMPAT_BINFMT_ELF.
> > 
> > While cleaning up the dependencies, I noticed that ELF_PLATFORM was 
> > strangely
> > defined: On a 32-bit kernel, it was defined to "PARISC", while when running 
> > in
> > compat mode on a 64-bit kernel it was defined to "PARISC32". Since it 
> > doesn't
> > seem to be used in glibc yet, it's now defined in both cases to "PARISC". In
> > any case, it can be distinguished because it's either a 32-bit or a 64-bit 
> > ELF
> > file.
> > 
> > Signed-off-by: Helge Deller 
> 
> This patch results in:
> 
> Building parisc:a500_defconfig ... failed
> --
> Error log:
> make[2]: *** No rule to make target 'arch/parisc/kernel/binfmt_elf32.o', 
> needed
> by 'arch/parisc/kernel/built-in.a'.  Stop.
> make[2]: *** Waiting for unfinished jobs
> make[1]: *** [arch/parisc/kernel] Error 2
> make[1]: *** Waiting for unfinished jobs
> make: *** [sub-make] Error 2
> --
> Building parisc:generic-64bit_defconfig ... failed
> --
> Error log:
> make[2]: *** No rule to make target 'arch/parisc/kernel/binfmt_elf32.o', 
> needed
> by 'arch/parisc/kernel/built-in.a'.  Stop.
> 
> Indeed, arch/parisc/kernel/binfmt_elf32.o is still listed in Makefile
> for 64-bit builds.
> 
> $ git grep binfmt_elf32.o arch/parisc/
> arch/parisc/kernel/Makefile:obj-$(CONFIG_64BIT) += binfmt_elf32.o 
> sys_parisc32.o signal32.o

You are right.
I got fooled because I still had the binfmt_elf32.o object in my build
directory and so I didn't faced this build error. And even 0-day builds
didn't complained...  

Thanks for testing!

Patch below fixes it.

Helge
---

[PATCH] parisc: Fix missing binfmt_elf32.o build error

Commit 71d577db01a5 ("parisc: Switch to generic COMPAT_BINFMT_ELF")
removed the binfmt_elf32.c source file, but missed to drop the object
file from list of object files the Makefile too, which then results in a
build error.

Fixes: 71d577db01a5 ("parisc: Switch to generic COMPAT_BINFMT_ELF")
Reported-by: Guenter Roeck 
Signed-off-by: Helge Deller 


diff --git a/arch/parisc/kernel/Makefile b/arch/parisc/kernel/Makefile
index eafd06a..e5de34d 100644
--- a/arch/parisc/kernel/Makefile
+++ b/arch/parisc/kernel/Makefile
@@ -23,7 +23,7 @@ obj-$(CONFIG_SMP) += smp.o
 obj-$(CONFIG_PA11) += pci-dma.o
 obj-$(CONFIG_PCI)  += pci.o
 obj-$(CONFIG_MODULES)  += module.o
-obj-$(CONFIG_64BIT)+= binfmt_elf32.o sys_parisc32.o signal32.o
+obj-$(CONFIG_64BIT)+= sys_parisc32.o signal32.o
 obj-$(CONFIG_STACKTRACE)+= stacktrace.o
 obj-$(CONFIG_AUDIT)+= audit.o
 obj64-$(CONFIG_AUDIT)  += compat_audit.o

[PATCH] clk: qcom: Base rcg parent rate off plan frequency

[Evan Green]

_freq_tbl_determine_rate uses the pre_div found in the clock plan
multiplied by the requested rate from the caller to determine the
best parent rate to set. If the requested rate is not exactly equal
to the rate that was found in the clock plan, then using the requested
rate in parent rate calculations is incorrect. For instance, if 150MHz
was requested, but 200MHz was the match found, and that plan had a
pre_div of 3, then the parent should be set to 600MHz, not 450MHz.

Signed-off-by: Evan Green 
---
 drivers/clk/qcom/clk-rcg2.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/clk/qcom/clk-rcg2.c b/drivers/clk/qcom/clk-rcg2.c
index bbeaf9c09dbb..ec6cee8ff1bc 100644
--- a/drivers/clk/qcom/clk-rcg2.c
+++ b/drivers/clk/qcom/clk-rcg2.c
@@ -211,6 +211,7 @@ static int _freq_tbl_determine_rate(struct clk_hw *hw, 
const struct freq_tbl *f,
clk_flags = clk_hw_get_flags(hw);
p = clk_hw_get_parent_by_index(hw, index);
if (clk_flags & CLK_SET_RATE_PARENT) {
+   rate = f->freq;
if (f->pre_div) {
rate /= 2;
rate *= f->pre_div + 1;
-- 
2.17.0.484.g0c8726318c-goog

Re: Potential problem with 31e77c93e432dec7 ("sched/fair: Update blocked load when newly idle")

[Niklas Söderlund]

Hi Vincent,

On 2018-04-12 13:15:19 +0200, Niklas Söderlund wrote:
> Hi Vincent,
> 
> Thanks for your feedback.
> 
> On 2018-04-12 12:33:27 +0200, Vincent Guittot wrote:
> > Hi Niklas,
> > 
> > On 12 April 2018 at 11:18, Niklas Söderlund
> >  wrote:
> > > Hi Vincent,
> > >
> > > I have observed issues running on linus/master from a few days back [1].
> > > I'm running on a Renesas Koelsch board (arm32) and I can trigger a issue
> > > by X forwarding the v4l2 test application qv4l2 over ssh and moving the
> > > courser around in the GUI (best test case description award...). I'm
> > > sorry about the really bad way I trigger this but I can't do it in any
> > > other way, I'm happy to try other methods if you got some ideas. The
> > > symptom of the issue is a complete hang of the system for more then 30
> > > seconds and then this information is printed in the console:
> > 
> > Heiner (edded cc) also reported similar problem with his platform: a
> > dual core celeron
> > 
> > Do you confirm that your platform is a dual cortex-A15 ? At least that
> > what I have seen on web
> > This would confirm that dual system is a key point.
> 
> I can confirm that my platform is a dual core.

I tested another dual core system today Renesas M3-W ARM64 system and I 
can observe the same lockups-on that system if it helps you understand 
the problem. It seems to be much harder to trigger the issue on this 
system for some reason. Hitting return in a ssh session don't seem to 
produce the lockup while starting a GUI using X forwarding over ssh it's 
possible.

[  392.306441] INFO: rcu_preempt detected stalls on CPUs/tasks:
[  392.312201]  (detected by 0, t=19366 jiffies, g=7177, c=7176, q=35)
[  392.318555] All QSes seen, last rcu_preempt kthread activity 19368 
(4294990375-4294971007), jiffies_till_next_fqs=1, root ->qsmask 0x0
[  392.330758] swapper/0   R  running task0 0  0 
0x0022
[  392.337883] Call trace:
[  392.340365]  dump_backtrace+0x0/0x1c8
[  392.344065]  show_stack+0x14/0x20
[  392.347416]  sched_show_task+0x224/0x2e8
[  392.351377]  rcu_check_callbacks+0x8ac/0x8b0
[  392.355686]  update_process_times+0x2c/0x58
[  392.359908]  tick_sched_handle.isra.5+0x30/0x50
[  392.364479]  tick_sched_timer+0x40/0x90
[  392.368351]  __hrtimer_run_queues+0xfc/0x208
[  392.372659]  hrtimer_interrupt+0xd4/0x258
[  392.376710]  arch_timer_handler_virt+0x28/0x48
[  392.381194]  handle_percpu_devid_irq+0x80/0x138
[  392.385767]  generic_handle_irq+0x28/0x40
[  392.389813]  __handle_domain_irq+0x5c/0xb8
[  392.393946]  gic_handle_irq+0x58/0xa8
[  392.397640]  el1_irq+0xb4/0x130
[  392.400810]  arch_cpu_idle+0x14/0x20
[  392.404422]  default_idle_call+0x1c/0x38
[  392.408381]  do_idle+0x17c/0x1f8
[  392.411640]  cpu_startup_entry+0x20/0x28
[  392.415598]  rest_init+0x24c/0x260
[  392.419037]  start_kernel+0x3e8/0x414

I was running the same tests on another ARM64 platform earlier using the 
same build which have more then two cores and there I could not observe 
this issue.

-- 
Regards,
Niklas Söderlund

Re: [PATCH 21/30] stack-protector: test compiler capability in Kconfig and drop AUTO mode

[Kees Cook]

On Fri, Apr 13, 2018 at 11:11 AM, Linus Torvalds
 wrote:
> config STACKPROTECTOR_FLAGS
> string
> default "-fstack-protector-strong" if CC_STACKPROTECTOR_STRONG
> default "-fstack-protector" if CC_STACKPROTECTOR
> default "-fno-stack-protector" if CC_HAS_STACKPROTECTOR_NONE
> default ""
>
> which is really simple and straightforward. In the presense of
> multiple defaults, the first is picked, so this _automatically_ does
> that whole priority ordering.

Ah, perfect! Yes, this is a much better solution.

-Kees

-- 
Kees Cook
Pixel Security

[PATCH v2] media: ir-spi: update Andi's e-mail

[Andi Shyti]

From: Andi Shyti 

Because I will be leaving Samsung soon, update my e-mail to the
etezian.org mail.

CC: Mauro Carvalho Chehab 
CC: Sean Young 
Signed-off-by: Andi Shyti 
---
Hi Sean,

thanks for the review and sorry for the late reply. Here is the
patch with my mail changed also in the MODULE_AUTHOR macro.

Thanks,
Andi

v1 - v2
changed the mail also in the MODULE_AUTHOR macro

 drivers/media/rc/ir-spi.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/rc/ir-spi.c b/drivers/media/rc/ir-spi.c
index 7163d5ce2e64..66334e8d63ba 100644
--- a/drivers/media/rc/ir-spi.c
+++ b/drivers/media/rc/ir-spi.c
@@ -2,7 +2,7 @@
 // SPI driven IR LED device driver
 //
 // Copyright (c) 2016 Samsung Electronics Co., Ltd.
-// Copyright (c) Andi Shyti 
+// Copyright (c) Andi Shyti 
 
 #include 
 #include 
@@ -173,6 +173,6 @@ static struct spi_driver ir_spi_driver = {
 
 module_spi_driver(ir_spi_driver);
 
-MODULE_AUTHOR("Andi Shyti ");
+MODULE_AUTHOR("Andi Shyti ");
 MODULE_DESCRIPTION("SPI IR LED");
 MODULE_LICENSE("GPL v2");
-- 
2.17.0

Re: [PATCH v2 1/5] clk: Extract OF clock helpers in

[Rob Herring]

On Tue, Apr 10, 2018 at 02:51:37PM +0200, Geert Uytterhoeven wrote:
> The use of of_clk_get_parent_{count,name}() and of_clk_init() is not
> limited to clock providers.
> 
> Hence move these helpers into their own header file, so callers that are
> not clock providers no longer have to include .
> 
> Suggested-by: Stephen Boyd 
> Signed-off-by: Geert Uytterhoeven 
> ---
> v2:
>   - New.
> 
> I have't added an SPDX-License-Identifier line, as
>  also doesn't have one yet.

Should that matter?

> 
> Other candidates to be moved here later?
>   - of_clk_get(),
>   - of_clk_get_by_name(),
>   - of_clk_get_from_provider().
> ---
>  include/linux/clk-provider.h | 14 +-
>  include/linux/of_clk.h   | 29 +

Please update MAINTAINERS so I am not the maintainer. :)

>  2 files changed, 30 insertions(+), 13 deletions(-)
>  create mode 100644 include/linux/of_clk.h

[PATCH] spi: meson-axg: Fix error handling in meson_spicc_probe()

[Alexey Khoroshilov]

If devm_spi_register_master() fails in meson_spicc_probe(),
spicc->core is left undisabled. The patch fixes that.

Found by Linux Driver Verification project (linuxtesting.org).

Signed-off-by: Alexey Khoroshilov 
---
 drivers/spi/spi-meson-spicc.c | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/spi/spi-meson-spicc.c b/drivers/spi/spi-meson-spicc.c
index 5c82910e3480..7fe4488ace57 100644
--- a/drivers/spi/spi-meson-spicc.c
+++ b/drivers/spi/spi-meson-spicc.c
@@ -574,10 +574,15 @@ static int meson_spicc_probe(struct platform_device *pdev)
master->max_speed_hz = rate >> 2;
 
ret = devm_spi_register_master(>dev, master);
-   if (!ret)
-   return 0;
+   if (ret) {
+   dev_err(>dev, "spi master registration failed\n");
+   goto out_clk;
+   }
 
-   dev_err(>dev, "spi master registration failed\n");
+   return 0;
+
+out_clk:
+   clk_disable_unprepare(spicc->core);
 
 out_master:
spi_master_put(master);
-- 
2.7.4

Re: [Regression] PCI / PM: Simplify device wakeup settings code

[Rafael J. Wysocki]

On Fri, Apr 13, 2018 at 7:56 PM, Joseph Salisbury
 wrote:
> Hi Rafael,
>
> A kernel bug report was opened against Ubuntu [0].  After a kernel
> bisect, it was found that reverting the following two commits resolved
> this bug:
>
> 0ce3fcaff929 ("PCI / PM: Restore PME Enable after config space restoration")
> 0847684cfc5f("PCI / PM: Simplify device wakeup settings code")
>
> This is a regression introduced in v4.13-rc1 and still exists in
> mainline.  The bug causes the battery to drain when the system is
> powered down and unplugged, which does not happed prior to these two
> commits.

What system and what do you mean by "powered down"?  How much time
does it take for the battery to drain now?

> The bisect actually pointed to commit de3ef1e, but reverting
> these two commits fixes the issue.
>
> I was hoping to get your feedback, since you are the patch author.  Do
> you think gathering any additional data will help diagnose this issue,
> or would it be best to submit a revert request?

First, reverting these is not an option or you will break systems
relying on them now.  4.13 is three releases back at this point.

Second, your issue appears to be related to the suspend/shutdown path
whereas commit 0ce3fcaff929 is mostly about resume, so presumably the
change in pci_enable_wake() causes the problem to happen.  Can you try
to revert this one alone and see if that helps?

Re: [PATCH v2 1/2] mtd: rawnand: gpmi: add support for specific ECC strength

[Han Xu]

On 03/04/2018 02:06 PM, Stefan Agner wrote:
> Add support for specified ECC strength/size using device tree
> properties nand-ecc-strength/nand-ecc-step-size.
> 
> Signed-off-by: Stefan Agner 
> ---
>   drivers/mtd/nand/gpmi-nand/gpmi-nand.c | 30 --
>   1 file changed, 20 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c 
> b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
> index 61fdd733492f..d04754289c03 100644
> --- a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
> +++ b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
> @@ -198,17 +198,16 @@ static inline bool gpmi_check_ecc(struct gpmi_nand_data 
> *this)
>*
>* We may have available oob space in this case.
>*/
> -static int set_geometry_by_ecc_info(struct gpmi_nand_data *this)
> +static int set_geometry_by_ecc_info(struct gpmi_nand_data *this,
> + unsigned int ecc_strength,
> + unsigned int ecc_step)
>   {
>   struct bch_geometry *geo = >bch_geometry;
>   struct nand_chip *chip = >nand;
>   struct mtd_info *mtd = nand_to_mtd(chip);
>   unsigned int block_mark_bit_offset;
>   
> - if (!(chip->ecc_strength_ds > 0 && chip->ecc_step_ds > 0))
> - return -EINVAL;
> -
> - switch (chip->ecc_step_ds) {
> + switch (ecc_step) {
>   case SZ_512:
>   geo->gf_len = 13;
>   break;
> @@ -221,8 +220,8 @@ static int set_geometry_by_ecc_info(struct gpmi_nand_data 
> *this)
>   chip->ecc_strength_ds, chip->ecc_step_ds);
>   return -EINVAL;
>   }
> - geo->ecc_chunk_size = chip->ecc_step_ds;
> - geo->ecc_strength = round_up(chip->ecc_strength_ds, 2);
> + geo->ecc_chunk_size = ecc_step;
> + geo->ecc_strength = round_up(ecc_strength, 2);
>   if (!gpmi_check_ecc(this))
>   return -EINVAL;
>   
> @@ -230,7 +229,7 @@ static int set_geometry_by_ecc_info(struct gpmi_nand_data 
> *this)
>   if (geo->ecc_chunk_size < mtd->oobsize) {
>   dev_err(this->dev,
>   "unsupported nand chip. ecc size: %d, oob size : %d\n",
> - chip->ecc_step_ds, mtd->oobsize);
> + ecc_step, mtd->oobsize);
>   return -EINVAL;
>   }
>   
> @@ -423,9 +422,20 @@ static int legacy_set_geometry(struct gpmi_nand_data 
> *this)
>   
>   int common_nfc_set_geometry(struct gpmi_nand_data *this)
>   {
> + struct nand_chip *chip = >nand;
> +
> + if (chip->ecc.strength > 0 && chip->ecc.size > 0)
> + return set_geometry_by_ecc_info(this, chip->ecc.strength,
> + chip->ecc.size);
> +
>   if ((of_property_read_bool(this->dev->of_node, "fsl,use-minimum-ecc"))
> - || legacy_set_geometry(this))
> - return set_geometry_by_ecc_info(this);
> + || legacy_set_geometry(this)) {
> + if (!(chip->ecc_strength_ds > 0 && chip->ecc_step_ds > 0))
> + return -EINVAL;
> +
> + return set_geometry_by_ecc_info(this, chip->ecc_strength_ds,
> + chip->ecc_step_ds);
> + }
>   
>   return 0;
>   }
> 

Acked-by: Han Xu 

Re: [PATCH] Input: i8042 - Fix KBD port cannot wake up system from suspend-to-idle

[Dmitry Torokhov]

On Wed, Apr 11, 2018 at 04:59:05PM +0800, Kai-Heng Feng wrote:
> Commit f13b2065de81 ("Input: i8042 - allow KBD and AUX ports to wake up
> from suspend-to-idle") make system in s2idle can be woken up by i8042
> keyboard, but it's disabled by default.
> 
> In commit 3e6e15a862a0 ("Input: enable remote wakeup for PNP i8042
> keyboard ports") states that "Keyboard ports are always supposed to be
> wakeup-enabled", it should be enabled by default. Keyboard wakeup from
> s2idles is also the default behavior for other OSes.
> 
> But right now we can't wake up the system by keyboard, from s2idle.
> 
> In i8042_probe(), device_set_wakeup_enable(), which gets called by
> i8042_pnp_kbd_probe(), runs before device_set_wakeup_capable(), which
> gets called by i8042_register_ports(). So device_set_wakeup_enable()
> doesn't really enable wakeup for keyboard.

You are talking about 2 different devices here, one representing PNP and
another KBD serio port. Unfortunately there is not really a link between
the 2.

> 
> We can enable keyboard wakeup in i8042_register_ports() directly.

No, the world is not all x86, what makes sense for x86 does not
necessarily work for other architectures. We need to come up with a way
for tying PNP devices and i8042 ports for x86 case.

> 
> Signed-off-by: Kai-Heng Feng 
> ---
>  drivers/input/serio/i8042-x86ia64io.h | 3 ---
>  drivers/input/serio/i8042.c   | 4 
>  2 files changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/input/serio/i8042-x86ia64io.h 
> b/drivers/input/serio/i8042-x86ia64io.h
> index b353d494ad40..e3def9195c2a 100644
> --- a/drivers/input/serio/i8042-x86ia64io.h
> +++ b/drivers/input/serio/i8042-x86ia64io.h
> @@ -925,9 +925,6 @@ static int i8042_pnp_kbd_probe(struct pnp_dev *dev, const 
> struct pnp_device_id *
>   i8042_pnp_id_to_string(dev->id, i8042_kbd_firmware_id,
>  sizeof(i8042_kbd_firmware_id));
>  
> - /* Keyboard ports are always supposed to be wakeup-enabled */
> - device_set_wakeup_enable(>dev, true);
> -
>   i8042_pnp_kbd_devices++;
>   return 0;
>  }
> diff --git a/drivers/input/serio/i8042.c b/drivers/input/serio/i8042.c
> index 824f4c1c1f31..21a16b757931 100644
> --- a/drivers/input/serio/i8042.c
> +++ b/drivers/input/serio/i8042.c
> @@ -1400,6 +1400,10 @@ static void __init i8042_register_ports(void)
>   i8042_ports[i].irq);
>   serio_register_port(serio);
>   device_set_wakeup_capable(>dev, true);
> +
> + /* Keyboard ports are always supposed to be 
> wakeup-enabled */
> + if (i == I8042_KBD_PORT_NO)
> + device_wakeup_enable(>dev);
>   }
>   }
>  }
> -- 
> 2.17.0
> 

Thanks.

-- 
Dmitry

RE: [PATCH v1 3/7] platform/mellanox: mlxreg-hotplug: add extra cycle for hotplug work queue

[Vadim Pasternak]

> -Original Message-
> From: Darren Hart [mailto:dvh...@infradead.org]
> Sent: Friday, April 13, 2018 7:47 PM
> To: Vadim Pasternak 
> Cc: andy.shevche...@gmail.com; gre...@linuxfoundation.org; linux-
> ker...@vger.kernel.org; platform-driver-...@vger.kernel.org; j...@resnulli.us;
> Michael Shych ; ivec...@redhat.com
> Subject: Re: [PATCH v1 3/7] platform/mellanox: mlxreg-hotplug: add extra cycle
> for hotplug work queue
> 
> On Tue, Mar 27, 2018 at 10:02:03AM +, Vadim Pasternak wrote:
> > It adds missed logic for signal acknowledge, by adding an extra run
> > for work queue in case a signal is received, but no specific signal
> > assertion is detected. Such case theoretically can happen for example
> > in case several units are removed or inserted at the same time. In
> > this situation acknowledge for some signal can be missed at signal top
> > aggreagation status level.
> 
> Why can they be missed? What does "signal top aggregation status level"
> mean? I'm asking to confirm that we are fixing this at the right place, and 
> not
> just applying a suboptimal bandaid by running the workqueue more.
> 

Hi Darren,

Thank for review.

It could happen within the next flow:

The signal routing flow is as following (f.e. for of FANi removing):
 - FAN status and event registers related bit is changed;
 -- intermediate aggregation status register is changed;
 --- top aggregation status register is changed;
  interrupt routed to CPU and interrupt handler is invoked.

When interrupt handler is invoked it follows the next simple logic (f.e
FAN3 is removed):
 (a1) mask top aggregation interrupt mask register;
 (a2) read top aggregation interrupt status register and test to which
  underling group belongs a signal (FANs in this case and is changed
  from 0xff to 0xfb and 0xfb is saved as a last status value);
   (b1) mask FANs interrupt mask register;
   (b2) read FANs status register and test which FAN has been changed (FAN3 in
this example);
 (c1) perform relevant action;
  <--- (FAN2 is removed at this point)
   (b3) clear FANs interrupt event register to acknowledge FAN3 signal;
   (b4) unmask FANs interrupt mask register
 (a3) unmask top aggregation interrupt mask register;
 
 An interrupt handler is invoked, since FAN2 interrupt is not acknowledge.
 It should set top aggregation interrupt status register bit 6 (0xfb).
 In step (a2)
 (a2) read top aggregation interrupt and comparing it with saved value doesn't
  show change (same 0xfb) and after (a2) execution jumps to (a3) and
  signal leaved unhandled.

> ...
> 
> >
> > Fixes: 1f976f6978bf ("platform/x86: Move Mellanox platform hotplug
> > driver to platform/mellanox")
> 
> You didn't mention above how this commit caused this - how did moving the
> driver create this problem? 

Actually I should reference to 
07b89c2b2a5e ("platform/x86: Introduce support for Mellanox hotplug driver")
which was initial driver commit, before it has been relocated. 

Does this need to go to stable? I'm assuming not as
> you've called it theoretical - not something you've observed in practice?
> 

It's not necessary to go to stable.

> ...
> 
> >  static int mlxreg_hotplug_device_create(struct
> > mlxreg_hotplug_priv_data *priv, @@ -410,6 +413,18 @@ static void
> mlxreg_hotplug_work_handler(struct work_struct *work)
> > aggr_asserted = priv->aggr_cache ^ regval;
> > priv->aggr_cache = regval;
> >
> > +   /*
> > +* Handler is invoked, but no assertion is detected at top aggregation
> > +* status level. Set aggr_asserted to mask value to allow handler extra
> > +* run over all relevant signals to recover any missed signal.
> > +*/
> > +   if (priv->not_asserted == MLXREG_HOTPLUG_NOT_ASSERT) {
> > +   priv->not_asserted = 0;
> > +   aggr_asserted = pdata->mask;
> > +   }
> > +   if (!aggr_asserted)
> 
> We seem to check aggr_asserted in several places in this routine now.
> Looks like something we could simplify. If you check it here, can you drop the
> check lower in the routine? Can you remove it from the for loop if conditional
> entirely? Please consider how to simplify.

OK, will review this code.

> 
> --
> Darren Hart
> VMware Open Source Technology Center

Re: sparc/ppc/arm compat siginfo ABI regressions: sending SIGFPE via kill() returns wrong values in si_pid and si_uid

[Linus Torvalds]

On Fri, Apr 13, 2018 at 11:45 AM, Dave Martin  wrote:
>
> Most uses I've seen do nothing more than use the FPE_xyz value to
> format diagnostic messages while dying.  I struggled to find code that
> made a meaningful functional decision based on the value, though that's
> not proof...

Yeah. I've seen code that cares about SIGFPE deeply, but it's almost
invariably about some emulated environment (eg Java VM, or CPU
emulation).

And the siginfo data is basically never good enough for those
environments anyway on its own, so they will go and look at the actual
instruction that caused the fault and the register state instead,
because they need *all* the information.

The cases that use si_code are the ones that just trapped signals in
order to give a more helpful abort message.

So I could certainly imagine that si_code is actually used by somebody
who then decides to actuall act differently on it, but aside from
perhaps printing out a different message, it sounds far-fetched.

Linus

Re: [PATCH 02/24] Add a SysRq option to lift kernel lockdown

[Pavel Machek]

On Wed 2018-04-11 17:24:52, David Howells wrote:
> From: Kyle McMartin 
> 
> Make an option to provide a sysrq key that will lift the kernel lockdown,
> thereby allowing the running kernel image to be accessed and modified.
> 
> On x86 this is triggered with SysRq+x, but this key may not be available on
> all arches, so it is set by setting LOCKDOWN_LIFT_KEY in asm/setup.h.
> Since this macro must be defined in an arch to be able to use this facility
> for that arch, the Kconfig option is restricted to arches that support it.
> 
> Signed-off-by: Kyle McMartin 
> Signed-off-by: David Howells 
> cc: x...@kernel.org

Is that good idea? Magic sysrq was meant for debugging, not for
toggling options like that. Distros are expected to turn it off.

It also works over serial consoles etc, being able to toggle security
options from serial is surprising...

> --- a/drivers/tty/sysrq.c
> +++ b/drivers/tty/sysrq.c
> @@ -487,6 +487,7 @@ static struct sysrq_key_op *sysrq_key_table[36] = {
>   /* x: May be registered on mips for TLB dump */
>   /* x: May be registered on ppc/powerpc for xmon */
>   /* x: May be registered on sparc64 for global PMU dump */
> + /* x: May be registered on x86_64 for disabling secure boot */
>   NULL,   /* x */

What about x86-32?

> +static struct sysrq_key_op lockdown_lift_sysrq_op = {
> + .handler= sysrq_handle_lockdown_lift,
> + .help_msg   = "unSB(x)",
> + .action_msg = "Disabling Secure Boot restrictions",
> + .enable_mask= SYSRQ_DISABLE_USERSPACE,
> +};

I'd remove secure boot mentions here.
Pavel

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


signature.asc
Description: Digital signature

Re: [PATCH 07/24] hibernate: Disable when the kernel is locked down

[Pavel Machek]

On Wed 2018-04-11 17:25:25, David Howells wrote:
> From: Josh Boyer 
> 
> There is currently no way to verify the resume image when returning
> from hibernate.  This might compromise the signed modules trust model,
> so until we can work with signed hibernate images we disable it when the
> kernel is locked down.

I'd rather see hibernation fixed than disabled like this.

I believe Jiri Kosina may have some patches for that?
Pavel

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


signature.asc
Description: Digital signature

Re: [PATCH 24/24] debugfs: Restrict debugfs when the kernel is locked down

[Pavel Machek]

On Wed 2018-04-11 17:27:16, David Howells wrote:
> Disallow opening of debugfs files that might be used to muck around when
> the kernel is locked down as various drivers give raw access to hardware
> through debugfs.  Given the effort of auditing all 2000 or so files and
> manually fixing each one as necessary, I've chosen to apply a heuristic
> instead.  The following changes are made:
> 
>  (1) chmod and chown are disallowed on debugfs objects (though the root dir
>  can be modified by mount and remount, but I'm not worried about that).

This has nothing to do with the lockdown goals, right? I find chown of
such files quite nice, to allow debugging without doing sudo all the time.

>  (2) When the kernel is locked down, only files with the following criteria
>  are permitted to be opened:
> 
>   - The file must have mode 00444
>   - The file must not have ioctl methods
>   - The file must not have mmap

Dunno. Would not it be nicer to go through the debugfs files and split
them into safe/unsafe varieties?

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


signature.asc
Description: Digital signature

Re: [PATCH 00/32] docs/vm: convert to ReST format

[Matthew Wilcox]

On Fri, Apr 13, 2018 at 01:55:51PM -0600, Jonathan Corbet wrote:
> > I believe that keeping the mm docs together will give better visibility of
> > what (little) mm documentation we have and will make the updates easier.
> > The documents that fit well into a certain topic could be linked there. For
> > instance:
> 
> ...but this sounds like just the opposite...?  
> 
> I've had this conversation with folks in a number of subsystems.
> Everybody wants to keep their documentation together in one place - it's
> easier for the developers after all.  But for the readers I think it's
> objectively worse.  It perpetuates the mess that Documentation/ is, and
> forces readers to go digging through all kinds of inappropriate material
> in the hope of finding something that tells them what they need to know.
> 
> So I would *really* like to split the documentation by audience, as has
> been done for a number of other kernel subsystems (and eventually all, I
> hope).
> 
> I can go ahead and apply the RST conversion, that seems like a step in
> the right direction regardless.  But I sure hope we don't really have to
> keep it as an unorganized jumble of stuff...

I've started on Documentation/core-api/memory.rst which covers just
memory allocation.  So far it has the Overview and GFP flags sections
written and an outline for 'The slab allocator', 'The page allocator',
'The vmalloc allocator' and 'The page_frag allocator'.  And typing this
up, I realise we need a 'The percpu allocator'.  I'm thinking that this
is *not* the right document for the DMA memory allocators (although it
should link to that documentation).

I suspect the existing Documentation/vm/ should probably stay as an
unorganised jumble of stuff.  Developers mostly talking to other MM
developers.  Stuff that people outside the MM fraternity should know
about needs to be centrally documented.  By all means convert it to
ReST ... I don't much care, and it may make it easier to steal bits
or link to it from the organised documentation.

Re: [PATCH v3] selftests/livepatch: introduce tests

[Joe Lawrence]

On 04/13/2018 07:20 AM, Miroslav Benes wrote:
> Hi,
> 
> On Thu, 12 Apr 2018, Joe Lawrence wrote:
> 
>> Add a few livepatch modules and simple target modules that the included
>> regression suite can run tests against.
> 
> Could you include a brief description which features are tested?

I can add this to the commit msg:

  - basic livepatching (multiple patches, atomic replace)
  - pre/post (un)patch callbacks
  - shadow variable API

Or do you prefer a little more detail?

>  
>> Signed-off-by: Joe Lawrence 
>> ---
> 
>> diff --git a/lib/livepatch/test_klp_shadow_vars.c 
>> b/lib/livepatch/test_klp_shadow_vars.c
>> new file mode 100644
>> index ..18c75b21cb9e
>> --- /dev/null
>> +++ b/lib/livepatch/test_klp_shadow_vars.c
>>
>> +/*
>> + * Shadow variable wrapper functions that echo the function and arguments
>> + * to the kernel log for testing verification.  Don't display raw pointers,
>> + * but use the ptr_id() value instead.
>> + */
>> +void *shadow_get(void *obj, unsigned long id)
>> +{
>> +void *ret = klp_shadow_get(obj, id);
>> +
>> +pr_info("klp_%s(obj=PTR%d, id=0x%lx) = PTR%d\n",
>> +__func__, ptr_id(obj), id, ptr_id(ret));
>> +
>> +return ret;
>> +}
> 
>> +void shadow_free(void *obj, unsigned long id, klp_shadow_dtor_t dtor)
>> +{
>> +klp_shadow_free(obj, id, dtor);
>> +pr_info("klp_%s(obj=PTR%d, id=0x%lx, dtor=PTR%d)\n",
>> +__func__, ptr_id(obj), id, ptr_id(dtor));
>> +}
> 
> Sparse (make C=1) would be happier with those two being static.

Ah right. I wonder why the kbuild test robot didn't complain about
those, too.  Easy enough to fix up, thanks.

> Otherwise it works as expected. Good job!

Thanks for reviewing.  I'll hold off on posting v4 until Petr (and
others) get a chance to comment.  Perhaps there are other tests that
would be helpful?

-- Joe

Re: [PATCH] configfs: inherit file and directory owners

[kbuild test robot]

Hi Gwendal,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on linus/master]
[also build test ERROR on v4.16 next-20180413]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Gwendal-Grignou/configfs-inherit-file-and-directory-owners/20180414-041333
config: i386-randconfig-x014-201814 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   fs/configfs/inode.c: In function 'alloc_iattr':
>> fs/configfs/inode.c:75:25: error: 'CURRENT_TIME' undeclared (first use in 
>> this function); did you mean 'MS_RELATIME'?
   sd_iattr->ia_ctime = CURRENT_TIME;
^~~~
MS_RELATIME
   fs/configfs/inode.c:75:25: note: each undeclared identifier is reported only 
once for each function it appears in

vim +75 fs/configfs/inode.c

56  
57  static struct iattr *alloc_iattr(struct configfs_dirent *sd_parent,
58  struct configfs_dirent 
*sd)
59  {
60  struct iattr *sd_iattr;
61  
62  sd_iattr = kzalloc(sizeof(struct iattr), GFP_KERNEL);
63  if (!sd_iattr)
64  return NULL;
65  /* assign default attributes */
66  sd_iattr->ia_mode = sd->s_mode;
67  if (sd_parent && sd_parent->s_iattr) {
68  sd_iattr->ia_uid = sd_parent->s_iattr->ia_uid;
69  sd_iattr->ia_gid = sd_parent->s_iattr->ia_gid;
70  } else {
71  sd_iattr->ia_uid = GLOBAL_ROOT_UID;
72  sd_iattr->ia_gid = GLOBAL_ROOT_GID;
73  }
74  sd_iattr->ia_atime = sd_iattr->ia_mtime =
  > 75  sd_iattr->ia_ctime = CURRENT_TIME;
76  return sd_iattr;
77  }
78  

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


.config.gz
Description: application/gzip

Re: [PATCH v8 1/2] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder

[Rob Herring]

On Tue, Apr 10, 2018 at 12:53:09PM +0200, Jacopo Mondi wrote:
> Document Thine THC63LVD1024 LVDS decoder device tree bindings.
> 
> Signed-off-by: Jacopo Mondi 
> Reviewed-by: Andrzej Hajda 
> Reviewed-by: Niklas Söderlund 
> Reviewed-by: Laurent Pinchart 
> ---
>  .../bindings/display/bridge/thine,thc63lvd1024.txt | 60 
> ++
>  1 file changed, 60 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt

Reviewed-by: Rob Herring 

Re: [PATCH] MAINTAINERS: Adding backup maintainers for libnvdimm and DAX

[Vishal Verma]

On Fri, 2018-04-13 at 15:03 -0600, Ross Zwisler wrote:
> On Fri, Apr 13, 2018 at 01:47:40PM -0700, Dave Jiang wrote:
> > Adding additional maintainers to libnvdimm related code and DAX.
> > 
> > Signed-off-by: Dave Jiang 
> 
> This is fine with me:
> 
> Acked-by: Ross Zwisler 

Fine by me as well

Acked-by: Vishal Verma 

> ___
> Linux-nvdimm mailing list
> linux-nvd...@lists.01.org
> https://lists.01.org/mailman/listinfo/linux-nvdimm

Re: [PATCH v3 01/11] PCI/P2PDMA: Support peer-to-peer memory

[Stephen Bates]

 
>  I'll see if I can get our PCI SIG people to follow this through 

Hi Jonathan

Can you let me know if this moves forward within PCI-SIG? I would like to track 
it. I can see this being doable between Root Ports that reside in the same Root 
Complex but might become more challenging to standardize for RPs that reside in 
different RCs in the same (potentially multi-socket) system. I know in the past 
we have seem MemWr TLPS cross the QPI bus in Intel systems but I am sure that 
is not something that would work in all systems and must fall outside the remit 
of PCI-SIG ;-).

I agree such a capability bit would be very useful but it's going to be quite 
some time before we can rely on hardware being available that supports it.

Stephen

Re: [PATCH v2 2/2] dt-bindings: mtd: rawnand: gpmi: document specific ECC strength

[Han Xu]

On 03/04/2018 02:06 PM, Stefan Agner wrote:
> Document newly supported device tree properties nand-ecc-strength/
> nand-ecc-step-size to specify ECC strength/size.
> 
> Signed-off-by: Stefan Agner 
> ---
>   Documentation/devicetree/bindings/mtd/gpmi-nand.txt | 5 +
>   1 file changed, 5 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/mtd/gpmi-nand.txt 
> b/Documentation/devicetree/bindings/mtd/gpmi-nand.txt
> index b289ef3c1b7e..393588385c6e 100644
> --- a/Documentation/devicetree/bindings/mtd/gpmi-nand.txt
> +++ b/Documentation/devicetree/bindings/mtd/gpmi-nand.txt
> @@ -47,6 +47,11 @@ Optional properties:
>  partitions written from Linux with this feature
>  turned on may not be accessible by the BootROM
>  code.
> +  - nand-ecc-strength: integer representing the number of bits to correct
> +   per ECC step. Needs to be a multiple of 2.
> +  - nand-ecc-step-size: integer representing the number of data bytes
> +   that are covered by a single ECC step. The driver
> +   supports 512 and 1024.
>   
>   The device tree may optionally contain sub-nodes describing partitions of 
> the
>   address space. See partition.txt for more detail.
> 

Acked-by: Han Xu 

Compliment of the day

[Tracy William]

--

Hi dear.
It is wonderful to contact you, I want us to have correspondence. I
wish you will have the desire so that we can get acquainted to each
other. Life itself is a mystery, you never know where it might lead
you.
I'm Tracy.William, a French American . I will be pleased if you reply
through.(tracy.medce...@outlook.com)
With Love
Tracy
--

[PATCH v2 10/14] staging: iio: ad7746: Add comments

[Hernán Gonzalez]

Add comments to clarify some of the calculations made, specially when
reading or writing values.

Signed-off-by: Hernán Gonzalez 
---
 drivers/staging/iio/cdc/ad7746.c | 32 +++-
 1 file changed, 27 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/iio/cdc/ad7746.c b/drivers/staging/iio/cdc/ad7746.c
index 05506bf9..ef0ebb5 100644
--- a/drivers/staging/iio/cdc/ad7746.c
+++ b/drivers/staging/iio/cdc/ad7746.c
@@ -429,6 +429,7 @@ static int ad7746_write_raw(struct iio_dev *indio_dev,
goto out;
}
 
+   /* 2^16 in micro */
val = (val2 * 1024) / 15625;
 
switch (chan->type) {
@@ -554,6 +555,13 @@ static int ad7746_read_raw(struct iio_dev *indio_dev,
if (ret < 0)
goto out;
 
+   /*
+* Either for Capacitance, Voltage or Temperature,
+* the 0x00 code represents negative full scale,
+* the 0x80 code represents zero scale, and
+* the 0xFF code represents positive full scale.
+*/
+
*val = (be32_to_cpu(chip->data.d32) & 0xFF) - 0x80;
 
switch (chan->type) {
@@ -565,7 +573,13 @@ static int ad7746_read_raw(struct iio_dev *indio_dev,
*val = (*val * 125) / 256;
break;
case IIO_VOLTAGE:
-   if (chan->channel == 1) /* supply_raw*/
+
+   /*
+* The voltage from the VDD pin is internally
+* attenuated by 6.
+*/
+
+   if (chan->channel == 1) /* supply_raw */
*val = *val * 6;
break;
default:
@@ -606,6 +620,13 @@ static int ad7746_read_raw(struct iio_dev *indio_dev,
ret = IIO_VAL_INT;
break;
case IIO_CHAN_INFO_OFFSET:
+
+   /*
+* CAPDAC Scale = 21pF_typ / 127
+* CIN Scale = 8.192pF / 2^24
+* Offset Scale = CAPDAC Scale / CIN Scale = 338646
+*/
+
*val = AD7746_CAPDAC_DACP(chip->capdac[chan->channel]
  [chan->differential]) * 338646;
 
@@ -614,13 +635,13 @@ static int ad7746_read_raw(struct iio_dev *indio_dev,
case IIO_CHAN_INFO_SCALE:
switch (chan->type) {
case IIO_CAPACITANCE:
-   /* 8.192pf / 2^24 */
+   /* CIN Scale: 8.192pf / 2^24 */
*val =  0;
*val2 = 488;
ret = IIO_VAL_INT_PLUS_NANO;
break;
case IIO_VOLTAGE:
-   /* 1170mV / 2^23 */
+   /* VIN Scale: 1170mV / 2^23 */
*val = 1170;
*val2 = 23;
ret = IIO_VAL_FRACTIONAL_LOG2;
@@ -674,7 +695,8 @@ static struct ad7746_platform_data *ad7746_parse_dt(struct 
device *dev)
unsigned int tmp;
int ret;
 
-   /* The default excitation outputs are not inverted, it should be stated
+   /*
+* The default excitation outputs are not inverted, it should be stated
 * in the dt if needed.
 */
 
@@ -685,7 +707,7 @@ static struct ad7746_platform_data *ad7746_parse_dt(struct 
device *dev)
ret = of_property_read_u32(np, "adi,exclvl", );
if (ret || tmp > 3) {
dev_warn(dev, "Wrong exclvl value, using default\n");
-   pdata->exclvl = 3; /* default value */
+   pdata->exclvl = 3;
} else {
pdata->exclvl = tmp;
}
-- 
2.7.4

[PATCH v2 09/14] staging: iio: ad7746: Add remove()

[Hernán Gonzalez]

This allows the driver to be probed and removed as a module powering it
down on remove().

Signed-off-by: Hernán Gonzalez 
---
 drivers/staging/iio/cdc/ad7746.c | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/drivers/staging/iio/cdc/ad7746.c b/drivers/staging/iio/cdc/ad7746.c
index c29a221..05506bf9 100644
--- a/drivers/staging/iio/cdc/ad7746.c
+++ b/drivers/staging/iio/cdc/ad7746.c
@@ -775,6 +775,31 @@ static int ad7746_probe(struct i2c_client *client,
return 0;
 }
 
+static int ad7746_remove(struct i2c_client *client)
+{
+   struct iio_dev *indio_dev = i2c_get_clientdata(client);
+   struct ad7746_chip_info *chip = iio_priv(indio_dev);
+   unsigned char regval;
+   int ret;
+
+   mutex_lock(>lock);
+
+   regval = chip->config | AD7746_CONF_MODE_PWRDN;
+   ret = i2c_smbus_write_byte_data(chip->client, AD7746_REG_CFG, regval);
+
+   mutex_unlock(>lock);
+
+   if (ret < 0) {
+   dev_warn(>dev, "Could NOT Power Down!\n");
+   goto out;
+   }
+
+   iio_device_unregister(indio_dev);
+
+out:
+   return ret;
+}
+
 static const struct i2c_device_id ad7746_id[] = {
{ "ad7745", 7745 },
{ "ad7746", 7746 },
@@ -799,6 +824,7 @@ static struct i2c_driver ad7746_driver = {
.of_match_table = of_match_ptr(ad7746_of_match),
},
.probe = ad7746_probe,
+   .remove = ad7746_remove,
.id_table = ad7746_id,
 };
 module_i2c_driver(ad7746_driver);
-- 
2.7.4

[PATCH v2 06/14] staging: iio: ad7746: Reorder variable declarations

[Hernán Gonzalez]

Reorder some variable declarations in an inverse-pyramid scheme.

Signed-off-by: Hernán Gonzalez 
---
 drivers/staging/iio/cdc/ad7746.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/iio/cdc/ad7746.c b/drivers/staging/iio/cdc/ad7746.c
index 9ef476a..f53612a 100644
--- a/drivers/staging/iio/cdc/ad7746.c
+++ b/drivers/staging/iio/cdc/ad7746.c
@@ -220,8 +220,8 @@ static int ad7746_select_channel(struct iio_dev *indio_dev,
 struct iio_chan_spec const *chan)
 {
struct ad7746_chip_info *chip = iio_priv(indio_dev);
-   int ret, delay, idx;
u8 vt_setup, cap_setup;
+   int ret, delay, idx;
 
switch (chan->type) {
case IIO_CAPACITANCE:
@@ -289,8 +289,8 @@ static inline ssize_t ad7746_start_calib(struct device *dev,
 {
struct iio_dev *indio_dev = dev_to_iio_dev(dev);
struct ad7746_chip_info *chip = iio_priv(indio_dev);
-   bool doit;
int ret, timeout = 10;
+   bool doit;
 
ret = strtobool(buf, );
if (ret < 0)
@@ -680,8 +680,8 @@ static int ad7746_probe(struct i2c_client *client,
struct ad7746_platform_data *pdata = client->dev.platform_data;
struct ad7746_chip_info *chip;
struct iio_dev *indio_dev;
-   int ret = 0;
unsigned char regval = 0;
+   int ret = 0;
 
indio_dev = devm_iio_device_alloc(>dev, sizeof(*chip));
if (!indio_dev)
-- 
2.7.4

[PATCH v2 07/14] staging: iio: ad7746: Remove unused defines

[Hernán Gonzalez]

Signed-off-by: Hernán Gonzalez 
---
 drivers/staging/iio/cdc/ad7746.c | 7 ---
 drivers/staging/iio/cdc/ad7746.h | 5 -
 2 files changed, 12 deletions(-)

diff --git a/drivers/staging/iio/cdc/ad7746.c b/drivers/staging/iio/cdc/ad7746.c
index f53612a..d39ab34 100644
--- a/drivers/staging/iio/cdc/ad7746.c
+++ b/drivers/staging/iio/cdc/ad7746.c
@@ -25,7 +25,6 @@
  * AD7746 Register Definition
  */
 
-#define AD7746_REG_STATUS  0
 #define AD7746_REG_CAP_DATA_HIGH   1
 #define AD7746_REG_VT_DATA_HIGH4
 #define AD7746_REG_CAP_SETUP   7
@@ -38,12 +37,6 @@
 #define AD7746_REG_CAP_GAINH   15
 #define AD7746_REG_VOLT_GAINH  17
 
-/* Status Register Bit Designations (AD7746_REG_STATUS) */
-#define AD7746_STATUS_EXCERR   BIT(3)
-#define AD7746_STATUS_RDY  BIT(2)
-#define AD7746_STATUS_RDYVTBIT(1)
-#define AD7746_STATUS_RDYCAP   BIT(0)
-
 /* Capacitive Channel Setup Register Bit Designations (AD7746_REG_CAP_SETUP) */
 #define AD7746_CAPSETUP_CAPEN  BIT(7)
 #define AD7746_CAPSETUP_CIN2   BIT(6) /* AD7746 only */
diff --git a/drivers/staging/iio/cdc/ad7746.h b/drivers/staging/iio/cdc/ad7746.h
index ea8572d..2fbcee8 100644
--- a/drivers/staging/iio/cdc/ad7746.h
+++ b/drivers/staging/iio/cdc/ad7746.h
@@ -13,11 +13,6 @@
  * TODO: struct ad7746_platform_data needs to go into include/linux/iio
  */
 
-#define AD7466_EXCLVL_00 /* +-VDD/8 */
-#define AD7466_EXCLVL_11 /* +-VDD/4 */
-#define AD7466_EXCLVL_22 /* +-VDD * 3/8 */
-#define AD7466_EXCLVL_33 /* +-VDD/2 */
-
 struct ad7746_platform_data {
unsigned char exclvl;   /*Excitation Voltage Level */
bool exca_en;   /* enables EXCA pin as the excitation output */
-- 
2.7.4

[PATCH v2 08/14] staging: iio: ad7746: Add dt-bindings

[Hernán Gonzalez]

This patch adds dt bindings by populating a pdata struct in order to
modify as little as possible the existing code. It supports both
platform_data and dt-bindings but uses only one depending on
CONFIG_OF's value.

Signed-off-by: Hernán Gonzalez 
---
 drivers/staging/iio/cdc/ad7746.c | 54 +++-
 1 file changed, 53 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/iio/cdc/ad7746.c b/drivers/staging/iio/cdc/ad7746.c
index d39ab34..c29a221 100644
--- a/drivers/staging/iio/cdc/ad7746.c
+++ b/drivers/staging/iio/cdc/ad7746.c
@@ -666,6 +666,43 @@ static const struct iio_info ad7746_info = {
 /*
  * device probe and remove
  */
+#ifdef CONFIG_OF
+static struct ad7746_platform_data *ad7746_parse_dt(struct device *dev)
+{
+   struct device_node *np = dev->of_node;
+   struct ad7746_platform_data *pdata;
+   unsigned int tmp;
+   int ret;
+
+   /* The default excitation outputs are not inverted, it should be stated
+* in the dt if needed.
+*/
+
+   pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
+   if (!pdata)
+   return NULL;
+
+   ret = of_property_read_u32(np, "adi,exclvl", );
+   if (ret || tmp > 3) {
+   dev_warn(dev, "Wrong exclvl value, using default\n");
+   pdata->exclvl = 3; /* default value */
+   } else {
+   pdata->exclvl = tmp;
+   }
+
+   pdata->exca_en = true;
+   pdata->excb_en = true;
+   pdata->exca_inv_en = of_property_read_bool(np, "adi,nexca_en");
+   pdata->excb_inv_en = of_property_read_bool(np, "adi,nexcb_en");
+
+   return pdata;
+}
+#else
+static struct ad7746_platform_data *ad7746_parse_dt(struct device *dev)
+{
+   return NULL;
+}
+#endif
 
 static int ad7746_probe(struct i2c_client *client,
const struct i2c_device_id *id)
@@ -676,6 +713,11 @@ static int ad7746_probe(struct i2c_client *client,
unsigned char regval = 0;
int ret = 0;
 
+   if (client->dev.of_node)
+   pdata = ad7746_parse_dt(>dev);
+   else
+   pdata = client->dev.platform_data;
+
indio_dev = devm_iio_device_alloc(>dev, sizeof(*chip));
if (!indio_dev)
return -ENOMEM;
@@ -739,12 +781,22 @@ static const struct i2c_device_id ad7746_id[] = {
{ "ad7747", 7747 },
{}
 };
-
 MODULE_DEVICE_TABLE(i2c, ad7746_id);
 
+#ifdef CONFIG_OF
+static const struct of_device_id ad7746_of_match[] = {
+   { .compatible = "adi,ad7745" },
+   { .compatible = "adi,ad7746" },
+   { .compatible = "adi,ad7747" },
+   { }
+};
+MODULE_DEVICE_TABLE(of, ad7746_of_match);
+#endif
+
 static struct i2c_driver ad7746_driver = {
.driver = {
.name = KBUILD_MODNAME,
+   .of_match_table = of_match_ptr(ad7746_of_match),
},
.probe = ad7746_probe,
.id_table = ad7746_id,
-- 
2.7.4

[PATCH v2 11/14] staging: iio: ad7746: Add devicetree bindings documentation

[Hernán Gonzalez]

Cc: Rob Herring 
Cc: Mark Rutland 
Cc: devicet...@vger.kernel.org
Signed-off-by: Hernán Gonzalez 
---
 .../devicetree/bindings/staging/iio/cdc/ad7746.txt | 34 ++
 1 file changed, 34 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/staging/iio/cdc/ad7746.txt

diff --git a/Documentation/devicetree/bindings/staging/iio/cdc/ad7746.txt 
b/Documentation/devicetree/bindings/staging/iio/cdc/ad7746.txt
new file mode 100644
index 000..7740f05
--- /dev/null
+++ b/Documentation/devicetree/bindings/staging/iio/cdc/ad7746.txt
@@ -0,0 +1,34 @@
+Analog Devices AD7746/5/7 capacitive sensor driver
+
+Required properties:
+   - compatible: Should be one of
+   * "adi,ad7745"
+   * "adi,ad7746"
+ * "adi,ad7747"
+   - reg: The 7-bits long I2c address of the device
+
+Optional properties:
+   - adi,exclvl: This property defines the excitation voltage level for the
+capacitance to be measured. Possible values are:
+  * 0 = +-VDD/8
+  * 1 = +-VDD/4
+  * 2 = +-VDD * 3/8
+  * 3 = +-VDD/2 (Default)
+   - adi,nexca_en: Invert excitation output A.
+   - adi,nexcb_en: Invert excitation output B.
+
+Example:
+Here exclvl would be 1 (VDD/4), Excitation pin A would be inverted and
+Excitation pin B would NOT be inverted.
+
+i2c2 {
+
+  < . . . >
+
+  ad7746: ad7746@60 {
+  compatible = "ad7746";
+  reg = <0x60>;
+  adi,exclvl = <1>;
+  adi,nexca_en;
+  };
+};
-- 
2.7.4

[PATCH v2 04/14] staging: iio: ad7746: Fix multiple line dereference

[Hernán Gonzalez]

Clear checkpatch.pl WARNING about multiple line derefence but creates a
new one of line over 80 characters. In my opinion, it improves
readability.

Signed-off-by: Hernán Gonzalez 
---
 drivers/staging/iio/cdc/ad7746.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/staging/iio/cdc/ad7746.c b/drivers/staging/iio/cdc/ad7746.c
index d793785..82fac76 100644
--- a/drivers/staging/iio/cdc/ad7746.c
+++ b/drivers/staging/iio/cdc/ad7746.c
@@ -410,8 +410,7 @@ static struct attribute *ad7746_attributes[] = {
_dev_attr_in_capacitance1_calibbias_calibration.dev_attr.attr,
_dev_attr_in_voltage0_calibscale_calibration.dev_attr.attr,
_const_attr_in_voltage_sampling_frequency_available.dev_attr.attr,
-   _const_attr_in_capacitance_sampling_frequency_available.
-   dev_attr.attr,
+   
_const_attr_in_capacitance_sampling_frequency_available.dev_attr.attr,
NULL,
 };
 
-- 
2.7.4

[PATCH v2 01/14] staging: iio: ad7746: Automatically swap values in readings/writings

[Hernán Gonzalez]

Data to read or write was being handled with the swab16() macro instead
of using i2c_smbus_{read,write}_swapped.

Signed-off-by: Hernán Gonzalez 
---
 drivers/staging/iio/cdc/ad7746.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/staging/iio/cdc/ad7746.c b/drivers/staging/iio/cdc/ad7746.c
index 4882dbc..53e28ae 100644
--- a/drivers/staging/iio/cdc/ad7746.c
+++ b/drivers/staging/iio/cdc/ad7746.c
@@ -451,7 +451,7 @@ static int ad7746_write_raw(struct iio_dev *indio_dev,
goto out;
}
 
-   ret = i2c_smbus_write_word_data(chip->client, reg, swab16(val));
+   ret = i2c_smbus_write_word_swapped(chip->client, reg, val);
if (ret < 0)
goto out;
 
@@ -462,8 +462,8 @@ static int ad7746_write_raw(struct iio_dev *indio_dev,
ret = -EINVAL;
goto out;
}
-   ret = i2c_smbus_write_word_data(chip->client,
-   AD7746_REG_CAP_OFFH, swab16(val));
+   ret = i2c_smbus_write_word_swapped(chip->client,
+  AD7746_REG_CAP_OFFH, val);
if (ret < 0)
goto out;
 
@@ -594,21 +594,21 @@ static int ad7746_read_raw(struct iio_dev *indio_dev,
goto out;
}
 
-   ret = i2c_smbus_read_word_data(chip->client, reg);
+   ret = i2c_smbus_read_word_swapped(chip->client, reg);
if (ret < 0)
goto out;
/* 1 + gain_val / 2^16 */
*val = 1;
-   *val2 = (15625 * swab16(ret)) / 1024;
+   *val2 = (15625 * ret) / 1024;
 
ret = IIO_VAL_INT_PLUS_MICRO;
break;
case IIO_CHAN_INFO_CALIBBIAS:
-   ret = i2c_smbus_read_word_data(chip->client,
-  AD7746_REG_CAP_OFFH);
+   ret = i2c_smbus_read_word_swapped(chip->client,
+ AD7746_REG_CAP_OFFH);
if (ret < 0)
goto out;
-   *val = swab16(ret);
+   *val = ret;
 
ret = IIO_VAL_INT;
break;
-- 
2.7.4

[PATCH v2 05/14] staging: iio: ad7746: Reorder includes alphabetically

[Hernán Gonzalez]

Signed-off-by: Hernán Gonzalez 
---
 drivers/staging/iio/cdc/ad7746.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/iio/cdc/ad7746.c b/drivers/staging/iio/cdc/ad7746.c
index 82fac76..9ef476a 100644
--- a/drivers/staging/iio/cdc/ad7746.c
+++ b/drivers/staging/iio/cdc/ad7746.c
@@ -6,15 +6,15 @@
  * Licensed under the GPL-2.
  */
 
-#include 
+#include 
 #include 
-#include 
-#include 
-#include 
 #include 
-#include 
+#include 
+#include 
 #include 
+#include 
 #include 
+#include 
 
 #include 
 #include 
-- 
2.7.4

[PATCH v2 02/14] staging: iio: ad7746: Adjust arguments to match open parenthesis

[Hernán Gonzalez]

Clear a couple more checkpatch.pl CHECKS.

Signed-off-by: Hernán Gonzalez 
---
 drivers/staging/iio/cdc/ad7746.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/iio/cdc/ad7746.c b/drivers/staging/iio/cdc/ad7746.c
index 53e28ae..516aa93 100644
--- a/drivers/staging/iio/cdc/ad7746.c
+++ b/drivers/staging/iio/cdc/ad7746.c
@@ -556,7 +556,8 @@ static int ad7746_read_raw(struct iio_dev *indio_dev,
/* Now read the actual register */
 
ret = i2c_smbus_read_i2c_block_data(chip->client,
-   chan->address >> 8, 3, >data.d8[1]);
+   chan->address >> 8, 3,
+   >data.d8[1]);
 
if (ret < 0)
goto out;
@@ -614,7 +615,7 @@ static int ad7746_read_raw(struct iio_dev *indio_dev,
break;
case IIO_CHAN_INFO_OFFSET:
*val = AD7746_CAPDAC_DACP(chip->capdac[chan->channel]
-   [chan->differential]) * 338646;
+ [chan->differential]) * 338646;
 
ret = IIO_VAL_INT;
break;
-- 
2.7.4

[PATCH v2 00/14] Move ad7746 driver out of staging

[Hernán Gonzalez]

Version 2 of the series trying to move ad7746 our of staging.

Changes in v2: (v1-> https://lkml.org/lkml/2018/3/21/406)
* Fix some issues pointed out by Jonathan
* Power down device on remove
* Add new ABI for the use case

Hernán Gonzalez (14):
  staging: iio: ad7746: Automatically swap values in readings/writings
  staging: iio: ad7746: Adjust arguments to match open parenthesis
  staging: iio: ad7746: Fix bound checkings
  staging: iio: ad7746: Fix multiple line dereference
  staging: iio: ad7746: Reorder includes alphabetically
  staging: iio: ad7746: Reorder variable declarations
  staging: iio: ad7746: Remove unused defines
  staging: iio: ad7746: Add dt-bindings
  staging: iio: ad7746: Add remove()
  staging: iio: ad7746: Add comments
  staging: iio: ad7746: Add devicetree bindings documentation
  staging: iio: ad7746: Add ABI documentation
  Move ad7746 out of staging
  staging: iio: Remove ad7746 from staging

 Documentation/ABI/testing/sysfs-bus-iio-ad7746 |  17 +++
 .../devicetree/bindings/iio/cdc/ad7746.txt |  34 +
 drivers/iio/Kconfig|   1 +
 drivers/iio/Makefile   |   1 +
 drivers/iio/cdc/Kconfig|  16 ++
 drivers/iio/cdc/Makefile   |   5 +
 drivers/{staging => }/iio/cdc/ad7746.c | 162 -
 drivers/staging/iio/cdc/Kconfig|  10 --
 drivers/staging/iio/cdc/Makefile   |   1 -
 .../staging => include/linux}/iio/cdc/ad7746.h |   9 --
 10 files changed, 201 insertions(+), 55 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-ad7746
 create mode 100644 Documentation/devicetree/bindings/iio/cdc/ad7746.txt
 create mode 100644 drivers/iio/cdc/Kconfig
 create mode 100644 drivers/iio/cdc/Makefile
 rename drivers/{staging => }/iio/cdc/ad7746.c (85%)
 rename {drivers/staging => include/linux}/iio/cdc/ad7746.h (70%)

-- 
2.7.4

[PATCH v2 03/14] staging: iio: ad7746: Fix bound checkings

[Hernán Gonzalez]

Also remove unnecessary parenthesis

Signed-off-by: Hernán Gonzalez 
---
 drivers/staging/iio/cdc/ad7746.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/iio/cdc/ad7746.c b/drivers/staging/iio/cdc/ad7746.c
index 516aa93..d793785 100644
--- a/drivers/staging/iio/cdc/ad7746.c
+++ b/drivers/staging/iio/cdc/ad7746.c
@@ -458,7 +458,7 @@ static int ad7746_write_raw(struct iio_dev *indio_dev,
ret = 0;
break;
case IIO_CHAN_INFO_CALIBBIAS:
-   if ((val < 0) | (val > 0x)) {
+   if (val < 0 || val > 0x) {
ret = -EINVAL;
goto out;
}
@@ -470,7 +470,7 @@ static int ad7746_write_raw(struct iio_dev *indio_dev,
ret = 0;
break;
case IIO_CHAN_INFO_OFFSET:
-   if ((val < 0) | (val > 43008000)) { /* 21pF */
+   if (val < 0 || val > 43008000) { /* 21pF */
ret = -EINVAL;
goto out;
}
-- 
2.7.4

Re: [PATCH 1/6] fs: use << for MS_* flags

[Randy Dunlap]

On 04/13/2018 09:11 AM, Christian Brauner wrote:
> Consistenly use << to define MS_* constants.
> 
> Signed-off-by: Christian Brauner 
> ---
>  include/uapi/linux/fs.h | 33 +
>  1 file changed, 17 insertions(+), 16 deletions(-)
> 
> diff --git a/include/uapi/linux/fs.h b/include/uapi/linux/fs.h
> index d2a8313fabd7..9662790a657c 100644
> --- a/include/uapi/linux/fs.h
> +++ b/include/uapi/linux/fs.h
> @@ -105,22 +105,23 @@ struct inodes_stat_t {
>  /*
>   * These are the fs-independent mount-flags: up to 32 flags are supported
>   */
> -#define MS_RDONLY 1  /* Mount read-only */
> -#define MS_NOSUID 2  /* Ignore suid and sgid bits */
> -#define MS_NODEV  4  /* Disallow access to device special files */
> -#define MS_NOEXEC 8  /* Disallow program execution */
> -#define MS_SYNCHRONOUS   16  /* Writes are synced at once */
> -#define MS_REMOUNT   32  /* Alter flags of a mounted FS */
> -#define MS_MANDLOCK  64  /* Allow mandatory locks on an FS */
> -#define MS_DIRSYNC   128 /* Directory modifications are synchronous */
> -#define MS_NOATIME   1024/* Do not update access times. */
> -#define MS_NODIRATIME2048/* Do not update directory access times 
> */
> -#define MS_BIND  4096
> -#define MS_MOVE  8192
> -#define MS_REC   16384
> -#define MS_VERBOSE   32768   /* War is peace. Verbosity is silence.
> -MS_VERBOSE is deprecated. */
> -#define MS_SILENT32768
> +#define MS_RDONLY(1<<0)  /* Mount read-only */

Why not just use BIT(n) instead?

#include 

#define MS_RDONLY   BIT(0)  /* Mount read-only */

etc.

> +#define MS_NOSUID(1<<1)  /* Ignore suid and sgid bits */
> +#define MS_NODEV (1<<2)  /* Disallow access to device special files */
> +#define MS_NOEXEC(1<<3)  /* Disallow program execution */
> +#define MS_SYNCHRONOUS   (1<<4)  /* Writes are synced at once */
> +#define MS_REMOUNT   (1<<5)  /* Alter flags of a mounted FS */
> +#define MS_MANDLOCK  (1<<6)  /* Allow mandatory locks on an FS */
> +#define MS_DIRSYNC   (1<<7)  /* Directory modifications are synchronous */
> +#define MS_NOATIME   (1<<10) /* Do not update access times. */
> +#define MS_NODIRATIME(1<<11) /* Do not update directory access times 
> */
> +#define MS_BIND  (1<<12)
> +#define MS_MOVE  (1<<13)
> +#define MS_REC   (1<<14)
> +#define MS_VERBOSE   (1<<15) /* War is peace. Verbosity is silence.
> +  * MS_VERBOSE is deprecated.
> +  */
> +#define MS_SILENT(1<<15)
>  #define MS_POSIXACL  (1<<16) /* VFS does not apply the umask */
>  #define MS_UNBINDABLE(1<<17) /* change to unbindable */
>  #define MS_PRIVATE   (1<<18) /* change to private */
> 


-- 
~Randy

Re: [PATCH V4 2/2] mmc: sdhci-msm: support voltage pad switching

[Doug Anderson]

Hi,

On Fri, Apr 6, 2018 at 2:48 AM, Vijay Viswanath  wrote:
>
>
> On 3/29/2018 4:23 AM, Doug Anderson wrote:
>>
>> Hi,
>>
>> On Wed, Mar 28, 2018 at 6:08 AM, Vijay Viswanath
>>  wrote:
>>>
>>> From: Krishna Konda 
>>>
>>> The PADs for SD card are dual-voltage that support 3v/1.8v. Those PADs
>>> have a control signal  (io_pad_pwr_switch/mode18 ) that indicates
>>> whether the PAD works in 3v or 1.8v.
>>>
>>> SDHC core on msm platforms should have IO_PAD_PWR_SWITCH bit set/unset
>>> based on actual voltage used for IO lines. So when power irq is
>>> triggered for io high or io low, the driver should check the voltages
>>> supported and set the pad accordingly.
>>>
>>> Signed-off-by: Krishna Konda 
>>> Signed-off-by: Venkat Gopalakrishnan 
>>> Signed-off-by: Vijay Viswanath 
>>> ---
>>>   drivers/mmc/host/sdhci-msm.c | 64
>>> ++--
>>>   1 file changed, 62 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/mmc/host/sdhci-msm.c b/drivers/mmc/host/sdhci-msm.c
>>> index 2fcd9010..bbf9626 100644
>>> --- a/drivers/mmc/host/sdhci-msm.c
>>> +++ b/drivers/mmc/host/sdhci-msm.c
>>> @@ -78,12 +78,15 @@
>>>   #define CORE_HC_MCLK_SEL_DFLT  (2 << 8)
>>>   #define CORE_HC_MCLK_SEL_HS400 (3 << 8)
>>>   #define CORE_HC_MCLK_SEL_MASK  (3 << 8)
>>> +#define CORE_IO_PAD_PWR_SWITCH_EN  (1 << 15)
>>> +#define CORE_IO_PAD_PWR_SWITCH  (1 << 16)
>>>   #define CORE_HC_SELECT_IN_EN   BIT(18)
>>>   #define CORE_HC_SELECT_IN_HS400(6 << 19)
>>>   #define CORE_HC_SELECT_IN_MASK (7 << 19)
>>>
>>>   #define CORE_3_0V_SUPPORT  (1 << 25)
>>>   #define CORE_1_8V_SUPPORT  (1 << 26)
>>> +#define CORE_VOLT_SUPPORT  (CORE_3_0V_SUPPORT | CORE_1_8V_SUPPORT)
>>>
>>>   #define CORE_CSR_CDC_CTLR_CFG0 0x130
>>>   #define CORE_SW_TRIG_FULL_CALIBBIT(16)
>>> @@ -1109,7 +1112,7 @@ static void sdhci_msm_handle_pwr_irq(struct
>>> sdhci_host *host, int irq)
>>>  u32 irq_status, irq_ack = 0;
>>>  int retry = 10;
>>>  u32 pwr_state = 0, io_level = 0;
>>> -
>>> +   u32 config;
>>>
>>>  irq_status = readl_relaxed(msm_host->core_mem +
>>> CORE_PWRCTL_STATUS);
>>>  irq_status &= INT_MASK;
>>> @@ -1166,6 +1169,45 @@ static void sdhci_msm_handle_pwr_irq(struct
>>> sdhci_host *host, int irq)
>>>   */
>>>  writel_relaxed(irq_ack, msm_host->core_mem + CORE_PWRCTL_CTL);
>>>
>>> +   /*
>>> +* If we don't have info regarding the voltage levels supported
>>> by
>>> +* regulators, don't change the IO PAD PWR SWITCH.
>>> +*/
>>> +   if (msm_host->caps_0 & CORE_VOLT_SUPPORT) {
>>> +   /* Ensure order between core_mem and hc_mem */
>>> +   mb();
>>
>>
>> Like in v2, I don't understand why you need a mb() before the read
>> from CORE_VENDOR_SPEC.  No reads or writes to the core_mem will affect
>> the value you're reading here, so you need no barrier.
>>
>> If you need a barrier before the _write_ to CORE_VENDOR_SPEC then add
>> it below.  Then in the case where the config doesn't change you have
>> no barriers.
>>
>>
>>> +   /*
>>> +* We should unset IO PAD PWR switch only if the register
>>> write
>>> +* can set IO lines high and the regulator also switches
>>> to 3 V.
>>> +* Else, we should keep the IO PAD PWR switch set.
>>> +* This is applicable to certain targets where eMMC vccq
>>> supply
>>> +* is only 1.8V. In such targets, even during
>>> REQ_IO_HIGH, the
>>> +* IO PAD PWR switch must be kept set to reflect actual
>>> +* regulator voltage. This way, during initialization of
>>> +* controllers with only 1.8V, we will set the IO PAD bit
>>> +* without waiting for a REQ_IO_LOW.
>>> +*/
>>
>>
>> For the above comment, what about just:
>>
>> new_config = config
>> if (msm_host->caps_0 == CORE_1_8V_SUPPORT) {
>>new_config |= CORE_IO_PAD_PWR_SWITCH;
>> } else if (msm_host->caps_0 == CORE_3_3V_SUPPORT) {
>>new_config &= ~CORE_IO_PAD_PWR_SWITCH;
>> } else if (msm_host->caps_0 & CORE_VOLT_SUPPORT) {
>>if (io_level & REQ_IO_HIGH)
>>  new_config &= ~CORE_IO_PAD_PWR_SWITCH;
>>else if (io_level & REQ_IO_LOW)
>>  new_config |= CORE_IO_PAD_PWR_SWITCH;
>> }
>
>
> This looks a big mess of if/else. Does the above implementation have better
> performance compared to having two if/else with bit operations inside ? The
> latter looks much cleaner and faster.
>
> If regulator only supports 3V and we get a io_low from BUS_OFF ( REQ_IO_LOW
> should never come if we don't support 1.8V), it is ok to set io pad.

Yeah, I think it's ugly no matter what.  Personally I find the
if/then/else easier to follow than the complicated conditions split
across 

Re: [PATCH 2/3] dt-bindings: add binding for at91-usart in spi mode

[Nicolas Ferre]

On 13/04/2018 at 18:23, Alexandre Belloni wrote:

On 13/04/2018 19:11:16+0300, Radu Pirea wrote:

These are bindings for at91-usart IP in spi spi mode. There is no support for
internal chip select. Only kind of chip selects available are gpio chip
selects.

Signed-off-by: Radu Pirea 
---
  .../bindings/spi/microchip,at91-usart-spi.txt | 24 +++
  1 file changed, 24 insertions(+)
  create mode 100644 
Documentation/devicetree/bindings/spi/microchip,at91-usart-spi.txt

diff --git a/Documentation/devicetree/bindings/spi/microchip,at91-usart-spi.txt 
b/Documentation/devicetree/bindings/spi/microchip,at91-usart-spi.txt
new file mode 100644
index ..92d33ccdffae
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/microchip,at91-usart-spi.txt
@@ -0,0 +1,24 @@
+* Universal Synchronous Asynchronous Receiver/Transmitter (USART) in SPI mode
+
+Required properties:
+- #size-cells  : Must be <0>
+- #address-cells   : Must be <1>
+- compatible: Should be "microchip,at91sam9g45-usart-spi" or 
"microchip,sama5d2-usart-spi"
+- reg: Should contain registers location and length
+- interrupts: Should contain interrupt
+- clocks: phandles to input clocks.
+- clock-names: tuple listing input clock names.
+   Required elements: "usart"
+- cs-gpios: chipselects (internal cs not supported)
+
+Example:
+   spi0: spi@f001c000 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   compatible = "microchip,sama5d2-usart-spi", 
"microchip,at91sam9g45-usart-spi";


I'm pretty sure this will be considered configuration rather than
hardware description. Why don't you do something like the flexcom mode
selection?


Because we are not in the same situation as having a glue layer that 
would select one of the already existing peripherals with associated 
drivers above.
This layout of the hardware is completely different from the USART one 
and it seems to makes sense to address it with a different hardware 
description and so a different compatible string.


Regards,
  Nicolas


+   reg = <0xf001c000 0x100>;
+   interrupts = <12 IRQ_TYPE_LEVEL_HIGH>;
+   clocks = <_clk>;
+   clock-names = "usart";
+   cs-gpios = < 3 0>;
+   };
--
2.17.0






--
Nicolas Ferre

Re: [PATCH net-next 1/3] net: ethernet: ave: add multiple clocks and resets support as required property

[Rob Herring]

On Mon, Apr 09, 2018 at 03:38:43PM +0900, Kunihiko Hayashi wrote:
> When the link is becoming up for Pro4 SoC, the kernel is stalled
> due to some missing clocks and resets.
> 
> The AVE block for Pro4 is connected to the GIO bus in the SoC.
> Without its clock/reset, the access to the AVE register makes the
> system stall.
> 
> In the same way, another MAC clock for Giga-bit Connection and
> the PHY clock are also required for Pro4 to activate the Giga-bit feature
> and to recognize the PHY.
> 
> To satisfy these requirements, this patch adds support for multiple clocks
> and resets, and adds the clock-names and reset-names to the binding because
> we need to distinguish clock/reset for the AVE main block and the others.
> 
> Also, make the resets a required property. Currently, "reset is
> optional" relies on that the bootloader or firmware has deasserted
> the reset before booting the kernel.  Drivers should work without
> such expectation.
> 
> Fixes: 4c270b55a5af ("net: ethernet: socionext: add AVE ethernet driver")
> Suggested-by: Masahiro Yamada 
> Signed-off-by: Kunihiko Hayashi 
> ---
>  .../bindings/net/socionext,uniphier-ave4.txt   |  13 ++-

Reviewed-by: Rob Herring 

>  drivers/net/ethernet/socionext/sni_ave.c   | 108 
> -
>  2 files changed, 96 insertions(+), 25 deletions(-)

Re: [PATCH net-next 2/3] dt-bindings: net: ave: add syscon-phy-mode property to configure phy-mode setting

[Rob Herring]

On Mon, Apr 09, 2018 at 03:38:44PM +0900, Kunihiko Hayashi wrote:
> Add "socionext,syscon-phy-mode" property to specify system controller that
> configures the settings about phy-mode.
> 
> Signed-off-by: Kunihiko Hayashi 
> ---
>  Documentation/devicetree/bindings/net/socionext,uniphier-ave4.txt | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)

Reviewed-by: Rob Herring 

Re: [PATCH v2 0/2] tracing/events: block: bring more on a par with blktrace

[Steven Rostedt]

On Fri, 13 Apr 2018 18:36:20 +0200
Steffen Maier  wrote:

> I had the need to understand I/O request processing in detail.
> But I also had the need to enrich block traces with other trace events
> including my own dynamic kprobe events. So I preferred block trace events
> over blktrace to get everything nicely sorted into one ftrace output.
> However, I missed device filtering for (un)plug events and also
> the difference between the two flavors of unplug.
> 
> The first two patches bring block trace events closer to their
> counterpart in blktrace tooling.
> 
> The last patch is just an RFC. I still kept it in this patch set because
> it is inspired by PATCH 2/2.
> 
> Changes since v1:
> [PATCH v2 1/2]
> Use 0 and 1 instead of false and true for __print_symbolic table.
> Now "trace-cmd report" can decode it. [Steven Rostedt]
> 
> Steffen Maier (3):
>   tracing/events: block: track and print if unplug was explicit or
> schedule
>   tracing/events: block: dev_t via driver core for plug and unplug
> events
>   tracing/events: block: also try to get dev_t via driver core for some
> events
> 
>  include/trace/events/block.h | 33 -
>  1 file changed, 28 insertions(+), 5 deletions(-)
> 

>From just the tracing point of view:

Reviewed-by: Steven Rostedt (VMware) 

as for the race conditions in the block layer, I'll let someone else
decided that.

-- Steve

Re: [PATCH v2 2/3] usb: dwc3: Add Qualcomm DWC3 glue driver

[Manu Gautam]

Hi Jack,


On 4/13/2018 11:03 PM, Jack Pham wrote:
> Hi Manu,
>
> On Fri, Apr 13, 2018 at 10:21:23PM +0530, Manu Gautam wrote:
>> DWC3 controller on Qualcomm SOCs has a Qscratch wrapper.
>> Some of its uses are described below resulting in need to
>> have a separate glue driver instead of using dwc3-of-simple:
>>  - It exposes register interface to override vbus-override
>>and lane0-pwr-present signals going to hardware. These
>>must be updated in peripheral mode for DWC3 if vbus lines
>>are not connected to hardware block. Otherwise RX termination
>>in SS mode or DP pull-up is not applied by device controller.
>>  - pwr_events_irq_stat support to check if USB2 PHY is in L2 state
>>before glue driver proceeds with suspend.
>>  - Support for wakeup interrupts lines that are asserted whenever
>>there is any wakeup event on USB3 or USB2 bus.
>>  - Support to replace pip3 clock going to DWC3 with utmi clock
>>for hardware configuration where SSPHY is not used with DWC3.
>>
>> Signed-off-by: Manu Gautam 
> 
>
>> +static int dwc3_qcom_register_extcon(struct dwc3_qcom *qcom)
>> +{
>> +struct device   *dev = qcom->dev;
>> +struct extcon_dev   *host_edev;
>> +int ret;
>> +
>> +if (!of_property_read_bool(dev->of_node, "extcon"))
>> +return 0;
>> +
>> +qcom->edev = extcon_get_edev_by_phandle(dev, 0);
> Are the extcon phandles bound to the glue node? I don't see the
> description in the bindings doc in PATCH 1/3. And if so, would it be
> a duplicate of the child node's extcon binding? Then again, the
> alternative would be to grab it directly from the child (i.e.
> qcom->dwc3->dev.of_node) which I'm not sure is ok to do or not.
>

Yes these are bound to glue node. I missed to add it to documentation, will do
so.
I kept it separate for couple of reasons - one is to not peek too-much into 
child
node. Another reason is that doing so allows to have extcon in "peripheral"
only mode as well (not just drd mode which is the case with dwc3 core).
It allows to notify h/w when vbus is not there in device mode which IMO is
right thing to do.



-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[Regression] PCI / PM: Simplify device wakeup settings code

[Joseph Salisbury]

Hi Rafael,

A kernel bug report was opened against Ubuntu [0].  After a kernel
bisect, it was found that reverting the following two commits resolved
this bug:

0ce3fcaff929 ("PCI / PM: Restore PME Enable after config space restoration")
0847684cfc5f("PCI / PM: Simplify device wakeup settings code")
 
This is a regression introduced in v4.13-rc1 and still exists in
mainline.  The bug causes the battery to drain when the system is
powered down and unplugged, which does not happed prior to these two
commits.  The bisect actually pointed to commit de3ef1e, but reverting
these two commits fixes the issue.

I was hoping to get your feedback, since you are the patch author.  Do
you think gathering any additional data will help diagnose this issue,
or would it be best to submit a revert request?
   
   
Thanks,

Joe

[0] http://pad.lv/1745646

Re: [PATCH 21/30] stack-protector: test compiler capability in Kconfig and drop AUTO mode

[Linus Torvalds]

On Fri, Apr 13, 2018 at 9:41 AM, Kees Cook  wrote:
>
> How about something like this instead:

I'd rather avoid the ifdef's in the Makefile if at all possible.

I'd rather expose this as a Kconfig rule, and in the Kconfig just have
an entry something like this

config STACKPROTECTOR_FLAGS
string
default "-fstack-protector-strong" if CC_STACKPROTECTOR_STRONG
default "-fstack-protector" if CC_STACKPROTECTOR
default "-fno-stack-protector" if CC_HAS_STACKPROTECTOR_NONE
default ""

which is really simple and straightforward. In the presense of
multiple defaults, the first is picked, so this _automatically_ does
that whole priority ordering.

And then the Makefile can just have

KBUILD_CFLAGS += $(CONFIG_STACKPROTECTOR_FLAGS)

which seems much simpler.

It also makes more complex conditionals easier (ie different compilers
with different flags, since clang sometimes does the same thing with
another flag name), so I'd rather see this pattern in general.

I'd also *much* rather do as much as possible at Kconfig time compared
to build time. Maybe it's just shifting the costs around, but the less
"clever" things we ask "make" to do, the better.

I find our Makefiles an odd combination of really clean and simply
(the ones that just have "obj-$(CONFIG_X) += xyz.o" are just lovely)
and completely incomprehensible (all of our infrastructure support for
the simple stuff).

I'd rather have more of the simple stuff in Makefiles, less of the
complex conditionals.

  Linus

Re: WARNING in up_write

[Dmitry Vyukov]

On Fri, Apr 6, 2018 at 4:01 AM, Dave Chinner  wrote:
> On Thu, Apr 05, 2018 at 05:13:25PM -0700, Eric Biggers wrote:
>> On Fri, Apr 06, 2018 at 08:32:26AM +1000, Dave Chinner wrote:
>> > On Wed, Apr 04, 2018 at 08:24:54PM -0700, Matthew Wilcox wrote:
>> > > On Wed, Apr 04, 2018 at 11:22:00PM -0400, Theodore Y. Ts'o wrote:
>> > > > On Wed, Apr 04, 2018 at 12:35:04PM -0700, Matthew Wilcox wrote:
>> > > > > On Wed, Apr 04, 2018 at 09:24:05PM +0200, Dmitry Vyukov wrote:
>> > > > > > On Tue, Apr 3, 2018 at 4:01 AM, syzbot
>> > > > > >  wrote:
>> > > > > > > DEBUG_LOCKS_WARN_ON(sem->owner != get_current())
>> > > > > > > WARNING: CPU: 1 PID: 4441 at kernel/locking/rwsem.c:133 
>> > > > > > > up_write+0x1cc/0x210
>> > > > > > > kernel/locking/rwsem.c:133
>> > > > > > > Kernel panic - not syncing: panic_on_warn set ...
>> > > > >
>> > > > > Message-Id: <1522852646-2196-1-git-send-email-long...@redhat.com>
>> > > > >
>> > > >
>> > > > We were way ahead of syzbot in this case.  :-)
>> > >
>> > > Not really ... syzbot caught it Monday evening ;-)
>> >
>> > Rather than arguing over who reported it first, I think that time
>> > would be better spent reflecting on why the syzbot report was
>> > completely ignored until *after* Ted diagnosed the issue
>> > independently and Waiman had already fixed it
>> >
>> > Clearly there is scope for improvement here.
>> >
>> > Cheers,
>> >
>>
>> Well, ultimately a human needed to investigate the syzbot bug report to 
>> figure
>> out what was really going on.  In my view, the largest problem is that there 
>> are
>> simply too many bugs, so many are getting ignored.
>
> Well, yeah. And when there's too many bugs, looking at the ones
> people are actually hitting tend to take precedence over those
> reported by a bot an image problem...
>
>> If there were only a few bugs, then Dmitry would investigate each
>> one and send a "real" bug report of better quality than the
>> automated system can provide, or even send a fix directly.  But in
>> reality, on the same day this bug was reported, syzbot also found
>> 10 other bugs, and in the previous 2 days it had found 38 more.
>> No single person can keep up with that.
>
> And this is precisely why people turn around and ask the syzbot
> developers to do things that make it easier for them to diagnose
> the problems syzbot reports.
>
>> You can see the current
>> bug list, which has 172 open bugs, on the dashboard at
>> https://syzkaller.appspot.com/.
>
> Is that all? That's *nothing*.
>
>> Yes, the kernel really is that
>> broken.
>
> Actually, that tells me the kernel is a hell of a lot better than my
> experience leads me to beleive it is. I'd have expected thousands of
> bugs, even tens of thousands of bugs given how many issues we deal
> with in individual subsystems on a day to day basis.
>
>> And although quite a few of these bugs will end up to be
>> duplicates or even already fixed, a human still has to look at
>> each one to figure that out.  (Though, I do think that syzbot
>> should try to automatically detect when a reproducible bug was
>> already fixed, via bisection.  It would cause a few bugs to be
>> incorrectly considered fixed, but it may be a worthwhile
>> tradeoff.)
>>
>> These bugs are all over the kernel as well, so most developers
>> don't see the big picture but rather just see a few bugs for
>> "their" subsystem on "their" subsystem's mailing list and
>> sometimes demand special attention.  Of course, it's great when
>> people suggest ways to improve the process.
>
> That's not the response I got
>
>> But it's not great
>> when people just don't feel responsible for fixing bugs and wait
>> for Someone Else to do it.
>
> The excessive cross posting of the reports is one of the reasons
> people think someone else will take care of it. i.e. "Oh, that looks VFS,
> that went to -fsdevel, I don't need to look at it"
>
> Put simply: if you're mounting an XFS filesystem image and something
> goes bang, then it should be reported to the XFS list. It does not
> need to be cross posted to LKML, -fsdevel, 10 individual developers,
> etc. If it's not an XFS problem, then the XFS developers will CC the
> relevant lists as needed.
>
>> I'm hoping that in the future the syzbot "team", which seems to
>> actually be just Dmitry now, can get more resources towards
>> helping fix the bugs.  But either way, in the end Linux is a
>> community effort.
>
> We don't really need help fixing the bugs - we need help making it
> easier to *find the bug* the bot tripped over. That's what the
> syzbot team needs to focus on, not tell people that what they got is
> all they are going to get.
>
>> Note also that syzbot wasn't super useful in this particular case
>> because people running xfstests came across the same bug.  But,
>> this is actually a rare case.  Most syzbot bug reports have been
>> for weird corner cases or races that no one ever thought of
>> 

Re: sparc/ppc/arm compat siginfo ABI regressions: sending SIGFPE via kill() returns wrong values in si_pid and si_uid

[Dave Martin]

On Fri, Apr 13, 2018 at 07:50:17PM +0100, Russell King - ARM Linux wrote:
> On Fri, Apr 13, 2018 at 07:35:38PM +0100, Dave Martin wrote:
> > If that's the case though, I don't see how a userspace testsuite is
> > hitting this code path.  Maybe I've misunderstood the context of this
> > thread.
> 
> It isn't hitting this exact case.
> 
> The userspace testsuite is hitting an entirely different case:
> 
>   kill(getpid(), SIGFPE);
> 
> As one expects, this generates a SIGFPE to the current process, which
> then inspects the siginfo structure.  Being a userspace generated
> signal, si_code is set to SI_USER, which has the value 0.
> 
> With FPE_FIXME defined to zero, as Eric has done:
> 
> enum siginfo_layout siginfo_layout(int sig, int si_code)
> {
> enum siginfo_layout layout = SIL_KILL;
> if ((si_code > SI_USER) && (si_code < SI_KERNEL)) {
> ...
> } else {
> ...
> #ifdef FPE_FIXME
> if ((sig == SIGFPE) && (si_code == FPE_FIXME))
> layout = SIL_FAULT;
> #endif
> }
> return layout;
> }
> 
> This causes siginfo_layout() to return SIL_FAULT for this userspace
> generated signal, rather than the correct SIL_KILL.
> 
> This affects which fields we copy to userspace.
> 
> SI_USER is defined to pass si_pid and si_uid to the userspace process,
> which on ARM are the first two consecutive 32-bit quantities in the
> union, which is done when siginfo_layout() returns SIL_KILL.  However,
> when SIL_FAULT is returned, we only copy si_addr in the union, which
> on ARM is just one 32-bit quantity.
> 
> Consequently, userspace sees a correct value for si_pid, and si_uid
> remains set to whatever was there in userspace.  In the case of the
> strace program, that's zero.  This means if you run the strace
> testsuite as root, the problem doesn't appear, but if you run it as
> a non-root user, it will.
> 
> So, the testsuite case has little to do with the behaviour of the VFP
> handling - it's to do with the behaviour of the kernel's signal handling.

Oh, right.  So, going back to the unhandled VFP bounce question,
is it reasonable for that to be a SIGKILL?  That avoids the question
of what si_code userspace should see, because userspace doesn't get
to see siginfo at all in that case: it's dead.

Or do we hit this in real situations that we want userspace to bail out
of more gracefully?

Cheers
---Dave

Re: [PATCH] base: dma-mapping: Postpone cpu addr translation on mmap()

[Christoph Hellwig]

Please send a v2.

RE: [PATCH v3] gpio: dwapb: Add support for 1 interrupt per port A GPIO

[Phil Edworthy]

Hi Hoan,

On 13 April 2018 17:37 Hoan Tran wrote:
> On Fri, Apr 13, 2018 at 1:51 AM, Phil Edworthy wrote:
> > The DesignWare GPIO IP can be configured for either 1 interrupt or 1
> > per GPIO in port A, but the driver currently only supports 1 interrupt.
> > See the DesignWare DW_apb_gpio Databook description of the
> > 'GPIO_INTR_IO' parameter.
> >
> > This change allows the driver to work with up to 32 interrupts, it
> > will get as many interrupts as specified in the DT 'interrupts' property.
> > It doesn't do anything clever with the different interrupts, it just
> > calls the same handler used for single interrupt hardware.
> >
> > Signed-off-by: Phil Edworthy 
> > ---
> > One point to mention is that I have made it possible for users to have
> > unconncted interrupts by specifying holes in the list of interrupts.
> > This is done by supporting the interrupts-extended DT prop.
> > However, I have no use for this and had to hack some test case for this.
> > Perhaps the driver should support 1 interrupt or all GPIOa as interrupts?
> >
> > v3:
> >  - Rolled mfd: intel_quark_i2c_gpio fix into this patch to avoid
> > bisect problems
> > v2:
> >  - Replaced interrupt-mask DT prop with support for the interrupts-
> extended
> >prop. This means replacing the call to irq_of_parse_and_map() with calls
> >to of_irq_parse_one() and irq_create_of_mapping().
> >
> > Note: There are a few *code* lines over 80 chars, but this is just guidance,
> >right? Especially as there are already some lines over 80 chars.
> > ---
[snip]

> > -   if (has_acpi_companion(dev) && pp->idx == 0)
> > -   pp->irq = platform_get_irq(to_platform_device(dev), 
> > 0);
> > +   if (has_acpi_companion(dev) && pp->idx == 0) {
> > +   pp->irq[0] = 
> > platform_get_irq(to_platform_device(dev), 0);
> > +   if (pp->irq[0])
> > +   pp->has_irq = true;
> > +   }
> 
> It doesn't work for ACPI. Could you do the same logic for ACPI?
I don’t have access to any device that was baked (i.e. fabbed) with multiple
output interrupts from the Synopsys GPIO blocks and use ACPI. I don't
know if any such device exists.

I would prefer not writing code that can be tested easily. I cannot even
test the current, albeit small, changes to the Intel Quark MFD.

Regards
Phil

> Thanks
> Hoan
> 
> >
> > pp->irq_shared  = false;
> > pp->gpio_base   = -1;
> > diff --git a/drivers/mfd/intel_quark_i2c_gpio.c
> > b/drivers/mfd/intel_quark_i2c_gpio.c
> > index 90e35de..5bddb84 100644
> > --- a/drivers/mfd/intel_quark_i2c_gpio.c
> > +++ b/drivers/mfd/intel_quark_i2c_gpio.c
> > @@ -233,7 +233,8 @@ static int intel_quark_gpio_setup(struct pci_dev
> *pdev, struct mfd_cell *cell)
> > pdata->properties->idx  = 0;
> > pdata->properties->ngpio= INTEL_QUARK_MFD_NGPIO;
> > pdata->properties->gpio_base= INTEL_QUARK_MFD_GPIO_BASE;
> > -   pdata->properties->irq  = pdev->irq;
> > +   pdata->properties->irq[0]   = pdev->irq;
> > +   pdata->properties->has_irq  = true;
> > pdata->properties->irq_shared   = true;
> >
> > cell->platform_data = pdata;
> > diff --git a/include/linux/platform_data/gpio-dwapb.h
> > b/include/linux/platform_data/gpio-dwapb.h
> > index 2dc7f4a..5a52d69 100644
> > --- a/include/linux/platform_data/gpio-dwapb.h
> > +++ b/include/linux/platform_data/gpio-dwapb.h
> > @@ -19,7 +19,8 @@ struct dwapb_port_property {
> > unsigned intidx;
> > unsigned intngpio;
> > unsigned intgpio_base;
> > -   unsigned intirq;
> > +   unsigned intirq[32];
> > +   boolhas_irq;
> > boolirq_shared;
> >  };
> >
> > --
> > 2.7.4
> >

Re: [PATCH 2/6] statfs: use << to align with fs header

[Randy Dunlap]

On 04/13/2018 09:11 AM, Christian Brauner wrote:
> Consistenly use << to define ST_* constants. This also aligns them with
> their MS_* counterparts in fs.h
> 
> Signed-off-by: Christian Brauner 
> ---
>  include/linux/statfs.h | 26 +-
>  1 file changed, 13 insertions(+), 13 deletions(-)

Lots of opportunities to use BIT(n) macro.
Is there some reason not to do that?


> diff --git a/include/linux/statfs.h b/include/linux/statfs.h
> index 3142e98546ac..b336c04e793c 100644
> --- a/include/linux/statfs.h
> +++ b/include/linux/statfs.h
> @@ -27,18 +27,18 @@ struct kstatfs {
>   * ABI.  The exception is ST_VALID which has the same value as MS_REMOUNT
>   * which doesn't make any sense for statfs.
>   */
> -#define ST_RDONLY0x0001  /* mount read-only */
> -#define ST_NOSUID0x0002  /* ignore suid and sgid bits */
> -#define ST_NODEV 0x0004  /* disallow access to device special files */
> -#define ST_NOEXEC0x0008  /* disallow program execution */
> -#define ST_SYNCHRONOUS   0x0010  /* writes are synced at once */
> -#define ST_VALID 0x0020  /* f_flags support is implemented */
> -#define ST_MANDLOCK  0x0040  /* allow mandatory locks on an FS */
> -/* 0x0080 used for ST_WRITE in glibc */
> -/* 0x0100 used for ST_APPEND in glibc */
> -/* 0x0200 used for ST_IMMUTABLE in glibc */
> -#define ST_NOATIME   0x0400  /* do not update access times */
> -#define ST_NODIRATIME0x0800  /* do not update directory access times 
> */
> -#define ST_RELATIME  0x1000  /* update atime relative to mtime/ctime */
> +#define ST_RDONLY(1<<0) /* mount read-only */
> +#define ST_NOSUID(1<<1) /* ignore suid and sgid bits */
> +#define ST_NODEV (1<<2) /* disallow access to device special files */
> +#define ST_NOEXEC(1<<3) /* disallow program execution */
> +#define ST_SYNCHRONOUS   (1<<4) /* writes are synced at once */
> +#define ST_VALID (1<<5) /* f_flags support is implemented */
> +#define ST_MANDLOCK  (1<<6) /* allow mandatory locks on an FS */
> +/* (1<<7) used for ST_WRITE in glibc */
> +/* (1<<8) used for ST_APPEND in glibc */
> +/* (1<<9) used for ST_IMMUTABLE in glibc */
> +#define ST_NOATIME   (1<<10) /* do not update access times */
> +#define ST_NODIRATIME(1<<11) /* do not update directory access times 
> */
> +#define ST_RELATIME  (1<<12) /* update atime relative to mtime/ctime */
>  
>  #endif
> 


-- 
~Randy

Re: [PATCH v2] block: ratelimite pr_err on IO path

[Martin K. Petersen]

Jinpu,

[CC:ed the mpt3sas maintainers]

The ratelimit patch is just an attempt to treat the symptom, not the
cause.

> Thanks for asking, we updated mpt3sas driver which enables DIX support
> (prot_mask=0x7f), all disks are SATA SSDs, no DIF support.
> After reboot, kernel reports the IO errors from all the drives behind
> HBA, seems for almost every read IO, which turns the system unusable:
> [   13.079375] sda: ref tag error at location 0 (rcvd 143196159)
> [   13.079989] sda: ref tag error at location 937702912 (rcvd 143196159)
> [   13.080233] sda: ref tag error at location 937703072 (rcvd 143196159)
> [   13.080407] sda: ref tag error at location 0 (rcvd 143196159)
> [   13.080594] sda: ref tag error at location 8 (rcvd 143196159)

That sounds like a bug in the mpt3sas driver or firmware. I guess the
HBA could conceivably be operating a SATA device as DIX Type 0 and strip
the PI on the drive side. But that doesn't seem to be a particularly
useful mode of operation.

Jinpu: Which firmware are you running? Also, please send us the output
of:

sg_readcap -l /dev/sda
sg_inq -x /dev/sda
sg_vpd /dev/sda

Broadcom: How is DIX supposed to work for SATA drives behind an mpt3sas
controller?

-- 
Martin K. Petersen  Oracle Linux Engineering

INFO: rcu detected stall in vfs_rmdir

[syzbot]

Hello,

syzbot hit the following crash on upstream commit
16e205cf42da1f497b10a4a24f563e6c0d574eec (Fri Apr 13 03:56:10 2018 +)
Merge tag 'drm-fixes-for-v4.17-rc1' of  
git://people.freedesktop.org/~airlied/linux
syzbot dashboard link:  
https://syzkaller.appspot.com/bug?extid=da69f0eccf07cdcf6710


Unfortunately, I don't have any reproducer for this crash yet.
Raw console output:  
https://syzkaller.appspot.com/x/log.txt?id=5006146695856128
Kernel config:  
https://syzkaller.appspot.com/x/.config?id=-5947642240294114534

compiler: gcc (GCC) 8.0.1 20180301 (experimental)

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+da69f0eccf07cdcf6...@syzkaller.appspotmail.com
It will help syzbot understand when the bug is fixed. See footer for  
details.

If you forward the report, please keep this part and the footer.

INFO: rcu_sched self-detected stall on CPU
	0-...!: (124998 ticks this GP) idle=10e/1/4611686018427387906  
softirq=30640/30640 fqs=8

 (t=125000 jiffies g=15921 c=15920 q=62)
rcu_sched kthread starved for 124967 jiffies! g15921 c15920 f0x0  
RCU_GP_WAIT_FQS(3) ->state=0x0 ->cpu=1

RCU grace-period kthread stack dump:
rcu_sched   R  running task23768 9  2 0x8000
Call Trace:
 context_switch kernel/sched/core.c:2848 [inline]
 __schedule+0x801/0x1e30 kernel/sched/core.c:3490
 schedule+0xef/0x430 kernel/sched/core.c:3549
 schedule_timeout+0x138/0x240 kernel/time/timer.c:1801
 rcu_gp_kthread+0x6b5/0x1940 kernel/rcu/tree.c:2231
 kthread+0x345/0x410 kernel/kthread.c:238
 ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:411
NMI backtrace for cpu 0
CPU: 0 PID: 4595 Comm: syz-executor3 Not tainted 4.16.0+ #2
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS  
Google 01/01/2011

Call Trace:
 
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0x1b9/0x294 lib/dump_stack.c:113
 nmi_cpu_backtrace.cold.4+0x19/0xce lib/nmi_backtrace.c:103
 nmi_trigger_cpumask_backtrace+0x151/0x192 lib/nmi_backtrace.c:62
 arch_trigger_cpumask_backtrace+0x14/0x20 arch/x86/kernel/apic/hw_nmi.c:38
 trigger_single_cpu_backtrace include/linux/nmi.h:156 [inline]
 rcu_dump_cpu_stacks+0x175/0x1c2 kernel/rcu/tree.c:1376
 print_cpu_stall kernel/rcu/tree.c:1525 [inline]
 check_cpu_stall.isra.61.cold.80+0x36c/0x59a kernel/rcu/tree.c:1593
 __rcu_pending kernel/rcu/tree.c:3356 [inline]
 rcu_pending kernel/rcu/tree.c:3401 [inline]
 rcu_check_callbacks+0x21b/0xad0 kernel/rcu/tree.c:2763
 update_process_times+0x2d/0x70 kernel/time/timer.c:1636
 tick_sched_handle+0x9f/0x180 kernel/time/tick-sched.c:173
 tick_sched_timer+0x45/0x130 kernel/time/tick-sched.c:1283
 __run_hrtimer kernel/time/hrtimer.c:1386 [inline]
 __hrtimer_run_queues+0x3e3/0x10a0 kernel/time/hrtimer.c:1448
 hrtimer_interrupt+0x286/0x650 kernel/time/hrtimer.c:1506
 local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1025 [inline]
 smp_apic_timer_interrupt+0x15d/0x710 arch/x86/kernel/apic/apic.c:1050
 apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:862
 
RIP: 0010:shrink_dcache_parent+0x174/0x230 fs/dcache.c:1484
RSP: 0018:88018cacfb68 EFLAGS: 0246 ORIG_RAX: ff13
RAX:  RBX: dc00 RCX: 
RDX: 81c20160 RSI: 88018cacfbf0 RDI: 8801d5252b80
RBP: 88018cacfc58 R08: 88018cac2480 R09: ed003aa4a580
R10: ed003aa4a580 R11: 8801d5252c03 R12: 88018cacfc30
R13: 88018cacfbf0 R14: 110031959f7e R15: ed0031959f81
 vfs_rmdir+0x202/0x470 fs/namei.c:3850
 do_rmdir+0x523/0x610 fs/namei.c:3911
 SYSC_rmdir fs/namei.c:3929 [inline]
 SyS_rmdir+0x1a/0x20 fs/namei.c:3927
 do_syscall_64+0x29e/0x9d0 arch/x86/entry/common.c:287
 entry_SYSCALL_64_after_hwframe+0x42/0xb7
RIP: 0033:0x455087
RSP: 002b:7fffa68fc118 EFLAGS: 0206 ORIG_RAX: 0054
RAX: ffda RBX: 0065 RCX: 00455087
RDX:  RSI: 7fffa68fdec0 RDI: 7fffa68fdec0
RBP: 7fffa68fdec0 R08:  R09: 0001
R10: 000a R11: 0206 R12: 01ea2940
R13:  R14: 01b8 R15: 00017faa


---
This bug is generated by a dumb bot. It may contain errors.
See https://goo.gl/tpsmEJ for details.
Direct all questions to syzkal...@googlegroups.com.

syzbot will keep track of this bug report.
If you forgot to add the Reported-by tag, once the fix for this bug is  
merged

into any tree, please reply to this email with:
#syz fix: exact-commit-title
To mark this as a duplicate of another syzbot report, please reply with:
#syz dup: exact-subject-of-another-report
If it's a one-off invalid bug report, please reply with:
#syz invalid
Note: if the crash happens again, it will cause creation of a new bug  
report.

Note: all commands must start from beginning of the line in the email body.

Re: [PATCH v5 2/2] dt-bindings: usb: rt1711h device tree binding document

[Rob Herring]

On Mon, Apr 09, 2018 at 10:11:35AM +0800, ShuFan Lee wrote:
> From: ShuFan Lee 
> 
> Add device tree binding document for Richtek RT1711H Type-C chip driver
> 
> Signed-off-by: ShuFan Lee 
> ---
>  .../devicetree/bindings/usb/richtek,rt1711h.txt | 17 
> +
>  1 file changed, 17 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/usb/richtek,rt1711h.txt

Reviewed-by: Rob Herring 

Re: [PATCH v2 3/3] Documentation/i2c: adopt kernel commenting style in examples

[Sam Hansen]

On Fri, Apr 13, 2018 at 9:50 AM, Wolfram Sang  wrote:
>
>> -  int adapter_nr = 2; /* probably dynamically determined */
>
> Such comments are actually OK.

Ah, gotcha.  Thanks for the correction.  Standby for revised patch set.

>
>> -/* ERROR HANDLING; you can check errno to see what went wrong */
>
> Such as well.
>
>> -  /* Using I2C Write, equivalent of
>> - i2c_smbus_write_word_data(file, reg, 0x6543) */
>> +  /*
>> +   * Using I2C Write, equivalent of
>> +   * i2c_smbus_write_word_data(file, reg, 0x6543).
>> +   */
>
> This is the only broken one AFAICT.
>

Re: [PATCH 1/2] dt-bindings/display/bridge: sii902x: add optional power supplies

[Rob Herring]

On Tue, Apr 10, 2018 at 07:19:26AM +0200, Philippe Cornu wrote:
> Add the 3 optional power supplies using the exact description
> found in the document named
> "SiI9022A/SiI9024A HDMI Transmitter Data Sheet (August 2016)".
> 
> Signed-off-by: Philippe Cornu 
> ---
>  Documentation/devicetree/bindings/display/bridge/sii902x.txt | 3 +++
>  1 file changed, 3 insertions(+)

Reviewed-by: Rob Herring 

Re: [PATCH] x86/cpufeature: guard asm_volatile_goto usage with CC_HAVE_ASM_GOTO

[Peter Zijlstra]

On Tue, Apr 10, 2018 at 02:28:04PM -0700, Alexei Starovoitov wrote:
> Instead of
> #ifdef CC_HAVE_ASM_GOTO
> we can replace it with
> #ifndef __BPF__
> or some other name,

I would prefer the BPF specific hack; otherwise we might be encouraging
people to build the kernel proper without asm-goto.