Re: [PATCH v2] x86: consider effective protection attributes in W+X check

[Jan Beulich]

>>> On 23.02.18 at 08:49,  wrote:

> * Jan Beulich  wrote:
> 
>> >>> On 21.02.18 at 17:53,  wrote:
>> 
>> > * Jan Beulich  wrote:
>> > 
>> >> Using just the leaf page table entry flags would cause a false warning
>> >> in case _PAGE_RW is clear or _PAGE_NX is set in a higher level entry.
>> >> Hand through both the current entry's flags as well as the accumulated
>> >> effective value (the latter as pgprotval_t instead of pgprot_t, as it's
>> >> not an actual entry's value).
>> >> 
>> >> This in particular eliminates the false W+X warning when running under
>> >> Xen, as commit 2cc42bac1c ("x86-64/Xen: eliminate W+X mappings") has to
>> >> make the necessary adjustment in L2 rather than L1 (the reason is
>> >> explained there). I.e. _PAGE_RW is clear there in L1, but _PAGE_NX is
>> >> set in L2.
>> >> 
>> >> Signed-off-by: Jan Beulich 
>> >> Reviewed-by: Juergen Gross 
>> >> ---
>> >> v2: Re-base onto tip tree. Add Xen related paragraph to description.
>> >> ---
>> >>  arch/x86/mm/dump_pagetables.c |   92 
>> > ++
>> >>  1 file changed, 57 insertions(+), 35 deletions(-)
>> > 
>> > There's a build failure with CONFIG_KASAN=y enabled:
>> > 
>> >  arch/x86/mm/dump_pagetables.c: In function ‘kasan_page_table’:
>> >  arch/x86/mm/dump_pagetables.c:365:3: error: too few arguments to function 
>> > ‘note_page’
>> >  arch/x86/mm/dump_pagetables.c:238:13: note: declared here
>> 
>> Oh, I see. Question though is what to pass as the extra argument:
>> Do I need to pass in the caller's effective rights, or should I take
>> kasan_page_table()'s checking against kasan_zero_p?d as an
>> indication that the effective permission is zero here? I'm sorry for
>> this probably trivial question, but I know nothing about how KASAN
>> works.
> 
> I'm not sure either - but I've Cc:-ed the KASAN gents who might be able to
> help us out here?

Actually, the "zero" in the names of the symbols meanwhile makes
me be pretty sure passing 0 for the effective permissions here is
exactly what is wanted. I'm about to produce v3.

Jan

Re: [PATCH] iio: light: add driver for bh1730fvc chips

[kbuild test robot]

Hi Pierre,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on iio/togreg]
[also build test ERROR on v4.16-rc2 next-20180222]
[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/Pierre-Bourdon/iio-light-add-driver-for-bh1730fvc-chips/20180222-064336
base:   https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git togreg
config: i386-allyesconfig (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 >>):

   drivers/iio/light/bh1730.o: In function `bh1730_read_raw':
>> bh1730.c:(.text+0x31d): undefined reference to `__udivdi3'
   bh1730.c:(.text+0x37d): undefined reference to `__udivdi3'
   bh1730.c:(.text+0x38a): undefined reference to `__udivdi3'
>> bh1730.c:(.text+0x3a4): undefined reference to `__divdi3'
>> bh1730.c:(.text+0x3b8): undefined reference to `__moddi3'

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


.config.gz
Description: application/gzip

[PATCH v3 1/2] x86/apic: Move pending intr check code into it's own function

[Dou Liyang]

the pending interrupt check code is mixed with the local APIC setup code,
that looks messy.

Extract the related code, move it into a new function named
apic_pending_intr_clear().

Signed-off-by: Dou Liyang 
---
 arch/x86/kernel/apic/apic.c | 98 -
 1 file changed, 52 insertions(+), 46 deletions(-)

diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
index 84b244ec49ed..be223ebd1bb3 100644
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -1408,6 +1408,56 @@ static void lapic_setup_esr(void)
oldvalue, value);
 }
 
