Re: [GIT PULL] io_uring fixes for 5.9-rc

[pr-tracker-bot]

The pull request you sent on Fri, 2 Oct 2020 11:48:48 -0600:

> git://git.kernel.dk/linux-block.git tags/io_uring-5.9-2020-10-02

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

Thank you!

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

Re: [GIT PULL] PCI fixes for v5.9

[pr-tracker-bot]

The pull request you sent on Fri, 2 Oct 2020 14:23:40 -0500:

> git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git 
> tags/pci-v5.9-fixes-2

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

Thank you!

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

Re: [GIT PULL] SCSI fixes for 5.9-rc7

[pr-tracker-bot]

The pull request you sent on Fri, 02 Oct 2020 12:28:04 -0700:

> git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git scsi-fixes

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

Thank you!

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

Re: [PATCH v7 3/3] media: i2c: ov772x: Add test pattern control

[Sakari Ailus]

On Fri, Oct 02, 2020 at 10:32:05PM +0100, Lad, Prabhakar wrote:
> Hi Sakari,
> 
> Thank you for the review.
> 
> On Fri, Oct 2, 2020 at 10:13 PM Sakari Ailus
>  wrote:
> >
> > On Fri, Oct 02, 2020 at 05:56:56PM +0100, Lad Prabhakar wrote:
> > > Add support for test pattern control supported by the sensor.
> > >
> > > Signed-off-by: Lad Prabhakar 
> > > Reviewed-by: Biju Das 
> > > Reviewed-by: Jacopo Mondi 
> > > ---
> > >  drivers/media/i2c/ov772x.c | 17 -
> > >  1 file changed, 16 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/media/i2c/ov772x.c b/drivers/media/i2c/ov772x.c
> > > index 6b46ad493bf7..b7e10c34ef59 100644
> > > --- a/drivers/media/i2c/ov772x.c
> > > +++ b/drivers/media/i2c/ov772x.c
> > > @@ -227,7 +227,7 @@
> > >
> > >  /* COM3 */
> > >  #define SWAP_MASK   (SWAP_RGB | SWAP_YUV | SWAP_ML)
> > > -#define IMG_MASK(VFLIP_IMG | HFLIP_IMG)
> > > +#define IMG_MASK(VFLIP_IMG | HFLIP_IMG | SCOLOR_TEST)
> > >
> > >  #define VFLIP_IMG   0x80 /* Vertical flip image ON/OFF selection */
> > >  #define HFLIP_IMG   0x40 /* Horizontal mirror image ON/OFF selection 
> > > */
> > > @@ -425,6 +425,7 @@ struct ov772x_priv {
> > >   const struct ov772x_win_size *win;
> > >   struct v4l2_ctrl *vflip_ctrl;
> > >   struct v4l2_ctrl *hflip_ctrl;
> > > + unsigned int  test_pattern;
> >
> > Alignment.
> >
> > You can get away with one or possibly two but three is too many in such a
> > small number of lines. :-)
> >
> It's aligned as per structure members (non pointers)

What a weird practice. Oh well. Keep as-is then.

checkpatch.pl no longer seems to complain about lines over 80. That keeps
the number of warnings lower but may lead to unintentional long lines when
you don't need them.

-- 
Sakari Ailus

Re: [PATCH v2 2/2] selftests/vm: fix run_vmtest.sh: restore executable bits, and "s" in name

[Andrew Morton]

On Fri, 2 Oct 2020 01:40:49 -0700 John Hubbard  wrote:

