Re: [RFC] dt-bindings: mailbox: add doorbell support to ARM MHU

[Viresh Kumar]

On 03-06-20, 19:17, Sudeep Holla wrote:
> I just realised that we have the timing info in the traces and you will
> observe the sensor readings take something in order of 100us to 500-600us
> or even more based on which sensor is being read. While we have 100us
> timeout for cpufreq opp set.

Which timeout from opp core are you talking about ?

-- 
viresh

Re: Capabilities are list when creating a user namespace

[Idan Yadgar]

Hello, sorry for duplicating the previous email, forgot to send it to
the mailing lists as well.
Did you miss my email?

Idan Yadgar.

On Fri, May 29, 2020 at 5:48 PM Idan Yadgar  wrote:
>
> Hello, did you miss my mail?
>
> בתאריך יום א׳, 24 במאי 2020, 15:32, מאת Idan Yadgar ‏:
>>
>> Hello,
>>
>> A process which changes its user namespace (unshare or setns), or a
>> process that is created by clone with the CLONE_NEWUSER flag has all
>> capabilities inside the new namespace, and loses all its capabilities
>> in the parent/previous user namespace.
>> This poses an issue because some operations require a capability in a
>> user namespace other then the current one for the process. The man
>> states multiple times that a system call requires a capability in the
>> initial user namespace (for example, open_by_handle_at requires
>> CAP_DAC_READ_SEARCH in the initial user namespace), but this cannot
>> happen unless the process is owned by root, thus preventing
>> open_by_handle_at to be run inside a user namespace.
>>
>> Solving this problem can be done by allowing (via prctl or any other
>> mechanism) a task to save its
>> capabilities for a given user namespace, even when it isn't a member
>> in that namespace.
>>
>> We would like to hear some thoughts about this issue and our proposed 
>> solution.

Re: [mainline][Oops][bisected 2ba3e6 ] 5.7.0 boot fails with kernel panic on powerpc

[Abdul Haleem]

On Wed, 2020-06-03 at 15:32 +0200, Joerg Roedel wrote:
> On Wed, Jun 03, 2020 at 04:20:57PM +0530, Abdul Haleem wrote:
> > @Joerg, Could you please have a look?
> 
> Can you please try the attached patch?

Thanks Joerg, The given patch fixes the boot problem.

Please add Reported-by in fix commit.

Reported-by: Abdul Haleem 