+static void apic_pending_intr_clear(void)
+{
+   long long max_loops = cpu_khz ? cpu_khz : 100;
+   unsigned long long tsc = 0, ntsc;
+   unsigned int value, queued;
+   int i, j, acked = 0;
+
+   if (boot_cpu_has(X86_FEATURE_TSC))
+   tsc = rdtsc();
+   /*
+* After a crash, we no longer service the interrupts and a pending
+* interrupt from previous kernel might still have ISR bit set.
+*
+* Most probably by now CPU has serviced that pending interrupt and
+* it might not have done the ack_APIC_irq() because it thought,
+* interrupt came from i8259 as ExtInt. LAPIC did not get EOI so it
+* does not clear the ISR bit and cpu thinks it has already serivced
+* the interrupt. Hence a vector might get locked. It was noticed
+* for timer irq (vector 0x31). Issue an extra EOI to clear ISR.
+*/
+   do {
+   queued = 0;
+   for (i = APIC_ISR_NR - 1; i >= 0; i--)
+   queued |= apic_read(APIC_IRR + i*0x10);
+
+   for (i = APIC_ISR_NR - 1; i >= 0; i--) {
+   value = apic_read(APIC_ISR + i*0x10);
+   for (j = 31; j >= 0; j--) {
+   if (value & (1< 256) {
+   printk(KERN_ERR "LAPIC pending interrupts after %d 
EOI\n",
+  acked);
+   break;
+   }
+   if (queued) {
+   if (boot_cpu_has(X86_FEATURE_TSC) && cpu_khz) {
+   ntsc = rdtsc();
+   max_loops = (cpu_khz << 10) - (ntsc - tsc);
+   } else
+   max_loops--;
+   }
+   } while (queued && max_loops > 0);
+   WARN_ON(max_loops <= 0);
+}
+
 /**
  * setup_local_APIC - setup the local APIC
  *
@@ -1417,13 +1467,7 @@ static void lapic_setup_esr(void)
 static void setup_local_APIC(void)
 {
int cpu = smp_processor_id();
-   unsigned int value, queued;
-   int i, j, acked = 0;
-   unsigned long long tsc = 0, ntsc;
-   long long max_loops = cpu_khz ? cpu_khz : 100;
-
-   if (boot_cpu_has(X86_FEATURE_TSC))
-   tsc = rdtsc();
+   unsigned int value;
 
if (disable_apic) {
disable_ioapic_support();
@@ -1475,45 +1519,7 @@ static void setup_local_APIC(void)
value &= ~APIC_TPRI_MASK;
apic_write(APIC_TASKPRI, value);
 
-   /*
-* After a crash, we no longer service the interrupts and a pending
-* interrupt from previous kernel might still have ISR bit set.
-*
-* Most probably by now CPU has serviced that pending interrupt and
-* it might not have done the ack_APIC_irq() because it thought,
-* interrupt came from i8259 as ExtInt. LAPIC did not get EOI so it
-* does not clear the ISR bit and cpu thinks it has already serivced
-* the interrupt. Hence a vector might get locked. It was noticed
-* for timer irq (vector 0x31). Issue an extra EOI to clear ISR.
-*/
-   do {
-   queued = 0;
-   for (i = APIC_ISR_NR - 1; i >= 0; i--)
-   queued |= apic_read(APIC_IRR + i*0x10);
-
-   for (i = APIC_ISR_NR - 1; i >= 0; i--) {
-   value = apic_read(APIC_ISR + i*0x10);
-   for (j = 31; j >= 0; j--) {
-   if (value & (1< 256) {
-   printk(KERN_ERR "LAPIC pending interrupts after %d 
EOI\n",
-  acked);
-   break;
-   }
-   if (queued) {
-   if (boot_cpu_has(X86_FEATURE_TSC) && cpu_khz) {
-   ntsc = rdtsc();
-   max_loops = (cpu_khz << 10) - (ntsc - tsc);
-   } else
-   max_loops--;
-   }
-   } while (queued && max_loops > 0);
-   WARN_ON(max_loops <= 0);
+   apic_pending_intr_clear();
 
/*
 * Now that we are all set up, enable the APIC
-- 
2.14.3

[PATCH v3 2/2] x86/apic: Replace common tools with new ones

[Dou Liyang]

The pending interrupt check code is old, update the following code.

  -Replace for() with for_each_set_bit()
  -Replace printk() with pr_err()

Also merge the printk's code in one line and make curly braces balanced

Suggested-by: Andy Shevchenko 
Signed-off-by: Dou Liyang 
---
 arch/x86/kernel/apic/apic.c | 13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
index be223ebd1bb3..b303b29c71ca 100644
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -1412,7 +1412,8 @@ static void apic_pending_intr_clear(void)
 {
long long max_loops = cpu_khz ? cpu_khz : 100;
unsigned long long tsc = 0, ntsc;
-   unsigned int value, queued;
+   unsigned int queued;
+   unsigned long value;
int i, j, acked = 0;
 
if (boot_cpu_has(X86_FEATURE_TSC))
@@ -1435,24 +1436,24 @@ static void apic_pending_intr_clear(void)
 
for (i = APIC_ISR_NR - 1; i >= 0; i--) {
value = apic_read(APIC_ISR + i*0x10);
-   for (j = 31; j >= 0; j--) {
-   if (value & (1< 256) {
-   printk(KERN_ERR "LAPIC pending interrupts after %d 
EOI\n",
-  acked);
+   pr_err("LAPIC pending interrupts after %d EOI\n", 
acked);
break;
}
if (queued) {
if (boot_cpu_has(X86_FEATURE_TSC) && cpu_khz) {
ntsc = rdtsc();
max_loops = (cpu_khz << 10) - (ntsc - tsc);
-   } else
+   } else {
max_loops--;
+   }
}
} while (queued && max_loops > 0);
WARN_ON(max_loops <= 0);
-- 
2.14.3

Re: [PATCH 5/9] drm/xen-front: Implement handling of shared display buffers

[Oleksandr Andrushchenko]

On 02/23/2018 02:25 AM, Boris Ostrovsky wrote:

On 02/21/2018 03:03 AM, Oleksandr Andrushchenko wrote:
  
  static int __init xen_drv_init(void)

  {
+   /* At the moment we only support case with XEN_PAGE_SIZE == PAGE_SIZE */
+   BUILD_BUG_ON(XEN_PAGE_SIZE != PAGE_SIZE);


Why BUILD_BUG_ON? This should simply not load if page sizes are different.

  

This is a compile time check, so if kernel/Xen is configured
to use page size combination which is not supported by the
driver it will fail during compilation. This seems correct to me,
because you shouldn't even try to load the driver which
cannot handle different page sizes to not make any harm.





+   ret = gnttab_map_refs(map_ops, NULL, buf->pages, buf->num_pages);
+   BUG_ON(ret);


We should try not to BUG*(). There are a few in this patch (and possibly
others) that I think can be avoided.


I will rework BUG_* for map/unmap code to handle errors,
but will still leave
    /* either pages or sgt, not both */
    BUG_ON(cfg->pages && cfg->sgt);
which is a real driver bug and must not happen





+
+static int alloc_storage(struct xen_drm_front_shbuf *buf)
+{
+   if (buf->sgt) {
+   buf->pages = kvmalloc_array(buf->num_pages,
+   sizeof(struct page *), GFP_KERNEL);
+   if (!buf->pages)
+   return -ENOMEM;
+
+   if (drm_prime_sg_to_page_addr_arrays(buf->sgt, buf->pages,
+   NULL, buf->num_pages) < 0)
+   return -EINVAL;
+   }
+
+   buf->grefs = kcalloc(buf->num_grefs, sizeof(*buf->grefs), GFP_KERNEL);
+   if (!buf->grefs)
+   return -ENOMEM;
+
+   buf->directory = kcalloc(get_num_pages_dir(buf), PAGE_SIZE, GFP_KERNEL);
+   if (!buf->directory)
+   return -ENOMEM;

You need to clean up on errors.

this is called in xen_drm_front_shbuf_alloc and is properly cleaned
on failure, e.g.:
    ret = alloc_storage(buf);
    if (ret)
        goto fail;
[...]
fail:
    xen_drm_front_shbuf_free(buf);


-boris


+
+   return 0;
+}

Re: [PATCH 1/4] dt-bindings: at24: sort manufacturers alphabetically

[Bartosz Golaszewski]

2018-02-21 10:40 GMT+01:00 Wolfram Sang :
>
>> Will do. What about this (http://patchwork.ozlabs.org/patch/867169/)
>> one? It's part of a bigger series, do you want me to apply it to my
>> tree and provide you with an immutable branch?
>
> Well, I would accept it for 4.16 using the "plain new id" rule. So, if
> you add it on top of Peter's sorting patch, totally fine by me.
>
> If you want it in v4.17, ok, too. I'd think an immutable branch is not
> needed. There is a fallback property in the DTS. So at worst, there will
> be a DTS warning during the merge window which will be fixed at rc1 time.
>
> Unless I overlooked something.
>

Ok, I'll have some time during the weekend, so I'll send a PR for rc3.

Bart

Re: [PATCH 2/2] media: ov2680: Add Omnivision OV2680 sensor driver

[Sakari Ailus]

Hi Rui,

On Thu, Feb 22, 2018 at 10:23:38AM +, Rui Miguel Silva wrote:
> This patch adds V4L2 sub-device driver for OV2680 image sensor.
> The OV2680 is a 1/5" CMOS color sensor from Omnivision.
> Supports output format: 10-bit Raw RGB.
> The OV2680 has a single lane MIPI interface.
> 
> The driver exposes following V4L2 controls:
> - auto/manual exposure,
> - exposure,
> - auto/manual gain,
> - gain,
> - horizontal/vertical flip,
> - test pattern menu.
> Supported resolution are only: QUXGA, 720P, UXGA.
> 
> Signed-off-by: Rui Miguel Silva 
> ---
>  drivers/media/i2c/Kconfig  |   13 +
>  drivers/media/i2c/Makefile |1 +
>  drivers/media/i2c/ov2680.c | 1189 
> 
>  3 files changed, 1203 insertions(+)
>  create mode 100644 drivers/media/i2c/ov2680.c
> 
> diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
> index 9f18cd296841..089103d29171 100644
> --- a/drivers/media/i2c/Kconfig
> +++ b/drivers/media/i2c/Kconfig
> @@ -586,6 +586,19 @@ config VIDEO_OV2659
> To compile this driver as a module, choose M here: the
> module will be called ov2659.
>  
> +config VIDEO_OV2680
> + tristate "OmniVision OV2680 sensor support"
> + depends on OF

I think you can drop OF dependency here.

> + depends on GPIOLIB && VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API
> + depends on MEDIA_CAMERA_SUPPORT
> + select V4L2_FWNODE
> + ---help---
> +   This is a Video4Linux2 sensor-level driver for the OmniVision
> +   OV2680 camera sensor with a MIPI CSI-2 interface.
> +
> +   To compile this driver as a module, choose M here: the
> +   module will be called ov2680.
> +
>  config VIDEO_OV5640
>   tristate "OmniVision OV5640 sensor support"
>   depends on OF
> diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
> index c0f94cd8d56d..d0aba4d37b8d 100644
> --- a/drivers/media/i2c/Makefile
> +++ b/drivers/media/i2c/Makefile
> @@ -61,6 +61,7 @@ obj-$(CONFIG_VIDEO_SONY_BTF_MPX) += sony-btf-mpx.o
>  obj-$(CONFIG_VIDEO_UPD64031A) += upd64031a.o
>  obj-$(CONFIG_VIDEO_UPD64083) += upd64083.o
>  obj-$(CONFIG_VIDEO_OV2640) += ov2640.o
> +obj-$(CONFIG_VIDEO_OV2680) += ov2680.o
>  obj-$(CONFIG_VIDEO_OV5640) += ov5640.o
>  obj-$(CONFIG_VIDEO_OV5645) += ov5645.o
>  obj-$(CONFIG_VIDEO_OV5647) += ov5647.o
> diff --git a/drivers/media/i2c/ov2680.c b/drivers/media/i2c/ov2680.c
> new file mode 100644
> index ..64c1c2b03f97
> --- /dev/null
> +++ b/drivers/media/i2c/ov2680.c
> @@ -0,0 +1,1189 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Omnivision OV2680 CMOS Image Sensor driver
> + *
> + * Copyright (C) 2018 Linaro Ltd
> + *
> + * Based on OV5640 Sensor Driver
> + * Copyright (C) 2011-2013 Freescale Semiconductor, Inc. All Rights Reserved.
> + * Copyright (C) 2014-2017 Mentor Graphics Inc.
> + *
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 

Do you need of_gpio.h?

> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 

Do you need all of these? At least v4l2-event.h and v4l2-image-sizes.h seem
redundant.

> +
> +#define OV2680_XVCLK_MIN 600
> +#define OV2680_XVCLK_MAX 2400
> +
> +#define OV2680_CHIP_ID_HIGH  0x26
> +#define OV2680_CHIP_ID_LOW   0x80
> +
> +#define OV2680_REG_STREAM_CTRL   0x0100
> +#define OV2680_REG_SOFT_RESET0x0103
> +
> +#define OV2680_REG_CHIP_ID_HIGH  0x300a
> +#define OV2680_REG_CHIP_ID_LOW   0x300b
> +
> +#define OV2680_REG_R_MANUAL  0x3503
> +#define OV2680_REG_GAIN_PK   0x350a
> +#define OV2680_REG_EXPOSURE_PK_HIGH  0x3500
> +#define OV2680_REG_EXPOSURE_PK_MED   0x3501
> +#define OV2680_REG_EXPOSURE_PK_LOW   0x3502
> +#define OV2680_REG_TIMING_HTS0x380c
> +#define OV2680_REG_TIMING_VTS0x380e
> +#define OV2680_REG_FORMAT1   0x3820
> +#define OV2680_REG_FORMAT2   0x3821
> +
> +#define OV2680_REG_ISP_CTRL000x5080
> +
> +enum ov2680_frame_rate {
> + OV2680_30_FPS,
> + OV2680_FRAMERATES_MAX,
> +};
> +
> +static const int ov2680_framerates[] = {
> + [OV2680_30_FPS] = 30,
> +};
> +
> +enum ov2680_mode_id {
> + OV2680_MODE_QUXGA_800_600,
> + OV2680_MODE_720P_1280_720,
> + OV2680_MODE_UXGA_1600_1200,
> + OV2680_MODE_MAX,
> +};
> +
> +struct reg_value {
> + u16 reg_addr;
> + u8 val;
> +};
> +
> +struct ov2680_mode_info {
> + const char *name;
> + enum ov2680_mode_id id;
> + u32 width;
> + u32 height;
> + const struct reg_value *reg_data;
> + u32 reg_data_size;
> +};
> +
> +struct ov2680_ctrls {
> + struct v4l2_ctrl_handler handler;
> + struct {
> + struct v4l2_ctrl *auto_exp;
> + struct v4l2_ctrl *exposure;
> + };
> + struct {
> + struct v4l2_ctrl *auto_gain;
> + struct v4l2_ctrl *gain;
> + 

Re: [PATCH v2] x86: consider effective protection attributes in W+X check

[Ingo Molnar]

* Jan Beulich  wrote:

> >>> On 21.02.18 at 17:53,  wrote:
> 
> > * Jan Beulich  wrote:
> > 
> >> Using just the leaf page table entry flags would cause a false warning
> >> in case _PAGE_RW is clear or _PAGE_NX is set in a higher level entry.
> >> Hand through both the current entry's flags as well as the accumulated
> >> effective value (the latter as pgprotval_t instead of pgprot_t, as it's
> >> not an actual entry's value).
> >> 
> >> This in particular eliminates the false W+X warning when running under
> >> Xen, as commit 2cc42bac1c ("x86-64/Xen: eliminate W+X mappings") has to
> >> make the necessary adjustment in L2 rather than L1 (the reason is
> >> explained there). I.e. _PAGE_RW is clear there in L1, but _PAGE_NX is
> >> set in L2.
> >> 
> >> Signed-off-by: Jan Beulich 
> >> Reviewed-by: Juergen Gross 
> >> ---
> >> v2: Re-base onto tip tree. Add Xen related paragraph to description.
> >> ---
> >>  arch/x86/mm/dump_pagetables.c |   92 
> > ++
> >>  1 file changed, 57 insertions(+), 35 deletions(-)
> > 
> > There's a build failure with CONFIG_KASAN=y enabled:
> > 
> >  arch/x86/mm/dump_pagetables.c: In function ‘kasan_page_table’:
> >  arch/x86/mm/dump_pagetables.c:365:3: error: too few arguments to function 
> > ‘note_page’
> >  arch/x86/mm/dump_pagetables.c:238:13: note: declared here
> 
> Oh, I see. Question though is what to pass as the extra argument:
> Do I need to pass in the caller's effective rights, or should I take
> kasan_page_table()'s checking against kasan_zero_p?d as an
> indication that the effective permission is zero here? I'm sorry for
> this probably trivial question, but I know nothing about how KASAN
> works.

I'm not sure either - but I've Cc:-ed the KASAN gents who might be able to
help us out here?

Thanks,

Ingo

Re: [RFCv4 13/21] media: videobuf2-v4l2: support for requests

[Hans Verkuil]

On 02/23/2018 08:33 AM, Tomasz Figa wrote:
> On Fri, Feb 23, 2018 at 4:21 PM, Hans Verkuil  wrote:
>> On 02/23/2018 07:34 AM, Tomasz Figa wrote:
>>> On Wed, Feb 21, 2018 at 1:18 AM, Hans Verkuil  wrote:
 On 02/20/2018 05:44 AM, Alexandre Courbot wrote:
> Add a new vb2_qbuf_request() (a request-aware version of vb2_qbuf())
> that request-aware drivers can call to queue a buffer into a request
> instead of directly into the vb2 queue if relevent.
>
> This function expects that drivers invoking it are using instances of
> v4l2_request_entity and v4l2_request_entity_data to describe their
> entity and entity data respectively.
>
> Also add the vb2_request_submit() helper function which drivers can
> invoke in order to queue all the buffers previously queued into a
> request into the regular vb2 queue.
>
> Signed-off-by: Alexandre Courbot 
> ---
>  .../media/common/videobuf2/videobuf2-v4l2.c   | 129 +-
>  include/media/videobuf2-v4l2.h|  59 
>  2 files changed, 187 insertions(+), 1 deletion(-)
>

 

> @@ -776,10 +899,14 @@ EXPORT_SYMBOL_GPL(vb2_ioctl_querybuf);
>  int vb2_ioctl_qbuf(struct file *file, void *priv, struct v4l2_buffer *p)
>  {
>   struct video_device *vdev = video_devdata(file);
> + struct v4l2_fh *fh = NULL;
> +
> + if (test_bit(V4L2_FL_USES_V4L2_FH, &vdev->flags))
> + fh = file->private_data;

 No need for this. All drivers using vb2 will also use v4l2_fh.

>
>   if (vb2_queue_is_busy(vdev, file))
>   return -EBUSY;
> - return vb2_qbuf(vdev->queue, p);
> + return vb2_qbuf_request(vdev->queue, p, fh ? fh->entity : NULL);
>  }
>  EXPORT_SYMBOL_GPL(vb2_ioctl_qbuf);
>
> diff --git a/include/media/videobuf2-v4l2.h 
> b/include/media/videobuf2-v4l2.h
> index 3d5e2d739f05..d4dfa266a0da 100644
> --- a/include/media/videobuf2-v4l2.h
> +++ b/include/media/videobuf2-v4l2.h
> @@ -23,6 +23,12 @@
>  #error VB2_MAX_PLANES != VIDEO_MAX_PLANES
>  #endif
>
> +struct media_entity;
> +struct v4l2_fh;
> +struct media_request;
> +struct media_request_entity;
> +struct v4l2_request_entity_data;
> +
>  /**
>   * struct vb2_v4l2_buffer - video buffer information for v4l2.
>   *
> @@ -116,6 +122,59 @@ int vb2_prepare_buf(struct vb2_queue *q, struct 
> v4l2_buffer *b);
>   */
>  int vb2_qbuf(struct vb2_queue *q, struct v4l2_buffer *b);
>
> +#if IS_ENABLED(CONFIG_MEDIA_REQUEST_API)
> +
> +/**
> + * vb2_qbuf_request() - Queue a buffer, with request support
> + * @q:   pointer to &struct vb2_queue with videobuf2 queue.
> + * @b:   buffer structure passed from userspace to
> + *   &v4l2_ioctl_ops->vidioc_qbuf handler in driver
> + * @entity:  request entity to queue for if requests are used.
> + *
> + * Should be called from &v4l2_ioctl_ops->vidioc_qbuf handler of a 
> driver.
> + *
> + * If requests are not in use, calling this is equivalent to calling 
> vb2_qbuf().
> + *
> + * If the request_fd member of b is set, then the buffer represented by 
> b is
> + * queued in the request instead of the vb2 queue. The buffer will be 
> passed
> + * to the vb2 queue when the request is submitted.

 I would definitely also prepare the buffer at this time. That way you'll 
 see any
 errors relating to the prepare early on.
>>>
>>> Would the prepare operation be completely independent of other state?
>>> I can see a case when how the buffer is to be prepared may depend on
>>> values of some controls. If so, it would be only possible at request
>>> submission time. Alternatively, the application would have to be
>>> mandated to include any controls that may affect buffer preparing in
>>> the request and before the QBUF is called.
>>
>> The buffer is just memory. Controls play no role here. So the prepare
>> operation is indeed independent of other state. Anything else would make
>> this horrible complicated. And besides, with buffers allocated by other
>> subsystems (dmabuf) how could controls from our subsystems ever affect
>> those? The videobuf(2) frameworks have always just operated on memory
>> buffers without any knowledge of what it contains.
> 
> What you said applies to the videobuf(2) frameworks, but driver
> callback is explicitly defined as having access to the buffer
> contents:
> 
>  * @buf_prepare: called every time the buffer is queued from userspace
>  * and from the VIDIOC_PREPARE_BUF() ioctl; drivers may
>  * perform any initialization required before each
>  * hardware operation in this callback; drivers can
>  * access/modify the buffer here as it is still synced for
>  * the CPU; drivers that support VIDIOC_CREATE_BUFS() must
>  * also validate the buf

Re: [PATCH] [v4.15-stable] arm64: dts: add #cooling-cells to CPU nodes

[Greg Kroah-Hartman]

On Wed, Feb 21, 2018 at 05:29:19PM +0100, Arnd Bergmann wrote:
> commit acbf76ee05067c3942852019993f7beb69a0f45f upstream.

Now applied, thanks.

greg k-h

Re: stable-rc build: 13 warnings 0 failures (stable-rc/v4.15.4-164-g0cbdf96)

[gregkh]

On Wed, Feb 21, 2018 at 05:35:26PM +0100, Arnd Bergmann wrote:
> On Wed, Feb 21, 2018 at 4:46 PM, Olof's autobuilder  wrote:
> > Warnings:
> 
> Hi Greg,
> 
> It's much better already, thanks for picking up all the patches so
> far. Looking at the
> remaining warnings:
> 
> > arm64.allmodconfig:
> > arch/arm64/boot/dts/mediatek/mt8173-evb.dtb: Warning 
> > (cooling_device_property): Missing property '#cooling-cells' in node 
> > /cpus/cpu@0 or bad phandle (referred from 
> > /thermal-zones/cpu_thermal/cooling-maps/map@0:cooling-device[0])
> > arch/arm64/boot/dts/mediatek/mt8173-evb.dtb: Warning 
> > (cooling_device_property): Missing property '#cooling-cells' in node 
> > /cpus/cpu@100 or bad phandle (referred from 
> > /thermal-zones/cpu_thermal/cooling-maps/map@1:cooling-device[0])
> 
> Send a patch for this now, backported from mainline.
> 
> > WARNING: modpost: missing MODULE_LICENSE() in 
> > drivers/phy/qualcomm/phy-qcom-ufs.o
> 
> This is coming to a future mainline kernel.
> 
> > WARNING: modpost: missing MODULE_LICENSE() in drivers/soc/qcom/rmtfs_mem.o
> 
> It seems I missed a couple of MODULE_LICENSE backports in the previous list.
> 
> 3b229bdb54cc ("soc: qcom: rmtfs_mem: add missing
> MODULE_DESCRIPTION/AUTHOR/LICENSE")
> 
> > arm.allmodconfig:
> > /tmp/cctgVBy5.s:18153: Warning: using r15 results in unpredictable behaviour
> > /tmp/cctgVBy5.s:18225: Warning: using r15 results in unpredictable behaviour
> 
> Still got this on my radar, no fix is upstream yet.
> 
> > WARNING: modpost: missing MODULE_LICENSE() in 
> > sound/soc/ux500/snd-soc-ux500-plat-dma.o
> > WARNING: modpost: missing MODULE_LICENSE() in 
> > sound/soc/ux500/snd-soc-ux500-mach-mop500.o
> 
> 1783c9d7cb7b ("ASoC: ux500: add MODULE_LICENSE tag")
> 
> > WARNING: modpost: missing MODULE_LICENSE() in 
> > drivers/video/fbdev/mmp/mmp_disp.o
> 
> c1530ac5a3ce ("video: fbdev/mmp: add MODULE_LICENSE")
> 
> > WARNING: modpost: missing MODULE_LICENSE() in 
> > arch/arm/common/bL_switcher_dummy_if.o
> 
> a21b4c10c7bf ARM: 8743/1: bL_switcher: add MODULE_LICENSE tag
> 
> > WARNING: modpost: missing MODULE_LICENSE() in drivers/soc/qcom/rmtfs_mem.o
> 
> 3b229bdb54cc soc: qcom: rmtfs_mem: add missing 
> MODULE_DESCRIPTION/AUTHOR/LICENSE

I've picked these license patches up now, thanks.

greg k-h

Re: [RFC PATCH] mmc: sdhci-of-arasan: Add auto tuning support for ZynqMP Platform

[Adrian Hunter]

On 23/02/18 09:29, Manish Narani wrote:
> 
> 
>> -Original Message-
>> From: Adrian Hunter [mailto:adrian.hun...@intel.com]
>> Sent: Thursday, February 22, 2018 1:50 PM
>> To: Manish Narani ; michal.si...@xilinx.com;
>> ulf.hans...@linaro.org; linux-arm-ker...@lists.infradead.org; linux-
>> m...@vger.kernel.org; linux-kernel@vger.kernel.org;
>> devicet...@vger.kernel.org; mark.rutl...@arm.com; robh...@kernel.org
>> Cc: Anirudha Sarangi ; Srinivas Goud
>> 
>> Subject: Re: [RFC PATCH] mmc: sdhci-of-arasan: Add auto tuning support for
>> ZynqMP Platform
>>
>> On 21/02/18 17:00, Manish Narani wrote:
>>> Hi Adrian,
>>>
 -Original Message-
 From: Manish Narani
 Sent: Wednesday, February 21, 2018 11:39 AM
 To: Adrian Hunter ; michal.si...@xilinx.com;
 ulf.hans...@linaro.org; linux-arm-ker...@lists.infradead.org; linux-
 m...@vger.kernel.org; linux-kernel@vger.kernel.org;
 devicet...@vger.kernel.org; mark.rutl...@arm.com;
>> robh...@kernel.org
 Cc: Anirudha Sarangi ; Srinivas Goud
 
 Subject: RE: [RFC PATCH] mmc: sdhci-of-arasan: Add auto tuning
 support for ZynqMP Platform

 Hi Adrian,


> -Original Message-
> From: Adrian Hunter [mailto:adrian.hun...@intel.com]
> Sent: Friday, February 16, 2018 7:37 PM
> To: Manish Narani ; michal.si...@xilinx.com;
> ulf.hans...@linaro.org; linux-arm-ker...@lists.infradead.org; linux-
> m...@vger.kernel.org; linux-kernel@vger.kernel.org;
> devicet...@vger.kernel.org; mark.rutl...@arm.com;
>> robh...@kernel.org
> Cc: Anirudha Sarangi ; Srinivas Goud
> ; Manish Narani 
> Subject: Re: [RFC PATCH] mmc: sdhci-of-arasan: Add auto tuning
> support for ZynqMP Platform
>
> On 30/01/18 20:14, Manish Narani wrote:
>> This patch adds support of SD auto tuning for ZynqMP platform. Auto
>> tuning sequence sends tuning block to card when operating in UHS-1
>> modes. This resets the DLL and sends CMD19/CMD21 as a part of the
>> auto tuning process. Once the auto tuning process gets completed,
>> reset the DLL to load the newly obtained SDHC tuned tap value.
>
> How is this different from:
>   1. reset the dll
>   2. call sdhci_execute_tuning
>   3. reset the dll
>
>>> Below is my take on your above comments:
>>> - 'Reset the dll' is a platform specific call inside
>>> 'arasan_zynqmp_execute_tuning' which is implemented in
>>> sdhci-of-arasan.c
>>> - 'arasan_zynqmp_execute_tuning' is called from 'sdhci_execute_tuning'
>>> as a platform_execute_tuning routine
>>> - So to keep 'DLL reset' routine called from sdhci-of-arasan.c, I have
>>> implemented the execute_tuning in sdhci-of-arasan.c
>>
>> I meant something like:
>>
>>  if (of_device_is_compatible(pdev->dev.of_node, "xlnx,zynqmp-
>> 8.9a"))
>>  host->mmc_host_ops.execute_tuning =
>> arasan_zynqmp_execute_tuning;
>>
> This will need the removal of 'const' from 'static const struct mmc_host_ops 
> sdhci_ops = {}' in sdhci.c file. Please confirm.

No, it is not const.  You are not looking at the right place. i.e.

$ grep mmc_host_ops drivers/mmc/host/sdhci.h
struct mmc_host_ops mmc_host_ops;   /* MMC host ops */

> 
> Thanks,
> Manish
>>
>> static int arasan_zynqmp_execute_tuning(struct mmc_host *mmc, u32
>> opcode) {
>>  struct sdhci_host *host = mmc_priv(mmc);
>>  struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
>>  struct sdhci_arasan_data *sdhci_arasan =
>> sdhci_pltfm_priv(pltfm_host);
>>  int err;
>>
>>  arasan_zynqmp_dll_reset(host, sdhci_arasan->device_id);
>>
>>  err = sdhci_execute_tuning(mmc, opcode);
>>  if (err)
>>  return err;
>>
>>  arasan_zynqmp_dll_reset(host, sdhci_arasan->device_id);
>>
>>  return 0;
>> }
>>
>>>
>>> Alternative way (Please review):
>>> - Define a host->quirk2 bit (SDHCI_QUIRK2_DLL_RESET_NEEDED) in
>>> sdhci-of-arasan.c indicating DLL reset needed while tuning operation
>>> - Call 'dll reset' routine before and after __sdhci_execute_tuning()
>>> in sdhci.c when a host->quirk2 bit (SDHCI_QUIRK2_DLL_RESET_NEEDED) is
>>> set
>>
>> We should try to avoid quirks.

Re: [PATCH V2 6/7] thermal/drivers/cpu_cooling: Introduce the cpu idle cooling driver

[Viresh Kumar]

On 21-02-18, 16:29, Daniel Lezcano wrote:
> diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c
> index 5c219dc..9340216 100644
> --- a/drivers/thermal/cpu_cooling.c
> +++ b/drivers/thermal/cpu_cooling.c
> @@ -10,18 +10,32 @@
>   *   Viresh Kumar 
>   *
>   */
> +#undef DEBUG

Why is this required ?

> +#define pr_fmt(fmt) "CPU cooling: " fmt

I think you can use the dev_***() routines instead, as you can
directly the CPU device from anywhere.

>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
> +#include 
>  #include 
> +#include 
>  #include 
>  #include 
> +#include 
> +#include 
>  #include 
>  #include 
> +#include 
> +
> +#include 
> +#include 
>  
>  #include 
>  
> +#include 
> +
>  #ifdef CONFIG_CPU_FREQ_THERMAL
>  /*
>   * Cooling state <-> CPUFreq frequency
> @@ -928,3 +942,440 @@ void cpufreq_cooling_unregister(struct 
> thermal_cooling_device *cdev)
>  }
>  EXPORT_SYMBOL_GPL(cpufreq_cooling_unregister);
>  #endif /* CONFIG_CPU_FREQ_THERMAL */
> +
> +#ifdef CONFIG_CPU_IDLE_THERMAL
> +/*
> + * The idle duration injection. As we don't have yet a way to specify
> + * from the DT configuration, let's default to a tick duration.
> + */
> +#define DEFAULT_IDLE_TIME_US TICK_USEC

I think this macro is a bit unnecessary here. Its used only at
initialization and so the same comment can be present there and you
can use TICK_USEC there.

Else, Keep it as it is and remove the "idle_cycle" field from the
below structure, as it holds a constant forever.

> +
> +/**
> + * struct cpuidle_cooling_device - data for the idle cooling device
> + * @cdev: a pointer to a struct thermal_cooling_device
> + * @cpumask: a cpumask containing the CPU managed by the cooling device

Missed @node here.

> + * @timer: a hrtimer giving the tempo for the idle injection cycles
> + * @kref: a kernel refcount on this structure
> + * @count: an atomic to keep track of the last task exiting the idle cycle
> + * @idle_cycle: an integer defining the duration of the idle injection
> + * @state: an normalized integer giving the state of the cooling device
> + */
> +struct cpuidle_cooling_device {
> + struct thermal_cooling_device *cdev;
> + struct cpumask *cpumask;
> + struct list_head node;
> + struct hrtimer timer;
> + struct kref kref;
> + atomic_t count;
> + unsigned int idle_cycle;
> + unsigned int state;
> +};
> +
> +/**
> + * @tsk: an array of pointer to the idle injection tasks
> + * @waitq: the waiq for the idle injection tasks
> + */
> +struct cpuidle_cooling_tsk {
> + struct task_struct *tsk;
> + wait_queue_head_t waitq;
> +};
> +
> +DEFINE_PER_CPU(struct cpuidle_cooling_tsk, cpuidle_cooling_tsk);

static ?

> +
> +static LIST_HEAD(cpuidle_cdev_list);
> +
> +/**
> + * cpuidle_cooling_wakeup - Wake up all idle injection threads
> + * @idle_cdev: the idle cooling device
> + *
> + * Every idle injection task belonging to the idle cooling device and
> + * running on an online cpu will be wake up by this call.
> + */
> +static void cpuidle_cooling_wakeup(struct cpuidle_cooling_device *idle_cdev)
> +{
> + int cpu;
> + struct cpuidle_cooling_tsk *cct;
> +
> + for_each_cpu_and(cpu, idle_cdev->cpumask, cpu_online_mask) {
> + cct = per_cpu_ptr(&cpuidle_cooling_tsk, cpu);
> + wake_up_process(cct->tsk);
> + }
> +}
> +
> +/**
> + * cpuidle_cooling_wakeup_fn - Running cycle timer callback
> + * @timer: a hrtimer structure
> + *
> + * When the mitigation is acting, the CPU is allowed to run an amount
> + * of time, then the idle injection happens for the specified delay
> + * and the idle task injection schedules itself until the timer event
> + * wakes the idle injection tasks again for a new idle injection
> + * cycle. The time between the end of the idle injection and the timer
> + * expiration is the allocated running time for the CPU.
> + *
> + * Returns always HRTIMER_NORESTART
> + */
> +static enum hrtimer_restart cpuidle_cooling_wakeup_fn(struct hrtimer *timer)
> +{
> + struct cpuidle_cooling_device *idle_cdev =
> + container_of(timer, struct cpuidle_cooling_device, timer);
> +
> + cpuidle_cooling_wakeup(idle_cdev);
> +
> + return HRTIMER_NORESTART;
> +}
> +
> +/**
> + * cpuidle_cooling_runtime - Running time computation
> + * @idle_cdev: the idle cooling device
> + *
> + * The running duration is computed from the idle injection duration
> + * which is fixed. If we reach 100% of idle injection ratio, that
> + * means the running duration is zero. If we have a 50% ratio
> + * injection, that means we have equal duration for idle and for
> + * running duration.
> + *
> + * The formula is deduced as the following:
> + *
> + *  running = idle x ((100 / ratio) - 1)
> + *
> + * For precision purpose for integer math, we use the following:
> + *
> + *  running = (idle x 100) / ratio - idle
> + *
> + * For example, if we have an injected duration of 50%, then we end up
> + * with 10ms of idle 

Linux 4.15.5

[Greg KH]

I'm announcing the release of the 4.15.5 kernel.

All users of the 4.15 kernel series must upgrade.

The updated 4.15.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
linux-4.15.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/dma/snps-dma.txt  |2 
 Documentation/filesystems/ext4.txt  |2 
 Makefile|2 
 arch/arm/boot/dts/arm-realview-eb-mp.dtsi   |5 
 arch/arm/boot/dts/exynos5410.dtsi   |1 
 arch/arm/boot/dts/lpc3250-ea3250.dts|4 
 arch/arm/boot/dts/lpc3250-phy3250.dts   |4 
 arch/arm/boot/dts/mt2701.dtsi   |2 
 arch/arm/boot/dts/mt7623.dtsi   |1 
 arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts   |2 
 arch/arm/boot/dts/s5pv210.dtsi  |1 
 arch/arm/boot/dts/spear1310-evb.dts |2 
 arch/arm/boot/dts/spear1340.dtsi|4 
 arch/arm/boot/dts/spear13xx.dtsi|6 
 arch/arm/boot/dts/spear600.dtsi |1 
 arch/arm/boot/dts/ste-nomadik-stn8815.dtsi  |1 
 arch/arm/boot/dts/stih407.dtsi  |3 
 arch/arm/boot/dts/stih410.dtsi  |3 
 arch/arm/mach-pxa/tosa-bt.c |4 
 arch/arm64/boot/dts/qcom/msm8916.dtsi   |5 
 arch/arm64/kernel/cpu_errata.c  |9 
 arch/arm64/kvm/hyp/switch.c |4 
 arch/arm64/mm/proc.S|   14 
 arch/mips/Kconfig   |   12 
 arch/mips/kernel/cps-vec.S  |   17 
 arch/mips/kernel/setup.c|   16 
 arch/powerpc/include/asm/topology.h |5 
 arch/powerpc/kernel/process.c   |   15 
 arch/powerpc/mm/numa.c  |5 
 arch/powerpc/mm/pgtable-radix.c |   95 +++-
 arch/powerpc/mm/pgtable_64.c|2 
 arch/powerpc/mm/tlb-radix.c |2 
 arch/powerpc/platforms/powernv/vas-window.c |   16 
 arch/powerpc/platforms/pseries/hotplug-cpu.c|2 
 arch/powerpc/sysdev/xive/spapr.c|   16 
 arch/s390/kernel/compat_linux.c |8 
 arch/x86/entry/calling.h|  107 ++--
 arch/x86/entry/entry_64.S   |   92 
 arch/x86/entry/entry_64_compat.S|   30 +
 arch/x86/events/intel/core.c|2 
 arch/x86/events/intel/lbr.c |2 
 arch/x86/events/intel/p6.c  |2 
 arch/x86/include/asm/acpi.h |2 
 arch/x86/include/asm/barrier.h  |2 
 arch/x86/include/asm/bug.h  |   19 
 arch/x86/include/asm/nospec-branch.h|   14 
 arch/x86/include/asm/page_64.h  |4 
 arch/x86/include/asm/paravirt.h |4 
 arch/x86/include/asm/paravirt_types.h   |2 
 arch/x86/include/asm/pgtable_32.h   |2 
 arch/x86/include/asm/processor.h|7 
 arch/x86/include/asm/tlbflush.h |   27 -
 arch/x86/kernel/amd_nb.c|2 
 arch/x86/kernel/apic/apic.c |6 
 arch/x86/kernel/apm_32.c|1 
 arch/x86/kernel/asm-offsets_32.c|2 
 arch/x86/kernel/cpu/amd.c   |   28 -
 arch/x86/kernel/cpu/bugs.c  |   34 -
 arch/x86/kernel/cpu/centaur.c   |4 
 arch/x86/kernel/cpu/common.c|   10 
 arch/x86/kernel/cpu/cyrix.c |2 
 arch/x86/kernel/cpu/intel.c |   31 -
 arch/x86/kernel/cpu/intel_rdt.c |2 
 arch/x86/kernel/cpu/mcheck/mce-internal.h   |   15 
 arch/x86/kernel/cpu/mcheck/mce.c|   17 
 arch/x86/kernel/cpu/microcode/intel.c   |6 
 arch/x86/kernel/cpu/mtrr/generic.c  |2 
 arch/x86/kernel/cpu/mtrr/main.c |4 
 arch/x86/kernel/cpu/proc.c  |8 
 arch/x86/kernel/early-quirks.c  |1 
 arch/x86/kernel/head_32.S   |4 
 arch/x86/kernel/mpparse.c   |2 
 arch/x86/kernel/paravirt.c  |6 
 arch/x86/kernel/relocate_kernel_64.S|8 
 arch/x86/kernel/smpboot.c

Re: [RFCv4 13/21] media: videobuf2-v4l2: support for requests

[Tomasz Figa]

On Fri, Feb 23, 2018 at 4:21 PM, Hans Verkuil  wrote:
> On 02/23/2018 07:34 AM, Tomasz Figa wrote:
>> On Wed, Feb 21, 2018 at 1:18 AM, Hans Verkuil  wrote:
>>> On 02/20/2018 05:44 AM, Alexandre Courbot wrote:
 Add a new vb2_qbuf_request() (a request-aware version of vb2_qbuf())
 that request-aware drivers can call to queue a buffer into a request
 instead of directly into the vb2 queue if relevent.

 This function expects that drivers invoking it are using instances of
 v4l2_request_entity and v4l2_request_entity_data to describe their
 entity and entity data respectively.

 Also add the vb2_request_submit() helper function which drivers can
 invoke in order to queue all the buffers previously queued into a
 request into the regular vb2 queue.

 Signed-off-by: Alexandre Courbot 
 ---
  .../media/common/videobuf2/videobuf2-v4l2.c   | 129 +-
  include/media/videobuf2-v4l2.h|  59 
  2 files changed, 187 insertions(+), 1 deletion(-)

>>>
>>> 
>>>
 @@ -776,10 +899,14 @@ EXPORT_SYMBOL_GPL(vb2_ioctl_querybuf);
  int vb2_ioctl_qbuf(struct file *file, void *priv, struct v4l2_buffer *p)
  {
   struct video_device *vdev = video_devdata(file);
 + struct v4l2_fh *fh = NULL;
 +
 + if (test_bit(V4L2_FL_USES_V4L2_FH, &vdev->flags))
 + fh = file->private_data;
>>>
>>> No need for this. All drivers using vb2 will also use v4l2_fh.
>>>

   if (vb2_queue_is_busy(vdev, file))
   return -EBUSY;
 - return vb2_qbuf(vdev->queue, p);
 + return vb2_qbuf_request(vdev->queue, p, fh ? fh->entity : NULL);
  }
  EXPORT_SYMBOL_GPL(vb2_ioctl_qbuf);

 diff --git a/include/media/videobuf2-v4l2.h 
 b/include/media/videobuf2-v4l2.h
 index 3d5e2d739f05..d4dfa266a0da 100644
 --- a/include/media/videobuf2-v4l2.h
 +++ b/include/media/videobuf2-v4l2.h
 @@ -23,6 +23,12 @@
  #error VB2_MAX_PLANES != VIDEO_MAX_PLANES
  #endif

 +struct media_entity;
 +struct v4l2_fh;
 +struct media_request;
 +struct media_request_entity;
 +struct v4l2_request_entity_data;
 +
  /**
   * struct vb2_v4l2_buffer - video buffer information for v4l2.
   *
 @@ -116,6 +122,59 @@ int vb2_prepare_buf(struct vb2_queue *q, struct 
 v4l2_buffer *b);
   */
  int vb2_qbuf(struct vb2_queue *q, struct v4l2_buffer *b);

 +#if IS_ENABLED(CONFIG_MEDIA_REQUEST_API)
 +
 +/**
 + * vb2_qbuf_request() - Queue a buffer, with request support
 + * @q:   pointer to &struct vb2_queue with videobuf2 queue.
 + * @b:   buffer structure passed from userspace to
 + *   &v4l2_ioctl_ops->vidioc_qbuf handler in driver
 + * @entity:  request entity to queue for if requests are used.
 + *
 + * Should be called from &v4l2_ioctl_ops->vidioc_qbuf handler of a driver.
 + *
 + * If requests are not in use, calling this is equivalent to calling 
 vb2_qbuf().
 + *
 + * If the request_fd member of b is set, then the buffer represented by b 
 is
 + * queued in the request instead of the vb2 queue. The buffer will be 
 passed
 + * to the vb2 queue when the request is submitted.
>>>
>>> I would definitely also prepare the buffer at this time. That way you'll 
>>> see any
>>> errors relating to the prepare early on.
>>
>> Would the prepare operation be completely independent of other state?
>> I can see a case when how the buffer is to be prepared may depend on
>> values of some controls. If so, it would be only possible at request
>> submission time. Alternatively, the application would have to be
>> mandated to include any controls that may affect buffer preparing in
>> the request and before the QBUF is called.
>
> The buffer is just memory. Controls play no role here. So the prepare
> operation is indeed independent of other state. Anything else would make
> this horrible complicated. And besides, with buffers allocated by other
> subsystems (dmabuf) how could controls from our subsystems ever affect
> those? The videobuf(2) frameworks have always just operated on memory
> buffers without any knowledge of what it contains.

What you said applies to the videobuf(2) frameworks, but driver
callback is explicitly defined as having access to the buffer
contents:

 * @buf_prepare: called every time the buffer is queued from userspace
 * and from the VIDIOC_PREPARE_BUF() ioctl; drivers may
 * perform any initialization required before each
 * hardware operation in this callback; drivers can
 * access/modify the buffer here as it is still synced for
 * the CPU; drivers that support VIDIOC_CREATE_BUFS() must
 * also validate the buffer size; if an error is returned,
 * the buffer will not be queued in driver; optional.

https://elixir.bootlin.com/linux/latest/source/include/media/videobuf2-core.h#L330

Best 

Linux 4.14.21

[Greg KH]

I'm announcing the release of the 4.14.21 kernel.

All users of the 4.14 kernel series must upgrade.

The updated 4.14.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
linux-4.14.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/admin-guide/kernel-parameters.txt |7 
 Documentation/dev-tools/index.rst   |1 
 Documentation/dev-tools/kmemcheck.rst   |  733 
 Documentation/devicetree/bindings/dma/snps-dma.txt  |2 
 Documentation/filesystems/ext4.txt  |2 
 MAINTAINERS |   10 
 Makefile|2 
 arch/arm/boot/dts/arm-realview-eb-mp.dtsi   |5 
 arch/arm/boot/dts/exynos5410.dtsi   |1 
 arch/arm/boot/dts/lpc3250-ea3250.dts|4 
 arch/arm/boot/dts/lpc3250-phy3250.dts   |4 
 arch/arm/boot/dts/mt2701.dtsi   |2 
 arch/arm/boot/dts/mt7623.dtsi   |1 
 arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts   |2 
 arch/arm/boot/dts/s5pv210.dtsi  |1 
 arch/arm/boot/dts/spear1310-evb.dts |2 
 arch/arm/boot/dts/spear1340.dtsi|4 
 arch/arm/boot/dts/spear13xx.dtsi|6 
 arch/arm/boot/dts/spear600.dtsi |1 
 arch/arm/boot/dts/ste-nomadik-stn8815.dtsi  |1 
 arch/arm/boot/dts/stih407.dtsi  |3 
 arch/arm/boot/dts/stih410.dtsi  |3 
 arch/arm/include/asm/dma-iommu.h|1 
 arch/arm/include/asm/pgalloc.h  |2 
 arch/arm/mach-pxa/tosa-bt.c |4 
 arch/arm64/boot/dts/qcom/msm8916.dtsi   |5 
 arch/arm64/include/asm/pgalloc.h|2 
 arch/arm64/kernel/cpu_errata.c  |9 
 arch/arm64/kvm/hyp/switch.c |4 
 arch/arm64/mm/proc.S|   14 
 arch/mips/Kconfig   |   12 
 arch/mips/kernel/setup.c|   16 
 arch/openrisc/include/asm/dma-mapping.h |1 
 arch/powerpc/include/asm/pgalloc.h  |2 
 arch/powerpc/include/asm/topology.h |5 
 arch/powerpc/kernel/exceptions-64s.S|2 
 arch/powerpc/kernel/head_32.S   |2 
 arch/powerpc/mm/numa.c  |5 
 arch/powerpc/mm/pgtable-radix.c |   95 ++
 arch/powerpc/mm/pgtable_64.c|2 
 arch/powerpc/mm/tlb-radix.c |2 
 arch/powerpc/platforms/pseries/hotplug-cpu.c|2 
 arch/powerpc/sysdev/xive/spapr.c|   16 
 arch/s390/kernel/compat_linux.c |8 
 arch/sh/kernel/dwarf.c  |4 
 arch/sh/kernel/process.c|2 
 arch/sparc/mm/init_64.c |4 
 arch/unicore32/include/asm/pgalloc.h|2 
 arch/x86/Kconfig|3 
 arch/x86/Makefile   |5 
 arch/x86/entry/calling.h|  107 +-
 arch/x86/entry/entry_64.S   |   92 --
 arch/x86/entry/entry_64_compat.S|   30 
 arch/x86/events/intel/core.c|2 
 arch/x86/events/intel/lbr.c |2 
 arch/x86/events/intel/p6.c  |2 
 arch/x86/include/asm/acpi.h |2 
 arch/x86/include/asm/barrier.h  |2 
 arch/x86/include/asm/bug.h  |   19 
 arch/x86/include/asm/dma-mapping.h  |1 
 arch/x86/include/asm/kmemcheck.h|   43 -
 arch/x86/include/asm/nospec-branch.h|   14 
 arch/x86/include/asm/page_64.h  |4 
 arch/x86/include/asm/paravirt.h |4 
 arch/x86/include/asm/paravirt_types.h   |2 
 arch/x86/include/asm/pgtable.h  |5 
 arch/x86/include/asm/pgtable_32.h   |2 
 arch/x86/include/asm/pgtable_types.h|   13 
 arch/x86/include/asm/processor.h|7 
 arch/x86/include/asm/string_32.h|9 
 arch/x86/include/asm/string_64.h|8 
 arch/x86/include/asm/tlbflush.h |   27 
 arch/x86/include/asm/xor.h  |5 
 arch/x86/kernel/acpi/apei.c |2 
 arch/x86/kernel/amd_nb.c  

Linux 4.9.83

[Greg KH]

I'm announcing the release of the 4.9.83 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/dma/snps-dma.txt  |2 
 Documentation/filesystems/ext4.txt  |2 
 Makefile|2 
 arch/arm/boot/dts/arm-realview-eb-mp.dtsi   |5 
 arch/arm/boot/dts/exynos5410.dtsi   |1 
 arch/arm/boot/dts/lpc3250-ea3250.dts|4 
 arch/arm/boot/dts/lpc3250-phy3250.dts   |4 
 arch/arm/boot/dts/mt2701.dtsi   |2 
 arch/arm/boot/dts/s5pv210.dtsi  |1 
 arch/arm/boot/dts/spear1310-evb.dts |2 
 arch/arm/boot/dts/spear1340.dtsi|4 
 arch/arm/boot/dts/spear13xx.dtsi|6 
 arch/arm/boot/dts/spear600.dtsi |1 
 arch/arm/boot/dts/ste-nomadik-stn8815.dtsi  |1 
 arch/arm/boot/dts/stih407.dtsi  |3 
 arch/arm/boot/dts/stih410.dtsi  |3 
 arch/arm/mach-pxa/tosa-bt.c |4 
 arch/arm64/boot/dts/qcom/msm8916.dtsi   |5 
 arch/mips/Kconfig   |   12 
 arch/powerpc/kernel/entry_64.S  |5 
 arch/s390/kernel/compat_linux.c |8 
 arch/x86/entry/entry_64_compat.S|   30 +
 arch/x86/events/intel/core.c|2 
 arch/x86/events/intel/lbr.c |2 
 arch/x86/events/intel/p6.c  |2 
 arch/x86/include/asm/acpi.h |2 
 arch/x86/include/asm/barrier.h  |2 
 arch/x86/include/asm/nospec-branch.h|1 
 arch/x86/include/asm/processor.h|4 
 arch/x86/kernel/amd_nb.c|2 
 arch/x86/kernel/asm-offsets_32.c|2 
 arch/x86/kernel/cpu/amd.c   |   26 -
 arch/x86/kernel/cpu/bugs.c  |   28 -
 arch/x86/kernel/cpu/centaur.c   |4 
 arch/x86/kernel/cpu/common.c|   10 
 arch/x86/kernel/cpu/cyrix.c |2 
 arch/x86/kernel/cpu/intel.c |   31 -
 arch/x86/kernel/cpu/microcode/intel.c   |6 
 arch/x86/kernel/cpu/mtrr/generic.c  |2 
 arch/x86/kernel/cpu/mtrr/main.c |4 
 arch/x86/kernel/cpu/proc.c  |8 
 arch/x86/kernel/head_32.S   |4 
 arch/x86/kernel/mpparse.c   |2 
 arch/x86/kvm/mmu.c  |   10 
 arch/x86/kvm/vmx.c  |4 
 arch/x86/lib/cpu.c  |2 
 drivers/char/hw_random/via-rng.c|2 
 drivers/cpufreq/acpi-cpufreq.c  |2 
 drivers/cpufreq/longhaul.c  |6 
 drivers/cpufreq/p4-clockmod.c   |2 
 drivers/cpufreq/powernow-k7.c   |2 
 drivers/cpufreq/powernv-cpufreq.c   |4 
 drivers/cpufreq/speedstep-centrino.c|4 
 drivers/cpufreq/speedstep-lib.c |6 
 drivers/crypto/padlock-aes.c|2 
 drivers/devfreq/devfreq.c   |2 
 drivers/edac/amd64_edac.c   |2 
 drivers/edac/mce_amd.c  |2 
 drivers/gpu/drm/radeon/radeon_uvd.c |2 
 drivers/gpu/drm/radeon/si_dpm.c |5 
 drivers/hwmon/coretemp.c|6 
 drivers/hwmon/hwmon-vid.c   |2 
 drivers/hwmon/k10temp.c |2 
 drivers/hwmon/k8temp.c  |2 
 drivers/infiniband/hw/mlx4/main.c   |   13 
 drivers/infiniband/hw/qib/qib_rc.c  |6 
 drivers/infiniband/sw/rxe/rxe_verbs.c   |2 
 drivers/md/dm.c |3 
 drivers/media/tuners/r820t.c|   13 
 drivers/mtd/nand/vf610_nfc.c|6 
 drivers/net/ethernet/marvell/mvpp2.c|   11 
 drivers/net/ethernet/mellanox/mlx4/qp.c |3 
 drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c |5 
 drivers/net/wireless/realtek/rtlwifi/wifi.h |1 
 drivers/pci/host/pci-keystone.c |5 
 driv

Re: Linux 4.4.117

[Greg KH]

diff --git a/Documentation/devicetree/bindings/dma/snps-dma.txt 
b/Documentation/devicetree/bindings/dma/snps-dma.txt
index c261598164a7..17d43ca27f41 100644
--- a/Documentation/devicetree/bindings/dma/snps-dma.txt
+++ b/Documentation/devicetree/bindings/dma/snps-dma.txt
@@ -58,6 +58,6 @@ Example:
interrupts = <0 35 0x4>;
status = "disabled";
dmas = <&dmahost 12 0 1>,
-   <&dmahost 13 0 1 0>;
+   <&dmahost 13 1 0>;
dma-names = "rx", "rx";
};
diff --git a/Documentation/filesystems/ext4.txt 
b/Documentation/filesystems/ext4.txt
index 6c0108eb0137..2139ea253142 100644
--- a/Documentation/filesystems/ext4.txt
+++ b/Documentation/filesystems/ext4.txt
@@ -233,7 +233,7 @@ data_err=ignore(*)  Just print an error message if an error 
occurs
 data_err=abort Abort the journal if an error occurs in a file
data buffer in ordered mode.
 
-grpid  Give objects the same group ID as their creator.
+grpid  New objects have the group ID of their parent.
 bsdgroups
 
 nogrpid(*) New objects have the group ID of their creator.
diff --git a/Makefile b/Makefile
index 71acaecd7899..9f53ba1835ad 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
 VERSION = 4
 PATCHLEVEL = 4
-SUBLEVEL = 116
+SUBLEVEL = 117
 EXTRAVERSION =
 NAME = Blurry Fish Butt
 
diff --git a/arch/arm/boot/dts/s5pv210.dtsi b/arch/arm/boot/dts/s5pv210.dtsi
index 8344a0ee2b86..b03fe747b98c 100644
--- a/arch/arm/boot/dts/s5pv210.dtsi
+++ b/arch/arm/boot/dts/s5pv210.dtsi
@@ -461,6 +461,7 @@
compatible = "samsung,exynos4210-ohci";
reg = <0xec30 0x100>;
interrupts = <23>;
+   interrupt-parent = <&vic1>;
clocks = <&clocks CLK_USB_HOST>;
clock-names = "usbhost";
#address-cells = <1>;
diff --git a/arch/arm/boot/dts/spear1310-evb.dts 
b/arch/arm/boot/dts/spear1310-evb.dts
index e48857249ce7..3d83992efd90 100644
--- a/arch/arm/boot/dts/spear1310-evb.dts
+++ b/arch/arm/boot/dts/spear1310-evb.dts
@@ -349,7 +349,7 @@
spi0: spi@e010 {
status = "okay";
num-cs = <3>;
-   cs-gpios = <&gpio1 7 0>, <&spics 0>, <&spics 1>;
+   cs-gpios = <&gpio1 7 0>, <&spics 0 0>, <&spics 
1 0>;
 
stmpe610@0 {
compatible = "st,stmpe610";
diff --git a/arch/arm/boot/dts/spear1340.dtsi b/arch/arm/boot/dts/spear1340.dtsi
index df2232d767ed..6361cbfcbe5e 100644
--- a/arch/arm/boot/dts/spear1340.dtsi
+++ b/arch/arm/boot/dts/spear1340.dtsi
@@ -141,8 +141,8 @@
reg = <0xb410 0x1000>;
interrupts = <0 105 0x4>;
status = "disabled";
-   dmas = <&dwdma0 0x600 0 0 1>, /* 0xC << 11 */
-   <&dwdma0 0x680 0 1 0>; /* 0xD << 7 */
+   dmas = <&dwdma0 12 0 1>,
+   <&dwdma0 13 1 0>;
dma-names = "tx", "rx";
};
 
diff --git a/arch/arm/boot/dts/spear13xx.dtsi b/arch/arm/boot/dts/spear13xx.dtsi
index 14594ce8c18a..8fd8a3328acb 100644
--- a/arch/arm/boot/dts/spear13xx.dtsi
+++ b/arch/arm/boot/dts/spear13xx.dtsi
@@ -100,7 +100,7 @@
reg = <0xb280 0x1000>;
interrupts = <0 29 0x4>;
status = "disabled";
-   dmas = <&dwdma0 0 0 0 0>;
+   dmas = <&dwdma0 0 0 0>;
dma-names = "data";
};
 
@@ -288,8 +288,8 @@
#size-cells = <0>;
interrupts = <0 31 0x4>;
status = "disabled";
-   dmas = <&dwdma0 0x2000 0 0 0>, /* 0x4 << 11 */
-   <&dwdma0 0x0280 0 0 0>;  /* 0x5 << 7 */
+   dmas = <&dwdma0 4 0 0>,
+   <&dwdma0 5 0 0>;
dma-names = "tx", "rx";
};
 
diff --git a/arch/arm/boot/dts/spear600.dtsi b/arch/arm/boot/dts/spear600.dtsi
index 9f60a7b6a42b..bd379034993c 100644
--- a/arch/arm/boot/dts/spear600.dtsi
+++ b/arch/arm/boot/dts/spear600.dtsi
@@ -194,6 +194,7 @@
rtc@fc90 {
compatible = "st,spear600-rtc";
reg = <0xfc90 0x1000>;
+   interrupt-parent = <&vic0>;
interrupts = <10>;
sta

Re: Linux 4.9.83

[Greg KH]

diff --git a/Documentation/devicetree/bindings/dma/snps-dma.txt 
b/Documentation/devicetree/bindings/dma/snps-dma.txt
index 0f5583293c9c..633481e2a4ec 100644
--- a/Documentation/devicetree/bindings/dma/snps-dma.txt
+++ b/Documentation/devicetree/bindings/dma/snps-dma.txt
@@ -63,6 +63,6 @@ Example:
interrupts = <0 35 0x4>;
status = "disabled";
dmas = <&dmahost 12 0 1>,
-   <&dmahost 13 0 1 0>;
+   <&dmahost 13 1 0>;
dma-names = "rx", "rx";
};
diff --git a/Documentation/filesystems/ext4.txt 
b/Documentation/filesystems/ext4.txt
index 6c0108eb0137..2139ea253142 100644
--- a/Documentation/filesystems/ext4.txt
+++ b/Documentation/filesystems/ext4.txt
@@ -233,7 +233,7 @@ data_err=ignore(*)  Just print an error message if an error 
occurs
 data_err=abort Abort the journal if an error occurs in a file
data buffer in ordered mode.
 
-grpid  Give objects the same group ID as their creator.
+grpid  New objects have the group ID of their parent.
 bsdgroups
 
 nogrpid(*) New objects have the group ID of their creator.
diff --git a/Makefile b/Makefile
index d338530540e0..cfae9b823d2b 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
 VERSION = 4
 PATCHLEVEL = 9
-SUBLEVEL = 82
+SUBLEVEL = 83
 EXTRAVERSION =
 NAME = Roaring Lionus
 
diff --git a/arch/arm/boot/dts/arm-realview-eb-mp.dtsi 
b/arch/arm/boot/dts/arm-realview-eb-mp.dtsi
index 7b8d90b7aeea..29b636fce23f 100644
--- a/arch/arm/boot/dts/arm-realview-eb-mp.dtsi
+++ b/arch/arm/boot/dts/arm-realview-eb-mp.dtsi
@@ -150,11 +150,6 @@
interrupts = <0 8 IRQ_TYPE_LEVEL_HIGH>;
 };
 
-&charlcd {
-   interrupt-parent = <&intc>;
-   interrupts = <0  IRQ_TYPE_LEVEL_HIGH>;
-};
-
 &serial0 {
interrupt-parent = <&intc>;
interrupts = <0 4 IRQ_TYPE_LEVEL_HIGH>;
diff --git a/arch/arm/boot/dts/exynos5410.dtsi 
b/arch/arm/boot/dts/exynos5410.dtsi
index 137f48464f8b..bb59fee072c0 100644
--- a/arch/arm/boot/dts/exynos5410.dtsi
+++ b/arch/arm/boot/dts/exynos5410.dtsi
@@ -274,7 +274,6 @@
 &rtc {
clocks = <&clock CLK_RTC>;
clock-names = "rtc";
-   interrupt-parent = <&pmu_system_controller>;
status = "disabled";
 };
 
diff --git a/arch/arm/boot/dts/lpc3250-ea3250.dts 
b/arch/arm/boot/dts/lpc3250-ea3250.dts
index 52b3ed10283a..e2bc731079be 100644
--- a/arch/arm/boot/dts/lpc3250-ea3250.dts
+++ b/arch/arm/boot/dts/lpc3250-ea3250.dts
@@ -156,8 +156,8 @@
uda1380: uda1380@18 {
compatible = "nxp,uda1380";
reg = <0x18>;
-   power-gpio = <&gpio 0x59 0>;
-   reset-gpio = <&gpio 0x51 0>;
+   power-gpio = <&gpio 3 10 0>;
+   reset-gpio = <&gpio 3 2 0>;
dac-clk = "wspll";
};
 
diff --git a/arch/arm/boot/dts/lpc3250-phy3250.dts 
b/arch/arm/boot/dts/lpc3250-phy3250.dts
index fd95e2b10357..b7bd3a110a8d 100644
--- a/arch/arm/boot/dts/lpc3250-phy3250.dts
+++ b/arch/arm/boot/dts/lpc3250-phy3250.dts
@@ -81,8 +81,8 @@
uda1380: uda1380@18 {
compatible = "nxp,uda1380";
reg = <0x18>;
-   power-gpio = <&gpio 0x59 0>;
-   reset-gpio = <&gpio 0x51 0>;
+   power-gpio = <&gpio 3 10 0>;
+   reset-gpio = <&gpio 3 2 0>;
dac-clk = "wspll";
};
 
diff --git a/arch/arm/boot/dts/mt2701.dtsi b/arch/arm/boot/dts/mt2701.dtsi
index 77c6b931dc24..23fe0497f708 100644
--- a/arch/arm/boot/dts/mt2701.dtsi
+++ b/arch/arm/boot/dts/mt2701.dtsi
@@ -197,12 +197,14 @@
compatible = "mediatek,mt2701-hifsys", "syscon";
reg = <0 0x1a00 0 0x1000>;
#clock-cells = <1>;
+   #reset-cells = <1>;
};
 
ethsys: syscon@1b00 {
compatible = "mediatek,mt2701-ethsys", "syscon";
reg = <0 0x1b00 0 0x1000>;
#clock-cells = <1>;
+   #reset-cells = <1>;
};
 
bdpsys: syscon@1c00 {
diff --git a/arch/arm/boot/dts/s5pv210.dtsi b/arch/arm/boot/dts/s5pv210.dtsi
index a853918be43f..0c10ba517cd0 100644
--- a/arch/arm/boot/dts/s5pv210.dtsi
+++ b/arch/arm/boot/dts/s5pv210.dtsi
@@ -463,6 +463,7 @@
compatible = "samsung,exynos4210-ohci";
reg = <0xec30 0x100>;
interrupts = <23>;
+   interrupt-parent = <&vic1>;
clocks = <&clocks CLK_USB_HOST>;
clock-names = "usbhost";
#address-cells = <1>;
diff --git a/arch/arm/boot/dts/spear1310-evb.dts 
b/arch/arm/boot/dts/spear1310-evb.dts
index 84101e4eebbf..0f5f379323a8 100644
--- a/arch/arm/boot/dts/spear1310-evb.dts
+++ b/arch/arm/boot/dts/spear1310-evb.dts
@@ -349,7 +349,7 @@
spi0: spi@e010 {
   

Linux 4.4.117

[Greg KH]

I'm announcing the release of the 4.4.117 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



 Documentation/devicetree/bindings/dma/snps-dma.txt  |2 -
 Documentation/filesystems/ext4.txt  |2 -
 Makefile|2 -
 arch/arm/boot/dts/s5pv210.dtsi  |1 
 arch/arm/boot/dts/spear1310-evb.dts |2 -
 arch/arm/boot/dts/spear1340.dtsi|4 +-
 arch/arm/boot/dts/spear13xx.dtsi|6 ++--
 arch/arm/boot/dts/spear600.dtsi |1 
 arch/arm/boot/dts/stih407.dtsi  |3 +-
 arch/arm/boot/dts/stih410.dtsi  |3 +-
 arch/arm/mach-pxa/tosa-bt.c |4 ++
 arch/s390/kernel/compat_linux.c |8 ++---
 arch/x86/include/asm/processor.h|2 -
 arch/x86/kernel/cpu/common.c|2 -
 arch/x86/kernel/cpu/microcode/intel.c   |2 -
 arch/x86/kernel/cpu/proc.c  |4 +-
 arch/x86/kvm/mmu.c  |   10 +++
 drivers/devfreq/devfreq.c   |2 -
 drivers/gpu/drm/radeon/radeon_uvd.c |2 -
 drivers/infiniband/hw/mlx4/main.c   |   13 +++--
 drivers/md/dm.c |3 +-
 drivers/media/tuners/r820t.c|   13 +
 drivers/net/ethernet/marvell/mvpp2.c|   11 +--
 drivers/net/ethernet/mellanox/mlx4/qp.c |3 ++
 drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c |5 ++-
 drivers/net/wireless/realtek/rtlwifi/wifi.h |1 
 drivers/rtc/rtc-opal.c  |   12 +++-
 drivers/video/console/dummycon.c|1 
 drivers/video/fbdev/atmel_lcdfb.c   |8 +
 fs/btrfs/inode.c|5 ++-
 fs/btrfs/tree-log.c |   27 +++
 fs/ext4/super.c |1 
 fs/namei.c  |3 ++
 include/linux/kaiser.h  |2 -
 mm/memory.c |2 -
 sound/core/seq/seq_clientmgr.c  |   23 +---
 sound/pci/hda/patch_realtek.c   |   28 
 sound/usb/mixer.c   |   18 +++-
 sound/usb/pcm.c |9 ++
 39 files changed, 180 insertions(+), 70 deletions(-)

Arnd Bergmann (5):
  mm: hide a #warning for COMPILE_TEST
  x86: fix build warnign with 32-bit PAE
  ARM: pxa/tosa-bt: add MODULE_LICENSE tag
  ARM: dts: s5pv210: add interrupt-parent for ohci
  media: r820t: fix r820t_write_reg for KASAN

Bjorn Andersson (1):
  PM / devfreq: Propagate error from devfreq_add_device()

David Woodhouse (1):
  KVM/x86: Reduce retpoline performance impact in 
slot_handle_level_range(), by always inlining iterator helper methods

Ernesto A. Fernández (1):
  ext4: correct documentation for grpid mount option

Eugene Syromiatnikov (1):
  s390: fix handling of -1 in set{,fs}[gu]id16 syscalls

Greg Kroah-Hartman (1):
  Linux 4.4.117

Gustavo A. R. Silva (1):
  x86/cpu: Change type of x86_cache_size variable to unsigned int

Hui Wang (1):
  ALSA: hda - Fix headset mic detection problem for two Dell machines

Jack Morgenstein (1):
  IB/mlx4: Fix incorrectly releasing steerable UD QPs when have only ETH 
ports

Jan-Marek Glogowski (1):
  ALSA: hda/realtek: PCI quirk for Fujitsu U7x7

Johan Hovold (1):
  video: fbdev: atmel_lcdfb: fix display-timings lookup

Julia Lawall (1):
  drm/radeon: adjust tested variable

Kirill Marinushkin (1):
  ALSA: usb-audio: Fix UAC2 get_ctl request with a RANGE attribute

Larry Finger (1):
  rtlwifi: rtl8821ae: Fix connection lost problem correctly

Lassi Ylikojola (1):
  ALSA: usb-audio: add implicit fb quirk for Behringer UFX1204

Linus Torvalds (1):
  vfs: don't do RCU lookup of empty pathnames

Liu Bo (3):
  Btrfs: fix deadlock in run_delalloc_nocow
  Btrfs: fix crash due to not cleaning up tree log block's dirty bits
  Btrfs: fix unexpected -EEXIST when creating new inode

Mikulas Patocka (1):
  mvpp2: fix multicast address filter

NeilBrown (1):
  dm: correctly handle chained bios in dec_pending()

Nicolas Pitre (1):
  console/dummy: leave .con_font_get set to NULL

Patrice Chotard (1):
  AR

Re: [PATCH 2/2] crypto: omap: Improve a size determination in three functions

[SF Markus Elfring]

>> @@ -1032,14 +1032,13 @@ static int omap_aes_get_res_pdev(struct omap_aes_dev 
>> *dd,
>>  static int omap_aes_probe(struct platform_device *pdev)
>>  {
>>  struct device *dev = &pdev->dev;
>> -struct omap_aes_dev *dd;
>>  struct crypto_alg *algp;
>>  struct aead_alg *aalg;
>>  struct resource res;
>>  int err = -ENOMEM, i, j, irq = -1;
>>  u32 reg;
>> +struct omap_aes_dev *dd = devm_kzalloc(dev, sizeof(*dd), GFP_KERNEL);
>>  
>> -dd = devm_kzalloc(dev, sizeof(struct omap_aes_dev), GFP_KERNEL);
> 
> I'm fine with sizeof(*dd)

Thanks for your feedback.


> but please don't combine the allocation with the declaration.

Why do you not like such an implementation detail?

Regards,
Markus

RE: [RFC PATCH] mmc: sdhci-of-arasan: Add auto tuning support for ZynqMP Platform

[Manish Narani]

> -Original Message-
> From: Adrian Hunter [mailto:adrian.hun...@intel.com]
> Sent: Thursday, February 22, 2018 1:50 PM
> To: Manish Narani ; michal.si...@xilinx.com;
> ulf.hans...@linaro.org; linux-arm-ker...@lists.infradead.org; linux-
> m...@vger.kernel.org; linux-kernel@vger.kernel.org;
> devicet...@vger.kernel.org; mark.rutl...@arm.com; robh...@kernel.org
> Cc: Anirudha Sarangi ; Srinivas Goud
> 
> Subject: Re: [RFC PATCH] mmc: sdhci-of-arasan: Add auto tuning support for
> ZynqMP Platform
> 
> On 21/02/18 17:00, Manish Narani wrote:
> > Hi Adrian,
> >
> >> -Original Message-
> >> From: Manish Narani
> >> Sent: Wednesday, February 21, 2018 11:39 AM
> >> To: Adrian Hunter ; michal.si...@xilinx.com;
> >> ulf.hans...@linaro.org; linux-arm-ker...@lists.infradead.org; linux-
> >> m...@vger.kernel.org; linux-kernel@vger.kernel.org;
> >> devicet...@vger.kernel.org; mark.rutl...@arm.com;
> robh...@kernel.org
> >> Cc: Anirudha Sarangi ; Srinivas Goud
> >> 
> >> Subject: RE: [RFC PATCH] mmc: sdhci-of-arasan: Add auto tuning
> >> support for ZynqMP Platform
> >>
> >> Hi Adrian,
> >>
> >>
> >>> -Original Message-
> >>> From: Adrian Hunter [mailto:adrian.hun...@intel.com]
> >>> Sent: Friday, February 16, 2018 7:37 PM
> >>> To: Manish Narani ; michal.si...@xilinx.com;
> >>> ulf.hans...@linaro.org; linux-arm-ker...@lists.infradead.org; linux-
> >>> m...@vger.kernel.org; linux-kernel@vger.kernel.org;
> >>> devicet...@vger.kernel.org; mark.rutl...@arm.com;
> robh...@kernel.org
> >>> Cc: Anirudha Sarangi ; Srinivas Goud
> >>> ; Manish Narani 
> >>> Subject: Re: [RFC PATCH] mmc: sdhci-of-arasan: Add auto tuning
> >>> support for ZynqMP Platform
> >>>
> >>> On 30/01/18 20:14, Manish Narani wrote:
>  This patch adds support of SD auto tuning for ZynqMP platform. Auto
>  tuning sequence sends tuning block to card when operating in UHS-1
>  modes. This resets the DLL and sends CMD19/CMD21 as a part of the
>  auto tuning process. Once the auto tuning process gets completed,
>  reset the DLL to load the newly obtained SDHC tuned tap value.
> >>>
> >>> How is this different from:
> >>>   1. reset the dll
> >>>   2. call sdhci_execute_tuning
> >>>   3. reset the dll
> >>>
> > Below is my take on your above comments:
> > - 'Reset the dll' is a platform specific call inside
> > 'arasan_zynqmp_execute_tuning' which is implemented in
> > sdhci-of-arasan.c
> > - 'arasan_zynqmp_execute_tuning' is called from 'sdhci_execute_tuning'
> > as a platform_execute_tuning routine
> > - So to keep 'DLL reset' routine called from sdhci-of-arasan.c, I have
> > implemented the execute_tuning in sdhci-of-arasan.c
> 
> I meant something like:
> 
>   if (of_device_is_compatible(pdev->dev.of_node, "xlnx,zynqmp-
> 8.9a"))
>   host->mmc_host_ops.execute_tuning =
> arasan_zynqmp_execute_tuning;
> 
This will need the removal of 'const' from 'static const struct mmc_host_ops 
sdhci_ops = {}' in sdhci.c file. Please confirm.

Thanks,
Manish
> 
> static int arasan_zynqmp_execute_tuning(struct mmc_host *mmc, u32
> opcode) {
>   struct sdhci_host *host = mmc_priv(mmc);
>   struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
>   struct sdhci_arasan_data *sdhci_arasan =
> sdhci_pltfm_priv(pltfm_host);
>   int err;
> 
>   arasan_zynqmp_dll_reset(host, sdhci_arasan->device_id);
> 
>   err = sdhci_execute_tuning(mmc, opcode);
>   if (err)
>   return err;
> 
>   arasan_zynqmp_dll_reset(host, sdhci_arasan->device_id);
> 
>   return 0;
> }
> 
> >
> > Alternative way (Please review):
> > - Define a host->quirk2 bit (SDHCI_QUIRK2_DLL_RESET_NEEDED) in
> > sdhci-of-arasan.c indicating DLL reset needed while tuning operation
> > - Call 'dll reset' routine before and after __sdhci_execute_tuning()
> > in sdhci.c when a host->quirk2 bit (SDHCI_QUIRK2_DLL_RESET_NEEDED) is
> > set
> 
> We should try to avoid quirks.

[PATCH v2 2/5] dax: fix dax_mapping() definition in the FS_DAX=n + DEV_DAX=y case

[Dan Williams]

An address_space will only have dax exceptional entries when FS_DAX is
enabled. The current reliance on S_DAX causes compile failures when
S_DAX is defined for DEV_DAX, but FS_DAX is disabled. Make dax_mapping()
always return false so that mm/truncate.c drops its link time
dependencies on fs/dax.c.

Cc: Alexander Viro 
Cc: linux-fsde...@vger.kernel.org
Cc: Christoph Hellwig 
Cc: Jan Kara 
Cc: 
Reported-by: kbuild test robot 
Fixes: dee410792419 ("/dev/dax, core: file operations and dax-mmap")
Signed-off-by: Dan Williams 
---
 include/linux/dax.h |9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/include/linux/dax.h b/include/linux/dax.h
index 0185ecdae135..62e8cf7eb566 100644
--- a/include/linux/dax.h
+++ b/include/linux/dax.h
@@ -107,6 +107,10 @@ int dax_invalidate_mapping_entry_sync(struct address_space 
*mapping,
 int __dax_zero_page_range(struct block_device *bdev,
struct dax_device *dax_dev, sector_t sector,
unsigned int offset, unsigned int length);
+static inline bool dax_mapping(struct address_space *mapping)
+{
+   return mapping->host && IS_DAX(mapping->host);
+}
 #else
 static inline int __dax_zero_page_range(struct block_device *bdev,
struct dax_device *dax_dev, sector_t sector,
@@ -114,12 +118,11 @@ static inline int __dax_zero_page_range(struct 
block_device *bdev,
 {
return -ENXIO;
 }
-#endif
-
 static inline bool dax_mapping(struct address_space *mapping)
 {
-   return mapping->host && IS_DAX(mapping->host);
+   return false;
 }
+#endif
 
 struct writeback_control;
 int dax_writeback_mapping_range(struct address_space *mapping,

[PATCH v2 3/5] dax: fix S_DAX definition

[Dan Williams]

Make sure S_DAX is defined in the CONFIG_FS_DAX=n + CONFIG_DEV_DAX=y
case. Otherwise vma_is_dax() may incorrectly return false in the
Device-DAX case.

Cc: Alexander Viro 
Cc: linux-fsde...@vger.kernel.org
Cc: Christoph Hellwig 
Cc: Jan Kara 
Cc: 
Fixes: dee410792419 ("/dev/dax, core: file operations and dax-mmap")
Signed-off-by: Dan Williams 
---
 include/linux/fs.h |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/fs.h b/include/linux/fs.h
index 79c413985305..b2fa9b4c1e51 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -1859,7 +1859,7 @@ struct super_operations {
 #define S_IMA  1024/* Inode has an associated IMA struct */
 #define S_AUTOMOUNT2048/* Automount/referral quasi-directory */
 #define S_NOSEC4096/* no suid or xattr security attributes 
*/
-#ifdef CONFIG_FS_DAX
+#if IS_ENABLED(CONFIG_FS_DAX) || IS_ENABLED(CONFIG_DEV_DAX)
 #define S_DAX  8192/* Direct Access, avoiding the page cache */
 #else
 #define S_DAX  0   /* Make all the DAX code disappear */

Re: linux-next: manual merge of the kvms390 tree with the nds32 tree

[Geert Uytterhoeven]

On Fri, Feb 23, 2018 at 3:09 AM, Stephen Rothwell  wrote:
> Today's linux-next merge of the kvms390 tree got a conflict in:
>
>   drivers/video/console/Kconfig
>
> between commit:
>
>   2312dbf7462b ("drivers/video/concole: add negative dependency for 
> VGA_CONSOLE on nds32")
>
> from the nds32 tree and commit:
>
>   2f1ca75f69f3 ("s390/setup : enable display support for KVM guest")
>
> from the kvms390 tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc drivers/video/console/Kconfig
> index 27bb893cf6b2,7aa721e3a581..
> --- a/drivers/video/console/Kconfig
> +++ b/drivers/video/console/Kconfig
> @@@ -9,7 -9,7 +9,7 @@@ config VGA_CONSOL
> depends on !4xx && !PPC_8xx && !SPARC && !M68K && !PARISC && !FRV && \
> !SUPERH && !BLACKFIN && !AVR32 && !MN10300 && !CRIS && \
> (!ARM || ARCH_FOOTBRIDGE || ARCH_INTEGRATOR || 
> ARCH_NETWINDER) && \
> -   !ARM64 && !ARC && !MICROBLAZE && !OPENRISC && !NDS32
>  -  !ARM64 && !ARC && !MICROBLAZE && !OPENRISC && !S390
> ++  !ARM64 && !ARC && !MICROBLAZE && !OPENRISC && !NDS32 && !S390
> default y
> help
>   Saying Y here will allow you to use Linux in text mode through a

Which brings us to repeating the old advice: "The next new architecture added
should invest the work to add a MAY_HAVE_VGA_CONSOLE Kconfig symbol, to be
selected by the handful architectures/platforms that can have a VGA console".

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

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

RE: [RFC PATCH] mmc: sdhci-of-arasan: Add auto tuning support for ZynqMP Platform

[Manish Narani]

Hi Adrian,

> -Original Message-
> From: Adrian Hunter [mailto:adrian.hun...@intel.com]
> Sent: Thursday, February 22, 2018 1:50 PM
> To: Manish Narani ; michal.si...@xilinx.com;
> ulf.hans...@linaro.org; linux-arm-ker...@lists.infradead.org; linux-
> m...@vger.kernel.org; linux-kernel@vger.kernel.org;
> devicet...@vger.kernel.org; mark.rutl...@arm.com; robh...@kernel.org
> Cc: Anirudha Sarangi ; Srinivas Goud
> 
> Subject: Re: [RFC PATCH] mmc: sdhci-of-arasan: Add auto tuning support for
> ZynqMP Platform
> 
> On 21/02/18 17:00, Manish Narani wrote:
> > Hi Adrian,
> >
> >> -Original Message-
> >> From: Manish Narani
> >> Sent: Wednesday, February 21, 2018 11:39 AM
> >> To: Adrian Hunter ; michal.si...@xilinx.com;
> >> ulf.hans...@linaro.org; linux-arm-ker...@lists.infradead.org; linux-
> >> m...@vger.kernel.org; linux-kernel@vger.kernel.org;
> >> devicet...@vger.kernel.org; mark.rutl...@arm.com;
> robh...@kernel.org
> >> Cc: Anirudha Sarangi ; Srinivas Goud
> >> 
> >> Subject: RE: [RFC PATCH] mmc: sdhci-of-arasan: Add auto tuning
> >> support for ZynqMP Platform
> >>
> >> Hi Adrian,
> >>
> >>
> >>> -Original Message-
> >>> From: Adrian Hunter [mailto:adrian.hun...@intel.com]
> >>> Sent: Friday, February 16, 2018 7:37 PM
> >>> To: Manish Narani ; michal.si...@xilinx.com;
> >>> ulf.hans...@linaro.org; linux-arm-ker...@lists.infradead.org; linux-
> >>> m...@vger.kernel.org; linux-kernel@vger.kernel.org;
> >>> devicet...@vger.kernel.org; mark.rutl...@arm.com;
> robh...@kernel.org
> >>> Cc: Anirudha Sarangi ; Srinivas Goud
> >>> ; Manish Narani 
> >>> Subject: Re: [RFC PATCH] mmc: sdhci-of-arasan: Add auto tuning
> >>> support for ZynqMP Platform
> >>>
> >>> On 30/01/18 20:14, Manish Narani wrote:
>  This patch adds support of SD auto tuning for ZynqMP platform. Auto
>  tuning sequence sends tuning block to card when operating in UHS-1
>  modes. This resets the DLL and sends CMD19/CMD21 as a part of the
>  auto tuning process. Once the auto tuning process gets completed,
>  reset the DLL to load the newly obtained SDHC tuned tap value.
> >>>
> >>> How is this different from:
> >>>   1. reset the dll
> >>>   2. call sdhci_execute_tuning
> >>>   3. reset the dll
> >>>
> > Below is my take on your above comments:
> > - 'Reset the dll' is a platform specific call inside
> > 'arasan_zynqmp_execute_tuning' which is implemented in
> > sdhci-of-arasan.c
> > - 'arasan_zynqmp_execute_tuning' is called from 'sdhci_execute_tuning'
> > as a platform_execute_tuning routine
> > - So to keep 'DLL reset' routine called from sdhci-of-arasan.c, I have
> > implemented the execute_tuning in sdhci-of-arasan.c
> 
> I meant something like:
> 
>   if (of_device_is_compatible(pdev->dev.of_node, "xlnx,zynqmp-
> 8.9a"))
>   host->mmc_host_ops.execute_tuning =
> arasan_zynqmp_execute_tuning;
> 
This will need the removal of 'const' from 
static const struct mmc_host_ops sdhci_ops = {}
in sdhci.c file. Please confirm.

Thanks,
Manish

> 
> static int arasan_zynqmp_execute_tuning(struct mmc_host *mmc, u32
> opcode) {
>   struct sdhci_host *host = mmc_priv(mmc);
>   struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
>   struct sdhci_arasan_data *sdhci_arasan =
> sdhci_pltfm_priv(pltfm_host);
>   int err;
> 
>   arasan_zynqmp_dll_reset(host, sdhci_arasan->device_id);
> 
>   err = sdhci_execute_tuning(mmc, opcode);
>   if (err)
>   return err;
> 
>   arasan_zynqmp_dll_reset(host, sdhci_arasan->device_id);
> 
>   return 0;
> }
> 
> >
> > Alternative way (Please review):
> > - Define a host->quirk2 bit (SDHCI_QUIRK2_DLL_RESET_NEEDED) in
> > sdhci-of-arasan.c indicating DLL reset needed while tuning operation
> > - Call 'dll reset' routine before and after __sdhci_execute_tuning()
> > in sdhci.c when a host->quirk2 bit (SDHCI_QUIRK2_DLL_RESET_NEEDED) is
> > set
> 
> We should try to avoid quirks.

[PATCH v2 5/5] vfio: disable filesystem-dax page pinning

[Dan Williams]

Filesystem-DAX is incompatible with 'longterm' page pinning. Without
page cache indirection a DAX mapping maps filesystem blocks directly.
This means that the filesystem must not modify a file's block map while
any page in a mapping is pinned. In order to prevent the situation of
userspace holding of filesystem operations indefinitely, disallow
'longterm' Filesystem-DAX mappings.

RDMA has the same conflict and the plan there is to add a 'with lease'
mechanism to allow the kernel to notify userspace that the mapping is
being torn down for block-map maintenance. Perhaps something similar can
be put in place for vfio.

Note that xfs and ext4 still report:

   "DAX enabled. Warning: EXPERIMENTAL, use at your own risk"

...at mount time, and resolving the dax-dma-vs-truncate problem is one
of the last hurdles to remove that designation.

Acked-by: Alex Williamson 
Cc: Michal Hocko 
Cc: Christoph Hellwig 
Cc: k...@vger.kernel.org
Cc: 
Reported-by: Haozhong Zhang 
Fixes: d475c6346a38 ("dax,ext2: replace XIP read and write with DAX I/O")
Signed-off-by: Dan Williams 
---
 drivers/vfio/vfio_iommu_type1.c |   18 +++---
 1 file changed, 15 insertions(+), 3 deletions(-)

diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
index e30e29ae4819..45657e2b1ff7 100644
--- a/drivers/vfio/vfio_iommu_type1.c
+++ b/drivers/vfio/vfio_iommu_type1.c
@@ -338,11 +338,12 @@ static int vaddr_get_pfn(struct mm_struct *mm, unsigned 
long vaddr,
 {
struct page *page[1];
struct vm_area_struct *vma;
+   struct vm_area_struct *vmas[1];
int ret;
 
if (mm == current->mm) {
-   ret = get_user_pages_fast(vaddr, 1, !!(prot & IOMMU_WRITE),
- page);
+   ret = get_user_pages_longterm(vaddr, 1, !!(prot & IOMMU_WRITE),
+ page, vmas);
} else {
unsigned int flags = 0;
 
@@ -351,7 +352,18 @@ static int vaddr_get_pfn(struct mm_struct *mm, unsigned 
long vaddr,
 
down_read(&mm->mmap_sem);
ret = get_user_pages_remote(NULL, mm, vaddr, 1, flags, page,
-   NULL, NULL);
+   vmas, NULL);
+   /*
+* The lifetime of a vaddr_get_pfn() page pin is
+* userspace-controlled. In the fs-dax case this could
+* lead to indefinite stalls in filesystem operations.
+* Disallow attempts to pin fs-dax pages via this
+* interface.
+*/
+   if (ret > 0 && vma_is_fsdax(vmas[0])) {
+   ret = -EOPNOTSUPP;
+   put_page(page[0]);
+   }
up_read(&mm->mmap_sem);
}
 

[PATCH v2 4/5] dax: short circuit vma_is_fsdax() in the CONFIG_FS_DAX=n case

[Dan Williams]

Do not bother looking up the file type in the case when Filesystem-DAX
is disabled at build time.

Cc: Alexander Viro 
Cc: linux-fsde...@vger.kernel.org
Cc: Christoph Hellwig 
Cc: Jan Kara 
Signed-off-by: Dan Williams 
---
 include/linux/fs.h |2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/linux/fs.h b/include/linux/fs.h
index b2fa9b4c1e51..8f80d9fff86d 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -3195,6 +3195,8 @@ static inline bool vma_is_fsdax(struct vm_area_struct 
*vma)
 
if (!vma->vm_file)
return false;
+   if (!IS_ENABLED(CONFIG_FS_DAX))
+   return false;
if (!vma_is_dax(vma))
return false;
inode = file_inode(vma->vm_file);

[PATCH v2 1/5] dax: fix vma_is_fsdax() helper

[Dan Williams]

Gerd reports that ->i_mode may contain other bits besides S_IFCHR. Use
S_ISCHR() instead. Otherwise, get_user_pages_longterm() may fail on
device-dax instances when those are meant to be explicitly allowed.

Fixes: 2bb6d2837083 ("mm: introduce get_user_pages_longterm")
Cc: 
Reported-by: Gerd Rausch 
Reported-by: Haozhong Zhang 
Signed-off-by: Dan Williams 
---
 include/linux/fs.h |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/fs.h b/include/linux/fs.h
index 2a815560fda0..79c413985305 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -3198,7 +3198,7 @@ static inline bool vma_is_fsdax(struct vm_area_struct 
*vma)
if (!vma_is_dax(vma))
return false;
inode = file_inode(vma->vm_file);
-   if (inode->i_mode == S_IFCHR)
+   if (S_ISCHR(inode->i_mode))
return false; /* device-dax */
return true;
 }

Re: [PATCH v2 0/2] x86/pti: KVM: fixes and optimizations for IBRS

[Ingo Molnar]

* Paolo Bonzini  wrote:

> Two tiny patches for the IBRS code.  They should go in
> through the x86/pti tree and should apply to both 4.9 and 4.14 trees.
> 
> Thanks,
> 
> Paolo
> 
> v1->v2: remove patch 2, the same bug has already been fixed
> 
> Paolo Bonzini (3):
>   KVM: x86: use native MSR ops for SPEC_CTRL
>   KVM: VMX: mark RDMSR path as unlikely
> 
>  arch/x86/kvm/svm.c |  9 +
>  arch/x86/kvm/vmx.c |  9 +
>  2 files changed, 10 insertions(+), 8 deletions(-)

Applied to tip:x86/pti, with minor tweaks to the titles/changelogs.

If all goes fine in testing I will send all pending tip:x86/pti changes to 
Linus 
later today, so the KVM development tree should be able to pull in these 
changes 
via upstream pretty soon.

Thanks,

Ingo

[PATCH v2 0/5] vfio, dax: prevent long term filesystem-dax pins and other fixes

[Dan Williams]

Changes since v1 [1]:

* Fix the detection of device-dax file instances in vma_is_fsdax().
  (Haozhong, Gerd)

* Fix compile breakage in the FS_DAX=n and DEV_DAX=y case. (0day robot)

[1]: https://lists.01.org/pipermail/linux-nvdimm/2018-February/014046.html

---

The vfio interface, like RDMA, wants to setup long term (indefinite)
pins of the pages backing an address range so that a guest or userspace
driver can perform DMA to the with physical address. Given that this
pinning may lead to filesystem operations deadlocking in the
filesystem-dax case, the pinning request needs to be rejected.

The longer term fix for vfio, RDMA, and any other long term pin user, is
to provide a 'pin with lease' mechanism. Similar to the leases that are
hold for pNFS RDMA layouts, this userspace lease gives the kernel a way
to notify userspace that the block layout of the file is changing and
the kernel is revoking access to pinned pages.

---

Dan Williams (5):
  dax: fix vma_is_fsdax() helper
  dax: fix dax_mapping() definition in the FS_DAX=n + DEV_DAX=y case
  dax: fix S_DAX definition
  dax: short circuit vma_is_fsdax() in the CONFIG_FS_DAX=n case
  vfio: disable filesystem-dax page pinning


 drivers/vfio/vfio_iommu_type1.c |   18 +++---
 include/linux/dax.h |9 ++---
 include/linux/fs.h  |6 --
 3 files changed, 25 insertions(+), 8 deletions(-)

Re: [RFCv4 13/21] media: videobuf2-v4l2: support for requests

[Hans Verkuil]

On 02/23/2018 07:34 AM, Tomasz Figa wrote:
> On Wed, Feb 21, 2018 at 1:18 AM, Hans Verkuil  wrote:
>> On 02/20/2018 05:44 AM, Alexandre Courbot wrote:
>>> Add a new vb2_qbuf_request() (a request-aware version of vb2_qbuf())
>>> that request-aware drivers can call to queue a buffer into a request
>>> instead of directly into the vb2 queue if relevent.
>>>
>>> This function expects that drivers invoking it are using instances of
>>> v4l2_request_entity and v4l2_request_entity_data to describe their
>>> entity and entity data respectively.
>>>
>>> Also add the vb2_request_submit() helper function which drivers can
>>> invoke in order to queue all the buffers previously queued into a
>>> request into the regular vb2 queue.
>>>
>>> Signed-off-by: Alexandre Courbot 
>>> ---
>>>  .../media/common/videobuf2/videobuf2-v4l2.c   | 129 +-
>>>  include/media/videobuf2-v4l2.h|  59 
>>>  2 files changed, 187 insertions(+), 1 deletion(-)
>>>
>>
>> 
>>
>>> @@ -776,10 +899,14 @@ EXPORT_SYMBOL_GPL(vb2_ioctl_querybuf);
>>>  int vb2_ioctl_qbuf(struct file *file, void *priv, struct v4l2_buffer *p)
>>>  {
>>>   struct video_device *vdev = video_devdata(file);
>>> + struct v4l2_fh *fh = NULL;
>>> +
>>> + if (test_bit(V4L2_FL_USES_V4L2_FH, &vdev->flags))
>>> + fh = file->private_data;
>>
>> No need for this. All drivers using vb2 will also use v4l2_fh.
>>
>>>
>>>   if (vb2_queue_is_busy(vdev, file))
>>>   return -EBUSY;
>>> - return vb2_qbuf(vdev->queue, p);
>>> + return vb2_qbuf_request(vdev->queue, p, fh ? fh->entity : NULL);
>>>  }
>>>  EXPORT_SYMBOL_GPL(vb2_ioctl_qbuf);
>>>
>>> diff --git a/include/media/videobuf2-v4l2.h b/include/media/videobuf2-v4l2.h
>>> index 3d5e2d739f05..d4dfa266a0da 100644
>>> --- a/include/media/videobuf2-v4l2.h
>>> +++ b/include/media/videobuf2-v4l2.h
>>> @@ -23,6 +23,12 @@
>>>  #error VB2_MAX_PLANES != VIDEO_MAX_PLANES
>>>  #endif
>>>
>>> +struct media_entity;
>>> +struct v4l2_fh;
>>> +struct media_request;
>>> +struct media_request_entity;
>>> +struct v4l2_request_entity_data;
>>> +
>>>  /**
>>>   * struct vb2_v4l2_buffer - video buffer information for v4l2.
>>>   *
>>> @@ -116,6 +122,59 @@ int vb2_prepare_buf(struct vb2_queue *q, struct 
>>> v4l2_buffer *b);
>>>   */
>>>  int vb2_qbuf(struct vb2_queue *q, struct v4l2_buffer *b);
>>>
>>> +#if IS_ENABLED(CONFIG_MEDIA_REQUEST_API)
>>> +
>>> +/**
>>> + * vb2_qbuf_request() - Queue a buffer, with request support
>>> + * @q:   pointer to &struct vb2_queue with videobuf2 queue.
>>> + * @b:   buffer structure passed from userspace to
>>> + *   &v4l2_ioctl_ops->vidioc_qbuf handler in driver
>>> + * @entity:  request entity to queue for if requests are used.
>>> + *
>>> + * Should be called from &v4l2_ioctl_ops->vidioc_qbuf handler of a driver.
>>> + *
>>> + * If requests are not in use, calling this is equivalent to calling 
>>> vb2_qbuf().
>>> + *
>>> + * If the request_fd member of b is set, then the buffer represented by b 
>>> is
>>> + * queued in the request instead of the vb2 queue. The buffer will be 
>>> passed
>>> + * to the vb2 queue when the request is submitted.
>>
>> I would definitely also prepare the buffer at this time. That way you'll see 
>> any
>> errors relating to the prepare early on.
> 
> Would the prepare operation be completely independent of other state?
> I can see a case when how the buffer is to be prepared may depend on
> values of some controls. If so, it would be only possible at request
> submission time. Alternatively, the application would have to be
> mandated to include any controls that may affect buffer preparing in
> the request and before the QBUF is called.

The buffer is just memory. Controls play no role here. So the prepare
operation is indeed independent of other state. Anything else would make
this horrible complicated. And besides, with buffers allocated by other
subsystems (dmabuf) how could controls from our subsystems ever affect
those? The videobuf(2) frameworks have always just operated on memory
buffers without any knowledge of what it contains.

Regards,

Hans

[tip:x86/urgent] x86/intel_rdt: Fix incorrect returned value when creating rdgroup sub-directory in resctrl file system

[tip-bot for Wang Hui]

Commit-ID:  36e74d355297dde6e69a39c838d24710e442babe
Gitweb: https://git.kernel.org/tip/36e74d355297dde6e69a39c838d24710e442babe
Author: Wang Hui 
AuthorDate: Thu, 22 Feb 2018 19:26:03 -0800
Committer:  Ingo Molnar 
CommitDate: Fri, 23 Feb 2018 08:03:21 +0100

x86/intel_rdt: Fix incorrect returned value when creating rdgroup sub-directory 
in resctrl file system

If no monitoring feature is detected because all monitoring features are
disabled during boot time or there is no monitoring feature in hardware,
creating rdtgroup sub-directory by "mkdir" command reports error:

  mkdir: cannot create directory ‘/sys/fs/resctrl/p1’: No such file or directory

But the sub-directory actually is generated and content is correct:

  cpus  cpus_list  schemata  tasks

The error is because rdtgroup_mkdir_ctrl_mon() returns non zero value after
the sub-directory is created and the returned value is reported as an error
to user.

Clear the returned value to report to user that the sub-directory is
actually created successfully.

Signed-off-by: Wang Hui 
Signed-off-by: Zhang Yanfei 
Signed-off-by: Fenghua Yu 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Ravi V Shankar 
Cc: Thomas Gleixner 
Cc: Tony Luck 
Cc: Vikas 
Cc: Xiaochen Shen 
Link: 
http://lkml.kernel.org/r/1519356363-133085-1-git-send-email-fenghua...@intel.com
Signed-off-by: Ingo Molnar 
---
 arch/x86/kernel/cpu/intel_rdt_rdtgroup.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c 
b/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c
index bdab7d2f51af..fca759d272a1 100644
--- a/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c
+++ b/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c
@@ -1804,6 +1804,7 @@ static int rdtgroup_mkdir_ctrl_mon(struct kernfs_node 
*parent_kn,
goto out_common_fail;
}
closid = ret;
+   ret = 0;
 
rdtgrp->closid = closid;
list_add(&rdtgrp->rdtgroup_list, &rdt_all_groups);

[tip:x86/urgent] x86/apic/vector: Handle vector release on CPU unplug correctly

[tip-bot for Thomas Gleixner]

Commit-ID:  e84cf6aa501c58bf4bf451f1e425192ec090aed2
Gitweb: https://git.kernel.org/tip/e84cf6aa501c58bf4bf451f1e425192ec090aed2
Author: Thomas Gleixner 
AuthorDate: Thu, 22 Feb 2018 12:08:06 +0100
Committer:  Ingo Molnar 
CommitDate: Fri, 23 Feb 2018 08:02:00 +0100

x86/apic/vector: Handle vector release on CPU unplug correctly

When a irq vector is replaced, then the previous vector is normally
released when the first interrupt happens on the new vector. If the target
CPU of the previous vector is already offline when the new vector is
installed, then the previous vector is silently discarded, which leads to
accounting issues causing suspend failures and other problems.

Adjust the logic so that the previous vector is freed in the underlying
matrix allocator to ensure that the accounting stays correct.

Fixes: 69cde0004a4b ("x86/vector: Use matrix allocator for vector assignment")
Reported-by: Yuriy Vostrikov 
Signed-off-by: Thomas Gleixner 
Tested-by: Yuriy Vostrikov 
Cc: Peter Zijlstra 
Cc: Randy Dunlap 
Cc: sta...@vger.kernel.org
Link: https://lkml.kernel.org/r/20180222112316.930791...@linutronix.de
Signed-off-by: Ingo Molnar 
---
 arch/x86/kernel/apic/vector.c | 25 ++---
 1 file changed, 22 insertions(+), 3 deletions(-)

diff --git a/arch/x86/kernel/apic/vector.c b/arch/x86/kernel/apic/vector.c
index 3cc471beb50b..bb6f7a2148d7 100644
--- a/arch/x86/kernel/apic/vector.c
+++ b/arch/x86/kernel/apic/vector.c
@@ -134,21 +134,40 @@ static void apic_update_vector(struct irq_data *irqd, 
unsigned int newvec,
 {
struct apic_chip_data *apicd = apic_chip_data(irqd);
struct irq_desc *desc = irq_data_to_desc(irqd);
+   bool managed = irqd_affinity_is_managed(irqd);
 
lockdep_assert_held(&vector_lock);
 
trace_vector_update(irqd->irq, newvec, newcpu, apicd->vector,
apicd->cpu);
 
-   /* Setup the vector move, if required  */
-   if (apicd->vector && cpu_online(apicd->cpu)) {
+   /*
+* If there is no vector associated or if the associated vector is
+* the shutdown vector, which is associated to make PCI/MSI
+* shutdown mode work, then there is nothing to release. Clear out
+* prev_vector for this and the offlined target case.
+*/
+   apicd->prev_vector = 0;
+   if (!apicd->vector || apicd->vector == MANAGED_IRQ_SHUTDOWN_VECTOR)
+   goto setnew;
+   /*
+* If the target CPU of the previous vector is online, then mark
+* the vector as move in progress and store it for cleanup when the
+* first interrupt on the new vector arrives. If the target CPU is
+* offline then the regular release mechanism via the cleanup
+* vector is not possible and the vector can be immediately freed
+* in the underlying matrix allocator.
+*/
+   if (cpu_online(apicd->cpu)) {
apicd->move_in_progress = true;
apicd->prev_vector = apicd->vector;
apicd->prev_cpu = apicd->cpu;
} else {
-   apicd->prev_vector = 0;
+   irq_matrix_free(vector_matrix, apicd->cpu, apicd->vector,
+   managed);
}
 
+setnew:
apicd->vector = newvec;
apicd->cpu = newcpu;
BUG_ON(!IS_ERR_OR_NULL(per_cpu(vector_irq, newcpu)[newvec]));

Re: [PATCH] Bluetooth: btusb: Restore QCA Rome suspend/resume fix with a "rewritten" version

[Hans de Goede]

Hi,

On 23-02-18 04:12, Brian Norris wrote:

Hi Hans,

Sorry if I'm a little slow to follow up here. This hasn't been my
top priority...

On Mon, Feb 19, 2018 at 11:17:24AM +0100, Hans de Goede wrote:

On 16-02-18 18:59, Brian Norris wrote:

On Fri, Feb 16, 2018 at 01:10:20PM +0100, Hans de Goede wrote:

Ok, I've asked the reporter of:

https://bugzilla.redhat.com/show_bug.cgi?id=1514836


Are you even sure that this reporter is seeing the original symptom at
all (BT loses power, and therefore firmware)? Their report shows them
running 4.15, which had this commit:

fd865802c66b Bluetooth: btusb: fix QCA Rome suspend/resume

which is admittedly completely broken. It breaks even perfectly working
BT/USB devices, like mine. That's where I first complained, and we got
this into 4.16-rc1:

7d06d5895c15 Revert "Bluetooth: btusb: fix QCA Rome suspend/resume"

Isn't it possible your reporter has no further problem, and none if this
is actually important to them? I'd just caution you to be careful before
assuming you need to add blacklist info for their DMI...


Thanks, that is a good question. His problems only started when I
enabled usb-autosuspend by default for btusb devices and he got things
working by adding "btusb.enable_autosuspend=n" on the kernel commandline,
so he was not hitting the firmware loading race introduced by
fd865802c66b and runtime suspend/resume is really broken for him.


Hmm? I'm not sure I completely follow here when you say "he was not
hitting the firmware loading race". If things were functioning fine with
system suspend (but not with autosuspend), then he's not seeing the
controller (quoting commit fd865802c66b) "losing power during suspend".


He was running a kernel with the original "fd865802c66b Bluetooth: btusb:
fix QCA Rome suspend/resume" commit, which fixes regular suspend for
devices which are "losing power during suspend", but does nothing for
runtime-suspend.

He ran tests both with and without runtime-pm enabled with that same kernel
and he needed to disable runtime-pm to get working bluetooth.


So, that would suggest he could only be seeing the race (as I was), and
that his machine does not deserve a RESET_RESUME quirk?


I hope my above answer helps to clarify why I believe the quirk is
necessary on his machine.

Regards,

Hans




Or maybe I'm really misunderstanding.


As I read it, you need to investigate who are the "numerous reported
instances" that generated commit fd865802c66b in the first place. That's
where this mess started, IIUC. >
But otherwise, yes, option 3 sounds OK. FWIW, my systems are ARM based
and don't have DMI data, so option 2 wouldn't work.


Right I think we all agree that the new plan now is to go back to
QCA behaving normally wrt (runtime) suspend/resume and then set the
USB-core RESET_RESUME quirk (which does not have the firmware
loading race) based on a DMI blacklist.

I only have the one report for which I will write a patch implementing
this new policy soonish. And Kai-Heng Feng has another report which
might even be the machine. I certainly would not be surprised if it
is another Lenovo machine.


It seems like you folks moved forward on that one. Thanks.

Brian

Re: [PATCH v12 1/3] mm, powerpc, x86: define VM_PKEY_BITx bits if CONFIG_ARCH_HAS_PKEYS is enabled

[kbuild test robot]

Hi Ram,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on linus/master]
[also build test ERROR on v4.16-rc2 next-20180222]
[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/Ram-Pai/mm-x86-powerpc-Enhancements-to-Memory-Protection-Keys/20180223-042743
config: powerpc-allmodconfig (attached as .config)
compiler: powerpc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=powerpc 

Note: the 
linux-review/Ram-Pai/mm-x86-powerpc-Enhancements-to-Memory-Protection-Keys/20180223-042743
 HEAD c5692bca45543c242ffca15c811923e4c548ed19 builds fine.
  It only hurts bisectibility.

All error/warnings (new ones prefixed by >>):

   In file included from include/linux/pkeys.h:9:0,
from arch/powerpc/include/asm/mman.h:16,
from include/uapi/linux/mman.h:5,
from include/linux/mman.h:9,
from arch/powerpc/kernel/asm-offsets.c:22:
   arch/powerpc/include/asm/pkeys.h: In function 'pkey_to_vmflag_bits':
>> arch/powerpc/include/asm/pkeys.h:32:23: error: 'VM_PKEY_BIT4' undeclared 
>> (first use in this function); did you mean 'VM_PKEY_BIT0'?
   VM_PKEY_BIT3 | VM_PKEY_BIT4)
  ^
>> arch/powerpc/include/asm/pkeys.h:42:41: note: in expansion of macro 
>> 'ARCH_VM_PKEY_FLAGS'
 return (((u64)pkey << VM_PKEY_SHIFT) & ARCH_VM_PKEY_FLAGS);
^~
   arch/powerpc/include/asm/pkeys.h:32:23: note: each undeclared identifier is 
reported only once for each function it appears in
   VM_PKEY_BIT3 | VM_PKEY_BIT4)
  ^
>> arch/powerpc/include/asm/pkeys.h:42:41: note: in expansion of macro 
>> 'ARCH_VM_PKEY_FLAGS'
 return (((u64)pkey << VM_PKEY_SHIFT) & ARCH_VM_PKEY_FLAGS);
^~
   arch/powerpc/include/asm/pkeys.h: In function 'vmflag_to_pte_pkey_bits':
   arch/powerpc/include/asm/pkeys.h:54:16: error: 'VM_PKEY_BIT4' undeclared 
(first use in this function); did you mean 'VM_PKEY_BIT0'?
  ((vm_flags & VM_PKEY_BIT4) ? H_PTE_PKEY_BIT0 : 0x0UL));
   ^~~~
   VM_PKEY_BIT0
   arch/powerpc/include/asm/pkeys.h: In function 'vma_pkey':
>> arch/powerpc/include/asm/pkeys.h:32:23: error: 'VM_PKEY_BIT4' undeclared 
>> (first use in this function); did you mean 'VM_PKEY_BIT0'?
   VM_PKEY_BIT3 | VM_PKEY_BIT4)
  ^
   arch/powerpc/include/asm/pkeys.h:61:26: note: in expansion of macro 
'ARCH_VM_PKEY_FLAGS'
 return (vma->vm_flags & ARCH_VM_PKEY_FLAGS) >> VM_PKEY_SHIFT;
 ^~
   make[2]: *** [arch/powerpc/kernel/asm-offsets.s] Error 1
   make[2]: Target '__build' not remade because of errors.
   make[1]: *** [prepare0] Error 2
   make[1]: Target 'prepare' not remade because of errors.
   make: *** [sub-make] Error 2

vim +32 arch/powerpc/include/asm/pkeys.h

4fb158f6 Ram Pai 2018-01-18  30  
4fb158f6 Ram Pai 2018-01-18  31  #define ARCH_VM_PKEY_FLAGS (VM_PKEY_BIT0 | 
VM_PKEY_BIT1 | VM_PKEY_BIT2 | \
4fb158f6 Ram Pai 2018-01-18 @32 VM_PKEY_BIT3 | 
VM_PKEY_BIT4)
4fb158f6 Ram Pai 2018-01-18  33  
013a91b3 Ram Pai 2018-01-18  34  /* Override any generic PKEY permission 
defines */
013a91b3 Ram Pai 2018-01-18  35  #define PKEY_DISABLE_EXECUTE   0x4
013a91b3 Ram Pai 2018-01-18  36  #define PKEY_ACCESS_MASK   
(PKEY_DISABLE_ACCESS | \
013a91b3 Ram Pai 2018-01-18  37 
PKEY_DISABLE_WRITE  | \
013a91b3 Ram Pai 2018-01-18  38 
PKEY_DISABLE_EXECUTE)
013a91b3 Ram Pai 2018-01-18  39  
013a91b3 Ram Pai 2018-01-18  40  static inline u64 pkey_to_vmflag_bits(u16 pkey)
013a91b3 Ram Pai 2018-01-18  41  {
013a91b3 Ram Pai 2018-01-18 @42 return (((u64)pkey << VM_PKEY_SHIFT) & 
ARCH_VM_PKEY_FLAGS);
013a91b3 Ram Pai 2018-01-18  43  }
013a91b3 Ram Pai 2018-01-18  44  

:: The code at line 32 was first introduced by commit
:: 4fb158f65ac5556b9b4a6f63f38272853ed99b22 powerpc: track allocation 
status of all pkeys

:: TO: Ram Pai 
:: CC: Michael Ellerman 

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


.config.gz
Description: application/gzip

Re: [PATCH v2] x86/apic: Move pending intr check code into it's own function

[Ingo Molnar]

* Dou Liyang  wrote:

> the pending interrupt check code is mixed with the local APIC setup code,
> that looks messy.
> 
> Extract the related code, move it into a new function named
> apic_pending_intr_clear().
> 
> bonus cleanups from Andy Shevchenko's suggestions:
> 
>   - for() -> for_each_set_bit()
>   - printk() -> pr_err()

Please split the cleanups (and the cleanups suggested further below) into a 
separate patch, so that there's a pure 'code movement' patch plus another patch 
that is easy to review.

> + /*
> +  * After a crash, we no longer service the interrupts and a pending
> +  * interrupt from previous kernel might still have ISR bit set.
> +  *
> +  * Most probably by now CPU has serviced that pending interrupt and
> +  * it might not have done the ack_APIC_irq() because it thought,
> +  * interrupt came from i8259 as ExtInt. LAPIC did not get EOI so it
> +  * does not clear the ISR bit and cpu thinks it has already serivced
> +  * the interrupt. Hence a vector might get locked. It was noticed
> +  * for timer irq (vector 0x31). Issue an extra EOI to clear ISR.
> +  */
> + do {
> + queued = 0;
> + for (i = APIC_ISR_NR - 1; i >= 0; i--)
> + queued |= apic_read(APIC_IRR + i*0x10);
> +
> + for (i = APIC_ISR_NR - 1; i >= 0; i--) {
> + value = apic_read(APIC_ISR + i*0x10);
> + for_each_set_bit(j, &value, 32) {
> + if (j) {
> + ack_APIC_irq();
> + acked++;
> + }
> + }
> + }
> + if (acked > 256) {
> + pr_err("LAPIC pending interrupts after %d EOI\n",
> + acked);

Please don't
break the line of
printk's.


> + if (queued) {
> + if (boot_cpu_has(X86_FEATURE_TSC) && cpu_khz) {
> + ntsc = rdtsc();
> + max_loops = (cpu_khz << 10) - (ntsc - tsc);
> + } else
> + max_loops--;

unbalanced curly braces.

Thanks,

Ingo

Re: [PATCH v2 19/19] ARM64: dts: r8a77965: Add EtherAVB device node

[Geert Uytterhoeven]

Hi Simon,

On Thu, Feb 22, 2018 at 4:54 PM, Simon Horman  wrote:
> On Wed, Feb 21, 2018 at 09:53:58PM +0300, Sergei Shtylyov wrote:
>> On 02/21/2018 09:23 PM, Simon Horman wrote:
>>
>> > ...
>> >
>>  +clocks = <&cpg CPG_MOD 812>;
>>  +power-domains = <&sysc 32>;
>>  +resets = <&cpg 812>;
>>  +phy-mode = "rgmii-txid";
>> >>>
>> >>>Why not just "rgmii"? TX delay is a board specific detail, no?
>> >>>
>> >> I admit I took this one straight from r8a7796 dtsi.
>> >> Would you like to me resend and change this?
>> >
>> >Yes, unless Simon would fix it while merging...
>> 
>>  Can I confirm the desired change is s/rgmii-txid/rgmii/ ?
>> >>>
>> >>>Yes.
>> >>
>> >>Apparently that means that this prop should be overridden in the board 
>> >> file
>> >> (which may not be an easy task given the board is Salvator-XS again).
>> >>
>> >> [...]
>> >
>> > Can we override it in r8a77965-salvator-x.dts or r8a77965-salvator-xs.dts?
>>
>>In salvator-common.dtsi most probably -- it has the PHY data for Ether 
>> AVB.
>>
>> > I feel that I'm missing an important point here.
>>
>>Well, r8a779{5|6}.dtsi also have phy-mode = "rgmii-txid" (which was
>>unjustified in my current understanding). Thus such board override
>>wouldn't hurt them. But we lack a patch modifying salvator-common.dtsi
>>in htis series, so I'm now thinking a respin of this series is needed
>>anyway... sorry for being unclear. :-)
>
> While I've applied other patches in this series I have
> not applied this one - mainly to allow this discussion to conclude.
>
> Is an appropriate solution to do the following?
>
> 1) Atomically update
>a) r8a779{5|6}.dtsi to use "rgmii" and
>b) salvator-common.dtsi to use "rgmii-txid"
> 2) Update this patch to use "rgmii"

No need for atomics.
It can all be done by patches touching single files only:
  1) Add "rgmii-txid" to board .dts(i) files,
  2) Change s/rgmii-txid/rgmii/ in SoC .dtsi files.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

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

Re: [PATCH] selftest: fix kselftest-merge depend on 'RUNTIME_TESTING_MENU'

[Zong Li]

2018-02-23 3:57 GMT+08:00 Anders Roxell :
> On 22 February 2018 at 12:53, Zong Li  wrote:
>> Since the 'commit d3deafaa8b5c ("lib/: make RUNTIME_TESTS a menuconfig
>> to ease disabling it all")', the make kselftest-merge cannot merge the
>> config dependencies of kselftest to the existing .config file.
>>
>> These config dependencies of kselftest need to enable the
>> 'CONFIG_RUNTIME_TESTING_MENU=y' at the same time.
>
> Is this patch needed when patch sha 'f29c79906064 ("lib/Kconfig.debug: enable
> RUNTIME_TESTING_MENU")' find its way into the kernel ?
> I think it's in linux-next now.

Thanks. The patch sha 'f29c79906064 ("lib/Kconfig.debug: enable
RUNTIME_TESTING_MENU")' can resolve the make kselftest-merge
on default situation, but I think the kselftest-merge should resolve
the dependencies
without the prerequisite, it should enable the 'RUNTIME_TESTING_MENU'
when merging
the config of some selftests if RUNTIME_TESTING_MENU is not set.

Best Regards,
Zong Li

Re: [PATCH 1/9] scsi: ufs: Allowing power mode change

[Asutosh Das (asd)]

On 2/23/2018 10:40 AM, Kyuho Choi wrote:

Hi Asutosh,

I've simple question in below.

On 2/21/18, Asutosh Das  wrote:

From: Yaniv Gardi 

Due to M-PHY issues, moving from HS to any other mode or gear or
even Hibern8 causes some un-predicted behavior of the device.
This patch fixes this issues.

Signed-off-by: Yaniv Gardi 
Signed-off-by: Subhash Jadavani 
Signed-off-by: Can Guo 
Signed-off-by: Asutosh Das 
---
  drivers/scsi/ufs/ufshcd.c | 6 +-
  1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 011c336..d74d529 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -4167,9 +4167,13 @@ static int ufshcd_link_startup(struct ufs_hba *hba)
goto out;
} while (ret && retries--);

-   if (ret)
+   if (ret) {
/* failed to get the link up... retire */
goto out;
+   } else {
+   ufshcd_dme_set(hba, UIC_ARG_MIB(TX_LCC_ENABLE), 0);
+   ufshcd_dme_set(hba, UIC_ARG_MIB(TX_LCC_ENABLE), 1);
+   }



Every ufs host has same issue and affected?.


if (link_startup_again) {
link_startup_again = false;
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center,
Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
Foundation Collaborative Project.



Hi Choi
Thanks for the review.

No - I can't say if every host has the same issue. However, I get your 
point. It could be done with a quirk.


I'll fix this in v2 after collating all the comments from the rest of 
the patches.


-asd

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

[PATCH arm/aspeed/ast2500 v2] eSPI: add ASPEED AST2500 eSPI driver to boot a host with PCH runs on eSPI

[Haiyue Wang]

When PCH works under eSPI mode, the PMC (Power Management Controller) in
PCH is waiting for SUS_ACK from BMC after it alerts SUS_WARN. It is in
dead loop if no SUS_ACK assert. This is the basic requirement for the BMC
works as eSPI slave.

Also for the host power on / off actions, from BMC side, the following VW
(Virtual Wire) messages are done in firmware:
1. SLAVE_BOOT_LOAD_DONE / SLAVE_BOOT_LOAD_STATUS
2. SUS_ACK
3. OOB_RESET_ACK
4. HOST_RESET_ACK

Signed-off-by: Haiyue Wang 
---
v1 -> v2:
 - Fix the checkpatch.pl warning in file espi-slave.rst
   Missing or malformed SPDX-License-Identifier tag in line 1
   #71: FILE: Documentation/misc-devices/espi-slave.rst:1:
 - Make the Kconfig desciption to be more accurate.
---
 .../devicetree/bindings/misc/aspeed,espi-slave.txt |  20 ++
 Documentation/misc-devices/espi-slave.rst  | 119 ++
 drivers/misc/Kconfig   |   7 +
 drivers/misc/Makefile  |   1 +
 drivers/misc/aspeed-espi-slave.c   | 263 +
 5 files changed, 410 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/misc/aspeed,espi-slave.txt
 create mode 100644 Documentation/misc-devices/espi-slave.rst
 create mode 100644 drivers/misc/aspeed-espi-slave.c

diff --git a/Documentation/devicetree/bindings/misc/aspeed,espi-slave.txt 
b/Documentation/devicetree/bindings/misc/aspeed,espi-slave.txt
new file mode 100644
index 000..35da26f
--- /dev/null
+++ b/Documentation/devicetree/bindings/misc/aspeed,espi-slave.txt
@@ -0,0 +1,20 @@
+Aspeed eSPI Slave Controller
+
+Required properties:
+ - compatible: must be one of:
+   - "aspeed,ast2500-espi-slave"
+
+ - reg: physical base address of the controller and length of memory mapped
+   region
+
+ - interrupts: interrupt generated by the controller
+
+Example:
+
+espi: espi@1e6ee000 {
+compatible = "aspeed,ast2500-espi-slave";
+reg = <0x1e6ee000 0x100>;
+interrupts = <23>;
+status = "disabled";
+};
+
diff --git a/Documentation/misc-devices/espi-slave.rst 
b/Documentation/misc-devices/espi-slave.rst
new file mode 100644
index 000..185acd7
--- /dev/null
+++ b/Documentation/misc-devices/espi-slave.rst
@@ -0,0 +1,119 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+==
+eSPI Slave
+==
+
+:Author: Haiyue Wang 
+
+The PCH (**eSPI master**) provides the eSPI to support connection of a
+BMC (**eSPI slave**) to the platform.
+
+The LPC and eSPI interfaces are mutually exclusive. Both use the same
+pins, but on power-up, a HW strap determines if the eSPI or the LPC bus
+is operational. Once selected, it’s not possible to change to the other
+interface.
+
+``eSPI Channels and Supported Transactions``
+ +--+-+--++
+ | CH # | Channel | Posted Cycles| Non-Posted Cycles  |
+ +==+=+==++
+ |  0   | Peripheral  | Memory Write,| Memory Read,   |
+ |  | | Completions  | I/O Read/Write |
+ +--+-+--++
+ |  1   | Virtual Wire| Virtual Wire GET/PUT | N/A|
+ +--+-+--++
+ |  2   | Out-of-Band Message | SMBus Packet GET/PUT | N/A|
+ +--+-+--++
+ |  3   | Flash Access| N/A  | Flash Read, Write, |
+ |  | |  | Erase  |
+ +--+-+--++
+ |  N/A | General | Register Accesses| N/A|
+ +--+-+--++
+
+Virtual Wire Channel (Channel 1) Overview
+-
+
+The Virtual Wire channel uses a standard message format to communicate
+several types of signals between the components on the platform::
+
+ - Sideband and GPIO Pins: System events and other dedicated signals
+   between the PCH and eSPI slave. These signals are tunneled between the
+   two components over eSPI.
+
+ - Serial IRQ Interrupts: Interrupts are tunneled from the eSPI slave to
+   the PCH. Both edge and triggered interrupts are supported.
+
+When PCH runs on eSPI mode, from BMC side, the following VW messages are
+done in firmware::
+
+ 1. SLAVE_BOOT_LOAD_DONE / SLAVE_BOOT_LOAD_STATUS
+ 2. SUS_ACK
+ 3. OOB_RESET_ACK
+ 4. HOST_RESET_ACK
+
+``eSPI Virtual Wires (VW)``
+ +--+-+---+
+ |Virtual Wire  |PCH Pin  |Comments   |
+ |  |Direction|   |
+ +==+=+===+
+ |SUS_W

Re: [PATCH 4/9] drm/xen-front: Implement Xen event channel handling

[Oleksandr Andrushchenko]

On 02/23/2018 01:50 AM, Boris Ostrovsky wrote:

On 02/21/2018 03:03 AM, Oleksandr Andrushchenko wrote:

+
+static irqreturn_t evtchnl_interrupt_ctrl(int irq, void *dev_id)
+{
+   struct xen_drm_front_evtchnl *evtchnl = dev_id;
+   struct xen_drm_front_info *front_info = evtchnl->front_info;
+   struct xendispl_resp *resp;
+   RING_IDX i, rp;
+   unsigned long flags;
+
+   spin_lock_irqsave(&front_info->io_lock, flags);
+
+   if (unlikely(evtchnl->state != EVTCHNL_STATE_CONNECTED))
+   goto out;

Do you need to check the state under lock? (in other routines too).

not really, will move out of the lock in interrupt handlers
other places (I assume you refer to be_stream_do_io)
it is set under lock as a part of atomic operation, e.g.
we get a new request pointer from the ring and reset completion
So, those places still seem to be ok

...


+
+static void evtchnl_free(struct xen_drm_front_info *front_info,
+   struct xen_drm_front_evtchnl *evtchnl)
+{
+   unsigned long page = 0;
+
+   if (evtchnl->type == EVTCHNL_TYPE_REQ)
+   page = (unsigned long)evtchnl->u.req.ring.sring;
+   else if (evtchnl->type == EVTCHNL_TYPE_EVT)
+   page = (unsigned long)evtchnl->u.evt.page;
+   if (!page)
+   return;
+
+   evtchnl->state = EVTCHNL_STATE_DISCONNECTED;
+
+   if (evtchnl->type == EVTCHNL_TYPE_REQ) {
+   /* release all who still waits for response if any */
+   evtchnl->u.req.resp_status = -EIO;
+   complete_all(&evtchnl->u.req.completion);
+   }
+
+   if (evtchnl->irq)
+   unbind_from_irqhandler(evtchnl->irq, evtchnl);
+
+   if (evtchnl->port)
+   xenbus_free_evtchn(front_info->xb_dev, evtchnl->port);
+
+   /* end access and free the page */
+   if (evtchnl->gref != GRANT_INVALID_REF)
+   gnttab_end_foreign_access(evtchnl->gref, 0, page);
+
+   if (evtchnl->type == EVTCHNL_TYPE_REQ)
+   evtchnl->u.req.ring.sring = NULL;
+   else
+   evtchnl->u.evt.page = NULL;
+
+   memset(evtchnl, 0, sizeof(*evtchnl));

Since you are zeroing out the structure you don't need to set fields to
zero.

good catch, thank you

I also think you need to free the page.

it is freed by gnttab_end_foreign_access, please see [1]

-boris


[1] 
https://elixir.bootlin.com/linux/v4.11-rc1/source/drivers/xen/grant-table.c#L380

[PATCH bpf-next] bpf: NULL pointer check is not needed in BPF_CGROUP_RUN_PROG_INET_SOCK

[Yafang Shao]

sk is already allocated in inet_create/inet6_create, hence when
BPF_CGROUP_RUN_PROG_INET_SOCK is executed sk will never be NULL.

The logic is as bellow,
sk = sk_alloc();
if (!sk)
goto out;
BPF_CGROUP_RUN_PROG_INET_SOCK(sk);

Signed-off-by: Yafang Shao 
---
 include/linux/bpf-cgroup.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/bpf-cgroup.h b/include/linux/bpf-cgroup.h
index a7f16e0..8a45666 100644
--- a/include/linux/bpf-cgroup.h
+++ b/include/linux/bpf-cgroup.h
@@ -96,7 +96,7 @@ int __cgroup_bpf_check_dev_permission(short dev_type, u32 
major, u32 minor,
 #define BPF_CGROUP_RUN_PROG_INET_SOCK(sk) \
 ({\
int __ret = 0; \
-   if (cgroup_bpf_enabled && sk) {\
+   if (cgroup_bpf_enabled) {  \
__ret = __cgroup_bpf_run_filter_sk(sk, \
 BPF_CGROUP_INET_SOCK_CREATE); \
}  \
--
1.8.3.1

Re: hpsa crashes on boot in 4.16-rc2-00062

[Meelis Roos]

> This happens on a HP DL360 G6 with Smart Array 410i.
> 
> Will try to bisect.
> 
> IO completion timeout could be because of some IRQ toubles?

Reverting 84676c1f21e8ff54befe985f4f14dc1edc10046b fixes it for me (as 
suggested by Laurence Oberman).

-- 
Meelis Roos (mr...@linux.ee)

Re: [PATCH v10 6/7] PCI: Unify wait for link active into generic pci

[poza]

On 2018-02-23 00:13, Christoph Hellwig wrote:


+/**
+ * pci__wait_for_link - Wait for link till its active/inactive


typo - just wants a single underscore.


+   pcie_capability_read_word(pdev, PCI_EXP_LNKSTA, &lnk_status);
+   ret = !!(lnk_status & PCI_EXP_LNKSTA_DLLLA);


no need for the !! when assigning to a boolean.


bool is 8 bit, while
#define  PCI_EXP_LNKSTA_DLLLA   0x2000  /* Data Link Layer Link Active */
so I think we need it. otherwise it will treat lnk_status & 
PCI_EXP_LNKSTA_DLLLA as 0 even if 13th bit is set.





+
+   while ((ret != active) && (timeout > 0)) {


No need for either pair of inner braces.


+   msleep(10);
+   timeout -= 10;
+   pcie_capability_read_word(pdev, PCI_EXP_LNKSTA, &lnk_status);
+   ret = !!(lnk_status & PCI_EXP_LNKSTA_DLLLA);


Same as above.


+   }
+
+   if (ret == active)
+   return true;


Seems like the structure is a bit odd.  Why not:

for (;;) {
pcie_capability_read_word(pdev, PCI_EXP_LNKSTA, &lnk_status);
if ((lnk_status & PCI_EXP_LNKSTA_DLLLA) == active)
return true;
if (timeout <= 0)
break;
timeout -= 10;
}


Thanks for suggestion, will do this way. thanks.
Regards,
Oza.

Re: [PATCH 3/9] drm/xen-front: Read driver configuration from Xen store

[Oleksandr Andrushchenko]

On 02/23/2018 01:20 AM, Boris Ostrovsky wrote:

On 02/21/2018 03:03 AM, Oleksandr Andrushchenko wrote:

+
+static int cfg_connector(struct xen_drm_front_info *front_info,
+   struct xen_drm_front_cfg_connector *connector,
+   const char *path, int index)
+{
+   char *connector_path;
+
+   connector_path = devm_kasprintf(&front_info->xb_dev->dev,
+   GFP_KERNEL, "%s/%d", path, index);
+   if (!connector_path)
+   return -ENOMEM;
+
+   connector->xenstore_path = connector_path;
+   if (xenbus_scanf(XBT_NIL, connector_path, XENDISPL_FIELD_RESOLUTION,
+   "%d" XENDISPL_RESOLUTION_SEPARATOR "%d",
+   &connector->width, &connector->height) < 0) {
+   /* either no entry configured or wrong resolution set */
+   connector->width = 0;
+   connector->height = 0;

Do you also need to set connector->xenstore_path to NULL? Or maybe just
set it after xenbus_scanf() call.

Will move it down the code, after "if", thank you

-boris

[PATCH 4/6] arm64: dts: stratix10: remove 'num-slots' property for dwmmc

[Jaehoon Chung]

Since 'num-slots' had already deprecated, remove the property in
device-tree file.

Signed-off-by: Jaehoon Chung 
---
 arch/arm64/boot/dts/altera/socfpga_stratix10_socdk.dts | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm64/boot/dts/altera/socfpga_stratix10_socdk.dts 
b/arch/arm64/boot/dts/altera/socfpga_stratix10_socdk.dts
index a37c46112876..4e146b4e6487 100644
--- a/arch/arm64/boot/dts/altera/socfpga_stratix10_socdk.dts
+++ b/arch/arm64/boot/dts/altera/socfpga_stratix10_socdk.dts
@@ -88,7 +88,6 @@
 
 &mmc {
status = "okay";
-   num-slots = <1>;
cap-sd-highspeed;
broken-cd;
bus-width = <4>;
-- 
2.15.1

[PATCH 6/6] arm64: dts: hi3660: remove 'num-slots' property for dwmmc

[Jaehoon Chung]

Since 'num-slots' had already deprecated, remove the property in
device-tree file.

Signed-off-by: Jaehoon Chung 
---
 arch/arm64/boot/dts/hisilicon/hi3660.dtsi | 2 --
 1 file changed, 2 deletions(-)

diff --git a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi 
b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
index ab0b95ba5ae5..d6638b1f09ca 100644
--- a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
@@ -910,7 +910,6 @@
#size-cells = <0>;
cd-inverted;
compatible = "hisilicon,hi3660-dw-mshc";
-   num-slots = <1>;
bus-width = <0x4>;
disable-wp;
cap-sd-highspeed;
@@ -948,7 +947,6 @@
compatible = "hisilicon,hi3660-dw-mshc";
reg = <0x0 0xff3ff000 0x0 0x1000>;
interrupts = ;
-   num-slots = <1>;
clocks = <&crg_ctrl HI3660_CLK_GATE_SDIO0>,
 <&crg_ctrl HI3660_HCLK_GATE_SDIO0>;
clock-names = "ciu", "biu";
-- 
2.15.1

[PATCH 5/6] ARM: dts: lpc18xx: remove 'num-slots' property for dwmmc

[Jaehoon Chung]

Since 'num-slots' had already deprecated, remove the property in
device-tree file.

Signed-off-by: Jaehoon Chung 
---
 arch/arm/boot/dts/lpc18xx.dtsi | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm/boot/dts/lpc18xx.dtsi b/arch/arm/boot/dts/lpc18xx.dtsi
index 7cae9c5e27db..10b8249b8ab6 100644
--- a/arch/arm/boot/dts/lpc18xx.dtsi
+++ b/arch/arm/boot/dts/lpc18xx.dtsi
@@ -115,7 +115,6 @@
compatible = "snps,dw-mshc";
reg = <0x40004000 0x1000>;
interrupts = <6>;
-   num-slots = <1>;
clocks = <&ccu2 CLK_SDIO>, <&ccu1 CLK_CPU_SDIO>;
clock-names = "ciu", "biu";
resets = <&rgu 20>;
-- 
2.15.1

[PATCH 3/6] ARM: dts: socfpga: remove 'num-slots' property for dwmmc

[Jaehoon Chung]

Since 'num-slots' had already deprecated, remove the property in
device-tree file.

Signed-off-by: Jaehoon Chung 
---
 arch/arm/boot/dts/socfpga_arria10_socdk_sdmmc.dts | 1 -
 arch/arm/boot/dts/socfpga_arria5.dtsi | 1 -
 arch/arm/boot/dts/socfpga_cyclone5.dtsi   | 1 -
 arch/arm/boot/dts/socfpga_vt.dts  | 1 -
 4 files changed, 4 deletions(-)

diff --git a/arch/arm/boot/dts/socfpga_arria10_socdk_sdmmc.dts 
b/arch/arm/boot/dts/socfpga_arria10_socdk_sdmmc.dts
index 040a164ba148..5822fd2085db 100644
--- a/arch/arm/boot/dts/socfpga_arria10_socdk_sdmmc.dts
+++ b/arch/arm/boot/dts/socfpga_arria10_socdk_sdmmc.dts
@@ -20,7 +20,6 @@
 
 &mmc {
status = "okay";
-   num-slots = <1>;
cap-sd-highspeed;
broken-cd;
bus-width = <4>;
diff --git a/arch/arm/boot/dts/socfpga_arria5.dtsi 
b/arch/arm/boot/dts/socfpga_arria5.dtsi
index 8c037297296c..e59461f5416e 100644
--- a/arch/arm/boot/dts/socfpga_arria5.dtsi
+++ b/arch/arm/boot/dts/socfpga_arria5.dtsi
@@ -30,7 +30,6 @@
};
 
mmc0: dwmmc0@ff704000 {
-   num-slots = <1>;
broken-cd;
bus-width = <4>;
cap-mmc-highspeed;
diff --git a/arch/arm/boot/dts/socfpga_cyclone5.dtsi 
b/arch/arm/boot/dts/socfpga_cyclone5.dtsi
index a05e3df23103..68ced67f8bfb 100644
--- a/arch/arm/boot/dts/socfpga_cyclone5.dtsi
+++ b/arch/arm/boot/dts/socfpga_cyclone5.dtsi
@@ -31,7 +31,6 @@
};
 
mmc0: dwmmc0@ff704000 {
-   num-slots = <1>;
broken-cd;
bus-width = <4>;
cap-mmc-highspeed;
diff --git a/arch/arm/boot/dts/socfpga_vt.dts b/arch/arm/boot/dts/socfpga_vt.dts
index dfe2193cd4d5..547c38632c68 100644
--- a/arch/arm/boot/dts/socfpga_vt.dts
+++ b/arch/arm/boot/dts/socfpga_vt.dts
@@ -42,7 +42,6 @@
};
 
dwmmc0@ff704000 {
-   num-slots = <1>;
broken-cd;
bus-width = <4>;
cap-mmc-highspeed;
-- 
2.15.1

[PATCH 1/6] mmc: dw_mmc: remove the deprecated "clock-freq-min-max" property

[Jaehoon Chung]

'clock-freq-min-max' property had already deprecated.
Remove the 'clock-freq-min-max' property that is kept to maintain
the compatibility.

Signed-off-by: Jaehoon Chung 
---
 .../devicetree/bindings/mmc/synopsys-dw-mshc.txt  |  4 
 drivers/mmc/host/dw_mmc.c | 15 ---
 2 files changed, 4 insertions(+), 15 deletions(-)

diff --git a/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt 
b/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt
index ef3e5f14067a..75c9fdca4aaf 100644
--- a/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt
+++ b/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt
@@ -59,10 +59,6 @@ Optional properties:
   is specified and the ciu clock is specified then we'll try to set the ciu
   clock to this at probe time.
 
-* clock-freq-min-max (DEPRECATED): Minimum and Maximum clock frequency for 
card output
-  clock(cclk_out). If it's not specified, max is 200MHZ and min is 400KHz by 
default.
- (Use the "max-frequency" instead of "clock-freq-min-max".)
-
 * num-slots (DEPRECATED): specifies the number of slots supported by the 
controller.
   The number of physical slots actually used could be equal or less than the
   value specified by num-slots. If this property is not specified, the value
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index 0aa39975f33b..38e0e7c4ffd9 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -2784,7 +2784,6 @@ static int dw_mci_init_slot(struct dw_mci *host)
struct dw_mci_slot *slot;
const struct dw_mci_drv_data *drv_data = host->drv_data;
int ctrl_id, ret;
-   u32 freq[2];
 
mmc = mmc_alloc_host(sizeof(struct dw_mci_slot), host->dev);
if (!mmc)
@@ -2798,16 +2797,6 @@ static int dw_mci_init_slot(struct dw_mci *host)
host->slot = slot;
 
mmc->ops = &dw_mci_ops;
-   if (device_property_read_u32_array(host->dev, "clock-freq-min-max",
-  freq, 2)) {
-   mmc->f_min = DW_MCI_FREQ_MIN;
-   mmc->f_max = DW_MCI_FREQ_MAX;
-   } else {
-   dev_info(host->dev,
-   "'clock-freq-min-max' property was deprecated.\n");
-   mmc->f_min = freq[0];
-   mmc->f_max = freq[1];
-   }
 
/*if there are external regulators, get them*/
ret = mmc_regulator_get_supply(mmc);
@@ -2846,6 +2835,10 @@ static int dw_mci_init_slot(struct dw_mci *host)
if (ret)
goto err_host_allocated;
 
+   mmc->f_min = DW_MCI_FREQ_MIN;
+   if (!mmc->f_max)
+   mmc->f_max = DW_MCI_FREQ_MAX;
+
/* Process SDIO IRQs through the sdio_irq_work. */
if (mmc->caps & MMC_CAP_SDIO_IRQ)
mmc->caps2 |= MMC_CAP2_SDIO_IRQ_NOTHREAD;
-- 
2.15.1

[PATCH] perf annotate: Support to display the LBR data in tui mode

[Jin Yao]

Unlike the perf report interactive annotate mode, the perf annotate
doesn't display the LBR data.

perf record -b ...
perf annotate function

It should show IPC/cycle, but it doesn't.

This patch lets perf annotate support the displaying of LBR data.

For example,

perf annotate compute_flag

Percent│ IPC Cycle
   │
   │
   │Disassembly of section .text:
   │
   │00400640 :
   │compute_flag():
   │volatile int count;
   │static unsigned int s_randseed;
   │
   │__attribute__((noinline))
   │int compute_flag()
   │{
 22.96 │1.18   584sub$0x8,%rsp
   │int i;
   │
   │i = rand() % 2;
 23.02 │1.18 1  → callq  rand@plt
   │
   │return i;
 27.05 │3.37  mov%eax,%edx
   │}
   │3.37  add$0x8,%rsp
   │{
   │int i;
   │
   │i = rand() % 2;
   │
   │return i;
   │3.37  shr$0x1f,%edx
   │3.37  add%edx,%eax
   │3.37  and$0x1,%eax
   │3.37  sub%edx,%eax
   │}
 26.97 │3.37 2  ← retq

Note that, this patch only supports tui mode. For other mode like --stdio,
it just keeps original behavior.

perf annotate compute_flag --stdio

 Percent |  Source code & Disassembly of div for cycles:ppp (7993 samples)
--
 :
 :
 :
 :Disassembly of section .text:
 :
 :00400640 :
 :compute_flag():
 :volatile int count;
 :static unsigned int s_randseed;
 :
 :__attribute__((noinline))
 :int compute_flag()
 :{
0.29 :   400640:   sub$0x8,%rsp # +100.00%
 :int i;
 :
 :i = rand() % 2;
   42.93 :   400644:   callq  400490  # -100.00% (p:100.00%)
 :
 :return i;
0.10 :   400649:   mov%eax,%edx # +100.00%
 :}
0.94 :   40064b:   add$0x8,%rsp
 :{
 :int i;
 :
 :i = rand() % 2;
 :
 :return i;
   27.02 :   40064f:   shr$0x1f,%edx
0.15 :   400652:   add%edx,%eax
1.24 :   400654:   and$0x1,%eax
2.08 :   400657:   sub%edx,%eax
 :}
   25.26 :   400659:   retq # -100.00% (p:100.00%)

Signed-off-by: Jin Yao 
---
 tools/perf/builtin-annotate.c | 88 ---
 1 file changed, 82 insertions(+), 6 deletions(-)

diff --git a/tools/perf/builtin-annotate.c b/tools/perf/builtin-annotate.c
index f15731a..ead6ae4 100644
--- a/tools/perf/builtin-annotate.c
+++ b/tools/perf/builtin-annotate.c
@@ -44,6 +44,7 @@ struct perf_annotate {
bool   full_paths;
bool   print_line;
bool   skip_missing;
+   bool   has_br_stack;
const char *sym_hist_filter;
const char *cpu_list;
DECLARE_BITMAP(cpu_bitmap, MAX_NR_CPUS);
@@ -146,16 +147,73 @@ static void process_branch_stack(struct branch_stack *bs, 
struct addr_location *
free(bi);
 }
 
+static int hist_iter__branch_callback(struct hist_entry_iter *iter,
+ struct addr_location *al __maybe_unused,
+ bool single __maybe_unused,
+ void *arg __maybe_unused)
+{
+   struct hist_entry *he = iter->he;
+   struct branch_info *bi;
+   struct perf_sample *sample = iter->sample;
+   struct perf_evsel *evsel = iter->evsel;
+   int err;
+
+   hist__account_cycles(sample->branch_stack, al, sample, false);
+
+   bi = he->branch_info;
+   err = addr_map_symbol__inc_samples(&bi->from, sample, evsel->idx);
+
+   if (err)
+   goto out;
+
+   err = addr_map_symbol__inc_samples(&bi->to, sample, evsel->idx);
+
+out:
+   return err;
+}
+
+static int process_branch_callback(struct perf_evsel *evsel,
+  struct perf_sample *sample,
+  struct addr_location *al __maybe_unused,
+  struct perf_annotate *ann,
+  struct machine *machine)
+{
+   struct hist_entry_iter iter = {
+   .evsel  = evsel,
+   .sample = sample,
+   .add_

[PATCH 2/6] mmc: dw_mmc: remove the deprecated "num-slots"

[Jaehoon Chung]

'num-slots' property had already deprecated.
Remove the 'nom-slots' property that is kept to maintain the compatibility.

Signed-off-by: Jaehoon Chung 
---
 Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt | 5 -
 drivers/mmc/host/dw_mmc-pci.c  | 1 -
 drivers/mmc/host/dw_mmc.c  | 4 
 drivers/mmc/host/dw_mmc.h  | 3 ---
 4 files changed, 13 deletions(-)

diff --git a/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt 
b/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt
index 75c9fdca4aaf..7e5e427a22ce 100644
--- a/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt
+++ b/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt
@@ -59,11 +59,6 @@ Optional properties:
   is specified and the ciu clock is specified then we'll try to set the ciu
   clock to this at probe time.
 
-* num-slots (DEPRECATED): specifies the number of slots supported by the 
controller.
-  The number of physical slots actually used could be equal or less than the
-  value specified by num-slots. If this property is not specified, the value
-  of num-slot property is assumed to be 1.
-
 * fifo-depth: The maximum size of the tx/rx fifo's. If this property is not
   specified, the default value of the fifo size is determined from the
   controller registers.
diff --git a/drivers/mmc/host/dw_mmc-pci.c b/drivers/mmc/host/dw_mmc-pci.c
index ab8713297edb..3ad07d7b2c97 100644
--- a/drivers/mmc/host/dw_mmc-pci.c
+++ b/drivers/mmc/host/dw_mmc-pci.c
@@ -29,7 +29,6 @@
MMC_CAP_SDIO_IRQ)
 
 static struct dw_mci_board pci_board_data = {
-   .num_slots  = 1,
.caps   = DW_MCI_CAPABILITIES,
.bus_hz = 33 * 1000 * 1000,
.detect_delay_ms= 200,
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index 38e0e7c4ffd9..a63ca7bc1099 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -3124,10 +3124,6 @@ static struct dw_mci_board *dw_mci_parse_dt(struct 
dw_mci *host)
return ERR_PTR(-EPROBE_DEFER);
}
 
-   /* find out number of slots supported */
-   if (!device_property_read_u32(dev, "num-slots", &pdata->num_slots))
-   dev_info(dev, "'num-slots' was deprecated.\n");
-
if (device_property_read_u32(dev, "fifo-depth", &pdata->fifo_depth))
dev_info(dev,
 "fifo-depth property not found, using value of FIFOTH 
register as default\n");
diff --git a/drivers/mmc/host/dw_mmc.h b/drivers/mmc/host/dw_mmc.h
index e3124f06a47e..80ff9a6c6fdd 100644
--- a/drivers/mmc/host/dw_mmc.h
+++ b/drivers/mmc/host/dw_mmc.h
@@ -102,7 +102,6 @@ struct dw_mci_dma_slave {
  * @bus_hz: The rate of @mck in Hz. This forms the basis for MMC bus
  * rate and timeout calculations.
  * @current_speed: Configured rate of the controller.
- * @num_slots: Number of slots available.
  * @fifoth_val: The value of FIFOTH register.
  * @verid: Denote Version ID.
  * @dev: Device associated with the MMC controller.
@@ -253,8 +252,6 @@ struct dma_pdata;
 
 /* Board platform data */
 struct dw_mci_board {
-   u32 num_slots;
-
unsigned int bus_hz; /* Clock speed at the cclk_in pad */
 
u32 caps;   /* Capabilities */
-- 
2.15.1

Re: [PATCH 1/9] drm/xen-front: Introduce Xen para-virtualized frontend driver

[Oleksandr Andrushchenko]

On 02/23/2018 12:23 AM, Boris Ostrovsky wrote:

On 02/21/2018 03:03 AM, Oleksandr Andrushchenko wrote:

+static struct xenbus_driver xen_driver = {
+   .ids = xen_drv_ids,
+   .probe = xen_drv_probe,
+   .remove = xen_drv_remove,
+   .otherend_changed = backend_on_changed,

What does "_on_" stand for?

Well, it is somewhat like a hint that this is called "on" event,
e.g. event when the other end state has changed, backend in this
case. It could be something like "backend_on_state_changed"

-boris

Re: [PATCH v9 2/7] PCI/AER: factor out error reporting from AER

[poza]

On 2018-02-23 00:53, Randy Dunlap wrote:

On 02/21/2018 11:46 PM, Oza Pawandeep wrote:

Hi,
Just minor stuff:


diff --git a/drivers/pci/pcie/pcie-err.c b/drivers/pci/pcie/pcie-err.c
new file mode 100644
index 000..a532fe0
--- /dev/null
+++ b/drivers/pci/pcie/pcie-err.c
@@ -0,0 +1,334 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * This file implements the error recovery as a core part of PCIe 
error reporting.
+ * When a PCIe error is delivered, an error message will be collected 
and printed
+ * to console, then, an error recovery procedure will be executed by 
following

+ * the PCI error recovery rules.
+ *
+ * Copyright (C) 2006 Intel Corp.
+ * Tom Long Nguyen (tom.l.ngu...@intel.com)
+ * Zhang Yanmin (yanmin.zh...@intel.com)
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "portdrv.h"



+static int report_error_detected(struct pci_dev *dev, void *data)
+{
+   pci_ers_result_t vote;
+   const struct pci_error_handlers *err_handler;
+   struct aer_broadcast_data *result_data;
+
+   result_data = (struct aer_broadcast_data *) data;
+
+   device_lock(&dev->dev);
+   dev->error_state = result_data->state;
+
+   if (!dev->driver ||
+   !dev->driver->err_handler ||
+   !dev->driver->err_handler->error_detected) {
+   if (result_data->state == pci_channel_io_frozen &&
+   dev->hdr_type != PCI_HEADER_TYPE_BRIDGE) {
+   /*
+* In case of fatal recovery, if one of down-
+* stream device has no driver. We might be
+* unable to recover because a later insmod
+* of a driver for this device is unaware of
+* its hw state.
+*/
+   dev_printk(KERN_DEBUG, &dev->dev, "device has %s\n",
+  dev->driver ?
+  "no error-aware driver" : "no driver");


or:
dev_printk(KERN_DEBUG, &dev->dev, "device has no%s 
driver\n",
   dev->driver ? " error-aware" : "");



I might not be able to take care of this, because all the later patches
are dependent on this, and probably I might have to manually merge.
though I will give it a try :)


+   }
+
+   /*
+* If there's any device in the subtree that does not
+* have an error_detected callback, returning
+* PCI_ERS_RESULT_NO_AER_DRIVER prevents calling of
+* the subsequent mmio_enabled/slot_reset/resume
+* callbacks of "any" device in the subtree. All the
+* devices in the subtree are left in the error state
+* without recovery.
+*/
+
+   if (dev->hdr_type != PCI_HEADER_TYPE_BRIDGE)
+   vote = PCI_ERS_RESULT_NO_AER_DRIVER;
+   else
+   vote = PCI_ERS_RESULT_NONE;
+   } else {
+   err_handler = dev->driver->err_handler;
+   vote = err_handler->error_detected(dev, result_data->state);
+   }
+
+   result_data->result = merge_result(result_data->result, vote);
+   device_unlock(&dev->dev);
+   return 0;
+}



+/**
+ * broadcast_error_message - handle message broadcast to downstream 
drivers
+ * @dev: pointer to from where in a hierarchy message is broadcasted 
down


I would drop ^^ "from" ...   is broadcast 
downstream



+ * @state: error state
+ * @error_mesg: message to print
+ * @cb: callback to be broadcasted


to be broadcast


+ *
+ * Invoked during error recovery process. Once being invoked, the 
content
+ * of error severity will be broadcasted to all downstream drivers in 
a


will be broadcast


+ * hierarchy in question.
+ */
+static pci_ers_result_t broadcast_error_message(struct pci_dev *dev,
+   enum pci_channel_state state,
+   char *error_mesg,
+   int (*cb)(struct pci_dev *, void *))
+{
+   struct aer_broadcast_data result_data;

Re: [RFCv4 13/21] media: videobuf2-v4l2: support for requests

[Tomasz Figa]

On Wed, Feb 21, 2018 at 1:18 AM, Hans Verkuil  wrote:
> On 02/20/2018 05:44 AM, Alexandre Courbot wrote:
>> Add a new vb2_qbuf_request() (a request-aware version of vb2_qbuf())
>> that request-aware drivers can call to queue a buffer into a request
>> instead of directly into the vb2 queue if relevent.
>>
>> This function expects that drivers invoking it are using instances of
>> v4l2_request_entity and v4l2_request_entity_data to describe their
>> entity and entity data respectively.
>>
>> Also add the vb2_request_submit() helper function which drivers can
>> invoke in order to queue all the buffers previously queued into a
>> request into the regular vb2 queue.
>>
>> Signed-off-by: Alexandre Courbot 
>> ---
>>  .../media/common/videobuf2/videobuf2-v4l2.c   | 129 +-
>>  include/media/videobuf2-v4l2.h|  59 
>>  2 files changed, 187 insertions(+), 1 deletion(-)
>>
>
> 
>
>> @@ -776,10 +899,14 @@ EXPORT_SYMBOL_GPL(vb2_ioctl_querybuf);
>>  int vb2_ioctl_qbuf(struct file *file, void *priv, struct v4l2_buffer *p)
>>  {
>>   struct video_device *vdev = video_devdata(file);
>> + struct v4l2_fh *fh = NULL;
>> +
>> + if (test_bit(V4L2_FL_USES_V4L2_FH, &vdev->flags))
>> + fh = file->private_data;
>
> No need for this. All drivers using vb2 will also use v4l2_fh.
>
>>
>>   if (vb2_queue_is_busy(vdev, file))
>>   return -EBUSY;
>> - return vb2_qbuf(vdev->queue, p);
>> + return vb2_qbuf_request(vdev->queue, p, fh ? fh->entity : NULL);
>>  }
>>  EXPORT_SYMBOL_GPL(vb2_ioctl_qbuf);
>>
>> diff --git a/include/media/videobuf2-v4l2.h b/include/media/videobuf2-v4l2.h
>> index 3d5e2d739f05..d4dfa266a0da 100644
>> --- a/include/media/videobuf2-v4l2.h
>> +++ b/include/media/videobuf2-v4l2.h
>> @@ -23,6 +23,12 @@
>>  #error VB2_MAX_PLANES != VIDEO_MAX_PLANES
>>  #endif
>>
>> +struct media_entity;
>> +struct v4l2_fh;
>> +struct media_request;
>> +struct media_request_entity;
>> +struct v4l2_request_entity_data;
>> +
>>  /**
>>   * struct vb2_v4l2_buffer - video buffer information for v4l2.
>>   *
>> @@ -116,6 +122,59 @@ int vb2_prepare_buf(struct vb2_queue *q, struct 
>> v4l2_buffer *b);
>>   */
>>  int vb2_qbuf(struct vb2_queue *q, struct v4l2_buffer *b);
>>
>> +#if IS_ENABLED(CONFIG_MEDIA_REQUEST_API)
>> +
>> +/**
>> + * vb2_qbuf_request() - Queue a buffer, with request support
>> + * @q:   pointer to &struct vb2_queue with videobuf2 queue.
>> + * @b:   buffer structure passed from userspace to
>> + *   &v4l2_ioctl_ops->vidioc_qbuf handler in driver
>> + * @entity:  request entity to queue for if requests are used.
>> + *
>> + * Should be called from &v4l2_ioctl_ops->vidioc_qbuf handler of a driver.
>> + *
>> + * If requests are not in use, calling this is equivalent to calling 
>> vb2_qbuf().
>> + *
>> + * If the request_fd member of b is set, then the buffer represented by b is
>> + * queued in the request instead of the vb2 queue. The buffer will be passed
>> + * to the vb2 queue when the request is submitted.
>
> I would definitely also prepare the buffer at this time. That way you'll see 
> any
> errors relating to the prepare early on.

Would the prepare operation be completely independent of other state?
I can see a case when how the buffer is to be prepared may depend on
values of some controls. If so, it would be only possible at request
submission time. Alternatively, the application would have to be
mandated to include any controls that may affect buffer preparing in
the request and before the QBUF is called.

Best regards,
Tomasz

Re: [PATCH v9 2/7] PCI/AER: factor out error reporting from AER

[poza]

On 2018-02-23 00:53, Randy Dunlap wrote:

On 02/21/2018 11:46 PM, Oza Pawandeep wrote:

Hi,
Just minor stuff:


diff --git a/drivers/pci/pcie/pcie-err.c b/drivers/pci/pcie/pcie-err.c
new file mode 100644
index 000..a532fe0
--- /dev/null
+++ b/drivers/pci/pcie/pcie-err.c
@@ -0,0 +1,334 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * This file implements the error recovery as a core part of PCIe 
error reporting.
+ * When a PCIe error is delivered, an error message will be collected 
and printed
+ * to console, then, an error recovery procedure will be executed by 
following

+ * the PCI error recovery rules.
+ *
+ * Copyright (C) 2006 Intel Corp.
+ * Tom Long Nguyen (tom.l.ngu...@intel.com)
+ * Zhang Yanmin (yanmin.zh...@intel.com)
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "portdrv.h"



+static int report_error_detected(struct pci_dev *dev, void *data)
+{
+   pci_ers_result_t vote;
+   const struct pci_error_handlers *err_handler;
+   struct aer_broadcast_data *result_data;
+
+   result_data = (struct aer_broadcast_data *) data;
+
+   device_lock(&dev->dev);
+   dev->error_state = result_data->state;
+
+   if (!dev->driver ||
+   !dev->driver->err_handler ||
+   !dev->driver->err_handler->error_detected) {
+   if (result_data->state == pci_channel_io_frozen &&
+   dev->hdr_type != PCI_HEADER_TYPE_BRIDGE) {
+   /*
+* In case of fatal recovery, if one of down-
+* stream device has no driver. We might be
+* unable to recover because a later insmod
+* of a driver for this device is unaware of
+* its hw state.
+*/
+   dev_printk(KERN_DEBUG, &dev->dev, "device has %s\n",
+  dev->driver ?
+  "no error-aware driver" : "no driver");


or:
dev_printk(KERN_DEBUG, &dev->dev, "device has no%s 
driver\n",
   dev->driver ? " error-aware" : "");


+   }
+
+   /*
+* If there's any device in the subtree that does not
+* have an error_detected callback, returning
+* PCI_ERS_RESULT_NO_AER_DRIVER prevents calling of
+* the subsequent mmio_enabled/slot_reset/resume
+* callbacks of "any" device in the subtree. All the
+* devices in the subtree are left in the error state
+* without recovery.
+*/
+
+   if (dev->hdr_type != PCI_HEADER_TYPE_BRIDGE)
+   vote = PCI_ERS_RESULT_NO_AER_DRIVER;
+   else
+   vote = PCI_ERS_RESULT_NONE;
+   } else {
+   err_handler = dev->driver->err_handler;
+   vote = err_handler->error_detected(dev, result_data->state);
+   }
+
+   result_data->result = merge_result(result_data->result, vote);
+   device_unlock(&dev->dev);
+   return 0;
+}



+/**
+ * broadcast_error_message - handle message broadcast to downstream 
drivers
+ * @dev: pointer to from where in a hierarchy message is broadcasted 
down


I would drop ^^ "from" ...   is broadcast 
downstream



+ * @state: error state
+ * @error_mesg: message to print
+ * @cb: callback to be broadcasted


to be broadcast


+ *
+ * Invoked during error recovery process. Once being invoked, the 
content
+ * of error severity will be broadcasted to all downstream drivers in 
a


will be broadcast


+ * hierarchy in question.
+ */
+static pci_ers_result_t broadcast_error_message(struct pci_dev *dev,
+   enum pci_channel_state state,
+   char *error_mesg,
+   int (*cb)(struct pci_dev *, void *))
+{
+   struct aer_broadcast_data result_data;



Thanks for the comments, will take care of it.

Re: [PATCH] clk: tegra: fix pllu rate configuration

[Marcel Ziswiler]

On February 23, 2018 12:47:56 AM GMT+01:00, Stephen Warren 
 wrote:
>On 02/22/2018 04:04 PM, Marcel Ziswiler wrote:
>> Turns out latest upstream U-Boot does not configure/enable pllu which
>> leaves it at some default rate of 500 kHz:
>
>I assume this is only because U-Boot just happened not to access any
>USB 
>devices. In other words, if you break into the U-Boot boot flow and 
>explicitly initialize/access USB, then USB works both in U-Boot and in 
>the kernel even without this patch?

Exactly.

> If that's not the case, it seems 
>there's a bug in U-Boot.
>
>Either way, I have no issue with this patch. I just want to make sure 
>there weren't other bugs in U-Boot that needed fixing.

No, rest assured U-Boot is working just fine on the legacy Tegras. The only 
thing in need of fixing lately was NAND on Colibri T20 and Harmony.

[PATCH] drm/rockchip: vop: Init vskiplines in scl_vop_cal_scale()

[Jeffy Chen]

Currently we are calling scl_vop_cal_scale() to get vskiplines for yrgb
and cbcr. So the cbcr's vskiplines might be an unexpected value if the
second scl_vop_cal_scale() didn't update it.

Init vskiplines in scl_vop_cal_scale() to avoid that.

Signed-off-by: Jeffy Chen 
---

 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 7715853ef90a..9b03c51903ab 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -259,6 +259,9 @@ static uint16_t scl_vop_cal_scale(enum scale_mode mode, 
uint32_t src,
 {
uint16_t val = 1 << SCL_FT_DEFAULT_FIXPOINT_SHIFT;
 
+   if (vskiplines)
+   *vskiplines = 0;
+
if (is_horizontal) {
if (mode == SCALE_UP)
val = GET_SCL_FT_BIC(src, dst);
@@ -299,7 +302,7 @@ static void scl_vop_cal_scl_fac(struct vop *vop, const 
struct vop_win_data *win,
uint16_t vsu_mode;
uint16_t lb_mode;
uint32_t val;
-   int vskiplines = 0;
+   int vskiplines;
 
if (dst_w > 3840) {
DRM_DEV_ERROR(vop->dev, "Maximum dst width (3840) exceeded\n");
-- 
2.11.0

Re: [PATCH] lightnvm: fix memory leak in pblk_luns_init

[Matias Bjørling]

On 02/23/2018 12:03 AM, Huaicheng Li wrote:

Please ignore my previous email as I found the memory is free'ed at
pblk_init()'s error handling logic.
Sorry for the interruption.

On Thu, Feb 22, 2018 at 3:01 PM, Huaicheng Li 
wrote:


Signed-off-by: Huaicheng Li 
---
drivers/lightnvm/pblk-init.c | 1 +
1 file changed, 1 insertion(+)

diff --git a/drivers/lightnvm/pblk-init.c b/drivers/lightnvm/pblk-init.c
index 93d671ca518e..330665d91d8d 100644
--- a/drivers/lightnvm/pblk-init.c
+++ b/drivers/lightnvm/pblk-init.c
@@ -510,6 +510,7 @@ static int pblk_luns_init(struct pblk *pblk, struct
ppa_addr *luns)
 if (ret) {
 while (--i >= 0)
 kfree(pblk->luns[i].bb_list);
+   kfree(pblk->luns);
 return ret;
 }
 }
--
2.13.6






No worries. The initialization part is pretty complex due to all the 
data structures being set up. I would love to have a clean 
initialization function, which cleans up after it self. But being able 
to share the "fail" bringup and tear-down code is very helpful and makes 
other parts easier.

Re: [PATCH 1/2] pci: endpoint: Free func_name after last usage

[Kishon Vijay Abraham I]

Hi Lorenzo,

On Thursday 22 February 2018 11:49 PM, Lorenzo Pieralisi wrote:
> On Wed, Feb 21, 2018 at 01:47:06PM +0100, Rolf Evers-Fischer wrote:
>> From: Rolf Evers-Fischer 
>>
>> This commit decreases the number of jump labels and ensures
>> that the next commit doesn't increase the number of occurrences
>> of 'kfree(func_name)'.
>>
>> Change-Id: I0d1b6fd652395b85f82b11c43bf9b7db512854d1
>> Signed-off-by: Rolf Evers-Fischer 
>> Signed-off-by: Rolf Evers-Fischer 
>> ---
>>  drivers/pci/endpoint/pci-epf-core.c | 7 ++-
>>  1 file changed, 2 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/pci/endpoint/pci-epf-core.c 
>> b/drivers/pci/endpoint/pci-epf-core.c
>> index 766ce1dca2ec..23d0e128d1a5 100644
>> --- a/drivers/pci/endpoint/pci-epf-core.c
>> +++ b/drivers/pci/endpoint/pci-epf-core.c
>> @@ -220,9 +220,10 @@ struct pci_epf *pci_epf_create(const char *name)
>>  *buf = '\0';
>>  
>>  epf->name = kstrdup(func_name, GFP_KERNEL);
>> +kfree(func_name);
> 
> I am certainly missing something but what if we reworked the code
> and just:
> 
> kstrdup(name, GFP_KERNEL);
> 
> once instead of allocating another local copy (that we then have to
> free) ?

name will be something like pci_epf_test.0 and in epf->name we want to just
have pci_epf_test.
> 
> Reworded: why
> 
> epf->name = func_name;

memory should be allocated for epf->name before it can be initialized. IMO
without kstrdup, there will be a null pointer exception.

Thanks
Kishon

[PATCH -V6 -mm] mm, swap: Fix race between swapoff and some swap operations

[Huang, Ying]

From: Huang Ying 

When the swapin is performed, after getting the swap entry information
from the page table, system will swap in the swap entry, without any
lock held to prevent the swap device from being swapoff.  This may
cause the race like below,

CPU 1   CPU 2
-   -
do_swap_page
  swapin_readahead
__read_swap_cache_async
swapoff   swapcache_prepare
  p->swap_map = NULL__swap_duplicate
  p->swap_map[?] /* !!! NULL pointer 
access */

Because swapoff is usually done when system shutdown only, the race
may not hit many people in practice.  But it is still a race need to
be fixed.

To fix the race, get_swap_device() is added to check whether the
specified swap entry is valid in its swap device.  If so, it will keep
the swap entry valid via preventing the swap device from being
swapoff, until put_swap_device() is called.

Because swapoff() is very rare code path, to make the normal path runs
as fast as possible, disabling preemption + stop_machine() instead of
reference count is used to implement get/put_swap_device().  From
get_swap_device() to put_swap_device(), the preemption is disabled, so
stop_machine() in swapoff() will wait until put_swap_device() is
called.

In addition to swap_map, cluster_info, etc. data structure in the
struct swap_info_struct, the swap cache radix tree will be freed after
swapoff, so this patch fixes the race between swap cache looking up
and swapoff too.

Races between some other swap cache usages protected via disabling
preemption and swapoff are fixed too via calling stop_machine()
between clearing PageSwapCache() and freeing swap cache data
structure.

Alternative implementation could be replacing disable preemption with
rcu_read_lock_sched and stop_machine() with synchronize_sched().

Cc: Hugh Dickins 
Cc: Paul E. McKenney 
Cc: Minchan Kim 
Cc: Johannes Weiner 
Cc: Tim Chen 
Cc: Shaohua Li 
Cc: Mel Gorman 
Cc: "Jérôme Glisse" 
Cc: Michal Hocko 
Cc: Andrea Arcangeli 
Cc: David Rientjes 
Cc: Rik van Riel 
Cc: Jan Kara 
Cc: Dave Jiang 
Cc: Aaron Lu 
Signed-off-by: "Huang, Ying" 

Changelog:

v6:

- Add more comments to get_swap_device() to make it more clear about
  possible swapoff or swapoff+swapon.

v5:

- Replace RCU with stop_machine()

v4:

- Use synchronize_rcu() in enable_swap_info() to reduce overhead of
  normal paths further.

v3:

- Re-implemented with RCU to reduce the overhead of normal paths

v2:

- Re-implemented with SRCU to reduce the overhead of normal paths.

- Avoid to check whether the swap device has been swapoff in
  get_swap_device().  Because we can check the origin of the swap
  entry to make sure the swap device hasn't bee swapoff.
---
 include/linux/swap.h |  13 -
 mm/memory.c  |   2 +-
 mm/swap_state.c  |  16 +-
 mm/swapfile.c| 152 +--
 4 files changed, 146 insertions(+), 37 deletions(-)

diff --git a/include/linux/swap.h b/include/linux/swap.h
index a1a3f4ed94ce..b4462789b970 100644
--- a/include/linux/swap.h
+++ b/include/linux/swap.h
@@ -172,8 +172,9 @@ enum {
SWP_PAGE_DISCARD = (1 << 9),/* freed swap page-cluster discards */
SWP_STABLE_WRITES = (1 << 10),  /* no overwrite PG_writeback pages */
SWP_SYNCHRONOUS_IO = (1 << 11), /* synchronous IO is efficient */
+   SWP_VALID   = (1 << 12),/* swap is valid to be operated on? */
/* add others here before... */
-   SWP_SCANNING= (1 << 12),/* refcount in scan_swap_map */
+   SWP_SCANNING= (1 << 13),/* refcount in scan_swap_map */
 };
 
 #define SWAP_CLUSTER_MAX 32UL
@@ -470,7 +471,7 @@ extern unsigned int count_swap_pages(int, int);
 extern sector_t map_swap_page(struct page *, struct block_device **);
 extern sector_t swapdev_block(int, pgoff_t);
 extern int page_swapcount(struct page *);
-extern int __swap_count(struct swap_info_struct *si, swp_entry_t entry);
+extern int __swap_count(swp_entry_t entry);
 extern int __swp_swapcount(swp_entry_t entry);
 extern int swp_swapcount(swp_entry_t entry);
 extern struct swap_info_struct *page_swap_info(struct page *);
@@ -480,6 +481,12 @@ extern int try_to_free_swap(struct page *);
 struct backing_dev_info;
 extern int init_swap_address_space(unsigned int type, unsigned long nr_pages);
 extern void exit_swap_address_space(unsigned int type);
+extern struct swap_info_struct *get_swap_device(swp_entry_t entry);
+
+static inline void put_swap_device(struct swap_info_struct *si)
+{
+   preempt_enable();
+}
 
 #else /* CONFIG_SWAP */
 
@@ -597,7 +604,7 @@ static inline int page_swapcount(struct page *page)
return 0;
 }
 
-static inline int __swap_count(struct swap_info_struct *si, swp_entry_t entry)
+static inline int __swap_count

Re: [PATCH v2 4/6] fs/dcache: Avoid the try_lock loops in dentry_kill()

[Al Viro]

On Fri, Feb 23, 2018 at 03:12:14AM +, Al Viro wrote:

> failed:
>   spin_unlock(&dentry->d_lock);
>   spin_lock(&inode->i_lock);
>   spin_lock(&dentry->d_lock);
>   parent = lock_parent(dentry);

Hmm...  Negative dentry case obviously is trickier - not to mention oopsen,
it might have become positive under us.  Bugger...  OTOH, it's not much
trickier - with negative dentry we can only fail on trying to lock the
parent, in which case we should just check that it's still negative before
killing it off.  If it has gone positive on us, we'll just unlock the
parent and we are back to the normal "positive dentry, only ->d_lock held"
case.  At most one retry there - once it's positive, it stays positive.
So,

static struct dentry *dentry_kill(struct dentry *dentry)
__releases(dentry->d_lock)
{
struct inode *inode = dentry->d_inode;
struct dentry *parent = NULL;

if (inode && unlikely(!spin_trylock(&inode->i_lock)))
goto no_locks;

if (!IS_ROOT(dentry)) {
parent = dentry->d_parent;
if (unlikely(!spin_trylock(&parent->d_lock))) {
if (inode) {
spin_unlock(&inode->i_lock);
goto no_locks;
}
goto need_parent;
}
}
kill_it:
__dentry_kill(dentry);
return parent;

no_locks:   /* positive, only ->d_lock held */
spin_unlock(&dentry->d_lock);
spin_lock(&inode->i_lock);
spin_lock(&dentry->d_lock);
need_parent:
parent = lock_parent(dentry);
if (unlikely(dentry->d_lockref.count != 1 || retain_dentry(dentry))) {
/* we are keeping it, after all */
if (inode)
spin_unlock(&inode->i_lock);
spin_unlock(&dentry->d_lock);
if (parent)
spin_unlock(&parent->d_lock);
return NULL;
}
/* it should die */
if (inode)  /* was positive, ->d_inode unchanged, locks held */
goto kill_it;
inode = dentry->d_inode;// READ_ONCE?
if (!inode) /* still negative, locks held */
goto kill_it;
/* negative became positive; it can't become negative again */
if (parent)
spin_unlock(&parent->d_lock);
goto no_locks;  /* once */
}

Re: [PATCH V2 7/7] cpuidle/drivers/cpuidle-arm: Register the cooling device

[Viresh Kumar]

On Wed, Feb 21, 2018 at 8:59 PM, Daniel Lezcano
 wrote:
> Register the ARM generic cpuidle driver as a cooling device.
>
> Signed-off-by: Daniel Lezcano 
> ---
>  drivers/cpuidle/cpuidle-arm.c | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/drivers/cpuidle/cpuidle-arm.c b/drivers/cpuidle/cpuidle-arm.c
> index ddee1b6..c100915 100644
> --- a/drivers/cpuidle/cpuidle-arm.c
> +++ b/drivers/cpuidle/cpuidle-arm.c
> @@ -11,6 +11,7 @@
>
>  #define pr_fmt(fmt) "CPUidle arm: " fmt
>
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -172,6 +173,10 @@ static int __init arm_idle_init(void)
> goto out_fail;
> }
>
> +   ret = cpuidle_cooling_register();
> +   if (ret)
> +   pr_warn("Failed to register the cpuidle cooling device\n");
> +

Because you aren't going to use the return value here, it might be better
to change return type of cpuidle_cooling_register() as "void" and do
error printing from within that routine.

Re: [PATCH v10 4/7] PCI/DPC: Unify and plumb error handling into DPC

[poza]

On 2018-02-23 00:09, Christoph Hellwig wrote:

On Thu, Feb 22, 2018 at 09:32:09PM +0530, Oza Pawandeep wrote:
Current DPC driver does not do recovery, e.g. calling end-point's 
driver's

callbacks, which sanitize the sw.

DPC driver implements link_reset callback, and calls pci_do_recovery.

Signed-off-by: Oza Pawandeep 

diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
index a5a79f0..124f42e 100644
--- a/drivers/pci/pci.h
+++ b/drivers/pci/pci.h
@@ -343,6 +343,8 @@ static inline resource_size_t 
pci_resource_alignment(struct pci_dev *dev,

 void pci_enable_acs(struct pci_dev *dev);

 /* PCI error reporting and recovery */
+#define DPC_FATAL  4
+
 void pci_do_recovery(struct pci_dev *dev, int severity);

 #ifdef CONFIG_PCIEASPM
diff --git a/drivers/pci/pcie/pcie-dpc.c b/drivers/pci/pcie/pcie-dpc.c
index 38e40c6..208b427 100644
--- a/drivers/pci/pcie/pcie-dpc.c
+++ b/drivers/pci/pcie/pcie-dpc.c
@@ -13,6 +13,7 @@
 #include 
 #include "../pci.h"
 #include "aer/aerdrv.h"
+#include "portdrv.h"

 struct dpc_dev {
struct pcie_device  *dev;
@@ -45,6 +46,60 @@ struct dpc_dev {
"Memory Request Completion Timeout",   /* Bit Position 18 */
 };

+static int find_dpc_dev_iter(struct device *device, void *data)
+{
+   struct pcie_port_service_driver *service_driver;
+   struct device **dev;
+
+   dev = (struct device **) data;
+
+   if (device->bus == &pcie_port_bus_type && device->driver) {
+   service_driver = to_service_driver(device->driver);


Please move the initial assignment to the declaration line to
clean this up a bit:

struct device **dev = (struct device **)data;

Same thing happens a couple more times in this patch.


+EXPORT_SYMBOL(pci_find_dpc_service);


EXPORT_SYMBOL_GPL for PCI layer internals again - and ditto for
probably about everything in this series.


will take care of all these comments.




 #if IS_ENABLED(CONFIG_PCIEAER)
-   /* Use the aer driver of the component firstly */
-   driver = pci_find_aer_service(udev);
+   if ((severity == AER_FATAL) ||
+   (severity == AER_NONFATAL) ||
+   (severity == AER_CORRECTABLE))
+   driver = pci_find_aer_service(udev);
 #endif


No need for the inner braces here.


-   if (severity == AER_FATAL)
+   if ((severity == AER_FATAL) ||
+   (severity == DPC_FATAL))
state = pci_channel_io_frozen;
else
state = pci_channel_io_normal;


Same here and a few more times below.


will take care
Thanks,
Oza.

Re: [PATCH v10 3/7] PCI/ERR: add mutex to synchronize recovery

[poza]

On 2018-02-23 00:06, Christoph Hellwig wrote:

On Thu, Feb 22, 2018 at 09:32:08PM +0530, Oza Pawandeep wrote:

This patch protects pci_do_recovery with mutex.


Do we really want a global mutex for this and not one per root complex
at very least?


This protects pcie_do_recovery, which is called by port service drivers.
mainly aer and dpc as of now. so the association is not root complex 
agents

instead service drivers who attempts to do link recovery.

so I think we are good here.

Re: [PATCH V2 0/7] CPU cooling device new strategies

[Viresh Kumar]

On Wed, Feb 21, 2018 at 8:59 PM, Daniel Lezcano
 wrote:
> Changelog:
>   V2:
>  - Dropped the cpu combo cooling device
>  - Added the acked-by tags
>  - Replaced task array by a percpu structure
>  - Fixed the copyright dates
>  - Fixed the extra lines
>  - Fixed the compilation macros to be reused
>  - Fixed the list node removal
>  - Massaged a couple of function names

There are few patches in this series, including the cover-letter,
where your script
forgot to cc me and probably other cpu-cooling maintainers.

Maybe just explicitly cc us all next time :)

--
viresh

Re: [PATCH v10 1/7] PCI/AER: Rename error recovery to generic pci naming

[poza]

On 2018-02-23 00:04, Christoph Hellwig wrote:

On Thu, Feb 22, 2018 at 09:32:06PM +0530, Oza Pawandeep wrote:

This patch renames error recovery to generic name with pci prefix

Signed-off-by: Oza Pawandeep 

diff --git a/drivers/pci/pcie/aer/aerdrv_core.c 
b/drivers/pci/pcie/aer/aerdrv_core.c

index a4bfea5..306bf2f 100644
--- a/drivers/pci/pcie/aer/aerdrv_core.c
+++ b/drivers/pci/pcie/aer/aerdrv_core.c
@@ -478,7 +478,7 @@ static pci_ers_result_t reset_link(struct pci_dev 
*dev)

 }

 /**
- * do_recovery - handle nonfatal/fatal error recovery process
+ * pci_do_recovery - handle nonfatal/fatal error recovery process
  * @dev: pointer to a pci_dev data structure of agent detecting an 
error

  * @severity: error severity type
  *
@@ -486,7 +486,7 @@ static pci_ers_result_t reset_link(struct pci_dev 
*dev)
  * error detected message to all downstream drivers within a 
hierarchy in

  * question and return the returned code.
  */
-static void do_recovery(struct pci_dev *dev, int severity)
+static void pci_do_recovery(struct pci_dev *dev, int severity)


Maybe pcie_do_recovery?



sure will take care.
Thanks.


Otherwise looks fine:

Reviewed-by: Christoph Hellwig 

Re: [PATCH V2 4/7] thermal/drivers/Kconfig: Convert the CPU cooling device to a choice

[Viresh Kumar]

On 21-02-18, 16:29, Daniel Lezcano wrote:
> The next changes will add new way to cool down a CPU. In order to
> sanitize and make the overall cpu cooling code consistent and robust
> we must prevent the cpu cooling devices to co-exists with the same
> purpose at the same time in the kernel.
> 
> Make the CPU cooling device a choice in the Kconfig, so only one CPU
> cooling strategy can be chosen.

Daniel T. already raised his concern (which I share too) about the
multi-platform builds, where we would want this to be runtime
selectable. I am fine with your approach of making that possible later
on, but I would really like that to be merged before the combo thing
comes in. So, I would suggest to merge stuff in this order:

- this series
- runtime selectable strategy
- combo stuff

I hope that would be fine ?

> Signed-off-by: Daniel Lezcano 
> ---
>  drivers/thermal/Kconfig   | 20 +---
>  drivers/thermal/cpu_cooling.c |  2 ++
>  include/linux/cpu_cooling.h   |  6 +++---
>  3 files changed, 22 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
> index b6adc54..5aaae1b 100644
> --- a/drivers/thermal/Kconfig
> +++ b/drivers/thermal/Kconfig
> @@ -142,17 +142,31 @@ config THERMAL_GOV_POWER_ALLOCATOR
> allocating and limiting power to devices.
>  
>  config CPU_THERMAL
> - bool "generic cpu cooling support"
> - depends on CPU_FREQ
> + bool "Generic cpu cooling support"
>   depends on THERMAL_OF
>   help
> +   Enable the CPU cooling features. If the system has no active
> +   cooling device available, this option allows to use the CPU
> +   as a cooling device.
> +
> +choice
> + prompt "CPU cooling strategies"
> + depends on CPU_THERMAL
> + default CPU_FREQ_THERMAL
> + help
> +   Select the CPU cooling strategy.
> +
> +config CPU_FREQ_THERMAL
> +bool "CPU frequency cooling strategy"
> + depends on CPU_FREQ
> + help
> This implements the generic cpu cooling mechanism through frequency
> reduction. An ACPI version of this already exists
> (drivers/acpi/processor_thermal.c).
> This will be useful for platforms using the generic thermal interface
> and not the ACPI interface.
>  
> -   If you want this support, you should say Y here.

Should this line be moved to the CPU_THERMAL section above ?

> +endchoice
>  
>  config CLOCK_THERMAL
>   bool "Generic clock cooling support"
> diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c
> index 7bdc19f..5c219dc 100644
> --- a/drivers/thermal/cpu_cooling.c
> +++ b/drivers/thermal/cpu_cooling.c
> @@ -22,6 +22,7 @@
>  
>  #include 
>  
> +#ifdef CONFIG_CPU_FREQ_THERMAL
>  /*
>   * Cooling state <-> CPUFreq frequency
>   *
> @@ -926,3 +927,4 @@ void cpufreq_cooling_unregister(struct 
> thermal_cooling_device *cdev)
>   kfree(cpufreq_cdev);
>  }
>  EXPORT_SYMBOL_GPL(cpufreq_cooling_unregister);
> +#endif /* CONFIG_CPU_FREQ_THERMAL */
> diff --git a/include/linux/cpu_cooling.h b/include/linux/cpu_cooling.h
> index d4292eb..c0accc7 100644
> --- a/include/linux/cpu_cooling.h
> +++ b/include/linux/cpu_cooling.h
> @@ -33,7 +33,7 @@ struct cpufreq_policy;
>  typedef int (*get_static_t)(cpumask_t *cpumask, int interval,
>   unsigned long voltage, u32 *power);
>  
> -#ifdef CONFIG_CPU_THERMAL
> +#ifdef CONFIG_CPU_FREQ_THERMAL
>  /**
>   * cpufreq_cooling_register - function to create cpufreq cooling device.
>   * @policy: cpufreq policy.
> @@ -84,7 +84,7 @@ of_cpufreq_power_cooling_register(struct device_node *np,
>   */
>  void cpufreq_cooling_unregister(struct thermal_cooling_device *cdev);
>  
> -#else /* !CONFIG_CPU_THERMAL */
> +#else /* !CONFIG_CPU_FREQ_THERMAL */
>  static inline struct thermal_cooling_device *
>  cpufreq_cooling_register(struct cpufreq_policy *policy)
>  {
> @@ -118,6 +118,6 @@ void cpufreq_cooling_unregister(struct 
> thermal_cooling_device *cdev)
>  {
>   return;
>  }
> -#endif   /* CONFIG_CPU_THERMAL */
> +#endif   /* CONFIG_CPU_FREQ_THERMAL */
>  
>  #endif /* __CPU_COOLING_H__ */

drivers/cpufreq/Kconfig:# if CPU_THERMAL is on and THERMAL=m, 
CPUFREQ_DT cannot be =y:
drivers/cpufreq/Kconfig:depends on !CPU_THERMAL || THERMAL
drivers/cpufreq/Kconfig:depends on !CPU_THERMAL || THERMAL
drivers/cpufreq/Kconfig.arm:# if CPU_THERMAL is on and THERMAL=m, 
ARM_BIT_LITTLE_CPUFREQ cannot be =y
drivers/cpufreq/Kconfig.arm:depends on !CPU_THERMAL || THERMAL
drivers/cpufreq/Kconfig.arm:depends on !CPU_THERMAL || THERMAL

All of these need to use CPU_FREQ_THERMAL now.

include/trace/events/thermal.h:#ifdef CONFIG_CPU_THERMAL
include/trace/events/thermal.h:#endif /* CONFIG_CPU_THERMAL */

And this too.

-- 
viresh

Re: [PATCH v9 7/7] PCI/DPC: Enumerate the devices after DPC trigger event

[poza]

On 2018-02-23 00:53, Randy Dunlap wrote:

On 02/21/2018 11:46 PM, Oza Pawandeep wrote:

Implement error_resume callback in DPC so, after DPC trigger event
enumerates the devices beneath.

Signed-off-by: Oza Pawandeep 

diff --git a/drivers/pci/pcie/pcie-dpc.c b/drivers/pci/pcie/pcie-dpc.c
index fce4518..59c01c7 100644
--- a/drivers/pci/pcie/pcie-dpc.c
+++ b/drivers/pci/pcie/pcie-dpc.c
@@ -129,6 +129,23 @@ static void dpc_wait_link_inactive(struct dpc_dev 
*dpc)

 }

 /**
+ * dpc_error_resume - enumerate the devices beneath
+ * @dev: pointer to Root Port's pci_dev data structure


* @pdev: ...


+ *
+ * Invoked by Port Bus driver during nonfatal recovery.
+ */
+static void dpc_error_resume(struct pci_dev *pdev)
+{
+   bool active = true;
+
+   if (pci_wait_for_link(pdev, active)) {
+   pci_lock_rescan_remove();
+   pci_rescan_bus(pdev->bus);
+   pci_unlock_rescan_remove();
+   }
+}
+
+/**
  * dpc_reset_link - reset link DPC  routine
  * @dev: pointer to Root Port's pci_dev data structure
  *
diff --git a/drivers/pci/pcie/pcie-err.c b/drivers/pci/pcie/pcie-err.c
index 6844347..4950f49 100644
--- a/drivers/pci/pcie/pcie-err.c
+++ b/drivers/pci/pcie/pcie-err.c
@@ -256,6 +258,15 @@ static pci_ers_result_t 
broadcast_error_message(struct pci_dev *dev,

result_data.result = PCI_ERS_RESULT_RECOVERED;

if (dev->hdr_type == PCI_HEADER_TYPE_BRIDGE) {
+   /* If DPC is triggered, call resume error hanlder


  handler

Kernel multi-line comment style is:
/*
 * Begin comment here.
 * foo bar blah
 */


+* because, at this point we can safely assume that
+* link recovery has happened.
+*/
+   if ((severity == DPC_FATAL) &&
+   (cb == report_resume)) {
+   cb(dev, NULL);
+   return PCI_ERS_RESULT_RECOVERED;
+   }
/*
 * If the error is reported by a bridge, we think this error
 * is related to the downstream link of the bridge, so we


thanks,


Thanks for the comments,
All your comments are taken care in v10, though I will post v11.

Re: [PATCH v9 4/7] PCI/DPC: Unify and plumb error handling into DPC

[poza]

On 2018-02-23 00:53, Randy Dunlap wrote:

On 02/21/2018 11:46 PM, Oza Pawandeep wrote:
Current DPC driver does not do recovery, e.g. calling end-point's 
driver's

callbacks, which sanitize the sw.

DPC driver implements link_reset callback, and calls pci_do_recovery.


Hi,
What does DPC mean?



DPC (Downstream port containment) is PCIe RP or Switch feature, which if 
detects FATAL error messages
halts the outgoing traffic, and PCIe link reset and quiescence 
activities are taken care by HW, and recovery is made.

followed by that; normal operation can be resumed.


Signed-off-by: Oza Pawandeep 




diff --git a/drivers/pci/pcie/pcie-dpc.c b/drivers/pci/pcie/pcie-dpc.c
index 38e40c6..208b427 100644
--- a/drivers/pci/pcie/pcie-dpc.c
+++ b/drivers/pci/pcie/pcie-dpc.c


@@ -82,12 +137,25 @@ static void dpc_wait_link_inactive(struct dpc_dev 
*dpc)

dev_warn(dev, "Link state not disabled for DPC event\n");
 }

+/**
+ * dpc_reset_link - reset link DPC  routine

 + * @dev: pointer to Root Port's pci_dev data structure

   * @pdev: ...


+ *
+ * Invoked by Port Bus driver when performing link reset at Root 
Port.

+ */
+static pci_ers_result_t dpc_reset_link(struct pci_dev *pdev)
 {


You can use 'make W=1 ...' to find kernel-doc warnings like this.



sure thanks for this tip.

ps: I am going to post v11 to address some comments.

thanks,

Re: [PATCH 1/9] scsi: ufs: Allowing power mode change

[Kyuho Choi]

Hi Asutosh,

I've simple question in below.

On 2/21/18, Asutosh Das  wrote:
> From: Yaniv Gardi 
>
> Due to M-PHY issues, moving from HS to any other mode or gear or
> even Hibern8 causes some un-predicted behavior of the device.
> This patch fixes this issues.
>
> Signed-off-by: Yaniv Gardi 
> Signed-off-by: Subhash Jadavani 
> Signed-off-by: Can Guo 
> Signed-off-by: Asutosh Das 
> ---
>  drivers/scsi/ufs/ufshcd.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
> index 011c336..d74d529 100644
> --- a/drivers/scsi/ufs/ufshcd.c
> +++ b/drivers/scsi/ufs/ufshcd.c
> @@ -4167,9 +4167,13 @@ static int ufshcd_link_startup(struct ufs_hba *hba)
>   goto out;
>   } while (ret && retries--);
>
> - if (ret)
> + if (ret) {
>   /* failed to get the link up... retire */
>   goto out;
> + } else {
> + ufshcd_dme_set(hba, UIC_ARG_MIB(TX_LCC_ENABLE), 0);
> + ufshcd_dme_set(hba, UIC_ARG_MIB(TX_LCC_ENABLE), 1);
> + }
>

Every ufs host has same issue and affected?.

>   if (link_startup_again) {
>   link_startup_again = false;
> --
> Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center,
> Inc.
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
> Foundation Collaborative Project.
>
>

Long standing kernel warning: perfevents: irq loop stuck!

[Cong Wang]

Hello,

We keep seeing the following kernel warning from 3.10 kernel to 4.9
kernel, it exists for a rather long time.

Google search shows there was a patch from Ingo:
https://patchwork.kernel.org/patch/6308681/

but it doesn't look like ever merged into mainline...

I don't know how it is triggered. Please let me know if any other
information I can provide.

BTW, the 4.9.78 kernel we use is based on the upstream 4.9 release,
plus some fs and networking patches backported, everything is from
upstream.


Thanks!

--->

[12032.813743] perf: interrupt took too long (7710 > 7696), lowering
kernel.perf_event_max_sample_rate to 25000
[14751.091121] perfevents: irq loop stuck!
[14751.095169] INFO: NMI handler (perf_event_nmi_handler) took too
long to run: 4.099 msecs
[14751.103265] perf: interrupt took too long (40100 > 9637), lowering
kernel.perf_event_max_sample_rate to 4000
[14751.113092] [ cut here ]
[14751.117719] WARNING: CPU: 34 PID: 85204 at
arch/x86/events/intel/core.c:2093 intel_pmu_handle_irq+0x35d/0x4c0
[14751.127629] Modules linked in:^Ac sch_htb^Ac cls_basic^Ac
act_mirred^Ac cls_u32^Ac veth^Ac fuse^Ac sch_ingress^Ac iTCO_wdt^Ac
intel_rapl^Ac sb_edac^Ac edac_core^Ac iTCO_vendor_
support^Ac x86_pkg_temp_thermal^Ac coretemp^Ac crct10dif_pclmul^Ac
crc32_pclmul^Ac ghash_clmulni_intel^Ac i2c_i801^Ac i2c_smbus^Ac
ioatdma^Ac i2c_core^Ac lpc_ich^Ac shpchp^Ac tcp_
diag^Ac hed^Ac inet_diag^Ac wmi^Ac acpi_pad^Ac ipmi_si^Ac
ipmi_devintf^Ac ipmi_msghandler^Ac acpi_cpufreq^Ac sch_fq_codel^Ac
xfs^Ac libcrc32c^Ac ixgbe^Ac mdio^Ac ptp^Ac crc32c_int
el^Ac pps_core^Ac dca^Ac
[14751.172819] CPU: 34 PID: 85204 Comm: kworker/34:2 Not tainted
4.9.78.x86_64 #1
[14751.181341] Hardware name: SYNNEX F3HY-MX/X10DRD-LTP-B-TW008, BIOS
2.0 10/14/2016
[14751.188829]  99577fa88b48^Ac 8138d5e7^Ac
99577fa88b98^Ac ^Ac
[14751.196922]  99577fa88b88^Ac 8108a7fb^Ac
082d^Ac 0064^Ac
[14751.205015]  0002^Ac 99577fa8d440^Ac
993902a16000^Ac 0040^Ac
[14751.213102] Call Trace:
[14751.215564][] dump_stack+0x4d/0x66
[14751.221321]  [] __warn+0xcb/0xf0
[14751.226124]  [] warn_slowpath_fmt+0x5f/0x80
[14751.231880]  [] intel_pmu_handle_irq+0x35d/0x4c0
[14751.238062]  [] perf_event_nmi_handler+0x2c/0x50
[14751.244248]  [] nmi_handle+0x6a/0x120
[14751.249484]  [] default_do_nmi+0x53/0xf0
[14751.254992]  [] do_nmi+0xe0/0x120
[14751.259884]  [] end_repeat_nmi+0x87/0x8f
[14751.265377]  [] ? intel_pmu_enable_event+0x1d1/0x230
[14751.271913]  [] ? intel_pmu_enable_event+0x1d1/0x230
[14751.278446]  [] ? intel_pmu_enable_event+0x1d1/0x230
[14751.284981][] x86_pmu_start+0x7e/0x100
[14751.291082]  [] x86_pmu_enable+0x272/0x2e0
[14751.296754]  [] perf_pmu_enable.part.92+0x7/0x10
[14751.302946]  [] perf_cgroup_switch+0x17b/0x1b0
[14751.308963]  [] __perf_event_task_sched_in+0x66/0x1a0
[14751.315582]  [] ? __perf_event_task_sched_out+0xb1/0x430
[14751.322463]  [] finish_task_switch+0x10a/0x1b0
[14751.328476]  [] __schedule+0x20d/0x690
[14751.333797]  [] schedule+0x36/0x80
[14751.338763]  [] worker_thread+0xbe/0x480
[14751.344251]  [] ? process_one_work+0x410/0x410
[14751.350265]  [] kthread+0xe6/0x100
[14751.355238]  [] ? do_exit+0x698/0xaa0
[14751.360475]  [] ? kthread_park+0x60/0x60
[14751.365966]  [] ret_from_fork+0x54/0x60
[14751.371376] ---[ end trace fd59d29a318e02d5 ]---

[14751.377511] CPU#34: ctrl:   
[14751.382141] CPU#34: status: 
[14751.386770] CPU#34: overflow:   
[14751.391395] CPU#34: fixed:  00b0
[14751.396022] CPU#34: pebs:   
[14751.400648] CPU#34: debugctl:   
[14751.405281] CPU#34: active: 0002
[14751.409912] CPU#34:   gen-PMC0 ctrl:  001301b7
[14751.415064] CPU#34:   gen-PMC0 count: 0025fa88
[14751.420214] CPU#34:   gen-PMC0 left:  ffda057b
[14751.425358] CPU#34:   gen-PMC1 ctrl:  001301bb
[14751.430497] CPU#34:   gen-PMC1 count: 005ad046
[14751.435643] CPU#34:   gen-PMC1 left:  ffa52fc1
[14751.440786] CPU#34:   gen-PMC2 ctrl:  00130151
[14751.445937] CPU#34:   gen-PMC2 count: 069ffd2d
[14751.451091] CPU#34:   gen-PMC2 left:  f9600409
[14751.456240] CPU#34:   gen-PMC3 ctrl:  0013003c
[14751.461383] CPU#34:   gen-PMC3 count: 05abd0c9
[14751.466524] CPU#34:   gen-PMC3 left:  fa54a75b
[14751.471670] CPU#34: fixed-PMC0 count: d26bbae7
[14751.476814] CPU#34: fixed-PMC1 count: 
[14751.481958] CPU#34: fixed-PMC2 count: 
[14751.487100] core: clearing PMU state on CPU#34

[PATCH 2/2] kbuild: simplify ld-option implementation

[Masahiro Yamada]

Currently, linker options are tested by the coordination of $(CC) and
$(LD) because LD needs some object to link.

As commit 86a9df597cdd ("kbuild: fix linker feature test macros when
cross compiling with Clang") addressed, we need to make sure $(CC)
and $(LD) agree the underlying architecture of the passed object.

This could be a bit complex when we combine tools from different groups.
For example, we can use clang for $(CC), but we still need to rely on
GCC toolchain for $(LD).

So, I was searching a way for standalone testing of linker options.
A trick I found is to use '-v'.  This prints the version string, but
also tests if the given option is recognized.

If a given option is supported,

  $ aarch64-linux-gnu-ld -v --fix-cortex-a53-843419
  GNU ld (Linaro_Binutils-2017.11) 2.28.2.20170706
  $ echo $?
  0

If unsupported,

  $ aarch64-linux-gnu-ld -v --fix-cortex-a53-843419
  GNU ld (crosstool-NG linaro-1.13.1-4.7-2013.04-20130415 - Linaro GCC 2013.04) 
2.23.1
  aarch64-linux-gnu-ld: unrecognized option '--fix-cortex-a53-843419'
  aarch64-linux-gnu-ld: use the --help option for usage information
  $ echo $?
  1

Gold works likewise.

  $ aarch64-linux-gnu-ld.gold -v --fix-cortex-a53-843419
  GNU gold (Linaro_Binutils-2017.11 2.28.2.20170706) 1.14
  masahiro@pug:~/ref/linux$ echo $?
  0
  $ aarch64-linux-gnu-ld.gold -v --fix-cortex-a53-99
  GNU gold (Linaro_Binutils-2017.11 2.28.2.20170706) 1.14
  aarch64-linux-gnu-ld.gold: --fix-cortex-a53-99: unknown option
  aarch64-linux-gnu-ld.gold: use the --help option for usage information
  $ echo $?
  1

LLD too.

  $ ld.lld -v --gc-sections
  LLD 7.0.0 (http://llvm.org/git/lld.git 
4a0e4190e74cea19f8a8dc625ccaebdf8b5d1585) (compatible with GNU linkers)
  $ echo $?
  0
  $ ld.lld -v --fix-cortex-a53-843419
  LLD 7.0.0 (http://llvm.org/git/lld.git 
4a0e4190e74cea19f8a8dc625ccaebdf8b5d1585) (compatible with GNU linkers)
  $ echo $?
  0
  $ ld.lld -v --fix-cortex-a53-99
  ld.lld: error: unknown argument: --fix-cortex-a53-99
  LLD 7.0.0 (http://llvm.org/git/lld.git 
4a0e4190e74cea19f8a8dc625ccaebdf8b5d1585) (compatible with GNU linkers)
  $ echo $?
  1

Signed-off-by: Masahiro Yamada 
---

 scripts/Kbuild.include | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/scripts/Kbuild.include b/scripts/Kbuild.include
index 34cbd81..f9c2f07 100644
--- a/scripts/Kbuild.include
+++ b/scripts/Kbuild.include
@@ -237,9 +237,7 @@ cc-ldoption = $(call try-run-cached,\
 
 # ld-option
 # Usage: LDFLAGS += $(call ld-option, -X)
-ld-option = $(call try-run-cached,\
-   $(CC) $(KBUILD_CPPFLAGS) $(CC_OPTION_CFLAGS) -x c /dev/null -c -o 
"$$TMPO"; \
-   $(LD) $(LDFLAGS) $(1) "$$TMPO" -o "$$TMP",$(1),$(2))
+ld-option = $(call try-run-cached, $(LD) $(LDFLAGS) $(1) -v,$(1),$(2))
 
 # ar-option
 # Usage: KBUILD_ARFLAGS := $(call ar-option,D)
-- 
2.7.4

[PATCH 1/2] kbuild: test --build-id linker flag by ld-option instead of cc-ldoption

[Masahiro Yamada]

'--build-id' is passed to $(LD), so it should be tested by 'ld-option'.

This seems a kind of misconversion when ld-option was renamed to
cc-ldoption.

Commit f86fd3066052 ("kbuild: rename ld-option to cc-ldoption") renamed
all instances of 'ld-option' to 'cc-ldoption'.

Then, commit 691ef3e7fdc1 ("kbuild: introduce ld-option") re-added
'ld-option' as a new implementation.

Signed-off-by: Masahiro Yamada 
---

 Makefile | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/Makefile b/Makefile
index 4f295a2..1ed2a15 100644
--- a/Makefile
+++ b/Makefile
@@ -866,8 +866,7 @@ KBUILD_AFLAGS   += $(ARCH_AFLAGS)   $(KAFLAGS)
 KBUILD_CFLAGS   += $(ARCH_CFLAGS)   $(KCFLAGS)
 
 # Use --build-id when available.
-LDFLAGS_BUILD_ID := $(patsubst -Wl$(comma)%,%,\
- $(call cc-ldoption, -Wl$(comma)--build-id,))
+LDFLAGS_BUILD_ID := $(call ld-option, --build-id)
 KBUILD_LDFLAGS_MODULE += $(LDFLAGS_BUILD_ID)
 LDFLAGS_vmlinux += $(LDFLAGS_BUILD_ID)
 
-- 
2.7.4

Re: [RFC tip/locking/lockdep v5 05/17] lockdep: Extend __bfs() to work with multiple kinds of dependencies

[Boqun Feng]

On Fri, Feb 23, 2018 at 12:31:20AM +0800, Boqun Feng wrote:
> On Thu, Feb 22, 2018 at 04:51:43PM +0100, Peter Zijlstra wrote:
> > On Thu, Feb 22, 2018 at 04:30:34PM +0100, Peter Zijlstra wrote:
> > > On Thu, Feb 22, 2018 at 11:12:10PM +0800, Boqun Feng wrote:
> > > > On Thu, Feb 22, 2018 at 03:26:14PM +0100, Peter Zijlstra wrote:
> > > 
> > > > > However, I would suggest:
> > > > > 
> > > > > static inline bool is_xr(u16 dep)
> > > > > {
> > > > >   return !!(dep & (DEP_NR_MASK | DEP_RR_MASK));
> > > > > }
> > > > > 
> > > > > static inline bool is_rx(u16 dep)
> > > > > {
> > > > >   return !!(dep & (DEP_RN_MASK | DEP_RR_MASK));
> > > > > }
> > > > > 
> > > > >   /* Skip *R -> R* relations */
> > > > >   if (have_xr && is_rx(entry->dep))
> > > > >   continue;
> > > > 
> > > > I don't think this works, if we pick a *R for previous entry, and for
> > > > current entry, we have RR, NN and NR, your approach will skip the
> > > > current entry, but actually we can pick NN or NR (of course, in __bfs(),
> > > > we can greedily pick NN, because if NR causes a deadlock, so does NN).
> > > 
> > > I don't get it, afaict my suggestion is identical.
> > > 
> > > You skip condition: pick_dep() < 0, evaluates to:
> > > 
> > >   is_rr && (!NN_MASK && !NR_MASK) :=
> > >   is_rr && (RN_MASK | RR_MASK)
> > > 
> > > Which is exactly what I have.
> > 
> > Ooh, I think I see what I did wrong, would something like:
> > 
> > if (have_xr && !is_nx(entry-dep))
> > 
> > work? That's a lot harder to argue about though, still much better than
> 
> I think it works. Although I prefer use name "has_nx" for the fucntion.
> 
> > that tri-state pick thing.
> > 
> 
> Agree.
> 
> > > If that is satisfied, you set entry->is_rr to pick_dep(), which his
> > > harder to evaluate, but is something like:
> > > 
> > >   is_rr && NR_MASK || !(NN_MASK | RN_MASK) :=
> 
> If is_rr is true and NN_MASK is true, pick_dep() will return 0, however,
> your expression will return NR_MASK.
> 

It was too late last night, I was meant to say, the correct
entry->have_xr should be as follow:

>   entry->have_xr = !(has_nn(entry->dep) || (!is_rr && 
> has_rn(entry->dep)));
> := !has_nn(entry->dep) && (is_rr || !has_rn(entry->dep))
> 

so it seems that we have to introduce is_{nn,rn,nx}(), I'm not sure
introducing three one-off helpers is a good direction to go. One benefit
of using pick_dep() is that we can keep the whole logic in one function.
Thoughts?

Regards,
Boqun

> Regards,
> Boqun
> 
> > >   is_rr && NR_MASK || (NR_MASK | RR_MASK) :=
> > >   (NR_MASK | RR_MASK)
> > > 
> > > (because is_rr && RR_MASK will have been skipped)
> > > 
> > > > > 
> > > > >   entry->have_xr = is_xr(entry->dep);
> > 
> > This one I think is still correct though.




signature.asc
Description: PGP signature

[PATCH v4 2/2] gpio: Add GPIO driver for Spreadtrum SC9860 platform

[Baolin Wang]

The Spreadtrum SC9860 platform GPIO controller contains 16 groups and
each group contains 16 GPIOs. Each GPIO can set input/output and has
the interrupt capability.

Signed-off-by: Baolin Wang 
Reviewed-by: Andy Shevchenko 
---
Changes since v3:
 - Add OF_GPIO dependency.
 - Rename all 'group' to 'bank'.
 - Simplify the sprd_gpio_update() and sprd_gpio_read().

Changes since v2:
 - Use devm_ioremap_resource() instead of devm_ioremap_nocache().

Changes since v1:
 - Change 'bool' to 'tristate'.
 - Add reviewed tag from Andy.
---
 drivers/gpio/Kconfig |8 ++
 drivers/gpio/Makefile|1 +
 drivers/gpio/gpio-sprd.c |  290 ++
 3 files changed, 299 insertions(+)
 create mode 100644 drivers/gpio/gpio-sprd.c

diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 8dbb228..a64b29d 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -398,6 +398,14 @@ config GPIO_SPEAR_SPICS
help
  Say yes here to support ST SPEAr SPI Chip Select as GPIO device
 
+config GPIO_SPRD
+   tristate "Spreadtrum GPIO support"
+   depends on ARCH_SPRD || COMPILE_TEST
+   depends on OF_GPIO
+   select GPIOLIB_IRQCHIP
+   help
+ Say yes here to support Spreadtrum GPIO device.
+
 config GPIO_STA2X11
bool "STA2x11/ConneXt GPIO support"
depends on MFD_STA2X11
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index cccb0d4..2e3d320 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -108,6 +108,7 @@ obj-$(CONFIG_GPIO_SCH)  += gpio-sch.o
 obj-$(CONFIG_GPIO_SCH311X) += gpio-sch311x.o
 obj-$(CONFIG_GPIO_SODAVILLE)   += gpio-sodaville.o
 obj-$(CONFIG_GPIO_SPEAR_SPICS) += gpio-spear-spics.o
+obj-$(CONFIG_GPIO_SPRD)+= gpio-sprd.o
 obj-$(CONFIG_GPIO_STA2X11) += gpio-sta2x11.o
 obj-$(CONFIG_GPIO_STMPE)   += gpio-stmpe.o
 obj-$(CONFIG_GPIO_STP_XWAY)+= gpio-stp-xway.o
diff --git a/drivers/gpio/gpio-sprd.c b/drivers/gpio/gpio-sprd.c
new file mode 100644
index 000..d847d37
--- /dev/null
+++ b/drivers/gpio/gpio-sprd.c
@@ -0,0 +1,290 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2018 Spreadtrum Communications Inc.
+ * Copyright (C) 2018 Linaro Ltd.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* GPIO registers definition */
+#define SPRD_GPIO_DATA 0x0
+#define SPRD_GPIO_DMSK 0x4
+#define SPRD_GPIO_DIR  0x8
+#define SPRD_GPIO_IS   0xc
+#define SPRD_GPIO_IBE  0x10
+#define SPRD_GPIO_IEV  0x14
+#define SPRD_GPIO_IE   0x18
+#define SPRD_GPIO_RIS  0x1c
+#define SPRD_GPIO_MIS  0x20
+#define SPRD_GPIO_IC   0x24
+#define SPRD_GPIO_INEN 0x28
+
+/* We have 16 banks GPIOs and each bank contain 16 GPIOs */
+#define SPRD_GPIO_BANK_NR  16
+#define SPRD_GPIO_NR   256
+#define SPRD_GPIO_BANK_SIZE0x80
+#define SPRD_GPIO_BANK_MASKGENMASK(15, 0)
+#define SPRD_GPIO_BIT(x)   ((x) & (SPRD_GPIO_BANK_NR - 1))
+
+struct sprd_gpio {
+   struct gpio_chip chip;
+   void __iomem *base;
+   spinlock_t lock;
+   int irq;
+};
+
+static inline void __iomem *sprd_gpio_bank_base(struct sprd_gpio *sprd_gpio,
+   unsigned int bank)
+{
+   return sprd_gpio->base + SPRD_GPIO_BANK_SIZE * bank;
+}
+
+static void sprd_gpio_update(struct gpio_chip *chip, unsigned int offset,
+u16 reg, int val)
+{
+   struct sprd_gpio *sprd_gpio = gpiochip_get_data(chip);
+   void __iomem *base = sprd_gpio_bank_base(sprd_gpio,
+offset / SPRD_GPIO_BANK_NR);
+   unsigned long flags;
+   u32 tmp;
+
+   spin_lock_irqsave(&sprd_gpio->lock, flags);
+   tmp = readl_relaxed(base + reg);
+
+   if (val)
+   tmp |= BIT(SPRD_GPIO_BIT(offset));
+   else
+   tmp &= ~BIT(SPRD_GPIO_BIT(offset));
+
+   writel_relaxed(tmp, base + reg);
+   spin_unlock_irqrestore(&sprd_gpio->lock, flags);
+}
+
+static int sprd_gpio_read(struct gpio_chip *chip, unsigned int offset, u16 reg)
+{
+   struct sprd_gpio *sprd_gpio = gpiochip_get_data(chip);
+   void __iomem *base = sprd_gpio_bank_base(sprd_gpio,
+offset / SPRD_GPIO_BANK_NR);
+
+   return !!(readl_relaxed(base + reg) & BIT(SPRD_GPIO_BIT(offset)));
+}
+
+static int sprd_gpio_request(struct gpio_chip *chip, unsigned int offset)
+{
+   sprd_gpio_update(chip, offset, SPRD_GPIO_DMSK, 1);
+   return 0;
+}
+
+static void sprd_gpio_free(struct gpio_chip *chip, unsigned int offset)
+{
+   sprd_gpio_update(chip, offset, SPRD_GPIO_DMSK, 0);
+}
+
+static int sprd_gpio_direction_input(struct gpio_chip *chip,
+unsigned int offset)
+{
+   sprd_gpio_update(chip, offset, SPRD_GPIO_DIR, 0);
+   sprd_gpio_update(chip, offset, SPRD_G

[PATCH v4 1/2] dt-bindings: gpio: Add Spreadtrum GPIO controller documentation

[Baolin Wang]

This patch adds the device tree bindings for the Spreadtrum
GPIO controller. The gpios will be supported by the GPIO
generic library.

Signed-off-by: Baolin Wang 
Acked-by: Rob Herring 
---
Changes since v3:
 - Add acked tag from Rob.

Changes since v2:
 - No updates.

Changes since v1:
 - No updates.
---
 .../devicetree/bindings/gpio/gpio-sprd.txt |   28 
 1 file changed, 28 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/gpio/gpio-sprd.txt

diff --git a/Documentation/devicetree/bindings/gpio/gpio-sprd.txt 
b/Documentation/devicetree/bindings/gpio/gpio-sprd.txt
new file mode 100644
index 000..eca97d4
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio-sprd.txt
@@ -0,0 +1,28 @@
+Spreadtrum GPIO controller bindings
+
+The controller's registers are organized as sets of sixteen 16-bit
+registers with each set controlling a bank of up to 16 pins. A single
+interrupt is shared for all of the banks handled by the controller.
+
+Required properties:
+- compatible: Should be "sprd,sc9860-gpio".
+- reg: Define the base and range of the I/O address space containing
+the GPIO controller registers.
+- gpio-controller: Marks the device node as a GPIO controller.
+- #gpio-cells: Should be <2>. The first cell is the gpio number and
+the second cell is used to specify optional parameters.
+- interrupt-controller: Marks the device node as an interrupt controller.
+- #interrupt-cells: Should be <2>. Specifies the number of cells needed
+to encode interrupt source.
+- interrupts: Should be the port interrupt shared by all the gpios.
+
+Example:
+   ap_gpio: gpio@4028 {
+   compatible = "sprd,sc9860-gpio";
+   reg = <0 0x4028 0 0x1000>;
+   gpio-controller;
+   #gpio-cells = <2>;
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   interrupts = ;
+   };
-- 
1.7.9.5

Re: The white man -- Who he is

[thetruthbeforeus]

Please listen to the arguments made and take them into consideration.
Again, fellow FLOSS programmers, the discussion is at: 
http://youtu.be/Foi_LbdMjXU


(Which is, ofcourse, CC-BY-SA licensed)
On 2018-02-23 04:24, thetruthbefor...@firemail.cc wrote:

Truth about the white man: http://youtu.be/Foi_LbdMjXU
I think all my fellow FLOSS programmers should take a moment to join
the discussion, to take a good look at just WHO the white man is and
how his essence negatively or positively affects the people of the
world, and if any accord can be reached so he realizes what he is
doing and why.

Re: [PATCH V2 1/7] thermal/drivers/cpu_cooling: Fixup the header and copyright

[Viresh Kumar]

On 21-02-18, 16:29, Daniel Lezcano wrote:
> The copyright format does not conform to the format requested by
> Linaro: https://wiki.linaro.org/Copyright
> 
> Fix it.
> 
> Signed-off-by: Daniel Lezcano 
> ---
>  drivers/thermal/cpu_cooling.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c
> index dc63aba..42110ee 100644
> --- a/drivers/thermal/cpu_cooling.c
> +++ b/drivers/thermal/cpu_cooling.c
> @@ -2,9 +2,11 @@
>   *  linux/drivers/thermal/cpu_cooling.c
>   *
>   *  Copyright (C) 2012   Samsung Electronics Co., 
> Ltd(http://www.samsung.com)
> - *  Copyright (C) 2012  Amit Daniel 
>   *
> - *  Copyright (C) 2014  Viresh Kumar 
> + *  Copyright (C) 2012-2018 Linaro Limited.
> + *
> + *  Authors: Amit Daniel 
> + *   Viresh Kumar 
>   *
>   * ~~
>   *  This program is free software; you can redistribute it and/or modify

Acked-by: Viresh Kumar 

-- 
viresh

Re: [PATCH v2 07/17] tracing: probeevent: Introduce new argument fetching code

[Namhyung Kim]

On Wed, Feb 21, 2018 at 11:57:36PM +0900, Masami Hiramatsu wrote:
> Replace {k,u}probe event argument fetching framework
> with switch-case based. Currently that is implemented
> with structures, macros and chain of function-pointers,
> which is more complicated than necessary and may get
> a performance penalty by retpoline.
> 
> This simplify that with an array of "fetch_insn" (opcode
> and oprands), and make process_fetch_insn() just
> interprets it. No function pointers are used.

I think it'd be nice to split this commit to 3 parts:

 * convert to the fetch_insn
 * remove fetch methods (now unused)
 * unify fetch type table

Thanks,
Namhyung


> 
> Signed-off-by: Masami Hiramatsu 
> ---
>  Changes in v2:
>   - Allow $comm:string.
> ---
>  kernel/trace/trace_kprobe.c |  314 +++-
>  kernel/trace/trace_probe.c  |  441 
> ---
>  kernel/trace/trace_probe.h  |  232 -
>  kernel/trace/trace_probe_tmpl.h |  120 +++
>  kernel/trace/trace_uprobe.c |  150 +++--
>  5 files changed, 517 insertions(+), 740 deletions(-)
>  create mode 100644 kernel/trace/trace_probe_tmpl.h
> 
> diff --git a/kernel/trace/trace_kprobe.c b/kernel/trace/trace_kprobe.c
> index a96328dfc012..5dd2d470cc7e 100644
> --- a/kernel/trace/trace_kprobe.c
> +++ b/kernel/trace/trace_kprobe.c
> @@ -24,6 +24,7 @@
>  #include 
>  
>  #include "trace_probe.h"
> +#include "trace_probe_tmpl.h"
>  
>  #define KPROBE_EVENT_SYSTEM "kprobes"
>  #define KRETPROBE_MAXACTIVE_MAX 4096
> @@ -121,184 +122,6 @@ static int kprobe_dispatcher(struct kprobe *kp, struct 
> pt_regs *regs);
>  static int kretprobe_dispatcher(struct kretprobe_instance *ri,
>   struct pt_regs *regs);
>  
> -/* Memory fetching by symbol */
> -struct symbol_cache {
> - char*symbol;
> - longoffset;
> - unsigned long   addr;
> -};
> -
> -unsigned long update_symbol_cache(struct symbol_cache *sc)
> -{
> - sc->addr = (unsigned long)kallsyms_lookup_name(sc->symbol);
> -
> - if (sc->addr)
> - sc->addr += sc->offset;
> -
> - return sc->addr;
> -}
> -
> -void free_symbol_cache(struct symbol_cache *sc)
> -{
> - kfree(sc->symbol);
> - kfree(sc);
> -}
> -
> -struct symbol_cache *alloc_symbol_cache(const char *sym, long offset)
> -{
> - struct symbol_cache *sc;
> -
> - if (!sym || strlen(sym) == 0)
> - return NULL;
> -
> - sc = kzalloc(sizeof(struct symbol_cache), GFP_KERNEL);
> - if (!sc)
> - return NULL;
> -
> - sc->symbol = kstrdup(sym, GFP_KERNEL);
> - if (!sc->symbol) {
> - kfree(sc);
> - return NULL;
> - }
> - sc->offset = offset;
> - update_symbol_cache(sc);
> -
> - return sc;
> -}
> -
> -/*
> - * Kprobes-specific fetch functions
> - */
> -#define DEFINE_FETCH_stack(type) \
> -static void FETCH_FUNC_NAME(stack, type)(struct pt_regs *regs,   
> \
> -   void *offset, void *dest) \
> -{\
> - *(type *)dest = (type)regs_get_kernel_stack_nth(regs,   \
> - (unsigned int)((unsigned long)offset)); \
> -}\
> -NOKPROBE_SYMBOL(FETCH_FUNC_NAME(stack, type));
> -
> -DEFINE_BASIC_FETCH_FUNCS(stack)
> -/* No string on the stack entry */
> -#define fetch_stack_string   NULL
> -#define fetch_stack_string_size  NULL
> -
> -#define DEFINE_FETCH_memory(type)\
> -static void FETCH_FUNC_NAME(memory, type)(struct pt_regs *regs,  
> \
> -   void *addr, void *dest)   \
> -{\
> - type retval;\
> - if (probe_kernel_address(addr, retval)) \
> - *(type *)dest = 0;  \
> - else\
> - *(type *)dest = retval; \
> -}\
> -NOKPROBE_SYMBOL(FETCH_FUNC_NAME(memory, type));
> -
> -DEFINE_BASIC_FETCH_FUNCS(memory)
> -/*
> - * Fetch a null-terminated string. Caller MUST set *(u32 *)dest with max
> - * length and relative data location.
> - */
> -static void FETCH_FUNC_NAME(memory, string)(struct pt_regs *regs,
> - void *addr, void *dest)
> -{
> - int maxlen = get_rloc_len(*(u32 *)dest);
> - u8 *dst = get_rloc_data(dest);
> - long ret;
> -
> - if (!maxlen)
> - return;
> -
> - /*
> -  * Try to get string again, since the string can be changed while
> -  * p

The white man -- Who he is

[thetruthbeforeus]

Truth about the white man: http://youtu.be/Foi_LbdMjXU
I think all my fellow FLOSS programmers should take a moment to join the 
discussion, to take a good look at just WHO the white man is and how his 
essence negatively or positively affects the people of the world, and if 
any accord can be reached so he realizes what he is doing and why.

[PATCH net-next] net/ncsi: Add generic netlink family

[Samuel Mendoza-Jonas]

Add a generic netlink family for NCSI. This supports two commands;
NCSI_CMD_PKG_INFO which returns information on packages and their
associated channels, and NCSI_CMD_SET_INTERFACE which allows a specific
package or package/channel combination to be set as the preferred
choice.

Signed-off-by: Samuel Mendoza-Jonas 
---
 include/uapi/linux/ncsi.h | 113 +
 net/ncsi/Makefile |   2 +-
 net/ncsi/internal.h   |   3 +
 net/ncsi/ncsi-manage.c|  30 +++-
 net/ncsi/ncsi-netlink.c   | 394 ++
 net/ncsi/ncsi-netlink.h   |  20 +++
 6 files changed, 557 insertions(+), 5 deletions(-)
 create mode 100644 include/uapi/linux/ncsi.h
 create mode 100644 net/ncsi/ncsi-netlink.c
 create mode 100644 net/ncsi/ncsi-netlink.h

diff --git a/include/uapi/linux/ncsi.h b/include/uapi/linux/ncsi.h
new file mode 100644
index ..aecab3fb92df
--- /dev/null
+++ b/include/uapi/linux/ncsi.h
@@ -0,0 +1,113 @@
+/*
+ * Copyright Samuel Mendoza-Jonas, IBM Corporation 2018.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#ifndef __UAPI_NCSI_NETLINK_H__
+#define __UAPI_NCSI_NETLINK_H__
+
+/**
+ * enum ncsi_nl_commands - supported NCSI commands
+ *
+ * @NCSI_CMD_UNSPEC: unspecified command to catch errors
+ * @NCSI_CMD_SET_INTERFACE: set preferred package and channel combination.
+ * Requires NCSI_ATTR_IFINDEX and the preferred NCSI_ATTR_PACKAGE_ID and
+ * optionally the preferred NCSI_ATTR_CHANNEL_ID. If neither IDs are
+ * specified the setting is cleared.
+ * @NCSI_CMD_PKG_INFO: list package and channel attributes. Requires
+ * NCSI_ATTR_IFINDEX. If NCSI_ATTR_PACKAGE_ID is specified returns the
+ * specific package and its channels - otherwise a dump request returns
+ * all packages and their associated channels.
+ * @NCSI_CMD_MAX: highest command number
+ */
+enum ncsi_nl_commands {
+   NCSI_CMD_UNSPEC,
+   NCSI_CMD_SET_INTERFACE,
+   NCSI_CMD_PKG_INFO,
+
+   __NCSI_CMD_AFTER_LAST,
+   NCSI_CMD_MAX = __NCSI_CMD_AFTER_LAST - 1
+};
+
+/**
+ * enum ncsi_nl_attrs - General NCSI netlink attributes
+ *
+ * @NCSI_ATTR_UNSPEC: unspecified attributes to catch errors
+ * @NCSI_ATTR_IFINDEX: ifindex of network device using NCSI
+ * @NCSI_ATTR_PACKAGE_LIST: nested array of NCSI_PKG_ATTR attributes
+ * @NCSI_ATTR_PACKAGE_ID: package ID
+ * @NCSI_ATTR_CHANNEL_ID: channel ID
+ * @NCSI_ATTR_MAX: highest attribute number
+ */
+enum ncsi_nl_attrs {
+   NCSI_ATTR_UNSPEC,
+   NCSI_ATTR_IFINDEX,
+   NCSI_ATTR_PACKAGE_LIST,
+   NCSI_ATTR_PACKAGE_ID,
+   NCSI_ATTR_CHANNEL_ID,
+
+   __NCSI_ATTR_AFTER_LAST,
+   NCSI_ATTR_MAX = __NCSI_ATTR_AFTER_LAST - 1
+};
+
+/**
+ * enum ncsi_nl_pkg_attrs - NCSI netlink package-specific attributes
+ *
+ * @NCSI_PKG_ATTR_UNSPEC: unspecified attributes to catch errors
+ * @NCSI_PKG_ATTR: nested array of package attributes
+ * @NCSI_PKG_ATTR_ID: package ID
+ * @NCSI_PKG_ATTR_FORCED: flag signifying a package has been set as preferred
+ * @NCSI_PKG_ATTR_CHANNEL_LIST: nested array of NCSI_CHANNEL_ATTR attributes
+ * @NCSI_PKG_ATTR_MAX: highest attribute number
+ */
+enum ncsi_nl_pkg_attrs {
+   NCSI_PKG_ATTR_UNSPEC,
+   NCSI_PKG_ATTR,
+   NCSI_PKG_ATTR_ID,
+   NCSI_PKG_ATTR_FORCED,
+   NCSI_PKG_ATTR_CHANNEL_LIST,
+
+   __NCSI_PKG_ATTR_AFTER_LAST,
+   NCSI_PKG_ATTR_MAX = __NCSI_PKG_ATTR_AFTER_LAST - 1
+};
+
+/**
+ * enum ncsi_nl_channel_attrs - NCSI netlink channel-specific attributes
+ *
+ * @NCSI_CHANNEL_ATTR_UNSPEC: unspecified attributes to catch errors
+ * @NCSI_CHANNEL_ATTR: nested array of channel attributes
+ * @NCSI_CHANNEL_ATTR_ID: channel ID
+ * @NCSI_CHANNEL_ATTR_VERSION_MAJOR: channel major version number
+ * @NCSI_CHANNEL_ATTR_VERSION_MINOR: channel minor version number
+ * @NCSI_CHANNEL_ATTR_VERSION_STR: channel version string
+ * @NCSI_CHANNEL_ATTR_LINK_STATE: channel link state flags
+ * @NCSI_CHANNEL_ATTR_ACTIVE: channels with this flag are in
+ * NCSI_CHANNEL_ACTIVE state
+ * @NCSI_CHANNEL_ATTR_FORCED: flag signifying a channel has been set as
+ * preferred
+ * @NCSI_CHANNEL_ATTR_VLAN_LIST: nested array of NCSI_CHANNEL_ATTR_VLAN_IDs
+ * @NCSI_CHANNEL_ATTR_VLAN_ID: VLAN ID being filtered on this channel
+ * @NCSI_CHANNEL_ATTR_MAX: highest attribute number
+ */
+enum ncsi_nl_channel_attrs {
+   NCSI_CHANNEL_ATTR_UNSPEC,
+   NCSI_CHANNEL_ATTR,
+   NCSI_CHANNEL_ATTR_ID,
+   NCSI_CHANNEL_ATTR_VERSION_MAJOR,
+   NCSI_CHANNEL_ATTR_VERSION_MINOR,
+   NCSI_CHANNEL_ATTR_VERSION_STR,
+   NCSI_CHANNEL_ATTR_LINK_STATE,
+   NCSI_CHANNEL_ATTR_ACTIVE,
+   NCSI_CHANNEL_ATTR_FORCED,
+   NCSI_CHANNEL_ATTR_VLAN_LIST,
+   NCSI_CHANNEL_ATTR_VLAN_ID,
+
+   __NCSI_CHANNEL_ATTR_AFTER_LAST,
+   

Re: [PATCH] cpufreq: scpi: drop redundant arm_big_little config dependency

[Viresh Kumar]

On 22-02-18, 18:00, Sudeep Holla wrote:

Not sure if 'redundant' is the right term to be used here. I would
rather say: "Fix incorrect config dependency" :)

> Commit 343a8d17fa8d (cpufreq: scpi: remove arm_big_little dependency)
> removed the SCPI cpufreq dependency on arm_big_little cpufreq driver.
> However the Kconfig entry still depends on ARM_BIG_LITTLE_CPUFREQ
> which is clearly wrong.
> 
> This patch removes that unnecessary Kconfig dependency.
> 
> Fixes: 343a8d17fa8d (cpufreq: scpi: remove arm_big_little dependency)
> Reported-by: Quentin Perret 
> Cc: "Rafael J. Wysocki" 
> Cc: Viresh Kumar 
> Signed-off-by: Sudeep Holla 
> ---
>  drivers/cpufreq/Kconfig.arm | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
> index 2e49673a9e21..9bbb5b39d18a 100644
> --- a/drivers/cpufreq/Kconfig.arm
> +++ b/drivers/cpufreq/Kconfig.arm
> @@ -44,10 +44,10 @@ config ARM_DT_BL_CPUFREQ
>  
>  config ARM_SCPI_CPUFREQ
>   tristate "SCPI based CPUfreq driver"
> - depends on ARM_BIG_LITTLE_CPUFREQ && ARM_SCPI_PROTOCOL && 
> COMMON_CLK_SCPI
> + depends on ARM_SCPI_PROTOCOL && COMMON_CLK_SCPI
>   help
> -   This adds the CPUfreq driver support for ARM big.LITTLE platforms
> -   using SCPI protocol for CPU power management.
> +   This adds the CPUfreq driver support for ARM platforms using SCPI
> +   protocol for CPU power management.
>  
> This driver uses SCPI Message Protocol driver to interact with the
> firmware providing the CPU DVFS functionality.

Acked-by: Viresh Kumar 

-- 
viresh

Re: [PATCH 2/3] Kconfig: improve handling for all{rand,yes,no,}.config fragments

[Masahiro Yamada]

2018-02-22 1:57 GMT+09:00 Arnd Bergmann :
> On Tue, Feb 20, 2018 at 6:04 PM, Masahiro Yamada
>  wrote:
>> 2018-02-20 18:59 GMT+09:00 Arnd Bergmann :
>>> On Tue, Feb 20, 2018 at 10:26 AM, Masahiro Yamada
>>>  wrote:
 2018-02-17 6:41 GMT+09:00 Arnd Bergmann :
>>>
> @@ -621,14 +622,24 @@ int main(int ac, char **av)
> case randconfig:name = "allrandom.config"; break;
> default: break;
> }
> -   if (conf_read_simple(name, S_DEF_USER) &&
> -   conf_read_simple("all.config", S_DEF_USER)) {
> -   fprintf(stderr,
> -   _("*** KCONFIG_ALLCONFIG set, but no 
> \"%s\" or \"all.config\" file found\n"),
> -   name);
> -   exit(1);
> +   /* try ./name, arch/$(ARCH)/configs/name and 
> kernel/config/name */
> +   if (!conf_read_simple(name, S_DEF_USER))
> +   break;
> +   arch = getenv("ARCH");
> +   if (arch) {
> +   snprintf(fullname, sizeof(fullname), 
> "arch/%s/configs/%s",
> +arch, name);
> +   if (!conf_read_simple(fullname, S_DEF_USER))
> +   break;
> }


 I am not a big fan of hard-coding the kernel directory structure.

 We already do this [1], but I am thinking of kicking this out.
 [1] 
 https://github.com/torvalds/linux/blob/v4.16-rc1/scripts/kconfig/confdata.c#L33
>>>
>>> Ok, I see. How about adding a way to detect that we are build-testing
>>> with randconfig instead?
>>
>>
>> How about implementing something in scripts/kconfig/Makefile?
>>
>> merge_config collects config fragments into 'configfiles'
>>
>> I was thinking of a similar thing.
>>
>>
>> If KCONFIG_ALLCONFIG is 1,
>> scripts/kconfig/Makefile searches
>> './', '$srctree/', 'arch/$(SRCARCH)/configs/', 'kernel/configs/'
>> and sets the found file in it,
>>
>> If KCONFIG_ALLCONFIG already contains a file name, it is used as-is.
>>
>> scripts/kconfig/conf.c will be simplified.
>
> Yes, good idea. I'm struggling a bit with the implementation (fitting
> it into the
> simple-tagets rule), can you come up with a prototype?


Just a prototype for the Makefile part.
(We need to agree with the search order specification, though)


>8-
configs_dirs := $(srctree)/kernel/configs/ $(srctree)/arch/$(SRCARCH)/configs/

allconfig_files = $(if $(filter 1, $(KCONFIG_ALLCONFIG)),$(firstword \
$(foreach f, $(1), $(wildcard $(addsuffix $(f), ./ $(srctree)/))) \
$(foreach f, $(1), $(subst $(space),$(comma),$(wildcard
$(addsuffix $(f), $(configs_dirs)), \
$(KCONFIG_ALLCONFIG))

allyesconfig: override KCONFIG_ALLCONFIG := $(call allconfig_files,
allyes.config all.config)
allmodconfig: override KCONFIG_ALLCONFIG := $(call allconfig_files,
allmoyes.config all.config)
 (likewise for allnoconfig, alldefconfig)
randconfig: override KCONFIG_ALLCONFIG := $(call allconfig_files,
allrandom.config all.config)
->8---


If a user specifies a file path in KCONFIG_ALLCONFIG, it is used as-is.

IF KCONFIG_ALLCONFIG=1, the input file is searched in the following order.
( [1] - [4] is the same as the current specification)

[1] ./allrandom.config
[2] $(srctree)/allrandom.config
[3] ./all.config
[4] $(srctree)/all.config
[5] $(srctree)/kernel/configs/allrandom.config +
$(srctree)/arch/$(SRCARCH)/configs/allrandom.config
[6] $(srctree)/kernel/configs/all.config +
$(srctree)/arch/$(SRCARCH)/configs/all.config

For [5] and [6], if multiple files are found, KCONFIG_ALLCONFIG
is set to comma-separated file paths.

scripts/kconfig/conf.c must be tweaked a little bit
if we need to read multiple config fragments.

Currently, tinyconfig for x86 comes from common part and arch-specific part.
./kernel/configs/tiny.config
./arch/x86/configs/tiny.config


What do you think?







> We also need to decide what happens when e.g. both a ./all.config and
> arch/${SRCARCH}/configs/allrand.config file exist, should the first path
> take precedence or the more specific file?
>



-- 
Best Regards
Masahiro Yamada

Re: [PATCH] integrity/security: fix digsig.c build error with header file

[James Morris]

On Mon, 12 Feb 2018, Randy Dunlap wrote:

> From: Randy Dunlap 
> 
> security/integrity/digsig.c has build errors on some $ARCH due to a
> missing header file, so add it.
> 
>   security/integrity/digsig.c:146:2: error: implicit declaration of function 
> 'vfree' [-Werror=implicit-function-declaration]
> 
> Reported-by: Michael Ellerman 
> Signed-off-by: Randy Dunlap 
> Cc: Mimi Zohar 
> Cc: linux-integr...@vger.kernel.org
> Link: http://kisskb.ellerman.id.au/kisskb/head/13396/
> ---
>  security/integrity/digsig.c |1 +
>  1 file changed, 1 insertion(+)

Applied to
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git 
fixes-v4.16-rc3




-- 
James Morris

Re: [PATCH v11 04/10] clocksource: timer-ti-dm: Replace architecture

[Keerthy]

On Friday 23 February 2018 12:15 AM, Tony Lindgren wrote:
> * Ladislav Michl  [180222 10:58]:
>> On Thu, Feb 15, 2018 at 11:31:45AM +0530, Keerthy wrote:
>>> Replace architecture specific guard with clocksource guard.
>>>
>>> Signed-off-by: Keerthy 
>>> Replace architecture specific defines with clocksource
>>
>> This looks like a bit unussual commit log. Also, what about merging
>> it with previous patch?
> 
> I'll just remove that line locally to avoid yet another set
> of patches being posted :)

Thanks!

> 
>> Btw, I tested whole serie again on the top of today's -next and it is
>> still working fine. What is preventing these patches from being merged?

Ladis,

Thanks once again.


> 
> Well I noticed we need a fix for omap1 that I just posted.
> And patch 4/10 needs the following select for omap16xx that
> I'll fold in.
> 
> I'll push it all to omap-for-v4.17/timer and will merge into
> my for-next after some more testing. It seems any further
> patching can be done after move to drivers.

Yes that would be great.

> 
> Regards,
> 
> Tony
> 
> 8< -
> --- a/arch/arm/mach-omap1/Kconfig
> +++ b/arch/arm/mach-omap1/Kconfig
> @@ -30,6 +30,7 @@ config ARCH_OMAP16XX
>   bool "OMAP16xx Based System"
>   select ARCH_OMAP_OTG
>   select CPU_ARM926T
> + select OMAP_DM_TIMER
>  
>  config OMAP_MUX
>   bool "OMAP multiplexing support"
> 

[PATCH] cpufreq: s3c24xx: Fix broken s3c_cpufreq_init()

[Viresh Kumar]

commit a307a1e6bc0d ("cpufreq: s3c: use cpufreq_generic_init()")
accidentally broke cpufreq on s3c2410 and s3c2412. These two platforms
don't have a CPU frequency table and used to skip calling
cpufreq_table_validate_and_show() for them. But with the above commit,
we started calling it unconditionally and that will eventually fail as
the frequency table pointer is NULL.

Fix this by calling cpufreq_table_validate_and_show() conditionally
again.

Cc: sta...@vger.kernel.org # v3.13+
Fixes: a307a1e6bc0d ("cpufreq: s3c: use cpufreq_generic_init()")
Signed-off-by: Viresh Kumar 
---
 drivers/cpufreq/s3c24xx-cpufreq.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/cpufreq/s3c24xx-cpufreq.c 
b/drivers/cpufreq/s3c24xx-cpufreq.c
index 7b596fa38ad2..6bebc1f9f55a 100644
--- a/drivers/cpufreq/s3c24xx-cpufreq.c
+++ b/drivers/cpufreq/s3c24xx-cpufreq.c
@@ -351,7 +351,13 @@ struct clk *s3c_cpufreq_clk_get(struct device *dev, const 
char *name)
 static int s3c_cpufreq_init(struct cpufreq_policy *policy)
 {
policy->clk = clk_arm;
-   return cpufreq_generic_init(policy, ftab, cpu_cur.info->latency);
+
+   policy->cpuinfo.transition_latency = cpu_cur.info->latency;
+
+   if (ftab)
+   return cpufreq_table_validate_and_show(policy, ftab);
+
+   return 0;
 }
 
 static int __init s3c_cpufreq_initclks(void)
-- 
2.15.0.194.g9af6a3dea062

Re: [PATCH v2 6/6] fs/dcache: Avoid remaining try_lock loop in shrink_dentry_list()

[Al Viro]

On Fri, Feb 23, 2018 at 03:58:14AM +, Al Viro wrote:
> On Fri, Feb 23, 2018 at 12:50:25AM +0100, John Ogness wrote:
> 
> > Avoid the trylock loop by using dentry_kill(). When killing dentries
> > from the dispose list, it is very similar to killing a dentry in
> > dput(). The difference is that dput() expects to be the last user of
> > the dentry (refcount=1) and will deref whereas shrink_dentry_list()
> > expects there to be no user (refcount=0). In order to handle both
> > situations with the same code, move the deref code from dentry_kill()
> > into a new wrapper function dentry_put_kill(), which can be used
> > by previous dentry_kill() users. Then shrink_dentry_list() can use
> > the dentry_kill() to cleanup the dispose list.
> > 
> > This also has the benefit that the locking order is now the same.
> > First the inode is locked, then the parent.
> 
> Current code moves the sucker to the end of list in that case; I'm not
> at all sure that what you are doing will improve the situation at all...
> 
> You *still* have a trylock loop there - only it keeps banging at the
> same dentry instead of going through the rest first...

Actually, it's even worse - _here_ you are dealing with something that
really can change inode under you.  This is one and only case where
we are kicking out a zero-refcount dentry without having already held
->i_lock.  At the very least, it's bloody different from regular
dentry_kill().  In this case, dentry itself is protected from freeing
by being on the shrink list - that's what makes __dentry_kill() to
leave the sucker allocated.   We are not holding references, it is
hashed and anybody could come, pick it, d_delete() it, etc.

Re: [PATCH v2 6/6] fs/dcache: Avoid remaining try_lock loop in shrink_dentry_list()

[Al Viro]

On Fri, Feb 23, 2018 at 12:50:25AM +0100, John Ogness wrote:

> Avoid the trylock loop by using dentry_kill(). When killing dentries
> from the dispose list, it is very similar to killing a dentry in
> dput(). The difference is that dput() expects to be the last user of
> the dentry (refcount=1) and will deref whereas shrink_dentry_list()
> expects there to be no user (refcount=0). In order to handle both
> situations with the same code, move the deref code from dentry_kill()
> into a new wrapper function dentry_put_kill(), which can be used
> by previous dentry_kill() users. Then shrink_dentry_list() can use
> the dentry_kill() to cleanup the dispose list.
> 
> This also has the benefit that the locking order is now the same.
> First the inode is locked, then the parent.

Current code moves the sucker to the end of list in that case; I'm not
at all sure that what you are doing will improve the situation at all...

You *still* have a trylock loop there - only it keeps banging at the
same dentry instead of going through the rest first...

Re: [PATCH v2 5/6] fs/dcache: Avoid a try_lock loop in shrink_dentry_list()

[Al Viro]

On Fri, Feb 23, 2018 at 12:50:24AM +0100, John Ogness wrote:
> - while (dentry && !lockref_put_or_lock(&dentry->d_lockref)) {
> - parent = lock_parent(dentry);
> - if (dentry->d_lockref.count != 1) {
> - dentry->d_lockref.count--;
> - spin_unlock(&dentry->d_lock);
> - if (parent)
> - spin_unlock(&parent->d_lock);
> - break;
> - }
> - inode = dentry->d_inode;/* can't be NULL */
> - if (unlikely(!spin_trylock(&inode->i_lock))) {
> - spin_unlock(&dentry->d_lock);
> - if (parent)
> - spin_unlock(&parent->d_lock);
> - cpu_relax();
> - continue;
> - }
> - __dentry_kill(dentry);
> - dentry = parent;
> - }
> + while (dentry && !lockref_put_or_lock(&dentry->d_lockref))
> + dentry = dentry_kill(dentry);

Hmm...  OK, that's interesting.  I agree that it looks similar to dentry_kill()
loop, with one exception - here we are aggressively pruning the branch.  None
of the "do we want to retain that sucker" stuff here.  It doesn't matter for
most of the callers, with one exception: prune_dcache_sb().  OTOH, there it
just might be the right thing to do anyway - after all, it matters only if
somebody has grabbed and dropped the sucker while we'd been trying to do
lock_parent().  Had we lost the race with their dput(), we would've left
the damn thing alone, and we are called from a memory shrinker, so we'll get
called again if needed.

linux-next: Tree for Feb 23

[Stephen Rothwell]

Hi all,

Changes since 20180222:

New tree: nds32

The kvms390 tree gained a conflict against the nds32 tree.

The staging tree gained a conflict against Linus' tree.

The akpm-current tree lost its build failure.

Non-merge commits (relative to Linus' tree): 3167
 3757 files changed, 146492 insertions(+), 67966 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a
multi_v7_defconfig for arm and a native build of tools/perf. After
the final fixups (if any), I do an x86_64 modules_install followed by
builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit),
ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc
and sparc64 defconfig. And finally, a simple boot test of the powerpc
pseries_le_defconfig kernel in qemu (with and without kvm enabled).

Below is a summary of the state of the merge.

I am currently merging 257 trees (counting Linus' and 44 trees of bug
fix patches pending for the current merge release).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (a638af00b272 Merge tag 'usb-4.16-rc3' of 
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb)
Merging fixes/master (7928b2cbe55b Linux 4.16-rc1)
Merging kbuild-current/fixes (36c1681678b5 genksyms: drop *.hash.c from 
.gitignore)
Merging arc-current/for-curr (053823335956 arc: dts: use 'atmel' as 
manufacturer for at24 in axs10x_mb)
Merging arm-current/fixes (091f02483df7 ARM: net: bpf: clarify tail_call index)
Merging m68k-current/for-linus (2334b1ac1235 MAINTAINERS: Add NuBus subsystem 
entry)
Merging metag-fixes/fixes (b884a190afce metag/usercopy: Add missing fixups)
Merging powerpc-fixes/fixes (083b20907185 powerpc/bpf/jit: Fix 32-bit JIT for 
seccomp_data access)
Merging sparc/master (aebb48f5e465 sparc64: fix typo in 
CONFIG_CRYPTO_DES_SPARC64 => CONFIG_CRYPTO_CAMELLIA_SPARC64)
Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2)
Merging net/master (93c62c45ed5f rxrpc: Fix send in rxrpc_send_data_packet())
Merging bpf/master (6c5f61023c5b bpf: fix rcu lockdep warning for lpm_trie 
map_free callback)
Merging ipsec/master (013cb81e89f8 xfrm: Fix infinite loop in 
xfrm_get_dst_nexthop with transport mode.)
Merging netfilter/master (cfd092f2db8b amd-xgbe: Restore PCI interrupt 
enablement setting on resume)
Merging ipvs/master (f7fb77fc1235 netfilter: nft_compat: check extension hook 
mask only if set)
Merging wireless-drivers/master (7ac8ff95f48c mvpp2: fix multicast address 
filter)
Merging mac80211/master (657308f73e67 regulatory: add NUL to request alpha2)
Merging rdma-fixes/for-rc (f45765872e7a RDMA/uverbs: Fix kernel panic while 
using XRC_TGT QP type)
Merging sound-current/for-linus (7229b12f5da3 ALSA: x86: hdmi: Add single_port 
option for compatible behavior)
Merging pci-current/for-linus (7928b2cbe55b Linux 4.16-rc1)
Merging driver-core.current/driver-core-linus (91ab883eb213 Linux 4.16-rc2)
Merging tty.current/tty-linus (91ab883eb213 Linux 4.16-rc2)
Merging usb.current/usb-linus (44eb5e12b845 Revert "usb: musb: host: don't 
start next rx urb if current one failed")
Merging usb-gadget-fixes/fixes (98112041bcca usb: dwc3: core: Fix ULPI PHYs and 
prevent phy_get/ulpi_init during suspend/resume)
Merging usb-serial-fixes/usb-linus (d14ac576d10f USB: serial: cp210x: add new 
device ID ELV ALC 8xxx)
Merging usb-chipidea-fixes/ci-for-usb-stable (964728f9f407 USB: chipidea: msm: 
fix ulpi-node lookup)
Merging phy/fixes (7928b2cbe55b Linux 4.16-rc1)
Merging staging.current/staging-linus (c6754712e053 Merge tag 
'iio-fixes-for-4.16a' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-linus)
Merging char-misc.current/char-misc-linus (2a4ac172c2f2 mei: me: add cannon 
point device ids for 4th device)
Merging input-current/for-linus (ea4f7bd

[PATCH v2] x86/apic: Move pending intr check code into it's own function

[Dou Liyang]

the pending interrupt check code is mixed with the local APIC setup code,
that looks messy.

Extract the related code, move it into a new function named
apic_pending_intr_clear().

bonus cleanups from Andy Shevchenko's suggestions:

  - for() -> for_each_set_bit()
  - printk() -> pr_err()

Signed-off-by: Dou Liyang 
---
changlog:
v1 --> v2:
  -do some cleanup suggested by Andy
  -rebase the patch on the tip/master tree

 arch/x86/kernel/apic/apic.c | 99 -
 1 file changed, 53 insertions(+), 46 deletions(-)

diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
index 84b244ec49ed..687457d9df41 100644
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -1408,6 +1408,57 @@ static void lapic_setup_esr(void)
oldvalue, value);
 }
 
+static void apic_pending_intr_clear(void)
+{
+   long long max_loops = cpu_khz ? cpu_khz : 100;
+   unsigned long long tsc = 0, ntsc;
+   unsigned int queued;
+   unsigned long value;
+   int i, j, acked = 0;
+
+   if (boot_cpu_has(X86_FEATURE_TSC))
+   tsc = rdtsc();
+   /*
+* After a crash, we no longer service the interrupts and a pending
+* interrupt from previous kernel might still have ISR bit set.
+*
+* Most probably by now CPU has serviced that pending interrupt and
+* it might not have done the ack_APIC_irq() because it thought,
+* interrupt came from i8259 as ExtInt. LAPIC did not get EOI so it
+* does not clear the ISR bit and cpu thinks it has already serivced
+* the interrupt. Hence a vector might get locked. It was noticed
+* for timer irq (vector 0x31). Issue an extra EOI to clear ISR.
+*/
+   do {
+   queued = 0;
+   for (i = APIC_ISR_NR - 1; i >= 0; i--)
+   queued |= apic_read(APIC_IRR + i*0x10);
+
+   for (i = APIC_ISR_NR - 1; i >= 0; i--) {
+   value = apic_read(APIC_ISR + i*0x10);
+   for_each_set_bit(j, &value, 32) {
+   if (j) {
+   ack_APIC_irq();
+   acked++;
+   }
+   }
+   }
+   if (acked > 256) {
+   pr_err("LAPIC pending interrupts after %d EOI\n",
+   acked);
+   break;
+   }
+   if (queued) {
+   if (boot_cpu_has(X86_FEATURE_TSC) && cpu_khz) {
+   ntsc = rdtsc();
+   max_loops = (cpu_khz << 10) - (ntsc - tsc);
+   } else
+   max_loops--;
+   }
+   } while (queued && max_loops > 0);
+   WARN_ON(max_loops <= 0);
+}
+
 /**
  * setup_local_APIC - setup the local APIC
  *
@@ -1417,13 +1468,7 @@ static void lapic_setup_esr(void)
 static void setup_local_APIC(void)
 {
int cpu = smp_processor_id();
-   unsigned int value, queued;
-   int i, j, acked = 0;
-   unsigned long long tsc = 0, ntsc;
-   long long max_loops = cpu_khz ? cpu_khz : 100;
-
-   if (boot_cpu_has(X86_FEATURE_TSC))
-   tsc = rdtsc();
+   unsigned int value;
 
if (disable_apic) {
disable_ioapic_support();
@@ -1475,45 +1520,7 @@ static void setup_local_APIC(void)
value &= ~APIC_TPRI_MASK;
apic_write(APIC_TASKPRI, value);
 
-   /*
-* After a crash, we no longer service the interrupts and a pending
-* interrupt from previous kernel might still have ISR bit set.
-*
-* Most probably by now CPU has serviced that pending interrupt and
-* it might not have done the ack_APIC_irq() because it thought,
-* interrupt came from i8259 as ExtInt. LAPIC did not get EOI so it
-* does not clear the ISR bit and cpu thinks it has already serivced
-* the interrupt. Hence a vector might get locked. It was noticed
-* for timer irq (vector 0x31). Issue an extra EOI to clear ISR.
-*/
-   do {
-   queued = 0;
-   for (i = APIC_ISR_NR - 1; i >= 0; i--)
-   queued |= apic_read(APIC_IRR + i*0x10);
-
-   for (i = APIC_ISR_NR - 1; i >= 0; i--) {
-   value = apic_read(APIC_ISR + i*0x10);
-   for (j = 31; j >= 0; j--) {
-   if (value & (1< 256) {
-   printk(KERN_ERR "LAPIC pending interrupts after %d 
EOI\n",
-  acked);
-   break;
-   }
-   if (queued) {
-   if (boot_cpu_has(X86_FEATURE_TSC) && cpu_khz) {
-   ntsc = rdtsc();
-   max_loops = (cpu_khz

[PATCH v3] power: reset: Add Spreadtrum SC27xx PMIC power off support

[Baolin Wang]

On Spreadtrum platform, we need power off system through external SC27xx
series PMICs including the SC2720, SC2721, SC2723, SC2730 and SC2731 chips.
Thus this patch adds SC27xx series PMICs power-off support.

Signed-off-by: Baolin Wang 
---
Changes since v2:
 - Change to build-in this driver.

Changes since v1:
 - Add remove interface.
 - Add regmap checking when probing the driver.
 - Add MODULE_ALIAS()
---
 drivers/power/reset/Kconfig   |9 +
 drivers/power/reset/Makefile  |1 +
 drivers/power/reset/sc27xx-poweroff.c |   64 +
 3 files changed, 74 insertions(+)
 create mode 100644 drivers/power/reset/sc27xx-poweroff.c

diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig
index ca0de1a..01543f5 100644
--- a/drivers/power/reset/Kconfig
+++ b/drivers/power/reset/Kconfig
@@ -227,5 +227,14 @@ config SYSCON_REBOOT_MODE
  register, then the bootloader can read it to take different
  action according to the mode.
 
+config POWER_RESET_SC27XX
+   bool "Spreadtrum SC27xx PMIC power-off driver"
+   depends on MFD_SC27XX_PMIC || COMPILE_TEST
+   help
+ This driver supports powering off a system through
+ Spreadtrum SC27xx series PMICs. The SC27xx series
+ PMICs includes the SC2720, SC2721, SC2723, SC2730
+ and SC2731 chips.
+
 endif
 
diff --git a/drivers/power/reset/Makefile b/drivers/power/reset/Makefile
index aeb65ed..225d645 100644
--- a/drivers/power/reset/Makefile
+++ b/drivers/power/reset/Makefile
@@ -27,3 +27,4 @@ obj-$(CONFIG_POWER_RESET_RMOBILE) += rmobile-reset.o
 obj-$(CONFIG_POWER_RESET_ZX) += zx-reboot.o
 obj-$(CONFIG_REBOOT_MODE) += reboot-mode.o
 obj-$(CONFIG_SYSCON_REBOOT_MODE) += syscon-reboot-mode.o
+obj-$(CONFIG_POWER_RESET_SC27XX) += sc27xx-poweroff.o
diff --git a/drivers/power/reset/sc27xx-poweroff.c 
b/drivers/power/reset/sc27xx-poweroff.c
new file mode 100644
index 000..e3925a9
--- /dev/null
+++ b/drivers/power/reset/sc27xx-poweroff.c
@@ -0,0 +1,64 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2018 Spreadtrum Communications Inc.
+ * Copyright (C) 2018 Linaro Ltd.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define SC27XX_PWR_PD_HW   0xc2c
+#define SC27XX_PWR_OFF_EN  BIT(0)
+
+static struct regmap *regmap;
+
+/*
+ * On Spreadtrum platform, we need power off system through external SC27xx
+ * series PMICs, and it is one similar SPI bus mapped by regmap to access PMIC,
+ * which is not fast io access.
+ *
+ * So before stopping other cores, we need release other cores' resource by
+ * taking cpus down to avoid racing regmap or spi mutex lock when poweroff
+ * system through PMIC.
+ */
+void sc27xx_poweroff_shutdown(void)
+{
+   int cpu = smp_processor_id();
+
+   freeze_secondary_cpus(cpu);
+}
+
+static struct syscore_ops poweroff_syscore_ops = {
+   .shutdown = sc27xx_poweroff_shutdown,
+};
+
+static void sc27xx_poweroff_do_poweroff(void)
+{
+   regmap_write(regmap, SC27XX_PWR_PD_HW, SC27XX_PWR_OFF_EN);
+}
+
+static int sc27xx_poweroff_probe(struct platform_device *pdev)
+{
+   if (regmap)
+   return -EINVAL;
+
+   regmap = dev_get_regmap(pdev->dev.parent, NULL);
+   if (!regmap)
+   return -ENODEV;
+
+   pm_power_off = sc27xx_poweroff_do_poweroff;
+   register_syscore_ops(&poweroff_syscore_ops);
+   return 0;
+}
+
+static struct platform_driver sc27xx_poweroff_driver = {
+   .probe = sc27xx_poweroff_probe,
+   .driver = {
+   .name = "sc27xx-poweroff",
+   },
+};
+builtin_platform_driver(sc27xx_poweroff_driver);
-- 
1.7.9.5

Re: [PATCH v2] mmc: dw_mmc: Fix the DTO timeout overflow calculation for 32-bit systems

[Jisheng Zhang]

On Thu, 22 Feb 2018 16:34:18 +0300 Evgeniy Didin wrote:

> In commit 9d9491a7da2a ("mmc: dw_mmc: Fix the DTO timeout calculation") have 
> been made
> changes which cause multiply overflow for 32-bit systems.
> The broken timeout calculations caused false interrupt latency warnings
> and stacktrace splat (such as below) when accessing the SD Card.
> 
> | Running :  4M-check-reassembly-tcp-cmykw2-rotatew2.out -v0 -w1
> | -  Info: Finished target initialization.
> | mmcblk0: error -110 transferring data, sector 320544, nr 2048, cmd response
> |  0x900, card status 0x0
> | mmc_host mmc0: Bus speed (slot 0) = 5000Hz (slot req 40Hz, actual
> | 396825HZ div = 63)
> | mmc_host mmc0: Bus speed (slot 0) = 5000Hz (slot req 2500Hz, actual
> |  2500HZ div = 1)
> | [ cut here ]
> | softirq: huh, entered softirq 6 TASKLET 6f6a9412 with preempt_count 
> 0101,
> | exited with 0100?
> | WARNING: CPU: 2 PID: 0 at ../lib/scatterlist.c:652 sg_miter_next+0x28/0x20c
> | Modules linked in:
> | CPU: 2 PID: 0 Comm: swapper/2 Not tainted 4.15.0 #57
> |
> | Stack Trace:
> |  arc_unwind_core.constprop.1+0xd0/0xf4
> |  dump_stack+0x68/0x80
> |  warn_slowpath_null+0x4e/0xec
> |  sg_miter_next+0x28/0x20c
> |  dw_mci_read_data_pio+0x44/0x190
> |  dw_mmc f000a000.mmc: Unexpected interrupt latency
> |   dw_mci_interrupt+0x3ee/0x530
> |  __handle_irq_event_percpu+0x56/0x150
> |  handle_irq_event+0x34/0x78
> |  handle_level_irq+0x8e/0x120
> |  generic_handle_irq+0x1c/0x2c
> |  idu_cascade_isr+0x30/0x6c
> |  __handle_domain_irq+0x72/0xc8
> |  ret_from_exception+0x0/0x8
> |---[ end trace 2a58c9af6c25fe51 ]---
> 
> Lets cast this multiply to u64 type which prevents overflow.
> 
> Tested-by: Vineet Gupta 
> Fixes: ARC STAR 9001306872 HSDK, sdio: board crashes when copying big files
> 
> Signed-off-by: Evgeniy Didin 
> 
> CC: Alexey Brodkin 
> CC: Eugeniy Paltsev 
> CC: Douglas Anderson 
> CC: Ulf Hansson 
> CC: linux-kernel@vger.kernel.org
> CC: linux-snps-...@lists.infradead.org
> Cc:  #  9d9491a7da2a mmc: dw_mmc: Fix the DTO timeout 
> calculation
> ---
> Changes since v1:
> -uint64_t switched to u64
> -changed commit message
>  drivers/mmc/host/dw_mmc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
> index 0aa39975f33b..1a0b9751c67c 100644
> --- a/drivers/mmc/host/dw_mmc.c
> +++ b/drivers/mmc/host/dw_mmc.c
> @@ -1944,7 +1944,7 @@ static void dw_mci_set_drto(struct dw_mci *host)
>   drto_div = (mci_readl(host, CLKDIV) & 0xff) * 2;
>   if (drto_div == 0)
>   drto_div = 1;
> - drto_ms = DIV_ROUND_UP(MSEC_PER_SEC * drto_clks * drto_div,
> + drto_ms = DIV_ROUND_UP((u64)MSEC_PER_SEC * drto_clks * drto_div,
>  host->bus_hz);

DIV_ROUND_UP_ULL?

>  
>   /* add a bit spare time */

Re: [GIT PULL] SCSI fixes for 4.16-rc2

[James Bottomley]

On Thu, 2018-02-22 at 16:37 -0800, Linus Torvalds wrote:
> On Thu, Feb 22, 2018 at 11:28 AM, James Bottomley
>  wrote:
> > 
> > 
> > git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git scsi-
> > fixes
> 
> When I pull that, I get something completely different from what you
> claim I should get. Much bigger, and a lot more commits.
> 
> Hmm?
> 
> Dropped.

OK, I see the problem, but I don't currently have an explanation for
how it happened.  The scsi-fixes tag somehow became attached to a push
of the misc tree for the next merge window instead of the fixes branch.

I've reset it to where it should be

commit 1bc5ad3a6acdcf56f83272f2de1cd2389ea9e9e2
Author: Manish Rangankar 
Date:   Sun Feb 11 22:48:41 2018 -0800

scsi: qla4xxx: skip error recovery in case of register disconnect.

So it should all be correct if you re-pull.

I suppose it's good that the checks and balances of changelog +
diffstat caught this; I'll poke about in my current preparation scripts
to see if I can find out what went wrong.

James

Re: [PATCH v4 00/16] R-Car DU: Convert LVDS code to bridge driver

[Frank Rowand]

Hi Laurent,

On 02/22/18 02:25, Laurent Pinchart wrote:
> Hi Frank,
> 
> On Thursday, 22 February 2018 08:07:14 EET Frank Rowand wrote:
>> On 02/20/18 15:10, Laurent Pinchart wrote:
>>> Hello,
>>>
>>> This patch series addresses a design mistake that dates back from the
>>> initial DU support. Support for the LVDS encoders, which are IP cores
>>> separate from the DU, was bundled in the DU driver. Worse, both the DU
>>> and LVDS were described through a single DT node.
>>>
>>> To fix the, patches 01/16 and 02/16 define new DT bindings for the LVDS
>>> encoders, and deprecate their description inside the DU bindings. To
>>> retain backward compatibility with existing DT, patches 03/16 to 08/16
>>> then patch the device tree at runtime to convert the legacy bindings to
>>> the new ones.
>>>
>>> With the DT side addressed, patch 09/16 converts the LVDS support code to
>>> a separate bridge driver. Patches 11/16 to 16/16 then update all the
>>> device tree sources to the new DU and LVDS encoders bindings.
>>>
>>> I decided to go for live DT patching in patch 08/16 because implementing
>>> support for both the legacy and new bindings in the driver would have been
>>> very intrusive, and prevented further cleanups. This version relies more
>>> heavily on overlays to avoid touching the internals of the OF core
>>> compared to v2, even if manual fixes to the device tree are still needed.
>>>
>>> Compared to v3, this series uses the OF changeset API to update properties
>>> instead of accessing the internals of the property structure. This removes
>>> the local implementation of functions to look up nodes by path and update
>>> properties. In order to do this, I pulled in Pantelis' patch series
>>> titled "[PATCH v2 0/5] of: dynamic: Changesets helpers & fixes" at Rob's
>>> request, and rebased it while taking two small review comments into
>>> account.
>>
>> Wait a minute!  Why are you putting a patch set to modify core devicetree
>> in the middle of a driver series.  Please pull it out to a separate series.
> 
> Because Rob asked for the driver-local implementation of the property add 
> function to be replaced by Pantelis' series. I want to get the LVDS changes 
> in 
> v4.17 and asked Rob whether I could then take the OF changeset patches merged 
> through the DRM tree, and he didn't object. If that causes an issue I'll 
> switch back to the driver-local implementation to get the driver changes 
> merged, split the OF changeset series out, and then move to the OF changeset 
> API once merged. Would you prefer that ?

You have already created a new version of the R-Car patches without the
set of patches that I was objecting to here.  So this is somewhat just
an academic comment.

As I mentioned in the v6 thread, I am coming back here to clean up loose
ends, and explain why I had the reaction I had.  Basically, this is a
process issue to me.

(1) The patch set from Pantelis is "hidden" in the driver patch series.
When viewing collapsed threads (which is my normal mode to avoid getting
overwhelmed by the vast volume of email I scan), the Pantelis patch set
is totally invisible.  If the R-Car driver patch series had not had me
on the to: list, there is a very good chance I would not have noticed
it.  Or noticed in a more delayed time frame.  And the same applies to
anyone else who might be subscribed to the devicetree mail list.  If
the Pantelis patch series was split out into a separate patch set then
it would be more visible on the list.

(2) There is no good way to indicate in the email subject lines for
the Pantelis patches that they are version 3 of the series, since
they are also version 4 of the R-Car patch series.  If one reads the
patch 0/0 header carefully, and/or the other Pantelis patch comment
headers carefully, and then does a little detective work, it is
possible to find version 2 of the Pantelis patch series, and thus
be able to track the full history.  If just glancing at each
individual patch email subject, scanning the patch comment, and
spending more time reading the body of the patch, it would be
very easy to overlook the existence of the previous versions on
the mail list.

(2b) Small quibble:  if the Pantelis patches were in a separate series,
with v3 in the subject header, then you would have normally put
a "changes since v2" section in the patch comment header, which would
have been more visible and less cryptic than what you wrote, which was:

   ...

   Signed-off-by: Pantelis Antoniou 
   [Fixed memory leak in __of_changeset_add_update_property_copy()]
   Signed-off-by: Laurent Pinchart 
   ---
drivers/of/dynamic.c | 222 ++
include/linux/of.h   | 328 
+++
2 files changed, 550 insertions(+)

My original scan of version 2 and then the email in this series had me
questioning whether the two open issues from patch 2 had been addressed
(yes, patch 0/16 did explicitly mention that 2 review comments had 

Re: [PATCH v2 0/3] Directed kmem charging

[Christopher Lameter]

On Wed, 21 Feb 2018, Andrew Morton wrote:

> What do others think?

I think the changes to the hotpaths of the slab allocators increasing
register pressure in some of the hotttest paths of the kernel are
problematic.

Its better to do the allocation properly in the task context to which it
is finally charged. There may be other restrictions that emerge from other
fields in the task_struct that also may influence allocation and reclaim
behavior. It is cleanest to do this in the proper task context instead of
taking a piece (like the cgroup) out of context.

Re: [PATCH v2 4/6] fs/dcache: Avoid the try_lock loops in dentry_kill()

[Al Viro]

On Fri, Feb 23, 2018 at 03:12:14AM +, Al Viro wrote:

>   /* retain_dentry() needs ->count == 1 already checked)

... obviously not even compile-tested ;-)

Re: [PATCH v2 0/3] Directed kmem charging

[Christopher Lameter]

On Thu, 22 Feb 2018, Jan Kara wrote:

> I don't see how task work can be used here. Firstly I don't know of a case
> where task work would be used for something else than the current task -
> and that is substantial because otherwise you have to deal with lots of
> problems like races with task exit, when work gets executed (normally it
> gets executed once task exits to userspace) etc. Or do you mean that you'd
> queue task work for current task and then somehow magically switch memcg
> there? In that case this magic switching isn't clear to me...

Thats surprising since one can specify the task. If its only for current
then why do you need a parameter?

I think a capability of executing a function in the context of another
running task could simplify a lot. In particular if something triggers
behavior that is related to another task from the kernel like whats
happening here.

It should not be that difficult to do proper synchronization on the list
of work and then set some flag (maybe SIGPENDING) to make the task execute
whats on the tasklist. Signal delivery is after all similar.