> commit cb2ab76685d7 ("selftests/vm: rename run_vmtests -->
> run_vmtests.sh") changed the name of run_vmtests to run_vmtest.sh, but
> inadvertently dropped the executable bits.

We cannot depend on the x bit.  Because downloading linux-foo.patch.gz
and installing it with patch(1) is a supported way of obtaining Linux. 
And patch(1) loses the x bit.

If $(CONFIG_SHELL) is unavailable then invoking the script with
"/bin/sh foo.sh" should do the trick.

> Somehow the name is missing an "s", too. Fix both of these problems by
> renaming, and restoring the executable bits.

But that's what your patch did!

tools/testing/selftests/vm/{run_vmtests => run_vmtest.sh} | 0

Here: https://lkml.kernel.org/r/20200929212747.251804-4-jhubb...@nvidia.com


So all confused.  I'll drop this version - please redo and resend when
convenient?

[ANNOUNCE] 4.19.148-rt64

[Tom Zanussi]

Hello RT Folks!

I'm pleased to announce the 4.19.148-rt64 stable release.

This release is just an update to the new stable 4.19.148
version and no RT specific changes have been made.

You can get this release via the git tree at:

  git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git

  branch: v4.19-rt
  Head SHA1: 0f0eda46246e76215f9056d17df7d964a2047cb8

Or to build 4.19.148-rt64 directly, the following patches should be applied:

  https://www.kernel.org/pub/linux/kernel/v4.x/linux-4.19.tar.xz

  https://www.kernel.org/pub/linux/kernel/v4.x/patch-4.19.148.xz

  
https://www.kernel.org/pub/linux/kernel/projects/rt/4.19/patch-4.19.148-rt64.patch.xz

Enjoy!

   Tom

Re: [PATCH 1/1] selftests/vm: 8x compaction_test speedup

[Andrew Morton]

On Fri, 2 Oct 2020 01:06:21 -0700 John Hubbard  wrote:

> This patch reduces the running time for compaction_test from about 27
> sec, to 3.3 sec, which is about an 8x speedup.
> 
> These numbers are for an Intel x86_64 system with 32 GB of DRAM.
> 
> The compaction_test.c program was spending most of its time doing
> mmap(), 1 MB at a time, on about 25 GB of memory.
> 
> Instead, do the mmaps 100 MB at a time. (Going past 100 MB doesn't make
> things go much faster, because other parts of the program are using the
> remaining time.)

Seems nice.  It's been 5 years, but hopefully Sri is still at Akamai?

> --- a/tools/testing/selftests/vm/compaction_test.c
> +++ b/tools/testing/selftests/vm/compaction_test.c
> @@ -18,7 +18,8 @@
>  
>  #include "../kselftest.h"
>  
> -#define MAP_SIZE 1048576
> +#define MAP_SIZE_MB  100
> +#define MAP_SIZE (MAP_SIZE_MB * 1024 * 1024)
>  
>  struct map_list {
>   void *map;
> @@ -165,7 +166,7 @@ int main(int argc, char **argv)
>   void *map = NULL;
>   unsigned long mem_free = 0;
>   unsigned long hugepage_size = 0;
> - unsigned long mem_fragmentable = 0;
> + long mem_fragmentable_MB = 0;
>  
>   if (prereq() != 0) {
>   printf("Either the sysctl compact_unevictable_allowed is not\n"
> @@ -190,9 +191,9 @@ int main(int argc, char **argv)
>   return -1;
>   }
>  
> - mem_fragmentable = mem_free * 0.8 / 1024;
> + mem_fragmentable_MB = mem_free * 0.8 / 1024;
>  
> - while (mem_fragmentable > 0) {
> + while (mem_fragmentable_MB > 0) {
>   map = mmap(NULL, MAP_SIZE, PROT_READ | PROT_WRITE,
>  MAP_ANONYMOUS | MAP_PRIVATE | MAP_LOCKED, -1, 0);
>   if (map == MAP_FAILED)
> @@ -213,7 +214,7 @@ int main(int argc, char **argv)
>   for (i = 0; i < MAP_SIZE; i += page_size)
>   *(unsigned long *)(map + i) = (unsigned long)map + i;
>  
> - mem_fragmentable--;
> + mem_fragmentable_MB -= MAP_SIZE_MB;
>   }
>  
>   for (entry = list; entry != NULL; entry = entry->next) {
> -- 
> 2.28.0
> 

Re: [PATCH v2 2/2] selftests/vm: fix run_vmtest.sh: restore executable bits, and "s" in name

[John Hubbard]

On 10/2/20 2:59 PM, Andrew Morton wrote:

On Fri, 2 Oct 2020 01:40:49 -0700 John Hubbard  wrote:


commit cb2ab76685d7 ("selftests/vm: rename run_vmtests -->
run_vmtests.sh") changed the name of run_vmtests to run_vmtest.sh, but
inadvertently dropped the executable bits.


We cannot depend on the x bit.  Because downloading linux-foo.patch.gz
and installing it with patch(1) is a supported way of obtaining Linux.
And patch(1) loses the x bit.


OK. I was just hoping that, within our processes here, there's still some
way to get something committed that does have the bit set. Because it's a
nice touch to be able to do

./run_vmtests.sh

Not a big deal of course.



If $(CONFIG_SHELL) is unavailable then invoking the script with
"/bin/sh foo.sh" should do the trick.


OK, I'll use that for the Makefile.




Somehow the name is missing an "s", too. Fix both of these problems by
renaming, and restoring the executable bits.


But that's what your patch did!

tools/testing/selftests/vm/{run_vmtests => run_vmtest.sh} | 0

Here: https://lkml.kernel.org/r/20200929212747.251804-4-jhubb...@nvidia.com



Yes, the dropped "s" is my mistake!



So all confused.  I'll drop this version - please redo and resend when
convenient?



Coming up, sorry about the mess here!

thanks,
--
John Hubbard
NVIDIA

Re: [PATCH v3 1/3] tracing: Change STR_VAR_MAX_LEN

[Tom Zanussi]

Hi Steve,

On Fri, 2020-10-02 at 15:44 -0400, Steven Rostedt wrote:
> On Thu,  1 Oct 2020 16:46:44 -0500
> Tom Zanussi  wrote:
> 
> > 32 is too small for this value, and anyway it makes more sense to
> > use
> > MAX_FILTER_STR_VAL, as this is also the value used for variable-
> > length
> > __strings.
> > 
> > Tested-by: Axel Rasmussen 
> > Signed-off-by: Tom Zanussi 
> > ---
> >  kernel/trace/trace_synth.h | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/kernel/trace/trace_synth.h
> > b/kernel/trace/trace_synth.h
> > index ac35c45207c4..5166705d1556 100644
> > --- a/kernel/trace/trace_synth.h
> > +++ b/kernel/trace/trace_synth.h
> > @@ -7,7 +7,7 @@
> >  #define SYNTH_SYSTEM   "synthetic"
> >  #define SYNTH_FIELDS_MAX   32
> >  
> > -#define STR_VAR_LEN_MAX32 /* must be multiple of
> > sizeof(u64) */
> > +#define STR_VAR_LEN_MAXMAX_FILTER_STR_VAL /* must be
> > multiple of sizeof(u64) */
> 
> Hmm, this requirement is now passed to MAX_FILTER_STR_VAL, but
> there's no
> mention of it there. I guess we should have a
> 
>   BUILD_BUG_ON(STR_VAR_LEN_MAX & (sizeof(u64) - 1));
> 
> in C code somewhere.

Good point.  I'll add that in the next version.

Thanks,

Tom

Re: [PATCH v2 3/3] tracing: Add support for dynamic strings to synthetic events

[Tom Zanussi]

Hi Masami,

On Fri, 2020-10-02 at 16:17 +0900, Masami Hiramatsu wrote:
> Hi Tom,
> 
> On Wed, 30 Sep 2020 13:40:52 -0500
> Tom Zanussi  wrote:
> 
> > Currently, sythetic events only support static string fields such
> > as:
> > 
> >   # echo 'test_latency u64 lat; char somename[32]' >
> > /sys/kernel/debug/tracing/synthetic_events
> > 
> > Which is fine, but wastes a lot of space in the event.
> > 
> > It also prevents the most commonly-defined strings in the existing
> > trace events e.g. those defined using __string(), from being passed
> > to
> > synthetic events via the trace() action.
> > 
> > With this change, synthetic events with dynamic fields can be
> > defined:
> > 
> >   # echo 'test_latency u64 lat; char somename[]' >
> > /sys/kernel/debug/tracing/synthetic_events
> 
> Could you add a testcase (and update existing one) of ftracetest
> for this new feature too?
> 

Yes, I'll add it in the next version.

> > 
> > And the trace() action can be used to generate events using either
> > dynamic or static strings:
> > 
> >   # echo 'hist:keys=name:lat=common_timestamp.usecs-
> > $ts0:onmatch(sys.event).test_latency($lat,name)' >
> > /sys/kernel/debug/tracing/events
> > 
> > The synthetic event dynamic strings are implemented in the same way
> > as
> > the existing __data_loc strings and appear as such in the format
> > file.
> > 
> > Signed-off-by: Tom Zanussi 
> > ---
> >  Documentation/trace/events.rst  |  15 +-
> >  Documentation/trace/histogram.rst   |  18 +++
> >  kernel/trace/synth_event_gen_test.c |  18 ++-
> >  kernel/trace/trace_events_hist.c|   9 ++
> >  kernel/trace/trace_events_synth.c   | 239
> > 
> >  kernel/trace/trace_synth.h  |   4 +
> 
> And you might also need to update tracefs/README so that user
> can check whether the kernel supports dynamic string or not.
> 

Yeah, good to add regardless, will do.

Thanks,

Tom

Re: [PATCH v2 3/6] mm: Speedup mremap on 1GB or larger regions

[Kalesh Singh]

Hi Kirill, thank you for the feedback.

On Fri, Oct 2, 2020 at 12:51 PM Kirill A. Shutemov
 wrote:
>
> On Fri, Oct 02, 2020 at 04:20:48PM +, Kalesh Singh wrote:
> > Android needs to move large memory regions for garbage collection.
> > The GC requires moving physical pages of multi-gigabyte heap
> > using mremap. During this move, the application threads have to
> > be paused for correctness. It is critical to keep this pause as
> > short as possible to avoid jitters during user interaction.
> >
> > Optimize mremap for >= 1GB-sized regions by moving at the PUD/PGD
> > level if the source and destination addresses are PUD-aligned.
> > For CONFIG_PGTABLE_LEVELS == 3, moving at the PUD level in effect moves
> > PGD entries, since the PUD entry is “folded back” onto the PGD entry.
> > Add HAVE_MOVE_PUD so that architectures where moving at the PUD level
> > isn't supported/tested can turn this off by not selecting the config.
> >
> > Fix build test error from v1 of this series reported by
> > kernel test robot in [1].
> >
> > [1] 
> > https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org/thread/CKPGL4FH4NG7TGH2CVYX2UX76L25BTA3/
> >
> > Signed-off-by: Kalesh Singh 
> > Reported-by: kernel test robot 
> > ---
> > Changes in v2:
> >   - Update commit message with description of Android GC's use case.
> >   - Move set_pud_at() to a separate patch.
> >   - Use switch() instead of ifs in move_pgt_entry()
> >   - Fix build test error reported by kernel test robot on x86_64 in [1].
> > Guard move_huge_pmd() with IS_ENABLED(CONFIG_TRANSPARENT_HUGEPAGE),
> > since this section doesn't get optimized out in the kernel test
> > robot's build test when HAVE_MOVE_PUD is enabled.
> >   - Keep WARN_ON_ONCE(1) instead of BUILD_BUG() for the aforementioned
> > reason.
>
> Okay, but IS_ENABLED(CONFIG_TRANSPARENT_HUGEPAGE) on the caller side would
> do the trick, I believe.
I tried moving this to the caller side in move_page_tables(),
-   if (extent == HPAGE_PMD_SIZE &&
+   if (extent == HPAGE_PMD_SIZE &&
IS_ENABLED(CONFIG_TRANSPARENT_HUGEPAGE) &&
but it produces the same error as reported by kernel test robot:
ld.lld: error: undefined symbol: move_huge_pmd
I'm not sure why these are different but the kernel test robot
compiler complains.
>
> >
> >  arch/Kconfig |   7 ++
> >  mm/mremap.c  | 220 ---
> >  2 files changed, 197 insertions(+), 30 deletions(-)
> >
> > diff --git a/arch/Kconfig b/arch/Kconfig
> > index af14a567b493..5eabaa00bf9b 100644
> > --- a/arch/Kconfig
> > +++ b/arch/Kconfig
> > @@ -602,6 +602,13 @@ config HAVE_IRQ_TIME_ACCOUNTING
> > Archs need to ensure they use a high enough resolution clock to
> > support irq time accounting and then call 
> > enable_sched_clock_irqtime().
> >
> > +config HAVE_MOVE_PUD
> > + bool
> > + help
> > +   Architectures that select this are able to move page tables at the
> > +   PUD level. If there are only 3 page table levels, the move 
> > effectively
> > +   happens at the PGD level.
> > +
> >  config HAVE_MOVE_PMD
> >   bool
> >   help
> > diff --git a/mm/mremap.c b/mm/mremap.c
> > index 138abbae4f75..c1d6ab667d70 100644
> > --- a/mm/mremap.c
> > +++ b/mm/mremap.c
> > @@ -249,14 +249,176 @@ static bool move_normal_pmd(struct vm_area_struct 
> > *vma, unsigned long old_addr,
> >
> >   return true;
> >  }
> > +#else
> > +static inline bool move_normal_pmd(struct vm_area_struct *vma, unsigned 
> > long old_addr,
> > +   unsigned long new_addr, pmd_t *old_pmd, pmd_t *new_pmd)
> > +{
> > + return false;
> > +}
> >  #endif
> >
> > +#ifdef CONFIG_HAVE_MOVE_PUD
> > +static pud_t *get_old_pud(struct mm_struct *mm, unsigned long addr)
> > +{
> > + pgd_t *pgd;
> > + p4d_t *p4d;
> > + pud_t *pud;
> > +
> > + pgd = pgd_offset(mm, addr);
> > + if (pgd_none_or_clear_bad(pgd))
> > + return NULL;
> > +
> > + p4d = p4d_offset(pgd, addr);
> > + if (p4d_none_or_clear_bad(p4d))
> > + return NULL;
> > +
> > + pud = pud_offset(p4d, addr);
> > + if (pud_none_or_clear_bad(pud))
> > + return NULL;
> > +
> > + return pud;
> > +}
> > +
> > +static pud_t *alloc_new_pud(struct mm_struct *mm, struct vm_area_struct 
> > *vma,
> > + unsigned long addr)
> > +{
> > + pgd_t *pgd;
> > + p4d_t *p4d;
> > + pud_t *pud;
> > +
> > + pgd = pgd_offset(mm, addr);
> > + p4d = p4d_alloc(mm, pgd, addr);
> > + if (!p4d)
> > + return NULL;
> > + pud = pud_alloc(mm, p4d, addr);
> > + if (!pud)
> > + return NULL;
> > +
> > + return pud;
> > +}
>
> Looks like a code duplication.
>
> Could you move these two helpers out of #ifdef CONFIG_HAVE_MOVE_PUD and
> make get_old_pmd() and alloc_new_pmd() use them?
Yes, that will be cleaner. I'll update it in the next version.
>
> > +
> > +static bool move_norma

[PATCH] drm/msm/dp: fixes wrong connection state caused by failure of link train

[Kuogee Hsieh]

Connection state is set incorrectly happen at either failure of link train
or cable plugged in while suspended. This patch fixes these problems.
This patch also replace ST_SUSPEND_PENDING with ST_DISPLAY_OFF.

Signed-off-by: Kuogee Hsieh 
---
 drivers/gpu/drm/msm/dp/dp_display.c | 52 ++---
 drivers/gpu/drm/msm/dp/dp_panel.c   |  5 +++
 2 files changed, 31 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/msm/dp/dp_display.c 
b/drivers/gpu/drm/msm/dp/dp_display.c
index 431dff9de797..898c6cc1643a 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -45,7 +45,7 @@ enum {
ST_CONNECT_PENDING,
ST_CONNECTED,
ST_DISCONNECT_PENDING,
-   ST_SUSPEND_PENDING,
+   ST_DISPLAY_OFF,
ST_SUSPENDED,
 };
 
@@ -340,8 +340,6 @@ static int dp_display_process_hpd_high(struct 
dp_display_private *dp)
}
 
dp_add_event(dp, EV_USER_NOTIFICATION, true, 0);
-
-
 end:
return rc;
 }
@@ -489,7 +487,7 @@ static int dp_hpd_plug_handle(struct dp_display_private 
*dp, u32 data)
mutex_lock(&dp->event_mutex);
 
state =  atomic_read(&dp->hpd_state);
-   if (state == ST_SUSPEND_PENDING) {
+   if (state == ST_DISPLAY_OFF || state == ST_SUSPENDED) {
mutex_unlock(&dp->event_mutex);
return 0;
}
@@ -511,14 +509,14 @@ static int dp_hpd_plug_handle(struct dp_display_private 
*dp, u32 data)
hpd->hpd_high = 1;
 
ret = dp_display_usbpd_configure_cb(&dp->pdev->dev);
-   if (ret) {  /* failed */
+   if (ret) {  /* link train failed */
hpd->hpd_high = 0;
atomic_set(&dp->hpd_state, ST_DISCONNECTED);
+   } else {
+   /* start sentinel checking in case of missing uevent */
+   dp_add_event(dp, EV_CONNECT_PENDING_TIMEOUT, 0, tout);
}
 
-   /* start sanity checking */
-   dp_add_event(dp, EV_CONNECT_PENDING_TIMEOUT, 0, tout);
-
mutex_unlock(&dp->event_mutex);
 
/* uevent will complete connection part */
@@ -563,10 +561,6 @@ static int dp_hpd_unplug_handle(struct dp_display_private 
*dp, u32 data)
mutex_lock(&dp->event_mutex);
 
state = atomic_read(&dp->hpd_state);
-   if (state == ST_SUSPEND_PENDING) {
-   mutex_unlock(&dp->event_mutex);
-   return 0;
-   }
 
if (state == ST_DISCONNECT_PENDING || state == ST_DISCONNECTED) {
mutex_unlock(&dp->event_mutex);
@@ -594,7 +588,7 @@ static int dp_hpd_unplug_handle(struct dp_display_private 
*dp, u32 data)
 */
dp_display_usbpd_disconnect_cb(&dp->pdev->dev);
 
-   /* start sanity checking */
+   /* start sentinel checking in case of missing uevent */
dp_add_event(dp, EV_DISCONNECT_PENDING_TIMEOUT, 0, DP_TIMEOUT_5_SECOND);
 
/* signal the disconnect event early to ensure proper teardown */
@@ -634,7 +628,7 @@ static int dp_irq_hpd_handle(struct dp_display_private *dp, 
u32 data)
 
/* irq_hpd can happen at either connected or disconnected state */
state =  atomic_read(&dp->hpd_state);
-   if (state == ST_SUSPEND_PENDING) {
+   if (state == ST_DISPLAY_OFF) {
mutex_unlock(&dp->event_mutex);
return 0;
}
@@ -1067,7 +1061,7 @@ static irqreturn_t dp_display_irq_handler(int irq, void 
*dev_id)
}
 
if (hpd_isr_status & DP_DP_IRQ_HPD_INT_MASK) {
-   /* delete connect pending event first */
+   /* delete sentinel connect pending checking */
dp_del_event(dp, EV_CONNECT_PENDING_TIMEOUT);
dp_add_event(dp, EV_IRQ_HPD_INT, 0, 0);
}
@@ -1186,19 +1180,19 @@ static int dp_pm_resume(struct device *dev)
 
dp = container_of(dp_display, struct dp_display_private, dp_display);
 
+   /* start from dis connection state */
+   atomic_set(&dp->hpd_state, ST_DISCONNECTED);
+
dp_display_host_init(dp);
 
dp_catalog_ctrl_hpd_config(dp->catalog);
 
status = dp_catalog_hpd_get_state_status(dp->catalog);
 
-   if (status) {
+   if (status)
dp->dp_display.is_connected = true;
-   } else {
+   else
dp->dp_display.is_connected = false;
-   /* make sure next resume host_init be called */
-   dp->core_initialized = false;
-   }
 
return 0;
 }
@@ -1214,6 +1208,9 @@ static int dp_pm_suspend(struct device *dev)
if (dp_display->power_on == true)
dp_display_disable(dp, 0);
 
+   /* host_init will be called at pm_resume */
+   dp->core_initialized = false;
+
atomic_set(&dp->hpd_state, ST_SUSPENDED);
 
return 0;
@@ -1343,6 +1340,9 @@ int msm_dp_display_enable(struct msm_dp *dp, struct 
drm_encoder *encoder)
 
mutex_lock(&dp_display->event_mutex);
 
+   /* delete 

Re: [PATCH v2 4/6] arm64: Add set_pud_at() function

[Kalesh Singh]

On Fri, Oct 2, 2020 at 12:52 PM Kirill A. Shutemov
 wrote:
>
> On Fri, Oct 02, 2020 at 04:20:49PM +, Kalesh Singh wrote:
> > set_pud_at() is used in move_normal_pud() for remapping
> > pages at the PUD level.
> >
> > Signed-off-by: Kalesh Singh 
> > ---
> >  arch/arm64/include/asm/pgtable.h | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/arch/arm64/include/asm/pgtable.h 
> > b/arch/arm64/include/asm/pgtable.h
> > index d5d3fbe73953..8848125e3024 100644
> > --- a/arch/arm64/include/asm/pgtable.h
> > +++ b/arch/arm64/include/asm/pgtable.h
> > @@ -415,6 +415,7 @@ static inline pmd_t pmd_mkdevmap(pmd_t pmd)
> >  #define pfn_pud(pfn,prot)__pud(__phys_to_pud_val((phys_addr_t)(pfn) << 
> > PAGE_SHIFT) | pgprot_val(prot))
> >
> >  #define set_pmd_at(mm, addr, pmdp, pmd)  set_pte_at(mm, addr, (pte_t 
> > *)pmdp, pmd_pte(pmd))
> > +#define set_pud_at(mm, addr, pudp, pud)  set_pte_at(mm, addr, (pte_t 
> > *)pudp, pud_pte(pud))
> >
> >  #define __p4d_to_phys(p4d)   __pte_to_phys(p4d_pte(p4d))
> >  #define __phys_to_p4d_val(phys)  __phys_to_pte_val(phys)
>
> Just fold it into the next patch.
Sounds good. I'll update in the next version. Thanks
>
> --
>  Kirill A. Shutemov
>
> --
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to kernel-team+unsubscr...@android.com.
>

[PATCH 0/4] Clean up UBSAN Makefile

[Kees Cook]

Hi,

This series attempts to address the issues seen with UBSAN's object-size
sanitizer causing problems under GCC. In the process, the Kconfig and
Makefile are refactored to do all the cc-option calls in the Kconfig.
Additionally start to detangle -Wno-maybe-uninitialized, and disable
UBSAN_TRAP under COMPILE_TEST for wider build coverage.

Thanks!

-Kees

Kees Cook (4):
  ubsan: Move cc-option tests into Kconfig
  ubsan: Disable object-size sanitizer under GCC
  ubsan: Force -Wno-maybe-uninitialized only for GCC
  ubsan: Disable UBSAN_TRAP for all*config

 lib/Kconfig.ubsan  | 58 +-
 scripts/Makefile.ubsan | 50 +---
 2 files changed, 74 insertions(+), 34 deletions(-)

-- 
2.25.1

[PATCH 3/4] ubsan: Force -Wno-maybe-uninitialized only for GCC

[Kees Cook]

Clang handles 'maybe-uninitialized' better in the face of using UBSAN,
so do not make this universally disabled for UBSAN builds.

Signed-off-by: Kees Cook 
---
 lib/Kconfig.ubsan  | 6 ++
 scripts/Makefile.ubsan | 6 +++---
 2 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/lib/Kconfig.ubsan b/lib/Kconfig.ubsan
index aeb2cdea0b94..1fc07f936e06 100644
--- a/lib/Kconfig.ubsan
+++ b/lib/Kconfig.ubsan
@@ -36,6 +36,12 @@ config UBSAN_KCOV_BROKEN
  See https://bugs.llvm.org/show_bug.cgi?id=45831 for the status
  in newer releases.
 
+config UBSAN_DISABLE_MAYBE_UNINITIALIZED
+   def_bool CC_IS_GCC
+   help
+ -fsanitize=* options makes GCC less smart than usual and
+ increases the number of 'maybe-uninitialized' false-positives.
+
 config CC_HAS_UBSAN_BOUNDS
def_bool $(cc-option,-fsanitize=bounds)
 
diff --git a/scripts/Makefile.ubsan b/scripts/Makefile.ubsan
index 72862da47baf..c5ef6bac09d4 100644
--- a/scripts/Makefile.ubsan
+++ b/scripts/Makefile.ubsan
@@ -1,8 +1,8 @@
 # SPDX-License-Identifier: GPL-2.0
 
-# -fsanitize=* options makes GCC less smart than usual and
-# increases the number of 'maybe-uninitialized' false-positives.
-ubsan-cflags-$(CONFIG_UBSAN) += $(call cc-disable-warning, maybe-uninitialized)
+# The "maybe-uninitialized" warning can be very noisy.
+ubsan-cflags-$(CONFIG_UBSAN_DISABLE_MAYBE_UNINITIALIZED) += \
+   $(call cc-disable-warning, 
maybe-uninitialized)
 
 # Enable available and selected UBSAN features.
 ubsan-cflags-$(CONFIG_UBSAN_ALIGNMENT) += -fsanitize=alignment
-- 
2.25.1

[PATCH 2/4] ubsan: Disable object-size sanitizer under GCC

[Kees Cook]

GCC's -fsanitize=object-size (as part of CONFIG_UBSAN_MISC) greatly
increases stack utilization. Do not allow this under GCC.

Suggested-by: Linus Torvalds 
Link: 
https://lore.kernel.org/lkml/CAHk-=wjPasyJrDuwDnpHJS2TuQfExwe=px-szlen8gfmaqj...@mail.gmail.com/
Signed-off-by: Kees Cook 
---
 lib/Kconfig.ubsan | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/lib/Kconfig.ubsan b/lib/Kconfig.ubsan
index c0b801871e0b..aeb2cdea0b94 100644
--- a/lib/Kconfig.ubsan
+++ b/lib/Kconfig.ubsan
@@ -104,6 +104,9 @@ config UBSAN_UNSIGNED_OVERFLOW
 
 config UBSAN_OBJECT_SIZE
def_bool UBSAN_MISC
+   # gcc hugely expands stack usage with -fsanitize=object-size
+   # 
https://lore.kernel.org/lkml/CAHk-=wjPasyJrDuwDnpHJS2TuQfExwe=px-szlen8gfmaqj...@mail.gmail.com/
+   depends on !CC_IS_GCC
depends on $(cc-option,-fsanitize=object-size)
 
 config UBSAN_BOOL
-- 
2.25.1

[PATCH 1/4] ubsan: Move cc-option tests into Kconfig

[Kees Cook]

Instead of doing if/endif blocks with cc-option calls in the UBSAN
Makefile, move all the tests into Kconfig and use the Makefile to
collect the results.

Suggested-by: Linus Torvalds 
Link: 
https://lore.kernel.org/lkml/CAHk-=wjPasyJrDuwDnpHJS2TuQfExwe=px-szlen8gfmaqj...@mail.gmail.com/
Signed-off-by: Kees Cook 
---
 lib/Kconfig.ubsan  | 48 +++-
 scripts/Makefile.ubsan | 50 ++
 2 files changed, 64 insertions(+), 34 deletions(-)

diff --git a/lib/Kconfig.ubsan b/lib/Kconfig.ubsan
index 58f8d03d037b..c0b801871e0b 100644
--- a/lib/Kconfig.ubsan
+++ b/lib/Kconfig.ubsan
@@ -36,10 +36,17 @@ config UBSAN_KCOV_BROKEN
  See https://bugs.llvm.org/show_bug.cgi?id=45831 for the status
  in newer releases.
 
+config CC_HAS_UBSAN_BOUNDS
+   def_bool $(cc-option,-fsanitize=bounds)
+
+config CC_HAS_UBSAN_ARRAY_BOUNDS
+   def_bool $(cc-option,-fsanitize=array-bounds)
+
 config UBSAN_BOUNDS
bool "Perform array index bounds checking"
default UBSAN
depends on !UBSAN_KCOV_BROKEN
+   depends on CC_HAS_UBSAN_ARRAY_BOUNDS || CC_HAS_UBSAN_BOUNDS
help
  This option enables detection of directly indexed out of bounds
  array accesses, where the array size is known at compile time.
@@ -47,11 +54,17 @@ config UBSAN_BOUNDS
  to the {str,mem}*cpy() family of functions (that is addressed
  by CONFIG_FORTIFY_SOURCE).
 
+config CC_ARG_UBSAN_BOUNDS
+   string
+   default "-fsanitize=array-bounds" if CC_HAS_UBSAN_ARRAY_BOUNDS
+   default "-fsanitize=bounds"
+   depends on UBSAN_BOUNDS
+
 config UBSAN_LOCAL_BOUNDS
bool "Perform array local bounds checking"
depends on UBSAN_TRAP
-   depends on CC_IS_CLANG
depends on !UBSAN_KCOV_BROKEN
+   depends on $(cc-option,-fsanitize=local-bounds)
help
  This option enables -fsanitize=local-bounds which traps when an
  exception/error is detected. Therefore, it should be enabled only
@@ -69,6 +82,38 @@ config UBSAN_MISC
  own Kconfig options. Disable this if you only want to have
  individually selected checks.
 
+config UBSAN_SHIFT
+   def_bool UBSAN_MISC
+   depends on $(cc-option,-fsanitize=shift)
+
+config UBSAN_DIV_ZERO
+   def_bool UBSAN_MISC
+   depends on $(cc-option,-fsanitize=integer-divide-by-zero)
+
+config UBSAN_UNREACHABLE
+   def_bool UBSAN_MISC
+   depends on $(cc-option,-fsanitize=unreachable)
+
+config UBSAN_SIGNED_OVERFLOW
+   def_bool UBSAN_MISC
+   depends on $(cc-option,-fsanitize=signed-integer-overflow)
+
+config UBSAN_UNSIGNED_OVERFLOW
+   def_bool UBSAN_MISC
+   depends on $(cc-option,-fsanitize=unsigned-integer-overflow)
+
+config UBSAN_OBJECT_SIZE
+   def_bool UBSAN_MISC
+   depends on $(cc-option,-fsanitize=object-size)
+
+config UBSAN_BOOL
+   def_bool UBSAN_MISC
+   depends on $(cc-option,-fsanitize=bool)
+
+config UBSAN_ENUM
+   def_bool UBSAN_MISC
+   depends on $(cc-option,-fsanitize=enum)
+
 config UBSAN_SANITIZE_ALL
bool "Enable instrumentation for the entire kernel"
depends on ARCH_HAS_UBSAN_SANITIZE_ALL
@@ -89,6 +134,7 @@ config UBSAN_ALIGNMENT
bool "Enable checks for pointers alignment"
default !HAVE_EFFICIENT_UNALIGNED_ACCESS
depends on !UBSAN_TRAP
+   depends on $(cc-option,-fsanitize=alignment)
help
  This option enables the check of unaligned memory accesses.
  Enabling this option on architectures that support unaligned
diff --git a/scripts/Makefile.ubsan b/scripts/Makefile.ubsan
index 9716dab06bc7..72862da47baf 100644
--- a/scripts/Makefile.ubsan
+++ b/scripts/Makefile.ubsan
@@ -1,37 +1,21 @@
 # SPDX-License-Identifier: GPL-2.0
 
-export CFLAGS_UBSAN :=
+# -fsanitize=* options makes GCC less smart than usual and
+# increases the number of 'maybe-uninitialized' false-positives.
+ubsan-cflags-$(CONFIG_UBSAN) += $(call cc-disable-warning, maybe-uninitialized)
 
-ifdef CONFIG_UBSAN_ALIGNMENT
-  CFLAGS_UBSAN += $(call cc-option, -fsanitize=alignment)
-endif
+# Enable available and selected UBSAN features.
+ubsan-cflags-$(CONFIG_UBSAN_ALIGNMENT) += -fsanitize=alignment
+ubsan-cflags-$(CONFIG_UBSAN_BOUNDS)+= $(CONFIG_CC_ARG_UBSAN_BOUNDS)
+ubsan-cflags-$(CONFIG_UBSAN_LOCAL_BOUNDS)  += -fsanitize=local-bounds
+ubsan-cflags-$(CONFIG_UBSAN_SHIFT) += -fsanitize=shift
+ubsan-cflags-$(CONFIG_UBSAN_DIV_ZERO)  += 
-fsanitize=integer-divide-by-zero
+ubsan-cflags-$(CONFIG_UBSAN_UNREACHABLE)   += -fsanitize=unreachable
+ubsan-cflags-$(CONFIG_UBSAN_SIGNED_OVERFLOW)   += 
-fsanitize=signed-integer-overflow
+ubsan-cflags-$(CONFIG_UBSAN_UNSIGNED_OVERFLOW) += 
-fsanitize=unsigned-integer-overflow
+ubsan-cflags-$(CONFIG_UBSAN_OBJECT_SIZE)   += -fsanitize=object-size
+ubsan-cflags-$(CONFIG_UBSAN_BOOL)  += -fsanitize=bool
+ubsan-cflags

[PATCH 4/4] ubsan: Disable UBSAN_TRAP for all*config

[Kees Cook]

Doing all*config builds attempts build as much as possible. UBSAN_TRAP
effectively short-circuits lib/usban.c, so it should be disabled for
COMPILE_TEST so that the lib/ubsan.c code gets built.

Signed-off-by: Kees Cook 
---
 lib/Kconfig.ubsan | 1 +
 1 file changed, 1 insertion(+)

diff --git a/lib/Kconfig.ubsan b/lib/Kconfig.ubsan
index 1fc07f936e06..b5b9da0b635a 100644
--- a/lib/Kconfig.ubsan
+++ b/lib/Kconfig.ubsan
@@ -14,6 +14,7 @@ if UBSAN
 
 config UBSAN_TRAP
bool "On Sanitizer warnings, abort the running kernel code"
+   depends on !COMPILE_TEST
depends on $(cc-option, -fsanitize-undefined-trap-on-error)
help
  Building kernels with Sanitizer features enabled tends to grow
-- 
2.25.1

Re: [PATCH 1/6] net: core: document two new elements of struct net_device

[David Miller]

From: Mauro Carvalho Chehab 
Date: Fri,  2 Oct 2020 07:49:45 +0200

> As warned by "make htmldocs", there are two new struct elements
> that aren't documented:
> 
>   ../include/linux/netdevice.h:2159: warning: Function parameter or 
> member 'unlink_list' not described in 'net_device'
>   ../include/linux/netdevice.h:2159: warning: Function parameter or 
> member 'nested_level' not described in 'net_device'
> 
> Fixes: 1fc70edb7d7b ("net: core: add nested_level variable in net_device")
> Signed-off-by: Mauro Carvalho Chehab 

Applied, thank you.

Re: [PATCH bpf-next v4 0/6] bpf: BTF support for ksyms

[Alexei Starovoitov]

On Tue, Sep 29, 2020 at 11:48 PM Hao Luo  wrote:
>
> Ah, this is the bug in pahole described in
> https://lkml.org/lkml/2020/8/20/1862. I proposed a fix [1] but it
> hasn't reached pahole's master branch. Let me ask Arnaldo to see if he
> is OK merging it.
>
> [1] https://www.spinics.net/lists/dwarves/msg00451.html
>
> On Tue, Sep 29, 2020 at 9:36 PM Alexei Starovoitov
>  wrote:
> >
> > On Tue, Sep 29, 2020 at 4:50 PM Hao Luo  wrote:
> > >
> > > v3 -> v4:
> > >  - Rebasing
> > >  - Cast bpf_[per|this]_cpu_ptr's parameter to void __percpu * before
> > >passing into per_cpu_ptr.

I've rebased it myself and applied. Thanks Hao.

Re: [PATCH 2/2] PCI: vmd: Enable ASPM for mobile platforms

[Bjorn Helgaas]

On Wed, Sep 30, 2020 at 04:24:54PM +0800, Kai-Heng Feng wrote:
> BIOS may not be able to program ASPM for links behind VMD, prevent Intel
> SoC from entering deeper power saving state.

It's not a question of BIOS not being *able* to configure ASPM.  I
think BIOS could do it, at least in principle, if it had a driver for
VMD.  Actually, it probably *does* include some sort of VMD code
because it sounds like BIOS can assign some Root Ports to appear
either as regular Root Ports or behind the VMD.

Since this issue is directly related to the unusual VMD topology, I
think it would be worth a quick recap here.  Maybe something like:

  VMD is a Root Complex Integrated Endpoint that acts as a host bridge
  to a secondary PCIe domain.  BIOS can reassign one or more Root
  Ports to appear within a VMD domain instead of the primary domain.

  However, BIOS may not enable ASPM for the hierarchies behind a VMD,
  ...

(This is based on the commit log from 185a383ada2e ("x86/PCI: Add
driver for Intel Volume Management Device (VMD)")).

But we still have the problem that CONFIG_PCIEASPM_DEFAULT=y means
"use the BIOS defaults", and this patch would make it so we use the
BIOS defaults *except* for things behind VMD.

  - Why should VMD be a special case?

  - How would we document such a special case?

  - If we built with CONFIG_PCIEASPM_POWERSAVE=y, would that solve the
SoC power state problem?

  - What issues would CONFIG_PCIEASPM_POWERSAVE=y introduce?

Link to previous discussion for the archives:
https://lore.kernel.org/r/49a36179-d336-4a5e-8b7a-a632833ae...@canonical.com

> So enable ASPM for links behind VMD to increase battery life.
> 
> Signed-off-by: Kai-Heng Feng 
> ---
>  drivers/pci/controller/vmd.c | 22 +-
>  1 file changed, 21 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/pci/controller/vmd.c b/drivers/pci/controller/vmd.c
> index f69ef8c89f72..058fdef9c566 100644
> --- a/drivers/pci/controller/vmd.c
> +++ b/drivers/pci/controller/vmd.c
> @@ -417,6 +417,22 @@ static int vmd_find_free_domain(void)
>   return domain + 1;
>  }
>  
> +static const struct pci_device_id vmd_mobile_bridge_tbl[] = {
> + { PCI_VDEVICE(INTEL, 0x9a09) },
> + { PCI_VDEVICE(INTEL, 0xa0b0) },
> + { PCI_VDEVICE(INTEL, 0xa0bc) },
> + { }
> +};
> +
> +static int vmd_enable_aspm(struct device *dev, void *data)
> +{
> + struct pci_dev *pdev = to_pci_dev(dev);
> +
> + pci_enable_link_state(pdev, PCIE_LINK_STATE_ALL);
> +
> + return 0;
> +}
> +
>  static int vmd_enable_domain(struct vmd_dev *vmd, unsigned long features)
>  {
>   struct pci_sysdata *sd = &vmd->sysdata;
> @@ -603,8 +619,12 @@ static int vmd_enable_domain(struct vmd_dev *vmd, 
> unsigned long features)
>* and will fail pcie_bus_configure_settings() early. It can instead be
>* run on each of the real root ports.
>*/
> - list_for_each_entry(child, &vmd->bus->children, node)
> + list_for_each_entry(child, &vmd->bus->children, node) {
> + if (pci_match_id(vmd_mobile_bridge_tbl, child->self))
> + device_for_each_child(&child->self->dev, NULL, 
> vmd_enable_aspm);

Wouldn't something like this be sufficient?

  list_for_each_entry(dev, &child->devices, bus_list)
vmd_enable_aspm(dev);

>   pcie_bus_configure_settings(child);
> + }
>  
>   pci_bus_add_devices(vmd->bus);
>  
> -- 
> 2.17.1
> 

Re: [PATCH] checkpatch: Emit a warning on embedded filenames

[Andrew Morton]

On Thu, 01 Oct 2020 11:28:10 -0700 Joe Perches  wrote:

> Embedding the complete filename path inside the file
> isn't particularly useful as often the path is moved
> around and becomes incorrect.
> 
> Emit a warning when the source contains the filename.
> 
> ...
>
> --- a/scripts/checkpatch.pl
> +++ b/scripts/checkpatch.pl
> @@ -3273,6 +3273,12 @@ sub process {
>   }
>   }
>  
> +# check for embedded filenames
> + if ($rawline =~ /^\+.*\Q$realfile\E/) { di
> + WARN("EMBEDDED_FILENAME",
> +  "It's generally not useful to have the filename in 
> the file\n" . $herecurr);
> + }
> +

I removed that " di".  Please check that I merged the correct version
of this!

Re: [PATCH 1/3] dt-bindings: nvmem: Add qcom,sc7180-qfprom compatible string

[Doug Anderson]

Hi,

On Tue, Sep 29, 2020 at 1:58 PM Evan Green  wrote:
>
> Add an SoC-specific compatible string so that data can be attached
> to it in the driver.
>
> Signed-off-by: Evan Green 
> ---
>
>  Documentation/devicetree/bindings/nvmem/qcom,qfprom.yaml | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/nvmem/qcom,qfprom.yaml 
> b/Documentation/devicetree/bindings/nvmem/qcom,qfprom.yaml
> index 59aca6d22ff9b..b16c8e6a8c23d 100644
> --- a/Documentation/devicetree/bindings/nvmem/qcom,qfprom.yaml
> +++ b/Documentation/devicetree/bindings/nvmem/qcom,qfprom.yaml
> @@ -14,7 +14,9 @@ allOf:
>
>  properties:
>compatible:
> -const: qcom,qfprom
> +enum:
> +  - qcom,qfprom
> +  - qcom,sc7180-qfprom

You don't want either/or.  You want both.  At the time Srinivas didn't
see the point of having the SoC-specific compatible string here, but
now that we have a reason for it maybe he'll be convinced?  IMO you
essentially want:

items:
  - enum:
  - qcom,apq8064-qfprom
  - qcom,apq8084-qfprom
  - qcom,msm8974-qfprom
  - qcom,msm8916-qfprom
  - qcom,msm8996-qfprom
  - qcom,msm8998-qfprom
  - qcom,qcs404-qfprom
  - qcom,sc7180-qfprom
  - qcom,sdm845-qfprom
  - const: qcom,qfprom

For some context:


-Doug


>
>reg:
>  # If the QFPROM is read-only OS image then only the corrected region
> --
> 2.26.2
>

[PATCH v8 1/3] media: i2c: ov772x: Parse endpoint properties

[Lad Prabhakar]

Parse endpoint properties using v4l2_fwnode_endpoint_alloc_parse()
to determine the bus type and store it in the driver structure.

Set bus_type to V4L2_MBUS_PARALLEL as it's the only supported one

Signed-off-by: Lad Prabhakar 
Reviewed-by: Jacopo Mondi 
---
 drivers/media/i2c/ov772x.c | 34 ++
 1 file changed, 34 insertions(+)

diff --git a/drivers/media/i2c/ov772x.c b/drivers/media/i2c/ov772x.c
index 2cc6a678069a..afe2446dfb68 100644
--- a/drivers/media/i2c/ov772x.c
+++ b/drivers/media/i2c/ov772x.c
@@ -31,6 +31,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -434,6 +435,7 @@ struct ov772x_priv {
 #ifdef CONFIG_MEDIA_CONTROLLER
struct media_pad pad;
 #endif
+   enum v4l2_mbus_type   bus_type;
 };
 
 /*
@@ -1348,6 +1350,34 @@ static const struct v4l2_subdev_ops ov772x_subdev_ops = {
.pad= &ov772x_subdev_pad_ops,
 };
 
+static int ov772x_parse_dt(struct i2c_client *client,
+  struct ov772x_priv *priv)
+{
+   struct v4l2_fwnode_endpoint bus_cfg = {
+   .bus_type = V4L2_MBUS_PARALLEL
+   };
+   struct fwnode_handle *ep;
+   int ret;
+
+   ep = fwnode_graph_get_next_endpoint(dev_fwnode(&client->dev), NULL);
+   if (!ep) {
+   dev_err(&client->dev, "Endpoint node not found\n");
+   return -EINVAL;
+   }
+
+   ret = v4l2_fwnode_endpoint_alloc_parse(ep, &bus_cfg);
+   if (ret)
+   goto error_fwnode_put;
+
+   priv->bus_type = bus_cfg.bus_type;
+   v4l2_fwnode_endpoint_free(&bus_cfg);
+
+error_fwnode_put:
+   fwnode_handle_put(ep);
+
+   return ret;
+}
+
 /*
  * i2c_driver function
  */
@@ -1415,6 +1445,10 @@ static int ov772x_probe(struct i2c_client *client)
goto error_clk_put;
}
 
+   ret = ov772x_parse_dt(client, priv);
+   if (ret)
+   goto error_clk_put;
+
ret = ov772x_video_probe(priv);
if (ret < 0)
goto error_gpio_put;
-- 
2.17.1

[PATCH v8 2/3] media: i2c: ov772x: Add support for BT.656 mode

[Lad Prabhakar]

Add support to read the bus-type for V4L2_MBUS_BT656 and enable BT.656
mode in the sensor if needed.

For backward compatibility with older DTS where the bus-type property was
not mandatory, assume V4L2_MBUS_PARALLEL as it was the only supported bus
at the time. v4l2_fwnode_endpoint_alloc_parse() will not fail if
'bus-type' is not specified.

Signed-off-by: Lad Prabhakar 
Reviewed-by: Biju Das 
Reviewed-by: Jacopo Mondi 
---
 drivers/media/i2c/ov772x.c | 24 ++--
 1 file changed, 22 insertions(+), 2 deletions(-)

diff --git a/drivers/media/i2c/ov772x.c b/drivers/media/i2c/ov772x.c
index afe2446dfb68..86e542b77ee5 100644
--- a/drivers/media/i2c/ov772x.c
+++ b/drivers/media/i2c/ov772x.c
@@ -583,6 +583,14 @@ static int ov772x_s_stream(struct v4l2_subdev *sd, int 
enable)
if (priv->streaming == enable)
goto done;
 
+   if (priv->bus_type == V4L2_MBUS_BT656) {
+   ret = regmap_update_bits(priv->regmap, COM7, ITU656_ON_OFF,
+enable ?
+ITU656_ON_OFF : ~ITU656_ON_OFF);
+   if (ret)
+   goto done;
+   }
+
ret = regmap_update_bits(priv->regmap, COM2, SOFT_SLEEP_MODE,
 enable ? 0 : SOFT_SLEEP_MODE);
if (ret)
@@ -1365,9 +1373,21 @@ static int ov772x_parse_dt(struct i2c_client *client,
return -EINVAL;
}
 
+   /*
+* For backward compatibility with older DTS where the
+* bus-type property was not mandatory, assume
+* V4L2_MBUS_PARALLEL as it was the only supported bus at the
+* time. v4l2_fwnode_endpoint_alloc_parse() will not fail if
+* 'bus-type' is not specified.
+*/
ret = v4l2_fwnode_endpoint_alloc_parse(ep, &bus_cfg);
-   if (ret)
-   goto error_fwnode_put;
+   if (ret) {
+   bus_cfg = (struct v4l2_fwnode_endpoint)
+ { .bus_type = V4L2_MBUS_BT656 };
+   ret = v4l2_fwnode_endpoint_alloc_parse(ep, &bus_cfg);
+   if (ret)
+   goto error_fwnode_put;
+   }
 
priv->bus_type = bus_cfg.bus_type;
v4l2_fwnode_endpoint_free(&bus_cfg);
-- 
2.17.1

[PATCH v8 0/3] media: i2c: ov772x: Enable BT.656 mode and test pattern support

[Lad Prabhakar]

Hi All,

This patch series adds support for BT.656 mode in the ov772x sensor
and also enables color bar test pattern control.

Cheers,
Prabhakar

V7->v8
* Fixed review comments pointed by Sakari

v6->v7
* Fixed review comments pointed by Sakari
* Included Ack from Jacopo

v5->v6
* Introduced new function ov772x_parse_dt()
* Moved the backward compatibility comment from 1/3 to 2/3

v4->v5:
* Put the ep instance back using fwnode_handle_put()
* Renamed BT656 to BT.656
* Correctly handled backward compatibility case falling
  back to parallel mode.

v3->v4:
* New patch 1/3 to fallback in parallel mode.
* Switched to v4l2_fwnode_endpoint_alloc_parse() for parsing the ep.
* Dropped support for pdat for test pattern control.
* DT documentation patches [1].

v2->v3:
* Dropped DT binding documentation patch as this is handled by Jacopo.
* Fixed review comments pointed by Jacopo.

v2:
 https://patchwork.kernel.org/project/linux-renesas-soc/
 list/?series=328133

 v1:
https://patchwork.kernel.org/project/linux-renesas-soc/
list/?series=323807

[1] https://patchwork.kernel.org/project/
linux-renesas-soc/list/?series=346809

Lad Prabhakar (3):
  media: i2c: ov772x: Parse endpoint properties
  media: i2c: ov772x: Add support for BT.656 mode
  media: i2c: ov772x: Add test pattern control

 drivers/media/i2c/ov772x.c | 71 +-
 1 file changed, 70 insertions(+), 1 deletion(-)

-- 
2.17.1

[PATCH v8 3/3] media: i2c: ov772x: Add test pattern control

[Lad Prabhakar]

Add support for test pattern control supported by the sensor.

Signed-off-by: Lad Prabhakar 
Reviewed-by: Biju Das 
Reviewed-by: Jacopo Mondi 
---
 drivers/media/i2c/ov772x.c | 17 -
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/drivers/media/i2c/ov772x.c b/drivers/media/i2c/ov772x.c
index 86e542b77ee5..d94cf2d39c2a 100644
--- a/drivers/media/i2c/ov772x.c
+++ b/drivers/media/i2c/ov772x.c
@@ -227,7 +227,7 @@
 
 /* COM3 */
 #define SWAP_MASK   (SWAP_RGB | SWAP_YUV | SWAP_ML)
-#define IMG_MASK(VFLIP_IMG | HFLIP_IMG)
+#define IMG_MASK(VFLIP_IMG | HFLIP_IMG | SCOLOR_TEST)
 
 #define VFLIP_IMG   0x80   /* Vertical flip image ON/OFF selection */
 #define HFLIP_IMG   0x40   /* Horizontal mirror image ON/OFF selection */
@@ -425,6 +425,7 @@ struct ov772x_priv {
const struct ov772x_win_size *win;
struct v4l2_ctrl *vflip_ctrl;
struct v4l2_ctrl *hflip_ctrl;
+   unsigned int  test_pattern;
/* band_filter = COM8[5] ? 256 - BDBASE : 0 */
struct v4l2_ctrl *band_filter_ctrl;
unsigned int  fps;
@@ -540,6 +541,11 @@ static const struct ov772x_win_size ov772x_win_sizes[] = {
},
 };
 
+static const char * const ov772x_test_pattern_menu[] = {
+   "Disabled",
+   "Vertical Color Bar Type 1",
+};
+
 /*
  * frame rate settings lists
  */
@@ -810,6 +816,9 @@ static int ov772x_s_ctrl(struct v4l2_ctrl *ctrl)
}
 
return ret;
+   case V4L2_CID_TEST_PATTERN:
+   priv->test_pattern = ctrl->val;
+   return 0;
}
 
return -EINVAL;
@@ -1108,6 +1117,8 @@ static int ov772x_set_params(struct ov772x_priv *priv,
val ^= VFLIP_IMG;
if (priv->hflip_ctrl->val)
val ^= HFLIP_IMG;
+   if (priv->test_pattern)
+   val |= SCOLOR_TEST;
 
ret = regmap_update_bits(priv->regmap, COM3, SWAP_MASK | IMG_MASK, val);
if (ret < 0)
@@ -1444,6 +1455,10 @@ static int ov772x_probe(struct i2c_client *client)
priv->band_filter_ctrl = v4l2_ctrl_new_std(&priv->hdl, &ov772x_ctrl_ops,
   V4L2_CID_BAND_STOP_FILTER,
   0, 256, 1, 0);
+   v4l2_ctrl_new_std_menu_items(&priv->hdl, &ov772x_ctrl_ops,
+V4L2_CID_TEST_PATTERN,
+ARRAY_SIZE(ov772x_test_pattern_menu) - 1,
+0, 0, ov772x_test_pattern_menu);
priv->subdev.ctrl_handler = &priv->hdl;
if (priv->hdl.error) {
ret = priv->hdl.error;
-- 
2.17.1

Re: Why ping latency is smaller with shorter send interval?

[David Miller]

Can you please not send the same posting to the mailing list
three times, from three different email addresses?

Once is enough, thank you.

Re: [PATCH 2/3] arm64: dts: qcom: sc7180: Add soc-specific qfprom compat string

[Doug Anderson]

Hi,

On Tue, Sep 29, 2020 at 1:58 PM Evan Green  wrote:
>
> Add the soc-specific compatible string so that it can be matched
> more specifically now that the driver cares which SoC it's on.
>
> Signed-off-by: Evan Green 
> ---
>
>  arch/arm64/boot/dts/qcom/sc7180.dtsi | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Reviewed-by: Douglas Anderson 

Re: [PATCH v4 01/11] mm: add Kernel Electric-Fence infrastructure

[Jann Horn]

On Fri, Oct 2, 2020 at 11:28 PM Marco Elver  wrote:
> On Fri, 2 Oct 2020 at 21:32, Jann Horn  wrote:
> > > That's another check; we don't want to make this more expensive.
> >
> > Ah, right, I missed that this is the one piece of KFENCE that is
> > actually really hot code until Dmitry pointed that out.
> >
> > But actually, can't you reduce how hot this is for SLUB by moving
> > is_kfence_address() down into the freeing slowpath? At the moment you
> > use it in slab_free_freelist_hook(), which is in the super-hot
> > fastpath, but you should be able to at least move it down into
> > __slab_free()...
> >
> > Actually, you already have hooked into __slab_free(), so can't you
> > just get rid of the check in the slab_free_freelist_hook()?
>
> I missed this bit: the loop that follows wants the free pointer, so I
> currently see how this might work. :-/

reverse call graph:
__slab_free
  do_slab_free
slab_free
  kmem_cache_free (frees a single non-kmalloc allocation)
  kmem_cache_free_bulk (frees multiple)
  kfree (frees a single kmalloc allocation)
___cache_free (frees a single allocation for KASAN)

So the only path for which we can actually loop in __slab_free() is
kmem_cache_free_bulk(); and you've already changed
build_detached_freelist() (which is used by kmem_cache_free_bulk() to
group objects from the same page) to consume KFENCE allocations before
they can ever reach __slab_free(). So we know that if we've reached
__slab_free(), then we are being called with either a single object
(which may be a KFENCE object) or with a list of objects that all
belong to the same page and don't contain any KFENCE allocations.

Re: [PATCH V3 1/8] sysfs: Add sysfs_emit and sysfs_emit_at to format sysfs output

[Kees Cook]

On Thu, Oct 01, 2020 at 10:50:29PM +0200, Greg Kroah-Hartman wrote:
> On Wed, Sep 30, 2020 at 09:17:03PM -0700, Kees Cook wrote:
> > On Wed, Sep 30, 2020 at 01:57:40PM +0200, Greg Kroah-Hartman wrote:
> > > Kees, and Rafael, I don't know if you saw this proposal from Joe for
> > > sysfs files, questions below:
> > 
> > I'm a fan. I think the use of sprintf() in sysfs might have been one of
> > my earliest complaints about unsafe code patterns in the kernel. ;)
> 
> Ok, great.
> 
> > > > +/**
> > > > + * sysfs_emit - scnprintf equivalent, aware of PAGE_SIZE buffer.
> > > > + * @buf:   start of PAGE_SIZE buffer.
> > > > + * @fmt:   format
> > > > + * @...:   optional arguments to @format
> > > > + *
> > > > + *
> > > > + * Returns number of characters written to @buf.
> > > > + */
> > > > +int sysfs_emit(char *buf, const char *fmt, ...)
> > > > +{
> > > > +   va_list args;
> > > > +   int len;
> > > > +
> > > > +   if (WARN(!buf || offset_in_page(buf),
> > > > +"invalid sysfs_emit: buf:%p\n", buf))
> > 
> > I don't want the %p here, but otherwise, sure. I'd also make it a _ONCE
> > variant:
> > 
> > if (WARN_ONCE(!buf || offset_in_page(buf),
> >  "invalid sysfs_emit: offset_in_page(buf):%zd\n",
> >   buf ? offset_in_page(buf) : 0))
> 
> As Joe points out, _ONCE doesn't work because this happens from all
> sysfs files, not just one.

Sure, it's just a question if you want log spamming vs how reachable you
think something might be. I would expect this to be uncommon to
encounter, but very repeatable for whatever system DOES hit it, so doing
_ONCE means they see the report and don't get completely flooded with
it.

I'm fine either way.

-- 
Kees Cook

Re: [PATCH v4 1/2] dt-bindings: usb: Add binding for discrete onboard USB hubs

[Rob Herring]

On Fri, Oct 2, 2020 at 12:08 PM Doug Anderson  wrote:
>
> Hi,
>
> On Wed, Sep 30, 2020 at 1:20 PM Rob Herring  wrote:
> >
> > > > > Datasheets from different manufacturers refer to these ICs as "USB hub
> > > > > controller". Calling the node "usb-hub-controller" would indeed help 
> > > > > to
> > > > > distinguish it from the USB hub devices and represent existing 
> > > > > hardware.
> > > > > And the USB device could have a "hub-controller" property, which also
> > > > > would be clearer than the current "hub" property.
> > > >
> > > > There aren't 2 (or 3) devices here. There's a single USB device (a
> > > > hub) and the DT representation should reflect that.
> > >
> > > That's not completely true, though, is it?
> >
> > I was referring to the hub. I only see 1 datasheet, 1 IC and 1 block
> > diagram... Lots of devices have more than one interface though usually
> > not different speeds of the same thing.
>
> Right, there is certainly more than one way to look at it and the way
> to look at it is based on how it's most convenient, I guess.  I mean,
> an SoC often has 1 (very long) datasheet, 1 IC, and 1 block diagram
> too...
>
> As a more similar example of single device that is listed in more than
> one location in the device tree, we can also look at embedded SDIO
> BT/WiFi combo cards.  This single device often provides WiFi under an
> SDIO bus and BT under a serial / USB bus.  I'm not 100% sure there are
> actually cases were the same board provides device tree data to both
> at the same time, but "brcm,bcm43540-bt" is an example of providing
> data to the Bluetooth (connected over serial port) and
> "brcm,bcm4329-fmac" to the WiFi (connected over the SDIO bus).  Of
> course WiFi/BT cheat in that the control logic is represented by the
> SDIO power sequencing stuff...

I figured you would mention this and it was brought up in the prior
version. We've gotten lucky on these that the BT and WiFi are almost
completely independent and any shared resources are easily shared
(refcounted). I don't know if this case is the same. It seems less so
to me. In any case, 2 independent devices is not what's been done here
so far. The question is does representing USB2 and USB3 buses
independently make sense, not whether just representing this hub as 2
devices makes sense.

> Back to our case, though.  I guess the issue here is that we're the
> child of more than one bus.  Let's first pretend that the i2c lines of
> this hub are actually hooked up and establish how that would look
> first.  Then we can think about how it looks if this same device isn't
> hooked up via i2c.  In this case, it sounds as if you still don't want
> the device split among two nodes.  So I guess you'd prefer something
> like:
>
> i2c {
>   usb-hub@xx {
> reg = ;
> compatible = "realtek,rts5411", "onboard-usb-hub";
> vdd-supply = <&pp3300_hub>;
> usb-devices = <&usb_controller 1>;

Why would you even need this prop? What it's attached to may not be
the host controller nor even represented in DT. You've just defined a
2nd way to represent USB devices in DT (there's always 2 ways: a tree
of nodes or a 'linked list' of phandles).

>   };
> };
>
> ...and then you wouldn't have anything under the USB controller
> itself.  Is that correct?

Right, as the examples you pointed out do. They just avoid the issue
of representing USB bus in DT which probably was not defined at the
time at least the first one was done. It works as long as you only
have the hub that needs special setup. If you have child devices
hanging off the hub too, then you need to represent the USB bus
structure.

>  So even though there are existing bindings
> saying that a USB device should be listed via VID/PID, the desire to
> represent this as a single node overrides that, right?  (NOTE: this is
> similar to what Matthias proposed in his response except that I've
> added an index so that we don't need _anything_ under the controller).
>
> Having this primarily listed under the i2c bus makes sense because the
> control logic for the hub is hooked up via i2c.  Having the power
> supply associated with it also makes some amount of sense since it's a
> control signal.  It's also convenient that i2c devices have their
> probe called _before_ we try to detect if they're there because it's
> common that i2c devices need power applied first.
>
> Now, just because we don't have the i2c bus hooked up doesn't change
> the fact that there is control logic.  We also certainly wouldn't want
> two ways of describing this same hub: one way if the i2c is hooked up
> and one way if it's not hooked up.  To me this means that the we
> should be describing this hub as a top-level node if i2c isn't hooked
> up, just like we do with "smsc,usb3503a"
>
> Said another way, we have these points:
>
> a) The control logic for this bus could be hooked up to an i2c bus.
>
> b) If the control logic is hooked up to an i2c bus it feels like
> that's where the device's primary node should be p

Re: [PATCH v10 0/7] Introduce sendpage_ok() to detect misused sendpage in network related drivers

[David Miller]

From: Coly Li 
Date: Fri,  2 Oct 2020 16:27:27 +0800

> As Sagi Grimberg suggested, the original fix is refind to a more common
> inline routine:
> static inline bool sendpage_ok(struct page *page)
> {
> return  (!PageSlab(page) && page_count(page) >= 1);
> }
> If sendpage_ok() returns true, the checking page can be handled by the
> concrete zero-copy sendpage method in network layer.

Series applied.

> The v10 series has 7 patches, fixes a WARN_ONCE() usage from v9 series,
 ...

I still haven't heard from you how such a fundamental build failure
was even possible.

If the v9 patch series did not even compile, how in the world did you
perform functional testing of these changes?

Please explain this to me, instead of just quietly fixing it and
posting an updated series.

Thank you.

Re: [PATCH v9 0/7] Introduce sendpage_ok() to detect misused sendpage in network related drivers

[David Miller]

From: Coly Li 
Date: Fri, 2 Oct 2020 16:30:12 +0800

> Obviously my fault and no excuse for leaking this uncompleted version to
> you. I just re-post a v10 version which I make sure all patches are the
> latest version.
> 
> Sorry for the inconvenience and thank you in advance for taking this set.

How did this happen?

How did you functionally test the patch set if it didn't even compile?

I want you to explain why you sent a completely untested patch set.

Re: [PATCH V3 1/8] sysfs: Add sysfs_emit and sysfs_emit_at to format sysfs output

[Kees Cook]

On Wed, Sep 30, 2020 at 09:22:19PM -0700, Joe Perches wrote:
> On Wed, 2020-09-30 at 21:17 -0700, Kees Cook wrote:
> > On Wed, Sep 30, 2020 at 01:57:40PM +0200, Greg Kroah-Hartman wrote:
> > > Kees, and Rafael, I don't know if you saw this proposal from Joe for
> > > sysfs files, questions below:
> > 
> > I'm a fan. I think the use of sprintf() in sysfs might have been one of
> > my earliest complaints about unsafe code patterns in the kernel. ;)
> []
> > > > +   if (WARN(!buf || offset_in_page(buf),
> > > > +"invalid sysfs_emit: buf:%p\n", buf))
> 
> The dump_stack() is also going to emit pointers
> so I don't see how it does anything but help
> show where the buffer was.  It is hashed...

dump_stack() is going to report symbols and register contents.

I was just pointing out that %p has no value here[1]. The interesting
states are: "was it NULL?" "how offset was it?". Its actual content
won't matter.

-Kees

[1] "New uses of %p should not be added to the kernel"

https://www.kernel.org/doc/html/latest/process/deprecated.html#p-format-specifier

-- 
Kees Cook

drivers/block/rbd.c: atomic_inc_return_safe() & atomic_dec_return_safe()

[Shuah Khan]

All,

I came across these atomic_inc_return_safe() & atomic_dec_return_safe()
functions that hold the counters at safe values.

atomic_inc_return_safe()

If the counter is already 0 it will not be incremented.
If the counter is already at its maximum value returns
-EINVAL without updating it.

atomic_dec_return_safe()

Decrement the counter.  Return the resulting value, or -EINVAL

These two routines are static and only used in rbd.c.

Can these become part of atomic_t ops?

thanks,
-- Shuah

Re: [PATCH bpf-next v4 0/6] bpf: BTF support for ksyms

[Hao Luo]

Thanks, Alexei and Andrii and other reviewers for the comments. It's a
pleasure to work with you and contribute to bpf.

Hao

On Fri, Oct 2, 2020 at 3:16 PM Alexei Starovoitov
 wrote:
>
> On Tue, Sep 29, 2020 at 11:48 PM Hao Luo  wrote:
> >
> > Ah, this is the bug in pahole described in
> > https://lkml.org/lkml/2020/8/20/1862. I proposed a fix [1] but it
> > hasn't reached pahole's master branch. Let me ask Arnaldo to see if he
> > is OK merging it.
> >
> > [1] https://www.spinics.net/lists/dwarves/msg00451.html
> >
> > On Tue, Sep 29, 2020 at 9:36 PM Alexei Starovoitov
> >  wrote:
> > >
> > > On Tue, Sep 29, 2020 at 4:50 PM Hao Luo  wrote:
> > > >
> > > > v3 -> v4:
> > > >  - Rebasing
> > > >  - Cast bpf_[per|this]_cpu_ptr's parameter to void __percpu * before
> > > >passing into per_cpu_ptr.
>
> I've rebased it myself and applied. Thanks Hao.

[PATCH v2 0/7] Intel FPGA Security Manager Class Driver

[Russ Weight]

The Intel FPGA Security Manager class driver provides a common
API for user-space tools to manage updates for secure Intel FPGA
devices. Device drivers that instantiate the Intel Security
Manager class driver will interact with a HW secure update
engine in order to transfer new FPGA and BMC images to FLASH so
that they will be automatically loaded when the FPGA card reboots.

A significant difference between the FPGA Manager and the Intel FPGA 
Security Manager is that the FPGA Manager does a live update (Partial
Reconfiguration) to a device whereas the Intel FPGA Security Manager
updates the FLASH images for the Static Region and the BMC so that
they will be loaded the next time the FPGA card boots. Security is
enforced by hardware and firmware. The security manager interacts
with the firmware to initiate an update, pass in the necessary data,
and collect status on the update.

The n3000bmc-secure driver is the first driver to use the Intel FPG
Security Manager. This driver was previously submittied in the same
patch set, but has been split out in to a separate patch set for V2.
Follow-on Intel devices will also make use of this common API for
secure updates.

In addition to managing secure updates of the FPGA and BMC images,
the Intel FPGA Security Manager update process may also used to
program root entry hashes and cancellation keys for the FPGA static
region, the FPGA partial reconfiguration region, and the BMC.

Secure updates make use of the request_firmware framework, which
requires that image files are accessible under /lib/firmware. A request
for a secure update returns immediately, while the update itself
proceeds in the context of a kernel worker thread. Sysfs files provide
a means for monitoring the progress of a secure update and for
retrieving error information in the event of a failure.

The API consists of sysfs nodes and supports the following functions:

(1) Instantiate and monitor a secure update
(2) Display security information including: Root Entry Hashes (REH),
Cancelled Code Signing Keys (CSK), and flash update counts for
both BMC and FPGA images.

Changelog v1 -> v2:
  - Separated out the MAX10 BMC Security Engine to be submitted in
a separate patch-set.
  - Bumped documentation dates and versions
  - Split ifpga_sec_mgr_register() into create() and register() functions
  - Added devm_ifpga_sec_mgr_create()
  - Added Documentation/fpga/ifpga-sec-mgr.rst 
  - Changed progress state "read_file" to "reading"
  - Added sec_error() function (similar to sec_progress())
  - Removed references to bmc_flash_count & smbus_flash_count (not supported)
  - Removed typedefs for imgr ops
  - Removed explicit value assignments in enums
  - Other minor code cleanup per review comments 

Russ Weight (7):
  fpga: sec-mgr: intel fpga security manager class driver
  fpga: sec-mgr: enable secure updates
  fpga: sec-mgr: expose sec-mgr update status
  fpga: sec-mgr: expose sec-mgr update errors
  fpga: sec-mgr: expose sec-mgr update size
  fpga: sec-mgr: enable cancel of secure update
  fpga: sec-mgr: expose hardware error info

 .../ABI/testing/sysfs-class-ifpga-sec-mgr | 143 
 Documentation/fpga/ifpga-sec-mgr.rst  |  50 ++
 Documentation/fpga/index.rst  |   1 +
 MAINTAINERS   |   9 +
 drivers/fpga/Kconfig  |   9 +
 drivers/fpga/Makefile |   3 +
 drivers/fpga/ifpga-sec-mgr.c  | 781 ++
 include/linux/fpga/ifpga-sec-mgr.h| 137 +++
 8 files changed, 1133 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-class-ifpga-sec-mgr
 create mode 100644 Documentation/fpga/ifpga-sec-mgr.rst
 create mode 100644 drivers/fpga/ifpga-sec-mgr.c
 create mode 100644 include/linux/fpga/ifpga-sec-mgr.h

-- 
2.17.1

[PATCH v2 5/7] fpga: sec-mgr: expose sec-mgr update size

[Russ Weight]

Extend the Intel Security Manager class driver to include
an update/remaining_size sysfs node that can be read to
determine how much data remains to be transferred to the
secure update engine. This file can be used to monitor
progress during the "writing" phase of an update.

Signed-off-by: Russ Weight 
Reviewed-by: Tom Rix 
---
v2:
  - Bumped documentation date and version
---
 Documentation/ABI/testing/sysfs-class-ifpga-sec-mgr | 11 +++
 drivers/fpga/ifpga-sec-mgr.c| 10 ++
 2 files changed, 21 insertions(+)

diff --git a/Documentation/ABI/testing/sysfs-class-ifpga-sec-mgr 
b/Documentation/ABI/testing/sysfs-class-ifpga-sec-mgr
index 1f9f2c215e0c..ec51135fcb6a 100644
--- a/Documentation/ABI/testing/sysfs-class-ifpga-sec-mgr
+++ b/Documentation/ABI/testing/sysfs-class-ifpga-sec-mgr
@@ -90,6 +90,17 @@ Description: Read-only. Returns a string describing the 
current
as it will be signaled by sysfs_notify() on each
state change.
 
+What:  /sys/class/ifpga_sec_mgr/ifpga_secX/update/remaining_size
+Date:  Oct 2020
+KernelVersion:  5.11
+Contact:   Russ Weight 
+Description:   Read-only. Returns the size of data that remains to
+   be written to the secure update engine. The size
+   value is initialized to the full size of the file
+   image and the value is updated periodically during
+   the "writing" phase of the update.
+   Format: "%u".
+
 What:  /sys/class/ifpga_sec_mgr/ifpga_secX/update/error
 Date:  Oct 2020
 KernelVersion:  5.11
diff --git a/drivers/fpga/ifpga-sec-mgr.c b/drivers/fpga/ifpga-sec-mgr.c
index 456ea0b71e3d..d8ac863c1159 100644
--- a/drivers/fpga/ifpga-sec-mgr.c
+++ b/drivers/fpga/ifpga-sec-mgr.c
@@ -350,6 +350,15 @@ error_show(struct device *dev, struct device_attribute 
*attr, char *buf)
 }
 static DEVICE_ATTR_RO(error);
 
+static ssize_t remaining_size_show(struct device *dev,
+  struct device_attribute *attr, char *buf)
+{
+   struct ifpga_sec_mgr *imgr = to_sec_mgr(dev);
+
+   return sprintf(buf, "%u\n", imgr->remaining_size);
+}
+static DEVICE_ATTR_RO(remaining_size);
+
 static ssize_t filename_store(struct device *dev, struct device_attribute 
*attr,
  const char *buf, size_t count)
 {
@@ -386,6 +395,7 @@ static struct attribute *sec_mgr_update_attrs[] = {
&dev_attr_filename.attr,
&dev_attr_status.attr,
&dev_attr_error.attr,
+   &dev_attr_remaining_size.attr,
NULL,
 };
 
-- 
2.17.1

[PATCH v2 7/7] fpga: sec-mgr: expose hardware error info

[Russ Weight]

Extend the Intel Security Manager class driver to include
an optional update/hw_errinfo sysfs node that can be used
to retrieve 64 bits of device specific error information
following a secure update failure.

The underlying driver must provide a get_hw_errinfo() callback
function to enable this feature. This data is treated as
opaque by the class driver. It is left to user-space software
or support personnel to interpret this data.

Signed-off-by: Russ Weight 
Reviewed-by: Tom Rix 
---
v2:
  - Bumped documentation date and version
---
 .../ABI/testing/sysfs-class-ifpga-sec-mgr | 14 +++
 drivers/fpga/ifpga-sec-mgr.c  | 38 +++
 include/linux/fpga/ifpga-sec-mgr.h|  5 +++
 3 files changed, 57 insertions(+)

diff --git a/Documentation/ABI/testing/sysfs-class-ifpga-sec-mgr 
b/Documentation/ABI/testing/sysfs-class-ifpga-sec-mgr
index caafe7eb7670..37a335ff4936 100644
--- a/Documentation/ABI/testing/sysfs-class-ifpga-sec-mgr
+++ b/Documentation/ABI/testing/sysfs-class-ifpga-sec-mgr
@@ -127,3 +127,17 @@ Description:   Read-only. Returns a string describing 
the failure
idle state. If this file is read while a secure
update is in progress, then the read will fail with
EBUSY.
+
+What:  /sys/class/ifpga_sec_mgr/ifpga_secX/update/hw_errinfo
+Date:  Oct 2020
+KernelVersion:  5.11
+Contact:   Russ Weight 
+Description:   Read-only. Returns a 64 bit error value providing
+   hardware specific information that may be useful in
+   debugging errors that occur during FPGA image updates.
+   This file is only visible if the underlying device
+   supports it. The hw_errinfo value is only accessible
+   when the secure update engine is in the idle state.
+   If this file is read while a secure update is in
+   progress, then the read will fail with EBUSY.
+   Format: "0x%llx".
diff --git a/drivers/fpga/ifpga-sec-mgr.c b/drivers/fpga/ifpga-sec-mgr.c
index 6267ac3a0780..eb306dff7d31 100644
--- a/drivers/fpga/ifpga-sec-mgr.c
+++ b/drivers/fpga/ifpga-sec-mgr.c
@@ -152,10 +152,17 @@ static void set_error(struct ifpga_sec_mgr *imgr, enum 
ifpga_sec_err err_code)
imgr->err_code = err_code;
 }
 
+static void set_hw_errinfo(struct ifpga_sec_mgr *imgr)
+{
+   if (imgr->iops->get_hw_errinfo)
+   imgr->hw_errinfo = imgr->iops->get_hw_errinfo(imgr);
+}
+
 static void ifpga_sec_dev_error(struct ifpga_sec_mgr *imgr,
enum ifpga_sec_err err_code)
 {
set_error(imgr, err_code);
+   set_hw_errinfo(imgr);
imgr->iops->cancel(imgr);
 }
 
@@ -373,6 +380,23 @@ error_show(struct device *dev, struct device_attribute 
*attr, char *buf)
 }
 static DEVICE_ATTR_RO(error);
 
+static ssize_t
+hw_errinfo_show(struct device *dev, struct device_attribute *attr, char *buf)
+{
+   struct ifpga_sec_mgr *imgr = to_sec_mgr(dev);
+   int ret;
+
+   mutex_lock(&imgr->lock);
+   if (imgr->progress != IFPGA_SEC_PROG_IDLE)
+   ret = -EBUSY;
+   else
+   ret = sprintf(buf, "0x%llx\n", imgr->hw_errinfo);
+   mutex_unlock(&imgr->lock);
+
+   return ret;
+}
+static DEVICE_ATTR_RO(hw_errinfo);
+
 static ssize_t remaining_size_show(struct device *dev,
   struct device_attribute *attr, char *buf)
 {
@@ -404,6 +428,7 @@ static ssize_t filename_store(struct device *dev, struct 
device_attribute *attr,
}
 
imgr->err_code = IFPGA_SEC_ERR_NONE;
+   imgr->hw_errinfo = 0;
imgr->request_cancel = false;
imgr->progress = IFPGA_SEC_PROG_READING;
reinit_completion(&imgr->update_done);
@@ -438,18 +463,31 @@ static ssize_t cancel_store(struct device *dev, struct 
device_attribute *attr,
 }
 static DEVICE_ATTR_WO(cancel);
 
+static umode_t
+sec_mgr_update_visible(struct kobject *kobj, struct attribute *attr, int n)
+{
+   struct ifpga_sec_mgr *imgr = to_sec_mgr(kobj_to_dev(kobj));
+
+   if (attr == &dev_attr_hw_errinfo.attr && !imgr->iops->get_hw_errinfo)
+   return 0;
+
+   return attr->mode;
+}
+
 static struct attribute *sec_mgr_update_attrs[] = {
&dev_attr_filename.attr,
&dev_attr_cancel.attr,
&dev_attr_status.attr,
&dev_attr_error.attr,
&dev_attr_remaining_size.attr,
+   &dev_attr_hw_errinfo.attr,
NULL,
 };
 
 static struct attribute_group sec_mgr_update_attr_group = {
.name = "update",
.attrs = sec_mgr_update_attrs,
+   .is_visible = sec_mgr_update_visible,
 };
 
 static ssize_t name_show(struct device *dev,
diff --git a/include/linux/fpga/ifpga-sec-mgr.h 
b/include/linux/fpga/ifpga-sec-mgr.h
index 890be0800b05..baf4fe876164 100644
--- a/include/linux/fpga/ifpga-sec-mgr.h
+++ b/include/linux/fpga/ifpga-sec-mgr.h
@@ -60,6 +60,9 @@ enum ifpga_sec_err {
  * 

[PATCH v2 3/7] fpga: sec-mgr: expose sec-mgr update status

[Russ Weight]

Extend the Intel Security Manager class driver to
include an update/status sysfs node that can be polled
and read to monitor the progress of an ongoing secure
update. Sysfs_notify() is used to signal transitions
between different phases of the update process.

Signed-off-by: Russ Weight 
---
v2:
  - Bumped documentation date and version
  - Changed progress state "read_file" to "reading"
---
 .../ABI/testing/sysfs-class-ifpga-sec-mgr | 11 +
 drivers/fpga/ifpga-sec-mgr.c  | 40 +--
 2 files changed, 47 insertions(+), 4 deletions(-)

diff --git a/Documentation/ABI/testing/sysfs-class-ifpga-sec-mgr 
b/Documentation/ABI/testing/sysfs-class-ifpga-sec-mgr
index 4f375f132c34..73a5246fea1b 100644
--- a/Documentation/ABI/testing/sysfs-class-ifpga-sec-mgr
+++ b/Documentation/ABI/testing/sysfs-class-ifpga-sec-mgr
@@ -78,3 +78,14 @@ Description: Write only. Write the filename of an Intel image
BMC images, BMC firmware, Static Region images,
and Root Entry Hashes, and to cancel Code Signing
Keys (CSK).
+
+What:  /sys/class/ifpga_sec_mgr/ifpga_secX/update/status
+Date:  Oct 2020
+KernelVersion:  5.11
+Contact:   Russ Weight 
+Description:   Read-only. Returns a string describing the current
+   status of an update. The string will be one of the
+   following: idle, reading, preparing, writing,
+   programming. Userspace code can poll on this file,
+   as it will be signaled by sysfs_notify() on each
+   state change.
diff --git a/drivers/fpga/ifpga-sec-mgr.c b/drivers/fpga/ifpga-sec-mgr.c
index 7d5a4979554b..ad918fb42dc2 100644
--- a/drivers/fpga/ifpga-sec-mgr.c
+++ b/drivers/fpga/ifpga-sec-mgr.c
@@ -139,6 +139,13 @@ static struct attribute *sec_mgr_security_attrs[] = {
NULL,
 };
 
+static void update_progress(struct ifpga_sec_mgr *imgr,
+   enum ifpga_sec_prog new_progress)
+{
+   imgr->progress = new_progress;
+   sysfs_notify(&imgr->dev.kobj, "update", "status");
+}
+
 static void ifpga_sec_dev_error(struct ifpga_sec_mgr *imgr,
enum ifpga_sec_err err_code)
 {
@@ -149,7 +156,7 @@ static void ifpga_sec_dev_error(struct ifpga_sec_mgr *imgr,
 static void progress_complete(struct ifpga_sec_mgr *imgr)
 {
mutex_lock(&imgr->lock);
-   imgr->progress = IFPGA_SEC_PROG_IDLE;
+   update_progress(imgr, IFPGA_SEC_PROG_IDLE);
complete_all(&imgr->update_done);
mutex_unlock(&imgr->lock);
 }
@@ -177,14 +184,14 @@ static void ifpga_sec_mgr_update(struct work_struct *work)
goto release_fw_exit;
}
 
-   imgr->progress = IFPGA_SEC_PROG_PREPARING;
+   update_progress(imgr, IFPGA_SEC_PROG_PREPARING);
ret = imgr->iops->prepare(imgr);
if (ret) {
ifpga_sec_dev_error(imgr, ret);
goto modput_exit;
}
 
-   imgr->progress = IFPGA_SEC_PROG_WRITING;
+   update_progress(imgr, IFPGA_SEC_PROG_WRITING);
size = imgr->remaining_size;
while (size) {
blk_size = min_t(u32, size, WRITE_BLOCK_SIZE);
@@ -199,7 +206,7 @@ static void ifpga_sec_mgr_update(struct work_struct *work)
offset += blk_size;
}
 
-   imgr->progress = IFPGA_SEC_PROG_PROGRAMMING;
+   update_progress(imgr, IFPGA_SEC_PROG_PROGRAMMING);
ret = imgr->iops->poll_complete(imgr);
if (ret) {
ifpga_sec_dev_error(imgr, ret);
@@ -259,6 +266,30 @@ static struct attribute_group sec_mgr_security_attr_group 
= {
.is_visible = sec_mgr_visible,
 };
 
+static const char * const sec_mgr_prog_str[] = {
+   "idle", /* IFPGA_SEC_PROG_IDLE */
+   "reading",  /* IFPGA_SEC_PROG_READING */
+   "preparing",/* IFPGA_SEC_PROG_PREPARING */
+   "writing",  /* IFPGA_SEC_PROG_WRITING */
+   "programming"   /* IFPGA_SEC_PROG_PROGRAMMING */
+};
+
+static ssize_t
+status_show(struct device *dev, struct device_attribute *attr, char *buf)
+{
+   struct ifpga_sec_mgr *imgr = to_sec_mgr(dev);
+   const char *status = "unknown-status";
+
+   if (imgr->progress < IFPGA_SEC_PROG_MAX)
+   status = sec_mgr_prog_str[imgr->progress];
+   else
+   dev_warn(dev, "Invalid status during secure update: %d\n",
+imgr->progress);
+
+   return sprintf(buf, "%s\n", status);
+}
+static DEVICE_ATTR_RO(status);
+
 static ssize_t filename_store(struct device *dev, struct device_attribute 
*attr,
  const char *buf, size_t count)
 {
@@ -293,6 +324,7 @@ static DEVICE_ATTR_WO(filename);
 
 static struct attribute *sec_mgr_update_attrs[] = {
&dev_attr_filename.attr,
+   &dev_attr_status.attr,
NULL,
 };
 
-- 
2.17.1

[PATCH v2 1/7] fpga: sec-mgr: intel fpga security manager class driver

[Russ Weight]

Create the Intel Security Manager class driver. The security
manager provides interfaces to manage secure updates for the
FPGA and BMC images that are stored in FLASH. The driver can
also be used to update root entry hashes and to cancel code
signing keys.

This patch creates the class driver and provides sysfs
interfaces for displaying root entry hashes, canceled code
signing keys and flash counts.

Signed-off-by: Russ Weight 
Signed-off-by: Xu Yilun 
---
v2:
  - Bumped documentation dates and versions
  - Added Documentation/fpga/ifpga-sec-mgr.rst 
  - Removed references to bmc_flash_count & smbus_flash_count (not supported)
  - Split ifpga_sec_mgr_register() into create() and register() functions
  - Added devm_ifpga_sec_mgr_create()
  - Removed typedefs for imgr ops
---
 .../ABI/testing/sysfs-class-ifpga-sec-mgr |  67 +++
 Documentation/fpga/ifpga-sec-mgr.rst  |  50 ++
 Documentation/fpga/index.rst  |   1 +
 MAINTAINERS   |   9 +
 drivers/fpga/Kconfig  |   9 +
 drivers/fpga/Makefile |   3 +
 drivers/fpga/ifpga-sec-mgr.c  | 432 ++
 include/linux/fpga/ifpga-sec-mgr.h|  81 
 8 files changed, 652 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-class-ifpga-sec-mgr
 create mode 100644 Documentation/fpga/ifpga-sec-mgr.rst
 create mode 100644 drivers/fpga/ifpga-sec-mgr.c
 create mode 100644 include/linux/fpga/ifpga-sec-mgr.h

diff --git a/Documentation/ABI/testing/sysfs-class-ifpga-sec-mgr 
b/Documentation/ABI/testing/sysfs-class-ifpga-sec-mgr
new file mode 100644
index ..707958971bcb
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-ifpga-sec-mgr
@@ -0,0 +1,67 @@
+What:  /sys/class/ifpga_sec_mgr/ifpga_secX/name
+Date:  Oct 2020
+KernelVersion:  5.11
+Contact:   Russ Weight 
+Description:   Name of low level fpga security manager driver.
+
+What:  /sys/class/ifpga_sec_mgr/ifpga_secX/security/sr_root_entry_hash
+Date:  Oct 2020
+KernelVersion:  5.11
+Contact:   Russ Weight 
+Description:   Read only. Returns the root entry hash for the static
+   region if one is programmed, else it returns the
+   string: "hash not programmed".  This file is only
+   visible if the underlying device supports it.
+   Format: "0x%x".
+
+What:  /sys/class/ifpga_sec_mgr/ifpga_secX/security/pr_root_entry_hash
+Date:  Oct 2020
+KernelVersion:  5.11
+Contact:   Russ Weight 
+Description:   Read only. Returns the root entry hash for the partial
+   reconfiguration region if one is programmed, else it
+   returns the string: "hash not programmed".  This file
+   is only visible if the underlying device supports it.
+   Format: "0x%x".
+
+What:  /sys/class/ifpga_sec_mgr/ifpga_secX/security/bmc_root_entry_hash
+Date:  Oct 2020
+KernelVersion:  5.11
+Contact:   Russ Weight 
+Description:   Read only. Returns the root entry hash for the BMC image
+   if one is programmed, else it returns the string:
+   "hash not programmed".  This file is only visible if the
+   underlying device supports it.
+   Format: "0x%x".
+
+What:  /sys/class/ifpga_sec_mgr/ifpga_secX/security/sr_canceled_csks
+Date:  Oct 2020
+KernelVersion:  5.11
+Contact:   Russ Weight 
+Description:   Read only. Returns a list of indices for canceled code
+   signing keys for the static region. The standard bitmap
+   list format is used (e.g. "1,2-6,9").
+
+What:  /sys/class/ifpga_sec_mgr/ifpga_secX/security/pr_canceled_csks
+Date:  Oct 2020
+KernelVersion:  5.11
+Contact:   Russ Weight 
+Description:   Read only. Returns a list of indices for canceled code
+   signing keys for the partial reconfiguration region. The
+   standard bitmap list format is used (e.g. "1,2-6,9").
+
+What:  /sys/class/ifpga_sec_mgr/ifpga_secX/security/bmc_canceled_csks
+Date:  Oct 2020
+KernelVersion:  5.11
+Contact:   Russ Weight 
+Description:   Read only. Returns a list of indices for canceled code
+   signing keys for the BMC.  The standard bitmap list format
+   is used (e.g. "1,2-6,9").
+
+What:  /sys/class/ifpga_sec_mgr/ifpga_secX/security/user_flash_count
+Date:  Oct 2020
+KernelVersion:  5.11
+Contact:   Russ Weight 
+Description:   Read only. Returns number of times the user image for the
+   static region has been flashed.
+   Format: "%u".
diff --git a/Documentation/fpga/ifpga-sec-mgr.rst 
b/Documentation/fpga/ifpga-sec-mgr.rst
new file mode 100644
index ..02f3f65b182b
--- /dev/null
+++ b/Documentation/fpga/ifpga-sec-mgr.rst
@@ -0,0 +1,50 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+==

[PATCH v2 6/7] fpga: sec-mgr: enable cancel of secure update

[Russ Weight]

Extend the Intel Security Manager class driver to include
an update/cancel sysfs file that can be written to request
that an update be canceled. The write may return EBUSY if
the update has progressed to the point that it cannot be
canceled by software or ENODEV if there is no update in
progress.

Signed-off-by: Russ Weight 
---
v2:
  - Bumped documentation date and version
  - Minor code cleanup per review comments 
---
 .../ABI/testing/sysfs-class-ifpga-sec-mgr | 10 
 drivers/fpga/ifpga-sec-mgr.c  | 59 +--
 include/linux/fpga/ifpga-sec-mgr.h|  1 +
 3 files changed, 66 insertions(+), 4 deletions(-)

diff --git a/Documentation/ABI/testing/sysfs-class-ifpga-sec-mgr 
b/Documentation/ABI/testing/sysfs-class-ifpga-sec-mgr
index ec51135fcb6a..caafe7eb7670 100644
--- a/Documentation/ABI/testing/sysfs-class-ifpga-sec-mgr
+++ b/Documentation/ABI/testing/sysfs-class-ifpga-sec-mgr
@@ -79,6 +79,16 @@ Description: Write only. Write the filename of an Intel image
and Root Entry Hashes, and to cancel Code Signing
Keys (CSK).
 
+What:  /sys/class/ifpga_sec_mgr/ifpga_secX/update/cancel
+Date:  Oct 2020
+KernelVersion:  5.11
+Contact:   Russ Weight 
+Description:   Write-only. Write a "1" to this file to request
+   that a current update be canceled. This request
+   will be rejected (EBUSY) if the programming phase
+   has already started or (ENODEV) if there is no
+   update in progress.
+
 What:  /sys/class/ifpga_sec_mgr/ifpga_secX/update/status
 Date:  Oct 2020
 KernelVersion:  5.11
diff --git a/drivers/fpga/ifpga-sec-mgr.c b/drivers/fpga/ifpga-sec-mgr.c
index d8ac863c1159..6267ac3a0780 100644
--- a/drivers/fpga/ifpga-sec-mgr.c
+++ b/drivers/fpga/ifpga-sec-mgr.c
@@ -159,6 +159,23 @@ static void ifpga_sec_dev_error(struct ifpga_sec_mgr *imgr,
imgr->iops->cancel(imgr);
 }
 
+static int progress_transition(struct ifpga_sec_mgr *imgr,
+  enum ifpga_sec_prog new_progress)
+{
+   int ret = 0;
+
+   mutex_lock(&imgr->lock);
+   if (imgr->request_cancel) {
+   set_error(imgr, IFPGA_SEC_ERR_CANCELED);
+   imgr->iops->cancel(imgr);
+   ret = -ECANCELED;
+   } else {
+   update_progress(imgr, new_progress);
+   }
+   mutex_unlock(&imgr->lock);
+   return ret;
+}
+
 static void progress_complete(struct ifpga_sec_mgr *imgr)
 {
mutex_lock(&imgr->lock);
@@ -190,16 +207,20 @@ static void ifpga_sec_mgr_update(struct work_struct *work)
goto release_fw_exit;
}
 
-   update_progress(imgr, IFPGA_SEC_PROG_PREPARING);
+   if (progress_transition(imgr, IFPGA_SEC_PROG_PREPARING))
+   goto modput_exit;
+
ret = imgr->iops->prepare(imgr);
if (ret) {
ifpga_sec_dev_error(imgr, ret);
goto modput_exit;
}
 
-   update_progress(imgr, IFPGA_SEC_PROG_WRITING);
+   if (progress_transition(imgr, IFPGA_SEC_PROG_WRITING))
+   goto done;
+
size = imgr->remaining_size;
-   while (size) {
+   while (size && !imgr->request_cancel) {
blk_size = min_t(u32, size, WRITE_BLOCK_SIZE);
size -= blk_size;
ret = imgr->iops->write_blk(imgr, offset, blk_size);
@@ -212,7 +233,9 @@ static void ifpga_sec_mgr_update(struct work_struct *work)
offset += blk_size;
}
 
-   update_progress(imgr, IFPGA_SEC_PROG_PROGRAMMING);
+   if (progress_transition(imgr, IFPGA_SEC_PROG_PROGRAMMING))
+   goto done;
+
ret = imgr->iops->poll_complete(imgr);
if (ret) {
ifpga_sec_dev_error(imgr, ret);
@@ -381,6 +404,7 @@ static ssize_t filename_store(struct device *dev, struct 
device_attribute *attr,
}
 
imgr->err_code = IFPGA_SEC_ERR_NONE;
+   imgr->request_cancel = false;
imgr->progress = IFPGA_SEC_PROG_READING;
reinit_completion(&imgr->update_done);
schedule_work(&imgr->work);
@@ -391,8 +415,32 @@ static ssize_t filename_store(struct device *dev, struct 
device_attribute *attr,
 }
 static DEVICE_ATTR_WO(filename);
 
+static ssize_t cancel_store(struct device *dev, struct device_attribute *attr,
+   const char *buf, size_t count)
+{
+   struct ifpga_sec_mgr *imgr = to_sec_mgr(dev);
+   bool cancel;
+   int ret = count;
+
+   if (kstrtobool(buf, &cancel) || !cancel)
+   return -EINVAL;
+
+   mutex_lock(&imgr->lock);
+   if (imgr->progress == IFPGA_SEC_PROG_PROGRAMMING)
+   ret = -EBUSY;
+   else if (imgr->progress == IFPGA_SEC_PROG_IDLE)
+   ret = -ENODEV;
+   else
+   imgr->request_cancel = true;
+   mutex_unlock(&imgr->lock);
+
+   return ret;
+}
+static DEVICE_ATTR_WO(cancel);
+
 static struct attribute *s

[PATCH v2 4/7] fpga: sec-mgr: expose sec-mgr update errors

[Russ Weight]

Extend Intel Security Manager class driver to include
an update/error sysfs node that can be read for error
information when a secure update fails.

Signed-off-by: Russ Weight 
---
v2:
  - Bumped documentation date and version
  - Added warning to sec_progress() for invalid progress status
  - Added sec_error() function (similar to sec_progress())
---
 .../ABI/testing/sysfs-class-ifpga-sec-mgr | 17 
 drivers/fpga/ifpga-sec-mgr.c  | 81 ---
 include/linux/fpga/ifpga-sec-mgr.h|  1 +
 3 files changed, 89 insertions(+), 10 deletions(-)

diff --git a/Documentation/ABI/testing/sysfs-class-ifpga-sec-mgr 
b/Documentation/ABI/testing/sysfs-class-ifpga-sec-mgr
index 73a5246fea1b..1f9f2c215e0c 100644
--- a/Documentation/ABI/testing/sysfs-class-ifpga-sec-mgr
+++ b/Documentation/ABI/testing/sysfs-class-ifpga-sec-mgr
@@ -89,3 +89,20 @@ Description: Read-only. Returns a string describing the 
current
programming. Userspace code can poll on this file,
as it will be signaled by sysfs_notify() on each
state change.
+
+What:  /sys/class/ifpga_sec_mgr/ifpga_secX/update/error
+Date:  Oct 2020
+KernelVersion:  5.11
+Contact:   Russ Weight 
+Description:   Read-only. Returns a string describing the failure
+   of a secure update. This string will be in the form
+   of :, where  will be one of
+   the status strings described for the status sysfs
+   file and  will be one of the following:
+   hw-error, timeout, user-abort, device-busy,
+   invalid-file-size, read-write-error, flash-wearout,
+   file-read-error.  The error sysfs file is only
+   meaningful when the secure update engine is in the
+   idle state. If this file is read while a secure
+   update is in progress, then the read will fail with
+   EBUSY.
diff --git a/drivers/fpga/ifpga-sec-mgr.c b/drivers/fpga/ifpga-sec-mgr.c
index ad918fb42dc2..456ea0b71e3d 100644
--- a/drivers/fpga/ifpga-sec-mgr.c
+++ b/drivers/fpga/ifpga-sec-mgr.c
@@ -146,10 +146,16 @@ static void update_progress(struct ifpga_sec_mgr *imgr,
sysfs_notify(&imgr->dev.kobj, "update", "status");
 }
 
+static void set_error(struct ifpga_sec_mgr *imgr, enum ifpga_sec_err err_code)
+{
+   imgr->err_state = imgr->progress;
+   imgr->err_code = err_code;
+}
+
 static void ifpga_sec_dev_error(struct ifpga_sec_mgr *imgr,
enum ifpga_sec_err err_code)
 {
-   imgr->err_code = err_code;
+   set_error(imgr, err_code);
imgr->iops->cancel(imgr);
 }
 
@@ -172,7 +178,7 @@ static void ifpga_sec_mgr_update(struct work_struct *work)
 
get_device(&imgr->dev);
if (request_firmware(&fw, imgr->filename, &imgr->dev)) {
-   imgr->err_code = IFPGA_SEC_ERR_FILE_READ;
+   set_error(imgr, IFPGA_SEC_ERR_FILE_READ);
goto idle_exit;
}
 
@@ -180,7 +186,7 @@ static void ifpga_sec_mgr_update(struct work_struct *work)
imgr->remaining_size = fw->size;
 
if (!try_module_get(imgr->dev.parent->driver->owner)) {
-   imgr->err_code = IFPGA_SEC_ERR_BUSY;
+   set_error(imgr, IFPGA_SEC_ERR_BUSY);
goto release_fw_exit;
}
 
@@ -274,22 +280,76 @@ static const char * const sec_mgr_prog_str[] = {
"programming"   /* IFPGA_SEC_PROG_PROGRAMMING */
 };
 
-static ssize_t
-status_show(struct device *dev, struct device_attribute *attr, char *buf)
+static const char * const sec_mgr_err_str[] = {
+   "none", /* IFPGA_SEC_ERR_NONE */
+   "hw-error", /* IFPGA_SEC_ERR_HW_ERROR */
+   "timeout",  /* IFPGA_SEC_ERR_TIMEOUT */
+   "user-abort",   /* IFPGA_SEC_ERR_CANCELED */
+   "device-busy",  /* IFPGA_SEC_ERR_BUSY */
+   "invalid-file-size",/* IFPGA_SEC_ERR_INVALID_SIZE */
+   "read-write-error", /* IFPGA_SEC_ERR_RW_ERROR */
+   "flash-wearout",/* IFPGA_SEC_ERR_WEAROUT */
+   "file-read-error"   /* IFPGA_SEC_ERR_FILE_READ */
+};
+
+static const char *sec_progress(struct device *dev, enum ifpga_sec_prog prog)
 {
-   struct ifpga_sec_mgr *imgr = to_sec_mgr(dev);
const char *status = "unknown-status";
 
-   if (imgr->progress < IFPGA_SEC_PROG_MAX)
-   status = sec_mgr_prog_str[imgr->progress];
+   if (prog < IFPGA_SEC_PROG_MAX)
+   status = sec_mgr_prog_str[prog];
else
dev_warn(dev, "Invalid status during secure update: %d\n",
-imgr->progress);
+prog);
+
+   return status;
+}
+
+static const char *sec_error(struct device *dev, enum ifpga_sec_err err_code)
+{
+   const char *error = "unknown-error";
+
+   if (err_code < IFPGA_SEC_ERR_MAX)
+   error = sec_mgr_err_str[err_code];

[PATCH v2 2/7] fpga: sec-mgr: enable secure updates

[Russ Weight]

Extend the FPGA Intel Security Manager class driver to
include an update/filename sysfs node that can be used
to initiate a security update.  The filename of a secure
update file (BMC image, FPGA image, Root Entry Hash image,
or Code Signing Key cancellation image) can be written to
this sysfs entry to cause a secure update to occur.

The write of the filename will return immediately, and the
update will begin in the context of a kernel worker thread.
This tool utilizes the request_firmware framework, which
requires that the image file reside under /lib/firmware.

Signed-off-by: Russ Weight 
---
v2:
  - Bumped documentation date and version
  - Removed explicit value assignments in enums
  - Other minor code cleanup per review comments 
---
 .../ABI/testing/sysfs-class-ifpga-sec-mgr |  13 ++
 drivers/fpga/ifpga-sec-mgr.c  | 157 ++
 include/linux/fpga/ifpga-sec-mgr.h|  49 ++
 3 files changed, 219 insertions(+)

diff --git a/Documentation/ABI/testing/sysfs-class-ifpga-sec-mgr 
b/Documentation/ABI/testing/sysfs-class-ifpga-sec-mgr
index 707958971bcb..4f375f132c34 100644
--- a/Documentation/ABI/testing/sysfs-class-ifpga-sec-mgr
+++ b/Documentation/ABI/testing/sysfs-class-ifpga-sec-mgr
@@ -65,3 +65,16 @@ Contact: Russ Weight 
 Description:   Read only. Returns number of times the user image for the
static region has been flashed.
Format: "%u".
+
+What:  /sys/class/ifpga_sec_mgr/ifpga_secX/update/filename
+Date:  Oct 2020
+KernelVersion:  5.11
+Contact:   Russ Weight 
+Description:   Write only. Write the filename of an Intel image
+   file to this sysfs file to initiate a secure
+   update. The file must have an appropriate header
+   which, among other things, identifies the target
+   for the update. This mechanism is used to update
+   BMC images, BMC firmware, Static Region images,
+   and Root Entry Hashes, and to cancel Code Signing
+   Keys (CSK).
diff --git a/drivers/fpga/ifpga-sec-mgr.c b/drivers/fpga/ifpga-sec-mgr.c
index f1caa4602ab3..7d5a4979554b 100644
--- a/drivers/fpga/ifpga-sec-mgr.c
+++ b/drivers/fpga/ifpga-sec-mgr.c
@@ -5,8 +5,11 @@
  * Copyright (C) 2019-2020 Intel Corporation, Inc.
  */
 
+#include 
+#include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -14,6 +17,8 @@
 static DEFINE_IDA(ifpga_sec_mgr_ida);
 static struct class *ifpga_sec_mgr_class;
 
+#define WRITE_BLOCK_SIZE   0x4000
+
 #define to_sec_mgr(d) container_of(d, struct ifpga_sec_mgr, dev)
 
 static ssize_t
@@ -134,6 +139,96 @@ static struct attribute *sec_mgr_security_attrs[] = {
NULL,
 };
 
+static void ifpga_sec_dev_error(struct ifpga_sec_mgr *imgr,
+   enum ifpga_sec_err err_code)
+{
+   imgr->err_code = err_code;
+   imgr->iops->cancel(imgr);
+}
+
+static void progress_complete(struct ifpga_sec_mgr *imgr)
+{
+   mutex_lock(&imgr->lock);
+   imgr->progress = IFPGA_SEC_PROG_IDLE;
+   complete_all(&imgr->update_done);
+   mutex_unlock(&imgr->lock);
+}
+
+static void ifpga_sec_mgr_update(struct work_struct *work)
+{
+   u32 size, blk_size, offset = 0;
+   struct ifpga_sec_mgr *imgr;
+   const struct firmware *fw;
+   enum ifpga_sec_err ret;
+
+   imgr = container_of(work, struct ifpga_sec_mgr, work);
+
+   get_device(&imgr->dev);
+   if (request_firmware(&fw, imgr->filename, &imgr->dev)) {
+   imgr->err_code = IFPGA_SEC_ERR_FILE_READ;
+   goto idle_exit;
+   }
+
+   imgr->data = fw->data;
+   imgr->remaining_size = fw->size;
+
+   if (!try_module_get(imgr->dev.parent->driver->owner)) {
+   imgr->err_code = IFPGA_SEC_ERR_BUSY;
+   goto release_fw_exit;
+   }
+
+   imgr->progress = IFPGA_SEC_PROG_PREPARING;
+   ret = imgr->iops->prepare(imgr);
+   if (ret) {
+   ifpga_sec_dev_error(imgr, ret);
+   goto modput_exit;
+   }
+
+   imgr->progress = IFPGA_SEC_PROG_WRITING;
+   size = imgr->remaining_size;
+   while (size) {
+   blk_size = min_t(u32, size, WRITE_BLOCK_SIZE);
+   size -= blk_size;
+   ret = imgr->iops->write_blk(imgr, offset, blk_size);
+   if (ret) {
+   ifpga_sec_dev_error(imgr, ret);
+   goto done;
+   }
+
+   imgr->remaining_size = size;
+   offset += blk_size;
+   }
+
+   imgr->progress = IFPGA_SEC_PROG_PROGRAMMING;
+   ret = imgr->iops->poll_complete(imgr);
+   if (ret) {
+   ifpga_sec_dev_error(imgr, ret);
+   goto done;
+   }
+
+done:
+   if (imgr->iops->cleanup)
+   imgr->iops->cleanup(imgr);
+
+modput_exit:
+   module_put(imgr->dev.parent->driver->owner);
+
+release_fw_exit:
+   imgr->data = NULL;
+

Re: [PATCH v2] net: usb: rtl8150: prevent set_ethernet_addr from setting uninit address

[David Miller]

From: Anant Thazhemadam 
Date: Fri, 2 Oct 2020 17:04:13 +0530

> But this patch is about ensuring that an uninitialized variable's
> value (whatever that may be) is not set as the ethernet address
> blindly (without any form of checking if get_registers() worked
> as expected, or not).

Right, and if you are going to check for errors then you have to
handle the error properly.

And the proper way to handle this error is to set a random ethernet
address on the device.

Re: [PATCH 2/2] mm/frame-vec: use FOLL_LONGTERM

[John Hubbard]

On 10/2/20 10:53 AM, Daniel Vetter wrote:

For $reasons I've stumbled over this code and I'm not sure the change
to the new gup functions in 55a650c35fea ("mm/gup: frame_vector:
convert get_user_pages() --> pin_user_pages()") was entirely correct.

This here is used for long term buffers (not just quick I/O) like
RDMA, and John notes this in his patch. But I thought the rule for
these is that they need to add FOLL_LONGTERM, which John's patch
didn't do.


Yep. The earlier gup --> pup conversion patches were intended to not
have any noticeable behavior changes, and FOLL_LONGTERM, with it's
special cases and such, added some risk that I wasn't ready to take
on yet. Also, FOLL_LONGTERM rules are only *recently* getting firmed
up. So there was some doubt at least in my mind, about which sites
should have it.

But now that we're here, I think it's really good that you've brought
this up. It's definitely time to add FOLL_LONGTERM wherever it's missing.

thanks,
--
John Hubbard
NVIDIA



There is already a dax specific check (added in b7f0554a56f2 ("mm:
fail get_vaddr_frames() for filesystem-dax mappings")), so this seems
like the prudent thing to do.

Signed-off-by: Daniel Vetter 
Cc: Andrew Morton 
Cc: John Hubbard 
Cc: Jérôme Glisse 
Cc: Jan Kara 
Cc: Dan Williams 
Cc: linux...@kvack.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-me...@vger.kernel.org
---
Hi all,

I stumbled over this and figured typing this patch can't hurt. Really
just to maybe learn a few things about how gup/pup is supposed to be
used (we have a bit of that in drivers/gpu), this here isn't really
ralated to anything I'm doing.

I'm also wondering whether the explicit dax check should be removed,
since FOLL_LONGTERM should take care of that already.
-Daniel
---
  mm/frame_vector.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mm/frame_vector.c b/mm/frame_vector.c
index 5d34c9047e9c..3507e09cb3ff 100644
--- a/mm/frame_vector.c
+++ b/mm/frame_vector.c
@@ -35,7 +35,7 @@ int get_vaddr_frames(unsigned long start, unsigned int 
nr_frames,
  {
struct mm_struct *mm = current->mm;
struct vm_area_struct *vma;
-   unsigned int gup_flags = FOLL_WRITE | FOLL_FORCE;
+   unsigned int gup_flags = FOLL_WRITE | FOLL_FORCE | FOLL_LONGTERM;
int ret = 0;
int err;
int locked;

[PATCH][next] printk: Use fallthrough pseudo-keyword

[Gustavo A. R. Silva]

Replace /* FALL THRU */ comment with the new pseudo-keyword macro
fallthrough[1].

[1] 
https://www.kernel.org/doc/html/v5.7/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-through

Signed-off-by: Gustavo A. R. Silva 
---
 kernel/printk/printk.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index 1538df175aae..fe64a49344bf 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -1617,7 +1617,7 @@ int do_syslog(int type, char __user *buf, int len, int 
source)
/* Read/clear last kernel messages */
case SYSLOG_ACTION_READ_CLEAR:
clear = true;
-   /* FALL THRU */
+   fallthrough;
/* Read last kernel messages */
case SYSLOG_ACTION_READ_ALL:
if (!buf || len < 0)
-- 
2.27.0

Re: [PATCH v2 7/9] x86: Use current USER_CS to setup correct context on vmx entry

[Sean Christopherson]

On Thu, Oct 01, 2020 at 02:52:32PM -0700, Andy Lutomirski wrote:
> On Thu, Oct 1, 2020 at 1:59 PM Gabriel Krisman Bertazi
>  wrote:
> >
> > vmx_prepare_switch_to_guest shouldn't use is_64bit_mm, which has a
> > very specific use in uprobes.  Use the user_64bit_mode helper instead.
> > This reduces the usage of is_64bit_mm, which is awkward, since it relies
> > on the personality at load time, which is fine for uprobes, but doesn't
> > seem fine here.
> >
> > I tested this by running VMs with 64 and 32 bits payloads from 64/32
> > programs.
> >
> > Signed-off-by: Gabriel Krisman Bertazi 
> > ---
> >  arch/x86/kvm/vmx/vmx.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
> > index 7b2a068f08c1..b5aafd9e5f5d 100644
> > --- a/arch/x86/kvm/vmx/vmx.c
> > +++ b/arch/x86/kvm/vmx/vmx.c
> > @@ -1172,7 +1172,7 @@ void vmx_prepare_switch_to_guest(struct kvm_vcpu 
> > *vcpu)
> > savesegment(es, host_state->es_sel);
> >
> > gs_base = cpu_kernelmode_gs_base(cpu);
> > -   if (likely(is_64bit_mm(current->mm))) {
> > +   if (likely(user_64bit_mode(current_pt_regs( {
> > current_save_fsgs();
> > fs_sel = current->thread.fsindex;
> > gs_sel = current->thread.gsindex;
> 
> I disagree with this one.  This whole code path is nonsense.  Can you
> just remove the condition entirely and use the 64-bit path
> unconditionally?

I finally came back to this one with fresh eyes.  I've read through the code
a bajllion times and typed up half a dozen responses.  I think, finally, I
understand what's broken.

I believe your original assertion that the bug was misdiagnosed is correct
(can't link because LKML wasn't in the loop).  I'm pretty sure your analysis
that KVM's handling of things works mostly by coincidence is also correct.

The coincidence is that "real" VMMs all use arch_prctl(), and
do_arch_prctl_64() ensures thread.{fs,gs}base are accurate.  save_base_legacy()
detects sel==0 and intentionally does nothing, knowing the the base is already
accurate.

Userspaces that don't use arch_prctl(), in the bug report case a 32-bit compat
test, may or may not have accurate thread.{fs,gs}base values.  This is
especially true if sel!=0 as save_base_legacy() explicitly zeros the base in
this case, as load_seg_legacy() will restore the seg on the backend.

KVM on the other hand assumes thread.{fs,gs}base are always fresh.  When that
didn't hold true for userspace that didn't use arch_prctl(), the fix of
detecting a !64-bit mm just so happened to work because all 64-bit VMMs use
arch_prctl().

It's tempting to just open code this and use RD{FS,GS}BASE when possible,
i.e. avoid any guesswork.  Maybe with a module param that userspace can set
to tell KVM it doesn't do anything fancy with FS/GS base (will userspace still
use arch_prctl() even if FSGSABSE is available?).

savesegment(fs, fs_sel);
savesegment(gs, gs_sel);
if (use_current_fsgs_base) {
fs_base = current->thread.fsbase;
vmx->msr_host_kernel_gs_base = current->thread.gsbase;
} else if (static_cpu_has(X86_FEATURE_FSGSBASE)) {
fs_base = rdfsbase()
vmx->msr_host_kernel_gs_base = __rdgsbase_inactive();
} else {
fs_base = read_msr(MSR_FS_BASE);
vmx->msr_host_kernel_gs_base = read_msr(MSR_KERNEL_GS_BASE);
}

I'll revisit this on Monday and run a patch by Paolo.

Re: [PATCH net-next v2 6/6] bonding: make Kconfig toggle to disable legacy interfaces

[Stephen Hemminger]

On Fri, 2 Oct 2020 16:23:46 -0400
Jarod Wilson  wrote:

> On Fri, Oct 2, 2020 at 3:13 PM Stephen Hemminger
>  wrote:
> >
> > On Fri,  2 Oct 2020 13:40:01 -0400
> > Jarod Wilson  wrote:
> >  
> > > By default, enable retaining all user-facing API that includes the use of
> > > master and slave, but add a Kconfig knob that allows those that wish to
> > > remove it entirely do so in one shot.
> > >
> > > Cc: Jay Vosburgh 
> > > Cc: Veaceslav Falico 
> > > Cc: Andy Gospodarek 
> > > Cc: "David S. Miller" 
> > > Cc: Jakub Kicinski 
> > > Cc: Thomas Davis 
> > > Cc: net...@vger.kernel.org
> > > Signed-off-by: Jarod Wilson 
> > > ---
> > >  drivers/net/Kconfig   | 12 
> > >  drivers/net/bonding/bond_main.c   |  4 ++--
> > >  drivers/net/bonding/bond_options.c|  4 ++--
> > >  drivers/net/bonding/bond_procfs.c |  8 
> > >  drivers/net/bonding/bond_sysfs.c  | 14 ++
> > >  drivers/net/bonding/bond_sysfs_port.c |  6 --
> > >  6 files changed, 38 insertions(+), 10 deletions(-)
> > >  
> >
> > This is problematic. You are printing both old and new values.
> > Also every distribution will have to enable it.
> >
> > This looks like too much of change to users.  
> 
> I'd had a bit of feedback that people would rather see both, and be
> able to toggle off the old ones, rather than only having one or the
> other, depending on the toggle, so I thought I'd give this a try. I
> kind of liked the one or the other route, but I see the problems with
> that too.
> 
> For simplicity, I'm kind of liking the idea of just not updating the
> proc and sysfs interfaces, have a toggle entirely disable them, and
> work on enhancing userspace to only use netlink, but ... it's going to
> be a while before any such work makes its way to any already shipping
> distros. I don't have a satisfying answer here.
> 

I like the idea of having bonding proc and sysf apis optional.

[PATCH][next] pata_cmd64x: Use fallthrough pseudo-keyword

[Gustavo A. R. Silva]

Replace /* FALL THRU */ comment with the new pseudo-keyword macro
fallthrough[1].

[1] 
https://www.kernel.org/doc/html/v5.7/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-through

Signed-off-by: Gustavo A. R. Silva 
---
 drivers/ata/pata_cmd64x.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/ata/pata_cmd64x.c b/drivers/ata/pata_cmd64x.c
index 3134eaec9e3d..1d74d89b5bed 100644
--- a/drivers/ata/pata_cmd64x.c
+++ b/drivers/ata/pata_cmd64x.c
@@ -461,7 +461,7 @@ static int cmd64x_init_one(struct pci_dev *pdev, const 
struct pci_device_id *id)
case 1:
ppi[0] = &cmd_info[4];
ppi[1] = &cmd_info[4];
-   /* FALL THRU */
+   fallthrough;
/* Early revs have no CNTRL_CH0 */
case 2:
case 0:
-- 
2.27.0

Re: [PATCH 1/2] sparc32: Move ioremap/iounmap declaration before asm-generic/io.h include

[David Miller]

From: Lorenzo Pieralisi 
Date: Fri, 2 Oct 2020 15:50:29 +0100

> On Tue, Sep 15, 2020 at 01:11:21PM -0700, David Miller wrote:
>> From: Lorenzo Pieralisi 
>> Date: Tue, 15 Sep 2020 10:32:02 +0100
>> 
>> > Move the ioremap/iounmap declaration before asm-generic/io.h is
>> > included so that it is visible within it.
>> > 
>> > Signed-off-by: Lorenzo Pieralisi 
>> 
>> Acked-by: David S. Miller 
> 
> Hi David,
> 
> can I apply your Acked-by to v2 (where I had to split this patch in 2):
> 
> https://lore.kernel.org/lkml/cover.1600254147.git.lorenzo.pieral...@arm.com
> I am about to merge it - please let me know.

Yes, you can.

Re: linux-next: build warning after merge of the tip tree

[Kees Cook]

On Thu, Oct 01, 2020 at 09:02:57PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> On Tue, 15 Sep 2020 08:35:53 +1000 Stephen Rothwell  
> wrote:
> >
> > Hi Kees,
> > 
> > On Mon, 14 Sep 2020 13:11:37 -0700 Kees Cook  wrote:
> > >
> > > On Mon, Sep 14, 2020 at 01:22:49PM +1000, Stephen Rothwell wrote:  
> > > > After merging the tip tree, today's linux-next build (x86_64 
> > > > allmodconfig)
> > > > produced this warning:
> > > > 
> > > > x86_64-linux-gnu-ld: warning: orphan section `.ctors.65435' from 
> > > > `kernel/trace/trace_selftest_dynamic.o' being placed in section 
> > > > `.ctors.65435'
> > > > [...]
> > > 
> > > Hmm, I wasn't seeing that...
> > > 
> > > Which gcc and bintuils versions are you using?  
> > 
> > gcc (Debian 10.2.0-5) 10.2.0
> > GNU ld (GNU Binutils for Debian) 2.35
> 
> Any progress on this?

Hi!

I needed to get by build environment set up with the newer toolchain,
and I've finally gotten that done today. I'll be investigating it
shortly; thanks for waiting on me!

-Kees

-- 
Kees Cook

[PATCH][next] usbnet: Use fallthrough pseudo-keyword

[Gustavo A. R. Silva]

Replace // FALLTHROUGH comment with the new pseudo-keyword macro
fallthrough[1].

[1] 
https://www.kernel.org/doc/html/v5.7/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-through

Signed-off-by: Gustavo A. R. Silva 
---
 drivers/net/usb/usbnet.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c
index 2b2a841cd938..bf6c58240bd4 100644
--- a/drivers/net/usb/usbnet.c
+++ b/drivers/net/usb/usbnet.c
@@ -597,7 +597,7 @@ static void rx_complete (struct urb *urb)
case -EPIPE:
dev->net->stats.rx_errors++;
usbnet_defer_kevent (dev, EVENT_RX_HALT);
-   // FALLTHROUGH
+   fallthrough;
 
/* software-driven interface shutdown */
case -ECONNRESET:   /* async unlink */
-- 
2.27.0

Re: [PATCH v13 19/26] mm: Re-introduce do_mmap_pgoff()

[Peter Collingbourne]

On Fri, Oct 2, 2020 at 8:58 AM Yu, Yu-cheng  wrote:
>
> On 10/1/2020 7:06 PM, Peter Collingbourne wrote:
> > On Fri, Sep 25, 2020 at 7:57 AM Yu-cheng Yu  wrote:
> >>
> >> There was no more caller passing vm_flags to do_mmap(), and vm_flags was
> >> removed from the function's input by:
> >>
> >>  commit 45e55300f114 ("mm: remove unnecessary wrapper function 
> >> do_mmap_pgoff()").
> >>
> >> There is a new user now.  Shadow stack allocation passes VM_SHSTK to
> >> do_mmap().  Re-introduce the vm_flags and do_mmap_pgoff().
> >
> > I would prefer to change the callers to pass the additional 0 argument
> > instead of bringing the wrapper function back, but if we're going to
> > bring it back then we should fix the naming (both functions take a
> > pgoff argument, so the previous name do_mmap_pgoff() was just plain
> > confusing).
> >
> > Peter
> >
>
> Thanks for your feedback.  Here is the updated patch.  I will re-send
> the whole series later.
>
> Yu-cheng
>
> ==
>
>  From 6a9f1e6bcdb6e599a44d5f58cf4cebd28c4634a2 Mon Sep 17 00:00:00 2001
> From: Yu-cheng Yu 
> Date: Wed, 12 Aug 2020 14:01:58 -0700
> Subject: [PATCH 19/26] mm: Re-introduce do_mmap_pgoff()

The subject line of the commit message needs to be updated, but aside from that:

Reviewed-by: Peter Collingbourne 

Peter

>
> There was no more caller passing vm_flags to do_mmap(), and vm_flags was
> removed from the function's input by:
>
>  commit 45e55300f114 ("mm: remove unnecessary wrapper function
> do_mmap_pgoff()").
>
> There is a new user now.  Shadow stack allocation passes VM_SHSTK to
> do_mmap().  Re-introduce vm_flags to do_mmap(), but without the old wrapper
> do_mmap_pgoff().  Instead, fix all callers of the wrapper by passing a zero
> vm_flags to do_mmap().
>
> Signed-off-by: Yu-cheng Yu 
> Cc: Peter Collingbourne 
> Cc: Andrew Morton 
> Cc: Oleg Nesterov 
> Cc: linux...@kvack.org
> ---
>   fs/aio.c   |  2 +-
>   include/linux/mm.h |  3 ++-
>   ipc/shm.c  |  2 +-
>   mm/mmap.c  | 10 +-
>   mm/nommu.c |  4 ++--
>   mm/util.c  |  2 +-
>   6 files changed, 12 insertions(+), 11 deletions(-)
>
> diff --git a/fs/aio.c b/fs/aio.c
> index d5ec30385566..ca8c11665eea 100644
> --- a/fs/aio.c
> +++ b/fs/aio.c
> @@ -527,7 +527,7 @@ static int aio_setup_ring(struct kioctx *ctx,
> unsigned int nr_events)
>
> ctx->mmap_base = do_mmap(ctx->aio_ring_file, 0, ctx->mmap_size,
>  PROT_READ | PROT_WRITE,
> -MAP_SHARED, 0, &unused, NULL);
> +MAP_SHARED, 0, 0, &unused, NULL);
> mmap_write_unlock(mm);
> if (IS_ERR((void *)ctx->mmap_base)) {
> ctx->mmap_size = 0;
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index e09d13699bbe..e020eea33138 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -2560,7 +2560,8 @@ extern unsigned long mmap_region(struct file
> *file, unsigned long addr,
> struct list_head *uf);
>   extern unsigned long do_mmap(struct file *file, unsigned long addr,
> unsigned long len, unsigned long prot, unsigned long flags,
> -   unsigned long pgoff, unsigned long *populate, struct list_head *uf);
> +   vm_flags_t vm_flags, unsigned long pgoff, unsigned long *populate,
> +   struct list_head *uf);
>   extern int __do_munmap(struct mm_struct *, unsigned long, size_t,
>struct list_head *uf, bool downgrade);
>   extern int do_munmap(struct mm_struct *, unsigned long, size_t,
> diff --git a/ipc/shm.c b/ipc/shm.c
> index e25c7c6106bc..91474258933d 100644
> --- a/ipc/shm.c
> +++ b/ipc/shm.c
> @@ -1556,7 +1556,7 @@ long do_shmat(int shmid, char __user *shmaddr, int
> shmflg,
> goto invalid;
> }
>
> -   addr = do_mmap(file, addr, size, prot, flags, 0, &populate, NULL);
> +   addr = do_mmap(file, addr, size, prot, flags, 0, 0, &populate, NULL);
> *raddr = addr;
> err = 0;
> if (IS_ERR_VALUE(addr))
> diff --git a/mm/mmap.c b/mm/mmap.c
> index 574b3f273462..fc04184d2eae 100644
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@ -1365,11 +1365,11 @@ static inline bool file_mmap_ok(struct file
> *file, struct inode *inode,
>*/
>   unsigned long do_mmap(struct file *file, unsigned long addr,
> unsigned long len, unsigned long prot,
> -   unsigned long flags, unsigned long pgoff,
> -   unsigned long *populate, struct list_head *uf)
> +   unsigned long flags, vm_flags_t vm_flags,
> +   unsigned long pgoff, unsigned long *populate,
> +   struct list_head *uf)
>   {
> struct mm_struct *mm = current->mm;
> -   vm_flags_t vm_flags;
> int pkey = 0;
>
> *populate = 0;
> @@ -1431,7 +1431,7 @@ unsigned long do_mmap(struct file *file, unsigned
> long addr,
>  * to. we assume access permission

Re: [PATCH net-next v2 6/6] bonding: make Kconfig toggle to disable legacy interfaces

[David Miller]

From: Stephen Hemminger 
Date: Fri, 2 Oct 2020 12:13:17 -0700

> On Fri,  2 Oct 2020 13:40:01 -0400
> Jarod Wilson  wrote:
> 
>> By default, enable retaining all user-facing API that includes the use of
>> master and slave, but add a Kconfig knob that allows those that wish to
>> remove it entirely do so in one shot.
> 
> This is problematic. You are printing both old and new values.
> Also every distribution will have to enable it.
> 
> This looks like too much of change to users.

Agreed, no Kconfig knob.

Keep everything during the deprecation period, then you can kill off
the old names at the end of the deprecation period.

I don't want to create a situation where distribution X lists as a
"feature" that they are able to enable this Kconfig value even though
it breaks UAPI for legacy external code out there.

That's the wrong way to go about this and creates the wrong incentive
system.

I also agree that you can't change the docs to stop mentioning the old
names.  It's almost like we are pretending we aren't doing the
transition and that only the new names matter.  The old names matter
and must therefore be acknowledged, exist, and be referencable in the
documentation until the end of the deprecation period.  You can mark
them "(DEPRECATED)" or similar, but they can't be removed just yet.

Thank you.

[PATCH][next] net: bna: Use fallthrough pseudo-keyword

[Gustavo A. R. Silva]

Replace /* !!! fall through !!! */ comments with the new pseudo-keyword
macro fallthrough[1].

[1] 
https://www.kernel.org/doc/html/v5.7/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-through

Signed-off-by: Gustavo A. R. Silva 
---
 drivers/net/ethernet/brocade/bna/bfa_ioc.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/brocade/bna/bfa_ioc.c 
b/drivers/net/ethernet/brocade/bna/bfa_ioc.c
index fd805c685d92..cd933817a0b8 100644
--- a/drivers/net/ethernet/brocade/bna/bfa_ioc.c
+++ b/drivers/net/ethernet/brocade/bna/bfa_ioc.c
@@ -269,7 +269,7 @@ bfa_ioc_sm_enabling(struct bfa_ioc *ioc, enum ioc_event 
event)
break;
 
case IOC_E_PFFAILED:
-   /* !!! fall through !!! */
+   fallthrough;
case IOC_E_HWERROR:
ioc->cbfn->enable_cbfn(ioc->bfa, BFA_STATUS_IOC_FAILURE);
bfa_fsm_set_state(ioc, bfa_ioc_sm_fail);
@@ -365,7 +365,8 @@ bfa_ioc_sm_op(struct bfa_ioc *ioc, enum ioc_event event)
case IOC_E_PFFAILED:
case IOC_E_HWERROR:
bfa_ioc_hb_stop(ioc);
-   /* !!! fall through !!! */
+   fallthrough;
+
case IOC_E_HBFAIL:
if (ioc->iocpf.auto_recover)
bfa_fsm_set_state(ioc, bfa_ioc_sm_fail_retry);
-- 
2.27.0

Re: [PATCH net-next v2 5/6] bonding: update Documentation for port/bond terminology

[David Miller]

From: Jarod Wilson 
Date: Fri, 2 Oct 2020 16:12:49 -0400

> The documentation was updated to point to the new names, but the old
> ones still exist across the board, there should be no userspace
> breakage here. (My lnst bonding tests actually fall flat currently
> if the old names are gone).

The documentation is the reference point for people reading code in
userspace that manipulates bonding devices.

So people will come across the deprecated names in userland code and
therefore will try to learn what they do and what they mean.

Which means that the documentation must reference the old names.

You can mark them "(DEPRECATED)" or similar, but you must not remove
them.

Re: [PATCH v3 3/7] mfd: Add base driver for Netronix embedded controller

[Jonathan Neuschäfer]

On Tue, Sep 29, 2020 at 07:37:21PM +0300, Andy Shevchenko wrote:
> On Sat, Sep 26, 2020 at 12:32 AM Jonathan Neuschäfer
>  wrote:
> > On Fri, Sep 25, 2020 at 12:29:45PM +0300, Andy Shevchenko wrote:
> > > On Thu, Sep 24, 2020 at 10:26 PM Jonathan Neuschäfer
> > >  wrote:
> 
> ...
> 
> > > > +   dev_alert(&poweroff_restart_client->dev,
> > > > + "Failed to power off (err = %d)\n", res);
> > >
> > > alert? This needs to be explained.
> >
> > I copied the dev_alert from drivers/mfd/rn5t618.c.
> >
> > Upon reconsideration, I'm not sure what the correct log level would be,
> > but _warn seems enough, or maybe _err is better
> 
> It's up to you to decide, but crit/alert and similar has to be
> justified (commit message / comment in the code).

Alright, thanks for explaining.

> > > > +   /*
> > > > +* NOTE: The lower half of the reset value is not sent, because 
> > > > sending
> > > > +* it causes an error
> > >
> > > Why? Any root cause? Perhaps you need to send 0x ?
> >
> > Unknown, because I don't have the EC firmware for analysis. The vendor
> > kernel sends 0xff00 and gets an error.
> >
> > Sending 0x doesn't help.
> 
> Maybe a slightly elaborated comment that it's copied from the vendor
> kernel (which is?).

Good idea, I'll do that.

> ...
> 
> > > > +   dev_info(ec->dev,
> > > > +"Netronix embedded controller version %04x 
> > > > detected.\n",
> > > > +version);
> > >
> > > This info level may confuse users if followed by an error path.
> >
> > Right. I suppose printing incompatible versions is still useful, so how
> > about something like the following?
> >
> >
> >/* Bail out if we encounter an unknown firmware version */
> >switch (version) {
> >case 0xd726: /* found in Kobo Aura */
> >dev_info(ec->dev,
> > "Netronix embedded controller version %04x 
> > detected.\n",
> > version);
> >break;
> >default:
> >dev_err(ec->dev,
> > "Netronix embedded controller version %04x is not 
> > supported.\n",
> > version);
> >return -ENODEV;
> >}
> 
> This is better.
> 
> ...
> 
> > > > +   WARN_ON(poweroff_restart_client);
> > >
> > > WARN_ON? All these alerts, WARNs, BUGs must be explained. Screaming to
> > > the user is not good if it wasn't justified.
> >
> > poweroff_restart_client being already set is not a situation that should
> > happen (and would indicate a bug in this driver, AFAICT), but I guess
> > the log message could be better in that case...
> 
> As per above.

Okay, I'll rework the dev_alert/WARN_ON parts.



Thanks,
Jonathan Neuschäfer


signature.asc
Description: PGP signature

Re: [PATCH net-next v2 6/6] bonding: make Kconfig toggle to disable legacy interfaces

[David Miller]

From: Jarod Wilson 
Date: Fri, 2 Oct 2020 16:23:46 -0400

> I'd had a bit of feedback that people would rather see both, and be
> able to toggle off the old ones, rather than only having one or the
> other, depending on the toggle, so I thought I'd give this a try. I
> kind of liked the one or the other route, but I see the problems with
> that too.

Please keep everything for the entire deprecation period, unconditionally.

Thank you.

[PATCH][next] net: ksz884x: Use fallthrough pseudo-keyword

[Gustavo A. R. Silva]

Replace /* Fallthrough... */ comment with the new pseudo-keyword macro
fallthrough[1].

[1] 
https://www.kernel.org/doc/html/v5.7/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-through

Signed-off-by: Gustavo A. R. Silva 
---
 drivers/net/ethernet/micrel/ksz884x.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/micrel/ksz884x.c 
b/drivers/net/ethernet/micrel/ksz884x.c
index cefbb2298004..9ed264ed7070 100644
--- a/drivers/net/ethernet/micrel/ksz884x.c
+++ b/drivers/net/ethernet/micrel/ksz884x.c
@@ -5833,8 +5833,7 @@ static int netdev_ioctl(struct net_device *dev, struct 
ifreq *ifr, int cmd)
/* Get address of MII PHY in use. */
case SIOCGMIIPHY:
data->phy_id = priv->id;
-
-   /* Fallthrough... */
+   fallthrough;
 
/* Read MII PHY register. */
case SIOCGMIIREG:
-- 
2.27.0

Re: [PATCH v4 1/2] dt-bindings: usb: Add binding for discrete onboard USB hubs

[Rob Herring]

On Fri, Oct 2, 2020 at 1:36 PM Alan Stern  wrote:
>
> On Fri, Oct 02, 2020 at 10:08:17AM -0700, Doug Anderson wrote:
> > As a more similar example of single device that is listed in more than
> > one location in the device tree, we can also look at embedded SDIO
> > BT/WiFi combo cards.  This single device often provides WiFi under an
> > SDIO bus and BT under a serial / USB bus.  I'm not 100% sure there are
> > actually cases were the same board provides device tree data to both
> > at the same time, but "brcm,bcm43540-bt" is an example of providing
> > data to the Bluetooth (connected over serial port) and
> > "brcm,bcm4329-fmac" to the WiFi (connected over the SDIO bus).  Of
> > course WiFi/BT cheat in that the control logic is represented by the
> > SDIO power sequencing stuff...
> >
> >
> > Back to our case, though.  I guess the issue here is that we're the
> > child of more than one bus.  Let's first pretend that the i2c lines of
> > this hub are actually hooked up and establish how that would look
> > first.  Then we can think about how it looks if this same device isn't
> > hooked up via i2c.  In this case, it sounds as if you still don't want
> > the device split among two nodes.  So I guess you'd prefer something
> > like:
> >
> > i2c {
> >   usb-hub@xx {
> > reg = ;
> > compatible = "realtek,rts5411", "onboard-usb-hub";
> > vdd-supply = <&pp3300_hub>;
> > usb-devices = <&usb_controller 1>;
> >   };
> > };
> >
> > ...and then you wouldn't have anything under the USB controller
> > itself.  Is that correct?  So even though there are existing bindings
> > saying that a USB device should be listed via VID/PID, the desire to
> > represent this as a single node overrides that, right?  (NOTE: this is
> > similar to what Matthias proposed in his response except that I've
> > added an index so that we don't need _anything_ under the controller).
> >
> > Having this primarily listed under the i2c bus makes sense because the
> > control logic for the hub is hooked up via i2c.  Having the power
> > supply associated with it also makes some amount of sense since it's a
> > control signal.  It's also convenient that i2c devices have their
> > probe called _before_ we try to detect if they're there because it's
> > common that i2c devices need power applied first.
> >
> > Now, just because we don't have the i2c bus hooked up doesn't change
> > the fact that there is control logic.  We also certainly wouldn't want
> > two ways of describing this same hub: one way if the i2c is hooked up
> > and one way if it's not hooked up.  To me this means that the we
> > should be describing this hub as a top-level node if i2c isn't hooked
> > up, just like we do with "smsc,usb3503a"
> >
> > Said another way, we have these points:
> >
> > a) The control logic for this bus could be hooked up to an i2c bus.
> >
> > b) If the control logic is hooked up to an i2c bus it feels like
> > that's where the device's primary node should be placed, not under the
> > USB controller.
> >
> > c) To keep the i2c and non-i2c case as similar as possible, if the i2c
> > bus isn't hooked up the hub's primary node should be a top-level node,
> > not under the USB controller.
> >
> >
> > NOTE ALSO: the fact that we might want to list this hub under an i2c
> > controller also seems like it's a good argument against putting this
> > logic in the xhci-platform driver?
>
> More and more we are going to see devices that are attached to multiple
> buses.  In this case, one for power control and another for
> commands/data.  If DT doesn't already have a canonical way of handling
> such situations, it needs to develop one soon.

Attached to multiple buses directly is kind of rare from what I've
seen. Most of the time, it's regulators, GPIOs, clocks, etc. which are
well defined in DT. If there is a 2nd bus, it's almost always I2C.

> One can make a case that there should be multiple device nodes in this
> situation, somehow referring to each other so that the system knows they
> all describe the same device.  Maybe one "primary" node for the device
> and the others acting kind of like symbolic links.
>
> Regardless of how the situation is represented in DT, there remains the
> issue of where (i.e., in which driver module) the appropriate code
> belongs.  This goes far beyond USB.  In general, what happens when one
> sort of device normally isn't hooked up through a power regulator, so
> its driver doesn't have any code to enable a regulator, but then some
> system does exactly that?
>
> Even worse, what if the device is on a discoverable bus, so the driver
> doesn't get invoked at all until the device is discovered, but on the
> new system it can't be discovered until the regulator is enabled?

Yep, it's the same issue here with USB, MDIO which just came up a few
weeks ago, MMC/SD which hacked around it with 'mmc-pwrseq' binding
(not something I want to duplicate) and every other discoverable bus.
What do they all have in common? The kern

Re: [PATCH v13 19/26] mm: Re-introduce do_mmap_pgoff()

[Yu, Yu-cheng]

On 10/2/2020 3:52 PM, Peter Collingbourne wrote:

On Fri, Oct 2, 2020 at 8:58 AM Yu, Yu-cheng  wrote:


On 10/1/2020 7:06 PM, Peter Collingbourne wrote:

On Fri, Sep 25, 2020 at 7:57 AM Yu-cheng Yu  wrote:


There was no more caller passing vm_flags to do_mmap(), and vm_flags was
removed from the function's input by:

  commit 45e55300f114 ("mm: remove unnecessary wrapper function 
do_mmap_pgoff()").

There is a new user now.  Shadow stack allocation passes VM_SHSTK to
do_mmap().  Re-introduce the vm_flags and do_mmap_pgoff().


I would prefer to change the callers to pass the additional 0 argument
instead of bringing the wrapper function back, but if we're going to
bring it back then we should fix the naming (both functions take a
pgoff argument, so the previous name do_mmap_pgoff() was just plain
confusing).

Peter



Thanks for your feedback.  Here is the updated patch.  I will re-send
the whole series later.

Yu-cheng

==

  From 6a9f1e6bcdb6e599a44d5f58cf4cebd28c4634a2 Mon Sep 17 00:00:00 2001
From: Yu-cheng Yu 
Date: Wed, 12 Aug 2020 14:01:58 -0700
Subject: [PATCH 19/26] mm: Re-introduce do_mmap_pgoff()


The subject line of the commit message needs to be updated, but aside from that:

Reviewed-by: Peter Collingbourne 

Peter


Thanks for reviewing.  I will fix the subject line.

Yu-cheng

[PATCH] dt-bindings: display: Add dsi-controller.yaml in DSI controller schemas

[Rob Herring]

Some DSI controllers are missing a reference to the recently added
dsi-controller.yaml schema. Add it and we can drop the duplicate parts.

Cc: Maxime Ripard 
Cc: Chen-Yu Tsai 
Cc: Eric Anholt 
Cc: Nicolas Saenz Julienne 
Cc: Florian Fainelli 
Cc: Ray Jui 
Cc: Scott Branden 
Cc: bcm-kernel-feedback-l...@broadcom.com
Cc: Maxime Coquelin 
Cc: Alexandre Torgue 
Cc: "Guido Gúnther" 
Cc: Robert Chiras 
Cc: Philippe Cornu 
Cc: Yannick Fertre 
Signed-off-by: Rob Herring 
---
 .../display/allwinner,sun6i-a31-mipi-dsi.yaml | 11 ++---
 .../bindings/display/brcm,bcm2835-dsi0.yaml   |  3 +++
 .../bindings/display/bridge/nwl-dsi.yaml  | 11 -
 .../bindings/display/st,stm32-dsi.yaml| 23 ---
 4 files changed, 14 insertions(+), 34 deletions(-)

diff --git 
a/Documentation/devicetree/bindings/display/allwinner,sun6i-a31-mipi-dsi.yaml 
b/Documentation/devicetree/bindings/display/allwinner,sun6i-a31-mipi-dsi.yaml
index 63f948175239..7aa330dabc44 100644
--- 
a/Documentation/devicetree/bindings/display/allwinner,sun6i-a31-mipi-dsi.yaml
+++ 
b/Documentation/devicetree/bindings/display/allwinner,sun6i-a31-mipi-dsi.yaml
@@ -11,9 +11,6 @@ maintainers:
   - Maxime Ripard 
 
 properties:
-  "#address-cells": true
-  "#size-cells": true
-
   compatible:
 enum:
   - allwinner,sun6i-a31-mipi-dsi
@@ -57,12 +54,7 @@ properties:
   port should be the input endpoint, usually coming from the
   associated TCON.
 
-patternProperties:
-  "^panel@[0-9]+$": true
-
 required:
-  - "#address-cells"
-  - "#size-cells"
   - compatible
   - reg
   - interrupts
@@ -74,6 +66,7 @@ required:
   - port
 
 allOf:
+  - $ref: dsi-controller.yaml#
   - if:
   properties:
 compatible:
@@ -99,7 +92,7 @@ allOf:
 clocks:
   minItems: 1
 
-additionalProperties: false
+unevaluatedProperties: false
 
 examples:
   - |
diff --git a/Documentation/devicetree/bindings/display/brcm,bcm2835-dsi0.yaml 
b/Documentation/devicetree/bindings/display/brcm,bcm2835-dsi0.yaml
index 3c643b227a70..eb44e072b6e5 100644
--- a/Documentation/devicetree/bindings/display/brcm,bcm2835-dsi0.yaml
+++ b/Documentation/devicetree/bindings/display/brcm,bcm2835-dsi0.yaml
@@ -9,6 +9,9 @@ title: Broadcom VC4 (VideoCore4) DSI Controller
 maintainers:
   - Eric Anholt 
 
+allOf:
+  - $ref: dsi-controller.yaml#
+
 properties:
   "#clock-cells":
 const: 1
diff --git a/Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml 
b/Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml
index b8ba6eb482a1..a125b2dd3a2f 100644
--- a/Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml
@@ -14,6 +14,9 @@ description: |
   NWL MIPI-DSI host controller found on i.MX8 platforms. This is a dsi bridge 
for
   the SOCs NWL MIPI-DSI host controller.
 
+allOf:
+  - $ref: ../dsi-controller.yaml#
+
 properties:
   compatible:
 const: fsl,imx8mq-nwl-dsi
@@ -144,10 +147,6 @@ properties:
 
 additionalProperties: false
 
-patternProperties:
-  "^panel@[0-9]+$":
-type: object
-
 required:
   - '#address-cells'
   - '#size-cells'
@@ -163,7 +162,7 @@ required:
   - reset-names
   - resets
 
-additionalProperties: false
+unevaluatedProperties: false
 
 examples:
   - |
@@ -172,7 +171,7 @@ examples:
 #include 
 #include 
 
-mipi_dsi: mipi_dsi@30a0 {
+dsi@30a0 {
   #address-cells = <1>;
   #size-cells = <0>;
   compatible = "fsl,imx8mq-nwl-dsi";
diff --git a/Documentation/devicetree/bindings/display/st,stm32-dsi.yaml 
b/Documentation/devicetree/bindings/display/st,stm32-dsi.yaml
index 69cc7e8bf15a..327a14d85df8 100644
--- a/Documentation/devicetree/bindings/display/st,stm32-dsi.yaml
+++ b/Documentation/devicetree/bindings/display/st,stm32-dsi.yaml
@@ -13,6 +13,9 @@ maintainers:
 description:
   The STMicroelectronics STM32 DSI controller uses the Synopsys DesignWare 
MIPI-DSI host controller.
 
+allOf:
+  - $ref: dsi-controller.yaml#
+
 properties:
   compatible:
 const: st,stm32-dsi
@@ -65,24 +68,6 @@ properties:
 description:
   DSI output port node, connected to a panel or a bridge input port"
 
-patternProperties:
-  "^(panel|panel-dsi)@[0-9]$":
-type: object
-description:
-  A node containing the panel or bridge description as documented in
-  Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
-properties:
-  port:
-type: object
-description:
-  Panel or bridge port node, connected to the DSI output port (port@1)
-
-  "#address-cells":
-const: 1
-
-  "#size-cells":
-const: 0
-
 required:
   - "#address-cells"
   - "#size-cells"
@@ -92,7 +77,7 @@ required:
   - clock-names
   - ports
 
-additionalProperties: false
+unevaluatedProperties: false
 
 examples:
   - |
-- 
2.25.1

Re: [PATCH] reset: Add reset controller API

[Kevin Hilman]

Amjad Ouled-Ameur  writes:

> The current reset framework API does not allow to release what is done by
> reset_control_reset(), IOW decrement triggered_count. Add the new
> reset_control_resettable() call to do so.
>
> When reset_control_reset() has been called once, the counter
> triggered_count, in the reset framework, is incremented i.e the resource
> under the reset is in-use and the reset should not be done again.
> reset_control_resettable() would be the way to state that the resource is 
> no longer used and, that from the caller's perspective, the reset can be 
> fired again if necessary.
>
> This patch will fix a usb suspend warning seen on the libretech-cc
> related to the shared reset line. This warning was addressed by the 
> previously reverted commit 7a410953d1fb ("usb: dwc3: meson-g12a: fix shared
> reset control use")

Could you also send a patch that shows how your new feature can be used
to fix the problem that was originally fixed by that patch (and still
exists, now that it was reverted.)

Thanks,

Kevin

Re: [PATCH net-next 00/23] rxrpc: Fixes and preparation for RxGK

[David Miller]

From: David Howells 
Date: Thu, 01 Oct 2020 15:56:43 +0100

> The patches are tagged here:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git
>   rxrpc-next-20201010

No, they aren't.


git pull --no-ff 
git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git 
rxrpc-next-20201010
fatal: couldn't find remote ref rxrpc-next-20201010


Also, you have to submit changes much much much earlier.  Don't let your
patch sets get into the 20+ patch range, it's much to large and a huge
burdon for patch reviewers.

Make this patch series smaller, fix the GIT stuff, and resubmit.

Thank you.

Re: [PATCH v2 1/7] fpga: sec-mgr: intel fpga security manager class driver

[Russ Weight]

Hi Moritz,

This patch aligns with FPGA Manager implementation as you requested by
splitting up the create() and register() functions and adding a devm_
version of the create() function. I have a question (below) regarding the
device_add() function call.


On 10/2/20 3:36 PM, Russ Weight wrote:
> Create the Intel Security Manager class driver. The security
> manager provides interfaces to manage secure updates for the
> FPGA and BMC images that are stored in FLASH. The driver can
> also be used to update root entry hashes and to cancel code
> signing keys.
>
> This patch creates the class driver and provides sysfs
> interfaces for displaying root entry hashes, canceled code
> signing keys and flash counts.
>
> Signed-off-by: Russ Weight 
> Signed-off-by: Xu Yilun 
> ---
> v2:
>   - Bumped documentation dates and versions
>   - Added Documentation/fpga/ifpga-sec-mgr.rst 
>   - Removed references to bmc_flash_count & smbus_flash_count (not supported)
>   - Split ifpga_sec_mgr_register() into create() and register() functions
>   - Added devm_ifpga_sec_mgr_create()
>   - Removed typedefs for imgr ops
> ---
>  .../ABI/testing/sysfs-class-ifpga-sec-mgr |  67 +++
>  Documentation/fpga/ifpga-sec-mgr.rst  |  50 ++
>  Documentation/fpga/index.rst  |   1 +
>  MAINTAINERS   |   9 +
>  drivers/fpga/Kconfig  |   9 +
>  drivers/fpga/Makefile |   3 +
>  drivers/fpga/ifpga-sec-mgr.c  | 432 ++
>  include/linux/fpga/ifpga-sec-mgr.h|  81 
>  8 files changed, 652 insertions(+)
>  create mode 100644 Documentation/ABI/testing/sysfs-class-ifpga-sec-mgr
>  create mode 100644 Documentation/fpga/ifpga-sec-mgr.rst
>  create mode 100644 drivers/fpga/ifpga-sec-mgr.c
>  create mode 100644 include/linux/fpga/ifpga-sec-mgr.h
>
> diff --git a/Documentation/ABI/testing/sysfs-class-ifpga-sec-mgr 
> b/Documentation/ABI/testing/sysfs-class-ifpga-sec-mgr
> new file mode 100644
> index ..707958971bcb
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-class-ifpga-sec-mgr
> @@ -0,0 +1,67 @@
> +What:/sys/class/ifpga_sec_mgr/ifpga_secX/name
> +Date:Oct 2020
> +KernelVersion:  5.11
> +Contact: Russ Weight 
> +Description: Name of low level fpga security manager driver.
> +
> +What:
> /sys/class/ifpga_sec_mgr/ifpga_secX/security/sr_root_entry_hash
> +Date:Oct 2020
> +KernelVersion:  5.11
> +Contact: Russ Weight 
> +Description: Read only. Returns the root entry hash for the static
> + region if one is programmed, else it returns the
> + string: "hash not programmed".  This file is only
> + visible if the underlying device supports it.
> + Format: "0x%x".
> +
> +What:
> /sys/class/ifpga_sec_mgr/ifpga_secX/security/pr_root_entry_hash
> +Date:Oct 2020
> +KernelVersion:  5.11
> +Contact: Russ Weight 
> +Description: Read only. Returns the root entry hash for the partial
> + reconfiguration region if one is programmed, else it
> + returns the string: "hash not programmed".  This file
> + is only visible if the underlying device supports it.
> + Format: "0x%x".
> +
> +What:
> /sys/class/ifpga_sec_mgr/ifpga_secX/security/bmc_root_entry_hash
> +Date:Oct 2020
> +KernelVersion:  5.11
> +Contact: Russ Weight 
> +Description: Read only. Returns the root entry hash for the BMC image
> + if one is programmed, else it returns the string:
> + "hash not programmed".  This file is only visible if the
> + underlying device supports it.
> + Format: "0x%x".
> +
> +What:
> /sys/class/ifpga_sec_mgr/ifpga_secX/security/sr_canceled_csks
> +Date:Oct 2020
> +KernelVersion:  5.11
> +Contact: Russ Weight 
> +Description: Read only. Returns a list of indices for canceled code
> + signing keys for the static region. The standard bitmap
> + list format is used (e.g. "1,2-6,9").
> +
> +What:
> /sys/class/ifpga_sec_mgr/ifpga_secX/security/pr_canceled_csks
> +Date:Oct 2020
> +KernelVersion:  5.11
> +Contact: Russ Weight 
> +Description: Read only. Returns a list of indices for canceled code
> + signing keys for the partial reconfiguration region. The
> + standard bitmap list format is used (e.g. "1,2-6,9").
> +
> +What:
> /sys/class/ifpga_sec_mgr/ifpga_secX/security/bmc_canceled_csks
> +Date:Oct 2020
> +KernelVersion:  5.11
> +Contact: Russ Weight 
> +Description: Read only. Returns a list of indices for canceled code
> + signing keys for the BMC.  The standard bitmap list format
> + is used (e.g. "1,2-6,9").
> +
> +What:
> /sys/class/ifpga

Re: [PATCH net-next 0/8] net: ethernet: ti: am65-cpsw: add multi port support in mac-only mode

[Jakub Kicinski]

On Fri, 2 Oct 2020 12:56:43 +0300 Grygorii Strashko wrote:
> On 02/10/2020 02:08, Jakub Kicinski wrote:
> > On Thu, 1 Oct 2020 13:52:50 +0300 Grygorii Strashko wrote:  
> >> This series adds multi-port support in mac-only mode (multi MAC mode) to TI
> >> AM65x CPSW driver in preparation for enabling support for multi-port 
> >> devices,
> >> like Main CPSW0 on K3 J721E SoC or future CPSW3g on K3 AM64x SoC.
> >>
> >> The multi MAC mode is implemented by configuring every enabled port in 
> >> "mac-only"
> >> mode (all ingress packets are sent only to the Host port and egress packets
> >> directed to target Ext. Port) and creating separate net_device for
> >> every enabled Ext. port.  
> > 
> > Do I get it right that you select the mode based on platform? Can the
> > other mode still be supported on these platforms?
> > 
> > Is this a transition to normal DSA mode where ports always have netdevs?
>
> The idea here is to start in multi mac mode by default, as we still
> have pretty high demand for this. Then, and we are working on it, the
> switchdev mode is going to be introduces (not DSA). The switch
> between modes will happen by using devlink option - the approach is
> similar to what was used for Sitara CPSW cpsw_new.c driver [1].

What's unclear from the patches is whether the default configuration
for already supported platforms will change?

All the patches sound like they are "in preparation for support of K3
J721E" etc. So this is just code restructuring with no user-visible
changes?

[PATCH][next] block: scsi_ioctl: Avoid the use of one-element arrays

[Gustavo A. R. Silva]

One-element arrays are being deprecated[1]. Replace the one-element array
with a simple object of type compat_caddr_t: 'compat_caddr_t unused'[2],
once it seems this field is actually never used.

Also, update struct cdrom_generic_command in UAPI by adding an
anonimous union to avoid using the one-element array _reserved_.

[1] 
https://www.kernel.org/doc/html/v5.9-rc1/process/deprecated.html#zero-length-and-one-element-arrays
[2] https://github.com/KSPP/linux/issues/86

Build-tested-by: kernel test robot 
Link: https://lore.kernel.org/lkml/5f76f5d0.qj4t%2fhwurzsw7bta%25...@intel.com/
Signed-off-by: Gustavo A. R. Silva 
---
 block/scsi_ioctl.c | 6 +++---
 include/uapi/linux/cdrom.h | 5 -
 2 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/block/scsi_ioctl.c b/block/scsi_ioctl.c
index 600e38cb69b2..2dfb699389df 100644
--- a/block/scsi_ioctl.c
+++ b/block/scsi_ioctl.c
@@ -643,7 +643,7 @@ struct compat_cdrom_generic_command {
unsigned char   data_direction;
compat_int_tquiet;
compat_int_ttimeout;
-   compat_caddr_t  reserved[1];
+   compat_caddr_t  unused;
 };
 #endif
 
@@ -665,7 +665,7 @@ static int scsi_get_cdrom_generic_arg(struct 
cdrom_generic_command *cgc,
.data_direction = cgc32.data_direction,
.quiet  = cgc32.quiet,
.timeout= cgc32.timeout,
-   .reserved[0]= compat_ptr(cgc32.reserved[0]),
+   .unused = compat_ptr(cgc32.unused),
};
memcpy(&cgc->cmd, &cgc32.cmd, CDROM_PACKET_SIZE);
return 0;
@@ -690,7 +690,7 @@ static int scsi_put_cdrom_generic_arg(const struct 
cdrom_generic_command *cgc,
.data_direction = cgc->data_direction,
.quiet  = cgc->quiet,
.timeout= cgc->timeout,
-   .reserved[0]= (uintptr_t)(cgc->reserved[0]),
+   .unused = (uintptr_t)(cgc->unused),
};
memcpy(&cgc32.cmd, &cgc->cmd, CDROM_PACKET_SIZE);
 
diff --git a/include/uapi/linux/cdrom.h b/include/uapi/linux/cdrom.h
index 2817230148fd..6c34f6e2f1f7 100644
--- a/include/uapi/linux/cdrom.h
+++ b/include/uapi/linux/cdrom.h
@@ -289,7 +289,10 @@ struct cdrom_generic_command
unsigned char   data_direction;
int quiet;
int timeout;
-   void__user *reserved[1];/* unused, actually */
+   union {
+   void__user *reserved[1];/* unused, actually */
+   void__user *unused;
+   };
 };
 
 /*
-- 
2.27.0

[PATCH] dt-bindings: mfd: ti,j721e-system-controller: Fix incorrect pattern property

[Rob Herring]

Pattern properties go under 'patternProperties', not 'properties'.
Otherwise, the pattern is treated as a literal string.

A corresponding meta-schema check has been added to catch bad DT property
names like this.

Fixes: e0f946915b23 ("dt-bindings: mfd: ti,j721e-system-controller.yaml: Add 
J721e system controller")
Cc: Roger Quadros 
Cc: Tero Kristo 
Cc: Lee Jones 
Cc: Kishon Vijay Abraham I 
Signed-off-by: Rob Herring 
---
 .../devicetree/bindings/mfd/ti,j721e-system-controller.yaml   | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git 
a/Documentation/devicetree/bindings/mfd/ti,j721e-system-controller.yaml 
b/Documentation/devicetree/bindings/mfd/ti,j721e-system-controller.yaml
index c8fd5d3e3071..da3d9ab758b9 100644
--- a/Documentation/devicetree/bindings/mfd/ti,j721e-system-controller.yaml
+++ b/Documentation/devicetree/bindings/mfd/ti,j721e-system-controller.yaml
@@ -38,8 +38,8 @@ properties:
 
   ranges: true
 
-# Optional children
-
+patternProperties:
+  # Optional children
   "^serdes-ln-ctrl@[0-9a-f]+$":
 type: object
 description: |
-- 
2.25.1

Re: [PATCH net-next 0/8] net: ethernet: ti: am65-cpsw: add multi port support in mac-only mode

[Jakub Kicinski]

On Fri, 2 Oct 2020 16:04:21 -0700 Jakub Kicinski wrote:
> On Fri, 2 Oct 2020 12:56:43 +0300 Grygorii Strashko wrote:
> > On 02/10/2020 02:08, Jakub Kicinski wrote:  
> > > On Thu, 1 Oct 2020 13:52:50 +0300 Grygorii Strashko wrote:
> > >> This series adds multi-port support in mac-only mode (multi MAC mode) to 
> > >> TI
> > >> AM65x CPSW driver in preparation for enabling support for multi-port 
> > >> devices,
> > >> like Main CPSW0 on K3 J721E SoC or future CPSW3g on K3 AM64x SoC.
> > >>
> > >> The multi MAC mode is implemented by configuring every enabled port in 
> > >> "mac-only"
> > >> mode (all ingress packets are sent only to the Host port and egress 
> > >> packets
> > >> directed to target Ext. Port) and creating separate net_device for
> > >> every enabled Ext. port.
> > > 
> > > Do I get it right that you select the mode based on platform? Can the
> > > other mode still be supported on these platforms?
> > > 
> > > Is this a transition to normal DSA mode where ports always have netdevs?  
> >
> > The idea here is to start in multi mac mode by default, as we still
> > have pretty high demand for this. Then, and we are working on it, the
> > switchdev mode is going to be introduces (not DSA). The switch
> > between modes will happen by using devlink option - the approach is
> > similar to what was used for Sitara CPSW cpsw_new.c driver [1].  
> 
> What's unclear from the patches is whether the default configuration
> for already supported platforms will change?
> 
> All the patches sound like they are "in preparation for support of K3
> J721E" etc. So this is just code restructuring with no user-visible
> changes?

Another way of putting the question perhaps would be - is num_ports
always 1 for existing platforms?

Re: [PATCH v4 1/2] dt-bindings: usb: Add binding for discrete onboard USB hubs

[Doug Anderson]

Hi,

On Fri, Oct 2, 2020 at 3:28 PM Rob Herring  wrote:
>
> On Fri, Oct 2, 2020 at 12:08 PM Doug Anderson  wrote:
> >
> > Hi,
> >
> > On Wed, Sep 30, 2020 at 1:20 PM Rob Herring  wrote:
> > >
> > > > > > Datasheets from different manufacturers refer to these ICs as "USB 
> > > > > > hub
> > > > > > controller". Calling the node "usb-hub-controller" would indeed 
> > > > > > help to
> > > > > > distinguish it from the USB hub devices and represent existing 
> > > > > > hardware.
> > > > > > And the USB device could have a "hub-controller" property, which 
> > > > > > also
> > > > > > would be clearer than the current "hub" property.
> > > > >
> > > > > There aren't 2 (or 3) devices here. There's a single USB device (a
> > > > > hub) and the DT representation should reflect that.
> > > >
> > > > That's not completely true, though, is it?
> > >
> > > I was referring to the hub. I only see 1 datasheet, 1 IC and 1 block
> > > diagram... Lots of devices have more than one interface though usually
> > > not different speeds of the same thing.
> >
> > Right, there is certainly more than one way to look at it and the way
> > to look at it is based on how it's most convenient, I guess.  I mean,
> > an SoC often has 1 (very long) datasheet, 1 IC, and 1 block diagram
> > too...
> >
> > As a more similar example of single device that is listed in more than
> > one location in the device tree, we can also look at embedded SDIO
> > BT/WiFi combo cards.  This single device often provides WiFi under an
> > SDIO bus and BT under a serial / USB bus.  I'm not 100% sure there are
> > actually cases were the same board provides device tree data to both
> > at the same time, but "brcm,bcm43540-bt" is an example of providing
> > data to the Bluetooth (connected over serial port) and
> > "brcm,bcm4329-fmac" to the WiFi (connected over the SDIO bus).  Of
> > course WiFi/BT cheat in that the control logic is represented by the
> > SDIO power sequencing stuff...
>
> I figured you would mention this and it was brought up in the prior
> version. We've gotten lucky on these that the BT and WiFi are almost
> completely independent and any shared resources are easily shared
> (refcounted). I don't know if this case is the same. It seems less so
> to me. In any case, 2 independent devices is not what's been done here
> so far. The question is does representing USB2 and USB3 buses
> independently make sense, not whether just representing this hub as 2
> devices makes sense.

It feels like we have to accept that we are going to represent the USB
2 and USB 3 parts separately?  From Alan's response it sounds as if,
at least in theory, there can be different hierarchies leading up to
them.  That kind of thing seems like it'll be hard to deal with unless
we accept that the USB2 and USB3 nodes are separate, right?


> > Back to our case, though.  I guess the issue here is that we're the
> > child of more than one bus.  Let's first pretend that the i2c lines of
> > this hub are actually hooked up and establish how that would look
> > first.  Then we can think about how it looks if this same device isn't
> > hooked up via i2c.  In this case, it sounds as if you still don't want
> > the device split among two nodes.  So I guess you'd prefer something
> > like:
> >
> > i2c {
> >   usb-hub@xx {
> > reg = ;
> > compatible = "realtek,rts5411", "onboard-usb-hub";
> > vdd-supply = <&pp3300_hub>;
> > usb-devices = <&usb_controller 1>;
>
> Why would you even need this prop? What it's attached to may not be
> the host controller nor even represented in DT. You've just defined a
> 2nd way to represent USB devices in DT (there's always 2 ways: a tree
> of nodes or a 'linked list' of phandles).

I'm certainly not wedded to the above representation, so let's drop it.


> >   };
> > };
> >
> > ...and then you wouldn't have anything under the USB controller
> > itself.  Is that correct?
>
> Right, as the examples you pointed out do. They just avoid the issue
> of representing USB bus in DT which probably was not defined at the
> time at least the first one was done. It works as long as you only
> have the hub that needs special setup. If you have child devices
> hanging off the hub too, then you need to represent the USB bus
> structure.
>
> >  So even though there are existing bindings
> > saying that a USB device should be listed via VID/PID, the desire to
> > represent this as a single node overrides that, right?  (NOTE: this is
> > similar to what Matthias proposed in his response except that I've
> > added an index so that we don't need _anything_ under the controller).
> >
> > Having this primarily listed under the i2c bus makes sense because the
> > control logic for the hub is hooked up via i2c.  Having the power
> > supply associated with it also makes some amount of sense since it's a
> > control signal.  It's also convenient that i2c devices have their
> > probe called _before_ we try to detect if they're there because it's
> > common th

Re: [PATCH v2 7/9] x86: Use current USER_CS to setup correct context on vmx entry

[Gabriel Krisman Bertazi]

Sean Christopherson  writes:

> On Thu, Oct 01, 2020 at 02:52:32PM -0700, Andy Lutomirski wrote:
>> On Thu, Oct 1, 2020 at 1:59 PM Gabriel Krisman Bertazi
>>  wrote:
>> >
>> > vmx_prepare_switch_to_guest shouldn't use is_64bit_mm, which has a
>> > very specific use in uprobes.  Use the user_64bit_mode helper instead.
>> > This reduces the usage of is_64bit_mm, which is awkward, since it relies
>> > on the personality at load time, which is fine for uprobes, but doesn't
>> > seem fine here.
>> >
>> > I tested this by running VMs with 64 and 32 bits payloads from 64/32
>> > programs.
>> >
>> > Signed-off-by: Gabriel Krisman Bertazi 
>> > ---
>> >  arch/x86/kvm/vmx/vmx.c | 2 +-
>> >  1 file changed, 1 insertion(+), 1 deletion(-)
>> >
>> > diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
>> > index 7b2a068f08c1..b5aafd9e5f5d 100644
>> > --- a/arch/x86/kvm/vmx/vmx.c
>> > +++ b/arch/x86/kvm/vmx/vmx.c
>> > @@ -1172,7 +1172,7 @@ void vmx_prepare_switch_to_guest(struct kvm_vcpu 
>> > *vcpu)
>> > savesegment(es, host_state->es_sel);
>> >
>> > gs_base = cpu_kernelmode_gs_base(cpu);
>> > -   if (likely(is_64bit_mm(current->mm))) {
>> > +   if (likely(user_64bit_mode(current_pt_regs( {
>> > current_save_fsgs();
>> > fs_sel = current->thread.fsindex;
>> > gs_sel = current->thread.gsindex;
>> 
>> I disagree with this one.  This whole code path is nonsense.  Can you
>> just remove the condition entirely and use the 64-bit path
>> unconditionally?
>
> I finally came back to this one with fresh eyes.  I've read through the code
> a bajllion times and typed up half a dozen responses.  I think, finally, I
> understand what's broken.
>
> I believe your original assertion that the bug was misdiagnosed is correct
> (can't link because LKML wasn't in the loop).  I'm pretty sure your analysis
> that KVM's handling of things works mostly by coincidence is also correct.
>
> The coincidence is that "real" VMMs all use arch_prctl(), and
> do_arch_prctl_64() ensures thread.{fs,gs}base are accurate.  
> save_base_legacy()
> detects sel==0 and intentionally does nothing, knowing the the base is already
> accurate.
>
> Userspaces that don't use arch_prctl(), in the bug report case a 32-bit compat
> test, may or may not have accurate thread.{fs,gs}base values.  This is
> especially true if sel!=0 as save_base_legacy() explicitly zeros the base in
> this case, as load_seg_legacy() will restore the seg on the backend.
>
> KVM on the other hand assumes thread.{fs,gs}base are always fresh.  When that
> didn't hold true for userspace that didn't use arch_prctl(), the fix of
> detecting a !64-bit mm just so happened to work because all 64-bit VMMs use
> arch_prctl().
>
> It's tempting to just open code this and use RD{FS,GS}BASE when possible,
> i.e. avoid any guesswork.  Maybe with a module param that userspace can set
> to tell KVM it doesn't do anything fancy with FS/GS base (will userspace still
> use arch_prctl() even if FSGSABSE is available?).
>
> savesegment(fs, fs_sel);
> savesegment(gs, gs_sel);
>   if (use_current_fsgs_base) {
>   fs_base = current->thread.fsbase;
>   vmx->msr_host_kernel_gs_base = current->thread.gsbase;
>   } else if (static_cpu_has(X86_FEATURE_FSGSBASE)) {
> fs_base = rdfsbase()
> vmx->msr_host_kernel_gs_base = __rdgsbase_inactive();
> } else {
> fs_base = read_msr(MSR_FS_BASE);
> vmx->msr_host_kernel_gs_base = read_msr(MSR_KERNEL_GS_BASE);
> }
>
> I'll revisit this on Monday and run a patch by Paolo.

If this is the case, I will just drop the current patch from my series
and leave it to you.  Given that is_64bit_mm() is not going away, this
use case can be fixed separately.

-- 
Gabriel Krisman Bertazi

Re: [PATCH v2] scsi: ufs: fix missing brace warning for old compilers

[Martin K. Petersen]

Pujin,

> For older versions of gcc, the array = {0}; will cause warnings:
>
> drivers/scsi/ufs/ufshcd-crypto.c: In function 'ufshcd_crypto_keyslot_program':
> drivers/scsi/ufs/ufshcd-crypto.c:62:8: warning: missing braces around 
> initializer [-Wmissing-braces]
>   union ufs_crypto_cfg_entry cfg = { 0 };
> ^
> drivers/scsi/ufs/ufshcd-crypto.c:62:8: warning: (near initialization for 
> 'cfg.reg_val') [-Wmissing-braces]
> drivers/scsi/ufs/ufshcd-crypto.c: In function 'ufshcd_clear_keyslot':
> drivers/scsi/ufs/ufshcd-crypto.c:103:8: warning: missing braces around 
> initializer [-Wmissing-braces]
>   union ufs_crypto_cfg_entry cfg = { 0 };
> ^
> 2 warnings generated

Applied to 5.10/scsi-staging, thanks!

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH 1/3] dt-bindings: nvmem: Add qcom,sc7180-qfprom compatible string

[Evan Green]

On Fri, Oct 2, 2020 at 3:20 PM Doug Anderson  wrote:
>
> Hi,
>
> On Tue, Sep 29, 2020 at 1:58 PM Evan Green  wrote:
> >
> > Add an SoC-specific compatible string so that data can be attached
> > to it in the driver.
> >
> > Signed-off-by: Evan Green 
> > ---
> >
> >  Documentation/devicetree/bindings/nvmem/qcom,qfprom.yaml | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/Documentation/devicetree/bindings/nvmem/qcom,qfprom.yaml 
> > b/Documentation/devicetree/bindings/nvmem/qcom,qfprom.yaml
> > index 59aca6d22ff9b..b16c8e6a8c23d 100644
> > --- a/Documentation/devicetree/bindings/nvmem/qcom,qfprom.yaml
> > +++ b/Documentation/devicetree/bindings/nvmem/qcom,qfprom.yaml
> > @@ -14,7 +14,9 @@ allOf:
> >
> >  properties:
> >compatible:
> > -const: qcom,qfprom
> > +enum:
> > +  - qcom,qfprom
> > +  - qcom,sc7180-qfprom
>
> You don't want either/or.  You want both.  At the time Srinivas didn't
> see the point of having the SoC-specific compatible string here, but
> now that we have a reason for it maybe he'll be convinced?  IMO you
> essentially want:
>
> items:
>   - enum:
>   - qcom,apq8064-qfprom
>   - qcom,apq8084-qfprom
>   - qcom,msm8974-qfprom
>   - qcom,msm8916-qfprom
>   - qcom,msm8996-qfprom
>   - qcom,msm8998-qfprom
>   - qcom,qcs404-qfprom
>   - qcom,sc7180-qfprom
>   - qcom,sdm845-qfprom
>   - const: qcom,qfprom
>
> For some context:
> 

That makes sense, thanks Doug.

Srini, do you want me to go fix up all the various device trees to add
the soc-compatible string, or just sc7180? (Also, don't forget about
my other question about whether you still want the keepout stuff in
the core at the cost of added complexity).

-Evan

>
> -Doug
>
>
> >
> >reg:
> >  # If the QFPROM is read-only OS image then only the corrected region
> > --
> > 2.26.2
> >

Re: [PATCH 2/2] docs: Update RCU's hotplug requirements with a bit about design

[Joel Fernandes]

On Fri, Oct 2, 2020 at 3:34 PM Paul E. McKenney  wrote:
>
> On Tue, Sep 29, 2020 at 03:32:48PM -0400, Joel Fernandes wrote:
> > Hi Paul,
> >
> > On Tue, Sep 29, 2020 at 03:29:28PM -0400, Joel Fernandes (Google) wrote:
> > > RCU's hotplug design will help understand the requirements an RCU
> > > implementation needs to fullfill, such as dead-lock avoidance.
> > >
> > > The rcu_barrier() section of the "Hotplug CPU" section already talks
> > > about deadlocks, however the description of what else can deadlock other
> > > than rcu_barrier is rather incomplete.
> > >
> > > This commit therefore continues the section by describing how RCU's
> > > design handles CPU hotplug in a deadlock-free way.
> > >
> > > Signed-off-by: Joel Fernandes (Google) 
> > > ---
> > >  .../RCU/Design/Requirements/Requirements.rst  | 30 +--
> > >  1 file changed, 28 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/Documentation/RCU/Design/Requirements/Requirements.rst 
> > > b/Documentation/RCU/Design/Requirements/Requirements.rst
> > > index 1ae79a10a8de..e0413aa989dd 100644
> > > --- a/Documentation/RCU/Design/Requirements/Requirements.rst
> > > +++ b/Documentation/RCU/Design/Requirements/Requirements.rst
> > > @@ -1929,8 +1929,10 @@ The Linux-kernel CPU-hotplug implementation has 
> > > notifiers that are used
> > >  to allow the various kernel subsystems (including RCU) to respond
> > >  appropriately to a given CPU-hotplug operation. Most RCU operations may
> > >  be invoked from CPU-hotplug notifiers, including even synchronous
> > > -grace-period operations such as ``synchronize_rcu()`` and
> > > -``synchronize_rcu_expedited()``.
> > > +grace-period operations such as. However, the synchronous variants
> > > +(``synchronize_rcu()`` and ``synchronize_rcu_expedited()``) should not
> > > +from notifiers that execute via ``stop_machine()`` -- specifically those
> >
> > The "should not from notifiers" should be "should not be used from
> > notifiers" here. Sorry and hope you can fix it up.
>
> Thank you, and queued for further review.  How does the below look
> for a general fixup?

Looks great, thanks!

 -Joel



>
> Thanx, Paul
>
> 
>
> commit a93716177eeac726037828b28e6b1a45e828688a
> Author: Joel Fernandes (Google) 
> Date:   Tue Sep 29 15:29:28 2020 -0400
>
> docs: Update RCU's hotplug requirements with a bit about design
>
> The rcu_barrier() section of the "Hotplug CPU" section discusses
> deadlocks, however the description of deadlocks other than those involving
> rcu_barrier() is rather incomplete.
>
> This commit therefore continues the section by describing how RCU's
> design handles CPU hotplug in a deadlock-free way.
>
> Signed-off-by: Joel Fernandes (Google) 
> Signed-off-by: Paul E. McKenney 
>
> diff --git a/Documentation/RCU/Design/Requirements/Requirements.rst 
> b/Documentation/RCU/Design/Requirements/Requirements.rst
> index 1ae79a1..98557fe 100644
> --- a/Documentation/RCU/Design/Requirements/Requirements.rst
> +++ b/Documentation/RCU/Design/Requirements/Requirements.rst
> @@ -1929,16 +1929,45 @@ The Linux-kernel CPU-hotplug implementation has 
> notifiers that are used
>  to allow the various kernel subsystems (including RCU) to respond
>  appropriately to a given CPU-hotplug operation. Most RCU operations may
>  be invoked from CPU-hotplug notifiers, including even synchronous
> -grace-period operations such as ``synchronize_rcu()`` and
> -``synchronize_rcu_expedited()``.
> -
> -However, all-callback-wait operations such as ``rcu_barrier()`` are also
> -not supported, due to the fact that there are phases of CPU-hotplug
> -operations where the outgoing CPU's callbacks will not be invoked until
> -after the CPU-hotplug operation ends, which could also result in
> -deadlock. Furthermore, ``rcu_barrier()`` blocks CPU-hotplug operations
> -during its execution, which results in another type of deadlock when
> -invoked from a CPU-hotplug notifier.
> +grace-period operations such as (``synchronize_rcu()`` and
> +``synchronize_rcu_expedited()``).  However, these synchronous operations
> +do block and therefore cannot be invoked from notifiers that execute via
> +``stop_machine()``, specifically those between the ``CPUHP_AP_OFFLINE``
> +and ``CPUHP_AP_ONLINE`` states.
> +
> +In addition, all-callback-wait operations such as ``rcu_barrier()`` may
> +not be invoked from any CPU-hotplug notifier.  This restriction is due
> +to the fact that there are phases of CPU-hotplug operations where the
> +outgoing CPU's callbacks will not be invoked until after the CPU-hotplug
> +operation ends, which could also result in deadlock. Furthermore,
> +``rcu_barrier()`` blocks CPU-hotplug operations during its execution,
> +which results in another type of deadlock when invoked from a CPU-hotplug
> +notifier.
> +
> +Finally, RCU must avoid deadlocks due to interac

[PATCH][next] bnx2x: Use fallthrough pseudo-keyword

[Gustavo A. R. Silva]

Replace /* no break */ comments with the new pseudo-keyword macro
fallthrough[1].

[1] 
https://www.kernel.org/doc/html/v5.7/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-through

Signed-off-by: Gustavo A. R. Silva 
---
 drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c 
b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
index 9e258fc50a7e..28069b290862 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
@@ -6313,11 +6313,11 @@ static void bnx2x_init_internal(struct bnx2x *bp, u32 
load_code)
case FW_MSG_CODE_DRV_LOAD_COMMON:
case FW_MSG_CODE_DRV_LOAD_COMMON_CHIP:
bnx2x_init_internal_common(bp);
-   /* no break */
+   fallthrough;
 
case FW_MSG_CODE_DRV_LOAD_PORT:
/* nothing to do */
-   /* no break */
+   fallthrough;
 
case FW_MSG_CODE_DRV_LOAD_FUNCTION:
/* internal memory per function is
-- 
2.27.0

Re: [PATCH 1/1] docs: admin-guide: fdt and initrd load in EFI stub

[Atish Patra]

On Fri, Oct 2, 2020 at 1:04 PM Heinrich Schuchardt  wrote:
>
> On 10/2/20 9:21 PM, Ard Biesheuvel wrote:
> > On Fri, 2 Oct 2020 at 21:14, Heinrich Schuchardt  wrote:
> >>
> >> On 10/2/20 7:21 PM, Ard Biesheuvel wrote:
> >>> Hi Heinrich,
> >>>
> >>> Thanks for documenting this.
> >>>
> >>>
> >>> On Fri, 2 Oct 2020 at 19:11, Heinrich Schuchardt  
> >>> wrote:
> 
>  Describe how a device tree and an initial RAM disk can be passed to the 
>  EFI
>  Boot Stub.
> 
>  Signed-off-by: Heinrich Schuchardt 
>  ---
>   Documentation/admin-guide/efi-stub.rst | 35 ++
>   1 file changed, 35 insertions(+)
> 
>  diff --git a/Documentation/admin-guide/efi-stub.rst 
>  b/Documentation/admin-guide/efi-stub.rst
>  index 833edb0d0bc4..86f50a33884c 100644
>  --- a/Documentation/admin-guide/efi-stub.rst
>  +++ b/Documentation/admin-guide/efi-stub.rst
>  @@ -38,6 +38,34 @@ arch/arm/boot/zImage should be copied to the system 
>  partition, and it
>   may not need to be renamed. Similarly for arm64, arch/arm64/boot/Image
>   should be copied but not necessarily renamed.
> 
>  +Passing an initial RAM disk to the EFI Boot Stub
>  +
>  +
>  +The following means sorted by decreasing priority can be used to 
>  provide an
>  +initial RAM disk to the EFI Boot Stub:
>  +
>  +* The firmware may provide a UEFI Load File 2 Protocol. The stub will 
>  try to
>  +  load the RAM disk by calling the LoadFile() service of the protocol 
>  using
>  +  a vendor device path with the vendor GUID
>  +  5568e427-0x68fc-4f3d-ac74-ca555231cc68.
>  +* Next the EFI stub will try to load the file indicated by the 
>  "initrd=" command
>  +  line parameter.

This is only applicable if EFI_GENERIC_STUB_INITRD_CMDLINE_LOADER is enabled.
Should we specify that as well?

>  +* The prior boot stage may pass the location of the initial RAM disk 
>  via the
>  +  "linux,initrd-start" and "linux,initrd-end" properties of the 
>  "/chosen" node
>  +  of the device-tree.
>  +
> >>>
> >>> On x86, the boot_params struct is used to pass the address and size of
> >>> the initrd in memory. Maybe include that for completeness?
> >>
> >> On x86 boot_params is set in function efi_pe_entry() after loading the
> >> file indicated by the initrd= command line.
> >>
> >> boot_params is not accessible by a caller of the EFI stub but is a
> >> structure used at the interface between EFI stub and main kernel. This
> >> interface is not in the scope of the admin-guide.
> >>
> >
> >  I don't see the difference between dt for arm and boot_params for
> > x86. Both can be provided by the bootloader, and will be created from
> > scratch by the efi stub if not. They both carry the command line and
> > address and size of the initrd, and the efi stub will load  the initrd
> > and update this Information, or pass it on unmodified if the
> > bootloader already loaded the initrd into memory.
>
> "The Linux kernel user’s and administrator’s guide" is not targeted for
> developers.
>
> All I have described in this patch are interfaces between Linux and the
> prior boot stage when using the EFI stub. It does not cover how the EFI
> stub communicates with main Linux.
>
> I may already have put too much technical detail here considering the
> audience.
>
> To my knowledge boot_params is not an inbound interface parameter of the
> EFI stub.
>
> Is it of interests for administrators and users to know that the EFI
> stub calls the legacy entry point of Linux? If yes, we should point to
> the documentation of the legacy entry point for all architectures:
>
> https://www.kernel.org/doc/html/latest/x86/boot.html#bit-boot-protocol
> https://www.kernel.org/doc/html/latest/x86/boot.html#id1
> https://www.kernel.org/doc/html/latest/arm/booting.html
> https://www.kernel.org/doc/html/latest/arm64/booting.html
>
> I could not find an appropriate chapter for RISC-V in
> https://www.kernel.org/doc/html/latest/riscv/index.html.
>

Unfortunately, there is no booting document for RISC-V yet. It has
been discussed many times but no patch yet.
If you want to take a stab at it, that would be great.


> As the interface between the EFI stub and main Linux is not exposed to
> the outside world and may rightfully change without notice I suggest to
> not mention it in the admin guide.
>
> Best regards
>
> Heinrich
>
> >
> >
> >
> >> The main Linux entry point is already described in
> >> Documentation/x86/boot.rst and ./Documentation/x86/zero-page.rst.
> >>
> >> We can add Sphinx style documentation for function efi_pe_entry()
> >> mentioning that it fills in boot_params.
> >> drivers/firmware/efi/libstub/x86-stub.c then can be added to
> >> Documentation/driver-api/firmware/efi/index.rst in an x86 chapter. But
> >> these will be separate patches.
> >>
> >> Best regards
> >>
> >> Heinrich

Re: [PATCH 2/2] mm/frame-vec: use FOLL_LONGTERM

[Jason Gunthorpe]

On Fri, Oct 02, 2020 at 08:16:48PM +0200, Daniel Vetter wrote:
> On Fri, Oct 2, 2020 at 8:06 PM Jason Gunthorpe  wrote:
> > On Fri, Oct 02, 2020 at 07:53:03PM +0200, Daniel Vetter wrote:
> > > For $reasons I've stumbled over this code and I'm not sure the change
> > > to the new gup functions in 55a650c35fea ("mm/gup: frame_vector:
> > > convert get_user_pages() --> pin_user_pages()") was entirely correct.
> > >
> > > This here is used for long term buffers (not just quick I/O) like
> > > RDMA, and John notes this in his patch. But I thought the rule for
> > > these is that they need to add FOLL_LONGTERM, which John's patch
> > > didn't do.
> > >
> > > There is already a dax specific check (added in b7f0554a56f2 ("mm:
> > > fail get_vaddr_frames() for filesystem-dax mappings")), so this seems
> > > like the prudent thing to do.
> > >
> > > Signed-off-by: Daniel Vetter 
> > > Cc: Andrew Morton 
> > > Cc: John Hubbard 
> > > Cc: Jérôme Glisse 
> > > Cc: Jan Kara 
> > > Cc: Dan Williams 
> > > Cc: linux...@kvack.org
> > > Cc: linux-arm-ker...@lists.infradead.org
> > > Cc: linux-samsung-...@vger.kernel.org
> > > Cc: linux-me...@vger.kernel.org
> > > Hi all,
> > >
> > > I stumbled over this and figured typing this patch can't hurt. Really
> > > just to maybe learn a few things about how gup/pup is supposed to be
> > > used (we have a bit of that in drivers/gpu), this here isn't really
> > > ralated to anything I'm doing.
> >
> > FOLL_FORCE is a pretty big clue it should be FOLL_LONGTERM, IMHO
> 
> Since you're here ... I've noticed that ib sets FOLL_FORCE when the ib
> verb access mode indicates possible writes. I'm not really clear on
> why FOLL_WRITE isn't enough any why you need to be able to write
> through a vma that's write protected currently.

Ah, FOLL_FORCE | FOLL_WRITE means *read* confusingly enough, and the
only reason you'd want this version for read is if you are doing
longterm stuff. I wrote about this recently:

https://lore.kernel.org/linux-mm/20200928235739.gu9...@ziepe.ca/

> > Since every driver does this wrong anything that uses this is creating
> > terrifying security issues.
> >
> > IMHO this whole API should be deleted :(
> 
> Yeah that part I just tried to conveniently ignore. I guess this dates
> back to a time when ioremaps where at best fixed, and there wasn't
> anything like a gpu driver dynamically managing vram around, resulting
> in random entirely unrelated things possibly being mapped to that set
> of pfns.

No, it was always wrong. Prior to GPU like cases the lifetime of the
PTE was tied to the vma and when the vma becomes free the driver can
move the things in the PTEs to 'free'. Easy to trigger use-after-free
issues and devices like RDMA have security contexts attached to these
PTEs so it becomes a serious security bug to do something like this.

> The underlying follow_pfn is also used in other places within
> drivers/media, so this doesn't seem to be an accident, but actually
> intentional.

Looking closely, there are very few users, most *seem* pointless, but
maybe there is a crazy reason?

The sequence 
  get_vaddr_frames(); 
  frame_vector_to_pages();
  sg_alloc_table_from_pages(); 

Should be written
  pin_user_pages_fast(FOLL_LONGTERM); 
  sg_alloc_table_from_pages()

There is some 'special' code in frame_vector_to_pages() that tries to
get a struct page for things from a VM_IO or VM_PFNMAP...

Oh snap, that is *completely* broken! If the first VMA is IO|PFNMAP
then get_vaddr_frames() iterates over all VMAs in the range, of any
kind and extracts the PTEs then blindly references them! This means it
can be used to use after free normal RAM struct pages!! Gah!

Wow. Okay. That has to go.

So, I *think* we can assume there is no sane cases where
frame_vector_to_pages() succeeds but pin_user_pages() wasn't called.

That means the users here:
 - habanalabs:  Hey Oded can you fix this up?

 - gpu/exynos: Daniel can you get someone there to stop using it?

 - media/videobuf via vb2_dma_sg_get_userptr()

Should all be switched to the standard pin_user_pages sequence
above.

That leaves the only interesting places as vb2_dc_get_userptr() and
vb2_vmalloc_get_userptr() which both completely fail to follow the
REQUIRED behavior in the function's comment about checking PTEs. It
just DMA maps them. Badly broken.

Guessing this hackery is for some embedded P2P DMA transfer?

After he three places above should use pin_user_pages_fast(), then
this whole broken API should be moved into videobuf2-memops.c and a
big fat "THIS DOESN'T WORK" stuck on it.

videobuf2 should probably use P2P DMA buf for this instead.

Jason

[PATCH v2 3/3] staging: greybus: use __force when assigning __u8 value to snd_ctl_elem_type_t

[Coiby Xu]

(struct gb_audio_ctl_elem_info*)->type has the type of __u8 so there is no
concern about the byte order. __force is safe to use.

Found by sparse,

$ make C=2 drivers/staging/greybus/
drivers/staging/greybus/audio_topology.c:185:24: warning: cast to restricted 
snd_ctl_elem_type_t

Suggested-by: Alex Elder 
Signed-off-by: Coiby Xu 
---
 drivers/staging/greybus/audio_topology.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/greybus/audio_topology.c 
b/drivers/staging/greybus/audio_topology.c
index 2091031659de..662e3e8b4b63 100644
--- a/drivers/staging/greybus/audio_topology.c
+++ b/drivers/staging/greybus/audio_topology.c
@@ -182,7 +182,7 @@ static int gbcodec_mixer_ctl_info(struct snd_kcontrol 
*kcontrol,
/* update uinfo */
uinfo->access = data->access;
uinfo->count = data->vcount;
-   uinfo->type = (snd_ctl_elem_type_t)info->type;
+   uinfo->type = (__force snd_ctl_elem_type_t)info->type;
 
switch (info->type) {
case GB_AUDIO_CTL_ELEM_TYPE_BOOLEAN:
-- 
2.28.0

[PATCH v2 1/3] staging: greybus: fix warnings about endianness detected by sparse

[Coiby Xu]

This patch fix the following warnings from sparse,

$ make C=2 drivers/staging/greybus/
drivers/staging/greybus/audio_module.c:222:25: warning: incorrect type in 
assignment (different base types)
drivers/staging/greybus/audio_module.c:222:25:expected restricted __le16 
[usertype] data_cport
drivers/staging/greybus/audio_module.c:222:25:got unsigned short [usertype] 
intf_cport_id
drivers/staging/greybus/audio_topology.c:460:40: warning: restricted __le32 
degrades to integer
drivers/staging/greybus/audio_topology.c:691:41: warning: incorrect type in 
assignment (different base types)
drivers/staging/greybus/audio_topology.c:691:41:expected unsigned int access
drivers/staging/greybus/audio_topology.c:691:41:got restricted __le32 
[usertype] access
drivers/staging/greybus/audio_topology.c:746:44: warning: incorrect type in 
assignment (different base types)
drivers/staging/greybus/audio_topology.c:746:44:expected unsigned int
drivers/staging/greybus/audio_topology.c:746:44:got restricted __le32
drivers/staging/greybus/audio_topology.c:748:52: warning: incorrect type in 
assignment (different base types)
drivers/staging/greybus/audio_topology.c:748:52:expected unsigned int
drivers/staging/greybus/audio_topology.c:748:52:got restricted __le32
drivers/staging/greybus/audio_topology.c:802:42: warning: restricted __le32 
degrades to integer
drivers/staging/greybus/audio_topology.c:805:50: warning: incorrect type in 
assignment (different base types)
drivers/staging/greybus/audio_topology.c:805:50:expected restricted __le32
drivers/staging/greybus/audio_topology.c:805:50:got unsigned int
drivers/staging/greybus/audio_topology.c:814:50: warning: restricted __le32 
degrades to integer
drivers/staging/greybus/audio_topology.c:817:58: warning: incorrect type in 
assignment (different base types)
drivers/staging/greybus/audio_topology.c:817:58:expected restricted __le32
drivers/staging/greybus/audio_topology.c:817:58:got unsigned int
drivers/staging/greybus/audio_topology.c:889:25: warning: incorrect type in 
assignment (different base types)
drivers/staging/greybus/audio_topology.c:889:25:expected unsigned int access
drivers/staging/greybus/audio_topology.c:889:25:got restricted __le32 
[usertype] access

Suggested-by: Dan Carpenter 
Reviewed-by: Dan Carpenter 
Reviewed-by: Alex Elder 
Signed-off-by: Coiby Xu 
---
 drivers/staging/greybus/audio_module.c   |  6 +++---
 drivers/staging/greybus/audio_topology.c | 18 +-
 2 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/drivers/staging/greybus/audio_module.c 
b/drivers/staging/greybus/audio_module.c
index 16f60256adb2..c52c4f361b90 100644
--- a/drivers/staging/greybus/audio_module.c
+++ b/drivers/staging/greybus/audio_module.c
@@ -219,7 +219,7 @@ static int gb_audio_add_data_connection(struct 
gbaudio_module_info *gbmodule,
 
greybus_set_drvdata(bundle, gbmodule);
dai->id = 0;
-   dai->data_cport = connection->intf_cport_id;
+   dai->data_cport = cpu_to_le16(connection->intf_cport_id);
dai->connection = connection;
list_add(&dai->list, &gbmodule->data_list);
 
@@ -329,7 +329,7 @@ static int gb_audio_probe(struct gb_bundle *bundle,
if (ret) {
dev_err(dev,
"%d:Error while enabling %d:data connection\n",
-   ret, dai->data_cport);
+   ret, le16_to_cpu(dai->data_cport));
goto disable_data_connection;
}
}
@@ -451,7 +451,7 @@ static int gb_audio_resume(struct device *dev)
if (ret) {
dev_err(dev,
"%d:Error while enabling %d:data connection\n",
-   ret, dai->data_cport);
+   ret, le16_to_cpu(dai->data_cport));
return ret;
}
}
diff --git a/drivers/staging/greybus/audio_topology.c 
b/drivers/staging/greybus/audio_topology.c
index 83b38ae8908c..2091031659de 100644
--- a/drivers/staging/greybus/audio_topology.c
+++ b/drivers/staging/greybus/audio_topology.c
@@ -466,7 +466,7 @@ static int gbcodec_mixer_dapm_ctl_put(struct snd_kcontrol 
*kcontrol,
goto exit;
 
/* update ucontrol */
-   if (gbvalue.value.integer_value[0] != val) {
+   if (le32_to_cpu(gbvalue.value.integer_value[0]) != val) {
for (wi = 0; wi < wlist->num_widgets; wi++) {
widget = wlist->widgets[wi];
snd_soc_dapm_mixer_update_power(widget->dapm, kcontrol,
@@ -689,7 +689,7 @@ static int gbaudio_tplg_create_kcontrol(struct 
gbaudio_module_info *gb,
return -ENOMEM;
ctldata->ctl_id = ctl->id;
ctldata->data_cport = le16_to_cpu(ctl->data_cport);
-   ctldata->access

[PATCH v2 2/3] staging: greybus: codecs: use SNDRV_PCM_FMTBIT_S16_LE for format bitmask

[Coiby Xu]

snd_soc_pcm_stream.formats should use the bitmask SNDRV_PCM_FMTBIT_*
instead of the sequential integers SNDRV_PCM_FORMAT_* as explained by
commit e712bfca1ac1f63f622f87c2f33b57608f2a4d19
("ASoC: codecs: use SNDRV_PCM_FMTBIT_* for format bitmask").

Found by sparse,

$ make C=2 drivers/staging/greybus/
drivers/staging/greybus/audio_codec.c:691:36: warning: incorrect type in 
initializer (different base types)
drivers/staging/greybus/audio_codec.c:691:36:expected unsigned long long 
[usertype] formats
drivers/staging/greybus/audio_codec.c:691:36:got restricted 
snd_pcm_format_t [usertype]
drivers/staging/greybus/audio_codec.c:701:36: warning: incorrect type in 
initializer (different base types)
drivers/staging/greybus/audio_codec.c:701:36:expected unsigned long long 
[usertype] formats
drivers/staging/greybus/audio_codec.c:701:36:got restricted 
snd_pcm_format_t [usertype]

Reviewed-by: Alex Elder 
Signed-off-by: Coiby Xu 
---
 drivers/staging/greybus/audio_codec.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/greybus/audio_codec.c 
b/drivers/staging/greybus/audio_codec.c
index 74538f8c5fa4..494aa823e998 100644
--- a/drivers/staging/greybus/audio_codec.c
+++ b/drivers/staging/greybus/audio_codec.c
@@ -688,7 +688,7 @@ static struct snd_soc_dai_driver gbaudio_dai[] = {
.playback = {
.stream_name = "I2S 0 Playback",
.rates = SNDRV_PCM_RATE_48000,
-   .formats = SNDRV_PCM_FORMAT_S16_LE,
+   .formats = SNDRV_PCM_FMTBIT_S16_LE,
.rate_max = 48000,
.rate_min = 48000,
.channels_min = 1,
@@ -698,7 +698,7 @@ static struct snd_soc_dai_driver gbaudio_dai[] = {
.capture = {
.stream_name = "I2S 0 Capture",
.rates = SNDRV_PCM_RATE_48000,
-   .formats = SNDRV_PCM_FORMAT_S16_LE,
+   .formats = SNDRV_PCM_FMTBIT_S16_LE,
.rate_max = 48000,
.rate_min = 48000,
.channels_min = 1,
-- 
2.28.0

Re: [PATCH v2] mm: Remove src/dst mm parameter in copy_page_range()

[Jason Gunthorpe]

On Fri, Oct 02, 2020 at 03:26:47PM -0400, Peter Xu wrote:
> Both of the mm pointers are not needed after commit 7a4830c380f3 ("mm/fork:
> Pass new vma pointer into copy_page_range()").
> 
> Jason Gunthorpe also reported that the ordering of copy_page_range() is odd.
> Since working at it, reorder the parameters to be logical, by (1) always put
> the dst_* fields to be before src_* fields, and (2) keep the same type of
> parameters together.
> 
> CC: Jason Gunthorpe 
> CC: Andrew Morton 
> Reported-by: Kirill A. Shutemov 
> Signed-off-by: Peter Xu 
> ---
> v2:
> - further reorder some parameters and line format [Jason]
> ---
>  include/linux/mm.h |   4 +-
>  kernel/fork.c  |   2 +-
>  mm/memory.c| 139 -
>  3 files changed, 76 insertions(+), 69 deletions(-)

Thanks, looks more readable to me

Reviewed-by: Jason Gunthorpe 

Jason

Re: [PATCH] checkpatch: Emit a warning on embedded filenames

[Joe Perches]

On Fri, 2020-10-02 at 15:18 -0700, Andrew Morton wrote:
> On Thu, 01 Oct 2020 11:28:10 -0700 Joe Perches  wrote:
> 
> > Embedding the complete filename path inside the file
> > isn't particularly useful as often the path is moved
> > around and becomes incorrect.
> > 
> > Emit a warning when the source contains the filename.
> > 
> > ...
> > 
> > --- a/scripts/checkpatch.pl
> > +++ b/scripts/checkpatch.pl
> > @@ -3273,6 +3273,12 @@ sub process {
> > }
> > }
> >  
> > +# check for embedded filenames
> > +   if ($rawline =~ /^\+.*\Q$realfile\E/) { di
> > +   WARN("EMBEDDED_FILENAME",
> > +"It's generally not useful to have the filename in 
> > the file\n" . $herecurr);
> > +   }
> > +
> 
> I removed that " di".  Please check that I merged the correct version
> of this!

Thanks, it must have been added accidentally in my email client.

Combined, the patches are correct.

[PATCH][next] bpf: verifier: Use fallthrough pseudo-keyword

[Gustavo A. R. Silva]

Replace /* fallthrough */ comments with the new pseudo-keyword macro
fallthrough[1].

[1] 
https://www.kernel.org/doc/html/v5.7/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-through

Signed-off-by: Gustavo A. R. Silva 
---
 kernel/bpf/verifier.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index 015a1c074b6b..fcef04b80b66 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -2667,7 +2667,7 @@ static bool may_access_direct_pkt_data(struct 
bpf_verifier_env *env,
case BPF_PROG_TYPE_CGROUP_SKB:
if (t == BPF_WRITE)
return false;
-   /* fallthrough */
+   fallthrough;
 
/* Program types with direct read + write access go here! */
case BPF_PROG_TYPE_SCHED_CLS:
@@ -5432,7 +5432,7 @@ static int adjust_ptr_min_max_vals(struct 
bpf_verifier_env *env,
/* smin_val represents the known value */
if (known && smin_val == 0 && opcode == BPF_ADD)
break;
-   /* fall-through */
+   fallthrough;
case PTR_TO_PACKET_END:
case PTR_TO_SOCKET:
case PTR_TO_SOCKET_OR_NULL:
-- 
2.27.0

Re: [PATCH v3 4/7] pwm: ntxec: Add driver for PWM function in Netronix EC

[Jonathan Neuschäfer]

On Mon, Sep 28, 2020 at 10:35:46AM +0200, Uwe Kleine-König wrote:
> Hello Jonathan,
> 
> On Sun, Sep 27, 2020 at 11:10:44PM +0200, Jonathan Neuschäfer wrote:
[...]
> > > > +   if (state->enabled && duty != 0) {
> > > > +   res = regmap_write(pwm->ec->regmap, NTXEC_REG_ENABLE, 
> > > > ntxec_reg8(1));
> > > > +   if (res)
> > > > +   return res;
> > > > +
> > > > +   /* Disable the auto-off timer */
> > > > +   res = regmap_write(pwm->ec->regmap, 
> > > > NTXEC_REG_AUTO_OFF_HI, ntxec_reg8(0xff));
> > > > +   if (res)
> > > > +   return res;
> > > > +
> > > > +   return regmap_write(pwm->ec->regmap, 
> > > > NTXEC_REG_AUTO_OFF_LO, ntxec_reg8(0xff));
> > > > +   } else {
> > > > +   return regmap_write(pwm->ec->regmap, NTXEC_REG_ENABLE, 
> > > > ntxec_reg8(0));
> > > > +   }
> > > 
> > > This code is wrong for state->enabled = false.
> > 
> > Why?
> 
> Hm, I wonder the same. Probably I just misunderstood the code, sorry :-\
> 
> > > How does the PWM behave when .apply is called? Does it complete the
> > > currently running period? Can it happen that when you switch from say
> > > 
> > >   .duty_cycle = 900 * TIME_BASE_NS (0x384)
> > >   .period = 1800 * TIME_BASE_NS (0x708)
> > > 
> > > to
> > > 
> > >   .duty_cycle = 300 * TIME_BASE_NS (0x12c)
> > >   .period = 600 * TIME_BASE_NS (0x258)
> > > 
> > > that a period with
> > > 
> > >   .duty_cycle = 388 * TIME_BASE_NS (0x184)
> > >   .period = 1800 * TIME_BASE_NS (0x708)
> > >   
> > > (because only NTXEC_REG_PERIOD_HIGH was written when the new period
> > > started) or something similar is emitted?
> > 
> > Changes take effect after the low byte is written, so a result like 0x184
> > in the above example should not happen.
> > 
> > When the period and duty cycle are both changed, it temporarily results
> > in an inconsistent state:
> > 
> >  - period = 1800ns, duty cycle = 900ns
> >  - period =  600ns, duty cycle = 900ns (!)
> >  - period =  600ns, duty cycle = 300ns
> 
> Does this always happen, or only if a new cycle starts at an unlucky
> moment?

Just based on thinking about the code, the register writes setting this
intermediate state would always happen, but I don't know if the state
changes are applied in the middle of a running period, or when the new
period starts, because I can't measure the signal in good enough detail
at the moment.

> > The inconsistent state of duty cycle > period is handled gracefully by
> > the EC and it outputs a 100% duty cycle, as far as I can tell.
> 
> OK.
> 
> > I currently don't have a logic analyzer / oscilloscope to measure
> > whether we get full PWM periods, or some kind of glitch when the new
> > period starts in the middle of the last one.
> 
> You can even check this with an LED using something like:
> 
>   pwm_apply(mypwm, {.enabled = true, .duty_cycle = $big, .period = $big});
>   pwm_apply(mypwm, {.enabled = false, ... });
> 
> . If the period is completed the LED is on for $big ns, if not the LED
> is on for a timespan that is probably hardly noticable with the human
> eye.

The longest configurable period is about 8ms, so it's not long enough to
see anything. However, after writing enable=0, it can take about a
second for the PWM signal to turn off... this hardware is a bit weird.

> > > > +}
> > > > +
> > > > +static struct pwm_ops ntxec_pwm_ops = {
> > > > +   .apply = ntxec_pwm_apply,
> > > 
> > > Please implement a .get_state() callback. And enable PWM_DEBUG during
> > > your tests.
> > 
> > The device doesn't support reading back the PWM state. What should a
> > driver do in this case?
> 
> Document it as a limitation, please.

Okay.


Thanks,
Jonathan Neuschäfer


signature.asc
Description: PGP signature

Re: [PATCH 2/3] x86/cpu: Describe hybrid CPUs in cpuinfo_x86

[Ricardo Neri]

On Fri, Oct 02, 2020 at 11:03:06PM +0200, Borislav Petkov wrote:
> On Fri, Oct 02, 2020 at 02:02:31PM -0700, Ricardo Neri wrote:
> > What about patches 1 and 3? Should I resubmit the series with only
> > those?
> 
> Why would you need to resubmit? They're good to go as is, AFAICT.

Thanks for clarifying Boris. Just wanted to check if there was any
action required from me regarding patches 1 & 3.

Thanks and BR,
Ricardo

Re: [PATCH v3 5/7] rtc: New driver for RTC in Netronix embedded controller

[Jonathan Neuschäfer]

On Thu, Sep 24, 2020 at 10:40:11PM +0200, Andreas Kemnade wrote:
> On Thu, 24 Sep 2020 21:24:53 +0200
> Jonathan Neuschäfer  wrote:
[...]
> > +static struct platform_driver ntxec_rtc_driver = {
> > +   .driver = {
> > +   .name = "ntxec-rtc",
> > +   },
> > +   .probe = ntxec_rtc_probe,
> > +};
> > +module_platform_driver(ntxec_rtc_driver);
> > +
> I think module autoloading will not work without
> 
> MODULE_ALIAS("platform:ntxec-rtc");
> 
> Same for the pwm device.

Right, I forgot that. Thanks for the reminder!

Jonathan


signature.asc
Description: PGP signature

[PATCH] dt-bindings: Another round of adding missing 'additionalProperties'

[Rob Herring]

Another round of wack-a-mole. The json-schema default is additional
unknown properties are allowed, but for DT all properties should be
defined.

Cc: Thierry Reding 
Cc: Linus Walleij 
Cc: Stephen Boyd 
Cc: Shawn Guo 
Cc: Bjorn Andersson 
Cc: Baolin Wang 
Cc: Guenter Roeck 
Cc: Jonathan Cameron 
Cc: Mauro Carvalho Chehab 
Cc: Laurent Pinchart 
Cc: Lee Jones 
Cc: Ulf Hansson 
Cc: "David S. Miller" 
Cc: Bjorn Helgaas 
Cc: Vinod Koul 
Cc: Liam Girdwood 
Cc: Mark Brown 
Cc: Greg Kroah-Hartman 
Cc: Daniel Lezcano 
Cc: linux-...@vger.kernel.org
Cc: dri-de...@lists.freedesktop.org
Cc: linux-...@vger.kernel.org
Cc: linux-g...@vger.kernel.org
Cc: linux-hw...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: openipmi-develo...@lists.sourceforge.net
Cc: linux-l...@vger.kernel.org
Cc: linux-me...@vger.kernel.org
Cc: linux-rockc...@lists.infradead.org
Cc: linux-st...@st-md-mailman.stormreply.com
Cc: linux-m...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: net...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: linux...@vger.kernel.org
Cc: linux-remotep...@vger.kernel.org
Cc: linux-ser...@vger.kernel.org
Cc: alsa-de...@alsa-project.org
Cc: linux-...@vger.kernel.org
Signed-off-by: Rob Herring 
---

I'll take this thru the DT tree.

 .../arm/bcm/raspberrypi,bcm2835-firmware.yaml |  2 ++
 .../arm/mediatek/mediatek,pericfg.yaml|  2 ++
 .../devicetree/bindings/arm/pmu.yaml  |  2 ++
 .../devicetree/bindings/arm/primecell.yaml|  3 +++
 .../bindings/arm/samsung/sysreg.yaml  |  2 ++
 .../arm/tegra/nvidia,tegra20-pmc.yaml |  2 ++
 .../bindings/bus/mti,mips-cdmm.yaml   |  2 ++
 .../bus/socionext,uniphier-system-bus.yaml|  7 +++
 .../bindings/clock/arm,syscon-icst.yaml   |  2 ++
 .../bindings/clock/idt,versaclock5.yaml   | 20 ++-
 .../bindings/clock/imx6q-clock.yaml   |  2 ++
 .../bindings/clock/imx6sl-clock.yaml  |  2 ++
 .../bindings/clock/imx6sll-clock.yaml |  2 ++
 .../bindings/clock/imx6sx-clock.yaml  |  2 ++
 .../bindings/clock/imx6ul-clock.yaml  |  2 ++
 .../bindings/clock/intel,cgu-lgm.yaml |  2 ++
 .../bindings/clock/qcom,gcc-sm8250.yaml   |  2 ++
 .../bindings/clock/sprd,sc9863a-clk.yaml  |  2 ++
 .../bindings/clock/ti,am654-ehrpwm-tbclk.yaml |  2 ++
 .../bindings/display/bridge/ite,it6505.yaml   |  5 +
 .../bindings/display/bridge/lvds-codec.yaml   |  3 +++
 .../devicetree/bindings/display/msm/gmu.yaml  |  2 ++
 .../devicetree/bindings/edac/dmc-520.yaml |  2 ++
 .../devicetree/bindings/fsi/ibm,fsi2spi.yaml  |  2 ++
 .../gpio/socionext,uniphier-gpio.yaml |  2 ++
 .../bindings/hwmon/adi,axi-fan-control.yaml   |  2 ++
 .../devicetree/bindings/hwmon/adt7475.yaml|  2 ++
 .../bindings/iio/accel/kionix,kxsd9.yaml  |  4 
 .../bindings/iio/adc/maxim,max1238.yaml   |  2 ++
 .../bindings/iio/adc/maxim,max1363.yaml   |  2 ++
 .../bindings/iio/adc/qcom,spmi-vadc.yaml  |  4 
 .../bindings/iio/adc/samsung,exynos-adc.yaml  |  2 ++
 .../bindings/iio/adc/ti,ads8688.yaml  |  4 
 .../bindings/iio/amplifiers/adi,hmc425a.yaml  |  2 ++
 .../bindings/iio/imu/invensense,icm42600.yaml |  6 ++
 .../bindings/iio/light/amstaos,tsl2563.yaml   |  2 ++
 .../bindings/iio/light/dynaimage,al3010.yaml  |  2 ++
 .../bindings/iio/light/dynaimage,al3320a.yaml |  2 ++
 .../bindings/iio/light/sharp,gp2ap002.yaml|  2 ++
 .../iio/magnetometer/asahi-kasei,ak8975.yaml  |  2 ++
 .../iio/proximity/vishay,vcnl3020.yaml|  2 ++
 .../interrupt-controller/ingenic,intc.yaml|  2 ++
 .../loongson,pch-msi.yaml |  2 ++
 .../loongson,pch-pic.yaml |  2 ++
 .../devicetree/bindings/ipmi/ipmi-smic.yaml   |  2 ++
 .../devicetree/bindings/leds/leds-lp55xx.yaml |  8 
 .../bindings/media/i2c/chrontel,ch7322.yaml   |  2 ++
 .../bindings/media/i2c/imi,rdacm2x-gmsl.yaml  |  2 ++
 .../bindings/media/nxp,imx8mq-vpu.yaml|  2 ++
 .../bindings/media/qcom,msm8916-venus.yaml|  2 ++
 .../bindings/media/qcom,msm8996-venus.yaml|  2 ++
 .../bindings/media/qcom,sc7180-venus.yaml |  2 ++
 .../bindings/media/qcom,sdm845-venus-v2.yaml  |  2 ++
 .../bindings/media/qcom,sdm845-venus.yaml |  2 ++
 .../bindings/memory-controllers/fsl/mmdc.yaml |  2 ++
 .../memory-controllers/st,stm32-fmc2-ebi.yaml |  2 ++
 .../bindings/mfd/gateworks-gsc.yaml   |  2 ++
 .../bindings/mfd/xylon,logicvc.yaml   | 14 +++--
 .../bindings/mips/ingenic/ingenic,cpu.yaml|  6 --
 .../bindings/mips/loongson/rs780e-acpi.yaml   |  2 ++
 .../bindings/mmc/mmc-pwrseq-emmc.yaml |  2 ++
 .../bindings/mmc/mmc-pwrseq-sd8787.yaml   |  2 ++
 .../bindings/mmc/mmc-pwrseq-simple.yaml   |  2 ++
 .../devicetree/bindings/net/qcom,ipa.yaml |  2 ++
 .../bindings/net/realtek-bluetooth.yaml   |  4 +++-
 .../net/wireless/microchip,wilc1000.yaml  |  4 
 .../devicetree/bindings/pci/rcar-pci-ep.yaml  |  2 ++
 .../phy/a

[PATCH v5 1/4] dt-bindings: remoteproc: Add bindings for R5F subsystem on TI K3 SoCs

[Suman Anna]

The Texas Instruments K3 family of SoCs have one or more dual-core
Arm Cortex R5F processor subsystems/clusters (R5FSS). The clusters
can be split between multiple voltage domains as well. Add the device
tree bindings document for these R5F subsystem devices. These R5F
processors do not have an MMU, and so require fixed memory carveout
regions matching the firmware image addresses. The nodes require more
than one memory region, with the first memory region used for DMA
allocations at runtime. The remaining memory regions are reserved
and are used for the loading and running of the R5F remote processors.
The R5F processors can also optionally use any internal on-chip SRAM
memories either for executing code or using it as fast-access data.

The added example illustrates the DT nodes for the single R5FSS device
present on K3 AM65x family of SoCs.

Signed-off-by: Suman Anna 
---
v5: Updated compatible in example to fix warnings against linux-next
v4: https://patchwork.kernel.org/patch/11763805/ 
 - Fixed whitespace indentation (added one extra space) on required list
v3: https://patchwork.kernel.org/patch/11679331/
 - Replaced ti,k3-sci-proc.yaml references with the new ti,k3-sci-common.yaml
 - Updated required list to include the three ti,sci properties
v2: https://patchwork.kernel.org/patch/11632997/
v1: https://patchwork.kernel.org/patch/11456381/

 .../bindings/remoteproc/ti,k3-r5f-rproc.yaml  | 281 ++
 1 file changed, 281 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/remoteproc/ti,k3-r5f-rproc.yaml

diff --git a/Documentation/devicetree/bindings/remoteproc/ti,k3-r5f-rproc.yaml 
b/Documentation/devicetree/bindings/remoteproc/ti,k3-r5f-rproc.yaml
new file mode 100644
index ..4069f0f5e8fa
--- /dev/null
+++ b/Documentation/devicetree/bindings/remoteproc/ti,k3-r5f-rproc.yaml
@@ -0,0 +1,281 @@
+# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/remoteproc/ti,k3-r5f-rproc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI K3 R5F processor subsystems
+
+maintainers:
+  - Suman Anna 
+
+description: |
+  The TI K3 family of SoCs usually have one or more dual-core Arm Cortex R5F
+  processor subsystems/clusters (R5FSS). The dual core cluster can be used
+  either in a LockStep mode providing safety/fault tolerance features or in a
+  Split mode providing two individual compute cores for doubling the compute
+  capacity. These are used together with other processors present on the SoC
+  to achieve various system level goals.
+
+  Each Dual-Core R5F sub-system is represented as a single DTS node
+  representing the cluster, with a pair of child DT nodes representing
+  the individual R5F cores. Each node has a number of required or optional
+  properties that enable the OS running on the host processor to perform
+  the device management of the remote processor and to communicate with the
+  remote processor.
+
+properties:
+  $nodename:
+pattern: "^r5fss(@.*)?"
+
+  compatible:
+enum:
+  - ti,am654-r5fss
+  - ti,j721e-r5fss
+
+  power-domains:
+description: |
+  Should contain a phandle to a PM domain provider node and an args
+  specifier containing the R5FSS device id value.
+maxItems: 1
+
+  "#address-cells":
+const: 1
+
+  "#size-cells":
+const: 1
+
+  ranges:
+description: |
+  Standard ranges definition providing address translations for
+  local R5F TCM address spaces to bus addresses.
+
+# Optional properties:
+# 
+
+  ti,cluster-mode:
+$ref: /schemas/types.yaml#/definitions/uint32
+enum: [0, 1]
+description: |
+  Configuration Mode for the Dual R5F cores within the R5F cluster.
+  Should be either a value of 1 (LockStep mode) or 0 (Split mode),
+  default is LockStep mode if omitted.
+
+# R5F Processor Child Nodes:
+# ==
+
+patternProperties:
+  "^r5f@[a-f0-9]+$":
+type: object
+description: |
+  The R5F Sub-System device node should define two R5F child nodes, each
+  node representing a TI instantiation of the Arm Cortex R5F core. There
+  are some specific integration differences for the IP like the usage of
+  a Region Address Translator (RAT) for translating the larger SoC bus
+  addresses into a 32-bit address space for the processor.
+
+  Each R5F core has an associated 64 KB of Tightly-Coupled Memory (TCM)
+  internal memories split between two banks - TCMA and TCMB (further
+  interleaved into two banks TCMB0 and TCMB1). These memories (also called
+  ATCM and BTCM) provide read/write performance on par with the core's L1
+  caches. Each of the TCMs can be enabled or disabled independently and
+  either of them can be configured to appear at that R5F's address 0x0.
+
+  The cores do not use an MMU, but has a Region Address Translater
+  (RAT) module that is accessible only from the R5Fs fo

[PATCH v5 3/4] remoteproc: k3-r5: Initialize TCM memories for ECC

[Suman Anna]

The R5F processors on K3 SoCs all have two TCMs (ATCM and BTCM) that
support 32-bit ECC. The TCMs are typically loaded with some boot-up
code to initialize the R5 MPUs to further execute code out of DDR.
The ECC for the TCMs is enabled by default on K3 SoCs due to internal
default tie-off values, but the TCM memories are not initialized on
device power up. Any read access without the corresponding TCM memory
location initialized will generate an ECC error, and any such access
from a A72 or A53 core will trigger a SError.

So, zero initialize both the TCM memories before loading any firmware
onto a R5F in remoteproc mode. Any R5F booted from U-Boot/SPL would
require a similar initialization in the bootloader. Note that both
the TCMs are initialized unconditionally as the TCM enable config bits
only manage the access and visibility from R5.

Signed-off-by: Suman Anna 
Reviewed-by: Mathieu Poirier 
---
v5: No changes
v4: No changes
v3: https://patchwork.kernel.org/patch/11679335/
 - No code changes, picked up tags
v2: https://patchwork.kernel.org/patch/11632989/
v1: https://patchwork.kernel.org/patch/11456371/

 drivers/remoteproc/ti_k3_r5_remoteproc.c | 17 +++--
 1 file changed, 15 insertions(+), 2 deletions(-)

diff --git a/drivers/remoteproc/ti_k3_r5_remoteproc.c 
b/drivers/remoteproc/ti_k3_r5_remoteproc.c
index 15e52ea67bbe..a6b395ab47b6 100644
--- a/drivers/remoteproc/ti_k3_r5_remoteproc.c
+++ b/drivers/remoteproc/ti_k3_r5_remoteproc.c
@@ -362,11 +362,24 @@ static int k3_r5_rproc_prepare(struct rproc *rproc)
 
ret = (cluster->mode == CLUSTER_MODE_LOCKSTEP) ?
k3_r5_lockstep_release(cluster) : k3_r5_split_release(core);
-   if (ret)
+   if (ret) {
dev_err(dev, "unable to enable cores for TCM loading, ret = 
%d\n",
ret);
+   return ret;
+   }
 
-   return ret;
+   /*
+* Zero out both TCMs unconditionally (access from v8 Arm core is not
+* affected by ATCM & BTCM enable configuration values) so that ECC
+* can be effective on all TCM addresses.
+*/
+   dev_dbg(dev, "zeroing out ATCM memory\n");
+   memset(core->mem[0].cpu_addr, 0x00, core->mem[0].size);
+
+   dev_dbg(dev, "zeroing out BTCM memory\n");
+   memset(core->mem[1].cpu_addr, 0x00, core->mem[1].size);
+
+   return 0;
 }
 
 /*
-- 
2.28.0

[PATCH v5 2/4] remoteproc: k3-r5: Add a remoteproc driver for R5F subsystem

[Suman Anna]

The TI K3 family of SoCs typically have one or more dual-core Arm Cortex
R5F processor clusters/subsystems (R5FSS). This R5F subsystem/cluster
can be configured at boot time to be either run in a LockStep mode or in
an Asymmetric Multi Processing (AMP) fashion in Split-mode. This subsystem
has 64 KB each Tightly-Coupled Memory (TCM) internal memories for each
core split between two banks - TCMA and TCMB (further interleaved into
two banks). The subsystem does not have an MMU, but has a Region Address
Translater (RAT) module that is accessible only from the R5Fs for providing
translations between 32-bit CPU addresses into larger system bus addresses.

Add a remoteproc driver to support this subsystem to be able to load and
boot the R5F cores primarily in LockStep mode. The code also includes the
base support for Split mode. Error Recovery and Power Management features
are not currently supported. Loading support includes the internal TCMs
and DDR. RAT support is left for a future patch, and as such the reserved
memory carveout regions are all expected to be using memory regions within
the first 2 GB.

The R5F remote processors do not have an MMU, and so require fixed memory
carveout regions matching the firmware image addresses. Support for this
is provided by mandating multiple memory regions to be attached to the
remoteproc device. The first memory region will be used to serve as the
DMA pool for all dynamic allocations like the vrings and vring buffers.
The remaining memory regions are mapped into the kernel at device probe
time, and are used to provide address translations for firmware image
segments without the need for any RSC_CARVEOUT entries. Any firmware
image using memory outside of the supplied reserved memory carveout
regions will be errored out.

The R5F processors on TI K3 SoCs require a specific sequence for booting
and shutting down the processors. This sequence is also dependent on the
mode (LockStep or Split) the R5F cluster is configured for. The R5F cores
have a Memory Protection Unit (MPU) that has a default configuration that
does not allow the cores to run out of DDR out of reset. This is resolved
by using the TCMs for boot-strapping code that applies the appropriate
executable permissions on desired DDR memory. The loading into the TCMs
requires that the resets be released first with the cores in halted state.
The Power Sleep Controller (PSC) module on K3 SoCs requires that the cores
be in WFI/WFE states with no active bus transactions before the cores can
be put back into reset. Support for this is provided by using the newly
introduced .prepare() and .unprepare() ops in the remoteproc core. The
.prepare() ops is invoked before any loading, and the .unprepare() ops
is invoked after the remoteproc resource cleanup. The R5F core resets
are deasserted in .prepare() and asserted in .unprepare(), and the cores
themselves are started and halted in .start() and .stop() ops. This
ensures symmetric usage and allows the R5F cores state machine to be
maintained properly between using the sysfs 'state' variable, bind/unbind
and regular module load/unload flows.

The subsystem is represented as a single remoteproc in LockStep mode, and
as two remoteprocs in Split mode. The driver uses various TI-SCI interfaces
to talk to the System Controller (DMSC) for managing configuration, power
and reset management of these cores. IPC between the A53 cores and the R5
cores is supported through the virtio rpmsg stack using shared memory and
OMAP Mailboxes.

The AM65x SoCs typically have a single R5FSS in the MCU voltage domain. The
J721E SoCs uses a slightly revised IP and typically have three R5FSSs, with
one cluster present within the MCU voltage domain (MCU_R5FSS0), and the
remaining two clusters present in the MAIN voltage domain (MAIN_R5FSS0 and
MAIN_R5FSS1). The integration of these clusters on J721E SoC is also
slightly different in that these IPs do support an actual local reset line,
while they are a no-op on AM65x SoCs.

Signed-off-by: Suman Anna 
Reviewed-by: Mathieu Poirier 
---
v5: No changes
v4: https://patchwork.kernel.org/patch/11763795/
 - Fixed error check and return code around devm_ioremap_wc in
   k3_r5_core_of_get_internal_memories() function
v3: https://patchwork.kernel.org/patch/11679333/
 - Addressed the last few minor comments from Mathieu
 - Removed the ti_sci_protocol.h header inclusion
 - Fixed the error checks on devm_reset_control_get_exclusive()
 - Removed the unnecessary cpu_addr check in failure path in
   k3_r5_reserved_mem_init()
 - Replaced http with http
v2: https://patchwork.kernel.org/patch/11632995/
v1: https://patchwork.kernel.org/patch/11456375/

 drivers/remoteproc/Kconfig   |   13 +
 drivers/remoteproc/Makefile  |1 +
 drivers/remoteproc/ti_k3_r5_remoteproc.c | 1303 ++
 3 files changed, 1317 insertions(+)
 create mode 100644 drivers/remoteproc/ti_k3_r5_remoteproc.c

diff --git a/drivers/remoteproc/Kconfig b/drivers/re

[PATCH v5 0/4] TI K3 R5F remoteproc support

[Suman Anna]

Hi Bjorn,

The following is v5 of the TI K3 R5F remoteproc driver series supporting all
the R5F processor clusters/subsystems on TI AM65x and J721E SoCs. Please
see the v1 cover-letter [1] for the features supported on these R5F processors.

This series has only 1 line change w.r.t v4 version [4], the example in 
dt-bindings is updated to fix couple of dt_binding_check warnings when 
applied against the latest linux-next version due to a base TI binding
conversion to YAML.

Rob has left it to your discretion w.r.t the bindings, so appreciate it
if you can review the binding and pick up the series for 5.10.

regards
Suman

[1] R5F v1: https://patchwork.kernel.org/cover/11456367/
[2] R5F v2: https://patchwork.kernel.org/cover/11632993/
[3] R5F v3: https://patchwork.kernel.org/cover/11679327/
[4] R5F v4: https://patchwork.kernel.org/cover/11763783/

Suman Anna (4):
  dt-bindings: remoteproc: Add bindings for R5F subsystem on TI K3 SoCs
  remoteproc: k3-r5: Add a remoteproc driver for R5F subsystem
  remoteproc: k3-r5: Initialize TCM memories for ECC
  remoteproc: k3-r5: Add loading support for on-chip SRAM regions

 .../bindings/remoteproc/ti,k3-r5f-rproc.yaml  |  281 
 drivers/remoteproc/Kconfig|   13 +
 drivers/remoteproc/Makefile   |1 +
 drivers/remoteproc/ti_k3_r5_remoteproc.c  | 1395 +
 4 files changed, 1690 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/remoteproc/ti,k3-r5f-rproc.yaml
 create mode 100644 drivers/remoteproc/ti_k3_r5_remoteproc.c

-- 
2.28.0

[PATCH v5 4/4] remoteproc: k3-r5: Add loading support for on-chip SRAM regions

[Suman Anna]

The K3 SoCs has various internal on-chip SRAM memories like the SRAM
within the MCU domain or the shared MSMC RAM within NavSS that can be
used for multiple purposes. One such purpose is to have the R5F cores
use a portion of such on-chip SRAM for fast-access data or to directly
execute code.

Add support to the K3 R5 remoteproc driver to parse and support
loading into such memories. The SRAM regions need to be mapped as
normal non-cacheable memory to avoid kernel crashes when the remoteproc
loader code uses the Arm64 memset library function (the "DC ZVA"
instruction throws a alignment fault on device type memory).

These SRAM regions are completely optional as not all firmware images
require these memories, and any such memory has to be reserved as such
in the DTS files.

Signed-off-by: Suman Anna 
Reviewed-by: Mathieu Poirier 
---
v5: No changes
v4: No changes
v3: https://patchwork.kernel.org/patch/11679329/
 - No code changes, picked up review tags
v2: https://patchwork.kernel.org/patch/11632991/
v1: https://patchwork.kernel.org/patch/11456373/

 drivers/remoteproc/ti_k3_r5_remoteproc.c | 79 
 1 file changed, 79 insertions(+)

diff --git a/drivers/remoteproc/ti_k3_r5_remoteproc.c 
b/drivers/remoteproc/ti_k3_r5_remoteproc.c
index a6b395ab47b6..d9307935441d 100644
--- a/drivers/remoteproc/ti_k3_r5_remoteproc.c
+++ b/drivers/remoteproc/ti_k3_r5_remoteproc.c
@@ -85,7 +85,9 @@ struct k3_r5_cluster {
  * @dev: cached device pointer
  * @rproc: rproc handle representing this core
  * @mem: internal memory regions data
+ * @sram: on-chip SRAM memory regions data
  * @num_mems: number of internal memory regions
+ * @num_sram: number of on-chip SRAM memory regions
  * @reset: reset control handle
  * @tsp: TI-SCI processor control handle
  * @ti_sci: TI-SCI handle
@@ -99,7 +101,9 @@ struct k3_r5_core {
struct device *dev;
struct rproc *rproc;
struct k3_r5_mem *mem;
+   struct k3_r5_mem *sram;
int num_mems;
+   int num_sram;
struct reset_control *reset;
struct ti_sci_proc *tsp;
const struct ti_sci_handle *ti_sci;
@@ -587,6 +591,18 @@ static void *k3_r5_rproc_da_to_va(struct rproc *rproc, u64 
da, size_t len)
}
}
 
+   /* handle any SRAM regions using SoC-view addresses */
+   for (i = 0; i < core->num_sram; i++) {
+   dev_addr = core->sram[i].dev_addr;
+   size = core->sram[i].size;
+
+   if (da >= dev_addr && ((da + len) <= (dev_addr + size))) {
+   offset = da - dev_addr;
+   va = core->sram[i].cpu_addr + offset;
+   return (__force void *)va;
+   }
+   }
+
/* handle static DDR reserved memory regions */
for (i = 0; i < kproc->num_rmems; i++) {
dev_addr = kproc->rmem[i].dev_addr;
@@ -1027,6 +1043,63 @@ static int k3_r5_core_of_get_internal_memories(struct 
platform_device *pdev,
return 0;
 }
 
+static int k3_r5_core_of_get_sram_memories(struct platform_device *pdev,
+  struct k3_r5_core *core)
+{
+   struct device_node *np = pdev->dev.of_node;
+   struct device *dev = &pdev->dev;
+   struct device_node *sram_np;
+   struct resource res;
+   int num_sram;
+   int i, ret;
+
+   num_sram = of_property_count_elems_of_size(np, "sram", sizeof(phandle));
+   if (num_sram <= 0) {
+   dev_dbg(dev, "device does not use reserved on-chip memories, 
num_sram = %d\n",
+   num_sram);
+   return 0;
+   }
+
+   core->sram = devm_kcalloc(dev, num_sram, sizeof(*core->sram), 
GFP_KERNEL);
+   if (!core->sram)
+   return -ENOMEM;
+
+   for (i = 0; i < num_sram; i++) {
+   sram_np = of_parse_phandle(np, "sram", i);
+   if (!sram_np)
+   return -EINVAL;
+
+   if (!of_device_is_available(sram_np)) {
+   of_node_put(sram_np);
+   return -EINVAL;
+   }
+
+   ret = of_address_to_resource(sram_np, 0, &res);
+   of_node_put(sram_np);
+   if (ret)
+   return -EINVAL;
+
+   core->sram[i].bus_addr = res.start;
+   core->sram[i].dev_addr = res.start;
+   core->sram[i].size = resource_size(&res);
+   core->sram[i].cpu_addr = devm_ioremap_wc(dev, res.start,
+resource_size(&res));
+   if (!core->sram[i].cpu_addr) {
+   dev_err(dev, "failed to parse and map sram%d memory at 
%pad\n",
+   i, &res.start);
+   return -ENOMEM;
+   }
+
+   dev_dbg(dev, "memory sram%d: bus addr %pa size 0x%zx va %pK da 
0x%x\n",
+   i, &core->sram[i].bus_addr,
+ 

Re: drivers/block/rbd.c: atomic_inc_return_safe() & atomic_dec_return_safe()

[Jens Axboe]

On 10/2/20 4:34 PM, Shuah Khan wrote:
> All,
> 
> I came across these atomic_inc_return_safe() & atomic_dec_return_safe()
> functions that hold the counters at safe values.
> 
> atomic_inc_return_safe()
> 
> If the counter is already 0 it will not be incremented.
> If the counter is already at its maximum value returns
> -EINVAL without updating it.
> 
> atomic_dec_return_safe()
> 
> Decrement the counter.  Return the resulting value, or -EINVAL
> 
> These two routines are static and only used in rbd.c.
> 
> Can these become part of atomic_t ops?

I think you just want to use refcount_t for this use case. They
have safe guards for under/overflow.

-- 
Jens Axboe

[PATCH v10 0/4] Introduce the for_each_set_clump macro

[Syed Nayyar Waris]

Hello Linus,

Since this patchset primarily affects GPIO drivers, would you like
to pick it up through your GPIO tree?

This patchset introduces a new generic version of for_each_set_clump. 
The previous version of for_each_set_clump8 used a fixed size 8-bit
clump, but the new generic version can work with clump of any size but
less than or equal to BITS_PER_LONG. The patchset utilizes the new macro 
in several GPIO drivers.

The earlier 8-bit for_each_set_clump8 facilitated a
for-loop syntax that iterates over a memory region entire groups of set
bits at a time.

For example, suppose you would like to iterate over a 32-bit integer 8
bits at a time, skipping over 8-bit groups with no set bit, where
 represents the current 8-bit group:

Example:1010   00110011
First loop: 1010   
Second loop:1010   00110011
Third loop:    00110011

Each iteration of the loop returns the next 8-bit group that has at
least one set bit.

But with the new for_each_set_clump the clump size can be different from 8 bits.
Moreover, the clump can be split at word boundary in situations where word 
size is not multiple of clump size. Following are examples showing the working 
of new macro for clump sizes of 24 bits and 6 bits.

Example 1:
clump size: 24 bits, Number of clumps (or ports): 10
bitmap stores the bit information from where successive clumps are retrieved.

 /* bitmap memory region */
0x00aaff00;  /* Most significant bits */
0xaaff;
0x00aa00aa;
0xabcdeffedcba;  /* Least significant bits */

Different iterations of for_each_set_clump:-
'offset' is the bit position and 'clump' is the 24 bit clump from the
above bitmap.
Iteration first:offset: 0 clump: 0xfedcba
Iteration second:   offset: 24 clump: 0xabcdef
Iteration third:offset: 48 clump: 0xaa
Iteration fourth:   offset: 96 clump: 0xaa
Iteration fifth:offset: 144 clump: 0xff
Iteration sixth:offset: 168 clump: 0xaa
Iteration seventh:  offset: 216 clump: 0xff
Loop breaks because in the end the remaining bits (0x00aa) size was less
than clump size of 24 bits.

In above example it can be seen that in iteration third, the 24 bit clump
that was retrieved was split between bitmap[0] and bitmap[1]. This example 
also shows that 24 bit zeroes if present in between, were skipped (preserving
the previous for_each_set_macro8 behaviour). 

Example 2:
clump size = 6 bits, Number of clumps (or ports) = 3.

 /* bitmap memory region */
0x00aaff00;  /* Most significant bits */
0xaaff;
0x0f00;
0x0ac0;  /* Least significant bits */

Different iterations of for_each_set_clump:
'offset' is the bit position and 'clump' is the 6 bit clump from the
above bitmap.
Iteration first:offset: 6 clump: 0x2b
Loop breaks because 6 * 3 = 18 bits traversed in bitmap.
Here 6 * 3 is clump size * no. of clumps.

Changes in v10:
 - Patchset based on v5.9-rc1.

Changes in v9:
 - [Patch 4/4]: Remove looping of 'for_each_set_clump' and instead process two 
   halves of a 64-bit bitmap separately or individually. Use normal spin_lock 
   call for second inner lock. And take the spin_lock_init call outside the 'if'
   condition in the probe function of driver.

Changes in v8:
 - [Patch 2/4]: Minor change: Use '__initdata' for correct section mismatch
   in 'clump_test_data' array.

Changes in v7:
 - [Patch 2/4]: Minor changes: Use macro 'DECLARE_BITMAP()' and split 'struct'
   definition and test data.

Changes in v6:
 - [Patch 2/4]: Make 'for loop' inside test_for_each_set_clump more
   succinct.

Changes in v5:
 - [Patch 4/4]: Minor change: Hardcode value for better code readability.

Changes in v4:
 - [Patch 2/4]: Use 'for' loop in test function of for_each_set_clump.
 - [Patch 3/4]: Minor change: Inline value for better code readability.
 - [Patch 4/4]: Minor change: Inline value for better code readability.

Changes in v3:
 - [Patch 3/4]: Change datatype of some variables from u64 to unsigned long
   in function thunderx_gpio_set_multiple.

CHanges in v2:
 - [Patch 2/4]: Unify different tests for 'for_each_set_clump'. Pass test data 
as
   function parameters.
 - [Patch 2/4]: Remove unnecessary bitmap_zero calls.

Syed Nayyar Waris (4):
  bitops: Introduce the for_each_set_clump macro
  lib/test_bitmap.c: Add for_each_set_clump test cases
  gpio: thunderx: Utilize for_each_set_clump macro
  gpio: xilinx: Utilize generic bitmap_get_value and _set_value

 drivers/gpio/gpio-thunderx.c  |  11 ++-
 drivers/gpio/gpio-xilinx.c|  66 +++---
 include/asm-generic/bitops/find.h |  19 
 include/linux/bitmap.h|  61 +
 include/linux/bitops.h|  13 +++
 lib/find_bit.c|  14 +++
 lib/test_bitmap.c | 

[PATCH v10 1/4] bitops: Introduce the for_each_set_clump macro

[Syed Nayyar Waris]

This macro iterates for each group of bits (clump) with set bits,
within a bitmap memory region. For each iteration, "start" is set to
the bit offset of the found clump, while the respective clump value is
stored to the location pointed by "clump". Additionally, the
bitmap_get_value and bitmap_set_value functions are introduced to
respectively get and set a value of n-bits in a bitmap memory region.
The n-bits can have any size less than or equal to BITS_PER_LONG.
Moreover, during setting value of n-bit in bitmap, if a situation arise
that the width of next n-bit is exceeding the word boundary, then it
will divide itself such that some portion of it is stored in that word,
while the remaining portion is stored in the next higher word. Similar
situation occurs while retrieving value of n-bits from bitmap.

Cc: Arnd Bergmann 
Signed-off-by: Syed Nayyar Waris 
Reviewed-by: Andy Shevchenko 
Signed-off-by: William Breathitt Gray 
---
Changes in v10:
 - No change.

Changes in v9:
 - No change.

Changes in v8:
 - No change.

Changes in v7:
 - No change.

Changes in v6:
 - No change.

Changes in v5:
 - No change.

Changes in v4:
 - No change.

Changes in v3:
 - No change.

Changes in v2:
 - No change.

 include/asm-generic/bitops/find.h | 19 ++
 include/linux/bitmap.h| 61 +++
 include/linux/bitops.h| 13 +++
 lib/find_bit.c| 14 +++
 4 files changed, 107 insertions(+)

diff --git a/include/asm-generic/bitops/find.h 
b/include/asm-generic/bitops/find.h
index 9fdf21302fdf..4e6600759455 100644
--- a/include/asm-generic/bitops/find.h
+++ b/include/asm-generic/bitops/find.h
@@ -97,4 +97,23 @@ extern unsigned long find_next_clump8(unsigned long *clump,
 #define find_first_clump8(clump, bits, size) \
find_next_clump8((clump), (bits), (size), 0)
 
+/**
+ * find_next_clump - find next clump with set bits in a memory region
+ * @clump: location to store copy of found clump
+ * @addr: address to base the search on
+ * @size: bitmap size in number of bits
+ * @offset: bit offset at which to start searching
+ * @clump_size: clump size in bits
+ *
+ * Returns the bit offset for the next set clump; the found clump value is
+ * copied to the location pointed by @clump. If no bits are set, returns @size.
+ */
+extern unsigned long find_next_clump(unsigned long *clump,
+ const unsigned long *addr,
+ unsigned long size, unsigned long offset,
+ unsigned long clump_size);
+
+#define find_first_clump(clump, bits, size, clump_size) \
+   find_next_clump((clump), (bits), (size), 0, (clump_size))
+
 #endif /*_ASM_GENERIC_BITOPS_FIND_H_ */
diff --git a/include/linux/bitmap.h b/include/linux/bitmap.h
index 99058eb81042..7ab2c65fc964 100644
--- a/include/linux/bitmap.h
+++ b/include/linux/bitmap.h
@@ -75,7 +75,11 @@
  *  bitmap_from_arr32(dst, buf, nbits)  Copy nbits from u32[] buf to 
dst
  *  bitmap_to_arr32(buf, src, nbits)Copy nbits from buf to u32[] 
dst
  *  bitmap_get_value8(map, start)   Get 8bit value from map at 
start
+ *  bitmap_get_value(map, start, nbits)Get bit value of size
+ * 'nbits' from map at start
  *  bitmap_set_value8(map, value, start)Set 8bit value to map at start
+ *  bitmap_set_value(map, value, start, nbits) Set bit value of size 'nbits'
+ * of map at start
  *
  * Note, bitmap_zero() and bitmap_fill() operate over the region of
  * unsigned longs, that is, bits behind bitmap till the unsigned long
@@ -563,6 +567,34 @@ static inline unsigned long bitmap_get_value8(const 
unsigned long *map,
return (map[index] >> offset) & 0xFF;
 }
 
+/**
+ * bitmap_get_value - get a value of n-bits from the memory region
+ * @map: address to the bitmap memory region
+ * @start: bit offset of the n-bit value
+ * @nbits: size of value in bits
+ *
+ * Returns value of nbits located at the @start bit offset within the @map
+ * memory region.
+ */
+static inline unsigned long bitmap_get_value(const unsigned long *map,
+ unsigned long start,
+ unsigned long nbits)
+{
+   const size_t index = BIT_WORD(start);
+   const unsigned long offset = start % BITS_PER_LONG;
+   const unsigned long ceiling = roundup(start + 1, BITS_PER_LONG);
+   const unsigned long space = ceiling - start;
+   unsigned long value_low, value_high;
+
+   if (space >= nbits)
+   return (map[index] >> offset) & GENMASK(nbits - 1, 0);
+   else {
+   value_low = map[index] & BITMAP_FIRST_WORD_MASK(start);
+   value_high = map[index + 1] & BITMAP_LAST_WORD_MASK(start + 
nbits);
+   return (value_low >> offset) | (value_high << space);
+   }
+}
+
 /**
  *

Re: drivers/block/rbd.c: atomic_inc_return_safe() & atomic_dec_return_safe()

[Shuah Khan]

On 10/2/20 5:44 PM, Jens Axboe wrote:

On 10/2/20 4:34 PM, Shuah Khan wrote:

All,

I came across these atomic_inc_return_safe() & atomic_dec_return_safe()
functions that hold the counters at safe values.

atomic_inc_return_safe()

If the counter is already 0 it will not be incremented.
If the counter is already at its maximum value returns
-EINVAL without updating it.

atomic_dec_return_safe()

Decrement the counter.  Return the resulting value, or -EINVAL

These two routines are static and only used in rbd.c.

Can these become part of atomic_t ops?


I think you just want to use refcount_t for this use case. They
have safe guards for under/overflow.



Makes sense. Guess these came before refcount_t.

I will track this for refcount_t conversion.

thanks,
-- Shuah

[PATCH v10 2/4] lib/test_bitmap.c: Add for_each_set_clump test cases

[Syed Nayyar Waris]

The introduction of the generic for_each_set_clump macro need test
cases to verify the implementation. This patch adds test cases for
scenarios in which clump sizes are 8 bits, 24 bits, 30 bits and 6 bits.
The cases contain situations where clump is getting split at the word
boundary and also when zeroes are present in the start and middle of
bitmap.

Signed-off-by: Syed Nayyar Waris 
Reviewed-by: Andy Shevchenko 
Signed-off-by: William Breathitt Gray 
---
Changes in v10:
 - No change.

Changes in v9:
 - No change.

Changes in v8:
 - [Patch 2/4]: Minor change: Use '__initdata' for correct section mismatch
   in 'clump_test_data' array.

Changes in v7:
 - Minor changes: Use macro 'DECLARE_BITMAP()' and split 'struct'
   definition and test data.

Changes in v6:
 - Make 'for loop' inside 'test_for_each_set_clump' more succinct.

Changes in v5:
 - No change.

Changes in v4:
 - Use 'for' loop in test function of 'for_each_set_clump'.

Changes in v3:
 - No Change.

Changes in v2:
 - Unify different tests for 'for_each_set_clump'. Pass test data as
   function parameters.
 - Remove unnecessary bitmap_zero calls.

 lib/test_bitmap.c | 144 ++
 1 file changed, 144 insertions(+)

diff --git a/lib/test_bitmap.c b/lib/test_bitmap.c
index df903c53952b..cb2cf3858f93 100644
--- a/lib/test_bitmap.c
+++ b/lib/test_bitmap.c
@@ -155,6 +155,37 @@ static bool __init __check_eq_clump8(const char *srcfile, 
unsigned int line,
return true;
 }
 
+static bool __init __check_eq_clump(const char *srcfile, unsigned int line,
+   const unsigned int offset,
+   const unsigned int size,
+   const unsigned long *const clump_exp,
+   const unsigned long *const clump,
+   const unsigned long clump_size)
+{
+   unsigned long exp;
+
+   if (offset >= size) {
+   pr_warn("[%s:%u] bit offset for clump out-of-bounds: expected 
less than %u, got %u\n",
+   srcfile, line, size, offset);
+   return false;
+   }
+
+   exp = clump_exp[offset / clump_size];
+   if (!exp) {
+   pr_warn("[%s:%u] bit offset for zero clump: expected nonzero 
clump, got bit offset %u with clump value 0",
+   srcfile, line, offset);
+   return false;
+   }
+
+   if (*clump != exp) {
+   pr_warn("[%s:%u] expected clump value of 0x%lX, got clump value 
of 0x%lX",
+   srcfile, line, exp, *clump);
+   return false;
+   }
+
+   return true;
+}
+
 #define __expect_eq(suffix, ...)   \
({  \
int result = 0; \
@@ -172,6 +203,7 @@ static bool __init __check_eq_clump8(const char *srcfile, 
unsigned int line,
 #define expect_eq_pbl(...) __expect_eq(pbl, ##__VA_ARGS__)
 #define expect_eq_u32_array(...)   __expect_eq(u32_array, ##__VA_ARGS__)
 #define expect_eq_clump8(...)  __expect_eq(clump8, ##__VA_ARGS__)
+#define expect_eq_clump(...)   __expect_eq(clump, ##__VA_ARGS__)
 
 static void __init test_zero_clear(void)
 {
@@ -577,6 +609,28 @@ static void noinline __init test_mem_optimisations(void)
}
 }
 
+static const unsigned long clump_bitmap_data[] __initconst = {
+   0x38000201,
+   0x05ff0f38,
+   0xeffedcba,
+   0xabcd,
+   0x00aa,
+   0x00aa,
+   0x00ff,
+   0xaa00,
+   0xff00,
+   0x00aa,
+   0x,
+   0x,
+   0x,
+   0x0f00,
+   0x00ff,
+   0xaa00,
+   0xff00,
+   0x00aa,
+   0x0ac0,
+};
+
 static const unsigned char clump_exp[] __initconst = {
0x01,   /* 1 bit set */
0x02,   /* non-edge 1 bit set */
@@ -588,6 +642,95 @@ static const unsigned char clump_exp[] __initconst = {
0x05,   /* non-adjacent 2 bits set */
 };
 
+static const unsigned long clump_exp1[] __initconst = {
+   0x01,   /* 1 bit set */
+   0x02,   /* non-edge 1 bit set */
+   0x00,   /* zero bits set */
+   0x38,   /* 3 bits set across 4-bit boundary */
+   0x38,   /* Repeated clump */
+   0x0F,   /* 4 bits set */
+   0xFF,   /* all bits set */
+   0x05,   /* non-adjacent 2 bits set */
+};
+
+static const unsigned long clump_exp2[] __initconst = {
+   0xfedcba,   /* 24 bits */
+   0xabcdef,
+   0xaa,   /* Clump split between 2 words */
+   0x00,   /* zeroes in between */
+   0xaa,
+   0x00,
+   0xff,
+   0xaa,
+   0x00,
+   0xff,
+};
+
+static const unsigned long clump_exp3[] __initconst = {
+   0x, /* starting with 0s*/
+   0x, /

[PATCH v10 3/4] gpio: thunderx: Utilize for_each_set_clump macro

[Syed Nayyar Waris]

This patch reimplements the thunderx_gpio_set_multiple function in
drivers/gpio/gpio-thunderx.c to use the new for_each_set_clump macro.
Instead of looping for each bank in thunderx_gpio_set_multiple
function, now we can skip bank which is not set and save cycles.

Cc: Robert Richter 
Cc: Bartosz Golaszewski 
Signed-off-by: Syed Nayyar Waris 
Signed-off-by: William Breathitt Gray 
---
Changes in v10:
 - No change.

Changes in v9:
 - No change.

Changes in v8:
 - No change.

Changes in v7:
 - No change.

Changes in v6:
 - No change.

Changes in v5:
 - No change.

Changes in v4:
 - Minor change: Inline value '64' in code for better code readability.

Changes in v3:
 - Change datatype of some variables from u64 to unsigned long
   in function thunderx_gpio_set_multiple.

Changes in v2:
 - No change.

 drivers/gpio/gpio-thunderx.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/gpio/gpio-thunderx.c b/drivers/gpio/gpio-thunderx.c
index 9f66deab46ea..58c9bb25a377 100644
--- a/drivers/gpio/gpio-thunderx.c
+++ b/drivers/gpio/gpio-thunderx.c
@@ -275,12 +275,15 @@ static void thunderx_gpio_set_multiple(struct gpio_chip 
*chip,
   unsigned long *bits)
 {
int bank;
-   u64 set_bits, clear_bits;
+   unsigned long set_bits, clear_bits, gpio_mask;
+   unsigned long offset;
+
struct thunderx_gpio *txgpio = gpiochip_get_data(chip);
 
-   for (bank = 0; bank <= chip->ngpio / 64; bank++) {
-   set_bits = bits[bank] & mask[bank];
-   clear_bits = ~bits[bank] & mask[bank];
+   for_each_set_clump(offset, gpio_mask, mask, chip->ngpio, 64) {
+   bank = offset / 64;
+   set_bits = bits[bank] & gpio_mask;
+   clear_bits = ~bits[bank] & gpio_mask;
writeq(set_bits, txgpio->register_base + (bank * GPIO_2ND_BANK) 
+ GPIO_TX_SET);
writeq(clear_bits, txgpio->register_base + (bank * 
GPIO_2ND_BANK) + GPIO_TX_CLR);
}
-- 
2.26.2