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

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();
- 

[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

[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 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 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;
> + 

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: [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, >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  vb2_queue with videobuf2 queue.
> + * @b:   buffer structure passed from userspace to
> + *   _ioctl_ops->vidioc_qbuf handler in driver
> + * @entity:  request entity to queue for if requests are used.
> + *
> + * Should be called from _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 

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, >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  vb2_queue with videobuf2 queue.
> + * @b:   buffer structure passed from userspace to
> + *   _ioctl_ops->vidioc_qbuf handler in driver
> + * @entity:  request entity to queue for if requests are used.
> + *
> + * Should be called from _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 

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: [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: 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: [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(_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
> + * 

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(_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

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, >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  vb2_queue with videobuf2 queue.
 + * @b:   buffer structure passed from userspace to
 + *   _ioctl_ops->vidioc_qbuf handler in driver
 + * @entity:  request entity to queue for if requests are used.
 + *
 + * Should be called from _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.

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  

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, >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  vb2_queue with videobuf2 queue.
 + * @b:   buffer structure passed from userspace to
 + *   _ioctl_ops->vidioc_qbuf handler in driver
 + * @entity:  request entity to queue for if requests are used.
 + *
 + * Should be called from _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 regards,
Tomasz

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  

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 = < 12 0 1>,
-   < 13 0 1 0>;
+   < 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 = <>;
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 = < 7 0>, < 0>, < 1>;
+   cs-gpios = < 7 0>, < 0 0>, < 
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 = < 0x600 0 0 1>, /* 0xC << 11 */
-   < 0x680 0 1 0>; /* 0xD << 7 */
+   dmas = < 12 0 1>,
+   < 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 = < 0 0 0 0>;
+   dmas = < 0 0 0>;
dma-names = "data";
};
 
@@ -288,8 +288,8 @@
#size-cells = <0>;
interrupts = <0 31 0x4>;
status = "disabled";
-   dmas = < 0x2000 0 0 0>, /* 0x4 << 11 */
-   < 0x0280 0 0 0>;  /* 0x5 << 7 */
+   dmas = < 4 0 0>,
+   < 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 = <>;
interrupts = <10>;
status = "disabled";
};
diff --git a/arch/arm/boot/dts/stih407.dtsi b/arch/arm/boot/dts/stih407.dtsi
index 

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 
 

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 
 

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 = < 12 0 1>,
-   < 13 0 1 0>;
+   < 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 = <>;
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 = < 7 0>, < 0>, < 1>;
+   cs-gpios = < 7 0>, < 0 0>, < 
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 = < 0x600 0 0 1>, /* 0xC << 11 */
-   < 0x680 0 1 0>; /* 0xD << 7 */
+   dmas = < 12 0 1>,
+   < 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 = < 0 0 0 0>;
+   dmas = < 0 0 0>;
dma-names = "data";
};
 
@@ -288,8 +288,8 @@
#size-cells = <0>;
interrupts = <0 31 0x4>;
status = "disabled";
-   dmas = < 0x2000 0 0 0>, /* 0x4 << 11 */
-   < 0x0280 0 0 0>;  /* 0x5 << 7 */
+   dmas = < 4 0 0>,
+   < 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 = <>;
interrupts = <10>;
status = "disabled";
};
diff --git a/arch/arm/boot/dts/stih407.dtsi b/arch/arm/boot/dts/stih407.dtsi
index 

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 = < 12 0 1>,
-   < 13 0 1 0>;
+   < 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>;
 };
 
- {
-   interrupt-parent = <>;
-   interrupts = <0  IRQ_TYPE_LEVEL_HIGH>;
-};
-
  {
interrupt-parent = <>;
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 @@
  {
clocks = < CLK_RTC>;
clock-names = "rtc";
-   interrupt-parent = <_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 = < 0x59 0>;
-   reset-gpio = < 0x51 0>;
+   power-gpio = < 3 10 0>;
+   reset-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 = < 0x59 0>;
-   reset-gpio = < 0x51 0>;
+   power-gpio = < 3 10 0>;
+   reset-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 = <>;
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 {
status = "okay";
num-cs = <3>;
-   

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 = < 12 0 1>,
-   < 13 0 1 0>;
+   < 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>;
 };
 
- {
-   interrupt-parent = <>;
-   interrupts = <0  IRQ_TYPE_LEVEL_HIGH>;
-};
-
  {
interrupt-parent = <>;
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 @@
  {
clocks = < CLK_RTC>;
clock-names = "rtc";
-   interrupt-parent = <_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 = < 0x59 0>;
-   reset-gpio = < 0x51 0>;
+   power-gpio = < 3 10 0>;
+   reset-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 = < 0x59 0>;
-   reset-gpio = < 0x51 0>;
+   power-gpio = < 3 10 0>;
+   reset-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 = <>;
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 {
status = "okay";
num-cs = <3>;
-   

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):
  

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):
  

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 = >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: [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 = >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.

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 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 */

[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(>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(>mmap_sem);
}
 

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(>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(>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 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;
 }

[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;
 }

[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: [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

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, >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  vb2_queue with videobuf2 queue.
>>> + * @b:   buffer structure passed from userspace to
>>> + *   _ioctl_ops->vidioc_qbuf handler in driver
>>> + * @entity:  request entity to queue for if requests are used.
>>> + *
>>> + * Should be called from _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

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, >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  vb2_queue with videobuf2 queue.
>>> + * @b:   buffer structure passed from userspace to
>>> + *   _ioctl_ops->vidioc_qbuf handler in driver
>>> + * @entity:  request entity to queue for if requests are used.
>>> + *
>>> + * Should be called from _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(>rdtgroup_list, _all_groups);

[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(>rdtgroup_list, _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(_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]));

[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(_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] 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 <linux...@us.ibm.com>
:: CC: Michael Ellerman <m...@ellerman.id.au>

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


.config.gz
Description: application/gzip

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, , 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] 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, , 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_MOD 812>;
>>  +power-domains = < 32>;
>>  +resets = < 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 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_MOD 812>;
>>  +power-domains = < 32>;
>>  +resets = < 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] 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

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

[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|   |
+ +==+=+===+
+ 

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(_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(>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

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(_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(>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

[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: 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, _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, _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, _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 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, _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, _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, _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(_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",
+   >width, >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

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(_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",
+   >width, >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 @@
 
  {
status = "okay";
-   num-slots = <1>;
cap-sd-highspeed;
broken-cd;
bus-width = <4>;
-- 
2.15.1

[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 @@
 
  {
status = "okay";
-   num-slots = <1>;
cap-sd-highspeed;
broken-cd;
bus-width = <4>;
-- 
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 @@
 
  {
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 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 = <_ctrl HI3660_CLK_GATE_SDIO0>,
 <_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 = < CLK_SDIO>, < CLK_CPU_SDIO>;
clock-names = "ciu", "biu";
resets = < 20>;
-- 
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 = <_ctrl HI3660_CLK_GATE_SDIO0>,
 <_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 = < CLK_SDIO>, < CLK_CPU_SDIO>;
clock-names = "ciu", "biu";
resets = < 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 @@
 
  {
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