> 
> diff --git a/include/asm-generic/5level-fixup.h 
> b/include/asm-generic/5level-fixup.h
> index 58046ddc08d0..afbab31fbd7e 100644
> --- a/include/asm-generic/5level-fixup.h
> +++ b/include/asm-generic/5level-fixup.h
> @@ -17,6 +17,11 @@
>   ((unlikely(pgd_none(*(p4d))) && __pud_alloc(mm, p4d, address)) ? \
>   NULL : pud_offset(p4d, address))
> 
> +#define pud_alloc_track(mm, p4d, address, mask)  
> \
> + ((unlikely(pgd_none(*(p4d))) && 
> \
> +   (__pud_alloc(mm, p4d, address) || 
> ({*(mask)|=PGTBL_P4D_MODIFIED;0;})))?   \
> +   NULL : pud_offset(p4d, address))
> +
>  #define p4d_alloc(mm, pgd, address)  (pgd)
>  #define p4d_alloc_track(mm, pgd, address, mask)  (pgd)
>  #define p4d_offset(pgd, start)   (pgd)
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 7e07f4f490cb..d46bf03b804f 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -2088,35 +2088,35 @@ static inline pud_t *pud_alloc(struct mm_struct *mm, 
> p4d_t *p4d,
>   NULL : pud_offset(p4d, address);
>  }
> 
> -static inline p4d_t *p4d_alloc_track(struct mm_struct *mm, pgd_t *pgd,
> +static inline pud_t *pud_alloc_track(struct mm_struct *mm, p4d_t *p4d,
>unsigned long address,
>pgtbl_mod_mask *mod_mask)
> -
>  {
> - if (unlikely(pgd_none(*pgd))) {
> - if (__p4d_alloc(mm, pgd, address))
> + if (unlikely(p4d_none(*p4d))) {
> + if (__pud_alloc(mm, p4d, address))
>   return NULL;
> - *mod_mask |= PGTBL_PGD_MODIFIED;
> + *mod_mask |= PGTBL_P4D_MODIFIED;
>   }
> 
> - return p4d_offset(pgd, address);
> + return pud_offset(p4d, address);
>  }
> 
> -#endif /* !__ARCH_HAS_5LEVEL_HACK */
> -
> -static inline pud_t *pud_alloc_track(struct mm_struct *mm, p4d_t *p4d,
> +static inline p4d_t *p4d_alloc_track(struct mm_struct *mm, pgd_t *pgd,
>unsigned long address,
>pgtbl_mod_mask *mod_mask)
> +
>  {
> - if (unlikely(p4d_none(*p4d))) {
> - if (__pud_alloc(mm, p4d, address))
> + if (unlikely(pgd_none(*pgd))) {
> + if (__p4d_alloc(mm, pgd, address))
>   return NULL;
> - *mod_mask |= PGTBL_P4D_MODIFIED;
> + *mod_mask |= PGTBL_PGD_MODIFIED;
>   }
> 
> - return pud_offset(p4d, address);
> + return p4d_offset(pgd, address);
>  }
> 
> +#endif /* !__ARCH_HAS_5LEVEL_HACK */
> +
>  static inline pmd_t *pmd_alloc(struct mm_struct *mm, pud_t *pud, unsigned 
> long address)
>  {
>   return (unlikely(pud_none(*pud)) && __pmd_alloc(mm, pud, address))?


-- 
Regard's

Abdul Haleem
IBM Linux Technology Centre

[PATCH -tip v2 1/2] kasan: Bump required compiler version

[Marco Elver]

Adds config variable CC_HAS_WORKING_NOSANITIZE_ADDRESS, which will be
true if we have a compiler that does not fail builds due to
no_sanitize_address functions. This does not yet mean they work as
intended, but for automated build-tests, this is the minimum
requirement.

For example, we require that __always_inline functions used from
no_sanitize_address functions do not generate instrumentation. On GCC <=
7 this fails to build entirely, therefore we make the minimum version
GCC 8.

Link: 
https://lkml.kernel.org/r/20200602175859.gc2...@hirez.programming.kicks-ass.net
Suggested-by: Peter Zijlstra 
Acked-by: Andrey Konovalov 
Reviewed-by: Nick Desaulniers 
Signed-off-by: Marco Elver 
---
Apply after:
https://lkml.kernel.org/r/20200602173103.931412...@infradead.org

v2:
* No longer restrict UBSAN (and KCSAN), since the attributes behave
  differently for different sanitizers. For UBSAN the above case with GCC
  <= 7 actually works fine (no compiler error). So it seems that only
  KASAN is affected by this -- let's limit our restriction to KASAN.
---
 lib/Kconfig.kasan | 4 
 1 file changed, 4 insertions(+)

diff --git a/lib/Kconfig.kasan b/lib/Kconfig.kasan
index 81f5464ea9e1..af0dd09f91e9 100644
--- a/lib/Kconfig.kasan
+++ b/lib/Kconfig.kasan
@@ -15,11 +15,15 @@ config CC_HAS_KASAN_GENERIC
 config CC_HAS_KASAN_SW_TAGS
def_bool $(cc-option, -fsanitize=kernel-hwaddress)
 
+config CC_HAS_WORKING_NOSANITIZE_ADDRESS
+   def_bool !CC_IS_GCC || GCC_VERSION >= 8
+
 config KASAN
bool "KASAN: runtime memory debugger"
depends on (HAVE_ARCH_KASAN && CC_HAS_KASAN_GENERIC) || \
   (HAVE_ARCH_KASAN_SW_TAGS && CC_HAS_KASAN_SW_TAGS)
depends on (SLUB && SYSFS) || (SLAB && !DEBUG_SLAB)
+   depends on CC_HAS_WORKING_NOSANITIZE_ADDRESS
help
  Enables KASAN (KernelAddressSANitizer) - runtime memory debugger,
  designed to find out-of-bounds accesses and use-after-free bugs.
-- 
2.27.0.rc2.251.g90737beb825-goog

[PATCH -tip v2 2/2] compiler_types.h: Add __no_sanitize_{address,undefined} to noinstr

[Marco Elver]

Adds the portable definitions for __no_sanitize_address, and
__no_sanitize_undefined, and subsequently changes noinstr to use the
attributes to disable instrumentation via KASAN or UBSAN.

Link: https://lore.kernel.org/lkml/d2474c05a6c93...@google.com/
Reported-by: syzbot+dc1fa714cb070b184...@syzkaller.appspotmail.com
Acked-by: Miguel Ojeda 
Signed-off-by: Marco Elver 
---

Note: __no_sanitize_coverage (for KCOV) isn't possible right now,
because neither GCC nor Clang support such an attribute. This means
going and changing the compilers again (for Clang it's fine, for GCC,
it'll take a while).

However, it looks like that KCOV_INSTRUMENT := n is currently in all the
right places. Short-term, this should be reasonable.

v2:
* No change.
---
 include/linux/compiler-clang.h | 8 
 include/linux/compiler-gcc.h   | 6 ++
 include/linux/compiler_types.h | 3 ++-
 3 files changed, 16 insertions(+), 1 deletion(-)

diff --git a/include/linux/compiler-clang.h b/include/linux/compiler-clang.h
index 2cb42d8bdedc..c0e4b193b311 100644
--- a/include/linux/compiler-clang.h
+++ b/include/linux/compiler-clang.h
@@ -33,6 +33,14 @@
 #define __no_sanitize_thread
 #endif
 
+#if __has_feature(undefined_behavior_sanitizer)
+/* GCC does not have __SANITIZE_UNDEFINED__ */
+#define __no_sanitize_undefined \
+   __attribute__((no_sanitize("undefined")))
+#else
+#define __no_sanitize_undefined
+#endif
+
 /*
  * Not all versions of clang implement the the type-generic versions
  * of the builtin overflow checkers. Fortunately, clang implements
diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h
index 7dd4e0349ef3..1c74464c80c6 100644
--- a/include/linux/compiler-gcc.h
+++ b/include/linux/compiler-gcc.h
@@ -150,6 +150,12 @@
 #define __no_sanitize_thread
 #endif
 
+#if __has_attribute(__no_sanitize_undefined__)
+#define __no_sanitize_undefined __attribute__((no_sanitize_undefined))
+#else
+#define __no_sanitize_undefined
+#endif
+
 #if GCC_VERSION >= 50100
 #define COMPILER_HAS_GENERIC_BUILTIN_OVERFLOW 1
 #endif
diff --git a/include/linux/compiler_types.h b/include/linux/compiler_types.h
index 02becd21d456..89b8c1ae18a1 100644
--- a/include/linux/compiler_types.h
+++ b/include/linux/compiler_types.h
@@ -198,7 +198,8 @@ struct ftrace_likely_data {
 
 /* Section for code which can't be instrumented at all */
 #define noinstr
\
-   noinline notrace __attribute((__section__(".noinstr.text"))) __no_kcsan
+   noinline notrace __attribute((__section__(".noinstr.text")))\
+   __no_kcsan __no_sanitize_address __no_sanitize_undefined
 
 #endif /* __KERNEL__ */
 
-- 
2.27.0.rc2.251.g90737beb825-goog

Re: [PATCH v6 10/12] mmap locking API: rename mmap_sem to mmap_lock

[Michel Lespinasse]

On Wed, Jun 3, 2020 at 9:35 PM youling 257  wrote:
> I have build error about kernel/sys.c,
>
> kernel/sys.c: In function ‘prctl_set_vma’:
> kernel/sys.c:2392:18: error:
> ‘struct mm_struct’ has no member named ‘mmap_sem’; did you mean
> ‘mmap_base’?
>   2392 |  down_write(>mmap_sem);
>|  ^~~~
>|  mmap_base
> kernel/sys.c:2402:16: error:
> ‘struct mm_struct’ has no member named ‘mmap_sem’; did you mean
> ‘mmap_base’?
>   2402 |  up_write(>mmap_sem);
>|^~~~
>|mmap_base
>
> why not rename kernel/sys.c mmap_sem to mmap_lock?

The proper fix would be to use the mmap locking apis defined in
include/linux/mmap_lock.h instead.

However I would like more information about your report. Did you apply
the series yourself ? If so, what base tree did you apply it onto ? If
not, what tree did you use that already included the series ?

Thanks,

-- 
Michel "Walken" Lespinasse
A program is never fully debugged until the last user dies.

Re: [PATCH] thunderbolt: Improve USB4 config symbol help text

[Mika Westerberg]

Hi,

On Tue, Jun 02, 2020 at 02:28:15PM +0200, Geert Uytterhoeven wrote:
> Fix the spelling of "specification", and add a missing "the" article.
> 
> Fixes: 690ac0d20d4022bb ("thunderbolt: Update Kconfig entries to USB4")

Maybe Fixes tag here is too strong. It is simply fixing a typo :)

I will pick this one up once v5.8-rc1 is released and drop the Fixes tag.

[PATCH 1/1] of: reserved_mem: Fix typo in the too-many-regions message

[Danny Lin]

Minor fix for a missing preposition in the error message that appears
when there are too many reserved memory regions for the allocated array
to store.

Signed-off-by: Danny Lin 
---
 drivers/of/of_reserved_mem.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/of/of_reserved_mem.c b/drivers/of/of_reserved_mem.c
index 1a84bc0d5fa8..e648904347a0 100644
--- a/drivers/of/of_reserved_mem.c
+++ b/drivers/of/of_reserved_mem.c
@@ -54,7 +54,7 @@ void __init fdt_reserved_mem_save_node(unsigned long node, 
const char *uname,
struct reserved_mem *rmem = _mem[reserved_mem_count];
 
if (reserved_mem_count == ARRAY_SIZE(reserved_mem)) {
-   pr_err("not enough space all defined regions.\n");
+   pr_err("not enough space for all defined regions.\n");
return;
}
 
-- 
2.26.2

[v2 PATCH] ASoC: max98390: Fix potential crash during param fw loading

[Steve Lee]

 malformed firmware file can cause out-of-bound access and crash
 during dsm_param bin loading.
  - add MIN/MAX param size to avoid out-of-bound access.
  - read start addr and size of param and check bound.
  - add condition that fw->size > param_size + _PAYLOAD_OFFSET
to confirm enough data.

Signed-off-by: Steve Lee 
---

Change log v2:
* add condtion that param_size + _PAYLOAD_OFFSET is less than fw->size
  to confirm enough data
* remove unintended code

 sound/soc/codecs/max98390.c | 24 
 sound/soc/codecs/max98390.h |  3 ++-
 2 files changed, 22 insertions(+), 5 deletions(-)

diff --git a/sound/soc/codecs/max98390.c b/sound/soc/codecs/max98390.c
index be7cd0aeb6a6..0d63ebfbff2f 100644
--- a/sound/soc/codecs/max98390.c
+++ b/sound/soc/codecs/max98390.c
@@ -754,6 +754,7 @@ static struct snd_soc_dai_driver max98390_dai[] = {
 static int max98390_dsm_init(struct snd_soc_component *component)
 {
int ret;
+   int param_size, param_start_addr;
char filename[128];
const char *vendor, *product;
struct max98390_priv *max98390 =
@@ -780,14 +781,29 @@ static int max98390_dsm_init(struct snd_soc_component 
*component)
dev_dbg(component->dev,
"max98390: param fw size %zd\n",
fw->size);
+   if (fw->size < MAX98390_DSM_PARAM_MIN_SIZE) {
+   dev_err(component->dev,
+   "param fw is invalid.\n");
+   goto err_alloc;
+   }
dsm_param = (char *)fw->data;
+   param_start_addr = (dsm_param[0] & 0xff) | (dsm_param[1] & 0xff) << 8;
+   param_size = (dsm_param[2] & 0xff) | (dsm_param[3] & 0xff) << 8;
+   if (param_size > MAX98390_DSM_PARAM_MAX_SIZE ||
+   param_start_addr < DSM_STBASS_HPF_B0_BYTE0 ||
+   fw->size < param_size + MAX98390_DSM_PAYLOAD_OFFSET) {
+   dev_err(component->dev,
+   "param fw is invalid.\n");
+   goto err_alloc;
+   }
+   regmap_write(max98390->regmap, MAX98390_R203A_AMP_EN, 0x80);
dsm_param += MAX98390_DSM_PAYLOAD_OFFSET;
-   regmap_bulk_write(max98390->regmap, DSM_EQ_BQ1_B0_BYTE0,
-   dsm_param,
-   fw->size - MAX98390_DSM_PAYLOAD_OFFSET);
-   release_firmware(fw);
+   regmap_bulk_write(max98390->regmap, param_start_addr,
+   dsm_param, param_size);
regmap_write(max98390->regmap, MAX98390_R23E1_DSP_GLOBAL_EN, 0x01);
 
+err_alloc:
+   release_firmware(fw);
 err:
return ret;
 }
diff --git a/sound/soc/codecs/max98390.h b/sound/soc/codecs/max98390.h
index f59cb114d957..5f444e7779b0 100644
--- a/sound/soc/codecs/max98390.h
+++ b/sound/soc/codecs/max98390.h
@@ -650,7 +650,8 @@
 
 /* DSM register offset */
 #define MAX98390_DSM_PAYLOAD_OFFSET 16
-#define MAX98390_DSM_PAYLOAD_OFFSET_2 495
+#define MAX98390_DSM_PARAM_MAX_SIZE 770
+#define MAX98390_DSM_PARAM_MIN_SIZE 670
 
 struct max98390_priv {
struct regmap *regmap;
-- 
2.17.1

Re: dmaengine: stm32-mdma: call pm_runtime_put if pm_runtime_get_sync fails

[Markus Elfring]

>>> Calling pm_runtime_get_sync increments the counter even in case of
>>> failure, causing incorrect ref count. Call pm_runtime_put if
>>> pm_runtime_get_sync fails.
>>
>> Is it appropriate to copy a sentence from the change description
>> into the patch subject?
>>
>> How do you think about a wording variant like the following?
>>
>>The PM runtime reference counter is generally incremented by a call of
>>the function “pm_runtime_get_sync”.
>>Thus call the function “pm_runtime_put” also in two error cases
>>to keep the reference counting consistent.
>
> IMHO the important part is "even in case of failure", which you dropped.
> Missing that point was the root cause of the issue being fixed.
> Hence I prefer the original description, FWIW.

Would you like to comment any more of the presented patch review concerns?

Can it make sense to combine any adjustments into a single patch
according to the discussed software transformation pattern?
https://lore.kernel.org/patchwork/project/lkml/list/?submitter=26544=*=engine%3A+stm32=both

Regards,
Markus

Re: [PATCH v3 1/4] fs, net: Standardize on file_receive helper to move fds across processes

[Sargun Dhillon]

On Wed, Jun 03, 2020 at 07:22:57PM -0700, Kees Cook wrote:
> On Thu, Jun 04, 2020 at 03:24:52AM +0200, Christian Brauner wrote:
> > On Tue, Jun 02, 2020 at 06:10:41PM -0700, Sargun Dhillon wrote:
> > > Previously there were two chunks of code where the logic to receive file
> > > descriptors was duplicated in net. The compat version of copying
> > > file descriptors via SCM_RIGHTS did not have logic to update cgroups.
> > > Logic to change the cgroup data was added in:
> > > commit 48a87cc26c13 ("net: netprio: fd passed in SCM_RIGHTS datagram not 
> > > set correctly")
> > > commit d84295067fc7 ("net: net_cls: fd passed in SCM_RIGHTS datagram not 
> > > set correctly")
> > > 
> > > This was not copied to the compat path. This commit fixes that, and thus
> > > should be cherry-picked into stable.
> > > 
> > > This introduces a helper (file_receive) which encapsulates the logic for
> > > handling calling security hooks as well as manipulating cgroup 
> > > information.
> > > This helper can then be used other places in the kernel where file
> > > descriptors are copied between processes
> > > 
> > > I tested cgroup classid setting on both the compat (x32) path, and the
> > > native path to ensure that when moving the file descriptor the classid
> > > is set.
> > > 
> > > Signed-off-by: Sargun Dhillon 
> > > Suggested-by: Kees Cook 
> > > Cc: Al Viro 
> > > Cc: Christian Brauner 
> > > Cc: Daniel Wagner 
> > > Cc: David S. Miller 
> > > Cc: Jann Horn ,
> > > Cc: John Fastabend 
> > > Cc: Tejun Heo 
> > > Cc: Tycho Andersen 
> > > Cc: sta...@vger.kernel.org
> > > Cc: cgro...@vger.kernel.org
> > > Cc: linux-fsde...@vger.kernel.org
> > > Cc: linux-kernel@vger.kernel.org
> > > ---
> > >  fs/file.c| 35 +++
> > >  include/linux/file.h |  1 +
> > >  net/compat.c | 10 +-
> > >  net/core/scm.c   | 14 --
> > >  4 files changed, 45 insertions(+), 15 deletions(-)
> > > 
> > > diff --git a/fs/file.c b/fs/file.c
> > > index abb8b7081d7a..5afd76fca8c2 100644
> > > --- a/fs/file.c
> > > +++ b/fs/file.c
> > > @@ -18,6 +18,9 @@
> > >  #include 
> > >  #include 
> > >  #include 
> > > +#include 
> > > +#include 
> > > +#include 
> > >  
> > >  unsigned int sysctl_nr_open __read_mostly = 1024*1024;
> > >  unsigned int sysctl_nr_open_min = BITS_PER_LONG;
> > > @@ -931,6 +934,38 @@ int replace_fd(unsigned fd, struct file *file, 
> > > unsigned flags)
> > >   return err;
> > >  }
> > >  
> > > +/*
> > > + * File Receive - Receive a file from another process
> > > + *
> > > + * This function is designed to receive files from other tasks. It 
> > > encapsulates
> > > + * logic around security and cgroups. The file descriptor provided must 
> > > be a
> > > + * freshly allocated (unused) file descriptor.
> > > + *
> > > + * This helper does not consume a reference to the file, so the caller 
> > > must put
> > > + * their reference.
> > > + *
> > > + * Returns 0 upon success.
> > > + */
> > > +int file_receive(int fd, struct file *file)
> > 
> > This is all just a remote version of fd_install(), yet it deviates from
> > fd_install()'s semantics and naming. That's not great imho. What about
> > naming this something like:
> > 
> > fd_install_received()
> > 
> > and move the get_file() out of there so it has the same semantics as
> > fd_install(). It seems rather dangerous to have a function like
> > fd_install() that consumes a reference once it returned and another
> > version of this that is basically the same thing but doesn't consume a
> > reference because it takes its own. Seems an invitation for confusion.
> > Does that make sense?
> 
> We have some competing opinions on this, I guess. What I really don't
> like is the copy/pasting of the get_unused_fd_flags() and
> put_unused_fd() needed by (nearly) all the callers. If it's a helper, it
> should help. Specifically, I'd like to see this:
> 
> int file_receive(int fd, unsigned long flags, struct file *file,
>int __user *fdptr)
> {
>   struct socket *sock;
>   int err;
> 
>   err = security_file_receive(file);
>   if (err)
>   return err;
> 
>   if (fd < 0) {
>   /* Install new fd. */
>   int new_fd;
> 
>   err = get_unused_fd_flags(flags);
>   if (err < 0)
>   return err;
>   new_fd = err;
> 
>   /* Copy fd to any waiting user memory. */
>   if (fdptr) {
>   err = put_user(new_fd, fdptr);
>   if (err < 0) {
>   put_unused_fd(new_fd);
>   return err;
>   }
>   }
>   fd_install(new_fd, get_file(file));
>   fd = new_fd;
>   } else {
>   /* Replace existing fd. */
>   err = replace_fd(fd, file, flags);
>   if (err)
>   return err;
>   }
> 
>   

Re: [PATCH] drm/sun4i: hdmi ddc clk: Fix size of m divider

[Chen-Yu Tsai]

On Wed, Apr 22, 2020 at 5:23 PM Maxime Ripard  wrote:
>
> Hi,
>
> On Wed, Apr 15, 2020 at 07:52:28PM +0200, Jernej Škrabec wrote:
> > Dne sreda, 15. april 2020 ob 12:42:14 CEST je Maxime Ripard napisal(a):
> > > On Mon, Apr 13, 2020 at 06:09:08PM +0200, Jernej Škrabec wrote:
> > > > Dne ponedeljek, 13. april 2020 ob 16:12:39 CEST je Chen-Yu Tsai
> > napisal(a):
> > > > > On Mon, Apr 13, 2020 at 6:11 PM Chen-Yu Tsai  wrote:
> > > > > > On Mon, Apr 13, 2020 at 5:55 PM Jernej Skrabec
> > > > > > 
> > > >
> > > > wrote:
> > > > > > > m divider in DDC clock register is 4 bits wide. Fix that.
> > > > > > >
> > > > > > > Fixes: 9c5681011a0c ("drm/sun4i: Add HDMI support")
> > > > > > > Signed-off-by: Jernej Skrabec 
> > > > > >
> > > > > > Reviewed-by: Chen-Yu Tsai 
> > > > >
> > > > > Cc stable?
> > > >
> > > > I don't think it's necessary:
> > > > 1. It doesn't change much (anything?) for me when reading EDID. I don't
> > > > think it's super important to have precise DDC clock in order to 
> > > > properly
> > > > read EDID. 2. No matter if it has "Cc stable" tag or not, it will be
> > > > eventually picked for stable due to fixes tag.
> > > >
> > > > This was only small observation when I was researching EDID readout 
> > > > issue
> > > > on A20 board, but sadly, I wasn't able to figure out why reading it
> > > > sometimes fails. I noticed similar issue on SoCs with DE2 (most
> > > > prominently on OrangePi PC2 - H5), but there was easy workaround - I 
> > > > just
> > > > disabled video driver in U- Boot. However, if A20 display driver gets
> > > > disabled in U-Boot, it totally breaks video output on my TV when Linux
> > > > boots (no output). I guess there is more fundamental problem with clocks
> > > > than just field size. I think we should add more constraints in clock
> > > > driver, like preset some clock parents and not allow to change parents
> > > > when setting rate, but carefully, so simplefb doesn't break. Such
> > > > constraints should also solve problems with dual head setups.
> > > I disagree here. Doing all sorts of special case just doesn't scale,
> > > and we'll never have the special cases sorted out on all the boards
> > > (and it's a nightmare to maintain).
> > >
> > > Especially since it's basically putting a blanket over the actual
> > > issue and looking the other way. If there's something wrong with how
> > > we deal with (re)parenting, we should fix that. It impacts more than
> > > just DRM, and all the SoCs.
> >
> > I agree with you that automatic solution would be best, but I just don't see
> > it how it would be done.
>
> > Dual head display pipeline is pretty complex for clock driver to get it 
> > right
> > on it's own. There are different possible setups and some of them are hot
> > pluggable, like HDMI.
>
> Do you have an actual scenario that is broken right now?
>
> > And there are also SoC specific quirks, like A64, where for some reason, 
> > MIPI
> > DPHY and HDMI PHY share same clock parent - PLL_VIDEO0. Technically, MIPI 
> > DPHY
> > can be clocked from PLL_PERIPH0 (fixed to 600 MHz), but that's not really
> > helpful. I'm not even sure if there is any good solution to this - certainly
> > HDMI and MIPI can't claim exclusivity and somehow best common rate must be
> > found for PLL_VIDEO0, if that's even possible.
>
> IIRC the DSI DPHY needs a clock running at 297MHz, which is pretty much what 
> the
> HDMI PHY should need too (or 148.5, but that's pretty easy to generate from
> 297). So which problem do we have there?
>
> > I was sure that HDMI PHY on A64 can be clocked from PLL_VIDEO1, which would
> > solve main issue, but to date, I didn't find any way to do that.
> >
> > That's pretty off topic, so I hope original patch can be merged as-is.
>
> It does, sorry
>
> Acked-by: Maxime Ripard 

Looks like this hasn't landed yet.

ChenYu

★ smdbobbin --“2018世界复合材料展览及会议”将于“3月”在“法国巴黎”举行 （地右P1-L-Me）

[linux-kernel-owner]

尊敬的 smdbobbin@126.comhttp 企业领导/公司负责人/业界专家，您好：
　　
　　
新材料为21世纪三大共性关键技术之一，已成为全球经济迅速增长的源动力和提升核心竞争力的战略焦点。材料作为制造业的基础，特别是新材料研究和产业发展的水平与规模，已经成为衡量一个国家科技进步和综合实力的重要标志。在新材料发展与应用中，复合材料占有相当重要的地位，特别广泛的应用在汽车、交通、风能、航空、航天、兵器、船舶、国防、机械、电子、化工、建筑、农业、渔业、纺织、运动器材等领域，一直是世界各国优先发展和竞争激烈的重要行业。
　　
　　“JEC世界复合材料展览及会议”（JEC world Composites Show & 
Conferences）创办于1963年，每年举办一届，至2017年总共举办了52届，主办单位是法国JEC复合材料发展促进会/JEC集团，中国总展团展商组织单位为映德国际会展集团中国代表处，在北京、上海等地设有分支机构，负责该展会在中国的推广和招商工作（JEC中国总展团报名热线：4000-680-860转8144、5220）。JEC复合材料展已成为世界上历史最悠久、规模最大的复合材料行业专业展览会，展示和反映了当前复合材料行业的最新技术和应用成果。
　　
　　为了增进国内外复合材料行业的交流与合作，同时展示我国复合材料产业的发展与成就，帮助境内企业开拓国内外市场，中国国际复材协会、映德国际会展集团（YOND 
EXPO）中国代表处已近十年组织中国企业参与该展会，为中国复合材料集团、中材科技、中钢集团、中国建材集团、中国商飞、北京玻钢院、上海杰事杰新材料集团、重庆国际复合材料、中南控股集团、秦皇岛耀华玻璃钢、烟台氨纶、天马集团、华东理工大学、哈尔滨工业大学、巨石集团、中冶集团、金光集团、江苏恒神纤维材料、重庆大学、上海玻璃钢研究院、中南大学、哈尔滨玻璃钢研究院等众多行业巨头和知名机构提供了优质高效的境外展贸服务。
　　
　　“JEC world 2018 
第五十三世界复合材料展览及会议”将于“3月06-08日”在“法国巴黎展览会议中心”再度举行，我们诚邀全国各地复合材料及新材料相关单位与业界人士加入咱们的中国总展团前往参展参观。
　　
　　
　　有关参展参观“JEC世界复合材料展”事宜，请联络【中国总展团】组办方—— 
全国统一客服热线：4000-580-850（转5220、8144、）、010—6923-6944； 邮箱/QQ：12809395#qq.com； 
微信： CanZhanXiaoXi（参展消息）、ZhanShangZhiJia（展商之家）； 
微博：http://weibo.com/jecshow（展会）、http://weibo.com/yingdehuizhan（公司）。
　　
　　参加JEC展会是一个复合材料及新材料企业走向国际化的标志和途径！
　　
　　
　　
　　
__
　　
（百万群发系统|为您发送|如不希望再收到此行业资讯|请回复“TD+JEC”至邮箱1055800...@qq.com）

RE: [EXT] Re: [PATCH v6 2/2] arm64/crash_core: Export TCR_EL1.T1SZ in vmcoreinfo

[Kamlakant Patel]

Hi Bhupesh,

> -Original Message-
> From: Bhupesh Sharma 
> Sent: Thursday, June 4, 2020 2:05 AM
> To: Kamlakant Patel 
> Cc: linux-arm-ker...@lists.infradead.org; x...@kernel.org; Mark Rutland
> ; Kazuhito Hagio ; Steve
> Capper ; Catalin Marinas
> ; Ard Biesheuvel ;
> ke...@lists.infradead.org; linux-kernel@vger.kernel.org; James Morse
> ; Dave Anderson ;
> bhupesh.li...@gmail.com; Will Deacon ; Ganapatrao Kulkarni
> 
> Subject: [EXT] Re: [PATCH v6 2/2] arm64/crash_core: Export TCR_EL1.T1SZ in
> vmcoreinfo
> 
> External Email
> 
> --
> Hi Kamlakant,
> 
> Many thanks for having a look at the patchset.
> 
> On Wed, Jun 3, 2020 at 4:50 PM Kamlakant Patel 
> wrote:
> >
> > Hi Bhupesh,
> >
> > > -Original Message-
> > > From: kexec  On Behalf Of Bhupesh
> > > Sharma
> > > Sent: Thursday, May 14, 2020 12:23 AM
> > > To: linux-arm-ker...@lists.infradead.org; x...@kernel.org
> > > Cc: Mark Rutland ; Kazuhito Hagio  > > ha...@ab.jp.nec.com>; Steve Capper ; Catalin
> > > Marinas ; bhsha...@redhat.com; Ard
> > > Biesheuvel ; ke...@lists.infradead.org;
> > > linux- ker...@vger.kernel.org; James Morse ;
> > > Dave Anderson ; bhupesh.li...@gmail.com; Will
> > > Deacon 
> > > Subject: [PATCH v6 2/2] arm64/crash_core: Export TCR_EL1.T1SZ in
> > > vmcoreinfo
> > >
> > > vabits_actual variable on arm64 indicates the actual VA space size,
> > > and allows a single binary to support both 48-bit and 52-bit VA spaces.
> > >
> > > If the ARMv8.2-LVA optional feature is present, and we are running
> > > with a 64KB page size; then it is possible to use 52-bits of address
> > > space for both userspace and kernel addresses. However, any kernel
> > > binary that supports 52-bit must also be able to fall back to 48-bit
> > > at early boot time if the hardware feature is not present.
> > >
> > > Since TCR_EL1.T1SZ indicates the size offset of the memory region
> > > addressed by
> > > TTBR1_EL1 (and hence can be used for determining the vabits_actual
> > > value) it makes more sense to export the same in vmcoreinfo rather
> > > than vabits_actual variable, as the name of the variable can change
> > > in future kernel versions, but the architectural constructs like
> > > TCR_EL1.T1SZ can be used better to indicate intended specific fields to 
> > > user-
> space.
> > >
> > > User-space utilities like makedumpfile and crash-utility, need to
> > > read this value from vmcoreinfo for determining if a virtual address lies 
> > > in the
> linear map range.
> > >
> > > While at it also add documentation for TCR_EL1.T1SZ variable being
> > > added to vmcoreinfo.
> > >
> > > It indicates the size offset of the memory region addressed by
> > > TTBR1_EL1
> > >
> > > Cc: James Morse 
> > > Cc: Mark Rutland 
> > > Cc: Will Deacon 
> > > Cc: Steve Capper 
> > > Cc: Catalin Marinas 
> > > Cc: Ard Biesheuvel 
> > > Cc: Dave Anderson 
> > > Cc: Kazuhito Hagio 
> > > Cc: linux-arm-ker...@lists.infradead.org
> > > Cc: linux-kernel@vger.kernel.org
> > > Cc: ke...@lists.infradead.org
> > > Tested-by: John Donnelly 
> > > Signed-off-by: Bhupesh Sharma 
> > > ---
> > >  Documentation/admin-guide/kdump/vmcoreinfo.rst | 11 +++
> > >  arch/arm64/include/asm/pgtable-hwdef.h |  1 +
> > >  arch/arm64/kernel/crash_core.c | 10 ++
> > >  3 files changed, 22 insertions(+)
> > >
> > > diff --git a/Documentation/admin-guide/kdump/vmcoreinfo.rst
> > > b/Documentation/admin-guide/kdump/vmcoreinfo.rst
> > > index 2a632020f809..2baad0bfb09d 100644
> > > --- a/Documentation/admin-guide/kdump/vmcoreinfo.rst
> > > +++ b/Documentation/admin-guide/kdump/vmcoreinfo.rst
> > > @@ -404,6 +404,17 @@ KERNELPACMASK
> > >  The mask to extract the Pointer Authentication Code from a kernel
> > > virtual address.
> > >
> > > +TCR_EL1.T1SZ
> > > +
> > > +
> > > +Indicates the size offset of the memory region addressed by TTBR1_EL1.
> > > +The region size is 2^(64-T1SZ) bytes.
> > > +
> > > +TTBR1_EL1 is the table base address register specified by ARMv8-A
> > > +architecture which is used to lookup the page-tables for the
> > > +Virtual addresses in the higher VA range (refer to ARMv8 ARM
> > > +document for more details).
> > > +
> > >  arm
> > >  ===
> > >
> > > diff --git a/arch/arm64/include/asm/pgtable-hwdef.h
> > > b/arch/arm64/include/asm/pgtable-hwdef.h
> > > index 6bf5e650da78..a1861af97ac9 100644
> > > --- a/arch/arm64/include/asm/pgtable-hwdef.h
> > > +++ b/arch/arm64/include/asm/pgtable-hwdef.h
> > > @@ -216,6 +216,7 @@
> > >  #define TCR_TxSZ(x)  (TCR_T0SZ(x) | TCR_T1SZ(x))
> > >  #define TCR_TxSZ_WIDTH   6
> > >  #define TCR_T0SZ_MASK(((UL(1) << TCR_TxSZ_WIDTH) - 1) <<
> > > TCR_T0SZ_OFFSET)
> > > +#define TCR_T1SZ_MASK(((UL(1) << TCR_TxSZ_WIDTH) - 1) <<
> > > TCR_T1SZ_OFFSET)
> > >
> > >  #define TCR_EPD0_SHIFT   7
> > >  #define TCR_EPD0_MASK(UL(1) << 

[PATCH] soc: amlogic: meson-gx-socinfo: Fix S905X3 ID

[Christian Hewitt]

The current value is taken from Amlogic's 4.9 bsp kernel which appears
to use the wrong ID. For comparison, here's before/after:

[0.152237] soc soc0: Amlogic Meson SM1 (Unknown) Revision 2b:c (10:2) 
Detected
[0.152463] soc soc0: Amlogic Meson SM1 (S905X3) Revision 2b:c (10:2) 
Detected

Fixes c9cc9bec36d0 ("soc: amlogic: meson-gx-socinfo: Add SM1 and S905X3 IDs")
Signed-off-by: Christian Hewitt 
---
 drivers/soc/amlogic/meson-gx-socinfo.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/soc/amlogic/meson-gx-socinfo.c 
b/drivers/soc/amlogic/meson-gx-socinfo.c
index 01fc0d20a70d..c38a1e4db28b 100644
--- a/drivers/soc/amlogic/meson-gx-socinfo.c
+++ b/drivers/soc/amlogic/meson-gx-socinfo.c
@@ -68,7 +68,7 @@ static const struct meson_gx_package_id {
{ "S905X2", 0x28, 0x40, 0xf0 },
{ "S922X", 0x29, 0x40, 0xf0 },
{ "A311D", 0x29, 0x10, 0xf0 },
-   { "S905X3", 0x2b, 0x5, 0xf },
+   { "S905X3", 0x2b, 0x10, 0xf0 },
{ "S905D3", 0x2b, 0xb0, 0xf0 },
{ "A113L", 0x2c, 0x0, 0xf8 },
 };
-- 
2.17.1

Re: [PATCH] net/mlx5: DR, Fix freeing in dr_create_rc_qp()

[Saeed Mahameed]

On Mon, 2020-06-01 at 19:45 +0300, Denis Efremov wrote:
> Variable "in" in dr_create_rc_qp() is allocated with kvzalloc() and
> should be freed with kvfree().
> 
> Fixes: 297cccebdc5a ("net/mlx5: DR, Expose an internal API to issue
> RDMA operations")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Denis Efremov 
> 

Applied to net-mlx5,
Thanks,
Saeed.

Re: [Question]: about 'cpuinfo_cur_freq' shown in sysfs when the CPU is in idle state

[Viresh Kumar]

On 04-06-20, 09:32, Xiongfeng Wang wrote:
> On 2020/6/3 21:39, Rafael J. Wysocki wrote:
> > The frequency value obtained by kicking the CPU out of idle
> > artificially is bogus, though.  You may as well return a random number
> > instead.
> 
> Yes, it may return a randowm number as well.
> 
> > 
> > The frequency of a CPU in an idle state is in fact unknown in the case
> > at hand, so returning 0 looks like the cleanest option to me.
> 
> I am not sure about how the user will use 'cpuinfo_cur_freq' in sysfs. If I
> return 0 when the CPU is idle, when I run a light load on the CPU, I will get 
> a
> zero value for 'cpuinfo_cur_freq' when the CPU is idle. When the CPU is not
> idle, I will get a non-zero value. The user may feel odd about
> 'cpuinfo_cur_frreq' switching between a zero value and a non-zero value. They
> may hope it can return the frequency when the CPU execute instructions, namely
> in C0 state. I am not so sure about the user will look at 'cpuinfo_cur_freq'.

This is what I was worried about as well. The interface to sysfs needs
to be robust. Returning frequency on some readings and 0 on others
doesn't look right to me as well. This will break scripts (I am not
sure if some scripts are there to look for these values) with the
randomness of values returned by it.

On reading values locally from the CPU, I thought about the case where
userspace can prevent a CPU going into idle just by reading its
frequency from sysfs (and so waste power), but the same can be done by
userspace to run arbitrary load on the CPUs.

Can we do some sort of caching of the last frequency the CPU was
running at before going into idle ? Then we can just check if cpu is
idle and so return cached value.

-- 
viresh

Re: [PATCH V2] dt-bindings: clock: Convert imx7ulp clock to json-schema

[Stephen Boyd]

Quoting Anson Huang (2020-06-03 18:33:07)
> Convert the i.MX7ULP clock binding to DT schema format using json-schema,
> the original binding doc is actually for two clock modules(SCG and PCC),
> so split it to two binding docs, and the MPLL(mipi PLL) is NOT supposed
> to be in clock module, so remove it from binding doc as well.
> 
> Signed-off-by: Anson Huang 
> ---

Reviewed-by: Stephen Boyd 

Re: [PATCH] x86/umip: Add emulation/spoofing for SLDT and STR instructions

[Andy Lutomirski]

On Wed, Jun 3, 2020 at 5:12 PM Ricardo Neri
 wrote:
>
> On Tue, Jun 02, 2020 at 11:42:12AM -0700, Brendan Shanks wrote:
> > Add emulation/spoofing of SLDT and STR for both 32- and 64-bit
> > processes.
> >
> > Wine users have found a small number of Windows apps using SLDT that
> > were crashing when run on UMIP-enabled systems.
> >
> > Reported-by: Andreas Rammhold 
> > Originally-by: Ricardo Neri 
> > Signed-off-by: Brendan Shanks 
> > ---
> >  arch/x86/kernel/umip.c | 23 ++-
> >  1 file changed, 14 insertions(+), 9 deletions(-)
> >
> > diff --git a/arch/x86/kernel/umip.c b/arch/x86/kernel/umip.c
> > index 8d5cbe1bbb3b..59dfceac5cc0 100644
> > --- a/arch/x86/kernel/umip.c
> > +++ b/arch/x86/kernel/umip.c
> > @@ -64,6 +64,8 @@
> >  #define UMIP_DUMMY_GDT_BASE 0xfffeULL
> >  #define UMIP_DUMMY_IDT_BASE 0xULL
> >
> > +#define UMIP_DUMMY_TASK_REGISTER_SELECTOR 0x40
> > +
> >  /*
> >   * The SGDT and SIDT instructions store the contents of the global 
> > descriptor
> >   * table and interrupt table registers, respectively. The destination is a
> > @@ -244,16 +246,24 @@ static int emulate_umip_insn(struct insn *insn, int 
> > umip_inst,
> >   *data_size += UMIP_GDT_IDT_LIMIT_SIZE;
> >   memcpy(data, _limit, UMIP_GDT_IDT_LIMIT_SIZE);
> >
> > - } else if (umip_inst == UMIP_INST_SMSW) {
> > - unsigned long dummy_value = CR0_STATE;
> > + } else if (umip_inst == UMIP_INST_SMSW || umip_inst == UMIP_INST_SLDT 
> > ||
> > +umip_inst == UMIP_INST_STR) {
> > + unsigned long dummy_value;
> > +
> > + if (umip_inst == UMIP_INST_SMSW)
> > + dummy_value = CR0_STATE;
> > + else if (umip_inst == UMIP_INST_STR)
> > + dummy_value = UMIP_DUMMY_TASK_REGISTER_SELECTOR;
> > + else
> > + dummy_value = 0;
>
> Perhaps you can return a non-zero value for SLDT if it has an LDT, as
> Andy had suggested. Maybe this can be implemented by looking at
> current->mm->context.ldt
>
> I guess the non-zero value can be (GDT_ENTRY_LDT*8).

You could probably even get away with always returning a nonzero
value.  After all, an empty LDT is quite similar to no LDT.

--Andy

Re: [PATCH 06/10] clk: st: Remove uninitialized_var() usage

[Stephen Boyd]

Quoting Kees Cook (2020-06-03 16:31:59)
> Using uninitialized_var() is dangerous as it papers over real bugs[1]
> (or can in the future), and suppresses unrelated compiler warnings (e.g.
> "unused variable"). If the compiler thinks it is uninitialized, either
> simply initialize the variable or make compiler changes. As a precursor
> to removing[2] this[3] macro[4], just remove this variable since it was
> actually unused:
> 
> drivers/clk/st/clkgen-fsyn.c: In function \u2018quadfs_set_rate\u2019:
> drivers/clk/st/clkgen-fsyn.c:793:6: warning: unused variable \u2018i\u2019 
> [-Wunused-variable]
>   793 |  int i;
>   |  ^
> 
> [1] https://lore.kernel.org/lkml/20200603174714.192027-1-gli...@google.com/
> [2] 
> https://lore.kernel.org/lkml/CA+55aFw+Vbj0i=1tgqcr5vqkczwj0qxk6cernou6eedsuda...@mail.gmail.com/
> [3] 
> https://lore.kernel.org/lkml/ca+55afwgbgqhbp1fkxvrkepzyr5j8n1vkt1vzdz9knmpuxh...@mail.gmail.com/
> [4] 
> https://lore.kernel.org/lkml/CA+55aFz2500WfbKXAx8s67wrm9=yvju65tplgn_ybynv0ve...@mail.gmail.com/
> 
> Signed-off-by: Kees Cook 
> ---

Acked-by: Stephen Boyd 

Re: [PATCH v6 03/14] videobuf2: handle V4L2 buffer cache flags

[Sergey Senozhatsky]

On (20/06/02 14:24), Hans Verkuil wrote:
[..]
> For vim2m (but looks the same for vivid/vimc/vicodec):
> 
> Streaming ioctls:
> test read/write: OK (Not Supported)
> test blocking wait: OK
> Video Capture: Captured 8 buffers
> test MMAP (no poll): OK
> Video Capture: Captured 8 buffers
> test MMAP (select): OK
> Video Capture: Captured 8 buffers
> test MMAP (epoll): OK
> Video Capture: Captured 8 buffers
> test USERPTR (no poll): OK
> Video Capture: Captured 8 buffers
> test USERPTR (select): OK
> fail: v4l2-test-buffers.cpp(1874): flags & 
> V4L2_BUF_FLAG_NO_CACHE_INVALIDATE
> fail: v4l2-test-buffers.cpp(1937): setupDmaBuf(expbuf_node, 
> node, q, exp_q)
> test DMABUF (no poll): FAIL
> fail: v4l2-test-buffers.cpp(1874): flags & 
> V4L2_BUF_FLAG_NO_CACHE_INVALIDATE
> fail: v4l2-test-buffers.cpp(1937): setupDmaBuf(expbuf_node, 
> node, q, exp_q)
> test DMABUF (select): FAIL

This helps. I'm probably "holding v4l2-compliance wrong", but I have
never seen that assertion triggering. The fix should be easy enough

---

diff --git a/utils/v4l2-compliance/v4l2-test-buffers.cpp 
b/utils/v4l2-compliance/v4l2-test-buffers.cpp
index 79b74e96..1ee12f96 100644
--- a/utils/v4l2-compliance/v4l2-test-buffers.cpp
+++ b/utils/v4l2-compliance/v4l2-test-buffers.cpp
@@ -1871,8 +1871,8 @@ static int setupDmaBuf(struct node *expbuf_node, struct 
node *node,
fail_on_test(!buf.g_bytesused(p));
}
flags = buf.g_flags();
-   fail_on_test(flags & V4L2_BUF_FLAG_NO_CACHE_INVALIDATE);
-   fail_on_test(flags & V4L2_BUF_FLAG_NO_CACHE_CLEAN);
+   fail_on_test(!(flags & V4L2_BUF_FLAG_NO_CACHE_INVALIDATE));
+   fail_on_test(!(flags & V4L2_BUF_FLAG_NO_CACHE_CLEAN));
fail_on_test(flags & V4L2_BUF_FLAG_DONE);
fail_on_test(buf.querybuf(node, i));
fail_on_test(buf.check(q, Queued, i));

Re: [PATCH v6 10/12] mmap locking API: rename mmap_sem to mmap_lock

[youling 257]

I have build error about kernel/sys.c,


kernel/sys.c: In function ‘prctl_set_vma’:

kernel/sys.c:2392:18: error:

‘struct mm_struct’ has no member named ‘mmap_sem’; did you mean

‘mmap_base’?

  2392 |  down_write(>mmap_sem);

   |  ^~~~

   |  mmap_base

kernel/sys.c:2402:16: error:

‘struct mm_struct’ has no member named ‘mmap_sem’; did you mean

‘mmap_base’?

  2402 |  up_write(>mmap_sem);

   |^~~~

   |mmap_base



why not rename kernel/sys.c mmap_sem to mmap_lock?


diff --git a/kernel/sys.c b/kernel/sys.c

index 113955fe1c6b..043c04a745a9 100644

--- a/kernel/sys.c

+++ b/kernel/sys.c

@@ -2389,7 +2389,7 @@ static int prctl_set_vma(unsigned long opt,
unsigned long start,

  if (end == start)

  return 0;

-down_write(>mmap_sem);

+down_write(>mmap_lock);

  switch (opt) {

  case PR_SET_VMA_ANON_NAME:

@@ -2399,7 +2399,7 @@ static int prctl_set_vma(unsigned long opt,
unsigned long start,

  error = -EINVAL;

  }

-up_write(>mmap_sem);

+up_write(>mmap_lock);

  return error;

  }

Re: [GIT PULL for v5.8-rc1] media updates

[pr-tracker-bot]

The pull request you sent on Wed, 3 Jun 2020 10:05:59 +0200:

> git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media 
> tags/media/v5.8-1

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/a98f670e41a99f53acb1fb33cee9c6abbb2e6f23

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker

Re: [PATCH 1/3] dt-bindings: spi: Document bcm2711 and bcm7211 SPI compatible

[Lukas Wunner]

On Wed, Jun 03, 2020 at 08:46:53PM -0700, Florian Fainelli wrote:
> The BCM2711 and BCM7211 chips use the BCM2835 SPI controller, but there
> are severl instances of those in the system and they all share the same
  ^^
Nit: "several"

And apparently they do not *all* share the interrupt, but only
4 controllers (out of 5, not counting the two bcm2835aux ones)
do so.

Thanks,

Lukas

Re: [GIT PULL for v5.8-rc1] media updates

[Linus Torvalds]

On Wed, Jun 3, 2020 at 1:06 AM Mauro Carvalho Chehab
 wrote:
>
>   - The atomisp staging driver was resurrected. It is meant to work with
> 4 generations of cameras on Atom-based laptops, tablets and cell
> phones. So, it seems worth investing time to cleanup this driver and
> making it in good shape.

Hmm. It causes a warning for me:

   drivers/staging/media/atomisp/pci/atomisp_v4l2.c:764:12: warning:
‘atomisp_mrfld_power’ defined but not used [-Wunused-function]

which is a bit annoying.

I can see the FIXME's there, but the warning still isn't acceptable.

I'll add a fixup commit. I was going to do it in the merge itself, but
decided that was a bit too subtle.

   Linus

Re: [PATCH 2/3] ARM: dts: bcm2711: Update SPI nodes compatible strings

[Lukas Wunner]

On Wed, Jun 03, 2020 at 08:46:54PM -0700, Florian Fainelli wrote:
> The BCM2711 SoC features 5 SPI controllers which all share the same
> interrupt line, the SPI driver needs to support interrupt sharing,
> therefore use the chip specific compatible string to help with that.

You're saying above that the 5 controllers all share the interrupt
but below you're only changing the compatible string of 4 controllers.

So I assume spi0 still has its own interrupt and only the additional
4 controllers present on the BCM2711/BCM7211 share their interrupt?

Thanks,

Lukas

> 
> Signed-off-by: Florian Fainelli 
> ---
>  arch/arm/boot/dts/bcm2711.dtsi | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/bcm2711.dtsi b/arch/arm/boot/dts/bcm2711.dtsi
> index a91cf68e3c4c..9a9ea67fbc2d 100644
> --- a/arch/arm/boot/dts/bcm2711.dtsi
> +++ b/arch/arm/boot/dts/bcm2711.dtsi
> @@ -152,7 +152,7 @@
>   };
>  
>   spi3: spi@7e204600 {
> - compatible = "brcm,bcm2835-spi";
> + compatible = "brcm,bcm2711-spi", "brcm,bcm2835-spi";
>   reg = <0x7e204600 0x0200>;
>   interrupts = ;
>   clocks = < BCM2835_CLOCK_VPU>;
> @@ -162,7 +162,7 @@
>   };
>  
>   spi4: spi@7e204800 {
> - compatible = "brcm,bcm2835-spi";
> + compatible = "brcm,bcm2711-spi", "brcm,bcm2835-spi";
>   reg = <0x7e204800 0x0200>;
>   interrupts = ;
>   clocks = < BCM2835_CLOCK_VPU>;
> @@ -172,7 +172,7 @@
>   };
>  
>   spi5: spi@7e204a00 {
> - compatible = "brcm,bcm2835-spi";
> + compatible = "brcm,bcm2711-spi", "brcm,bcm2835-spi";
>   reg = <0x7e204a00 0x0200>;
>   interrupts = ;
>   clocks = < BCM2835_CLOCK_VPU>;
> @@ -182,7 +182,7 @@
>   };
>  
>   spi6: spi@7e204c00 {
> - compatible = "brcm,bcm2835-spi";
> + compatible = "brcm,bcm2711-spi", "brcm,bcm2835-spi";
>   reg = <0x7e204c00 0x0200>;
>   interrupts = ;
>   clocks = < BCM2835_CLOCK_VPU>;
> -- 
> 2.17.1
> 

Re: [PATCH 3/3] spi: bcm2835: Enable shared interrupt support

[Lukas Wunner]

On Wed, Jun 03, 2020 at 08:46:55PM -0700, Florian Fainelli wrote:
> +static const struct of_device_id bcm2835_spi_match[] = {
> + { .compatible = "brcm,bcm2835-spi", .data = _spi_interrupt },
> + { .compatible = "brcm,bcm2711-spi", .data = _spi_sh_interrupt },
> + { .compatible = "brcm,bcm7211-spi", .data = _spi_sh_interrupt },
> + {}
> +};
> +MODULE_DEVICE_TABLE(of, bcm2835_spi_match);

Maybe I'm missing something but I think you either have to reverse the
order of the entries in this array or change patch [2/3] to drop
"brcm,bcm2835-spi" from the compatible string:

__of_match_node() iterates over the entries in the array above and
calls __of_device_is_compatible() for each of them, which returns
success if the entry matches any of the device's compatible string.

Because "brcm,bcm2835-spi" is checked first and that string is
present on the controllers with shared interrupt, they're all
deemed not to use shared interrupts.

If you opt so fix this by dropping "brcm,bcm2835-spi" from the
device's compatible strings, then you have to move patch [2/3]
behind patch [3/3].


>  static int bcm2835_spi_probe(struct platform_device *pdev)
>  {
> + irqreturn_t (*bcm2835_spi_isr_func)(int, void *);

A more succinct alternative is:

irq_handler_t bcm2835_spi_isr_func;

Otherwise this patch LGTM.

Thanks,

Lukas

[PATCH v2] KVM: x86: Assign correct value to array.maxnent

[Xiaoyao Li]

Delay the assignment of array.maxnent to use correct value for the case
cpuid->nent > KVM_MAX_CPUID_ENTRIES.

Fixes: e53c95e8d41e ("KVM: x86: Encapsulate CPUID entries and metadata in 
struct")
Signed-off-by: Xiaoyao Li 
---
v2:
   - remove "const" of maxnent to fix build error.
---
 arch/x86/kvm/cpuid.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
index 253b8e875ccd..3d88ddf781d0 100644
--- a/arch/x86/kvm/cpuid.c
+++ b/arch/x86/kvm/cpuid.c
@@ -426,7 +426,7 @@ EXPORT_SYMBOL_GPL(kvm_set_cpu_caps);
 
 struct kvm_cpuid_array {
struct kvm_cpuid_entry2 *entries;
-   const int maxnent;
+   int maxnent;
int nent;
 };
 
@@ -870,7 +870,6 @@ int kvm_dev_ioctl_get_cpuid(struct kvm_cpuid2 *cpuid,
 
struct kvm_cpuid_array array = {
.nent = 0,
-   .maxnent = cpuid->nent,
};
int r, i;
 
@@ -887,6 +886,8 @@ int kvm_dev_ioctl_get_cpuid(struct kvm_cpuid2 *cpuid,
if (!array.entries)
return -ENOMEM;
 
+   array.maxnent = cpuid->nent;
+
for (i = 0; i < ARRAY_SIZE(funcs); i++) {
r = get_cpuid_func(, funcs[i], type);
if (r)
-- 
2.18.2

[PATCH v2] usb: usbtest: fix missing kfree(dev->buf) in usbtest_disconnect

[qiang.zhang]

From: Zqiang 

BUG: memory leak
unreferenced object 0x888055046e00 (size 256):
  comm "kworker/2:9", pid 2570, jiffies 4294942129 (age 1095.500s)
  hex dump (first 32 bytes):
00 70 04 55 80 88 ff ff 18 bb 5a 81 ff ff ff ff  .p.U..Z.
f5 96 78 81 ff ff ff ff 37 de 8e 81 ff ff ff ff  ..x.7...
  backtrace:
[] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[] slab_post_alloc_hook mm/slab.h:586 [inline]
[] slab_alloc_node mm/slub.c:2786 [inline]
[] slab_alloc mm/slub.c:2794 [inline]
[] kmem_cache_alloc_trace+0x15e/0x2d0 mm/slub.c:2811
[<5c3c3381>] kmalloc include/linux/slab.h:555 [inline]
[<5c3c3381>] usbtest_probe+0x286/0x19d0
drivers/usb/misc/usbtest.c:2790
[<1cec6910>] usb_probe_interface+0x2bd/0x870
drivers/usb/core/driver.c:361
[<7806c118>] really_probe+0x48d/0x8f0 drivers/base/dd.c:551
[] driver_probe_device+0xfc/0x2a0 drivers/base/dd.c:724
[<3ef66004>] __device_attach_driver+0x1b6/0x240
drivers/base/dd.c:831
[] bus_for_each_drv+0x14e/0x1e0 drivers/base/bus.c:431
[] __device_attach+0x1f9/0x350 drivers/base/dd.c:897
[<838b324a>] device_initial_probe+0x1a/0x20 drivers/base/dd.c:944
[<30d501c1>] bus_probe_device+0x1e1/0x280 drivers/base/bus.c:491
[<5bd7adef>] device_add+0x131d/0x1c40 drivers/base/core.c:2504
[] usb_set_configuration+0xe84/0x1ab0
drivers/usb/core/message.c:2030
[] generic_probe+0x6a/0xe0 drivers/usb/core/generic.c:210
[<98ade0f1>] usb_probe_device+0x90/0xd0
drivers/usb/core/driver.c:266
[<7806c118>] really_probe+0x48d/0x8f0 drivers/base/dd.c:551
[] driver_probe_device+0xfc/0x2a0 drivers/base/dd.c:724

Reported-by: Kyungtae Kim 
Signed-off-by: Zqiang 
---
 v1->v2:
 Remove Fixes field.

 drivers/usb/misc/usbtest.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/usb/misc/usbtest.c b/drivers/usb/misc/usbtest.c
index 98ada1a3425c..bae88893ee8e 100644
--- a/drivers/usb/misc/usbtest.c
+++ b/drivers/usb/misc/usbtest.c
@@ -2873,6 +2873,7 @@ static void usbtest_disconnect(struct usb_interface *intf)
 
usb_set_intfdata(intf, NULL);
dev_dbg(>dev, "disconnect\n");
+   kfree(dev->buf);
kfree(dev);
 }
 
-- 
2.24.1

Re: [GIT PULL for v5.8-rc1] media updates

[Linus Torvalds]

On Wed, Jun 3, 2020 at 1:06 AM Mauro Carvalho Chehab
 wrote:
>
> PS.: The diffstat is so big that I almost dropped it, as it is almost
> useless for humans to read. I ended by not doing it just because perhaps
> you could be using some sort of script to check diffstat.

No, but I do compare the basics, and you don't have to more than scan
it to see that "ok, it only touches area xyz".

And it turns out that it is huge for you partly because you have the
default (fairly low) git rename detection limits, in order to avoid
using a lot of CPU or memory for rename detection.

So you get:

>  2181 files changed, 260633 insertions(+), 106012 deletions(-)

while I get

 1698 files changed, 161922 insertions(+), 7301 deletions(-)

which is a noticeable difference. Still a big diffstat, but quite a
bit smaller than yours.

You also get a _lot_ more noise in the form of "create mode xyz" and
"delete mode abc" notices, while for me a lot of them are just "rename
abc => xyz". So there's a double whammy for you.

The reason is that your diff only has renames for the 100% matches like this:

>  rename Documentation/{media/v4l-drivers => 
> admin-guide/media}/au0828-cardlist.rst (100%)

which git can detect purely by seeing "oh, same exact SHA1".

But you don't have any non-100% renames.

In contrast, the diffstat I see also has the inexact renames like

 rename Documentation/{media/v4l-drivers =>
admin-guide/media}/bttv-cardlist.rst (99%)
 rename Documentation/{media/v4l-drivers => admin-guide/media}/bttv.rst (79%)

because I have done

   git config diff.renamelimit 0

to make the rename detection limit be infinite (alternatively, just
edit your ~/.gitconfig file manually - it's often easier than
remembering what the "git config" syntax is).

You want to see

  [diff]
renamelimit = 0

in your ~/.gitconfig file (or, alternatively, if you want the setting
to be per-repo, in your .git/config file in your repository).

The default git limits for "should I spend CPU time and memory on
detecting inexact renames" are fairly low, because people use git on
fairly low-end machines.

I bet your development machine isn't some kind of low-end toy, and
rename detection is not _that_ expensive.

  Linus

Re: [RFC PATCH v4 07/10] vfio/pci: introduce a new irq type VFIO_IRQ_TYPE_REMAP_BAR_REGION

[Alex Williamson]

On Wed, 3 Jun 2020 22:42:28 -0400
Yan Zhao  wrote:

> On Wed, Jun 03, 2020 at 05:04:52PM -0600, Alex Williamson wrote:
> > On Tue, 2 Jun 2020 21:40:58 -0400
> > Yan Zhao  wrote:
> >   
> > > On Tue, Jun 02, 2020 at 01:34:35PM -0600, Alex Williamson wrote:  
> > > > I'm not at all happy with this.  Why do we need to hide the migration
> > > > sparse mmap from the user until migration time?  What if instead we
> > > > introduced a new VFIO_REGION_INFO_CAP_SPARSE_MMAP_SAVING capability
> > > > where the existing capability is the normal runtime sparse setup and
> > > > the user is required to use this new one prior to enabled device_state
> > > > with _SAVING.  The vendor driver could then simply track mmap vmas to
> > > > the region and refuse to change device_state if there are outstanding
> > > > mmaps conflicting with the _SAVING sparse mmap layout.  No new IRQs
> > > > required, no new irqfds, an incremental change to the protocol,
> > > > backwards compatible to the extent that a vendor driver requiring this
> > > > will automatically fail migration.
> > > > 
> > > right. looks we need to use this approach to solve the problem.
> > > thanks for your guide.
> > > so I'll abandon the current remap irq way for dirty tracking during live
> > > migration.
> > > but anyway, it demos how to customize irq_types in vendor drivers.
> > > then, what do you think about patches 1-5?  
> > 
> > In broad strokes, I don't think we've found the right solution yet.  I
> > really question whether it's supportable to parcel out vfio-pci like
> > this and I don't know how I'd support unraveling whether we have a bug
> > in vfio-pci, the vendor driver, or how the vendor driver is making use
> > of vfio-pci.
> >
> > Let me also ask, why does any of this need to be in the kernel?  We
> > spend 5 patches slicing up vfio-pci so that we can register a vendor
> > driver and have that vendor driver call into vfio-pci as it sees fit.
> > We have two patches creating device specific interrupts and a BAR
> > remapping scheme that we've decided we don't need.  That brings us to
> > the actual i40e vendor driver, where the first patch is simply making
> > the vendor driver work like vfio-pci already does, the second patch is
> > handling the migration region, and the third patch is implementing the
> > BAR remapping IRQ that we decided we don't need.  It's difficult to
> > actually find the small bit of code that's required to support
> > migration outside of just dealing with the protocol we've defined to
> > expose this from the kernel.  So why are we trying to do this in the
> > kernel?  We have quirk support in QEMU, we can easily flip
> > MemoryRegions on and off, etc.  What access to the device outside of
> > what vfio-pci provides to the user, and therefore QEMU, is necessary to
> > implement this migration support for i40e VFs?  Is this just an
> > exercise in making use of the migration interface?  Thanks,
> >   
> hi Alex
> 
> There was a description of intention of this series in RFC v1
> (https://www.spinics.net/lists/kernel/msg3337337.html).
> sorry, I didn't include it in starting from RFC v2.
> 
> "
> The reason why we don't choose the way of writing mdev parent driver is
> that

I didn't mention an mdev approach, I'm asking what are we accomplishing
by doing this in the kernel at all versus exposing the device as normal
through vfio-pci and providing the migration support in QEMU.  Are you
actually leveraging having some sort of access to the PF in supporting
migration of the VF?  Is vfio-pci masking the device in a way that
prevents migrating the state from QEMU?

> (1) VFs are almost all the time directly passthroughed. Directly binding
> to vfio-pci can make most of the code shared/reused. If we write a
> vendor specific mdev parent driver, most of the code (like passthrough
> style of rw/mmap) still needs to be copied from vfio-pci driver, which is
> actually a duplicated and tedious work.
> (2) For features like dynamically trap/untrap pci bars, if they are in
> vfio-pci, they can be available to most people without repeated code
> copying and re-testing.
> (3) with a 1:1 mdev driver which passes through VFs most of the time, people
> have to decide whether to bind VFs to vfio-pci or mdev parent driver before
> it runs into a real migration need. However, if vfio-pci is bound
> initially, they have no chance to do live migration when there's a need
> later.
> "
> particularly, there're some devices (like NVMe) they purely reply on
> vfio-pci to do device pass-through and they have no standalone parent driver
> to do mdev way.
> 
> I think live migration is a general requirement for most devices and to
> interact with the migration interface requires vendor drivers to do
> device specific tasks like geting/seting device state, starting/stopping
> devices, tracking dirty data, report migration capabilities... all those
> works need be in kernel.

I think Alex Graf proved they don't necessarily need to be done in

Re: [PATCH 09/10] treewide: Remove uninitialized_var() usage

[Kees Cook]

On Wed, Jun 03, 2020 at 08:33:15PM -0700, Nathan Chancellor wrote:
> On Wed, Jun 03, 2020 at 04:32:02PM -0700, Kees Cook wrote:
> > Using uninitialized_var() is dangerous as it papers over real bugs[1]
> > (or can in the future), and suppresses unrelated compiler warnings
> > (e.g. "unused variable"). If the compiler thinks it is uninitialized,
> > either simply initialize the variable or make compiler changes.
> > 
> > I preparation for removing[2] the[3] macro[4], remove all remaining
> > needless uses with the following script:
> > 
> > git grep '\buninitialized_var\b' | cut -d: -f1 | sort -u | \
> > xargs perl -pi -e \
> > 's/\buninitialized_var\(([^\)]+)\)/\1/g;
> >  s:\s*/\* (GCC be quiet|to make compiler happy) \*/$::g;'
> > 
> > drivers/video/fbdev/riva/riva_hw.c was manually tweaked to avoid
> > pathological white-space.
> > 
> > No outstanding warnings were found building allmodconfig with GCC 9.3.0
> > for x86_64, i386, arm64, arm, powerpc, powerpc64le, s390x, mips, sparc64,
> > alpha, and m68k.
> > 
> > [1] https://lore.kernel.org/lkml/20200603174714.192027-1-gli...@google.com/
> > [2] 
> > https://lore.kernel.org/lkml/CA+55aFw+Vbj0i=1tgqcr5vqkczwj0qxk6cernou6eedsuda...@mail.gmail.com/
> > [3] 
> > https://lore.kernel.org/lkml/ca+55afwgbgqhbp1fkxvrkepzyr5j8n1vkt1vzdz9knmpuxh...@mail.gmail.com/
> > [4] 
> > https://lore.kernel.org/lkml/CA+55aFz2500WfbKXAx8s67wrm9=yvju65tplgn_ybynv0ve...@mail.gmail.com/
> > 
> > Signed-off-by: Kees Cook 
> 
> 
> 
> > diff --git a/arch/powerpc/kvm/book3s_pr.c b/arch/powerpc/kvm/book3s_pr.c
> > index a0f6813f4560..a71fa7204882 100644
> > --- a/arch/powerpc/kvm/book3s_pr.c
> > +++ b/arch/powerpc/kvm/book3s_pr.c
> > @@ -1829,7 +1829,7 @@ static int kvmppc_vcpu_run_pr(struct kvm_run 
> > *kvm_run, struct kvm_vcpu *vcpu)
> >  {
> > int ret;
> >  #ifdef CONFIG_ALTIVEC
> > -   unsigned long uninitialized_var(vrsave);
> > +   unsigned long vrsave;
> >  #endif
> 
> This variable is actually unused:
> 
> ../arch/powerpc/kvm/book3s_pr.c:1832:16: warning: unused variable 'vrsave' 
> [-Wunused-variable]
> unsigned long vrsave;
>   ^
> 1 warning generated.
> 
> It has been unused since commit 99dae3bad28d ("KVM: PPC: Load/save
> FP/VMX/VSX state directly to/from vcpu struct").
> 
> $ git grep vrsave 99dae3bad28d8fdd32b7bfdd5e2ec7bb2d4d019d 
> arch/powerpc/kvm/book3s_pr.c
> 99dae3bad28d8fdd32b7bfdd5e2ec7bb2d4d019d:arch/powerpc/kvm/book3s_pr.c:  
> unsigned long uninitialized_var(vrsave);
> 
> I would nuke the whole '#ifdef' block.

Ah, thanks! I wonder why I don't have CONFIG_ALTIVEC in any of my ppc
builds. Hmmm.

-Kees

-- 
Kees Cook

[PATCH V2] mm/vmstat: Add events for THP migration without split

[Anshuman Khandual]

Add the following new VM events which will help in validating THP migration
without split. Statistics reported through these new events will help in
performance debugging.

1. THP_MIGRATION_SUCCESS
2. THP_MIGRATION_FAILURE

THP_MIGRATION_FAILURE in particular represents an event when a THP could
not be migrated as a single entity following an allocation failure and
ended up getting split into constituent normal pages before being retried.
This event, along with PGMIGRATE_SUCCESS and PGMIGRATE_FAIL will help in
quantifying and analyzing THP migration events including both success and
failure cases.

Cc: Naoya Horiguchi 
Cc: Zi Yan 
Cc: John Hubbard 
Cc: Andrew Morton 
Cc: linux...@kvack.org
Cc: linux-kernel@vger.kernel.org
[hughd: fixed oops on NULL newpage]
Signed-off-by: Anshuman Khandual 
---
Changes in V2:

- Dropped PMD reference both from code and commit message per Matthew
- Added documentation and updated the commit message per Daniel

Changes in V1: (https://patchwork.kernel.org/patch/11564497/)

- Changed function name as thp_pmd_migration_success() per John
- Folded in a fix (https://patchwork.kernel.org/patch/11563009/) from Hugh

Changes in RFC V2: (https://patchwork.kernel.org/patch/11554861/)

- Decopupled and renamed VM events from their implementation per Zi and John
- Added THP_PMD_MIGRATION_FAILURE VM event upon allocation failure and split

Changes in RFC V1: (https://patchwork.kernel.org/patch/11542055/)

 Documentation/vm/page_migration.rst | 15 +++
 include/linux/vm_event_item.h   |  4 
 mm/migrate.c| 23 +++
 mm/vmstat.c |  4 
 4 files changed, 46 insertions(+)

diff --git a/Documentation/vm/page_migration.rst 
b/Documentation/vm/page_migration.rst
index 1d6cd7db4e43..67e9b067fed7 100644
--- a/Documentation/vm/page_migration.rst
+++ b/Documentation/vm/page_migration.rst
@@ -253,5 +253,20 @@ which are function pointers of struct 
address_space_operations.
  PG_isolated is alias with PG_reclaim flag so driver shouldn't use the flag
  for own purpose.
 
+Quantifying Migration
+=
+Following events can be used to quantify page migration.
+
+- PGMIGRATE_SUCCESS
+- PGMIGRATE_FAIL
+- THP_MIGRATION_SUCCESS
+- THP_MIGRATION_FAILURE
+
+THP_MIGRATION_FAILURE in particular represents an event when a THP could not be
+migrated as a single entity following an allocation failure and ended up 
getting
+split into constituent normal pages before being retried. This event, along 
with
+PGMIGRATE_SUCCESS and PGMIGRATE_FAIL will help in quantifying and analyzing THP
+migration events including both success and failure cases.
+
 Christoph Lameter, May 8, 2006.
 Minchan Kim, Mar 28, 2016.
diff --git a/include/linux/vm_event_item.h b/include/linux/vm_event_item.h
index ffef0f279747..6459265461df 100644
--- a/include/linux/vm_event_item.h
+++ b/include/linux/vm_event_item.h
@@ -91,6 +91,10 @@ enum vm_event_item { PGPGIN, PGPGOUT, PSWPIN, PSWPOUT,
THP_ZERO_PAGE_ALLOC_FAILED,
THP_SWPOUT,
THP_SWPOUT_FALLBACK,
+#ifdef CONFIG_ARCH_ENABLE_THP_MIGRATION
+   THP_MIGRATION_SUCCESS,
+   THP_MIGRATION_FAILURE,
+#endif
 #endif
 #ifdef CONFIG_MEMORY_BALLOON
BALLOON_INFLATE,
diff --git a/mm/migrate.c b/mm/migrate.c
index 7160c1556f79..0bb1dbb891bb 100644
--- a/mm/migrate.c
+++ b/mm/migrate.c
@@ -1170,6 +1170,20 @@ static int __unmap_and_move(struct page *page, struct 
page *newpage,
 #define ICE_noinline
 #endif
 
+#ifdef CONFIG_ARCH_ENABLE_THP_MIGRATION
+static inline void thp_migration_success(bool success)
+{
+   if (success)
+   count_vm_event(THP_MIGRATION_SUCCESS);
+   else
+   count_vm_event(THP_MIGRATION_FAILURE);
+}
+#else
+static inline void thp_migration_success(bool success)
+{
+}
+#endif
+
 /*
  * Obtain the lock on page, remove all ptes and migrate the page
  * to the newly allocated page in newpage.
@@ -1232,6 +1246,14 @@ static ICE_noinline int unmap_and_move(new_page_t 
get_new_page,
 * we want to retry.
 */
if (rc == MIGRATEPAGE_SUCCESS) {
+   /*
+* When the page to be migrated has been freed from under
+* us, that is considered a MIGRATEPAGE_SUCCESS, but no
+* newpage has been allocated. It should not be counted
+* as a successful THP migration.
+*/
+   if (newpage && PageTransHuge(newpage))
+   thp_migration_success(true);
put_page(page);
if (reason == MR_MEMORY_FAILURE) {
/*
@@ -1474,6 +1496,7 @@ int migrate_pages(struct list_head *from, new_page_t 
get_new_page,
unlock_page(page);
if (!rc) {
list_safe_reset_next(page, 
page2, lru);
+   

Re: [PATCH v5 0/3] SELinux support for anonymous inodes and UFFD

[James Morris]

On Wed, 1 Apr 2020, Daniel Colascione wrote:

> Daniel Colascione (3):
>   Add a new LSM-supporting anonymous inode interface
>   Teach SELinux about anonymous inodes
>   Wire UFFD up to SELinux
> 
>  fs/anon_inodes.c| 191 ++--
>  fs/userfaultfd.c|  30 -
>  include/linux/anon_inodes.h |  13 ++
>  include/linux/lsm_hooks.h   |  11 ++
>  include/linux/security.h|   3 +
>  security/security.c |   9 ++
>  security/selinux/hooks.c|  53 
>  security/selinux/include/classmap.h |   2 +
>  8 files changed, 267 insertions(+), 45 deletions(-)

Applied to
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git 
secure_uffd_v5.9
and next-testing.

This will provide test coverage in linux-next, as we aim to get this 
upstream for v5.9.

I had to make some minor fixups, please review.


-- 
James Morris

Re: [PATCH] KVM: x86: Assign correct value to array.maxnent

[Xiaoyao Li]

On 6/4/2020 10:43 AM, Xiaoyao Li wrote:

Delay the assignment of array.maxnent to use correct value for the case
cpuid->nent > KVM_MAX_CPUID_ENTRIES.

Fixes: e53c95e8d41e ("KVM: x86: Encapsulate CPUID entries and metadata in 
struct")
Signed-off-by: Xiaoyao Li 
---
  arch/x86/kvm/cpuid.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
index 253b8e875ccd..befff01d100c 100644
--- a/arch/x86/kvm/cpuid.c
+++ b/arch/x86/kvm/cpuid.c
@@ -870,7 +870,6 @@ int kvm_dev_ioctl_get_cpuid(struct kvm_cpuid2 *cpuid,
  
  	struct kvm_cpuid_array array = {

.nent = 0,
-   .maxnent = cpuid->nent,
};
int r, i;
  
@@ -887,6 +886,8 @@ int kvm_dev_ioctl_get_cpuid(struct kvm_cpuid2 *cpuid,

if (!array.entries)
return -ENOMEM;
  
+	array.maxnent = cpuid->nent;


Miss the fact that maxnent is const, V2 is coming.


+
for (i = 0; i < ARRAY_SIZE(funcs); i++) {
r = get_cpuid_func(, funcs[i], type);
if (r)

[PATCH] x86/mm: use max memory block size with unaligned memory end

[Daniel Jordan]

Some of our servers spend 14 out of the 21 seconds of kernel boot
initializing memory block sysfs directories and then creating symlinks
between them and the corresponding nodes.  The slowness happens because
the machines get stuck with the smallest supported memory block size on
x86 (128M), which results in 16,288 directories to cover the 2T of
installed RAM, and each of these paths does a linear search of the
memory blocks for every block id, with atomic ops at each step.

Commit 078eb6aa50dc ("x86/mm/memory_hotplug: determine block size based
on the end of boot memory") chooses the block size based on alignment
with memory end.  That addresses hotplug failures in qemu guests, but
for bare metal systems whose memory end isn't aligned to the smallest
size, it leaves them at 128M.

For such systems, use the largest supported size (2G) to minimize
overhead on big machines.  That saves nearly all of the 14 seconds so
the kernel boots 3x faster.

There are some simple ways to avoid the linear searches, but for now it
makes no difference with a 2G block.

Signed-off-by: Daniel Jordan 
---
 arch/x86/mm/init_64.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
index 8b5f73f5e207c..d388127d1b519 100644
--- a/arch/x86/mm/init_64.c
+++ b/arch/x86/mm/init_64.c
@@ -1390,6 +1390,15 @@ static unsigned long probe_memory_block_size(void)
goto done;
}
 
+   /*
+* Memory end isn't aligned to any allowed block size, so default to
+* the largest to minimize overhead on large memory systems.
+*/
+   if (!IS_ALIGNED(boot_mem_end, MIN_MEMORY_BLOCK_SIZE)) {
+   bz = MAX_BLOCK_SIZE;
+   goto done;
+   }
+
/* Find the largest allowed block size that aligns to memory end */
for (bz = MAX_BLOCK_SIZE; bz > MIN_MEMORY_BLOCK_SIZE; bz >>= 1) {
if (IS_ALIGNED(boot_mem_end, bz))

base-commit: 3d77e6a8804abcc0504c904bd6e5cdf3a5cf8162
-- 
2.26.2

[PATCH 0/3] spi: bcm2835: Enable shared interrupt support

[Florian Fainelli]

Hi Mark, Lukas,

This patch series is implementing the approach that was discussed in
response to this previous submission:

https://lore.kernel.org/linux-arm-kernel/20200528185805.28991-1-nsaenzjulie...@suse.de/

It aims to have dedicated interrupt handlers for 2835 versus 2711/7211
so as to minimize the overhead for 2835.

Florian Fainelli (3):
  dt-bindings: spi: Document bcm2711 and bcm7211 SPI compatible
  ARM: dts: bcm2711: Update SPI nodes compatible strings
  spi: bcm2835: Enable shared interrupt support

 .../bindings/spi/brcm,bcm2835-spi.txt |  3 +-
 arch/arm/boot/dts/bcm2711.dtsi|  8 ++--
 drivers/spi/spi-bcm2835.c | 48 +++
 3 files changed, 44 insertions(+), 15 deletions(-)

-- 
2.17.1

[PATCH 3/3] spi: bcm2835: Enable shared interrupt support

[Florian Fainelli]

The SPI controller found in the BCM2711 and BCM7211 SoCs is instantiated
5 times, with all instances sharing the same interrupt line. We
specifically match the two compatible strings here to determine whether
it is necessary to request the interrupt with the IRQF_SHARED flag and
to use an appropriate interrupt handler capable of returning IRQ_NONE.

For the BCM2835 case which is deemed performance critical, there is no
overhead since a dedicated handler that does not assume sharing is used.

Signed-off-by: Florian Fainelli 
---
 drivers/spi/spi-bcm2835.c | 48 +++
 1 file changed, 38 insertions(+), 10 deletions(-)

diff --git a/drivers/spi/spi-bcm2835.c b/drivers/spi/spi-bcm2835.c
index 237bd306c268..2e73ec70ee80 100644
--- a/drivers/spi/spi-bcm2835.c
+++ b/drivers/spi/spi-bcm2835.c
@@ -361,11 +361,10 @@ static void bcm2835_spi_reset_hw(struct spi_controller 
*ctlr)
bcm2835_wr(bs, BCM2835_SPI_DLEN, 0);
 }
 
-static irqreturn_t bcm2835_spi_interrupt(int irq, void *dev_id)
+static inline irqreturn_t bcm2835_spi_interrupt_common(struct spi_controller 
*ctlr,
+  u32 cs)
 {
-   struct spi_controller *ctlr = dev_id;
struct bcm2835_spi *bs = spi_controller_get_devdata(ctlr);
-   u32 cs = bcm2835_rd(bs, BCM2835_SPI_CS);
 
/*
 * An interrupt is signaled either if DONE is set (TX FIFO empty)
@@ -394,6 +393,27 @@ static irqreturn_t bcm2835_spi_interrupt(int irq, void 
*dev_id)
return IRQ_HANDLED;
 }
 
+static irqreturn_t bcm2835_spi_interrupt(int irq, void *dev_id)
+{
+   struct spi_controller *ctlr = dev_id;
+   struct bcm2835_spi *bs = spi_controller_get_devdata(ctlr);
+   u32 cs = bcm2835_rd(bs, BCM2835_SPI_CS);
+
+   return bcm2835_spi_interrupt_common(ctlr, cs);
+}
+
+static irqreturn_t bcm2835_spi_sh_interrupt(int irq, void *dev_id)
+{
+   struct spi_controller *ctlr = dev_id;
+   struct bcm2835_spi *bs = spi_controller_get_devdata(ctlr);
+   u32 cs = bcm2835_rd(bs, BCM2835_SPI_CS);
+
+   if (!(cs & BCM2835_SPI_CS_INTR))
+   return IRQ_NONE;
+
+   return bcm2835_spi_interrupt_common(ctlr, cs);
+}
+
 static int bcm2835_spi_transfer_one_irq(struct spi_controller *ctlr,
struct spi_device *spi,
struct spi_transfer *tfr,
@@ -1287,12 +1307,26 @@ static int bcm2835_spi_setup(struct spi_device *spi)
return 0;
 }
 
+static const struct of_device_id bcm2835_spi_match[] = {
+   { .compatible = "brcm,bcm2835-spi", .data = _spi_interrupt },
+   { .compatible = "brcm,bcm2711-spi", .data = _spi_sh_interrupt },
+   { .compatible = "brcm,bcm7211-spi", .data = _spi_sh_interrupt },
+   {}
+};
+MODULE_DEVICE_TABLE(of, bcm2835_spi_match);
+
 static int bcm2835_spi_probe(struct platform_device *pdev)
 {
+   irqreturn_t (*bcm2835_spi_isr_func)(int, void *);
struct spi_controller *ctlr;
+   unsigned long flags = 0;
struct bcm2835_spi *bs;
int err;
 
+   bcm2835_spi_isr_func = of_device_get_match_data(>dev);
+   if (bcm2835_spi_isr_func == _spi_sh_interrupt)
+   flags = IRQF_SHARED;
+
ctlr = spi_alloc_master(>dev, ALIGN(sizeof(*bs),
  dma_get_cache_alignment()));
if (!ctlr)
@@ -1344,7 +1378,7 @@ static int bcm2835_spi_probe(struct platform_device *pdev)
bcm2835_wr(bs, BCM2835_SPI_CS,
   BCM2835_SPI_CS_CLEAR_RX | BCM2835_SPI_CS_CLEAR_TX);
 
-   err = devm_request_irq(>dev, bs->irq, bcm2835_spi_interrupt, 0,
+   err = devm_request_irq(>dev, bs->irq, bcm2835_spi_isr_func, flags,
   dev_name(>dev), ctlr);
if (err) {
dev_err(>dev, "could not request IRQ: %d\n", err);
@@ -1400,12 +1434,6 @@ static void bcm2835_spi_shutdown(struct platform_device 
*pdev)
dev_err(>dev, "failed to shutdown\n");
 }
 
-static const struct of_device_id bcm2835_spi_match[] = {
-   { .compatible = "brcm,bcm2835-spi", },
-   {}
-};
-MODULE_DEVICE_TABLE(of, bcm2835_spi_match);
-
 static struct platform_driver bcm2835_spi_driver = {
.driver = {
.name   = DRV_NAME,
-- 
2.17.1

[PATCH 1/3] dt-bindings: spi: Document bcm2711 and bcm7211 SPI compatible

[Florian Fainelli]

The BCM2711 and BCM7211 chips use the BCM2835 SPI controller, but there
are severl instances of those in the system and they all share the same
interrupt line. Document specific compatible strings such that the
driver can take appropriate actions.

Signed-off-by: Florian Fainelli 
---
 Documentation/devicetree/bindings/spi/brcm,bcm2835-spi.txt | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/spi/brcm,bcm2835-spi.txt 
b/Documentation/devicetree/bindings/spi/brcm,bcm2835-spi.txt
index f11f295c8450..3d55dd64b1be 100644
--- a/Documentation/devicetree/bindings/spi/brcm,bcm2835-spi.txt
+++ b/Documentation/devicetree/bindings/spi/brcm,bcm2835-spi.txt
@@ -5,7 +5,8 @@ SPI0, and the other known as the "Universal SPI Master"; part 
of the
 auxiliary block. This binding applies to the SPI0 controller.
 
 Required properties:
-- compatible: Should be "brcm,bcm2835-spi".
+- compatible: Should be one of "brcm,bcm2835-spi" for BCM2835/2836/2837 or
+  "brcm,bcm2711-spi" for BCM2711 or "brcm,bcm7211-spi" for BCM7211.
 - reg: Should contain register location and length.
 - interrupts: Should contain interrupt.
 - clocks: The clock feeding the SPI controller.
-- 
2.17.1

[PATCH 2/3] ARM: dts: bcm2711: Update SPI nodes compatible strings

[Florian Fainelli]

The BCM2711 SoC features 5 SPI controllers which all share the same
interrupt line, the SPI driver needs to support interrupt sharing,
therefore use the chip specific compatible string to help with that.

Signed-off-by: Florian Fainelli 
---
 arch/arm/boot/dts/bcm2711.dtsi | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/bcm2711.dtsi b/arch/arm/boot/dts/bcm2711.dtsi
index a91cf68e3c4c..9a9ea67fbc2d 100644
--- a/arch/arm/boot/dts/bcm2711.dtsi
+++ b/arch/arm/boot/dts/bcm2711.dtsi
@@ -152,7 +152,7 @@
};
 
spi3: spi@7e204600 {
-   compatible = "brcm,bcm2835-spi";
+   compatible = "brcm,bcm2711-spi", "brcm,bcm2835-spi";
reg = <0x7e204600 0x0200>;
interrupts = ;
clocks = < BCM2835_CLOCK_VPU>;
@@ -162,7 +162,7 @@
};
 
spi4: spi@7e204800 {
-   compatible = "brcm,bcm2835-spi";
+   compatible = "brcm,bcm2711-spi", "brcm,bcm2835-spi";
reg = <0x7e204800 0x0200>;
interrupts = ;
clocks = < BCM2835_CLOCK_VPU>;
@@ -172,7 +172,7 @@
};
 
spi5: spi@7e204a00 {
-   compatible = "brcm,bcm2835-spi";
+   compatible = "brcm,bcm2711-spi", "brcm,bcm2835-spi";
reg = <0x7e204a00 0x0200>;
interrupts = ;
clocks = < BCM2835_CLOCK_VPU>;
@@ -182,7 +182,7 @@
};
 
spi6: spi@7e204c00 {
-   compatible = "brcm,bcm2835-spi";
+   compatible = "brcm,bcm2711-spi", "brcm,bcm2835-spi";
reg = <0x7e204c00 0x0200>;
interrupts = ;
clocks = < BCM2835_CLOCK_VPU>;
-- 
2.17.1

Re: [PATCH 08/10] checkpatch: Remove awareness of uninitialized_var() macro

[Kees Cook]

On Thu, Jun 04, 2020 at 04:53:34AM +0200, Sedat Dilek wrote:
> can you push that change also to kees/linux.git#kspp/uninit/v5.7/macro ?

Done! :)

-- 
Kees Cook

Re: [PATCH] mm/memblock: export max_pfn for kernel modules

[Miles Chen]

On Wed, 2020-06-03 at 18:16 +0200, David Hildenbrand wrote:
> On 03.06.20 18:11, Miles Chen wrote:
> > max_pfn is uesd to get the highest pfn in the system. Drivers like
> > drivers/iommu/mtk_iommu.c checks max_pfn to see if it should enable
> > its "4GB mode".
> > 
> > This patch exports the max_pfn symbol, so we can build the driver as
> > a kernel module.
> 
> Please add that change to the respective user patch (and cc MM-people
> for that patch), so we have the actual user right along the change and
> can figure out if this is the right thing to do.
> 

Thanks for the comment.

Mike points out another alternative way to do this by totalram_pages().
I will use that approach so we don't have to export max_pfn here.

https://lkml.org/lkml/2020/6/3/771

Miles

> > 
> > Signed-off-by: Miles Chen 
> > ---
> >  mm/memblock.c | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/mm/memblock.c b/mm/memblock.c
> > index c79ba6f9920c..3b2b21ecebb6 100644
> > --- a/mm/memblock.c
> > +++ b/mm/memblock.c
> > @@ -99,6 +99,7 @@ EXPORT_SYMBOL(contig_page_data);
> >  unsigned long max_low_pfn;
> >  unsigned long min_low_pfn;
> >  unsigned long max_pfn;
> > +EXPORT_SYMBOL(max_pfn);
> >  unsigned long long max_possible_pfn;
> >  
> >  static struct memblock_region 
> > memblock_memory_init_regions[INIT_MEMBLOCK_REGIONS] __initdata_memblock;
> > 
> 
> 

Re: [PATCH] crypto: hisilicon - fix strncpy warning with strlcpy

[Herbert Xu]

On Thu, Jun 04, 2020 at 11:32:04AM +0800, Zhangfei Gao wrote:
> Use strlcpy to fix the warning
> warning: 'strncpy' specified bound 64 equals destination size
>  [-Wstringop-truncation]
> 
> Reported-by: kernel test robot 
> Signed-off-by: Zhangfei Gao 
> ---
>  drivers/crypto/hisilicon/qm.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/crypto/hisilicon/qm.c b/drivers/crypto/hisilicon/qm.c
> index f795fb5..224f3e2 100644
> --- a/drivers/crypto/hisilicon/qm.c
> +++ b/drivers/crypto/hisilicon/qm.c
> @@ -1574,7 +1574,7 @@ static int qm_alloc_uacce(struct hisi_qm *qm)
>   .ops = _qm_ops,
>   };
>  
> - strncpy(interface.name, pdev->driver->name, sizeof(interface.name));
> + strlcpy(interface.name, pdev->driver->name, sizeof(interface.name));

Should this even allow truncation? Perhaps it'd be better to fail
in case of an overrun?

Cheers,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH] mm/memblock: export max_pfn for kernel modules

[Miles Chen]

On Wed, 2020-06-03 at 20:06 +0300, Mike Rapoport wrote:
> On Thu, Jun 04, 2020 at 12:11:32AM +0800, Miles Chen wrote:
> > max_pfn is uesd to get the highest pfn in the system. Drivers like
> > drivers/iommu/mtk_iommu.c checks max_pfn to see if it should enable
> > its "4GB mode".
> > 
> > This patch exports the max_pfn symbol, so we can build the driver as
> > a kernel module.
> 
> You can use totalram_pages(), like e.g.
> drivers/media/platform/mtk-vpu/mtk_vpu.c:
> 
> $ git grep -np totalram_pages 
> drivers/medhttps://lkml.org/lkml/2020/5/30/123ia/
> drivers/media/platform/mtk-vpu/mtk_vpu.c=779=static int mtk_vpu_probe(struct 
> platform_device *pdev)
> drivers/media/platform/mtk-vpu/mtk_vpu.c:861:   vpu->enable_4GB = 
> !!(totalram_pages() > (SZ_2G >> PAGE_SHIFT));
> 

Thanks for the suggestion.
totalram_pages() works and I can follow this example.

Miles

> 
> > Signed-off-by: Miles Chen 
> > ---
> >  mm/memblock.c | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/mm/memblock.c b/mm/memblock.c
> > index c79ba6f9920c..3b2b21ecebb6 100644
> > --- a/mm/memblock.c
> > +++ b/mm/memblock.c
> > @@ -99,6 +99,7 @@ EXPORT_SYMBOL(contig_page_data);
> >  unsigned long max_low_pfn;
> >  unsigned long min_low_pfn;
> >  unsigned long max_pfn;
> > +EXPORT_SYMBOL(max_pfn);
> >  unsigned long long max_possible_pfn;
> >  
> >  static struct memblock_region 
> > memblock_memory_init_regions[INIT_MEMBLOCK_REGIONS] __initdata_memblock;
> > -- 
> > 2.18.0
> 

Re: [PATCH v3 1/4] fs, net: Standardize on file_receive helper to move fds across processes

[Sargun Dhillon]

On Thu, Jun 04, 2020 at 03:24:52AM +0200, Christian Brauner wrote:
> On Tue, Jun 02, 2020 at 06:10:41PM -0700, Sargun Dhillon wrote:
> > Previously there were two chunks of code where the logic to receive file
> > descriptors was duplicated in net. The compat version of copying
> > file descriptors via SCM_RIGHTS did not have logic to update cgroups.
> > Logic to change the cgroup data was added in:
> > commit 48a87cc26c13 ("net: netprio: fd passed in SCM_RIGHTS datagram not 
> > set correctly")
> > commit d84295067fc7 ("net: net_cls: fd passed in SCM_RIGHTS datagram not 
> > set correctly")
> > 
> > This was not copied to the compat path. This commit fixes that, and thus
> > should be cherry-picked into stable.
> > 
> > This introduces a helper (file_receive) which encapsulates the logic for
> > handling calling security hooks as well as manipulating cgroup information.
> > This helper can then be used other places in the kernel where file
> > descriptors are copied between processes
> > 
> > I tested cgroup classid setting on both the compat (x32) path, and the
> > native path to ensure that when moving the file descriptor the classid
> > is set.
> > 
> > Signed-off-by: Sargun Dhillon 
> > Suggested-by: Kees Cook 
> > Cc: Al Viro 
> > Cc: Christian Brauner 
> > Cc: Daniel Wagner 
> > Cc: David S. Miller 
> > Cc: Jann Horn ,
> > Cc: John Fastabend 
> > Cc: Tejun Heo 
> > Cc: Tycho Andersen 
> > Cc: sta...@vger.kernel.org
> > Cc: cgro...@vger.kernel.org
> > Cc: linux-fsde...@vger.kernel.org
> > Cc: linux-kernel@vger.kernel.org
> > ---
> >  fs/file.c| 35 +++
> >  include/linux/file.h |  1 +
> >  net/compat.c | 10 +-
> >  net/core/scm.c   | 14 --
> >  4 files changed, 45 insertions(+), 15 deletions(-)
> > 
> > diff --git a/fs/file.c b/fs/file.c
> > index abb8b7081d7a..5afd76fca8c2 100644
> > --- a/fs/file.c
> > +++ b/fs/file.c
> > @@ -18,6 +18,9 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> > +#include 
> > +#include 
> >  
> >  unsigned int sysctl_nr_open __read_mostly = 1024*1024;
> >  unsigned int sysctl_nr_open_min = BITS_PER_LONG;
> > @@ -931,6 +934,38 @@ int replace_fd(unsigned fd, struct file *file, 
> > unsigned flags)
> > return err;
> >  }
> >  
> > +/*
> > + * File Receive - Receive a file from another process
> > + *
> > + * This function is designed to receive files from other tasks. It 
> > encapsulates
> > + * logic around security and cgroups. The file descriptor provided must be 
> > a
> > + * freshly allocated (unused) file descriptor.
> > + *
> > + * This helper does not consume a reference to the file, so the caller 
> > must put
> > + * their reference.
> > + *
> > + * Returns 0 upon success.
> > + */
> > +int file_receive(int fd, struct file *file)
> 
> This is all just a remote version of fd_install(), yet it deviates from
> fd_install()'s semantics and naming. That's not great imho. What about
> naming this something like:
> 
> fd_install_received()
> 
> and move the get_file() out of there so it has the same semantics as
> fd_install(). It seems rather dangerous to have a function like
> fd_install() that consumes a reference once it returned and another
> version of this that is basically the same thing but doesn't consume a
> reference because it takes its own. Seems an invitation for confusion.
> Does that make sense?
> 
You're right. The reason for the difference in my mind is that fd_install
always succeeds, whereas file_receive can fail. It's easier to do something
like:
fd_install(fd, get_file(f))
vs.
if (file_receive(fd, get_file(f))
fput(f);

Alternatively, if the reference was always consumed, it is somewhat
easier.

I'm fine either way, but just explaining my reasoning for the difference
in behaviour.

[PATCH v2 1/8] powerpc/watchpoint: Fix 512 byte boundary limit

[Ravi Bangoria]

Milton reported that we are aligning start and end address to wrong
size SZ_512M. It should be SZ_512. Fix that.

While doing this change I also found a case where ALIGN() comparison
fails. Within a given aligned range, ALIGN() of two addresses does not
match when start address is pointing to the first byte and end address
is pointing to any other byte except the first one. But that's not true
for ALIGN_DOWN(). ALIGN_DOWN() of any two addresses within that range
will always point to the first byte. So use ALIGN_DOWN() instead of
ALIGN().

Fixes: e68ef121c1f4 ("powerpc/watchpoint: Use builtin ALIGN*() macros")
Reported-by: Milton Miller 
Signed-off-by: Ravi Bangoria 
---
 arch/powerpc/kernel/hw_breakpoint.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/kernel/hw_breakpoint.c 
b/arch/powerpc/kernel/hw_breakpoint.c
index daf0e1da..031e6defc08e 100644
--- a/arch/powerpc/kernel/hw_breakpoint.c
+++ b/arch/powerpc/kernel/hw_breakpoint.c
@@ -419,7 +419,7 @@ static int hw_breakpoint_validate_len(struct 
arch_hw_breakpoint *hw)
if (dawr_enabled()) {
max_len = DAWR_MAX_LEN;
/* DAWR region can't cross 512 bytes boundary */
-   if (ALIGN(start_addr, SZ_512M) != ALIGN(end_addr - 1, SZ_512M))
+   if (ALIGN_DOWN(start_addr, SZ_512) != ALIGN_DOWN(end_addr - 1, 
SZ_512))
return -EINVAL;
} else if (IS_ENABLED(CONFIG_PPC_8xx)) {
/* 8xx can setup a range without limitation */
-- 
2.26.2

[PATCH v2 7/8] powerpc/watchpoint: Return available watchpoints dynamically

[Ravi Bangoria]

So far Book3S Powerpc supported only one watchpoint. Power10 is
introducing 2nd DAWR. Enable 2nd DAWR support for Power10.
Availability of 2nd DAWR will depend on CPU_FTR_DAWR1.

Signed-off-by: Ravi Bangoria 
---
 arch/powerpc/include/asm/cputable.h  | 4 +++-
 arch/powerpc/include/asm/hw_breakpoint.h | 5 +++--
 2 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/include/asm/cputable.h 
b/arch/powerpc/include/asm/cputable.h
index 3445c86e1f6f..36a0851a7a9b 100644
--- a/arch/powerpc/include/asm/cputable.h
+++ b/arch/powerpc/include/asm/cputable.h
@@ -633,7 +633,9 @@ enum {
  * Maximum number of hw breakpoint supported on powerpc. Number of
  * breakpoints supported by actual hw might be less than this.
  */
-#define HBP_NUM_MAX1
+#define HBP_NUM_MAX2
+#define HBP_NUM_ONE1
+#define HBP_NUM_TWO2
 
 #endif /* !__ASSEMBLY__ */
 
diff --git a/arch/powerpc/include/asm/hw_breakpoint.h 
b/arch/powerpc/include/asm/hw_breakpoint.h
index cb424799da0d..d4eab1694bcd 100644
--- a/arch/powerpc/include/asm/hw_breakpoint.h
+++ b/arch/powerpc/include/asm/hw_breakpoint.h
@@ -5,10 +5,11 @@
  * Copyright 2010, IBM Corporation.
  * Author: K.Prasad 
  */
-
 #ifndef _PPC_BOOK3S_64_HW_BREAKPOINT_H
 #define _PPC_BOOK3S_64_HW_BREAKPOINT_H
 
+#include 
+
 #ifdef __KERNEL__
 struct arch_hw_breakpoint {
unsigned long   address;
@@ -46,7 +47,7 @@ struct arch_hw_breakpoint {
 
 static inline int nr_wp_slots(void)
 {
-   return HBP_NUM_MAX;
+   return cpu_has_feature(CPU_FTR_DAWR1) ? HBP_NUM_TWO : HBP_NUM_ONE;
 }
 
 #ifdef CONFIG_HAVE_HW_BREAKPOINT
-- 
2.26.2

[PATCH v2 2/8] powerpc/watchpoint: Enable watchpoint functionality on power10 guest

[Ravi Bangoria]

CPU_FTR_DAWR is by default enabled for host via CPU_FTRS_DT_CPU_BASE
(controlled by CONFIG_PPC_DT_CPU_FTRS). But cpu-features device-tree
node is not PAPR compatible and thus not yet used by kvm or pHyp
guests. Enable watchpoint functionality on power10 guest (both kvm
and powervm) by adding CPU_FTR_DAWR to CPU_FTRS_POWER10. Note that
this change does not enable 2nd DAWR support.

Signed-off-by: Ravi Bangoria 
---
 arch/powerpc/include/asm/cputable.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/include/asm/cputable.h 
b/arch/powerpc/include/asm/cputable.h
index bac2252c839e..e506d429b1af 100644
--- a/arch/powerpc/include/asm/cputable.h
+++ b/arch/powerpc/include/asm/cputable.h
@@ -478,7 +478,7 @@ static inline void cpu_feature_keys_init(void) { }
CPU_FTR_CFAR | CPU_FTR_HVMODE | CPU_FTR_VMX_COPY | \
CPU_FTR_DBELL | CPU_FTR_HAS_PPR | CPU_FTR_ARCH_207S | \
CPU_FTR_TM_COMP | CPU_FTR_ARCH_300 | CPU_FTR_PKEY | \
-   CPU_FTR_ARCH_31)
+   CPU_FTR_ARCH_31 | CPU_FTR_DAWR)
 #define CPU_FTRS_CELL  (CPU_FTR_LWSYNC | \
CPU_FTR_PPCAS_ARCH_V2 | CPU_FTR_CTRL | \
CPU_FTR_ALTIVEC_COMP | CPU_FTR_MMCRA | CPU_FTR_SMT | \
-- 
2.26.2

[PATCH v2 4/8] powerpc/watchpoint: Set CPU_FTR_DAWR1 based on pa-features bit

[Ravi Bangoria]

As per the PAPR, bit 0 of byte 64 in pa-features property indicates
availability of 2nd DAWR registers. i.e. If this bit is set, 2nd
DAWR is present, otherwise not. Host generally uses "cpu-features",
which masks "pa-features". But "cpu-features" are still not used for
guests and thus this change is mostly applicable for guests only.

Signed-off-by: Ravi Bangoria 
---
 arch/powerpc/kernel/prom.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
index 6a3bac357e24..34272cef8ae6 100644
--- a/arch/powerpc/kernel/prom.c
+++ b/arch/powerpc/kernel/prom.c
@@ -175,6 +175,8 @@ static struct ibm_pa_feature {
 */
{ .pabyte = 22, .pabit = 0, .cpu_features = CPU_FTR_TM_COMP,
  .cpu_user_ftrs2 = PPC_FEATURE2_HTM_COMP | PPC_FEATURE2_HTM_NOSC_COMP 
},
+
+   { .pabyte = 64, .pabit = 0, .cpu_features = CPU_FTR_DAWR1 },
 };
 
 static void __init scan_features(unsigned long node, const unsigned char *ftrs,
-- 
2.26.2

[PATCH v2 6/8] powerpc/watchpoint: Guest support for 2nd DAWR hcall

[Ravi Bangoria]

2nd DAWR can be set/unset using H_SET_MODE hcall with resource value 5.
Enable powervm guest support with that. This has no effect on kvm guest
because kvm will return error if guest does hcall with resource value 5.

Signed-off-by: Ravi Bangoria 
---
 arch/powerpc/include/asm/hvcall.h | 1 +
 arch/powerpc/include/asm/machdep.h| 2 +-
 arch/powerpc/include/asm/plpar_wrappers.h | 5 +
 arch/powerpc/kernel/dawr.c| 2 +-
 arch/powerpc/platforms/pseries/setup.c| 7 +--
 5 files changed, 13 insertions(+), 4 deletions(-)

diff --git a/arch/powerpc/include/asm/hvcall.h 
b/arch/powerpc/include/asm/hvcall.h
index a7f6f1aeda6b..3f170b9496a1 100644
--- a/arch/powerpc/include/asm/hvcall.h
+++ b/arch/powerpc/include/asm/hvcall.h
@@ -357,6 +357,7 @@
 #define H_SET_MODE_RESOURCE_SET_DAWR0  2
 #define H_SET_MODE_RESOURCE_ADDR_TRANS_MODE3
 #define H_SET_MODE_RESOURCE_LE 4
+#define H_SET_MODE_RESOURCE_SET_DAWR1  5
 
 /* Values for argument to H_SIGNAL_SYS_RESET */
 #define H_SIGNAL_SYS_RESET_ALL -1
diff --git a/arch/powerpc/include/asm/machdep.h 
b/arch/powerpc/include/asm/machdep.h
index 7bcb6a39..a90b892f0bfe 100644
--- a/arch/powerpc/include/asm/machdep.h
+++ b/arch/powerpc/include/asm/machdep.h
@@ -131,7 +131,7 @@ struct machdep_calls {
unsigned long dabrx);
 
/* Set DAWR for this platform, leave empty for default implementation */
-   int (*set_dawr)(unsigned long dawr,
+   int (*set_dawr)(int nr, unsigned long dawr,
unsigned long dawrx);
 
 #ifdef CONFIG_PPC32/* XXX for now */
diff --git a/arch/powerpc/include/asm/plpar_wrappers.h 
b/arch/powerpc/include/asm/plpar_wrappers.h
index 93eb133d572c..d7a1acc83593 100644
--- a/arch/powerpc/include/asm/plpar_wrappers.h
+++ b/arch/powerpc/include/asm/plpar_wrappers.h
@@ -315,6 +315,11 @@ static inline long plpar_set_watchpoint0(unsigned long 
dawr0, unsigned long dawr
return plpar_set_mode(0, H_SET_MODE_RESOURCE_SET_DAWR0, dawr0, dawrx0);
 }
 
+static inline long plpar_set_watchpoint1(unsigned long dawr1, unsigned long 
dawrx1)
+{
+   return plpar_set_mode(0, H_SET_MODE_RESOURCE_SET_DAWR1, dawr1, dawrx1);
+}
+
 static inline long plpar_signal_sys_reset(long cpu)
 {
return plpar_hcall_norets(H_SIGNAL_SYS_RESET, cpu);
diff --git a/arch/powerpc/kernel/dawr.c b/arch/powerpc/kernel/dawr.c
index 500f52fa4711..cdc2dccb987d 100644
--- a/arch/powerpc/kernel/dawr.c
+++ b/arch/powerpc/kernel/dawr.c
@@ -37,7 +37,7 @@ int set_dawr(int nr, struct arch_hw_breakpoint *brk)
dawrx |= (mrd & 0x3f) << (63 - 53);
 
if (ppc_md.set_dawr)
-   return ppc_md.set_dawr(dawr, dawrx);
+   return ppc_md.set_dawr(nr, dawr, dawrx);
 
if (nr == 0) {
mtspr(SPRN_DAWR0, dawr);
diff --git a/arch/powerpc/platforms/pseries/setup.c 
b/arch/powerpc/platforms/pseries/setup.c
index 64d18f4bf093..b001cde1a2d7 100644
--- a/arch/powerpc/platforms/pseries/setup.c
+++ b/arch/powerpc/platforms/pseries/setup.c
@@ -832,12 +832,15 @@ static int pseries_set_xdabr(unsigned long dabr, unsigned 
long dabrx)
return plpar_hcall_norets(H_SET_XDABR, dabr, dabrx);
 }
 
-static int pseries_set_dawr(unsigned long dawr, unsigned long dawrx)
+static int pseries_set_dawr(int nr, unsigned long dawr, unsigned long dawrx)
 {
/* PAPR says we can't set HYP */
dawrx &= ~DAWRX_HYP;
 
-   return  plpar_set_watchpoint0(dawr, dawrx);
+   if (nr == 0)
+   return plpar_set_watchpoint0(dawr, dawrx);
+   else
+   return plpar_set_watchpoint1(dawr, dawrx);
 }
 
 #define CMO_CHARACTERISTICS_TOKEN 44
-- 
2.26.2

[PATCH v2 3/8] powerpc/dt_cpu_ftrs: Add feature for 2nd DAWR

[Ravi Bangoria]

Add new device-tree feature for 2nd DAWR. If this feature is present,
2nd DAWR is supported, otherwise not.

Signed-off-by: Ravi Bangoria 
---
 arch/powerpc/include/asm/cputable.h | 7 +--
 arch/powerpc/kernel/dt_cpu_ftrs.c   | 7 +++
 2 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/include/asm/cputable.h 
b/arch/powerpc/include/asm/cputable.h
index e506d429b1af..3445c86e1f6f 100644
--- a/arch/powerpc/include/asm/cputable.h
+++ b/arch/powerpc/include/asm/cputable.h
@@ -214,6 +214,7 @@ static inline void cpu_feature_keys_init(void) { }
 #define CPU_FTR_P9_TLBIE_ERAT_BUG  LONG_ASM_CONST(0x0001)
 #define CPU_FTR_P9_RADIX_PREFETCH_BUG  LONG_ASM_CONST(0x0002)
 #define CPU_FTR_ARCH_31
LONG_ASM_CONST(0x0004)
+#define CPU_FTR_DAWR1  LONG_ASM_CONST(0x0008)
 
 #ifndef __ASSEMBLY__
 
@@ -497,14 +498,16 @@ static inline void cpu_feature_keys_init(void) { }
 #define CPU_FTRS_POSSIBLE  \
(CPU_FTRS_POWER7 | CPU_FTRS_POWER8E | CPU_FTRS_POWER8 | \
 CPU_FTR_ALTIVEC_COMP | CPU_FTR_VSX_COMP | CPU_FTRS_POWER9 | \
-CPU_FTRS_POWER9_DD2_1 | CPU_FTRS_POWER9_DD2_2 | CPU_FTRS_POWER10)
+CPU_FTRS_POWER9_DD2_1 | CPU_FTRS_POWER9_DD2_2 | CPU_FTRS_POWER10 | 
\
+CPU_FTR_DAWR1)
 #else
 #define CPU_FTRS_POSSIBLE  \
(CPU_FTRS_PPC970 | CPU_FTRS_POWER5 | \
 CPU_FTRS_POWER6 | CPU_FTRS_POWER7 | CPU_FTRS_POWER8E | \
 CPU_FTRS_POWER8 | CPU_FTRS_CELL | CPU_FTRS_PA6T | \
 CPU_FTR_VSX_COMP | CPU_FTR_ALTIVEC_COMP | CPU_FTRS_POWER9 | \
-CPU_FTRS_POWER9_DD2_1 | CPU_FTRS_POWER9_DD2_2 | CPU_FTRS_POWER10)
+CPU_FTRS_POWER9_DD2_1 | CPU_FTRS_POWER9_DD2_2 | CPU_FTRS_POWER10 | 
\
+CPU_FTR_DAWR1)
 #endif /* CONFIG_CPU_LITTLE_ENDIAN */
 #endif
 #else
diff --git a/arch/powerpc/kernel/dt_cpu_ftrs.c 
b/arch/powerpc/kernel/dt_cpu_ftrs.c
index 3a409517c031..eafd713ca23d 100644
--- a/arch/powerpc/kernel/dt_cpu_ftrs.c
+++ b/arch/powerpc/kernel/dt_cpu_ftrs.c
@@ -574,6 +574,12 @@ static int __init feat_enable_mma(struct dt_cpu_feature *f)
return 1;
 }
 
+static int __init feat_enable_dawr1(struct dt_cpu_feature *f)
+{
+   cur_cpu_spec->cpu_features |= CPU_FTR_DAWR1;
+   return 1;
+}
+
 struct dt_cpu_feature_match {
const char *name;
int (*enable)(struct dt_cpu_feature *f);
@@ -649,6 +655,7 @@ static struct dt_cpu_feature_match __initdata
{"wait-v3", feat_enable, 0},
{"prefix-instructions", feat_enable, 0},
{"matrix-multiply-assist", feat_enable_mma, 0},
+   {"dawr1", feat_enable_dawr1, 0},
 };
 
 static bool __initdata using_dt_cpu_ftrs;
-- 
2.26.2

[PATCH v2 8/8] powerpc/watchpoint: Remove 512 byte boundary

[Ravi Bangoria]

Power10 has removed 512 bytes boundary from match criteria. i.e. The watch
range can cross 512 bytes boundary.

Signed-off-by: Ravi Bangoria 
---
 arch/powerpc/kernel/hw_breakpoint.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/kernel/hw_breakpoint.c 
b/arch/powerpc/kernel/hw_breakpoint.c
index 031e6defc08e..9a2899f25aae 100644
--- a/arch/powerpc/kernel/hw_breakpoint.c
+++ b/arch/powerpc/kernel/hw_breakpoint.c
@@ -418,8 +418,9 @@ static int hw_breakpoint_validate_len(struct 
arch_hw_breakpoint *hw)
 
if (dawr_enabled()) {
max_len = DAWR_MAX_LEN;
-   /* DAWR region can't cross 512 bytes boundary */
-   if (ALIGN_DOWN(start_addr, SZ_512) != ALIGN_DOWN(end_addr - 1, 
SZ_512))
+   /* DAWR region can't cross 512 bytes boundary on p10 
predecessors */
+   if (!cpu_has_feature(CPU_FTR_ARCH_31) &&
+   (ALIGN_DOWN(start_addr, SZ_512) != ALIGN_DOWN(end_addr - 1, 
SZ_512)))
return -EINVAL;
} else if (IS_ENABLED(CONFIG_PPC_8xx)) {
/* 8xx can setup a range without limitation */
-- 
2.26.2

[PATCH v2 0/8] powerpc/watchpoint: Enable 2nd DAWR on baremetal and powervm

[Ravi Bangoria]

Last series[1] was to add basic infrastructure support for more than
one watchpoint on Book3S powerpc. This series actually enables the 2nd 
DAWR for baremetal and powervm. Kvm guest is still not supported.

v1: 
https://lore.kernel.org/linuxppc-dev/20200602040106.127693-1-ravi.bango...@linux.ibm.com

v1->v2:
  - Milton reported an issue with one patch in last series[1]. patch #1
fixes that. So patch#1 is new.
  - Rebased to powerpc/next which now has "Base support for POWER10"[2]
series included.

[1]: 
https://lore.kernel.org/linuxppc-dev/20200514111741.97993-1-ravi.bango...@linux.ibm.com/
[2]: 
https://lore.kernel.org/linuxppc-dev/20200521014341.29095-1-alist...@popple.id.au

Ravi Bangoria (8):
  powerpc/watchpoint: Fix 512 byte boundary limit
  powerpc/watchpoint: Enable watchpoint functionality on power10 guest
  powerpc/dt_cpu_ftrs: Add feature for 2nd DAWR
  powerpc/watchpoint: Set CPU_FTR_DAWR1 based on pa-features bit
  powerpc/watchpoint: Rename current H_SET_MODE DAWR macro
  powerpc/watchpoint: Guest support for 2nd DAWR hcall
  powerpc/watchpoint: Return available watchpoints dynamically
  powerpc/watchpoint: Remove 512 byte boundary

 arch/powerpc/include/asm/cputable.h   | 13 +
 arch/powerpc/include/asm/hvcall.h |  3 ++-
 arch/powerpc/include/asm/hw_breakpoint.h  |  5 +++--
 arch/powerpc/include/asm/machdep.h|  2 +-
 arch/powerpc/include/asm/plpar_wrappers.h |  7 ++-
 arch/powerpc/kernel/dawr.c|  2 +-
 arch/powerpc/kernel/dt_cpu_ftrs.c |  7 +++
 arch/powerpc/kernel/hw_breakpoint.c   |  5 +++--
 arch/powerpc/kernel/prom.c|  2 ++
 arch/powerpc/kvm/book3s_hv.c  |  2 +-
 arch/powerpc/platforms/pseries/setup.c|  7 +--
 11 files changed, 40 insertions(+), 15 deletions(-)

-- 
2.26.2

[PATCH v2 5/8] powerpc/watchpoint: Rename current H_SET_MODE DAWR macro

[Ravi Bangoria]

Current H_SET_MODE hcall macro name for setting/resetting DAWR0 is
H_SET_MODE_RESOURCE_SET_DAWR. Add suffix 0 to macro name as well.

Signed-off-by: Ravi Bangoria 
---
 arch/powerpc/include/asm/hvcall.h | 2 +-
 arch/powerpc/include/asm/plpar_wrappers.h | 2 +-
 arch/powerpc/kvm/book3s_hv.c  | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/include/asm/hvcall.h 
b/arch/powerpc/include/asm/hvcall.h
index e90c073e437e..a7f6f1aeda6b 100644
--- a/arch/powerpc/include/asm/hvcall.h
+++ b/arch/powerpc/include/asm/hvcall.h
@@ -354,7 +354,7 @@
 
 /* Values for 2nd argument to H_SET_MODE */
 #define H_SET_MODE_RESOURCE_SET_CIABR  1
-#define H_SET_MODE_RESOURCE_SET_DAWR   2
+#define H_SET_MODE_RESOURCE_SET_DAWR0  2
 #define H_SET_MODE_RESOURCE_ADDR_TRANS_MODE3
 #define H_SET_MODE_RESOURCE_LE 4
 
diff --git a/arch/powerpc/include/asm/plpar_wrappers.h 
b/arch/powerpc/include/asm/plpar_wrappers.h
index 4497c8afb573..93eb133d572c 100644
--- a/arch/powerpc/include/asm/plpar_wrappers.h
+++ b/arch/powerpc/include/asm/plpar_wrappers.h
@@ -312,7 +312,7 @@ static inline long plpar_set_ciabr(unsigned long ciabr)
 
 static inline long plpar_set_watchpoint0(unsigned long dawr0, unsigned long 
dawrx0)
 {
-   return plpar_set_mode(0, H_SET_MODE_RESOURCE_SET_DAWR, dawr0, dawrx0);
+   return plpar_set_mode(0, H_SET_MODE_RESOURCE_SET_DAWR0, dawr0, dawrx0);
 }
 
 static inline long plpar_signal_sys_reset(long cpu)
diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
index a0cf17597838..26820b7bd75c 100644
--- a/arch/powerpc/kvm/book3s_hv.c
+++ b/arch/powerpc/kvm/book3s_hv.c
@@ -766,7 +766,7 @@ static int kvmppc_h_set_mode(struct kvm_vcpu *vcpu, 
unsigned long mflags,
return H_P3;
vcpu->arch.ciabr  = value1;
return H_SUCCESS;
-   case H_SET_MODE_RESOURCE_SET_DAWR:
+   case H_SET_MODE_RESOURCE_SET_DAWR0:
if (!kvmppc_power8_compatible(vcpu))
return H_P2;
if (!ppc_breakpoint_available())
-- 
2.26.2

Re: [PATCH 00/10] Remove uninitialized_var() macro

[Nathan Chancellor]

On Wed, Jun 03, 2020 at 04:31:53PM -0700, Kees Cook wrote:
> Using uninitialized_var() is dangerous as it papers over real bugs[1]
> (or can in the future), and suppresses unrelated compiler warnings
> (e.g. "unused variable"). If the compiler thinks it is uninitialized,
> either simply initialize the variable or make compiler changes.
> 
> As recommended[2] by[3] Linus[4], remove the macro.
> 
> Most of the 300 uses don't cause any warnings on gcc 9.3.0, so they're in
> a single treewide commit in this series. A few others needed to actually
> get cleaned up, and I broke those out into individual patches.
> 
> -Kees
> 
> [1] https://lore.kernel.org/lkml/20200603174714.192027-1-gli...@google.com/
> [2] 
> https://lore.kernel.org/lkml/CA+55aFw+Vbj0i=1tgqcr5vqkczwj0qxk6cernou6eedsuda...@mail.gmail.com/
> [3] 
> https://lore.kernel.org/lkml/ca+55afwgbgqhbp1fkxvrkepzyr5j8n1vkt1vzdz9knmpuxh...@mail.gmail.com/
> [4] 
> https://lore.kernel.org/lkml/CA+55aFz2500WfbKXAx8s67wrm9=yvju65tplgn_ybynv0ve...@mail.gmail.com/
> 
> Kees Cook (10):
>   x86/mm/numa: Remove uninitialized_var() usage
>   drbd: Remove uninitialized_var() usage
>   b43: Remove uninitialized_var() usage
>   rtlwifi: rtl8192cu: Remove uninitialized_var() usage
>   ide: Remove uninitialized_var() usage
>   clk: st: Remove uninitialized_var() usage
>   spi: davinci: Remove uninitialized_var() usage
>   checkpatch: Remove awareness of uninitialized_var() macro
>   treewide: Remove uninitialized_var() usage
>   compiler: Remove uninitialized_var() macro

I applied all of these on top of cb8e59cc8720 and ran a variety of
builds with clang for arm32, arm64, mips, powerpc, s390, and x86_64 [1]
and only saw one warning pop up (which was about a variable being
unused, commented on patch 9 about it). No warnings about uninitialized
variables came up; clang's -Wuninitialized was not impacted by
78a5255ffb6a ("Stop the ad-hoc games with -Wno-maybe-initialized") so it
should have caught anything egregious.

[1]: https://github.com/nathanchance/llvm-kernel-testing

For the series, consider it:

Tested-by: Nathan Chancellor  [build]

Re: [PATCH 2/9] rcu: Fixup noinstr warnings

[Paul E. McKenney]

On Wed, Jun 03, 2020 at 07:13:20PM +0200, Peter Zijlstra wrote:
> On Wed, Jun 03, 2020 at 09:46:00AM -0700, Paul E. McKenney wrote:
> 
> > > --- a/kernel/rcu/tree.c
> > > +++ b/kernel/rcu/tree.c
> > > @@ -250,7 +250,7 @@ static noinstr void rcu_dynticks_eqs_ent
> > >* next idle sojourn.
> > >*/
> > >   rcu_dynticks_task_trace_enter();  // Before ->dynticks update!
> > > - seq = atomic_add_return(RCU_DYNTICK_CTRL_CTR, >dynticks);
> > > + seq = arch_atomic_add_return(RCU_DYNTICK_CTRL_CTR, >dynticks);
> > 
> > To preserve KCSAN's ability to see this, there would be something like
> > instrument_atomic_write(>dynticks, sizeof(rdp->dynticks)) prior
> > to the instrumentation_end() invoked before rcu_dynticks_eqs_enter()
> > in each of rcu_eqs_enter() and rcu_nmi_exit(), correct?
> 
> Yes.
> 
> > >   // RCU is no longer watching.  Better be in extended quiescent state!
> > >   WARN_ON_ONCE(IS_ENABLED(CONFIG_RCU_EQS_DEBUG) &&
> > >(seq & RCU_DYNTICK_CTRL_CTR));
> > > @@ -274,13 +274,13 @@ static noinstr void rcu_dynticks_eqs_exi
> > >* and we also must force ordering with the next RCU read-side
> > >* critical section.
> > >*/
> > > - seq = atomic_add_return(RCU_DYNTICK_CTRL_CTR, >dynticks);
> > > + seq = arch_atomic_add_return(RCU_DYNTICK_CTRL_CTR, >dynticks);
> > 
> > And same here, but after the instrumentation_begin() following
> > rcu_dynticks_eqs_exit() in both rcu_eqs_exit() and rcu_nmi_enter(),
> > correct?
> 
> Yep.
> 
> > >   // RCU is now watching.  Better not be in an extended quiescent state!
> > >   rcu_dynticks_task_trace_exit();  // After ->dynticks update!
> > >   WARN_ON_ONCE(IS_ENABLED(CONFIG_RCU_EQS_DEBUG) &&
> > >!(seq & RCU_DYNTICK_CTRL_CTR));
> > >   if (seq & RCU_DYNTICK_CTRL_MASK) {
> > > - atomic_andnot(RCU_DYNTICK_CTRL_MASK, >dynticks);
> > > + arch_atomic_andnot(RCU_DYNTICK_CTRL_MASK, >dynticks);
> > 
> > This one is gone in -rcu.
> 
> Good, because that would make things 'complicated' with the external
> instrumentation call. And is actually the reason I didn't even attempt
> it this time around.
> 
> > >   smp_mb__after_atomic(); /* _exit after clearing mask. */
> > >   }
> > >  }
> > > @@ -313,7 +313,7 @@ static __always_inline bool rcu_dynticks
> > >  {
> > >   struct rcu_data *rdp = this_cpu_ptr(_data);
> > >  
> > > - return !(atomic_read(>dynticks) & RCU_DYNTICK_CTRL_CTR);
> > > + return !(arch_atomic_read(>dynticks) & RCU_DYNTICK_CTRL_CTR);
> 
> The above is actually instrumented by KCSAN, due to arch_atomic_read()
> being a READ_ONCE() and it now understanding volatile.
> 
> > Also instrument_atomic_write(>dynticks, sizeof(rdp->dynticks)) as

Right, this should instead be instrument_read(...).

Though if KCSAN is unconditionally instrumenting volatile, how does
this help?  Or does KCSAN's instrumentation of volatile somehow avoid
causing trouble?

> > follows:
> > 
> > o   rcu_nmi_exit(): After each following instrumentation_begin().
> 
> Yes
> 
> > o   In theory in rcu_irq_exit_preempt(), but as this generates code
> > only in lockdep builds, it might not be worth worrying about.
> > 
> > o   Ditto for rcu_irq_exit_check_preempt().
> > 
> > o   Ditto for __rcu_irq_enter_check_tick().
> 
> Not these, afaict they're all the above arch_atomic_read(), which is
> instrumented due to volatile in these cases.
> 
> > o   rcu_nmi_enter(): After each following instrumentation_begin().
> 
> Yes
> 
> > o   __rcu_is_watching() is itself noinstr:
> > 
> > o   idtentry_enter_cond_rcu(): After each following
> > instrumentation_begin().
> > 
> > o   rcu_is_watching(): Either before or after the call to
> > rcu_dynticks_curr_cpu_in_eqs().
> 
> Something like that yes.
> 
> > >  }
> > >  
> > >  /*
> > > @@ -692,6 +692,7 @@ noinstr void rcu_nmi_exit(void)
> > >  {
> > >   struct rcu_data *rdp = this_cpu_ptr(_data);
> > >  
> > > + instrumentation_begin();
> > >   /*
> > >* Check for ->dynticks_nmi_nesting underflow and bad ->dynticks.
> > >* (We are exiting an NMI handler, so RCU better be paying attention
> > > @@ -705,7 +706,6 @@ noinstr void rcu_nmi_exit(void)
> > >* leave it in non-RCU-idle state.
> > >*/
> > >   if (rdp->dynticks_nmi_nesting != 1) {
> > > - instrumentation_begin();
> > >   trace_rcu_dyntick(TPS("--="), rdp->dynticks_nmi_nesting, 
> > > rdp->dynticks_nmi_nesting - 2,
> > > atomic_read(>dynticks));
> > >   WRITE_ONCE(rdp->dynticks_nmi_nesting, /* No store tearing. */
> > > @@ -714,7 +714,6 @@ noinstr void rcu_nmi_exit(void)
> > >   return;
> > >   }
> > >  
> > > - instrumentation_begin();
> > >   /* This NMI interrupted an RCU-idle CPU, restore RCU-idleness. */
> > >   trace_rcu_dyntick(TPS("Startirq"), rdp->dynticks_nmi_nesting, 0, 
> > > atomic_read(>dynticks));
> > >   WRITE_ONCE(rdp->dynticks_nmi_nesting, 0); /* Avoid store tearing. */
> > 
> > This one looks to be having no effect on 

Re: [PATCH 09/10] treewide: Remove uninitialized_var() usage

[Nathan Chancellor]

On Wed, Jun 03, 2020 at 04:32:02PM -0700, Kees Cook wrote:
> Using uninitialized_var() is dangerous as it papers over real bugs[1]
> (or can in the future), and suppresses unrelated compiler warnings
> (e.g. "unused variable"). If the compiler thinks it is uninitialized,
> either simply initialize the variable or make compiler changes.
> 
> I preparation for removing[2] the[3] macro[4], remove all remaining
> needless uses with the following script:
> 
> git grep '\buninitialized_var\b' | cut -d: -f1 | sort -u | \
>   xargs perl -pi -e \
>   's/\buninitialized_var\(([^\)]+)\)/\1/g;
>s:\s*/\* (GCC be quiet|to make compiler happy) \*/$::g;'
> 
> drivers/video/fbdev/riva/riva_hw.c was manually tweaked to avoid
> pathological white-space.
> 
> No outstanding warnings were found building allmodconfig with GCC 9.3.0
> for x86_64, i386, arm64, arm, powerpc, powerpc64le, s390x, mips, sparc64,
> alpha, and m68k.
> 
> [1] https://lore.kernel.org/lkml/20200603174714.192027-1-gli...@google.com/
> [2] 
> https://lore.kernel.org/lkml/CA+55aFw+Vbj0i=1tgqcr5vqkczwj0qxk6cernou6eedsuda...@mail.gmail.com/
> [3] 
> https://lore.kernel.org/lkml/ca+55afwgbgqhbp1fkxvrkepzyr5j8n1vkt1vzdz9knmpuxh...@mail.gmail.com/
> [4] 
> https://lore.kernel.org/lkml/CA+55aFz2500WfbKXAx8s67wrm9=yvju65tplgn_ybynv0ve...@mail.gmail.com/
> 
> Signed-off-by: Kees Cook 



> diff --git a/arch/powerpc/kvm/book3s_pr.c b/arch/powerpc/kvm/book3s_pr.c
> index a0f6813f4560..a71fa7204882 100644
> --- a/arch/powerpc/kvm/book3s_pr.c
> +++ b/arch/powerpc/kvm/book3s_pr.c
> @@ -1829,7 +1829,7 @@ static int kvmppc_vcpu_run_pr(struct kvm_run *kvm_run, 
> struct kvm_vcpu *vcpu)
>  {
>   int ret;
>  #ifdef CONFIG_ALTIVEC
> - unsigned long uninitialized_var(vrsave);
> + unsigned long vrsave;
>  #endif

This variable is actually unused:

../arch/powerpc/kvm/book3s_pr.c:1832:16: warning: unused variable 'vrsave' 
[-Wunused-variable]
unsigned long vrsave;
  ^
1 warning generated.

It has been unused since commit 99dae3bad28d ("KVM: PPC: Load/save
FP/VMX/VSX state directly to/from vcpu struct").

$ git grep vrsave 99dae3bad28d8fdd32b7bfdd5e2ec7bb2d4d019d 
arch/powerpc/kvm/book3s_pr.c
99dae3bad28d8fdd32b7bfdd5e2ec7bb2d4d019d:arch/powerpc/kvm/book3s_pr.c:  
unsigned long uninitialized_var(vrsave);

I would nuke the whole '#ifdef' block.

Cheers,
Nathan

[PATCH] crypto: hisilicon - fix strncpy warning with strlcpy

[Zhangfei Gao]

Use strlcpy to fix the warning
warning: 'strncpy' specified bound 64 equals destination size
 [-Wstringop-truncation]

Reported-by: kernel test robot 
Signed-off-by: Zhangfei Gao 
---
 drivers/crypto/hisilicon/qm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/crypto/hisilicon/qm.c b/drivers/crypto/hisilicon/qm.c
index f795fb5..224f3e2 100644
--- a/drivers/crypto/hisilicon/qm.c
+++ b/drivers/crypto/hisilicon/qm.c
@@ -1574,7 +1574,7 @@ static int qm_alloc_uacce(struct hisi_qm *qm)
.ops = _qm_ops,
};
 
-   strncpy(interface.name, pdev->driver->name, sizeof(interface.name));
+   strlcpy(interface.name, pdev->driver->name, sizeof(interface.name));
 
uacce = uacce_alloc(>dev, );
if (IS_ERR(uacce))
-- 
2.7.4

Re: [PATCH] function:stacktrace/mips: Fix function:stacktrace for mips

[yuanjunqing]

在 2020/6/4 上午9:17, Maciej W. Rozycki 写道:
> On Fri, 29 May 2020, WANG Xuerui wrote:
>
>> On 2020/5/29 17:29, yuanjunqing wrote:
>>
 diff --git a/arch/mips/kernel/mcount.S b/arch/mips/kernel/mcount.S
 index cff52b283e03..cd5545764e5f 100644
 --- a/arch/mips/kernel/mcount.S
 +++ b/arch/mips/kernel/mcount.S
 @@ -87,8 +87,15 @@ EXPORT_SYMBOL(_mcount)
PTR_LA   t1, _etext
sltu t3, t1, a0 /* t3 = (a0 > _etext) */
or   t1, t2, t3
 +  PTR_LA   t2, stlab-4/* t2: "function:stacktrace" return address */
 +  move a1, AT /* arg2: parent's return address */
beqz t1, ftrace_call
 -   nop
 +   nop/* "function:stacktrace" return address */
 +stlab:
 +  PTR_LA  t2, stlab-4
 +  /* ftrace_call_end: ftrace_call return address */
 +  beq t2,ra, ftrace_call_end
 +  nop
>  Broken delay slot indentation.

Thank you for your reply. For this question that you mentioned about the delay 
slot, I will modify my patch again.

>
   #if defined(KBUILD_MCOUNT_RA_ADDRESS) && defined(CONFIG_32BIT)
PTR_SUBU a0, a0, 16 /* arg1: adjust to module's recorded callsite */
   #else
 @@ -98,7 +105,9 @@ EXPORT_SYMBOL(_mcount)
.globl ftrace_call
   ftrace_call:
nop /* a placeholder for the call to a real tracing function */
 -   move   a1, AT  /* arg2: parent's return address */
 +  movera, t2  /* t2: "function:stacktrace" return address */
>  Likewise.  NB I haven't investigated if the change makes sense.  A more 
> detailed explanation in the change description is certainly needed.

I will attach a specific description for further explanation about the second 
patch later.

>
>   Maciej

Re: linux-next: manual merge of the kvm tree with the tip tree

[Stephen Rothwell]

Hi all,

On Tue, 2 Jun 2020 14:53:58 +1000 Stephen Rothwell  
wrote:
>
> Hi all,
> 
> Today's linux-next merge of the kvm tree got a conflict in:
> 
>   arch/x86/kernel/kvm.c
> 
> between commit:
> 
>   a707ae1a9bbb ("x86/entry: Switch page fault exception to IDTENTRY_RAW")
> 
> from the tip tree and commit:
> 
>   68fd66f100d1 ("KVM: x86: extend struct kvm_vcpu_pv_apf_data with token 
> info")
> 
> from the kvm 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 arch/x86/kernel/kvm.c
> index 07dc47359c4f,d6f22a3a1f7d..
> --- a/arch/x86/kernel/kvm.c
> +++ b/arch/x86/kernel/kvm.c
> @@@ -217,23 -218,23 +217,23 @@@ again
>   }
>   EXPORT_SYMBOL_GPL(kvm_async_pf_task_wake);
>   
> - u32 noinstr kvm_read_and_reset_pf_reason(void)
>  -u32 kvm_read_and_reset_apf_flags(void)
> ++u32 noinstr kvm_read_and_reset_apf_flags(void)
>   {
> - u32 reason = 0;
> + u32 flags = 0;
>   
>   if (__this_cpu_read(apf_reason.enabled)) {
> - reason = __this_cpu_read(apf_reason.reason);
> - __this_cpu_write(apf_reason.reason, 0);
> + flags = __this_cpu_read(apf_reason.flags);
> + __this_cpu_write(apf_reason.flags, 0);
>   }
>   
> - return reason;
> + return flags;
>   }
> - EXPORT_SYMBOL_GPL(kvm_read_and_reset_pf_reason);
> + EXPORT_SYMBOL_GPL(kvm_read_and_reset_apf_flags);
>  -NOKPROBE_SYMBOL(kvm_read_and_reset_apf_flags);
>   
>  -bool __kvm_handle_async_pf(struct pt_regs *regs, u32 token)
>  +noinstr bool __kvm_handle_async_pf(struct pt_regs *regs, u32 token)
>   {
> - u32 reason = kvm_read_and_reset_pf_reason();
> + u32 reason = kvm_read_and_reset_apf_flags();
>  +bool rcu_exit;
>   
>   switch (reason) {
>   case KVM_PV_REASON_PAGE_NOT_PRESENT:

This is now a conflict between the tip tree and Linus' tree.

-- 
Cheers,
Stephen Rothwell


pgpQBxIQK4a8B.pgp
Description: OpenPGP digital signature

Re: [PATCH net-next 5/5] hinic: add support to get eeprom information

[luobin (L)]

On 2020/6/4 11:01, Jakub Kicinski wrote:
> On Wed, 3 Jun 2020 14:20:15 +0800 Luo bin wrote:
>> add support to get eeprom information from the plug-in module
>> with ethtool -m cmd.
>>
>> Signed-off-by: Luo bin 
> 
> drivers/net/ethernet/huawei/hinic/hinic_port.c:1386:5: warning: variable 
> port_id set but not used [-Wunused-but-set-variable]
>  1386 |  u8 port_id;
>   | ^~~
> .
> 
Will fix. Thanks.

Re: [PATCH v2 3/7] Bluetooth: Add handler of MGMT_OP_ADD_ADV_PATTERNS_MONITOR

[Jakub Kicinski]

On Wed,  3 Jun 2020 16:01:46 -0700 Miao-chen Chou wrote:
> This adds the request handler of MGMT_OP_ADD_ADV_PATTERNS_MONITOR command.
> Note that the controller-based monitoring is not yet in place. This tracks
> the content of the monitor without sending HCI traffic, so the request
> returns immediately.
> 
> The following manual test was performed.
> - Issue btmgmt advmon-add with valid and invalid inputs.
> - Issue btmgmt advmon-add more the allowed number of monitors.
> 
> Signed-off-by: Miao-chen Chou 

Looks like this adds new sparse warnings:

net/bluetooth/mgmt.c:3886:32: warning: incorrect type in assignment (different 
base types)
net/bluetooth/mgmt.c:3886:32:expected unsigned int [usertype] 
supported_features
net/bluetooth/mgmt.c:3886:32:got restricted __le32 [usertype]
net/bluetooth/mgmt.c:3888:29: warning: incorrect type in assignment (different 
base types)
net/bluetooth/mgmt.c:3888:29:expected unsigned short [usertype] 
max_num_handles
net/bluetooth/mgmt.c:3888:29:got restricted __le16 [usertype]
net/bluetooth/mgmt.c:3890:25: warning: incorrect type in assignment (different 
base types)
net/bluetooth/mgmt.c:3890:25:expected unsigned short [usertype] num_handles
net/bluetooth/mgmt.c:3890:25:got restricted __le16 [usertype]

Please make sure patches build cleanly with W=1 C=1 flags.

Re: linux-next: manual merge of the kvm tree with the s390 tree

[Stephen Rothwell]

Hi all,

On Fri, 29 May 2020 16:46:13 +1000 Stephen Rothwell  
wrote:
>
> Today's linux-next merge of the kvm tree got a conflict in:
> 
>   arch/s390/kvm/vsie.c
> 
> between commit:
> 
>   0b0ed657fe00 ("s390: remove critical section cleanup from entry.S")
> 
> from the s390 tree and commit:
> 
>   d075fc3154be ("KVM: s390: vsie: Move conditional reschedule")
> 
> from the kvm tree.
> 
> diff --cc arch/s390/kvm/vsie.c
> index 4fde24a1856e,ef05b4e167fb..
> --- a/arch/s390/kvm/vsie.c
> +++ b/arch/s390/kvm/vsie.c
> @@@ -1000,9 -1000,9 +1000,6 @@@ static int do_vsie_run(struct kvm_vcpu 
>   
>   handle_last_fault(vcpu, vsie_page);
>   
> - if (need_resched())
> - schedule();
>  -if (test_cpu_flag(CIF_MCCK_PENDING))
>  -s390_handle_mcck();
> --
>   srcu_read_unlock(>kvm->srcu, vcpu->srcu_idx);
>   
>   /* save current guest state of bp isolation override */

This is now a conflict between the s390 tree and Linus' tree.

-- 
Cheers,
Stephen Rothwell


pgpS5qCLujoYM.pgp
Description: OpenPGP digital signature

[PATCH v4] usb: host: xhci-mtk: avoid runtime suspend when removing hcd

[Macpaul Lin]

When runtime suspend was enabled, runtime suspend might happen
when xhci is removing hcd. This might cause kernel panic when hcd
has been freed but runtime pm suspend related handle need to
reference it.

Signed-off-by: Macpaul Lin 
Reviewed-by: Chunfeng Yun 
Cc: sta...@vger.kernel.org
---
Changes for v3:
  - Replace better sequence for disabling the pm_runtime suspend.
Changes for v4:
  - Thanks for Sergei's review, typo in commit description has been corrected.

 drivers/usb/host/xhci-mtk.c |5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/host/xhci-mtk.c b/drivers/usb/host/xhci-mtk.c
index bfbdb3c..641d24e 100644
--- a/drivers/usb/host/xhci-mtk.c
+++ b/drivers/usb/host/xhci-mtk.c
@@ -587,6 +587,9 @@ static int xhci_mtk_remove(struct platform_device *dev)
struct xhci_hcd *xhci = hcd_to_xhci(hcd);
struct usb_hcd  *shared_hcd = xhci->shared_hcd;
 
+   pm_runtime_put_noidle(>dev);
+   pm_runtime_disable(>dev);
+
usb_remove_hcd(shared_hcd);
xhci->shared_hcd = NULL;
device_init_wakeup(>dev, false);
@@ -597,8 +600,6 @@ static int xhci_mtk_remove(struct platform_device *dev)
xhci_mtk_sch_exit(mtk);
xhci_mtk_clks_disable(mtk);
xhci_mtk_ldos_disable(mtk);
-   pm_runtime_put_sync(>dev);
-   pm_runtime_disable(>dev);
 
return 0;
 }
-- 
1.7.9.5

Re: [PATCH net-next 5/5] hinic: add support to get eeprom information

[Jakub Kicinski]

On Wed, 3 Jun 2020 14:20:15 +0800 Luo bin wrote:
> add support to get eeprom information from the plug-in module
> with ethtool -m cmd.
> 
> Signed-off-by: Luo bin 

drivers/net/ethernet/huawei/hinic/hinic_port.c:1386:5: warning: variable 
port_id set but not used [-Wunused-but-set-variable]
 1386 |  u8 port_id;
  | ^~~

[PATCH] iio: adc: mt6360: Add ADC driver for MT6360

[Gene Chen]

From: Gene Chen 

Add MT6360 ADC driver include Charger Current, Voltage, and
Temperature.

Signed-off-by: Gene Chen 
base-commit: 098c4adf249c198519a4abebe482b1e6b8c50e47
---
 drivers/iio/adc/Kconfig  |  11 ++
 drivers/iio/adc/Makefile |   1 +
 drivers/iio/adc/mt6360-adc.c | 419 +++
 3 files changed, 431 insertions(+)
 create mode 100644 drivers/iio/adc/mt6360-adc.c

diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index 12bb8b7..a9736ec 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -657,6 +657,17 @@ config MCP3911
  This driver can also be built as a module. If so, the module will be
  called mcp3911.
 
+config MEDIATEK_MT6360_ADC
+   tristate "Mediatek MT6360 ADC Part"
+   depends on MFD_MT6360
+   select IIO_BUFFER
+   select IIO_KFIFO_BUF
+   help
+ Say Y here to enable MT6360 ADC Part.
+ Integrated for System Monitoring include
+ Charger and Battery Current, Voltage and
+ Terperature
+
 config MEDIATEK_MT6577_AUXADC
tristate "MediaTek AUXADC driver"
depends on ARCH_MEDIATEK || COMPILE_TEST
diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
index 6378078..4209776 100644
--- a/drivers/iio/adc/Makefile
+++ b/drivers/iio/adc/Makefile
@@ -62,6 +62,7 @@ obj-$(CONFIG_MAX9611) += max9611.o
 obj-$(CONFIG_MCP320X) += mcp320x.o
 obj-$(CONFIG_MCP3422) += mcp3422.o
 obj-$(CONFIG_MCP3911) += mcp3911.o
+obj-$(CONFIG_MEDIATEK_MT6360_ADC) += mt6360-adc.o
 obj-$(CONFIG_MEDIATEK_MT6577_AUXADC) += mt6577_auxadc.o
 obj-$(CONFIG_MEN_Z188_ADC) += men_z188_adc.o
 obj-$(CONFIG_MESON_SARADC) += meson_saradc.o
diff --git a/drivers/iio/adc/mt6360-adc.c b/drivers/iio/adc/mt6360-adc.c
new file mode 100644
index 000..bc9c488
--- /dev/null
+++ b/drivers/iio/adc/mt6360-adc.c
@@ -0,0 +1,419 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2020 MediaTek Inc.
+ *
+ * Author: Gene Chen 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+/* CHG_CTRL3 0x13 */
+#define MT6360_AICR_MASK   (0xFC)
+#define MT6360_AICR_SHFT   (2)
+#define MT6360_AICR_400MA  (0x6)
+/* ADC_CONFIG 0x56 */
+#define MT6360_ADCEN_SHFT  (7)
+/* ADC_RPT_1 0x5A */
+#define MT6360_PREFERCH_MASK   (0xF0)
+#define MT6360_PREFERCH_SHFT   (4)
+#define MT6360_RPTCH_MASK  (0x0F)
+
+enum {
+   MT6360_CHAN_USBID = 0,
+   MT6360_CHAN_VBUSDIV5,
+   MT6360_CHAN_VBUSDIV2,
+   MT6360_CHAN_VSYS,
+   MT6360_CHAN_VBAT,
+   MT6360_CHAN_IBUS,
+   MT6360_CHAN_IBAT,
+   MT6360_CHAN_CHG_VDDP,
+   MT6360_CHAN_TEMP_JC,
+   MT6360_CHAN_VREF_TS,
+   MT6360_CHAN_TS,
+   MT6360_CHAN_MAX,
+};
+
+struct mt6360_adc_data {
+   struct device *dev;
+   struct regmap *regmap;
+   struct task_struct *scan_task;
+   struct completion adc_complete;
+   struct mutex adc_lock;
+   ktime_t last_off_timestamps[MT6360_CHAN_MAX];
+   int irq;
+};
+
+static inline int mt6360_adc_val_converte(int val, int multiplier,
+  int offset, int divisor)
+{
+   return ((val * multiplier) + offset) / divisor;
+}
+
+static int mt6360_adc_get_process_val(struct mt6360_adc_data *info,
+ int chan_idx, int *val)
+{
+   unsigned int regval = 0;
+   int ret;
+   const struct converter {
+   int multiplier;
+   int offset;
+   int divisor;
+   } adc_converter[MT6360_CHAN_MAX] = {
+   { 1250, 0, 1}, /* USBID */
+   { 6250, 0, 1}, /* VBUSDIV5 */
+   { 2500, 0, 1}, /* VBUSDIV2 */
+   { 1250, 0, 1}, /* VSYS */
+   { 1250, 0, 1}, /* VBAT */
+   { 2500, 0, 1}, /* IBUS */
+   { 2500, 0, 1}, /* IBAT */
+   { 1250, 0, 1}, /* CHG_VDDP */
+   { 105, -8000, 100}, /* TEMP_JC */
+   { 1250, 0, 1}, /* VREF_TS */
+   { 1250, 0, 1}, /* TS */
+   }, sp_ibus_adc_converter = { 1900, 0, 1 }, *sel_converter;
+
+   if (chan_idx < 0 || chan_idx >= MT6360_CHAN_MAX)
+   return -EINVAL;
+   sel_converter = adc_converter + chan_idx;
+   if (chan_idx == MT6360_CHAN_IBUS) {
+   /* ibus chan will be affected by aicr config */
+   /* if aicr < 400, apply the special ibus converter */
+   ret = regmap_read(info->regmap, MT6360_PMU_CHG_CTRL3, );
+   if (ret < 0)
+   return ret;
+   regval = (regval & MT6360_AICR_MASK) >> MT6360_AICR_SHFT;
+   if (regval < MT6360_AICR_400MA)
+   sel_converter = _ibus_adc_converter;
+   }
+   *val = mt6360_adc_val_converte(*val, sel_converter->multiplier,
+sel_converter->offset, 

Re: [PATCH v3 02/13] ata: ahci_brcm: Fix use of BCM7216 reset controller

[Florian Fainelli]

On 6/3/2020 12:20 PM, Jim Quinlan wrote:
> From: Jim Quinlan 
> 
> A reset controller "rescal" is shared between the AHCI driver and the PCIe
> driver for the BrcmSTB 7216 chip.  The code is modified to allow this
> sharing and to deassert() properly.
> 
> Signed-off-by: Jim Quinlan 
> 
> Fixes: 272ecd60a636 ("ata: ahci_brcm: BCM7216 reset is self de-asserting")
> Fixes: c345ec6a50e9 ("ata: ahci_brcm: Support BCM7216 reset controller
> name")
> ---

[snip]

> @@ -479,10 +478,7 @@ static int brcm_ahci_probe(struct platform_device *pdev)
>   break;
>   }
>  
> - if (priv->version == BRCM_SATA_BCM7216)
> - ret = reset_control_reset(priv->rcdev);
> - else
> - ret = reset_control_deassert(priv->rcdev);
> + ret = reset_control_deassert(priv->rcdev);
>   if (ret)
>   return ret;

Do we need a similar change for brcm_ahci_resume()?
-- 
Florian

Re: [PATCH v3 11/13] PCI: brcmstb: Accommodate MSI for older chips

[Florian Fainelli]

On 6/3/2020 12:20 PM, Jim Quinlan wrote:
> From: Jim Quinlan 
> 
> Older BrcmSTB chips do not have a separate register for MSI interrupts; the
> MSIs are in a register that also contains unrelated interrupts.  In
> addition, the interrupts lie in bits [31..24] for these legacy chips.  This
> commit provides common code for both legacy and non-legacy MSI interrupt
> registers.
> 
> Signed-off-by: Jim Quinlan 

Acked-by: Florian Fainelli 
-- 
Florian

Re: linux-next: manual merge of the ipsec-next tree with Linus' tree

[David Ahern]

On 6/3/20 7:26 PM, Stephen Rothwell wrote:
> 
> And now the net-next tree has been merged into Linus' tree without this fix 
> :-(
> 

I took a look earlier and I think it is fine. Some code was moved around
in ipsec-next and I think the merge is good. I'll run the test cases
later this week and double check. Thanks for the reminder

Re: linux-next: build failure after merge of the kvm tree

[Stephen Rothwell]

Hi all,

On Thu, 21 May 2020 16:28:54 +1000 Stephen Rothwell  
wrote:
>
> After merging the kvm tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
> 
> arch/x86/kvm/svm/svm.c: In function 'kvm_machine_check':
> arch/x86/kvm/svm/svm.c:1834:2: error: too many arguments to function 
> 'do_machine_check'
>  1834 |  do_machine_check(, 0);
>   |  ^~~~
> In file included from arch/x86/kvm/svm/svm.c:36:
> arch/x86/include/asm/mce.h:254:6: note: declared here
>   254 | void do_machine_check(struct pt_regs *pt_regs);
>   |  ^~~~
> 
> Caused by commit
> 
>   1c164cb3ffd0 ("KVM: SVM: Use do_machine_check to pass MCE to the host")
> 
> interacting with commit
> 
>   aaa4947defff ("x86/entry: Convert Machine Check to IDTENTRY_IST")
> 
> from the tip tree.
> 
> I added the following merge fix patch.
> 
> From: Stephen Rothwell 
> Date: Thu, 21 May 2020 16:24:59 +1000
> Subject: [PATCH] KVM: SVM: fix up for do_machine_check() API change
> 
> Signed-off-by: Stephen Rothwell 
> ---
>  arch/x86/kvm/svm/svm.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
> index ae287980c027..7488c8abe825 100644
> --- a/arch/x86/kvm/svm/svm.c
> +++ b/arch/x86/kvm/svm/svm.c
> @@ -1831,7 +1831,7 @@ static void kvm_machine_check(void)
>   .flags = X86_EFLAGS_IF,
>   };
>  
> - do_machine_check(, 0);
> + do_machine_check();
>  #endif
>  }
>  
> -- 
> 2.26.2

This fix is now needed whe the tip tree merges with Linus' tree.

-- 
Cheers,
Stephen Rothwell


pgp4h6V5DLNI1.pgp
Description: OpenPGP digital signature

Re: [PATCH 08/10] checkpatch: Remove awareness of uninitialized_var() macro

[Sedat Dilek]

Hi Kees,

can you push that change also to kees/linux.git#kspp/uninit/v5.7/macro ?

Thanks in advance.

Regards,
- Sedat -

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/log/?h=kspp/uninit/v5.7/macro

On Thu, Jun 4, 2020 at 4:44 AM Kees Cook  wrote:
>
> On Wed, Jun 03, 2020 at 06:47:13PM -0700, Joe Perches wrote:
> > On Wed, 2020-06-03 at 18:40 -0700, Kees Cook wrote:
> > > On Wed, Jun 03, 2020 at 05:02:29PM -0700, Joe Perches wrote:
> > > > On Wed, 2020-06-03 at 16:32 -0700, Kees Cook wrote:
> > > > > Using uninitialized_var() is dangerous as it papers over real bugs[1]
> > > > > (or can in the future), and suppresses unrelated compiler warnings
> > > > > (e.g. "unused variable"). If the compiler thinks it is uninitialized,
> > > > > either simply initialize the variable or make compiler changes.
> > > > >
> > > > > In preparation for removing[2] the[3] macro[4], effectively revert
> > > > > commit 16b7f3c89907 ("checkpatch: avoid warning about 
> > > > > uninitialized_var()")
> > > > > and remove all remaining mentions of uninitialized_var().
> > > > >
> > > > > [1] 
> > > > > https://lore.kernel.org/lkml/20200603174714.192027-1-gli...@google.com/
> > > > > [2] 
> > > > > https://lore.kernel.org/lkml/CA+55aFw+Vbj0i=1tgqcr5vqkczwj0qxk6cernou6eedsuda...@mail.gmail.com/
> > > > > [3] 
> > > > > https://lore.kernel.org/lkml/ca+55afwgbgqhbp1fkxvrkepzyr5j8n1vkt1vzdz9knmpuxh...@mail.gmail.com/
> > > > > [4] 
> > > > > https://lore.kernel.org/lkml/CA+55aFz2500WfbKXAx8s67wrm9=yvju65tplgn_ybynv0ve...@mail.gmail.com/
> > > >
> > > > nack.  see below.
> > > >
> > > > I'd prefer a simple revert, but it shouldn't
> > > > be done here.
> > >
> > > What do you mean? (I can't understand this and "fine by me" below?)
> >
> > I did write "other than that"...
> >
> > I mean that the original commit fixed 2 issues,
> > one with the uninitialized_var addition, and
> > another with the missing void function declaration.
> >
> > I think I found the missing void function bit because
> > the uninitialized_var use looked like a function so I
> > fixed both things at the same time.
> >
> > If you change it, please just remove the bit that
> > checks for uninitialized_var.
>
> Ah! Gotcha. Thanks; I will update it.
>
> -Kees
>
> >
> > Thanks, Joe
> >
> > > > > diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> > > > []
> > > > > @@ -4075,7 +4074,7 @@ sub process {
> > > > > }
> > > > >
> > > > >  # check for function declarations without arguments like "int foo()"
> > > > > -   if ($line =~ /(\b$Type\s*$Ident)\s*\(\s*\)/) {
> > > > > +   if ($line =~ /(\b$Type\s+$Ident)\s*\(\s*\)/) {
> > > >
> > > > This isn't right because $Type includes a possible trailing *
> > > > where there isn't a space between $Type and $Ident
> > >
> > > Ah, hm, that was changed in the mentioned commit:
> > >
> > > -   if ($line =~ /(\b$Type\s+$Ident)\s*\(\s*\)/) {
> > > +   if ($line =~ /(\b$Type\s*$Ident)\s*\(\s*\)/) {
> > >
> > > > e.g.: int *bar(void);
> > > >
> > > > Other than that, fine by me...
> > >
> > > Thanks for looking it over! I'll adjust it however you'd like. :)
> > >
> >
>
> --
> Kees Cook
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Clang Built Linux" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clang-built-linux+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/clang-built-linux/202006031944.9551FAA68E%40keescook.

Re: [PATCH v4 1/4] riscv: Move kernel mapping to vmalloc zone

[Zong Li]

On Wed, Jun 3, 2020 at 4:01 PM Alexandre Ghiti  wrote:
>
> This is a preparatory patch for relocatable kernel.
>
> The kernel used to be linked at PAGE_OFFSET address and used to be loaded
> physically at the beginning of the main memory. Therefore, we could use
> the linear mapping for the kernel mapping.
>
> But the relocated kernel base address will be different from PAGE_OFFSET
> and since in the linear mapping, two different virtual addresses cannot
> point to the same physical address, the kernel mapping needs to lie outside
> the linear mapping.
>
> In addition, because modules and BPF must be close to the kernel (inside
> +-2GB window), the kernel is placed at the end of the vmalloc zone minus
> 2GB, which leaves room for modules and BPF. The kernel could not be
> placed at the beginning of the vmalloc zone since other vmalloc
> allocations from the kernel could get all the +-2GB window around the
> kernel which would prevent new modules and BPF programs to be loaded.
>
> Signed-off-by: Alexandre Ghiti 
> ---
>  arch/riscv/boot/loader.lds.S |  3 +-
>  arch/riscv/include/asm/page.h| 10 +-
>  arch/riscv/include/asm/pgtable.h | 38 ++---
>  arch/riscv/kernel/head.S |  3 +-
>  arch/riscv/kernel/module.c   |  4 +--
>  arch/riscv/kernel/vmlinux.lds.S  |  3 +-
>  arch/riscv/mm/init.c | 58 +---
>  arch/riscv/mm/physaddr.c |  2 +-
>  8 files changed, 88 insertions(+), 33 deletions(-)
>
> diff --git a/arch/riscv/boot/loader.lds.S b/arch/riscv/boot/loader.lds.S
> index 47a5003c2e28..62d94696a19c 100644
> --- a/arch/riscv/boot/loader.lds.S
> +++ b/arch/riscv/boot/loader.lds.S
> @@ -1,13 +1,14 @@
>  /* SPDX-License-Identifier: GPL-2.0 */
>
>  #include 
> +#include 
>
>  OUTPUT_ARCH(riscv)
>  ENTRY(_start)
>
>  SECTIONS
>  {
> -   . = PAGE_OFFSET;
> +   . = KERNEL_LINK_ADDR;
>
> .payload : {
> *(.payload)
> diff --git a/arch/riscv/include/asm/page.h b/arch/riscv/include/asm/page.h
> index 2d50f76efe48..48bb09b6a9b7 100644
> --- a/arch/riscv/include/asm/page.h
> +++ b/arch/riscv/include/asm/page.h
> @@ -90,18 +90,26 @@ typedef struct page *pgtable_t;
>
>  #ifdef CONFIG_MMU
>  extern unsigned long va_pa_offset;
> +extern unsigned long va_kernel_pa_offset;
>  extern unsigned long pfn_base;
>  #define ARCH_PFN_OFFSET(pfn_base)
>  #else
>  #define va_pa_offset   0
> +#define va_kernel_pa_offset0
>  #define ARCH_PFN_OFFSET(PAGE_OFFSET >> PAGE_SHIFT)
>  #endif /* CONFIG_MMU */
>
>  extern unsigned long max_low_pfn;
>  extern unsigned long min_low_pfn;
> +extern unsigned long kernel_virt_addr;
>
>  #define __pa_to_va_nodebug(x)  ((void *)((unsigned long) (x) + va_pa_offset))
> -#define __va_to_pa_nodebug(x)  ((unsigned long)(x) - va_pa_offset)
> +#define linear_mapping_va_to_pa(x) ((unsigned long)(x) - va_pa_offset)
> +#define kernel_mapping_va_to_pa(x) \
> +   ((unsigned long)(x) - va_kernel_pa_offset)
> +#define __va_to_pa_nodebug(x)  \
> +   (((x) >= PAGE_OFFSET) ? \
> +   linear_mapping_va_to_pa(x) : kernel_mapping_va_to_pa(x))
>
>  #ifdef CONFIG_DEBUG_VIRTUAL
>  extern phys_addr_t __virt_to_phys(unsigned long x);
> diff --git a/arch/riscv/include/asm/pgtable.h 
> b/arch/riscv/include/asm/pgtable.h
> index 35b60035b6b0..94ef3b49dfb6 100644
> --- a/arch/riscv/include/asm/pgtable.h
> +++ b/arch/riscv/include/asm/pgtable.h
> @@ -11,23 +11,29 @@
>
>  #include 
>
> -#ifndef __ASSEMBLY__
> -
> -/* Page Upper Directory not used in RISC-V */
> -#include 
> -#include 
> -#include 
> -#include 
> -
> -#ifdef CONFIG_MMU
> +#ifndef CONFIG_MMU
> +#define KERNEL_VIRT_ADDR   PAGE_OFFSET
> +#define KERNEL_LINK_ADDR   PAGE_OFFSET
> +#else
> +/*
> + * Leave 2GB for modules and BPF that must lie within a 2GB range around
> + * the kernel.
> + */
> +#define KERNEL_VIRT_ADDR   (VMALLOC_END - SZ_2G + 1)
> +#define KERNEL_LINK_ADDR   KERNEL_VIRT_ADDR
>
>  #define VMALLOC_SIZE (KERN_VIRT_SIZE >> 1)
>  #define VMALLOC_END  (PAGE_OFFSET - 1)
>  #define VMALLOC_START(PAGE_OFFSET - VMALLOC_SIZE)
>
>  #define BPF_JIT_REGION_SIZE(SZ_128M)
> -#define BPF_JIT_REGION_START   (PAGE_OFFSET - BPF_JIT_REGION_SIZE)
> -#define BPF_JIT_REGION_END (VMALLOC_END)
> +#define BPF_JIT_REGION_START   PFN_ALIGN((unsigned long)&_end)
> +#define BPF_JIT_REGION_END (BPF_JIT_REGION_START + BPF_JIT_REGION_SIZE)
> +
> +#ifdef CONFIG_64BIT
> +#define VMALLOC_MODULE_START   BPF_JIT_REGION_END
> +#define VMALLOC_MODULE_END (((unsigned long)&_start & PAGE_MASK) + SZ_2G)
> +#endif
>
>  /*
>   * Roughly size the vmemmap space to be large enough to fit enough
> @@ -57,9 +63,16 @@
>  #define FIXADDR_SIZE PGDIR_SIZE
>  #endif
>  #define FIXADDR_START(FIXADDR_TOP - FIXADDR_SIZE)
> -
>  #endif
>
> +#ifndef __ASSEMBLY__
> +
> +/* Page Upper Directory not used in RISC-V */
> +#include 
> +#include 
> +#include 
> +#include 
> 

Re: [RFC PATCH v4 07/10] vfio/pci: introduce a new irq type VFIO_IRQ_TYPE_REMAP_BAR_REGION

[Yan Zhao]

On Wed, Jun 03, 2020 at 05:04:52PM -0600, Alex Williamson wrote:
> On Tue, 2 Jun 2020 21:40:58 -0400
> Yan Zhao  wrote:
> 
> > On Tue, Jun 02, 2020 at 01:34:35PM -0600, Alex Williamson wrote:
> > > I'm not at all happy with this.  Why do we need to hide the migration
> > > sparse mmap from the user until migration time?  What if instead we
> > > introduced a new VFIO_REGION_INFO_CAP_SPARSE_MMAP_SAVING capability
> > > where the existing capability is the normal runtime sparse setup and
> > > the user is required to use this new one prior to enabled device_state
> > > with _SAVING.  The vendor driver could then simply track mmap vmas to
> > > the region and refuse to change device_state if there are outstanding
> > > mmaps conflicting with the _SAVING sparse mmap layout.  No new IRQs
> > > required, no new irqfds, an incremental change to the protocol,
> > > backwards compatible to the extent that a vendor driver requiring this
> > > will automatically fail migration.
> > >   
> > right. looks we need to use this approach to solve the problem.
> > thanks for your guide.
> > so I'll abandon the current remap irq way for dirty tracking during live
> > migration.
> > but anyway, it demos how to customize irq_types in vendor drivers.
> > then, what do you think about patches 1-5?
> 
> In broad strokes, I don't think we've found the right solution yet.  I
> really question whether it's supportable to parcel out vfio-pci like
> this and I don't know how I'd support unraveling whether we have a bug
> in vfio-pci, the vendor driver, or how the vendor driver is making use
> of vfio-pci.
>
> Let me also ask, why does any of this need to be in the kernel?  We
> spend 5 patches slicing up vfio-pci so that we can register a vendor
> driver and have that vendor driver call into vfio-pci as it sees fit.
> We have two patches creating device specific interrupts and a BAR
> remapping scheme that we've decided we don't need.  That brings us to
> the actual i40e vendor driver, where the first patch is simply making
> the vendor driver work like vfio-pci already does, the second patch is
> handling the migration region, and the third patch is implementing the
> BAR remapping IRQ that we decided we don't need.  It's difficult to
> actually find the small bit of code that's required to support
> migration outside of just dealing with the protocol we've defined to
> expose this from the kernel.  So why are we trying to do this in the
> kernel?  We have quirk support in QEMU, we can easily flip
> MemoryRegions on and off, etc.  What access to the device outside of
> what vfio-pci provides to the user, and therefore QEMU, is necessary to
> implement this migration support for i40e VFs?  Is this just an
> exercise in making use of the migration interface?  Thanks,
> 
hi Alex

There was a description of intention of this series in RFC v1
(https://www.spinics.net/lists/kernel/msg3337337.html).
sorry, I didn't include it in starting from RFC v2.

"
The reason why we don't choose the way of writing mdev parent driver is
that
(1) VFs are almost all the time directly passthroughed. Directly binding
to vfio-pci can make most of the code shared/reused. If we write a
vendor specific mdev parent driver, most of the code (like passthrough
style of rw/mmap) still needs to be copied from vfio-pci driver, which is
actually a duplicated and tedious work.
(2) For features like dynamically trap/untrap pci bars, if they are in
vfio-pci, they can be available to most people without repeated code
copying and re-testing.
(3) with a 1:1 mdev driver which passes through VFs most of the time, people
have to decide whether to bind VFs to vfio-pci or mdev parent driver before
it runs into a real migration need. However, if vfio-pci is bound
initially, they have no chance to do live migration when there's a need
later.
"
particularly, there're some devices (like NVMe) they purely reply on
vfio-pci to do device pass-through and they have no standalone parent driver
to do mdev way.

I think live migration is a general requirement for most devices and to
interact with the migration interface requires vendor drivers to do
device specific tasks like geting/seting device state, starting/stopping
devices, tracking dirty data, report migration capabilities... all those
works need be in kernel.
do you think it's better to create numerous vendor quirks in vfio-pci?

as to this series, though patch 9/10 currently only demos reporting a
migration region, it actually shows the capability iof vendor driver to
customize device regions. e.g. in patch 10/10, it customizes the BAR0 to
be read/write. and though we abandoned the REMAP BAR irq_type in patch
10/10 for migration purpose, I have to say this irq_type has its usage
in other use cases, where synchronization is not a hard requirement and
all it needs is a notification channel from kernel to use. this series
just provides a possibility for vendors to customize device regions and
irqs.

for interfaces exported in patch 

[tip:x86/entry 29/29] include/linux/cpumask.h:894:9: error: implicit declaration of function 'arch_test_bit'; did you mean

[kernel test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/entry
head:   02da62886d81c6683fbd6a09aec02b2c050d5827
commit: 02da62886d81c6683fbd6a09aec02b2c050d5827 [29/29] x86/entry, cpumask: 
Provide non-instrumented variant of cpu_is_offline()
config: arc-randconfig-r024-20200603 (attached as .config)
compiler: arc-elf-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 02da62886d81c6683fbd6a09aec02b2c050d5827
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=arc 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All errors (new ones prefixed by >>, old ones prefixed by <<):

In file included from include/linux/rcupdate.h:31,
from include/linux/rculist.h:11,
from include/linux/pid.h:5,
from include/linux/sched.h:14,
from arch/arc/kernel/asm-offsets.c:6:
include/linux/cpumask.h: In function 'arch_cpu_online':
>> include/linux/cpumask.h:894:9: error: implicit declaration of function 
>> 'arch_test_bit'; did you mean 'test_bit'? 
>> [-Werror=implicit-function-declaration]
894 |  return arch_test_bit(cpu, cpumask_bits(cpu_online_mask));
| ^
| test_bit
cc1: some warnings being treated as errors
make[2]: *** [scripts/Makefile.build:100: arch/arc/kernel/asm-offsets.s] Error 1
make[2]: Target '__build' not remade because of errors.
make[1]: *** [Makefile:1149: prepare0] Error 2
make[1]: Target 'prepare' not remade because of errors.
make: *** [Makefile:180: sub-make] Error 2

vim +894 include/linux/cpumask.h

   890  
   891  #if NR_CPUS > 1
   892  static __always_inline bool arch_cpu_online(int cpu)
   893  {
 > 894  return arch_test_bit(cpu, cpumask_bits(cpu_online_mask));
   895  }
   896  #else
   897  static __always_inline bool arch_cpu_online(int cpu)
   898  {
   899  return cpu == 0;
   900  }
   901  #endif
   902  

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org


.config.gz
Description: application/gzip

Re: [PATCH 08/10] checkpatch: Remove awareness of uninitialized_var() macro

[Kees Cook]

On Wed, Jun 03, 2020 at 06:47:13PM -0700, Joe Perches wrote:
> On Wed, 2020-06-03 at 18:40 -0700, Kees Cook wrote:
> > On Wed, Jun 03, 2020 at 05:02:29PM -0700, Joe Perches wrote:
> > > On Wed, 2020-06-03 at 16:32 -0700, Kees Cook wrote:
> > > > Using uninitialized_var() is dangerous as it papers over real bugs[1]
> > > > (or can in the future), and suppresses unrelated compiler warnings
> > > > (e.g. "unused variable"). If the compiler thinks it is uninitialized,
> > > > either simply initialize the variable or make compiler changes.
> > > > 
> > > > In preparation for removing[2] the[3] macro[4], effectively revert
> > > > commit 16b7f3c89907 ("checkpatch: avoid warning about 
> > > > uninitialized_var()")
> > > > and remove all remaining mentions of uninitialized_var().
> > > > 
> > > > [1] 
> > > > https://lore.kernel.org/lkml/20200603174714.192027-1-gli...@google.com/
> > > > [2] 
> > > > https://lore.kernel.org/lkml/CA+55aFw+Vbj0i=1tgqcr5vqkczwj0qxk6cernou6eedsuda...@mail.gmail.com/
> > > > [3] 
> > > > https://lore.kernel.org/lkml/ca+55afwgbgqhbp1fkxvrkepzyr5j8n1vkt1vzdz9knmpuxh...@mail.gmail.com/
> > > > [4] 
> > > > https://lore.kernel.org/lkml/CA+55aFz2500WfbKXAx8s67wrm9=yvju65tplgn_ybynv0ve...@mail.gmail.com/
> > > 
> > > nack.  see below.
> > > 
> > > I'd prefer a simple revert, but it shouldn't
> > > be done here.
> > 
> > What do you mean? (I can't understand this and "fine by me" below?)
> 
> I did write "other than that"...
> 
> I mean that the original commit fixed 2 issues,
> one with the uninitialized_var addition, and
> another with the missing void function declaration.
> 
> I think I found the missing void function bit because
> the uninitialized_var use looked like a function so I
> fixed both things at the same time.
> 
> If you change it, please just remove the bit that
> checks for uninitialized_var.

Ah! Gotcha. Thanks; I will update it.

-Kees

> 
> Thanks, Joe
> 
> > > > diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> > > []
> > > > @@ -4075,7 +4074,7 @@ sub process {
> > > > }
> > > >  
> > > >  # check for function declarations without arguments like "int foo()"
> > > > -   if ($line =~ /(\b$Type\s*$Ident)\s*\(\s*\)/) {
> > > > +   if ($line =~ /(\b$Type\s+$Ident)\s*\(\s*\)/) {
> > > 
> > > This isn't right because $Type includes a possible trailing *
> > > where there isn't a space between $Type and $Ident
> > 
> > Ah, hm, that was changed in the mentioned commit:
> > 
> > -   if ($line =~ /(\b$Type\s+$Ident)\s*\(\s*\)/) {
> > +   if ($line =~ /(\b$Type\s*$Ident)\s*\(\s*\)/) {
> > 
> > > e.g.: int *bar(void);
> > > 
> > > Other than that, fine by me...
> > 
> > Thanks for looking it over! I'll adjust it however you'd like. :)
> > 
> 

-- 
Kees Cook

Re: [PATCH v3 0/4] Add seccomp notifier ioctl that enables adding fds

[Kees Cook]

On Wed, Jun 03, 2020 at 04:56:59PM -0700, Sargun Dhillon wrote:
> On Wed, Jun 3, 2020 at 4:42 PM Kees Cook  wrote:
> >
> > On Tue, Jun 02, 2020 at 06:10:40PM -0700, Sargun Dhillon wrote:
> > > Sargun Dhillon (4):
> > >   fs, net: Standardize on file_receive helper to move fds across
> > > processes
> > >   pid: Use file_receive helper to copy FDs
> >
> > The fixes (that should add open-coded cgroups stuff) should be separate
> > patches so they can be backported.
> Patch 1/4, and 2/4 are separated so they can be backported. Patch 1 should
> go into long term, and patch 2 should land in stable.
> 
> Do you see anything in 1/4, and 2/4 that shouldn't be there?

So, my thinking was to open code the fixes to minimize the code churn
in the -stable trees and isolate logical changes. However, in looking
at the commits (3.6, 3.8) and the age of the rest of the nearby code in
SCM_RIGHTS (3.7), and the actual oldest supported kernel release (3.16),
I guess it would be better to split it like you've done.

> > The helper doesn't take the __user pointer I thought we'd agreed it
> > should to avoid changing any SCM_RIGHTS behaviors?
> >
> It doesn't change the SCM_RIGHTS behaviour because it continues
> to have the logic which allocates the file descriptor outside of the
> helper.
> 1. Allocate FD (this happens in scm.c)
> 2. Copy FD # to userspace (this happens in scm.c)
> 3. Receive FD (this happens in the new helper)

Sorry, I was not writing very clearly: I was meaning to have said:

I was expecting the helper to take the __user pointer (like I thought
we agreed[1]) so we could both avoid changing SCM_RIGHTS behavior and
avoid copy/pasting of the get_unused/put_unused code in 3 places. (I
get into this more in the other thread[2]).

So, let's finalize this decision in the thread at [2]. Again, sorry I
wasted your time due to my confusion!

-Kees

[1] Apologies, I misread your "1" in [3] to be "suggestion 1" from the
quoted text from me in that email, rather than the "[1]" it was,
which was a link to your counter-proposal. And then I wasted your
time by saying "agreed".
[2] https://lore.kernel.org/lkml/202006031845.F587F85A@keescook/
[3] 
https://lore.kernel.org/lkml/20200530011054.GA14852@ircssh-2.c.rugged-nimbus-611.internal/

-- 
Kees Cook

[PATCH] KVM: x86: Assign correct value to array.maxnent

[Xiaoyao Li]

Delay the assignment of array.maxnent to use correct value for the case
cpuid->nent > KVM_MAX_CPUID_ENTRIES.

Fixes: e53c95e8d41e ("KVM: x86: Encapsulate CPUID entries and metadata in 
struct")
Signed-off-by: Xiaoyao Li 
---
 arch/x86/kvm/cpuid.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
index 253b8e875ccd..befff01d100c 100644
--- a/arch/x86/kvm/cpuid.c
+++ b/arch/x86/kvm/cpuid.c
@@ -870,7 +870,6 @@ int kvm_dev_ioctl_get_cpuid(struct kvm_cpuid2 *cpuid,
 
struct kvm_cpuid_array array = {
.nent = 0,
-   .maxnent = cpuid->nent,
};
int r, i;
 
@@ -887,6 +886,8 @@ int kvm_dev_ioctl_get_cpuid(struct kvm_cpuid2 *cpuid,
if (!array.entries)
return -ENOMEM;
 
+   array.maxnent = cpuid->nent;
+
for (i = 0; i < ARRAY_SIZE(funcs); i++) {
r = get_cpuid_func(, funcs[i], type);
if (r)
-- 
2.18.2

[PATCH 1/1] crypto: caam - fix typo

[Heinrich Schuchardt]

%s/suppying/supplying/

Signed-off-by: Heinrich Schuchardt 
---
 drivers/crypto/caam/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/crypto/caam/Kconfig b/drivers/crypto/caam/Kconfig
index a62f228be6da..bc35aa0ec07a 100644
--- a/drivers/crypto/caam/Kconfig
+++ b/drivers/crypto/caam/Kconfig
@@ -147,7 +147,7 @@ config CRYPTO_DEV_FSL_CAAM_RNG_API
select HW_RANDOM
help
  Selecting this will register the SEC4 hardware rng to
- the hw_random API for suppying the kernel entropy pool.
+ the hw_random API for supplying the kernel entropy pool.

 endif # CRYPTO_DEV_FSL_CAAM_JR

--
2.26.2

Re: Question: livepatch failed for new fork() task stack unreliable

[Josh Poimboeuf]

On Thu, Jun 04, 2020 at 09:24:55AM +0800, Wangshaobo (bobo) wrote:
> 
> 在 2020/6/3 23:33, Josh Poimboeuf 写道:
> > On Wed, Jun 03, 2020 at 10:06:07PM +0800, Wangshaobo (bobo) wrote:
> > To be honest, I don't remember what I meant by sibling calls.  They
> > don't even leave anything on the stack.
> > 
> > For noreturns, the code might be laid out like this:
> > 
> > func1:
> > ...
> > call noreturn_foo
> > func2:
> > 
> > func2 is immediately after the call to noreturn_foo.  So the return
> > address on the stack will actually be 'func2'.  We want to retrieve the
> > ORC data for the call instruction (inside func1), instead of the
> > instruction at the beginning of func2.
> > 
> > I should probably update that comment.
> 
> So, I want to ask is there any side effects if i modify like this ? this
> modification is based on
> 
> your fix. It looks like ok with proper test.
> 
> diff --git a/arch/x86/kernel/unwind_orc.c b/arch/x86/kernel/unwind_orc.c
> index e9cc182aa97e..ecce5051e8fd 100644
> --- a/arch/x86/kernel/unwind_orc.c
> +++ b/arch/x86/kernel/unwind_orc.c
> @@ -620,6 +620,7 @@ void __unwind_start(struct unwind_state *state, struct
> task_struct *task,
>     state->sp = task->thread.sp;
>     state->bp = READ_ONCE_NOCHECK(frame->bp);
>     state->ip = READ_ONCE_NOCHECK(frame->ret_addr);
> +  state->signal = ((void *)state->ip == ret_from_fork);
>     }
> 
> diff --git a/arch/x86/kernel/unwind_orc.c b/arch/x86/kernel/unwind_orc.c
> index 7f969b2d240f..d7396431261a 100644
> --- a/arch/x86/kernel/unwind_orc.c
> +++ b/arch/x86/kernel/unwind_orc.c
> @@ -540,7 +540,7 @@ bool unwind_next_frame(struct unwind_state *state)
>  state->sp = sp;
>  state->regs = NULL;
>  state->prev_regs = NULL;
> -    state->signal = ((void *)state->ip == ret_from_fork);
> +    state->signal = false;
>  break;

Yes that's correct.

-- 
Josh

linux-next: manual merge of the tip tree with the sparc-next tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the tip tree got conflicts in:

  arch/sparc/mm/srmmu.c

Commits

3408974d0533 sparc32: mm: Restructure sparc32 MMU page-table layout
c95be5b549d6 sparc32: mm: Change pgtable_t type to pte_t * instead of struct 
page *
f790d0205fd5 sparc32: mm: Fix argument checking in __srmmu_get_nocache()

from the tip tree are also in the sparc-next tree as different commits
(plus some others).

I fixed it up (I just used the sparc-next tree version) 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


pgp1B2Shw3vDI.pgp
Description: OpenPGP digital signature

Re: [RFC PATCH -rcu lkmm] tools/memory-model/README: Expand dependency of klitmus7

[Paul E. McKenney]

On Mon, Jun 01, 2020 at 06:34:33AM +0200, Andrea Parri wrote:
> On Mon, Jun 01, 2020 at 12:37:20AM +0900, Akira Yokosawa wrote:
> > From 87048d7212f6cb16b0a2b85fa6d2f34c28b078c0 Mon Sep 17 00:00:00 2001
> > From: Akira Yokosawa 
> > Date: Sun, 31 May 2020 20:04:32 +0900
> > Subject: [PATCH RFC] tools/memory-model/README: Expand dependency of 
> > klitmus7
> > 
> > klitmus7 is independent of the memory model but depends on the
> > build-target kernel release.
> > It occasionally lost compatibility due to kernel API changes [1, 2, 3].
> > It was remedied in a backwards-compatible manner respectively [4, 5, 6].
> > 
> > Reflect this fact in README.
> > 
> > [1]: b899a850431e ("compiler.h: Remove ACCESS_ONCE()")
> > [2]: 0bb95f80a38f ("Makefile: Globally enable VLA warning")
> > [3]: d56c0d45f0e2 ("proc: decouple proc from VFS with "struct proc_ops"")
> > [4]: https://github.com/herd/herdtools7/commit/e87d7f9287d1
> >  ("klitmus: Use WRITE_ONCE and READ_ONCE in place of deprecated 
> > ACCESS_ONCE")
> > [5]: https://github.com/herd/herdtools7/commit/a0cbb10d02be
> >  ("klitmus: Avoid variable length array")
> > [6]: https://github.com/herd/herdtools7/commit/46b9412d3a58
> >  ("klitmus: Linux kernel v5.6.x compat")
> > 
> > NOTE: [5] was ahead of herdtools7 7.53, which did not make an
> > official release.  Code generated by klitmus7 without [5] can still be
> > built targeting Linux 4.20--5.5 if you don't care VLA warnings.
> > 
> > Signed-off-by: Akira Yokosawa 
> 
> Acked-by: Andrea Parri 

Queued, thank you both!

Thanx, Paul

>   Andrea
> 
> 
> > ---
> > Hi all,
> > 
> > Recent struggle of Andrii with the use of klitmus7 on an up-to-date
> > Linux system prompted me to add some explanation of klitmus7's dependency
> > in README.
> > 
> > As herdtools7 7.56 is still under development, I called out just HEAD
> > in the compatibility table.  Once 7.56 is released, the table can be
> > updated.
> > 
> > I'm not sure if this is the right place to carry such info.
> > Anyway, I'd be glad if this patch can trigger a meaningful update of
> > README.
> > 
> > Thanks, Akira
> > --
> >  tools/memory-model/README | 30 --
> >  1 file changed, 28 insertions(+), 2 deletions(-)
> > 
> > diff --git a/tools/memory-model/README b/tools/memory-model/README
> > index b9c562e92981..90af203c3cf1 100644
> > --- a/tools/memory-model/README
> > +++ b/tools/memory-model/README
> > @@ -28,8 +28,34 @@ downloaded separately:
> >  See "herdtools7/INSTALL.md" for installation instructions.
> >  
> >  Note that although these tools usually provide backwards compatibility,
> > -this is not absolutely guaranteed.  Therefore, if a later version does
> > -not work, please try using the exact version called out above.
> > +this is not absolutely guaranteed.
> > +
> > +For example, a future version of herd7 might not work with the model
> > +in this release.  A compatible model will likely be made available in
> > +a later release of Linux kernel.
> > +
> > +If you absolutely need to run the model in this particular release,
> > +please try using the exact version called out above.
> > +
> > +klitmus7 is independent of the model provided here.  It has its own
> > +dependency on a target kernel release where converted code is built
> > +and executed.  Any change in kernel APIs essential to klitmus7 will
> > +necessitate an upgrade of klitmus7.
> > +
> > +If you find any compatibility issues in klitmus7, please inform the
> > +memory model maintainers.
> > +
> > +klitmus7 Compatibility Table
> > +
> > +
> > +     ==
> > +   target Linux  herdtools7
> > +     --
> > +-- 4.18  7.48 --
> > +   4.15 -- 4.19  7.49 --
> > +   4.20 -- 5.5   7.54 --
> > +   5.6  --   HEAD
> > +     ==
> >  
> >  
> >  ==
> > -- 
> > 2.17.1
> > 

Re: kernel/trace/blktrace.c:347:12: sparse: sparse: incorrect type in assignment (different address spaces)

[Jens Axboe]

On 6/3/20 4:34 PM, Chaitanya Kulkarni wrote:
> Jens,
> 
> On 6/3/20 4:32 AM, kernel test robot wrote:
>> tree:https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git  
>> master
>> head:   d6f9469a03d832dcd17041ed67774ffb5f3e73b3
>> commit: c780e86dd48ef6467a1146cf7d0fe1e05a635039 blktrace: Protect 
>> q->blk_trace with RCU
>> date:   3 months ago
>> config: arc-randconfig-s031-20200603 (attached as .config)
>> compiler: arc-elf-gcc (GCC) 9.3.0
>> reproduce:
>>  # apt-get install sparse
>>  # sparse version: v0.6.1-244-g0ee050a8-dirty
>>  git checkout c780e86dd48ef6467a1146cf7d0fe1e05a635039
>>  # save the attached .config to linux build tree
>>  make W=1 C=1 ARCH=arc CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__'
>>
>> If you fix the issue, kindly add following tag as appropriate
>> Reported-by: kernel test robot
> 
> I think Jan has sent the patch to fix the rcu and I've sent out the 
> series to fix the rest of the issues.
> 
> Can you please let me know how can we proceed with the series so that
> we can stop these emails ?

Which patch from Jan? I saw one, and it had issues. Then there's a second
one, which is ordered behind a series that's not in my tree and wasn't
queued for 5.8. And finally, there's your series, which seemed to be a
subset of Jan's patch for patch 1.

So it's really not very clear. Maybe if folks got together and actually
put together a series to fix this it would be easier to get this done.

-- 
Jens Axboe

Re: [PATCH v15 06/11] soc: mediatek: Add subsys clock control for bus protection

[Nicolas Boichat]

On Thu, May 21, 2020 at 5:06 PM Weiyi Lu  wrote:
>
> For the bus protection operations, some subsys clocks need to be enabled
> before releasing the protection, and vice versa.
> But those subsys clocks could only be controlled once its corresponding
> power domain is turned on first.
> In this patch, we add the subsys clock control into its relevant steps.
>
> Signed-off-by: Weiyi Lu 
> ---
>  drivers/soc/mediatek/mtk-scpsys.c | 62 
> +--
>  1 file changed, 60 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/soc/mediatek/mtk-scpsys.c 
> b/drivers/soc/mediatek/mtk-scpsys.c
> index 59a525a..ef2c668 100644
> --- a/drivers/soc/mediatek/mtk-scpsys.c
> +++ b/drivers/soc/mediatek/mtk-scpsys.c
> [snip]
> val |= PWR_ISO_BIT;
> @@ -498,6 +511,39 @@ static int scpsys_power_off(struct generic_pm_domain 
> *genpd)
> return ret;
>  }
>
> +static int init_subsys_clks(struct platform_device *pdev,
> +   const char *prefix, struct clk **clk)
> +{
> +   struct device_node *node = pdev->dev.of_node;
> +   u32 prefix_len, sub_clk_cnt = 0;
> +   struct property *prop;
> +   const char *clk_name;
> +
> +   prefix_len = strlen(prefix);
> +
> +   of_property_for_each_string(node, "clock-names", prop, clk_name) {
> +   if (!strncmp(clk_name, prefix, prefix_len) &&
> +   (clk_name[prefix_len] == '-')) {
> +   if (sub_clk_cnt >= MAX_SUBSYS_CLKS) {
> +   dev_err(>dev,
> +   "subsys clk out of range %d\n",
> +   sub_clk_cnt);
> +   return -EINVAL;
> +   }
> +
> +   clk[sub_clk_cnt] = devm_clk_get(>dev,
> +   clk_name);
> +
> +   if (IS_ERR(clk[sub_clk_cnt]))
> +   return PTR_ERR(clk[sub_clk_cnt]);
> +
> +   sub_clk_cnt++;
> +   }
> +   }
> +
> +   return sub_clk_cnt;
> +}
> +
>  static int init_basic_clks(struct platform_device *pdev, struct clk **clk,
> const char * const *name)
>  {
> @@ -596,6 +642,18 @@ static struct scp *init_scp(struct platform_device *pdev,
> if (ret)
> return ERR_PTR(ret);
>
> +   if (data->subsys_clk_prefix) {
> +   ret = init_subsys_clks(pdev,
> +   data->subsys_clk_prefix,
> +   scpd->subsys_clk);
> +   if (ret < 0) {
> +   dev_err(>dev,
> +   "%s: subsys clk unavailable\n",
> +   data->name);

init_subsys_clks should already have printed an error (directly or
indirectly), so this is not needed.

> +   return ERR_PTR(ret);
> +   }
> +   }
> +
> genpd->name = data->name;
> genpd->power_off = scpsys_power_off;
> genpd->power_on = scpsys_power_on;
> --
> 1.8.1.1.dirty

Re: [PATCH v3 1/4] fs, net: Standardize on file_receive helper to move fds across processes

[Kees Cook]

On Thu, Jun 04, 2020 at 03:24:52AM +0200, Christian Brauner wrote:
> On Tue, Jun 02, 2020 at 06:10:41PM -0700, Sargun Dhillon wrote:
> > Previously there were two chunks of code where the logic to receive file
> > descriptors was duplicated in net. The compat version of copying
> > file descriptors via SCM_RIGHTS did not have logic to update cgroups.
> > Logic to change the cgroup data was added in:
> > commit 48a87cc26c13 ("net: netprio: fd passed in SCM_RIGHTS datagram not 
> > set correctly")
> > commit d84295067fc7 ("net: net_cls: fd passed in SCM_RIGHTS datagram not 
> > set correctly")
> > 
> > This was not copied to the compat path. This commit fixes that, and thus
> > should be cherry-picked into stable.
> > 
> > This introduces a helper (file_receive) which encapsulates the logic for
> > handling calling security hooks as well as manipulating cgroup information.
> > This helper can then be used other places in the kernel where file
> > descriptors are copied between processes
> > 
> > I tested cgroup classid setting on both the compat (x32) path, and the
> > native path to ensure that when moving the file descriptor the classid
> > is set.
> > 
> > Signed-off-by: Sargun Dhillon 
> > Suggested-by: Kees Cook 
> > Cc: Al Viro 
> > Cc: Christian Brauner 
> > Cc: Daniel Wagner 
> > Cc: David S. Miller 
> > Cc: Jann Horn ,
> > Cc: John Fastabend 
> > Cc: Tejun Heo 
> > Cc: Tycho Andersen 
> > Cc: sta...@vger.kernel.org
> > Cc: cgro...@vger.kernel.org
> > Cc: linux-fsde...@vger.kernel.org
> > Cc: linux-kernel@vger.kernel.org
> > ---
> >  fs/file.c| 35 +++
> >  include/linux/file.h |  1 +
> >  net/compat.c | 10 +-
> >  net/core/scm.c   | 14 --
> >  4 files changed, 45 insertions(+), 15 deletions(-)
> > 
> > diff --git a/fs/file.c b/fs/file.c
> > index abb8b7081d7a..5afd76fca8c2 100644
> > --- a/fs/file.c
> > +++ b/fs/file.c
> > @@ -18,6 +18,9 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> > +#include 
> > +#include 
> >  
> >  unsigned int sysctl_nr_open __read_mostly = 1024*1024;
> >  unsigned int sysctl_nr_open_min = BITS_PER_LONG;
> > @@ -931,6 +934,38 @@ int replace_fd(unsigned fd, struct file *file, 
> > unsigned flags)
> > return err;
> >  }
> >  
> > +/*
> > + * File Receive - Receive a file from another process
> > + *
> > + * This function is designed to receive files from other tasks. It 
> > encapsulates
> > + * logic around security and cgroups. The file descriptor provided must be 
> > a
> > + * freshly allocated (unused) file descriptor.
> > + *
> > + * This helper does not consume a reference to the file, so the caller 
> > must put
> > + * their reference.
> > + *
> > + * Returns 0 upon success.
> > + */
> > +int file_receive(int fd, struct file *file)
> 
> This is all just a remote version of fd_install(), yet it deviates from
> fd_install()'s semantics and naming. That's not great imho. What about
> naming this something like:
> 
> fd_install_received()
> 
> and move the get_file() out of there so it has the same semantics as
> fd_install(). It seems rather dangerous to have a function like
> fd_install() that consumes a reference once it returned and another
> version of this that is basically the same thing but doesn't consume a
> reference because it takes its own. Seems an invitation for confusion.
> Does that make sense?

We have some competing opinions on this, I guess. What I really don't
like is the copy/pasting of the get_unused_fd_flags() and
put_unused_fd() needed by (nearly) all the callers. If it's a helper, it
should help. Specifically, I'd like to see this:

int file_receive(int fd, unsigned long flags, struct file *file,
 int __user *fdptr)
{
struct socket *sock;
int err;

err = security_file_receive(file);
if (err)
return err;

if (fd < 0) {
/* Install new fd. */
int new_fd;

err = get_unused_fd_flags(flags);
if (err < 0)
return err;
new_fd = err;

/* Copy fd to any waiting user memory. */
if (fdptr) {
err = put_user(new_fd, fdptr);
if (err < 0) {
put_unused_fd(new_fd);
return err;
}
}
fd_install(new_fd, get_file(file));
fd = new_fd;
} else {
/* Replace existing fd. */
err = replace_fd(fd, file, flags);
if (err)
return err;
}

/* Bump the cgroup usage counts. */
sock = sock_from_file(fd, );
if (sock) {
sock_update_netprioidx(>sk->sk_cgrp_data);
sock_update_classid(>sk->sk_cgrp_data);
}

return fd;
}

If everyone else *really* 

[PATCH v2 2/2] efi/libstub: refactor Makefile to not use lib-y syntax

[Masahiro Yamada]

Documentation/kbuild/makefiles.rst says:

  Use of lib-y is normally restricted to `lib/` and `arch/*/lib`.

This is because lib-y is inteded to be hooked to KBUILD_VMLINUX_LIBS,
which is passed down to scripts/link-vmlinux.sh.

Besides, lib-y is not so interesting because objects from lib-y are
mostly linked in normal usecases. For example, lib-y only saves 364
bytes for x86_64_defconfig. You can see the details in commit
7273ad2b08f8 ("kbuild: link lib-y objects to vmlinux forcibly when
CONFIG_MODULES=y").

I think we should consider to deprecate lib-y syntax at some point
because we should aim for better solution like dead code elimination
or LTO.

Other than lib/ and arch/*/lib, this Makefile is the only user of
lib-y. Replace lib-y with a custom rule.

Signed-off-by: Masahiro Yamada 
---

Changes in v2:
  - Add more description

 drivers/firmware/efi/libstub/Makefile | 49 +++
 1 file changed, 27 insertions(+), 22 deletions(-)

diff --git a/drivers/firmware/efi/libstub/Makefile 
b/drivers/firmware/efi/libstub/Makefile
index cce4a7436052..7d81dc45cadf 100644
--- a/drivers/firmware/efi/libstub/Makefile
+++ b/drivers/firmware/efi/libstub/Makefile
@@ -44,7 +44,7 @@ OBJECT_FILES_NON_STANDARD := y
 # Prevents link failures: __sanitizer_cov_trace_pc() is not linked in.
 KCOV_INSTRUMENT:= n
 
-lib-y  := efi-stub-helper.o gop.o secureboot.o tpm.o \
+stub-obj-y := efi-stub-helper.o gop.o secureboot.o tpm.o \
   file.o mem.o random.o randomalloc.o pci.o \
   skip_spaces.o lib-cmdline.o lib-ctype.o \
   alignedmem.o relocate.o vsprintf.o
@@ -55,15 +55,19 @@ efi-deps-y := fdt_rw.c fdt_ro.c fdt_wip.c fdt.c 
fdt_empty_tree.c fdt_sw.c
 $(obj)/lib-%.o: $(srctree)/lib/%.c FORCE
$(call if_changed_rule,cc_o_c)
 
-lib-$(CONFIG_EFI_GENERIC_STUB) += efi-stub.o fdt.o string.o \
+stub-obj-$(CONFIG_EFI_GENERIC_STUB)+= efi-stub.o fdt.o string.o \
   $(patsubst %.c,lib-%.o,$(efi-deps-y))
 
-lib-$(CONFIG_ARM)  += arm32-stub.o
-lib-$(CONFIG_ARM64)+= arm64-stub.o
-lib-$(CONFIG_X86)  += x86-stub.o
+stub-obj-$(CONFIG_ARM) += arm32-stub.o
+stub-obj-$(CONFIG_ARM64)   += arm64-stub.o
+stub-obj-$(CONFIG_X86) += x86-stub.o
 CFLAGS_arm32-stub.o:= -DTEXT_OFFSET=$(TEXT_OFFSET)
 CFLAGS_arm64-stub.o:= -DTEXT_OFFSET=$(TEXT_OFFSET)
 
+targets+= $(stub-obj-y)
+stub-obj-y := $(patsubst %.o,%.stub.o, $(stub-obj-y))
+targets+= $(stub-obj-y)
+
 #
 # For x86, bootloaders like systemd-boot or grub-efi do not zero-initialize the
 # .bss section, so the .bss section of the EFI stub needs to be included in the
@@ -83,23 +87,6 @@ STUBCOPY_FLAGS-$(CONFIG_ARM) += --rename-section 
.data=.data.efistub \
   --rename-section .bss=.bss.efistub,load,alloc
 STUBCOPY_RELOC-$(CONFIG_ARM)   := R_ARM_ABS
 
-#
-# arm64 puts the stub in the kernel proper, which will unnecessarily retain all
-# code indefinitely unless it is annotated as __init/__initdata/__initconst 
etc.
-# So let's apply the __init annotations at the section level, by prefixing
-# the section names directly. This will ensure that even all the inline string
-# literals are covered.
-# The fact that the stub and the kernel proper are essentially the same binary
-# also means that we need to be extra careful to make sure that the stub does
-# not rely on any absolute symbol references, considering that the virtual
-# kernel mapping that the linker uses is not active yet when the stub is
-# executing. So build all C dependencies of the EFI stub into libstub, and do
-# a verification pass to see if any absolute relocations exist in any of the
-# object files.
-#
-extra-y:= $(lib-y)
-lib-y  := $(patsubst %.o,%.stub.o,$(lib-y))
-
 STUBCOPY_FLAGS-$(CONFIG_ARM64) += --prefix-alloc-sections=.init \
   --prefix-symbols=__efistub_
 STUBCOPY_RELOC-$(CONFIG_ARM64) := R_AARCH64_ABS
@@ -121,3 +108,21 @@ quiet_cmd_stubcopy = STUBCPY $@
/bin/false; \
fi; \
$(OBJCOPY) $(STUBCOPY_FLAGS-y) $< $@
+
+# arm64 puts the stub in the kernel proper, which will unnecessarily retain all
+# code indefinitely unless it is annotated as __init/__initdata/__initconst 
etc.
+# So let's apply the __init annotations at the section level, by prefixing
+# the section names directly. This will ensure that even all the inline string
+# literals are covered.
+# The fact that the stub and the kernel proper are essentially the same binary
+# also means that we need to be extra careful to make sure that 

[PATCH v2 1/2] efi/libstub/arm64: link stub lib.a conditionally

[Masahiro Yamada]

Since commit 799c43415442 ("kbuild: thin archives make default for
all archs"), core-y is passed to the linker with --whole-archive.
Hence, the whole of stub library is linked to vmlinux.

Use libs-y so that lib.a is passed after --no-whole-archive for
conditional linking.

The unused drivers/firmware/efi/libstub/relocate.o will be dropped
for ARCH=arm64.

Signed-off-by: Masahiro Yamada 
---

This patch touches under arch/arm64/, but
this is more related to efi.
I am sending this to Ard.

 arch/arm64/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
index 650e1185c190..48a6afa774fc 100644
--- a/arch/arm64/Makefile
+++ b/arch/arm64/Makefile
@@ -145,7 +145,7 @@ export  TEXT_OFFSET
 
 core-y += arch/arm64/
 libs-y := arch/arm64/lib/ $(libs-y)
-core-$(CONFIG_EFI_STUB) += $(objtree)/drivers/firmware/efi/libstub/lib.a
+libs-$(CONFIG_EFI_STUB) += $(objtree)/drivers/firmware/efi/libstub/lib.a
 
 # Default target when executing plain make
 boot   := arch/arm64/boot
-- 
2.25.1

Re: [GIT PULL] SELinux patches for v5.8

[James Morris]

On Wed, 3 Jun 2020, Casey Schaufler wrote:

> On 6/3/2020 3:12 PM, James Morris wrote:
> > On Wed, 3 Jun 2020, Casey Schaufler wrote:
> >
> >> The use of security modules was expected to be rare.
> > This is not correct. Capabilities were ported to LSM and stacked from the 
> > beginning, and several major distros worked on LSM so they could ship 
> > their own security modules.
> 
> Capabilities has always been a special case.
> Until Android adopted SELinux the actual use of LSMs was rare.

Nope, it was enabled by default in several distros and very widely 
deployed in the govt space (at least).

-- 
James Morris

[PATCH V2 1/3] dt-bindings: spi: Convert mxs spi to json-schema

[Anson Huang]

Convert the MXS SPI binding to DT schema format using json-schema

Signed-off-by: Anson Huang 
---
Changes since V1:
- add "unevaluatedProperties: false".
---
 Documentation/devicetree/bindings/spi/mxs-spi.txt  | 26 --
 Documentation/devicetree/bindings/spi/mxs-spi.yaml | 57 ++
 2 files changed, 57 insertions(+), 26 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/spi/mxs-spi.txt
 create mode 100644 Documentation/devicetree/bindings/spi/mxs-spi.yaml

diff --git a/Documentation/devicetree/bindings/spi/mxs-spi.txt 
b/Documentation/devicetree/bindings/spi/mxs-spi.txt
deleted file mode 100644
index 3499b73..000
--- a/Documentation/devicetree/bindings/spi/mxs-spi.txt
+++ /dev/null
@@ -1,26 +0,0 @@
-* Freescale MX233/MX28 SSP/SPI
-
-Required properties:
-- compatible: Should be "fsl,-spi", where soc is "imx23" or "imx28"
-- reg: Offset and length of the register set for the device
-- interrupts: Should contain SSP ERROR interrupt
-- dmas: DMA specifier, consisting of a phandle to DMA controller node
-  and SSP DMA channel ID.
-  Refer to dma.txt and fsl-mxs-dma.txt for details.
-- dma-names: Must be "rx-tx".
-
-Optional properties:
-- clock-frequency : Input clock frequency to the SPI block in Hz.
-   Default is 16000 Hz.
-
-Example:
-
-ssp0: ssp@8001 {
-   #address-cells = <1>;
-   #size-cells = <0>;
-   compatible = "fsl,imx28-spi";
-   reg = <0x8001 0x2000>;
-   interrupts = <96>;
-   dmas = <_apbh 0>;
-   dma-names = "rx-tx";
-};
diff --git a/Documentation/devicetree/bindings/spi/mxs-spi.yaml 
b/Documentation/devicetree/bindings/spi/mxs-spi.yaml
new file mode 100644
index 000..68c5d6d
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/mxs-spi.yaml
@@ -0,0 +1,57 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/spi/mxs-spi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale MX233/MX28 SSP/SPI
+
+maintainers:
+  - Marek Vasut 
+
+allOf:
+  - $ref: "/schemas/spi/spi-controller.yaml#"
+
+properties:
+  compatible:
+enum:
+  - fsl,imx23-spi
+  - fsl,imx28-spi
+
+  reg:
+maxItems: 1
+
+  interrupts:
+maxItems: 1
+
+  dmas:
+maxItems: 1
+
+  dma-names:
+const: rx-tx
+
+  clock-frequency:
+$ref: /schemas/types.yaml#/definitions/uint32
+description: input clock frequency to the SPI block in Hz.
+default: 16000
+
+required:
+  - compatible
+  - reg
+  - interrupts
+  - dmas
+  - dma-names
+
+unevaluatedProperties: false
+
+examples:
+  - |
+spi@8001 {
+#address-cells = <1>;
+#size-cells = <0>;
+compatible = "fsl,imx28-spi";
+reg = <0x8001 0x2000>;
+interrupts = <96>;
+dmas = <_apbh 0>;
+dma-names = "rx-tx";
+};
-- 
2.7.4

[PATCH V2 3/3] dt-bindings: spi: Convert imx lpspi to json-schema

[Anson Huang]

Convert the i.MX LPSPI binding to DT schema format using json-schema

Signed-off-by: Anson Huang 
---
Changes since V1:
- add "unevaluatedProperties: false".
---
 .../devicetree/bindings/spi/spi-fsl-lpspi.txt  | 29 --
 .../devicetree/bindings/spi/spi-fsl-lpspi.yaml | 62 ++
 2 files changed, 62 insertions(+), 29 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/spi/spi-fsl-lpspi.txt
 create mode 100644 Documentation/devicetree/bindings/spi/spi-fsl-lpspi.yaml

diff --git a/Documentation/devicetree/bindings/spi/spi-fsl-lpspi.txt 
b/Documentation/devicetree/bindings/spi/spi-fsl-lpspi.txt
deleted file mode 100644
index e71b81a..000
--- a/Documentation/devicetree/bindings/spi/spi-fsl-lpspi.txt
+++ /dev/null
@@ -1,29 +0,0 @@
-* Freescale Low Power SPI (LPSPI) for i.MX
-
-Required properties:
-- compatible :
-  - "fsl,imx7ulp-spi" for LPSPI compatible with the one integrated on i.MX7ULP 
soc
-  - "fsl,imx8qxp-spi" for LPSPI compatible with the one integrated on i.MX8QXP 
soc
-- reg : address and length of the lpspi master registers
-- interrupt-parent : core interrupt controller
-- interrupts : lpspi interrupt
-- clocks : lpspi clock specifier. Its number and order need to correspond to 
the
-  value in clock-names.
-- clock-names : Corresponding to per clock and ipg clock in "clocks"
-   respectively. In i.MX7ULP, it only has per clk, so use CLK_DUMMY
-   to fill the "ipg" blank.
-- spi-slave : spi slave mode support. In slave mode, add this attribute without
- value. In master mode, remove it.
-
-Examples:
-
-lpspi2: lpspi@4029 {
-   compatible = "fsl,imx7ulp-spi";
-   reg = <0x4029 0x1>;
-   interrupt-parent = <>;
-   interrupts = ;
-   clocks = < IMX7ULP_CLK_LPSPI2>,
-< IMX7ULP_CLK_DUMMY>;
-   clock-names = "per", "ipg";
-   spi-slave;
-};
diff --git a/Documentation/devicetree/bindings/spi/spi-fsl-lpspi.yaml 
b/Documentation/devicetree/bindings/spi/spi-fsl-lpspi.yaml
new file mode 100644
index 000..8ceb529
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/spi-fsl-lpspi.yaml
@@ -0,0 +1,62 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/spi/spi-fsl-lpspi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale Low Power SPI (LPSPI) for i.MX
+
+maintainers:
+  - Anson Huang 
+
+allOf:
+  - $ref: "/schemas/spi/spi-controller.yaml#"
+
+properties:
+  compatible:
+enum:
+  - fsl,imx7ulp-spi
+  - fsl,imx8qxp-spi
+
+  reg:
+maxItems: 1
+
+  interrupts:
+maxItems: 1
+
+  clocks:
+items:
+  - description: SoC SPI per clock
+  - description: SoC SPI ipg clock
+maxItems: 2
+
+  clock-names:
+items:
+  - const: per
+  - const: ipg
+maxItems: 2
+
+required:
+  - compatible
+  - reg
+  - interrupts
+  - clocks
+  - clock-names
+
+unevaluatedProperties: false
+
+examples:
+  - |
+#include 
+#include 
+
+spi@4029 {
+compatible = "fsl,imx7ulp-spi";
+reg = <0x4029 0x1>;
+interrupt-parent = <>;
+interrupts = ;
+clocks = < IMX7ULP_CLK_LPSPI2>,
+ < IMX7ULP_CLK_DUMMY>;
+clock-names = "per", "ipg";
+spi-slave;
+};
-- 
2.7.4

[PATCH V2 0/3] Convert mxs/imx spi/cspi/lpspi binding to json-schema

[Anson Huang]

This patch series converts mxs/imx spi/cspi/lpspi binding to json-schema.

In fsl-imx-cspi.yaml, also update compatible, remove obsolete properties
"fsl,spi-num-chipselects" and update the example based on latest DT file;

In spi-fsl-lpspi.yaml, the original maintainer's email address pandy@nxp.com
is no longer valid, so I use mine.

Compared to V1, this patch series adds "unevaluatedProperties: false" for
each binding doc.

Anson Huang (3):
  dt-bindings: spi: Convert mxs spi to json-schema
  dt-bindings: spi: Convert imx cspi to json-schema
  dt-bindings: spi: Convert imx lpspi to json-schema

 .../devicetree/bindings/spi/fsl-imx-cspi.txt   | 56 
 .../devicetree/bindings/spi/fsl-imx-cspi.yaml  | 99 ++
 Documentation/devicetree/bindings/spi/mxs-spi.txt  | 26 --
 Documentation/devicetree/bindings/spi/mxs-spi.yaml | 57 +
 .../devicetree/bindings/spi/spi-fsl-lpspi.txt  | 29 ---
 .../devicetree/bindings/spi/spi-fsl-lpspi.yaml | 62 ++
 6 files changed, 218 insertions(+), 111 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/spi/fsl-imx-cspi.txt
 create mode 100644 Documentation/devicetree/bindings/spi/fsl-imx-cspi.yaml
 delete mode 100644 Documentation/devicetree/bindings/spi/mxs-spi.txt
 create mode 100644 Documentation/devicetree/bindings/spi/mxs-spi.yaml
 delete mode 100644 Documentation/devicetree/bindings/spi/spi-fsl-lpspi.txt
 create mode 100644 Documentation/devicetree/bindings/spi/spi-fsl-lpspi.yaml

-- 
2.7.4

[PATCH V2 2/3] dt-bindings: spi: Convert imx cspi to json-schema

[Anson Huang]

Convert the i.MX CSPI binding to DT schema format using json-schema,
update compatible, remove obsolete properties "fsl,spi-num-chipselects"
and update the example based on latest DT file.

Signed-off-by: Anson Huang 
---
Changes since V1:
- add "unevaluatedProperties: false".
---
 .../devicetree/bindings/spi/fsl-imx-cspi.txt   | 56 
 .../devicetree/bindings/spi/fsl-imx-cspi.yaml  | 99 ++
 2 files changed, 99 insertions(+), 56 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/spi/fsl-imx-cspi.txt
 create mode 100644 Documentation/devicetree/bindings/spi/fsl-imx-cspi.yaml

diff --git a/Documentation/devicetree/bindings/spi/fsl-imx-cspi.txt 
b/Documentation/devicetree/bindings/spi/fsl-imx-cspi.txt
deleted file mode 100644
index 33bc58f..000
--- a/Documentation/devicetree/bindings/spi/fsl-imx-cspi.txt
+++ /dev/null
@@ -1,56 +0,0 @@
-* Freescale (Enhanced) Configurable Serial Peripheral Interface
-  (CSPI/eCSPI) for i.MX
-
-Required properties:
-- compatible :
-  - "fsl,imx1-cspi" for SPI compatible with the one integrated on i.MX1
-  - "fsl,imx21-cspi" for SPI compatible with the one integrated on i.MX21
-  - "fsl,imx27-cspi" for SPI compatible with the one integrated on i.MX27
-  - "fsl,imx31-cspi" for SPI compatible with the one integrated on i.MX31
-  - "fsl,imx35-cspi" for SPI compatible with the one integrated on i.MX35
-  - "fsl,imx51-ecspi" for SPI compatible with the one integrated on i.MX51
-  - "fsl,imx53-ecspi" for SPI compatible with the one integrated on i.MX53 and 
later Soc
-  - "fsl,imx8mq-ecspi" for SPI compatible with the one integrated on i.MX8MQ
-  - "fsl,imx8mm-ecspi" for SPI compatible with the one integrated on i.MX8MM
-  - "fsl,imx8mn-ecspi" for SPI compatible with the one integrated on i.MX8MN
-  - "fsl,imx8mp-ecspi" for SPI compatible with the one integrated on i.MX8MP
-- reg : Offset and length of the register set for the device
-- interrupts : Should contain CSPI/eCSPI interrupt
-- clocks : Clock specifiers for both ipg and per clocks.
-- clock-names : Clock names should include both "ipg" and "per"
-See the clock consumer binding,
-   Documentation/devicetree/bindings/clock/clock-bindings.txt
-
-Recommended properties:
-- cs-gpios : GPIOs to use as chip selects, see spi-bus.txt.  While the native 
chip
-select lines can be used, they appear to always generate a pulse between each
-word of a transfer.  Most use cases will require GPIO based chip selects to
-generate a valid transaction.
-
-Optional properties:
-- num-cs :  Number of total chip selects, see spi-bus.txt.
-- dmas: DMA specifiers for tx and rx dma. See the DMA client binding,
-Documentation/devicetree/bindings/dma/dma.txt.
-- dma-names: DMA request names, if present, should include "tx" and "rx".
-- fsl,spi-rdy-drctl: Integer, representing the value of DRCTL, the register
-controlling the SPI_READY handling. Note that to enable the DRCTL 
consideration,
-the SPI_READY mode-flag needs to be set too.
-Valid values are: 0 (disabled), 1 (edge-triggered burst) and 2 
(level-triggered burst).
-
-Obsolete properties:
-- fsl,spi-num-chipselects : Contains the number of the chipselect
-
-Example:
-
-ecspi@7001 {
-   #address-cells = <1>;
-   #size-cells = <0>;
-   compatible = "fsl,imx51-ecspi";
-   reg = <0x7001 0x4000>;
-   interrupts = <36>;
-   cs-gpios = < 24 0>, /* GPIO3_24 */
-  < 25 0>; /* GPIO3_25 */
-   dmas = < 3 7 1>, < 4 7 2>;
-   dma-names = "rx", "tx";
-   fsl,spi-rdy-drctl = <1>;
-};
diff --git a/Documentation/devicetree/bindings/spi/fsl-imx-cspi.yaml 
b/Documentation/devicetree/bindings/spi/fsl-imx-cspi.yaml
new file mode 100644
index 000..606af7d
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/fsl-imx-cspi.yaml
@@ -0,0 +1,99 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/spi/fsl-imx-cspi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale (Enhanced) Configurable Serial Peripheral Interface 
(CSPI/eCSPI) for i.MX
+
+maintainers:
+  - Shawn Guo 
+
+allOf:
+  - $ref: "/schemas/spi/spi-controller.yaml#"
+
+properties:
+  compatible:
+oneOf:
+  - const: fsl,imx1-cspi
+  - const: fsl,imx21-cspi
+  - const: fsl,imx27-cspi
+  - const: fsl,imx31-cspi
+  - const: fsl,imx35-cspi
+  - const: fsl,imx51-ecspi
+  - const: fsl,imx53-ecspi
+  - items:
+- enum:
+  - fsl,imx50-ecspi
+  - fsl,imx6q-ecspi
+  - fsl,imx6sx-ecspi
+  - fsl,imx6sl-ecspi
+  - fsl,imx6sll-ecspi
+  - fsl,imx6ul-ecspi
+  - fsl,imx7d-ecspi
+  - fsl,imx8mq-ecspi
+  - fsl,imx8mm-ecspi
+  - fsl,imx8mn-ecspi
+  - fsl,imx8mp-ecspi
+- const: fsl,imx51-ecspi
+
+  reg:
+maxItems: 1
+
+  interrupts:
+maxItems: 1
+
+  clocks:
+items:
+  - description: SoC SPI ipg clock
+

[PATCH V2 2/3] dt-bindings: i2c: Convert mxs i2c to json-schema

[Anson Huang]

Convert the MXS I2C binding to DT schema format using json-schema

Signed-off-by: Anson Huang 
---
Changes since V1:
- add "additionalProperties: false".
---
 Documentation/devicetree/bindings/i2c/i2c-mxs.txt  | 25 --
 Documentation/devicetree/bindings/i2c/i2c-mxs.yaml | 55 ++
 2 files changed, 55 insertions(+), 25 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/i2c/i2c-mxs.txt
 create mode 100644 Documentation/devicetree/bindings/i2c/i2c-mxs.yaml

diff --git a/Documentation/devicetree/bindings/i2c/i2c-mxs.txt 
b/Documentation/devicetree/bindings/i2c/i2c-mxs.txt
deleted file mode 100644
index 4e1c8ac..000
--- a/Documentation/devicetree/bindings/i2c/i2c-mxs.txt
+++ /dev/null
@@ -1,25 +0,0 @@
-* Freescale MXS Inter IC (I2C) Controller
-
-Required properties:
-- compatible: Should be "fsl,-i2c"
-- reg: Should contain registers location and length
-- interrupts: Should contain ERROR interrupt number
-- clock-frequency: Desired I2C bus clock frequency in Hz.
-   Only 10Hz and 40Hz modes are supported.
-- dmas: DMA specifier, consisting of a phandle to DMA controller node
-  and I2C DMA channel ID.
-  Refer to dma.txt and fsl-mxs-dma.txt for details.
-- dma-names: Must be "rx-tx".
-
-Examples:
-
-i2c0: i2c@80058000 {
-   #address-cells = <1>;
-   #size-cells = <0>;
-   compatible = "fsl,imx28-i2c";
-   reg = <0x80058000 2000>;
-   interrupts = <111>;
-   clock-frequency = <10>;
-   dmas = <_apbx 6>;
-   dma-names = "rx-tx";
-};
diff --git a/Documentation/devicetree/bindings/i2c/i2c-mxs.yaml 
b/Documentation/devicetree/bindings/i2c/i2c-mxs.yaml
new file mode 100644
index 000..3bc14bb
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-mxs.yaml
@@ -0,0 +1,55 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/i2c/i2c-mxs.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale MXS Inter IC (I2C) Controller
+
+maintainers:
+  - Shawn Guo 
+
+properties:
+  compatible:
+enum:
+  - fsl,imx23-i2c
+  - fsl,imx28-i2c
+
+  reg:
+maxItems: 1
+
+  interrupts:
+maxItems: 1
+
+  clock-frequency:
+$ref: /schemas/types.yaml#/definitions/uint32
+description: |
+  Desired I2C bus clock frequency in Hz, only 10Hz and 40Hz
+  modes are supported.
+default: 10
+
+  dmas:
+maxItems: 1
+
+  dma-names:
+const: rx-tx
+
+required:
+  - compatible
+  - reg
+  - interrupts
+  - dmas
+  - dma-names
+
+additionalProperties: false
+
+examples:
+  - |
+i2c@80058000 {
+compatible = "fsl,imx28-i2c";
+reg = <0x80058000 2000>;
+interrupts = <111>;
+clock-frequency = <10>;
+dmas = <_apbx 6>;
+dma-names = "rx-tx";
+};
-- 
2.7.4

[PATCH V2 3/3] dt-bindings: i2c: Convert imx i2c to json-schema

[Anson Huang]

Convert the i.MX I2C binding to DT schema format using json-schema,
some improvements applied, such as update example based on latest DT
file, add more compatible for existing SoCs, and remove unnecessary
common property "pinctrl".

Signed-off-by: Anson Huang 
---
Changes since V1:
- add "additionalProperties: false".
---
 Documentation/devicetree/bindings/i2c/i2c-imx.txt  |  49 -
 Documentation/devicetree/bindings/i2c/i2c-imx.yaml | 119 +
 2 files changed, 119 insertions(+), 49 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/i2c/i2c-imx.txt
 create mode 100644 Documentation/devicetree/bindings/i2c/i2c-imx.yaml

diff --git a/Documentation/devicetree/bindings/i2c/i2c-imx.txt 
b/Documentation/devicetree/bindings/i2c/i2c-imx.txt
deleted file mode 100644
index b967544..000
--- a/Documentation/devicetree/bindings/i2c/i2c-imx.txt
+++ /dev/null
@@ -1,49 +0,0 @@
-* Freescale Inter IC (I2C) and High Speed Inter IC (HS-I2C) for i.MX
-
-Required properties:
-- compatible :
-  - "fsl,imx1-i2c" for I2C compatible with the one integrated on i.MX1 SoC
-  - "fsl,imx21-i2c" for I2C compatible with the one integrated on i.MX21 SoC
-  - "fsl,vf610-i2c" for I2C compatible with the one integrated on Vybrid vf610 
SoC
-- reg : Should contain I2C/HS-I2C registers location and length
-- interrupts : Should contain I2C/HS-I2C interrupt
-- clocks : Should contain the I2C/HS-I2C clock specifier
-
-Optional properties:
-- clock-frequency : Constains desired I2C/HS-I2C bus clock frequency in Hz.
-  The absence of the property indicates the default frequency 100 kHz.
-- dmas: A list of two dma specifiers, one for each entry in dma-names.
-- dma-names: should contain "tx" and "rx".
-- scl-gpios: specify the gpio related to SCL pin
-- sda-gpios: specify the gpio related to SDA pin
-- pinctrl: add extra pinctrl to configure i2c pins to gpio function for i2c
-  bus recovery, call it "gpio" state
-
-Examples:
-
-i2c@83fc4000 { /* I2C2 on i.MX51 */
-   compatible = "fsl,imx51-i2c", "fsl,imx21-i2c";
-   reg = <0x83fc4000 0x4000>;
-   interrupts = <63>;
-};
-
-i2c@70038000 { /* HS-I2C on i.MX51 */
-   compatible = "fsl,imx51-i2c", "fsl,imx21-i2c";
-   reg = <0x70038000 0x4000>;
-   interrupts = <64>;
-   clock-frequency = <40>;
-};
-
-i2c0: i2c@40066000 { /* i2c0 on vf610 */
-   compatible = "fsl,vf610-i2c";
-   reg = <0x40066000 0x1000>;
-   interrupts =<0 71 0x04>;
-   dmas = < 0 50>,
-   < 0 51>;
-   dma-names = "rx","tx";
-   pinctrl-names = "default", "gpio";
-   pinctrl-0 = <_i2c1>;
-   pinctrl-1 = <_i2c1_gpio>;
-   scl-gpios = < 26 GPIO_ACTIVE_HIGH>;
-   sda-gpios = < 27 GPIO_ACTIVE_HIGH>;
-};
diff --git a/Documentation/devicetree/bindings/i2c/i2c-imx.yaml 
b/Documentation/devicetree/bindings/i2c/i2c-imx.yaml
new file mode 100644
index 000..63cceab
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-imx.yaml
@@ -0,0 +1,119 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/i2c/i2c-imx.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale Inter IC (I2C) and High Speed Inter IC (HS-I2C) for i.MX
+
+maintainers:
+  - Wolfram Sang 
+
+properties:
+  compatible:
+oneOf:
+  - const: fsl,imx1-i2c
+  - const: fsl,imx21-i2c
+  - const: fsl,vf610-i2c
+  - items:
+  - const: fsl,imx35-i2c
+  - const: fsl,imx1-i2c
+  - items:
+  - enum:
+- fsl,imx25-i2c
+- fsl,imx27-i2c
+- fsl,imx31-i2c
+- fsl,imx50-i2c
+- fsl,imx51-i2c
+- fsl,imx53-i2c
+- fsl,imx6q-i2c
+- fsl,imx6sl-i2c
+- fsl,imx6sx-i2c
+- fsl,imx6sll-i2c
+- fsl,imx6ul-i2c
+- fsl,imx7s-i2c
+- fsl,imx8mq-i2c
+- fsl,imx8mm-i2c
+- fsl,imx8mn-i2c
+- fsl,imx8mp-i2c
+  - const: fsl,imx21-i2c
+
+  reg:
+maxItems: 1
+
+  interrupts:
+maxItems: 1
+
+  clocks:
+maxItems: 1
+
+  clock-names:
+const: ipg
+
+  clock-frequency:
+$ref: /schemas/types.yaml#/definitions/uint32
+description: |
+  Constains desired I2C/HS-I2C bus clock frequency in Hz.
+  The absence of the property indicates the default frequency 100 kHz.
+default: 10
+
+  dmas:
+items:
+  - description: DMA controller phandle and request line for RX
+  - description: DMA controller phandle and request line for TX
+
+  dma-names:
+items:
+  - const: rx
+  - const: tx
+
+  sda-gpios:
+$ref: '/schemas/types.yaml#/definitions/phandle'
+description: |
+  gpio used for the sda signal, this should be flagged as
+  active high using open drain with (GPIO_ACTIVE_HIGH|GPIO_OPEN_DRAIN)
+  from  since the signal is by definition
+  open drain.
+maxItems: 1
+
+  scl-gpios:
+

[PATCH V2 0/3] Convert i.MX/MXS I2C/LPI2C binding doc to json-schema

[Anson Huang]

Coverts i.MX/MXS I2C/LPI2C binding doc to json-schema, some examples are too 
old,
update them based on latest DT file, also add more compatible based on 
supported SoCs.

Compated to V1, this patch series adds "additionalProperties: false" for each
binding doc.

Anson Huang (3):
  dt-bindings: i2c: Convert imx lpi2c to json-schema
  dt-bindings: i2c: Convert mxs i2c to json-schema
  dt-bindings: i2c: Convert imx i2c to json-schema

 .../devicetree/bindings/i2c/i2c-imx-lpi2c.txt  |  20 
 .../devicetree/bindings/i2c/i2c-imx-lpi2c.yaml |  47 
 Documentation/devicetree/bindings/i2c/i2c-imx.txt  |  49 -
 Documentation/devicetree/bindings/i2c/i2c-imx.yaml | 119 +
 Documentation/devicetree/bindings/i2c/i2c-mxs.txt  |  25 -
 Documentation/devicetree/bindings/i2c/i2c-mxs.yaml |  55 ++
 6 files changed, 221 insertions(+), 94 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/i2c/i2c-imx-lpi2c.txt
 create mode 100644 Documentation/devicetree/bindings/i2c/i2c-imx-lpi2c.yaml
 delete mode 100644 Documentation/devicetree/bindings/i2c/i2c-imx.txt
 create mode 100644 Documentation/devicetree/bindings/i2c/i2c-imx.yaml
 delete mode 100644 Documentation/devicetree/bindings/i2c/i2c-mxs.txt
 create mode 100644 Documentation/devicetree/bindings/i2c/i2c-mxs.yaml

-- 
2.7.4

[PATCH V2 1/3] dt-bindings: i2c: Convert imx lpi2c to json-schema

[Anson Huang]

Convert the i.MX LPI2C binding to DT schema format using json-schema

Signed-off-by: Anson Huang 
---
Changes since V1:
- add "additionalProperties: false".
---
 .../devicetree/bindings/i2c/i2c-imx-lpi2c.txt  | 20 -
 .../devicetree/bindings/i2c/i2c-imx-lpi2c.yaml | 47 ++
 2 files changed, 47 insertions(+), 20 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/i2c/i2c-imx-lpi2c.txt
 create mode 100644 Documentation/devicetree/bindings/i2c/i2c-imx-lpi2c.yaml

diff --git a/Documentation/devicetree/bindings/i2c/i2c-imx-lpi2c.txt 
b/Documentation/devicetree/bindings/i2c/i2c-imx-lpi2c.txt
deleted file mode 100644
index f0c072f..000
--- a/Documentation/devicetree/bindings/i2c/i2c-imx-lpi2c.txt
+++ /dev/null
@@ -1,20 +0,0 @@
-* Freescale Low Power Inter IC (LPI2C) for i.MX
-
-Required properties:
-- compatible :
-  - "fsl,imx7ulp-lpi2c" for LPI2C compatible with the one integrated on 
i.MX7ULP soc
-  - "fsl,imx8qxp-lpi2c" for LPI2C compatible with the one integrated on 
i.MX8QXP soc
-  - "fsl,imx8qm-lpi2c" for LPI2C compatible with the one integrated on i.MX8QM 
soc
-- reg : address and length of the lpi2c master registers
-- interrupts : lpi2c interrupt
-- clocks : lpi2c clock specifier
-
-Examples:
-
-lpi2c7: lpi2c7@40a5 {
-   compatible = "fsl,imx7ulp-lpi2c";
-   reg = <0x40A5 0x1>;
-   interrupt-parent = <>;
-   interrupts = ;
-   clocks = < IMX7ULP_CLK_LPI2C7>;
-};
diff --git a/Documentation/devicetree/bindings/i2c/i2c-imx-lpi2c.yaml 
b/Documentation/devicetree/bindings/i2c/i2c-imx-lpi2c.yaml
new file mode 100644
index 000..ac0bc5d
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-imx-lpi2c.yaml
@@ -0,0 +1,47 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/i2c/i2c-imx-lpi2c.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale Low Power Inter IC (LPI2C) for i.MX
+
+maintainers:
+  - Anson Huang 
+
+properties:
+  compatible:
+enum:
+  - fsl,imx7ulp-lpi2c
+  - fsl,imx8qxp-lpi2c
+  - fsl,imx8qm-lpi2c
+
+  reg:
+maxItems: 1
+
+  interrupts:
+maxItems: 1
+
+  clocks:
+maxItems: 1
+
+required:
+  - compatible
+  - reg
+  - interrupts
+  - clocks
+
+additionalProperties: false
+
+examples:
+  - |
+#include 
+#include 
+
+lpi2c7@40a5 {
+compatible = "fsl,imx7ulp-lpi2c";
+reg = <0x40A5 0x1>;
+interrupt-parent = <>;
+interrupts = ;
+clocks = < IMX7ULP_CLK_LPI2C7>;
+};
-- 
2.7.4

[PATCH v6 5/6] dt-bindings: power: Extend RPMh power controller binding to describe thermal warming device

[Thara Gopinath]

RPMh power controller hosts mx domain that can be used as thermal warming
device. Add #cooling-cells property to the power domain provider node to
indicate this.

Signed-off-by: Thara Gopinath 
Acked-by: Rob Herring 
---

v3->v4:
- Removed subnode to indicate that mx power domain is a warming
  device. Instead #cooling-cells is used as a power domain
  provider property to indicate if the provider hosts a power
  domain that can be used as a warming device.

v4->v5:
Moved the property from .txt format to .yaml format.

 Documentation/devicetree/bindings/power/qcom,rpmpd.yaml | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml 
b/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml
index 8058955fb3b9..a4fbbd88ce18 100644
--- a/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml
+++ b/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml
@@ -28,6 +28,9 @@ properties:
   '#power-domain-cells':
 const: 1
 
+  '#cooling-cells':
+const: 2
+
   operating-points-v2: true
 
   opp-table:
-- 
2.20.1

[PATCH v6 2/6] soc: qcom: rpmhpd: Introduce function to retrieve power domain performance state count

[Thara Gopinath]

Populate .get_performance_state_count in genpd ops to retrieve the count of
performance states supported by a rpmh power domain.

Signed-off-by: Thara Gopinath 
Reviewed-by: Bjorn Andersson 
---
 drivers/soc/qcom/rpmhpd.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/soc/qcom/rpmhpd.c b/drivers/soc/qcom/rpmhpd.c
index e72426221a69..a9c597143525 100644
--- a/drivers/soc/qcom/rpmhpd.c
+++ b/drivers/soc/qcom/rpmhpd.c
@@ -362,6 +362,13 @@ static unsigned int rpmhpd_get_performance_state(struct 
generic_pm_domain *genpd
return dev_pm_opp_get_level(opp);
 }
 
+static int rpmhpd_performance_states_count(struct generic_pm_domain *domain)
+{
+   struct rpmhpd *pd = domain_to_rpmhpd(domain);
+
+   return pd->level_count;
+}
+
 static int rpmhpd_update_level_mapping(struct rpmhpd *rpmhpd)
 {
int i;
@@ -450,6 +457,7 @@ static int rpmhpd_probe(struct platform_device *pdev)
rpmhpds[i]->pd.power_on = rpmhpd_power_on;
rpmhpds[i]->pd.set_performance_state = 
rpmhpd_set_performance_state;
rpmhpds[i]->pd.opp_to_performance_state = 
rpmhpd_get_performance_state;
+   rpmhpds[i]->pd.get_performance_state_count = 
rpmhpd_performance_states_count;
pm_genpd_init([i]->pd, NULL, true);
 
data->domains[i] = [i]->pd;
-- 
2.20.1

[PATCH v6 6/6] arm64: dts: qcom: Indicate rpmhpd hosts a power domain that can be used as a warming device.

[Thara Gopinath]

RPMh hosts mx power domain that can be used to warm up the SoC.  Indicate
this by using #cooling-cells property.

Signed-off-by: Thara Gopinath 
Reviewed-by: Ulf Hansson 
Reviewed-by: Bjorn Andersson 
---

v3->v4:
- Removed subnode to indicate that mx power domain is a warming
  device. Instead #cooling-cells is used as a power domain
  provider property to indicate if the provider hosts a power
  domain that can be used as a warming device.

 arch/arm64/boot/dts/qcom/sdm845.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi 
b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index 8eb5a31346d2..dcc3bcd16b68 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -3854,6 +3854,7 @@
rpmhpd: power-controller {
compatible = "qcom,sdm845-rpmhpd";
#power-domain-cells = <1>;
+   #cooling-cells = <2>;
operating-points-v2 = <_opp_table>;
 
rpmhpd_opp_table: opp-table {
-- 
2.20.1

[PATCH v6 4/6] soc: qcom: Extend RPMh power controller driver to register warming devices.

[Thara Gopinath]

RPMh power control hosts power domains that can be used as
thermal warming devices. Register these power domains
with the generic power domain warming device thermal framework.

Signed-off-by: Thara Gopinath 
---

v3->v4:
- Introduce a boolean value is_warming_dev in rpmhpd structure to
  indicate if a generic power domain can be used as a warming
  device or not.With this change, device tree no longer has to
  specify which power domain inside the rpmh power domain provider
  is a warming device.
- Move registering of warming devices into a late initcall to
  ensure that warming devices are registered after thermal
  framework is initialized.

v5->v6:
- Moved back registering of warming devices into probe since
  Bjorn pointed out that now the driver can be initialized as
  as a module, late_initcall will not work. Thermal framework
  takes care of binding a cooling device to a thermal zone even
  if the cooling device is registered before the thermal framework
  is initialized.

 drivers/soc/qcom/rpmhpd.c | 17 -
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/drivers/soc/qcom/rpmhpd.c b/drivers/soc/qcom/rpmhpd.c
index a9c597143525..29e1eb4d11af 100644
--- a/drivers/soc/qcom/rpmhpd.c
+++ b/drivers/soc/qcom/rpmhpd.c
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -49,6 +50,7 @@ struct rpmhpd {
boolenabled;
const char  *res_name;
u32 addr;
+   boolis_warming_dev;
 };
 
 struct rpmhpd_desc {
@@ -90,6 +92,7 @@ static struct rpmhpd sdm845_mx = {
.pd = { .name = "mx", },
.peer = _mx_ao,
.res_name = "mx.lvl",
+   .is_warming_dev = true,
 };
 
 static struct rpmhpd sdm845_mx_ao = {
@@ -472,7 +475,19 @@ static int rpmhpd_probe(struct platform_device *pdev)
   [i]->pd);
}
 
-   return of_genpd_add_provider_onecell(pdev->dev.of_node, data);
+   ret = of_genpd_add_provider_onecell(pdev->dev.of_node, data);
+
+   if (ret)
+   return ret;
+
+   if (!of_find_property(dev->of_node, "#cooling-cells", NULL))
+   return 0;
+
+   for (i = 0; i < num_pds; i++)
+   if (rpmhpds[i]->is_warming_dev)
+   of_pd_warming_register(rpmhpds[i]->dev, i);
+
+   return 0;
 }
 
 static struct platform_driver rpmhpd_driver = {
-- 
2.20.1

[PATCH v6 1/6] PM/Domains: Add support for retrieving genpd performance states information

[Thara Gopinath]

Add two new APIs in the genpd framework, dev_pm_genpd_get_performance_state
to return the current performance state of a power domain and
dev_pm_genpd_performance_state_count to return the total number of
performance states supported by a power domain. Since the genpd framework
does not maintain a count of number of performance states supported by a
power domain, introduce a new callback(.get_performance_state_count) that
can be used to retrieve this information from power domain drivers.

These APIs are added to aid the implementation of a power domain as a
warming device. Linux kernel cooling device framework(into which warming
device can be plugged in) requires during initialization to be provided
with the maximum number of states that can be supported. When a power
domain acts as a warming device, the max state is the max number of
perfomrance states supported by the power domain. The cooling device
framework implements API to retrieve the current state of the cooling
device. This in turn translates to the current performance state of the
power domain.

Signed-off-by: Thara Gopinath 
Reviewed-by: Ulf Hansson 
Reviewed-by: Bjorn Andersson 
---
 drivers/base/power/domain.c | 37 +
 include/linux/pm_domain.h   | 13 +
 2 files changed, 50 insertions(+)

diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index 0a01df608849..88f8773cabe7 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -408,6 +408,43 @@ int dev_pm_genpd_set_performance_state(struct device *dev, 
unsigned int state)
 }
 EXPORT_SYMBOL_GPL(dev_pm_genpd_set_performance_state);
 
+int dev_pm_genpd_get_performance_state(struct device *dev)
+{
+   struct generic_pm_domain *genpd;
+   unsigned int state;
+
+   genpd = dev_to_genpd_safe(dev);
+   if (IS_ERR(genpd))
+   return -ENODEV;
+
+   genpd_lock(genpd);
+   state = genpd->performance_state;
+   genpd_unlock(genpd);
+
+   return state;
+}
+EXPORT_SYMBOL_GPL(dev_pm_genpd_get_performance_state);
+
+int dev_pm_genpd_performance_state_count(struct device *dev)
+{
+   struct generic_pm_domain *genpd;
+   int count;
+
+   genpd = dev_to_genpd_safe(dev);
+   if (IS_ERR(genpd))
+   return -ENODEV;
+
+   if (unlikely(!genpd->get_performance_state_count))
+   return -EINVAL;
+
+   genpd_lock(genpd);
+   count = genpd->get_performance_state_count(genpd);
+   genpd_unlock(genpd);
+
+   return count;
+}
+EXPORT_SYMBOL_GPL(dev_pm_genpd_performance_state_count);
+
 static int _genpd_power_on(struct generic_pm_domain *genpd, bool timed)
 {
unsigned int state_idx = genpd->state_idx;
diff --git a/include/linux/pm_domain.h b/include/linux/pm_domain.h
index 9ec78ee53652..7d415350380f 100644
--- a/include/linux/pm_domain.h
+++ b/include/linux/pm_domain.h
@@ -117,6 +117,7 @@ struct generic_pm_domain {
 struct dev_pm_opp *opp);
int (*set_performance_state)(struct generic_pm_domain *genpd,
 unsigned int state);
+   int (*get_performance_state_count)(struct generic_pm_domain *genpd);
struct gpd_dev_ops dev_ops;
s64 max_off_time_ns;/* Maximum allowed "suspended" time. */
bool max_off_time_changed;
@@ -204,6 +205,8 @@ int pm_genpd_init(struct generic_pm_domain *genpd,
  struct dev_power_governor *gov, bool is_off);
 int pm_genpd_remove(struct generic_pm_domain *genpd);
 int dev_pm_genpd_set_performance_state(struct device *dev, unsigned int state);
+int dev_pm_genpd_get_performance_state(struct device *dev);
+int dev_pm_genpd_performance_state_count(struct device *dev);
 
 extern struct dev_power_governor simple_qos_governor;
 extern struct dev_power_governor pm_domain_always_on_gov;
@@ -251,6 +254,16 @@ static inline int 
dev_pm_genpd_set_performance_state(struct device *dev,
return -ENOTSUPP;
 }
 
+static inline int dev_pm_genpd_get_performance_state(struct device *dev)
+{
+   return -ENOTSUPP;
+}
+
+static inline int dev_pm_genpd_performance_state_count(struct device *dev)
+{
+   return -ENOTSUPP;
+}
+
 #define simple_qos_governor(*(struct dev_power_governor *)(NULL))
 #define pm_domain_always_on_gov(*(struct dev_power_governor 
*)(NULL))
 #endif
-- 
2.20.1