Re: [PATCH v6] RISC-V: enable XIP

[Alex Ghiti]

Le 3/30/21 à 2:26 AM, Vitaly Wool a écrit :

On Tue, Mar 30, 2021 at 8:23 AM Palmer Dabbelt  wrote:


On Sun, 21 Mar 2021 17:12:15 PDT (-0700), vitaly.w...@konsulko.com wrote:

Introduce XIP (eXecute In Place) support for RISC-V platforms.
It allows code to be executed directly from non-volatile storage
directly addressable by the CPU, such as QSPI NOR flash which can
be found on many RISC-V platforms. This makes way for significant
optimization of RAM footprint. The XIP kernel is not compressed
since it has to run directly from flash, so it will occupy more
space on the non-volatile storage. The physical flash address used
to link the kernel object files and for storing it has to be known
at compile time and is represented by a Kconfig option.

XIP on RISC-V will for the time being only work on MMU-enabled
kernels.

Signed-off-by: Vitaly Wool 

---

Changes in v2:
- dedicated macro for XIP address fixup when MMU is not enabled yet
   o both for 32-bit and 64-bit RISC-V
- SP is explicitly set to a safe place in RAM before __copy_data call
- removed redundant alignment requirements in vmlinux-xip.lds.S
- changed long -> uintptr_t typecast in __XIP_FIXUP macro.
Changes in v3:
- rebased against latest for-next
- XIP address fixup macro now takes an argument
- SMP related fixes
Changes in v4:
- rebased against the current for-next
- less #ifdef's in C/ASM code
- dedicated XIP_FIXUP_OFFSET assembler macro in head.S
- C-specific definitions moved into #ifndef __ASSEMBLY__
- Fixed multi-core boot
Changes in v5:
- fixed build error for non-XIP kernels
Changes in v6:
- XIP_PHYS_RAM_BASE config option renamed to PHYS_RAM_BASE
- added PHYS_RAM_BASE_FIXED config flag to allow usage of
   PHYS_RAM_BASE in non-XIP configurations if needed
- XIP_FIXUP macro rewritten with a tempoarary variable to avoid side
   effects
- fixed crash for non-XIP kernels that don't use built-in DTB


So v5 landed on for-next, which generally means it's best to avoid
re-spinning the patch and instead send along fixups.  That said, the v5
is causing some testing failures for me.

I'm going to drop the v5 for now as I don't have time to test this
tonight.  I'll try and take a look soon, as it will conflict with Alex's
patches.


I can come up with the incremental patch instead pretty much straight
away if that works better.

~Vitaly


  arch/riscv/Kconfig  |  49 ++-
  arch/riscv/Makefile |   8 +-
  arch/riscv/boot/Makefile|  13 +++
  arch/riscv/include/asm/pgtable.h|  65 --
  arch/riscv/kernel/cpu_ops_sbi.c |  11 ++-
  arch/riscv/kernel/head.S|  49 ++-
  arch/riscv/kernel/head.h|   3 +
  arch/riscv/kernel/setup.c   |   8 +-
  arch/riscv/kernel/vmlinux-xip.lds.S | 132 
  arch/riscv/kernel/vmlinux.lds.S |   6 ++
  arch/riscv/mm/init.c| 100 +++--
  11 files changed, 426 insertions(+), 18 deletions(-)
  create mode 100644 arch/riscv/kernel/vmlinux-xip.lds.S

diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 8ea60a0a19ae..bd6f82240c34 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -441,7 +441,7 @@ config EFI_STUB

  config EFI
   bool "UEFI runtime support"
- depends on OF
+ depends on OF && !XIP_KERNEL
   select LIBFDT
   select UCS2_STRING
   select EFI_PARAMS_FROM_FDT
@@ -465,11 +465,56 @@ config STACKPROTECTOR_PER_TASK
   def_bool y
   depends on STACKPROTECTOR && CC_HAVE_STACKPROTECTOR_TLS

+config PHYS_RAM_BASE_FIXED
+ bool "Explicitly specified physical RAM address"
+ default n
+
+config PHYS_RAM_BASE
+ hex "Platform Physical RAM address"
+ depends on PHYS_RAM_BASE_FIXED
+ default "0x8000"
+ help
+   This is the physical address of RAM in the system. It has to be
+   explicitly specified to run early relocations of read-write data
+   from flash to RAM.
+
+config XIP_KERNEL
+ bool "Kernel Execute-In-Place from ROM"
+ depends on MMU
+ select PHYS_RAM_BASE_FIXED
+ help
+   Execute-In-Place allows the kernel to run from non-volatile storage
+   directly addressable by the CPU, such as NOR flash. This saves RAM
+   space since the text section of the kernel is not loaded from flash
+   to RAM.  Read-write sections, such as the data section and stack,
+   are still copied to RAM.  The XIP kernel is not compressed since
+   it has to run directly from flash, so it will take more space to
+   store it.  The flash address used to link the kernel object files,
+   and for storing it, is configuration dependent. Therefore, if you
+   say Y here, you must know the proper physical address where to
+   store the kernel image depending on your own flash memory usage.
+
+   Also note that the make target becomes "make xipImage" rather than
+   "make zImage" or "make Image".  The final kernel binary to put in
+   ROM 

Re: [PATCH v7 1/8] mm: Remove special swap entry functions

[Jason Gunthorpe]

On Fri, Mar 26, 2021 at 11:07:58AM +1100, Alistair Popple wrote:
> Remove multiple similar inline functions for dealing with different
> types of special swap entries.
> 
> Both migration and device private swap entries use the swap offset to
> store a pfn. Instead of multiple inline functions to obtain a struct
> page for each swap entry type use a common function
> pfn_swap_entry_to_page(). Also open-code the various entry_to_pfn()
> functions as this results is shorter code that is easier to understand.
> 
> Signed-off-by: Alistair Popple 
> Reviewed-by: Ralph Campbell 
> Reviewed-by: Christoph Hellwig 
> 
> ---
> 
> v7:
> * Reworded commit message to include pfn_swap_entry_to_page()
> * Added Christoph's Reviewed-by
> 
> v6:
> * Removed redundant compound_page() call from inside PageLocked()
> * Fixed a minor build issue for s390 reported by kernel test bot
> 
> v4:
> * Added pfn_swap_entry_to_page()
> * Reinstated check that migration entries point to locked pages
> * Removed #define swapcache_prepare which isn't needed for CONFIG_SWAP=0
>   builds
> ---
>  arch/s390/mm/pgtable.c  |  2 +-
>  fs/proc/task_mmu.c  | 23 +-
>  include/linux/swap.h|  4 +--
>  include/linux/swapops.h | 69 ++---
>  mm/hmm.c|  5 ++-
>  mm/huge_memory.c|  4 +--
>  mm/memcontrol.c |  2 +-
>  mm/memory.c | 10 +++---
>  mm/migrate.c|  6 ++--
>  mm/page_vma_mapped.c|  6 ++--
>  10 files changed, 50 insertions(+), 81 deletions(-)

Looks good

Reviewed-by: Jason Gunthorpe 

> diff --git a/mm/hmm.c b/mm/hmm.c
> index 943cb2ba4442..3b2dda71d0ed 100644
> --- a/mm/hmm.c
> +++ b/mm/hmm.c
> @@ -214,7 +214,7 @@ static inline bool hmm_is_device_private_entry(struct 
> hmm_range *range,
>   swp_entry_t entry)
>  {
>   return is_device_private_entry(entry) &&
> - device_private_entry_to_page(entry)->pgmap->owner ==
> + pfn_swap_entry_to_page(entry)->pgmap->owner ==
>   range->dev_private_owner;
>  }
>  
> @@ -257,8 +257,7 @@ static int hmm_vma_handle_pte(struct mm_walk *walk, 
> unsigned long addr,
>   cpu_flags = HMM_PFN_VALID;
>   if (is_write_device_private_entry(entry))
>   cpu_flags |= HMM_PFN_WRITE;
> - *hmm_pfn = device_private_entry_to_pfn(entry) |
> - cpu_flags;
> + *hmm_pfn = swp_offset(entry) | cpu_flags;

Though swp_offset() seems poor here

Something like this seems nicer, maybe as an additional patch in this
series?

diff --git a/mm/hmm.c b/mm/hmm.c
index 943cb2ba444232..c06cbc4e3981b7 100644
--- a/mm/hmm.c
+++ b/mm/hmm.c
@@ -210,14 +210,6 @@ int hmm_vma_handle_pmd(struct mm_walk *walk, unsigned long 
addr,
unsigned long end, unsigned long hmm_pfns[], pmd_t pmd);
 #endif /* CONFIG_TRANSPARENT_HUGEPAGE */
 
-static inline bool hmm_is_device_private_entry(struct hmm_range *range,
-   swp_entry_t entry)
-{
-   return is_device_private_entry(entry) &&
-   device_private_entry_to_page(entry)->pgmap->owner ==
-   range->dev_private_owner;
-}
-
 static inline unsigned long pte_to_hmm_pfn_flags(struct hmm_range *range,
 pte_t pte)
 {
@@ -226,6 +218,32 @@ static inline unsigned long pte_to_hmm_pfn_flags(struct 
hmm_range *range,
return pte_write(pte) ? (HMM_PFN_VALID | HMM_PFN_WRITE) : HMM_PFN_VALID;
 }
 
+static bool hmm_pte_handle_device_private(struct hmm_range *range, pte_t pte,
+ unsigned long *hmm_pfn)
+{
+   swp_entry_t entry = pte_to_swp_entry(pte);
+   struct page *device_page;
+   unsigned long cpu_flags;
+
+   if (is_device_private_entry(entry))
+   return false;
+
+   /*
+* If the device private page matches the device the caller understands
+* then return the private pfn directly. The caller must know what to do
+* with it.
+*/
+   device_page = pfn_swap_entry_to_page(entry);
+   if (device_page->pgmap->owner != range->dev_private_owner)
+   return false;
+
+   cpu_flags = HMM_PFN_VALID;
+   if (is_write_device_private_entry(entry))
+   cpu_flags |= HMM_PFN_WRITE;
+   *hmm_pfn = page_to_pfn(device_page) | cpu_flags;
+   return true;
+}
+
 static int hmm_vma_handle_pte(struct mm_walk *walk, unsigned long addr,
  unsigned long end, pmd_t *pmdp, pte_t *ptep,
  unsigned long *hmm_pfn)
@@ -247,20 +265,8 @@ static int hmm_vma_handle_pte(struct mm_walk *walk, 
unsigned long addr,
}
 
if (!pte_present(pte)) {
-   swp_entry_t entry = pte_to_swp_entry(pte);
-
-   /*
-* Never fault in device private pages, but just report
-* the PFN even if not 

Re: [PATCH] jffs2: Hook up splice_write callback

[Al Viro]

On Tue, Mar 30, 2021 at 06:31:00PM +, Al Viro wrote:
> On Tue, Mar 30, 2021 at 06:17:15PM +0200, Christoph Hellwig wrote:
> > On Wed, Mar 31, 2021 at 12:15:37AM +1030, Joel Stanley wrote:
> > > overlayfs using jffs2 as the upper filesystem would fail in some cases
> > > since moving to v5.10. The test case used was to run 'touch' on a file
> > > that exists in the lower fs, causing the modification time to be
> > > updated. It returns EINVAL when the bug is triggered.
> > > 
> > > A bisection showed this was introduced in v5.9-rc1, with commit
> > > 36e2c7421f02 ("fs: don't allow splice read/write without explicit ops").
> > > Reverting that commit restores the expected behaviour.
> > > 
> > > Some digging showed that this was due to jffs2 lacking an implementation
> > > of splice_write. (For unknown reasons the warn_unsupported that should
> > > trigger was not displaying any output).
> > > 
> > > Adding this patch resolved the issue and the test now passes.
> > 
> > Looks good:
> > 
> > Reviewed-by: Christoph Hellwig 
> 
> The same goes for quite a few other filesystems, actually - at least
> adfs, affs, bfs, hfs, hfsplus, hostfs, hpfs, minix, omfs, sysv, ufs 
> and vboxsf are in the same boat, and I suspect that ecryptfs and ntfs
> might be too.
> 
> Christoph, do you see any problems with doing the same thing for that
> bunch as well?

coda and udf as well, by the look of it...

Re: [PATCH 00/18] KVM: Consolidate and optimize MMU notifiers

[Ben Gardon]

On Thu, Mar 25, 2021 at 7:20 PM Sean Christopherson  wrote:
>
> The end goal of this series is to optimize the MMU notifiers to take
> mmu_lock if and only if the notification is relevant to KVM, i.e. the hva
> range overlaps a memslot.   Large VMs (hundreds of vCPUs) are very
> sensitive to mmu_lock being taken for write at inopportune times, and
> such VMs also tend to be "static", e.g. backed by HugeTLB with minimal
> page shenanigans.  The vast majority of notifications for these VMs will
> be spurious (for KVM), and eliding mmu_lock for spurious notifications
> avoids an otherwise unacceptable disruption to the guest.
>
> To get there without potentially degrading performance, e.g. due to
> multiple memslot lookups, especially on non-x86 where the use cases are
> largely unknown (from my perspective), first consolidate the MMU notifier
> logic by moving the hva->gfn lookups into common KVM.
>
> Applies on my TDP MMU TLB flushing bug fixes[*], which conflict horribly
> with the TDP MMU changes in this series.  That code applies on kvm/queue
> (commit 4a98623d5d90, "KVM: x86/mmu: Mark the PAE roots as decrypted for
> shadow paging").
>
> Speaking of conflicts, Ben will soon be posting a series to convert a
> bunch of TDP MMU flows to take mmu_lock only for read.  Presumably there
> will be an absurd number of conflicts; Ben and I will sort out the
> conflicts in whichever series loses the race.
>
> Well tested on Intel and AMD.  Compile tested for arm64, MIPS, PPC,
> PPC e500, and s390.  Absolutely needs to be tested for real on non-x86,
> I give it even odds that I introduced an off-by-one bug somewhere.
>
> [*] https://lkml.kernel.org/r/20210325200119.1359384-1-sea...@google.com
>
>
> Patches 1-7 are x86 specific prep patches to play nice with moving
> the hva->gfn memslot lookups into common code.  There ended up being waaay
> more of these than I expected/wanted, but I had a hell of a time getting
> the flushing logic right when shuffling the memslot and address space
> loops.  In the end, I was more confident I got things correct by batching
> the flushes.
>
> Patch 8 moves the existing API prototypes into common code.  It could
> technically be dropped since the old APIs are gone in the end, but I
> thought the switch to the new APIs would suck a bit less this way.

Patches 1-8 look good to me. Feel free to add my Reviewed-by tag to those.
I appreciate the care you took to make all those changes tiny and reviewable.

>
> Patch 9 moves arm64's MMU notifier tracepoints into common code so that
> they are not lost when arm64 is converted to the new APIs, and so that all
> architectures can benefit.
>
> Patch 10 moves x86's memslot walkers into common KVM.  I chose x86 purely
> because I could actually test it.  All architectures use nearly identical
> code, so I don't think it actually matters in the end.

I'm still reviewing 10 and 14-18. 10 is a huge change and the diff is
pretty hard to parse.

>
> Patches 11-13 move arm64, MIPS, and PPC to the new APIs.
>
> Patch 14 yanks out the old APIs.
>
> Patch 15 adds the mmu_lock elision, but only for unpaired notifications.

Reading through all this code and considering the changes I'm
preparing for the TDP MMU have me wondering if it might help to have a
more general purpose MMU lock context struct which could be embedded
in the structs added in this patch. I'm thinking something like:
enum kvm_mmu_lock_mode {
KVM_MMU_LOCK_NONE,
KVM_MMU_LOCK_READ,
KVM_MMU_LOCK_WRITE,
};

struct kvm_mmu_lock_context {
enum kvm_mmu_lock_mode lock_mode;
bool can_block;
bool can_yield;
bool flush;
};

This could yield some grossly long lines, but it would also have
potential to unify a bunch of ad-hoc handling.
The above struct could also fit into a single byte, so it'd be pretty
easy to pass it around.

>
> Patch 16 adds mmu_lock elision for paired .invalidate_range_{start,end}().
> This is quite nasty and no small part of me thinks the patch should be
> burned with fire (I won't spoil it any further), but it's also the most
> problematic scenario for our particular use case.  :-/
>
> Patches 17-18 are additional x86 cleanups.
>
> Sean Christopherson (18):
>   KVM: x86/mmu: Coalesce TDP MMU TLB flushes when zapping collapsible
> SPTEs
>   KVM: x86/mmu: Move flushing for "slot" handlers to caller for legacy
> MMU
>   KVM: x86/mmu: Coalesce TLB flushes when zapping collapsible SPTEs
>   KVM: x86/mmu: Coalesce TLB flushes across address spaces for gfn range
> zap
>   KVM: x86/mmu: Pass address space ID to __kvm_tdp_mmu_zap_gfn_range()
>   KVM: x86/mmu: Pass address space ID to TDP MMU root walkers
>   KVM: x86/mmu: Use leaf-only loop for walking TDP SPTEs when changing
> SPTE
>   KVM: Move prototypes for MMU notifier callbacks to generic code
>   KVM: Move arm64's MMU notifier trace events to generic code
>   KVM: Move x86's MMU notifier memslot walkers to generic code
>   KVM: arm64: Convert to the gfn-based MMU notifier callbacks

Re: [PATCH] jffs2: Hook up splice_write callback

[Al Viro]

On Tue, Mar 30, 2021 at 06:17:15PM +0200, Christoph Hellwig wrote:
> On Wed, Mar 31, 2021 at 12:15:37AM +1030, Joel Stanley wrote:
> > overlayfs using jffs2 as the upper filesystem would fail in some cases
> > since moving to v5.10. The test case used was to run 'touch' on a file
> > that exists in the lower fs, causing the modification time to be
> > updated. It returns EINVAL when the bug is triggered.
> > 
> > A bisection showed this was introduced in v5.9-rc1, with commit
> > 36e2c7421f02 ("fs: don't allow splice read/write without explicit ops").
> > Reverting that commit restores the expected behaviour.
> > 
> > Some digging showed that this was due to jffs2 lacking an implementation
> > of splice_write. (For unknown reasons the warn_unsupported that should
> > trigger was not displaying any output).
> > 
> > Adding this patch resolved the issue and the test now passes.
> 
> Looks good:
> 
> Reviewed-by: Christoph Hellwig 

The same goes for quite a few other filesystems, actually - at least
adfs, affs, bfs, hfs, hfsplus, hostfs, hpfs, minix, omfs, sysv, ufs 
and vboxsf are in the same boat, and I suspect that ecryptfs and ntfs
might be too.

Christoph, do you see any problems with doing the same thing for that
bunch as well?

Re: [RFC PATCH] nvme: allow NVME_IOCTL_IO_CMD on controller char dev even when multiple ns

[jav...@javigon.com]

On 26.03.2021 20:59, Niklas Cassel wrote:

From: Niklas Cassel 

Currently when doing NVME_IOCTL_IO_CMD on the controller character device,
the command is rejected if there is more than one namespace in the
ctrl->namespaces list.

There is not really any reason for this restriction.
Instead, check the nsid value specified in the passthru command, and try
to find the matching namespace in ctrl->namespaces list.
If found, call nvme_user_cmd() on the namespace.
If not found, reject the command.

While at it, remove the warning that says that NVME_IOCTL_IO_CMD is
deprecated on the controller character device.
There is no comment saying why it is deprecated.
It might be very unsafe to send a passthru command, but if that is
the issue with this IOCTL, then we should add a warning about that
instead.

Signed-off-by: Niklas Cassel 


I think the idea is OK, but I have 3 questions:

  1. Wouldn't this break user-space when nsid is not specified?
  2. What is the use case for this? As I understand it, this char device
  is primarily for admin commands sent to the controller. Do you see a
  use case for sending commands to the namespace using the controller
  char device?
  3. Following up on the above, if the use-case is I/O, don't you think
  it is cleaner to use the ongoing per-namespace char device effort? We
  would very much like to get your input there and eventually send a
  series together. When this is merged, we could wire that logic to the
  controller char device if there is an use-case for it.

Javier

Re: [PATCH] perf annotate: add --demangle and --demangle-kernel

[Arnaldo Carvalho de Melo]

Em Tue, Mar 30, 2021 at 08:19:10PM +0200, Martin Liška escreveu:
> On 3/30/21 5:42 PM, Arnaldo Carvalho de Melo wrote:
> > Trying to find V2

You said you would resend fixing up this:

+   OPT_BOOLEAN(0, "demangle", _conf.demangle,
+   "Disable symbol demangling"),
 ^^^



+   OPT_BOOLEAN(0, "demangle-kernel", _conf.demangle_kernel,
+   "Enable kernel symbol demangling"),
 
> It's this email:
> https://lore.kernel.org/lkml/deb2af9e-25dd-ac72-29f4-ab90c2b24...@suse.cz/
> 
> Subject: Re: [PATCH] perf config: add annotate.demangle{,_kernel}
> From:   =?UTF-8?Q?Martin_Li=c5=a1ka?= 
> To: Arnaldo Carvalho de Melo 
> Cc: linux-kernel@vger.kernel.org, linux-perf-us...@vger.kernel.org
> References: 
>   
> Message-ID: 
> Date:   Fri, 26 Feb 2021 11:08:12 +0100
> 
> 
> Cheers,
> Martin

-- 

- Arnaldo

Re: [PATCH v3 01/17] cmdline: Add generic function to build command line.

[Daniel Walker]

On Tue, Mar 30, 2021 at 08:07:30PM +0200, H. Nikolaus Schaller wrote:
> 
> > Am 30.03.2021 um 19:27 schrieb Daniel Walker :
> > 
> > On Fri, Mar 26, 2021 at 01:44:48PM +, Christophe Leroy wrote:
> >> This code provides architectures with a way to build command line
> >> based on what is built in the kernel and what is handed over by the
> >> bootloader, based on selected compile-time options.
> >> 
> >> Signed-off-by: Christophe Leroy 
> >> ---
> >> v3:
> >> - Addressed comments from Will
> >> - Added capability to have src == dst
> >> ---
> >> include/linux/cmdline.h | 57 +
> >> 1 file changed, 57 insertions(+)
> >> create mode 100644 include/linux/cmdline.h
> >> 
> >> diff --git a/include/linux/cmdline.h b/include/linux/cmdline.h
> >> new file mode 100644
> >> index ..dea87edd41be
> >> --- /dev/null
> >> +++ b/include/linux/cmdline.h
> >> @@ -0,0 +1,57 @@
> >> +/* SPDX-License-Identifier: GPL-2.0 */
> >> +#ifndef _LINUX_CMDLINE_H
> >> +#define _LINUX_CMDLINE_H
> >> +
> >> +#include 
> >> +
> >> +/* Allow architectures to override strlcat, powerpc can't use strings so 
> >> early */
> >> +#ifndef cmdline_strlcat
> >> +#define cmdline_strlcat strlcat
> >> +#endif
> >> +
> >> +/*
> >> + * This function will append or prepend a builtin command line to the 
> >> command
> >> + * line provided by the bootloader. Kconfig options can be used to alter
> >> + * the behavior of this builtin command line.
> >> + * @dst: The destination of the final appended/prepended string.
> >> + * @src: The starting string or NULL if there isn't one.
> >> + * @len: the length of dest buffer.
> >> + */
> > 
> > Append or prepend ? Cisco requires both at the same time. This is why my
> > implementation provides both. I can't use this with both at once.
> 
> Just an idea: what about defining CMDLINE as a pattern where e.g. "$$" or "%%"
> is replaced by the boot loader command line?
> 
> Then you can formulate replace, prepend, append, prepend+append with a single
> CONFIG setting.
> 
> It may be a little more complex in code (scanning for the pattern and 
> replacing
> it and take care to temporary memory) but IMHO it could be worth to consider.

In some cases this code could be used extremely early in boot up. For example 
in the
prom_init.c powerpc code, or in efi changes. The flexibility to find and replace
like that is not always an option due to the nature of the environment. It's not
impossible of course.

Daniel

Re: [PATCH v5 1/1] fs: Allow no_new_privs tasks to call chroot(2)

[Casey Schaufler]

On 3/30/2021 11:11 AM, Mickaël Salaün wrote:
> On 30/03/2021 19:19, Casey Schaufler wrote:
>> On 3/30/2021 10:01 AM, Mickaël Salaün wrote:
>>> Hi,
>>>
>>> Is there new comments on this patch? Could we move forward?
>> I don't see that new comments are necessary when I don't see
>> that you've provided compelling counters to some of the old ones.
> Which ones? I don't buy your argument about the beauty of CAP_SYS_CHROOT.

>
>> It's possible to use minimal privilege with CAP_SYS_CHROOT.
> CAP_SYS_CHROOT can lead to privilege escalation.
>
>> It looks like namespaces provide alternatives for all your
>> use cases.
> I explained in the commit message why it is not the case. In a nutshell,
> namespaces bring complexity which may not be required. When designing a
> secure system, we want to avoid giving access to such complexity to
> untrusted processes (i.e. more complexity leads to more bugs). An
> unprivileged chroot would enable to give just the minimum feature to
> drop some accesses. Of course it is not enough on its own, but it can be
> combined with existing (and future) security features.
>
>> The constraints required to make this work are quite
>> limiting. Where is the real value add?
> As explain in the commit message, it is useful when hardening
> applications (e.g. network services, browsers, parsers, etc.). We don't
> want an untrusted (or compromised) application to have CAP_SYS_CHROOT
> nor (complex) namespace access.
>
>>> Regards,
>>>  Mickaël
>>>
>>>
>>> On 16/03/2021 21:36, Mickaël Salaün wrote:
 From: Mickaël Salaün 

 Being able to easily change root directories enables to ease some
 development workflow and can be used as a tool to strengthen
 unprivileged security sandboxes.  chroot(2) is not an access-control
 mechanism per se, but it can be used to limit the absolute view of the
 filesystem, and then limit ways to access data and kernel interfaces
 (e.g. /proc, /sys, /dev, etc.).

 Users may not wish to expose namespace complexity to potentially
 malicious processes, or limit their use because of limited resources.
 The chroot feature is much more simple (and limited) than the mount
 namespace, but can still be useful.  As for containers, users of
 chroot(2) should take care of file descriptors or data accessible by
 other means (e.g. current working directory, leaked FDs, passed FDs,
 devices, mount points, etc.).  There is a lot of literature that discuss
 the limitations of chroot, and users of this feature should be aware of
 the multiple ways to bypass it.  Using chroot(2) for security purposes
 can make sense if it is combined with other features (e.g. dedicated
 user, seccomp, LSM access-controls, etc.).

 One could argue that chroot(2) is useless without a properly populated
 root hierarchy (i.e. without /dev and /proc).  However, there are
 multiple use cases that don't require the chrooting process to create
 file hierarchies with special files nor mount points, e.g.:
 * A process sandboxing itself, once all its libraries are loaded, may
   not need files other than regular files, or even no file at all.
 * Some pre-populated root hierarchies could be used to chroot into,
   provided for instance by development environments or tailored
   distributions.
 * Processes executed in a chroot may not require access to these special
   files (e.g. with minimal runtimes, or by emulating some special files
   with a LD_PRELOADed library or seccomp).

 Allowing a task to change its own root directory is not a threat to the
 system if we can prevent confused deputy attacks, which could be
 performed through execution of SUID-like binaries.  This can be
 prevented if the calling task sets PR_SET_NO_NEW_PRIVS on itself with
 prctl(2).  To only affect this task, its filesystem information must not
 be shared with other tasks, which can be achieved by not passing
 CLONE_FS to clone(2).  A similar no_new_privs check is already used by
 seccomp to avoid the same kind of security issues.  Furthermore, because
 of its security use and to avoid giving a new way for attackers to get
 out of a chroot (e.g. using /proc//root, or chroot/chdir), an
 unprivileged chroot is only allowed if the calling process is not
 already chrooted.  This limitation is the same as for creating user
 namespaces.

 This change may not impact systems relying on other permission models
 than POSIX capabilities (e.g. Tomoyo).  Being able to use chroot(2) on
 such systems may require to update their security policies.

 Only the chroot system call is relaxed with this no_new_privs check; the
 init_chroot() helper doesn't require such change.

 Allowing unprivileged users to use chroot(2) is one of the initial
 objectives of no_new_privs:
 

Re: [PATCH] arm64: dts: qcom: sc7280: Add PMIC peripherals for SC7280

[Matthias Kaehlcke]

On Thu, Mar 25, 2021 at 10:50:57AM +0530, ska...@codeaurora.org wrote:
> Hi Matthias,
> 
> On 2021-03-22 23:04, Matthias Kaehlcke wrote:
> > Hi Satya,
> > 
> > On Mon, Mar 22, 2021 at 06:50:47PM +0530, ska...@codeaurora.org wrote:
> > > Hi Matthias,
> > > 
> > > On 2021-03-13 02:10, Matthias Kaehlcke wrote:
> > > > Hi Satya,
> > > >
> > > > On Thu, Mar 11, 2021 at 04:10:29PM +0530, satya priya wrote:
> > > > > Add PM7325/PM8350C/PMK8350/PMR735A peripherals such as PON,
> > > > > GPIOs, RTC and other PMIC infra modules for SC7280.
> > > > >
> > > > > Signed-off-by: satya priya 
> > > > > ---
> > > > > This patch depends on base DT and board files for SC7280 to merge
> > > > > first
> > > > > https://lore.kernel.org/patchwork/project/lkml/list/?series=487403
> > > > >
> > > > >  arch/arm64/boot/dts/qcom/pm7325.dtsi  |  60 
> > > > >  arch/arm64/boot/dts/qcom/pm8350c.dtsi |  60 
> > > > >  arch/arm64/boot/dts/qcom/pmk8350.dtsi | 104
> > > > > ++
> > > > >  arch/arm64/boot/dts/qcom/pmr735a.dtsi |  60 
> > > > >  arch/arm64/boot/dts/qcom/sc7280.dtsi  |   8 +++
> > > > >  5 files changed, 292 insertions(+)
> > > > >  create mode 100644 arch/arm64/boot/dts/qcom/pm7325.dtsi
> > > > >  create mode 100644 arch/arm64/boot/dts/qcom/pm8350c.dtsi
> > > > >  create mode 100644 arch/arm64/boot/dts/qcom/pmk8350.dtsi
> > > > >  create mode 100644 arch/arm64/boot/dts/qcom/pmr735a.dtsi
> > > > >
> > > > > diff --git a/arch/arm64/boot/dts/qcom/pm7325.dtsi
> > > > > b/arch/arm64/boot/dts/qcom/pm7325.dtsi
> > > > > new file mode 100644
> > > > > index 000..393b256
> > > > > --- /dev/null
> > > > > +++ b/arch/arm64/boot/dts/qcom/pm7325.dtsi
> > > > > @@ -0,0 +1,60 @@
> > > >
> > > > ...
> > > >
> > > > > + polling-delay-passive = <100>;
> > > > > + polling-delay = <0>;
> > > >
> > > > Are you sure that no polling delay is needed? How does the thermal
> > > > framework
> > > > detect that the temperatures is >= the passive trip point and that it
> > > > should
> > > > start polling at 'polling-delay-passive' rate?
> > > >
> > > 
> > > As the temp-alarm has interrupt support, whenever preconfigured
> > > threshold
> > > violates it notifies thermal framework, so I think the polling delay
> > > is not
> > > needed here.
> > 
> > From the documentation I found it's not clear to me how exactly these
> > interrupts work. Is a single interrupt triggered when the threshold is
> > violated or are there periodic (?) interrupts as long as the temperature
> > is above the stage 0 threshold?
> > 
> > Why is 'polling-delay-passive' passive needed if there are interrupts?
> > Maybe
> > to detect that the zone should transition from passive to no cooling
> > when the
> > temperature drops below the stage 0 threshold?
> 
> The PMIC TEMP_ALARM peripheral maintains an internal over-temperature stage:
> 0, 1, 2, or 3.  Stage 0 is normal operation below the lowest (stage 1)
> threshold [usually 95 C].  When in stage 1, the temperature is between the
> stage 1 and 2 thresholds [stage 2 threshold is usually 115 C].  Upon hitting
> the stage 3 threshold [usually 145 C], the PMIC hardware will automatically
> shut down the system.
> 
> The TEMP_ALARM IRQ fires on stage 0 -> 1 and 1 -> 0 transitions.  We
> therefore set polling-delay = <0> since there is no need for software to
> monitor the temperature periodically when operating in stage 0.  Upon
> crossing the stage 1 threshold, SW receives the IRQ and the thermal
> framework hits its first trip changing the thermal zone to passive mode.
> This then engages the 100 ms polling enabled via polling-delay-passive =
> <100>.  If the temperate keeps climbing and passes the stage 2 threshold,
> the thermal framework hits the second trip (which is critical) and it
> initiates an orderly shutdown.  If the temperature drops below the stage 1
> threshold, then the thermal framework exits passive mode and stops polling.
> This approach reduces/eliminates the software overhead when not at an
> elevated temperature.

Thanks for the clarification. With the interrupt only firing on stage 0 -> 1
and stage 1 -> 0 it makes sense. I was expecting interrupts on the other
transitions too.

Re: [PATCH] perf annotate: add --demangle and --demangle-kernel

[Martin Liška]

On 3/30/21 5:42 PM, Arnaldo Carvalho de Melo wrote:

Trying to find V2


It's this email:
https://lore.kernel.org/lkml/deb2af9e-25dd-ac72-29f4-ab90c2b24...@suse.cz/

Subject: Re: [PATCH] perf config: add annotate.demangle{,_kernel}
From:   =?UTF-8?Q?Martin_Li=c5=a1ka?= 
To: Arnaldo Carvalho de Melo 
Cc: linux-kernel@vger.kernel.org, linux-perf-us...@vger.kernel.org
References: 
  
Message-ID: 
Date:   Fri, 26 Feb 2021 11:08:12 +0100


Cheers,
Martin

Re: [PATCH RFC/RFT 1/1] misc: add simple logic analyzer using polling

[Randy Dunlap]

Hi--

On 3/30/21 1:56 AM, Wolfram Sang wrote:
> diff --git a/Documentation/dev-tools/gpio-logic-analyzer.rst 
> b/Documentation/dev-tools/gpio-logic-analyzer.rst
> new file mode 100644
> index ..2847260736d4
> --- /dev/null
> +++ b/Documentation/dev-tools/gpio-logic-analyzer.rst
> @@ -0,0 +1,63 @@
> +Linux Kernel GPIO based logic analyzer
> +==
> +
> +:Author: Wolfram Sang
> +
> +Introduction
> +
> +
> +This document briefly describes how to run the software based in-kernel logic
> +analyzer.
> +
> +Note that this is still a last resort analyzer which can be affected by
> +latencies and non-determinant code paths. However, for e.g. remote 
> development,
> +it may be useful to get a first view and aid further debugging.
> +
> +Setup
> +-
> +
> +Tell the kernel which GPIOs are used as probes. For a DT based system:
> +
> +i2c-analyzer {
> +compatible = "gpio-logic-analyzer";
> +probe-gpios = < 21 GPIO_OPEN_DRAIN>, < 4 
> GPIO_OPEN_DRAIN>;
> +probe-names = "SCL", "SDA";
> +};
> +
> +The binding documentation is in the ``misc`` folder of the Kernel binding
> +documentation.
> +
> +Usage
> +-
> +
> +The logic analyzer is configurable via files in debugfs. However, it is
> +strongly recommended to not use them directly, but to to use the
> +``gpio-logic-analyzer`` script in the ``tools/debugging`` directory. Besides
> +checking parameters more extensively, it will isolate a CPU core for you, so
> +you will have least disturbance while measuring.
> +
> +The script has a help option explaining the parameters. For the above DT
> +snipplet which analyzes an I2C bus at 400KHz on a Renesas Salvator-XS board,

   snippet

> +the following settings are used: The isolated CPU shall be CPU1 because it 
> is a
> +big core in a big.LITTLE setup. Because CPU1 is the default, we don't need a
> +parameter. The bus speed is 400kHz. So, the sampling theorem says we need to
> +sample at least at 800kHz. However, falling of both, SDA and SCL, in a start

Is "falling" like a falling edge of a signal?
If not, then I think "failing" would make more sense.
Even "failing both".

> +condition is faster, so we need a higher sampling frequency, e.g. ``-s
> +150`` for 1.5MHz. Also, we don't want to sample right away but wait for a
> +start condition on an idle bus. So, we need to set a trigger to a falling 
> edge
> +on SDA, i.e. ``-t "2F"``. Last is the duration, let us assume 15ms here which
> +results in the parameter ``-d 15000``. So, altogether:
> +
> +gpio-logic-analyzer -s 150 -t "2F" -d 15000
> +
> +Note that the process will return you back to the prompt but a sub-process is
> +still sampling in the background. Unless this finished, you will not find a
> +result file in the current or specified directory. Please also note that
> +currently this sub-process is not killable! For the above example, we will 
> then
> +need to trigger I2C communication:
> +
> +i2cdetect -y -r 
> +
> +Result is a .sr file to be consumed with PulseView from the free Sigrok 
> project. It is
> +a zip file which also contains the binary sample data which may be consumed 
> by others.
> +The filename is the logic analyzer instance name plus a since-epoch 
> timestamp.


thanks.
-- 
~Randy

[PATCH v1 08/10] ipmi_si: Use strstrip() to remove surrounding spaces

[Andy Shevchenko]

Instead of home grown analogue, use strstrip() from the kernel library.

Signed-off-by: Andy Shevchenko 
---
 drivers/char/ipmi/ipmi_si_hotmod.c | 16 
 1 file changed, 4 insertions(+), 12 deletions(-)

diff --git a/drivers/char/ipmi/ipmi_si_hotmod.c 
b/drivers/char/ipmi/ipmi_si_hotmod.c
index 4fbb4e18bae2..087f5eb1ebc0 100644
--- a/drivers/char/ipmi/ipmi_si_hotmod.c
+++ b/drivers/char/ipmi/ipmi_si_hotmod.c
@@ -185,24 +185,16 @@ static atomic_t hotmod_nr;
 
 static int hotmod_handler(const char *val, const struct kernel_param *kp)
 {
-   char *str = kstrdup(val, GFP_KERNEL), *curr, *next;
int  rv;
struct ipmi_plat_data h;
-   unsigned int len;
-   int ival;
+   char *str, *curr, *next;
 
+   str = kstrdup(val, GFP_KERNEL);
if (!str)
return -ENOMEM;
 
/* Kill any trailing spaces, as we can get a "\n" from echo. */
-   len = strlen(str);
-   ival = len - 1;
-   while ((ival >= 0) && isspace(str[ival])) {
-   str[ival] = '\0';
-   ival--;
-   }
-
-   for (curr = str; curr; curr = next) {
+   for (curr = strstrip(str); curr; curr = next) {
enum hotmod_op op;
 
next = strchr(curr, ':');
@@ -235,7 +227,7 @@ static int hotmod_handler(const char *val, const struct 
kernel_param *kp)
put_device(dev);
}
}
-   rv = len;
+   rv = strlen(val);
 out:
kfree(str);
return rv;
-- 
2.30.2

[PATCH v1 05/10] ipmi_si: Introduce panic_event_str array

[Andy Shevchenko]

Instead of twice repeat the constant literals, introduce
panic_event_str array. It allows to simplify the code with
help of match_string() API.

Signed-off-by: Andy Shevchenko 
---
 drivers/char/ipmi/ipmi_msghandler.c | 49 ++---
 1 file changed, 17 insertions(+), 32 deletions(-)

diff --git a/drivers/char/ipmi/ipmi_msghandler.c 
b/drivers/char/ipmi/ipmi_msghandler.c
index f19f0f967e28..c7d37366d7bb 100644
--- a/drivers/char/ipmi/ipmi_msghandler.c
+++ b/drivers/char/ipmi/ipmi_msghandler.c
@@ -52,8 +52,12 @@ static bool drvregistered;
 enum ipmi_panic_event_op {
IPMI_SEND_PANIC_EVENT_NONE,
IPMI_SEND_PANIC_EVENT,
-   IPMI_SEND_PANIC_EVENT_STRING
+   IPMI_SEND_PANIC_EVENT_STRING,
+   IPMI_SEND_PANIC_EVENT_MAX
 };
+
+static const char *const panic_event_str[] = { "none", "event", "string", NULL 
};
+
 #ifdef CONFIG_IPMI_PANIC_STRING
 #define IPMI_PANIC_DEFAULT IPMI_SEND_PANIC_EVENT_STRING
 #elif defined(CONFIG_IPMI_PANIC_EVENT)
@@ -68,46 +72,27 @@ static int panic_op_write_handler(const char *val,
  const struct kernel_param *kp)
 {
char valcp[16];
-   char *s;
-
-   strncpy(valcp, val, 15);
-   valcp[15] = '\0';
+   int e;
 
-   s = strstrip(valcp);
-
-   if (strcmp(s, "none") == 0)
-   ipmi_send_panic_event = IPMI_SEND_PANIC_EVENT_NONE;
-   else if (strcmp(s, "event") == 0)
-   ipmi_send_panic_event = IPMI_SEND_PANIC_EVENT;
-   else if (strcmp(s, "string") == 0)
-   ipmi_send_panic_event = IPMI_SEND_PANIC_EVENT_STRING;
-   else
-   return -EINVAL;
+   strscpy(valcp, val, sizeof(valcp));
+   e = match_string(panic_event_str, -1, strstrip(valcp));
+   if (e < 0)
+   return e;
 
+   ipmi_send_panic_event = e;
return 0;
 }
 
 static int panic_op_read_handler(char *buffer, const struct kernel_param *kp)
 {
-   switch (ipmi_send_panic_event) {
-   case IPMI_SEND_PANIC_EVENT_NONE:
-   strcpy(buffer, "none\n");
-   break;
-
-   case IPMI_SEND_PANIC_EVENT:
-   strcpy(buffer, "event\n");
-   break;
-
-   case IPMI_SEND_PANIC_EVENT_STRING:
-   strcpy(buffer, "string\n");
-   break;
+   const char *event_str;
 
-   default:
-   strcpy(buffer, "???\n");
-   break;
-   }
+   if (ipmi_send_panic_event >= IPMI_SEND_PANIC_EVENT_MAX)
+   event_str = "???";
+   else
+   event_str = panic_event_str[ipmi_send_panic_event];
 
-   return strlen(buffer);
+   return sprintf(buffer, "%s\n", event_str);
 }
 
 static const struct kernel_param_ops panic_op_ops = {
-- 
2.30.2

[PATCH v1 03/10] ipmi_si: Utilize temporary variable to hold device pointer

[Andy Shevchenko]

By one of the previous clean up change we got a temporary variable to hold
a device pointer. It can be utilized in other calls in the ->probe() and
save a bit of LOCs.

Signed-off-by: Andy Shevchenko 
---
 drivers/char/ipmi/ipmi_si_platform.c | 15 +++
 1 file changed, 7 insertions(+), 8 deletions(-)

diff --git a/drivers/char/ipmi/ipmi_si_platform.c 
b/drivers/char/ipmi/ipmi_si_platform.c
index 009563073d30..954c297b459b 100644
--- a/drivers/char/ipmi/ipmi_si_platform.c
+++ b/drivers/char/ipmi/ipmi_si_platform.c
@@ -309,6 +309,7 @@ static int find_slave_address(struct si_sm_io *io, int 
slave_addr)
 
 static int acpi_ipmi_probe(struct platform_device *pdev)
 {
+   struct device *dev = >dev;
struct si_sm_io io;
acpi_handle handle;
acpi_status status;
@@ -318,21 +319,20 @@ static int acpi_ipmi_probe(struct platform_device *pdev)
if (!si_tryacpi)
return -ENODEV;
 
-   handle = ACPI_HANDLE(>dev);
+   handle = ACPI_HANDLE(dev);
if (!handle)
return -ENODEV;
 
memset(, 0, sizeof(io));
io.addr_source = SI_ACPI;
-   dev_info(>dev, "probing via ACPI\n");
+   dev_info(dev, "probing via ACPI\n");
 
io.addr_info.acpi_info.acpi_handle = handle;
 
/* _IFT tells us the interface type: KCS, BT, etc */
status = acpi_evaluate_integer(handle, "_IFT", NULL, );
if (ACPI_FAILURE(status)) {
-   dev_err(>dev,
-   "Could not find ACPI IPMI interface type\n");
+   dev_err(dev, "Could not find ACPI IPMI interface type\n");
return -EINVAL;
}
 
@@ -349,10 +349,11 @@ static int acpi_ipmi_probe(struct platform_device *pdev)
case 4: /* SSIF, just ignore */
return -ENODEV;
default:
-   dev_info(>dev, "unknown IPMI type %lld\n", tmp);
+   dev_info(dev, "unknown IPMI type %lld\n", tmp);
return -EINVAL;
}
 
+   io.dev = dev;
io.regsize = DEFAULT_REGSIZE;
io.regshift = 0;
 
@@ -376,9 +377,7 @@ static int acpi_ipmi_probe(struct platform_device *pdev)
 
io.slave_addr = find_slave_address(, io.slave_addr);
 
-   io.dev = >dev;
-
-   dev_info(io.dev, "%pR regsize %d spacing %d irq %d\n",
+   dev_info(dev, "%pR regsize %d spacing %d irq %d\n",
 res, io.regsize, io.regspacing, io.irq);
 
request_module("acpi_ipmi");
-- 
2.30.2

[PATCH v1 07/10] ipmi_si: Get rid of ->addr_source_cleanup()

[Andy Shevchenko]

The ->addr_source_cleanup() callback is solely used by PCI driver
and only for one purpose, i.e. to disable device. Get rid of
->addr_source_cleanup() by switching to PCI managed API.

Signed-off-by: Andy Shevchenko 
---
 drivers/char/ipmi/ipmi_si.h  |  2 --
 drivers/char/ipmi/ipmi_si_intf.c |  4 
 drivers/char/ipmi/ipmi_si_pci.c  | 18 ++
 3 files changed, 2 insertions(+), 22 deletions(-)

diff --git a/drivers/char/ipmi/ipmi_si.h b/drivers/char/ipmi/ipmi_si.h
index fd3167d1e1e9..53463f7762e0 100644
--- a/drivers/char/ipmi/ipmi_si.h
+++ b/drivers/char/ipmi/ipmi_si.h
@@ -51,8 +51,6 @@ struct si_sm_io {
enum ipmi_addr_space addr_space;
unsigned long addr_data;
enum ipmi_addr_src addr_source; /* ACPI, PCI, SMBIOS, hardcode, etc. */
-   void (*addr_source_cleanup)(struct si_sm_io *io);
-   void *addr_source_data;
union ipmi_smi_info_union addr_info;
 
int (*io_setup)(struct si_sm_io *info);
diff --git a/drivers/char/ipmi/ipmi_si_intf.c b/drivers/char/ipmi/ipmi_si_intf.c
index ff448098f185..1f568cc88b39 100644
--- a/drivers/char/ipmi/ipmi_si_intf.c
+++ b/drivers/char/ipmi/ipmi_si_intf.c
@@ -2203,10 +2203,6 @@ static void shutdown_smi(void *send_info)
if (smi_info->handlers)
smi_info->handlers->cleanup(smi_info->si_sm);
 
-   if (smi_info->io.addr_source_cleanup) {
-   smi_info->io.addr_source_cleanup(_info->io);
-   smi_info->io.addr_source_cleanup = NULL;
-   }
if (smi_info->io.io_cleanup) {
smi_info->io.io_cleanup(_info->io);
smi_info->io.io_cleanup = NULL;
diff --git a/drivers/char/ipmi/ipmi_si_pci.c b/drivers/char/ipmi/ipmi_si_pci.c
index 95bbcfba5408..0bc7efb6902c 100644
--- a/drivers/char/ipmi/ipmi_si_pci.c
+++ b/drivers/char/ipmi/ipmi_si_pci.c
@@ -21,13 +21,6 @@ MODULE_PARM_DESC(trypci, "Setting this to zero will disable 
the"
 
 #define PCI_DEVICE_ID_HP_MMC 0x121A
 
-static void ipmi_pci_cleanup(struct si_sm_io *io)
-{
-   struct pci_dev *pdev = io->addr_source_data;
-
-   pci_disable_device(pdev);
-}
-
 static int ipmi_pci_probe_regspacing(struct si_sm_io *io)
 {
if (io->si_type == SI_KCS) {
@@ -97,15 +90,12 @@ static int ipmi_pci_probe(struct pci_dev *pdev,
return -ENOMEM;
}
 
-   rv = pci_enable_device(pdev);
+   rv = pcim_enable_device(pdev);
if (rv) {
dev_err(>dev, "couldn't enable PCI device\n");
return rv;
}
 
-   io.addr_source_cleanup = ipmi_pci_cleanup;
-   io.addr_source_data = pdev;
-
if (pci_resource_flags(pdev, 0) & IORESOURCE_IO) {
io.addr_space = IPMI_IO_ADDR_SPACE;
io.io_setup = ipmi_si_port_setup;
@@ -128,11 +118,7 @@ static int ipmi_pci_probe(struct pci_dev *pdev,
dev_info(>dev, "%pR regsize %d spacing %d irq %d\n",
 >resource[0], io.regsize, io.regspacing, io.irq);
 
-   rv = ipmi_si_add_smi();
-   if (rv)
-   pci_disable_device(pdev);
-
-   return rv;
+   return ipmi_si_add_smi();
 }
 
 static void ipmi_pci_remove(struct pci_dev *pdev)
-- 
2.30.2

[PATCH v1 06/10] ipmi_si: Reuse si_to_str array in ipmi_hardcode_init_one()

[Andy Shevchenko]

Instead of making the comparison one by one, reuse si_to_str array
in ipmi_hardcode_init_one() in conjunction with match_string() API.

Signed-off-by: Andy Shevchenko 
---
 drivers/char/ipmi/ipmi_si.h  |  3 +++
 drivers/char/ipmi/ipmi_si_hardcode.c | 23 +--
 drivers/char/ipmi/ipmi_si_intf.c |  2 --
 3 files changed, 12 insertions(+), 16 deletions(-)

diff --git a/drivers/char/ipmi/ipmi_si.h b/drivers/char/ipmi/ipmi_si.h
index bac0ff86e48e..fd3167d1e1e9 100644
--- a/drivers/char/ipmi/ipmi_si.h
+++ b/drivers/char/ipmi/ipmi_si.h
@@ -22,6 +22,9 @@ enum si_type {
SI_TYPE_INVALID, SI_KCS, SI_SMIC, SI_BT
 };
 
+/* 'invalid' to allow a firmware-specified interface to be disabled */
+static __maybe_unused const char *const si_to_str[] = { "invalid", "kcs", 
"smic", "bt" };
+
 enum ipmi_addr_space {
IPMI_IO_ADDR_SPACE, IPMI_MEM_ADDR_SPACE
 };
diff --git a/drivers/char/ipmi/ipmi_si_hardcode.c 
b/drivers/char/ipmi/ipmi_si_hardcode.c
index f6ece7569504..cf3797523469 100644
--- a/drivers/char/ipmi/ipmi_si_hardcode.c
+++ b/drivers/char/ipmi/ipmi_si_hardcode.c
@@ -80,26 +80,21 @@ static void __init ipmi_hardcode_init_one(const char 
*si_type_str,
  enum ipmi_addr_space addr_space)
 {
struct ipmi_plat_data p;
+   int t;
 
memset(, 0, sizeof(p));
 
p.iftype = IPMI_PLAT_IF_SI;
-   if (!si_type_str || !*si_type_str || strcmp(si_type_str, "kcs") == 0) {
+   if (!si_type_str || !*si_type_str) {
p.type = SI_KCS;
-   } else if (strcmp(si_type_str, "smic") == 0) {
-   p.type = SI_SMIC;
-   } else if (strcmp(si_type_str, "bt") == 0) {
-   p.type = SI_BT;
-   } else if (strcmp(si_type_str, "invalid") == 0) {
-   /*
-* Allow a firmware-specified interface to be
-* disabled.
-*/
-   p.type = SI_TYPE_INVALID;
} else {
-   pr_warn("Interface type specified for interface %d, was 
invalid: %s\n",
-   i, si_type_str);
-   return;
+   t = match_string(si_to_str, ARRAY_SIZE(si_to_str), si_type_str);
+   if (t < 0) {
+   pr_warn("Interface type specified for interface %d, was 
invalid: %s\n",
+   i, si_type_str);
+   return;
+   }
+   p.type = t;
}
 
p.regsize = regsizes[i];
diff --git a/drivers/char/ipmi/ipmi_si_intf.c b/drivers/char/ipmi/ipmi_si_intf.c
index be41a473e3c2..ff448098f185 100644
--- a/drivers/char/ipmi/ipmi_si_intf.c
+++ b/drivers/char/ipmi/ipmi_si_intf.c
@@ -70,8 +70,6 @@ enum si_intf_state {
 #define IPMI_BT_INTMASK_CLEAR_IRQ_BIT  2
 #define IPMI_BT_INTMASK_ENABLE_IRQ_BIT 1
 
-static const char * const si_to_str[] = { "invalid", "kcs", "smic", "bt" };
-
 static bool initialized;
 
 /*
-- 
2.30.2

[PATCH v1 10/10] ipmi_si: Join string literals back

[Andy Shevchenko]

For easy grepping on debug purposes join string literals back in
the messages.

No functional change.

Signed-off-by: Andy Shevchenko 
---
 drivers/char/ipmi/ipmi_msghandler.c  |  3 +-
 drivers/char/ipmi/ipmi_si_hardcode.c | 50 +---
 drivers/char/ipmi/ipmi_si_hotmod.c   |  5 ++-
 drivers/char/ipmi/ipmi_si_intf.c | 25 +-
 drivers/char/ipmi/ipmi_si_pci.c  |  4 +--
 drivers/char/ipmi/ipmi_si_platform.c | 17 +-
 6 files changed, 38 insertions(+), 66 deletions(-)

diff --git a/drivers/char/ipmi/ipmi_msghandler.c 
b/drivers/char/ipmi/ipmi_msghandler.c
index c7d37366d7bb..aaca8873a486 100644
--- a/drivers/char/ipmi/ipmi_msghandler.c
+++ b/drivers/char/ipmi/ipmi_msghandler.c
@@ -5207,7 +5207,6 @@ module_exit(cleanup_ipmi);
 module_init(ipmi_init_msghandler_mod);
 MODULE_LICENSE("GPL");
 MODULE_AUTHOR("Corey Minyard ");
-MODULE_DESCRIPTION("Incoming and outgoing message routing for an IPMI"
-  " interface.");
+MODULE_DESCRIPTION("Incoming and outgoing message routing for an IPMI 
interface.");
 MODULE_VERSION(IPMI_DRIVER_VERSION);
 MODULE_SOFTDEP("post: ipmi_devintf");
diff --git a/drivers/char/ipmi/ipmi_si_hardcode.c 
b/drivers/char/ipmi/ipmi_si_hardcode.c
index cf3797523469..47eee958edcc 100644
--- a/drivers/char/ipmi/ipmi_si_hardcode.c
+++ b/drivers/char/ipmi/ipmi_si_hardcode.c
@@ -32,47 +32,29 @@ static int slave_addrs[SI_MAX_PARMS] __initdata;
 static unsigned int num_slave_addrs __initdata;
 
 module_param_string(type, si_type_str, MAX_SI_TYPE_STR, 0);
-MODULE_PARM_DESC(type, "Defines the type of each interface, each"
-" interface separated by commas.  The types are 'kcs',"
-" 'smic', and 'bt'.  For example si_type=kcs,bt will set"
-" the first interface to kcs and the second to bt");
+MODULE_PARM_DESC(type,
+"Defines the type of each interface, each interface separated 
by commas.  The types are 'kcs', 'smic', and 'bt'.  For example si_type=kcs,bt 
will set the first interface to kcs and the second to bt");
 module_param_hw_array(addrs, ulong, iomem, _addrs, 0);
-MODULE_PARM_DESC(addrs, "Sets the memory address of each interface, the"
-" addresses separated by commas.  Only use if an interface"
-" is in memory.  Otherwise, set it to zero or leave"
-" it blank.");
+MODULE_PARM_DESC(addrs,
+"Sets the memory address of each interface, the addresses 
separated by commas.  Only use if an interface is in memory.  Otherwise, set it 
to zero or leave it blank.");
 module_param_hw_array(ports, uint, ioport, _ports, 0);
-MODULE_PARM_DESC(ports, "Sets the port address of each interface, the"
-" addresses separated by commas.  Only use if an interface"
-" is a port.  Otherwise, set it to zero or leave"
-" it blank.");
+MODULE_PARM_DESC(ports,
+"Sets the port address of each interface, the addresses 
separated by commas.  Only use if an interface is a port.  Otherwise, set it to 
zero or leave it blank.");
 module_param_hw_array(irqs, int, irq, _irqs, 0);
-MODULE_PARM_DESC(irqs, "Sets the interrupt of each interface, the"
-" addresses separated by commas.  Only use if an interface"
-" has an interrupt.  Otherwise, set it to zero or leave"
-" it blank.");
+MODULE_PARM_DESC(irqs,
+"Sets the interrupt of each interface, the addresses separated 
by commas.  Only use if an interface has an interrupt.  Otherwise, set it to 
zero or leave it blank.");
 module_param_hw_array(regspacings, int, other, _regspacings, 0);
-MODULE_PARM_DESC(regspacings, "The number of bytes between the start address"
-" and each successive register used by the interface.  For"
-" instance, if the start address is 0xca2 and the spacing"
-" is 2, then the second address is at 0xca4.  Defaults"
-" to 1.");
+MODULE_PARM_DESC(regspacings,
+"The number of bytes between the start address and each 
successive register used by the interface.  For instance, if the start address 
is 0xca2 and the spacing is 2, then the second address is at 0xca4.  Defaults 
to 1.");
 module_param_hw_array(regsizes, int, other, _regsizes, 0);
-MODULE_PARM_DESC(regsizes, "The size of the specific IPMI register in bytes."
-" This should generally be 1, 2, 4, or 8 for an 8-bit,"
-" 16-bit, 32-bit, or 64-bit register.  Use this if you"
-" the 8-bit IPMI register has to be read from a larger"
-" register.");
+MODULE_PARM_DESC(regsizes,
+"The size of the specific IPMI register in bytes. This should 
generally be 1, 2, 4, or 8 for an 8-bit, 16-bit, 32-bit, or 64-bit register.  
Use this if you the 8-bit IPMI register has to be read from a larger 
register.");
 module_param_hw_array(regshifts, int, other, 

[PATCH v1 04/10] ipmi_si: Use proper ACPI macros to check error code for failures

[Andy Shevchenko]

Instead of direct comparison, use proper ACPI macros to check error code
for failures.

While at it, drop unneeded 'else' keyword.

Signed-off-by: Andy Shevchenko 
---
 drivers/char/ipmi/ipmi_si_platform.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/char/ipmi/ipmi_si_platform.c 
b/drivers/char/ipmi/ipmi_si_platform.c
index 954c297b459b..023c88ea9c4c 100644
--- a/drivers/char/ipmi/ipmi_si_platform.c
+++ b/drivers/char/ipmi/ipmi_si_platform.c
@@ -85,18 +85,18 @@ static int acpi_gpe_irq_setup(struct si_sm_io *io)
  ACPI_GPE_LEVEL_TRIGGERED,
  _acpi_gpe,
  io);
-   if (status != AE_OK) {
+   if (ACPI_FAILURE(status)) {
dev_warn(io->dev,
 "Unable to claim ACPI GPE %d, running polled\n",
 io->irq);
io->irq = 0;
return -EINVAL;
-   } else {
-   io->irq_cleanup = acpi_gpe_irq_cleanup;
-   ipmi_irq_finish_setup(io);
-   dev_info(io->dev, "Using ACPI GPE %d\n", io->irq);
-   return 0;
}
+
+   io->irq_cleanup = acpi_gpe_irq_cleanup;
+   ipmi_irq_finish_setup(io);
+   dev_info(io->dev, "Using ACPI GPE %d\n", io->irq);
+   return 0;
 }
 #endif
 
-- 
2.30.2

[PATCH v1 02/10] ipmi_si: Remove bogus err_free label

[Andy Shevchenko]

There is no more 'free' in the error path, so drop the label and
return errors inline.

Signed-off-by: Andy Shevchenko 
---
 drivers/char/ipmi/ipmi_si_platform.c | 17 +
 1 file changed, 5 insertions(+), 12 deletions(-)

diff --git a/drivers/char/ipmi/ipmi_si_platform.c 
b/drivers/char/ipmi/ipmi_si_platform.c
index d7bd093f80e9..009563073d30 100644
--- a/drivers/char/ipmi/ipmi_si_platform.c
+++ b/drivers/char/ipmi/ipmi_si_platform.c
@@ -314,7 +314,6 @@ static int acpi_ipmi_probe(struct platform_device *pdev)
acpi_status status;
unsigned long long tmp;
struct resource *res;
-   int rv = -EINVAL;
 
if (!si_tryacpi)
return -ENODEV;
@@ -334,7 +333,7 @@ static int acpi_ipmi_probe(struct platform_device *pdev)
if (ACPI_FAILURE(status)) {
dev_err(>dev,
"Could not find ACPI IPMI interface type\n");
-   goto err_free;
+   return -EINVAL;
}
 
switch (tmp) {
@@ -348,21 +347,18 @@ static int acpi_ipmi_probe(struct platform_device *pdev)
io.si_type = SI_BT;
break;
case 4: /* SSIF, just ignore */
-   rv = -ENODEV;
-   goto err_free;
+   return -ENODEV;
default:
dev_info(>dev, "unknown IPMI type %lld\n", tmp);
-   goto err_free;
+   return -EINVAL;
}
 
io.regsize = DEFAULT_REGSIZE;
io.regshift = 0;
 
res = ipmi_get_info_from_resources(pdev, );
-   if (!res) {
-   rv = -EINVAL;
-   goto err_free;
-   }
+   if (!res)
+   return -EINVAL;
 
/* If _GPE exists, use it; otherwise use standard interrupts */
status = acpi_evaluate_integer(handle, "_GPE", NULL, );
@@ -388,9 +384,6 @@ static int acpi_ipmi_probe(struct platform_device *pdev)
request_module("acpi_ipmi");
 
return ipmi_si_add_smi();
-
-err_free:
-   return rv;
 }
 
 static const struct acpi_device_id acpi_ipmi_match[] = {
-- 
2.30.2

[PATCH v1 09/10] ipmi_si: Drop redundant check before calling put_device()

[Andy Shevchenko]

put_device() is NULL aware, drop redundant check before calling it.

Signed-off-by: Andy Shevchenko 
---
 drivers/char/ipmi/ipmi_si_hotmod.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/char/ipmi/ipmi_si_hotmod.c 
b/drivers/char/ipmi/ipmi_si_hotmod.c
index 087f5eb1ebc0..a07ef37c0e3f 100644
--- a/drivers/char/ipmi/ipmi_si_hotmod.c
+++ b/drivers/char/ipmi/ipmi_si_hotmod.c
@@ -223,8 +223,7 @@ static int hotmod_handler(const char *val, const struct 
kernel_param *kp)
if (strcmp(pdev->name, "hotmod-ipmi-si") == 0)
platform_device_unregister(pdev);
}
-   if (dev)
-   put_device(dev);
+   put_device(dev);
}
}
rv = strlen(val);
-- 
2.30.2

[PATCH v1 01/10] ipmi_si: Switch to use platform_get_mem_or_io()

[Andy Shevchenko]

Switch to use new platform_get_mem_or_io() instead of home grown analogue.
Note, we also introduce ipmi_set_addr_data_and_space() helper here.

Signed-off-by: Andy Shevchenko 
---
 drivers/char/ipmi/ipmi_si_platform.c | 40 +++-
 1 file changed, 16 insertions(+), 24 deletions(-)

diff --git a/drivers/char/ipmi/ipmi_si_platform.c 
b/drivers/char/ipmi/ipmi_si_platform.c
index 129b5713f187..d7bd093f80e9 100644
--- a/drivers/char/ipmi/ipmi_si_platform.c
+++ b/drivers/char/ipmi/ipmi_si_platform.c
@@ -100,35 +100,32 @@ static int acpi_gpe_irq_setup(struct si_sm_io *io)
 }
 #endif
 
+static void ipmi_set_addr_data_and_space(struct resource *r, struct si_sm_io 
*io)
+{
+   io->addr_data = r->start;
+   if (resource_type(r) == IORESOURCE_IO)
+   io->addr_space = IPMI_IO_ADDR_SPACE;
+   else
+   io->addr_space = IPMI_MEM_ADDR_SPACE;
+}
+
 static struct resource *
 ipmi_get_info_from_resources(struct platform_device *pdev,
 struct si_sm_io *io)
 {
-   struct resource *res, *res_second;
+   struct resource *res, *second;
 
-   res = platform_get_resource(pdev, IORESOURCE_IO, 0);
-   if (res) {
-   io->addr_space = IPMI_IO_ADDR_SPACE;
-   } else {
-   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-   if (res)
-   io->addr_space = IPMI_MEM_ADDR_SPACE;
-   }
+   res = platform_get_mem_or_io(pdev, 0);
if (!res) {
dev_err(>dev, "no I/O or memory address\n");
return NULL;
}
-   io->addr_data = res->start;
+   ipmi_set_addr_data_and_space(res, io);
 
io->regspacing = DEFAULT_REGSPACING;
-   res_second = platform_get_resource(pdev,
-  (io->addr_space == IPMI_IO_ADDR_SPACE) ?
-   IORESOURCE_IO : IORESOURCE_MEM,
-  1);
-   if (res_second) {
-   if (res_second->start > io->addr_data)
-   io->regspacing = res_second->start - io->addr_data;
-   }
+   second = platform_get_mem_or_io(pdev, 1);
+   if (second && resource_type(second) == resource_type(res) && 
second->start > io->addr_data)
+   io->regspacing = second->start - io->addr_data;
 
return res;
 }
@@ -275,12 +272,7 @@ static int of_ipmi_probe(struct platform_device *pdev)
io.addr_source  = SI_DEVICETREE;
io.irq_setup= ipmi_std_irq_setup;
 
-   if (resource.flags & IORESOURCE_IO)
-   io.addr_space = IPMI_IO_ADDR_SPACE;
-   else
-   io.addr_space = IPMI_MEM_ADDR_SPACE;
-
-   io.addr_data= resource.start;
+   ipmi_set_addr_data_and_space(, );
 
io.regsize  = regsize ? be32_to_cpup(regsize) : DEFAULT_REGSIZE;
io.regspacing   = regspacing ? be32_to_cpup(regspacing) : 
DEFAULT_REGSPACING;
-- 
2.30.2

Re: [PATCH] nds32: flush_dcache_page: use page_mapping_file to avoid races with swapoff

[Matthew Wilcox]

On Tue, Mar 30, 2021 at 08:51:26PM +0300, Mike Rapoport wrote:
> From: Mike Rapoport 
> 
> Commit cb9f753a3731 ("mm: fix races between swapoff and flush dcache")
> updated flush_dcache_page implementations on several architectures to use
> page_mapping_file() in order to avoid races between page_mapping() and
> swapoff().
> 
> This update missed arch/nds32 and there is a possibility of a race there.
> 
> Replace page_mapping() with page_mapping_file() in nds32 implementation of
> flush_dcache_page().
> 
> Fixes: cb9f753a3731 ("mm: fix races between swapoff and flush dcache")
> Signed-off-by: Mike Rapoport 

Reviewed-by: Matthew Wilcox (Oracle) 

Re: [PATCH] mtd: intel-spi: add is_protected and is_bios_locked knobs

[Joe Perches]

On Tue, 2021-03-30 at 18:54 +0300, Tomas Winkler wrote:
> From: Tamar Mashiah 
[]
> the region protection status is exposed via sysfs file
> as the manufacturing will need the both files in order to validate
> that the device is properly sealed.
[]
> diff --git a/drivers/mtd/spi-nor/controllers/intel-spi.c 
> b/drivers/mtd/spi-nor/controllers/intel-spi.c
[]
> +static ssize_t intel_spi_is_protected_show(struct device *dev,
> +struct device_attribute *attr, char 
> *buf)
> +{
> + struct intel_spi *ispi = dev_get_drvdata(dev);
> +
> + return sysfs_emit(buf, "%d", ispi->is_protected);

These should also include a newline in the format.  i.e.:

return sysfs_emit(buf, "%d\n", ispi->is_protected);


> +static ssize_t intel_spi_bios_lock_show(struct device *dev,
> + struct device_attribute *attr, char 
> *buf)
> +{
> + struct intel_spi *ispi = dev_get_drvdata(dev);
> +
> + return sysfs_emit(buf, "%d", ispi->is_bios_locked);

etc...

Re: [PATCH] USB: serial: xr: fix CSIZE handling

[Manivannan Sadhasivam]

On Tue, Mar 30, 2021 at 04:37:16PM +0200, Johan Hovold wrote:
> The XR21V141X does not have a 5- or 6-bit mode, but the current
> implementation failed to properly restore the old setting when CS5 or
> CS6 was requested. Instead an invalid request would be sent to the
> device.
> 
> Fixes: c2d405aa86b4 ("USB: serial: add MaxLinear/Exar USB to Serial driver")
> Signed-off-by: Johan Hovold 

Reviewed-by: Manivannan Sadhasivam 

Thanks,
Mani

> ---
>  drivers/usb/serial/xr_serial.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/drivers/usb/serial/xr_serial.c b/drivers/usb/serial/xr_serial.c
> index 0ca04906da4b..c59c8b47a120 100644
> --- a/drivers/usb/serial/xr_serial.c
> +++ b/drivers/usb/serial/xr_serial.c
> @@ -467,6 +467,11 @@ static void xr_set_termios(struct tty_struct *tty,
>   termios->c_cflag &= ~CSIZE;
>   if (old_termios)
>   termios->c_cflag |= old_termios->c_cflag & CSIZE;
> + else
> + termios->c_cflag |= CS8;
> +
> + if (C_CSIZE(tty) == CS7)
> + bits |= XR21V141X_UART_DATA_7;
>   else
>   bits |= XR21V141X_UART_DATA_8;
>   break;
> -- 
> 2.26.3
> 

Re: [PATCH bpf-next] bpf: check flags in 'bpf_ringbuf_discard()' and 'bpf_ringbuf_submit()'

[Song Liu]

> On Mar 30, 2021, at 7:22 AM, Pedro Tammela  wrote:
> 
> Em seg., 29 de mar. de 2021 às 13:10, Song Liu  
> escreveu:
>> 
>> 
>> 
>>> On Mar 28, 2021, at 9:10 AM, Pedro Tammela  wrote:
>>> 
>>> The current code only checks flags in 'bpf_ringbuf_output()'.
>>> 
>>> Signed-off-by: Pedro Tammela 
>>> ---
>>> include/uapi/linux/bpf.h   |  8 
>>> kernel/bpf/ringbuf.c   | 13 +++--
>>> tools/include/uapi/linux/bpf.h |  8 
>>> 3 files changed, 19 insertions(+), 10 deletions(-)
>>> 
>>> diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
>>> index 100cb2e4c104..232b5e5dd045 100644
>>> --- a/include/uapi/linux/bpf.h
>>> +++ b/include/uapi/linux/bpf.h
>>> @@ -4073,7 +4073,7 @@ union bpf_attr {
>>> *Valid pointer with *size* bytes of memory available; NULL,
>>> *otherwise.
>>> *
>>> - * void bpf_ringbuf_submit(void *data, u64 flags)
>>> + * int bpf_ringbuf_submit(void *data, u64 flags)
>> 
>> This should be "long" instead of "int".
>> 
>>> *Description
>>> *Submit reserved ring buffer sample, pointed to by *data*.
>>> *If **BPF_RB_NO_WAKEUP** is specified in *flags*, no 
>>> notification
>>> @@ -4083,9 +4083,9 @@ union bpf_attr {
>>> *If **BPF_RB_FORCE_WAKEUP** is specified in *flags*, 
>>> notification
>>> *of new data availability is sent unconditionally.
>>> *Return
>>> - *   Nothing. Always succeeds.
>>> + *   0 on success, or a negative error in case of failure.
>>> *
>>> - * void bpf_ringbuf_discard(void *data, u64 flags)
>>> + * int bpf_ringbuf_discard(void *data, u64 flags)
>> 
>> Ditto. And same for tools/include/uapi/linux/bpf.h
>> 
>>> *Description
>>> *Discard reserved ring buffer sample, pointed to by *data*.
>>> *If **BPF_RB_NO_WAKEUP** is specified in *flags*, no 
>>> notification
>>> @@ -4095,7 +4095,7 @@ union bpf_attr {
>>> *If **BPF_RB_FORCE_WAKEUP** is specified in *flags*, 
>>> notification
>>> *of new data availability is sent unconditionally.
>>> *Return
>>> - *   Nothing. Always succeeds.
>>> + *   0 on success, or a negative error in case of failure.
>>> *
>>> * u64 bpf_ringbuf_query(void *ringbuf, u64 flags)
>>> *Description
>>> diff --git a/kernel/bpf/ringbuf.c b/kernel/bpf/ringbuf.c
>>> index f25b719ac786..f76dafe2427e 100644
>>> --- a/kernel/bpf/ringbuf.c
>>> +++ b/kernel/bpf/ringbuf.c
>>> @@ -397,26 +397,35 @@ static void bpf_ringbuf_commit(void *sample, u64 
>>> flags, bool discard)
>>> 
>>> BPF_CALL_2(bpf_ringbuf_submit, void *, sample, u64, flags)
>>> {
>>> + if (unlikely(flags & ~(BPF_RB_NO_WAKEUP | BPF_RB_FORCE_WAKEUP)))
>>> + return -EINVAL;
>> 
>> We can move this check to bpf_ringbuf_commit().
> 
> I don't believe we can because in 'bpf_ringbuf_output()' the flag
> checking in 'bpf_ringbuf_commit()' is already
> too late.

I see. Let's keep it in current functions then. 

Thanks,
Song

Re: [PATCH mm v2] mm, kasan: fix for "integrate page_alloc init with HW_TAGS"

[Sergei Trofimovich]

On Tue, 30 Mar 2021 18:44:09 +0200
Vlastimil Babka  wrote:

> On 3/30/21 6:37 PM, Andrey Konovalov wrote:
> > My commit "integrate page_alloc init with HW_TAGS" changed the order of
> > kernel_unpoison_pages() and kernel_init_free_pages() calls. This leads
> > to complaints from the page unpoisoning code, as the poison pattern gets
> > overwritten for __GFP_ZERO allocations.
> > 
> > Fix by restoring the initial order. Also add a warning comment.
> > 
> > Reported-by: Vlastimil Babka 
> > Reported-by: Sergei Trofimovich 
> > Signed-off-by: Andrey Konovalov   
> 
> Tested that the bug indeed occurs in -next and is fixed by this. Thanks.

Reviewed-by: Sergei Trofimovich 

> > ---
> >  mm/page_alloc.c | 8 +++-
> >  1 file changed, 7 insertions(+), 1 deletion(-)
> > 
> > diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> > index 033bd92e8398..d2c020563c0b 100644
> > --- a/mm/page_alloc.c
> > +++ b/mm/page_alloc.c
> > @@ -2328,6 +2328,13 @@ inline void post_alloc_hook(struct page *page, 
> > unsigned int order,
> > arch_alloc_page(page, order);
> > debug_pagealloc_map_pages(page, 1 << order);
> >  
> > +   /*
> > +* Page unpoisoning must happen before memory initialization.
> > +* Otherwise, the poison pattern will be overwritten for __GFP_ZERO
> > +* allocations and the page unpoisoning code will complain.
> > +*/
> > +   kernel_unpoison_pages(page, 1 << order);
> > +
> > /*
> >  * As memory initialization might be integrated into KASAN,
> >  * kasan_alloc_pages and kernel_init_free_pages must be
> > @@ -2338,7 +2345,6 @@ inline void post_alloc_hook(struct page *page, 
> > unsigned int order,
> > if (init && !kasan_has_integrated_init())
> > kernel_init_free_pages(page, 1 << order);
> >  
> > -   kernel_unpoison_pages(page, 1 << order);
> > set_page_owner(page, order, gfp_flags);
> >  }
> >  
> >   
> 


-- 

  Sergei

arch/x86/lib/copy_mc.c:30:1: warning: no previous prototype for 'copy_mc_fragile_handle_tail'

[kernel test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   1e43c377a79f9189fea8f2711b399d4e8b4e609b
commit: ec6347bb43395cb92126788a1a5b25302543f815 x86, powerpc: Rename 
memcpy_mcsafe() to copy_mc_to_{user, kernel}()
date:   6 months ago
config: x86_64-randconfig-r002-20210330 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
reproduce (this is a W=1 build):
# 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ec6347bb43395cb92126788a1a5b25302543f815
git remote add linus 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout ec6347bb43395cb92126788a1a5b25302543f815
# save the attached .config to linux build tree
make W=1 ARCH=x86_64 

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

All warnings (new ones prefixed by >>):

>> arch/x86/lib/copy_mc.c:30:1: warning: no previous prototype for 
>> 'copy_mc_fragile_handle_tail' [-Wmissing-prototypes]
  30 | copy_mc_fragile_handle_tail(char *to, char *from, unsigned len)
 | ^~~


vim +/copy_mc_fragile_handle_tail +30 arch/x86/lib/copy_mc.c

24  
25  /*
26   * Similar to copy_user_handle_tail, probe for the write fault point, or
27   * source exception point.
28   */
29  __visible notrace unsigned long
  > 30  copy_mc_fragile_handle_tail(char *to, char *from, unsigned len)
31  {
32  for (; len; --len, to++, from++)
33  if (copy_mc_fragile(to, from, 1))
34  break;
35  return len;
36  }
37  #else
38  /*
39   * No point in doing careful copying, or consulting a static key when
40   * there is no #MC handler in the CONFIG_X86_MCE=n case.
41   */
42  void enable_copy_mc_fragile(void)
43  {
44  }
45  #define copy_mc_fragile_enabled (0)
46  #endif
47  

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


.config.gz
Description: application/gzip

Re: [PATCH v5 1/1] fs: Allow no_new_privs tasks to call chroot(2)

[Mickaël Salaün]

On 30/03/2021 19:19, Casey Schaufler wrote:
> On 3/30/2021 10:01 AM, Mickaël Salaün wrote:
>> Hi,
>>
>> Is there new comments on this patch? Could we move forward?
> 
> I don't see that new comments are necessary when I don't see
> that you've provided compelling counters to some of the old ones.

Which ones? I don't buy your argument about the beauty of CAP_SYS_CHROOT.

> It's possible to use minimal privilege with CAP_SYS_CHROOT.

CAP_SYS_CHROOT can lead to privilege escalation.

> It looks like namespaces provide alternatives for all your
> use cases.

I explained in the commit message why it is not the case. In a nutshell,
namespaces bring complexity which may not be required. When designing a
secure system, we want to avoid giving access to such complexity to
untrusted processes (i.e. more complexity leads to more bugs). An
unprivileged chroot would enable to give just the minimum feature to
drop some accesses. Of course it is not enough on its own, but it can be
combined with existing (and future) security features.

> The constraints required to make this work are quite
> limiting. Where is the real value add?

As explain in the commit message, it is useful when hardening
applications (e.g. network services, browsers, parsers, etc.). We don't
want an untrusted (or compromised) application to have CAP_SYS_CHROOT
nor (complex) namespace access.

> 
>>
>> Regards,
>>  Mickaël
>>
>>
>> On 16/03/2021 21:36, Mickaël Salaün wrote:
>>> From: Mickaël Salaün 
>>>
>>> Being able to easily change root directories enables to ease some
>>> development workflow and can be used as a tool to strengthen
>>> unprivileged security sandboxes.  chroot(2) is not an access-control
>>> mechanism per se, but it can be used to limit the absolute view of the
>>> filesystem, and then limit ways to access data and kernel interfaces
>>> (e.g. /proc, /sys, /dev, etc.).
>>>
>>> Users may not wish to expose namespace complexity to potentially
>>> malicious processes, or limit their use because of limited resources.
>>> The chroot feature is much more simple (and limited) than the mount
>>> namespace, but can still be useful.  As for containers, users of
>>> chroot(2) should take care of file descriptors or data accessible by
>>> other means (e.g. current working directory, leaked FDs, passed FDs,
>>> devices, mount points, etc.).  There is a lot of literature that discuss
>>> the limitations of chroot, and users of this feature should be aware of
>>> the multiple ways to bypass it.  Using chroot(2) for security purposes
>>> can make sense if it is combined with other features (e.g. dedicated
>>> user, seccomp, LSM access-controls, etc.).
>>>
>>> One could argue that chroot(2) is useless without a properly populated
>>> root hierarchy (i.e. without /dev and /proc).  However, there are
>>> multiple use cases that don't require the chrooting process to create
>>> file hierarchies with special files nor mount points, e.g.:
>>> * A process sandboxing itself, once all its libraries are loaded, may
>>>   not need files other than regular files, or even no file at all.
>>> * Some pre-populated root hierarchies could be used to chroot into,
>>>   provided for instance by development environments or tailored
>>>   distributions.
>>> * Processes executed in a chroot may not require access to these special
>>>   files (e.g. with minimal runtimes, or by emulating some special files
>>>   with a LD_PRELOADed library or seccomp).
>>>
>>> Allowing a task to change its own root directory is not a threat to the
>>> system if we can prevent confused deputy attacks, which could be
>>> performed through execution of SUID-like binaries.  This can be
>>> prevented if the calling task sets PR_SET_NO_NEW_PRIVS on itself with
>>> prctl(2).  To only affect this task, its filesystem information must not
>>> be shared with other tasks, which can be achieved by not passing
>>> CLONE_FS to clone(2).  A similar no_new_privs check is already used by
>>> seccomp to avoid the same kind of security issues.  Furthermore, because
>>> of its security use and to avoid giving a new way for attackers to get
>>> out of a chroot (e.g. using /proc//root, or chroot/chdir), an
>>> unprivileged chroot is only allowed if the calling process is not
>>> already chrooted.  This limitation is the same as for creating user
>>> namespaces.
>>>
>>> This change may not impact systems relying on other permission models
>>> than POSIX capabilities (e.g. Tomoyo).  Being able to use chroot(2) on
>>> such systems may require to update their security policies.
>>>
>>> Only the chroot system call is relaxed with this no_new_privs check; the
>>> init_chroot() helper doesn't require such change.
>>>
>>> Allowing unprivileged users to use chroot(2) is one of the initial
>>> objectives of no_new_privs:
>>> https://www.kernel.org/doc/html/latest/userspace-api/no_new_privs.html
>>> This patch is a follow-up of a previous one sent by Andy Lutomirski:
>>> 

Re: [Patch bpf-next] net: filter: Remove unused bpf_load_pointer

[Song Liu]

On Mon, Mar 29, 2021 at 7:11 PM He Fengqing  wrote:
>
> Remove unused bpf_load_pointer function in filter.h
>
> Signed-off-by: He Fengqing 

Acked-by: Song Liu 

[...]

Re: [PATCH v3 01/17] cmdline: Add generic function to build command line.

[H. Nikolaus Schaller]

> Am 30.03.2021 um 19:27 schrieb Daniel Walker :
> 
> On Fri, Mar 26, 2021 at 01:44:48PM +, Christophe Leroy wrote:
>> This code provides architectures with a way to build command line
>> based on what is built in the kernel and what is handed over by the
>> bootloader, based on selected compile-time options.
>> 
>> Signed-off-by: Christophe Leroy 
>> ---
>> v3:
>> - Addressed comments from Will
>> - Added capability to have src == dst
>> ---
>> include/linux/cmdline.h | 57 +
>> 1 file changed, 57 insertions(+)
>> create mode 100644 include/linux/cmdline.h
>> 
>> diff --git a/include/linux/cmdline.h b/include/linux/cmdline.h
>> new file mode 100644
>> index ..dea87edd41be
>> --- /dev/null
>> +++ b/include/linux/cmdline.h
>> @@ -0,0 +1,57 @@
>> +/* SPDX-License-Identifier: GPL-2.0 */
>> +#ifndef _LINUX_CMDLINE_H
>> +#define _LINUX_CMDLINE_H
>> +
>> +#include 
>> +
>> +/* Allow architectures to override strlcat, powerpc can't use strings so 
>> early */
>> +#ifndef cmdline_strlcat
>> +#define cmdline_strlcat strlcat
>> +#endif
>> +
>> +/*
>> + * This function will append or prepend a builtin command line to the 
>> command
>> + * line provided by the bootloader. Kconfig options can be used to alter
>> + * the behavior of this builtin command line.
>> + * @dst: The destination of the final appended/prepended string.
>> + * @src: The starting string or NULL if there isn't one.
>> + * @len: the length of dest buffer.
>> + */
> 
> Append or prepend ? Cisco requires both at the same time. This is why my
> implementation provides both. I can't use this with both at once.

Just an idea: what about defining CMDLINE as a pattern where e.g. "$$" or "%%"
is replaced by the boot loader command line?

Then you can formulate replace, prepend, append, prepend+append with a single
CONFIG setting.

It may be a little more complex in code (scanning for the pattern and replacing
it and take care to temporary memory) but IMHO it could be worth to consider.

BR,
Nikolaus Schaller

Re: [PATCH v2 4/8] block: introduce bio_required_sector_alignment()

[Christoph Hellwig]

On Thu, Mar 25, 2021 at 09:26:05PM +, Satya Tangirala wrote:
> +/*
> + * The required sector alignment for a bio. The number of sectors in any bio
> + * that's constructed/split must be aligned to this value.
> + */
> +static inline unsigned int bio_required_sector_alignment(struct bio *bio)
> +{
> + struct request_queue *q = bio->bi_bdev->bd_disk->queue;
> +
> + return max(queue_logical_block_size(q) >> SECTOR_SHIFT,
> +blk_crypto_bio_sectors_alignment(bio));
> +}

It might make more sense to just have a field in the request queue
for the max alignment so that the fast path just looks at one field.
Then the various setup time functions would update it to the maximum
required.

Re: [PATCH 0/4] PHY: Update Cadence Torrent PHY multilink configurations specific to TI

[Vinod Koul]

On 04-03-21, 07:08, Swapnil Jakhade wrote:
> This patch series updates Torrent PHY driver for multilink configurations
> specific to TI platform. It also adds support for configuring QSGMII in
> TI Wiz driver.
> 
> This patch series is dependent on [1] and should be applied on
> top of this.

Applied, thanks

-- 
~Vinod

Re: [PATCH v2 1/8] block: introduce blk_ksm_is_empty()

[Christoph Hellwig]

On Thu, Mar 25, 2021 at 09:26:02PM +, Satya Tangirala wrote:
> This function checks if a given keyslot manager supports any encryption
> mode/data unit size combination (and returns true if there is no such
> supported combination). Helps clean up code a little.

The name sounds a little strange to me, but the functionality looks
ok.  A kerneldoc comment might be useful to describe what it does so
that we don't have to rely on the name alone.

Re: [PATCH v3 0/6] AM64: Add SERDES driver support

[Vinod Koul]

On 10-03-21, 17:38, Kishon Vijay Abraham I wrote:
> AM64 uses the same SERDES as in J7200, however AM642 EVM doesn't
> have a clock generator (unlike J7200 base board). Here the clock from
> the SERDES has to be routed to the PCIE connector. This series adds
> support to drive reference clock output from SERDES and also adds
> SERDES (torrent) and SERDES wrapper (WIZ) bindings.
> 
> v1 of the patch series can be found @ [1]
> v2 of the patch series can be found @ [3]
> 
> Changes from v2:
> *) Sent the DT bindings as a separate series [4]
> *) Remove enabling PHY output clock in isolation mode
> 
> Changes from v1:
> *) Model the internal clocks without device tree input (Add #clock-cells
>to SERDES DT nodes for getting a reference to the clock using index
>to phandle). This is in accordance with comment given by Rob [2].
>However the existing method to model clocks from device tree is not
>removed to support upstreamed device tree.
> *) Included a patch to fix modifying static data by instance specific
>initializations.
> *) Added a fix to delete "clk_div_sel" clk provider during cleanup

Applied, thanks

-- 
~Vinod

Re: Fix hibernation in FIPS mode?

[Simo Sorce]

On Tue, 2021-03-30 at 16:46 +0200, Rafael J. Wysocki wrote:
> On Tue, Mar 30, 2021 at 12:14 AM Dexuan Cui  wrote:
> > Hi,
> > MD5 was marked incompliant with FIPS in 2009:
> > a3bef3a31a19 ("crypto: testmgr - Skip algs not flagged fips_allowed in fips 
> > mode")
> > a1915d51e8e7 ("crypto: testmgr - Mark algs allowed in fips mode")
> > 
> > But hibernation_e820_save() is still using MD5, and fails in FIPS mode
> > due to the 2018 patch:
> > 749fa17093ff ("PM / hibernate: Check the success of generating md5 digest 
> > before hibernation")
> > 
> > As a result, hibernation doesn't work when FIPS is on.
> > 
> > Do you think if hibernation_e820_save() should be changed to use a
> > FIPS-compliant algorithm like SHA-1?
> 
> I would say yes, it should.
> 
> > PS, currently it looks like FIPS mode is broken in the mainline:
> > https://www.mail-archive.com/linux-crypto@vger.kernel.org/msg49414.html


FYI, SHA-1 is not a good choice, it is only permitted in HMAC
constructions and only for specified uses. If you need to change
algorithm you should go straight to SHA-2 or SHA-3 based hashes.

HTH,
Simo.

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc

Re: Enabling pmbus power control

[Mark Brown]

On Tue, Mar 30, 2021 at 12:56:56PM -0500, Zev Weiss wrote:

> Okay, to expand a bit on the description in my initial message -- we've
> got a single chassis with multiple server boards and a single manager board
> that handles, among other things, power control for the servers.
> The manager board has one LM25066 for each attached server, which acts as
> the "power switch" for that server.  There thus really isn't any driver to
> speak of for the downstream device.

This sounds like you need a driver representing those server boards (or
the slots they plug into perhaps) that represents everything about those
boards to userspace, including power switching.  I don't see why you
wouldn't have a driver for that - it's a thing that physically exists
and clearly has some software control, and you'd presumably also expect
to represent some labelling about the slot as well.


signature.asc
Description: PGP signature

Re: [PATCH v2 2/2] thermal: qcom-spmi-temp-alarm: add support for GEN2 rev 1 PMIC peripherals

[Daniel Lezcano]

On 30/03/2021 19:49, Guru Das Srinagesh wrote:
> On Tue, Aug 04, 2020 at 11:48:30PM -0700, Stephen Boyd wrote:
>> Quoting Guru Das Srinagesh (2020-07-29 09:52:52)
>>> From: David Collins 
>>>
>>> Add support for TEMP_ALARM GEN2 PMIC peripherals with digital
>>> major revision 1.  This revision utilizes a different temperature
>>> threshold mapping than earlier revisions.
>>>
>>> Signed-off-by: David Collins 
>>> Signed-off-by: Guru Das Srinagesh 
>>> ---
>>
>> Reviewed-by: Stephen Boyd 
> 
> + Daniel Lezcano
> 
> Hi Daniel,
> 
> I just checked Linus' tree and discovered that this patch has not been
> applied - only the other patch in this series. Since this patch has been
> reviewed already, could you please check if it's good to be applied as
> well?

Applied, thanks


-- 
 Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

[PATCH 8/8] CMDLINE: arm64: convert to generic builtin command line

[Daniel Walker]

This updates the arm64 code to use the CONFIG_GENERIC_CMDLINE
option.

Cc: xe-linux-exter...@cisco.com
Signed-off-by: Daniel Walker 
---
 arch/arm64/Kconfig | 33 +-
 arch/arm64/kernel/idreg-override.c |  8 +---
 arch/arm64/kernel/setup.c  |  4 
 3 files changed, 10 insertions(+), 35 deletions(-)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index e4e1b6550115..9781ba3758b1 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -105,6 +105,7 @@ config ARM64
select GENERIC_ALLOCATOR
select GENERIC_ARCH_TOPOLOGY
select GENERIC_CLOCKEVENTS_BROADCAST
+   select GENERIC_CMDLINE
select GENERIC_CPU_AUTOPROBE
select GENERIC_CPU_VULNERABILITIES
select GENERIC_EARLY_IOREMAP
@@ -1841,38 +1842,6 @@ config ARM64_ACPI_PARKING_PROTOCOL
  protocol even if the corresponding data is present in the ACPI
  MADT table.
 
-config CMDLINE
-   string "Default kernel command string"
-   default ""
-   help
- Provide a set of default command-line options at build time by
- entering them here. As a minimum, you should specify the the
- root device (e.g. root=/dev/nfs).
-
-choice
-   prompt "Kernel command line type" if CMDLINE != ""
-   default CMDLINE_FROM_BOOTLOADER
-   help
- Choose how the kernel will handle the provided default kernel
- command line string.
-
-config CMDLINE_FROM_BOOTLOADER
-   bool "Use bootloader kernel arguments if available"
-   help
- Uses the command-line options passed by the boot loader. If
- the boot loader doesn't provide any, the default kernel command
- string provided in CMDLINE will be used.
-
-config CMDLINE_FORCE
-   bool "Always use the default kernel command string"
-   help
- Always use the default kernel command string, even if the boot
- loader passes other arguments to the kernel.
- This is useful if you cannot or don't want to change the
- command-line options your boot loader passes to the kernel.
-
-endchoice
-
 config EFI_STUB
bool
 
diff --git a/arch/arm64/kernel/idreg-override.c 
b/arch/arm64/kernel/idreg-override.c
index 83f1c4b92095..fb10cd860a26 100644
--- a/arch/arm64/kernel/idreg-override.c
+++ b/arch/arm64/kernel/idreg-override.c
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -188,11 +189,12 @@ static __init void parse_cmdline(void)
 {
const u8 *prop = get_bootargs_cmdline();
 
-   if (IS_ENABLED(CONFIG_CMDLINE_FORCE) || !prop)
-   __parse_cmdline(CONFIG_CMDLINE, true);
+   __parse_cmdline(CMDLINE_PREPEND, true);
 
-   if (!IS_ENABLED(CONFIG_CMDLINE_FORCE) && prop)
+   if (IS_ENABLED(CMDLINE_OVERRIDE) && prop)
__parse_cmdline(prop, true);
+
+   __parse_cmdline(CMDLINE_APPEND, true);
 }
 
 /* Keep checkers quiet */
diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index 61845c0821d9..01791ce5244c 100644
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -322,6 +323,9 @@ void __init __no_sanitize_address setup_arch(char 
**cmdline_p)
 * cpufeature code and early parameters.
 */
jump_label_init();
+
+   cmdline_add_builtin(boot_command_line, NULL, COMMAND_LINE_SIZE);
+
parse_early_param();
 
/*
-- 
2.25.1

[PATCH 7/8] CMDLINE: x86: convert to generic builtin command line

[Daniel Walker]

This updates the x86 code to use the CONFIG_GENERIC_CMDLINE
option.

Cc: xe-linux-exter...@cisco.com
Signed-off-by: Ruslan Ruslichenko 
Signed-off-by: Ruslan Bilovol 
Signed-off-by: Daniel Walker 
---
 arch/x86/Kconfig| 44 +
 arch/x86/kernel/setup.c | 18 ++---
 2 files changed, 3 insertions(+), 59 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 2792879d398e..73ea9589e50d 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -118,6 +118,7 @@ config X86
select EDAC_SUPPORT
select GENERIC_CLOCKEVENTS_BROADCASTif X86_64 || (X86_32 && 
X86_LOCAL_APIC)
select GENERIC_CLOCKEVENTS_MIN_ADJUST
+   select GENERIC_CMDLINE
select GENERIC_CMOS_UPDATE
select GENERIC_CPU_AUTOPROBE
select GENERIC_CPU_VULNERABILITIES
@@ -2358,49 +2359,6 @@ choice
 
 endchoice
 
-config CMDLINE_BOOL
-   bool "Built-in kernel command line"
-   help
- Allow for specifying boot arguments to the kernel at
- build time.  On some systems (e.g. embedded ones), it is
- necessary or convenient to provide some or all of the
- kernel boot arguments with the kernel itself (that is,
- to not rely on the boot loader to provide them.)
-
- To compile command line arguments into the kernel,
- set this option to 'Y', then fill in the
- boot arguments in CONFIG_CMDLINE.
-
- Systems with fully functional boot loaders (i.e. non-embedded)
- should leave this option set to 'N'.
-
-config CMDLINE
-   string "Built-in kernel command string"
-   depends on CMDLINE_BOOL
-   default ""
-   help
- Enter arguments here that should be compiled into the kernel
- image and used at boot time.  If the boot loader provides a
- command line at boot time, it is appended to this string to
- form the full kernel command line, when the system boots.
-
- However, you can use the CONFIG_CMDLINE_OVERRIDE option to
- change this behavior.
-
- In most cases, the command line (whether built-in or provided
- by the boot loader) should specify the device for the root
- file system.
-
-config CMDLINE_OVERRIDE
-   bool "Built-in command line overrides boot loader arguments"
-   depends on CMDLINE_BOOL && CMDLINE != ""
-   help
- Set this option to 'Y' to have the kernel ignore the boot loader
- command line, and use ONLY the built-in command line.
-
- This is used to work around broken boot loaders.  This should
- be set to 'N' under normal conditions.
-
 config MODIFY_LDT_SYSCALL
bool "Enable the LDT (local descriptor table)" if EXPERT
default y
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index d883176ef2ce..6444a5f1fabf 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -47,6 +47,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /*
  * max_low_pfn_mapped: highest directly mapped pfn < 4 GB
@@ -161,9 +162,6 @@ unsigned long saved_video_mode;
 #define RAMDISK_LOAD_FLAG  0x4000
 
 static char __initdata command_line[COMMAND_LINE_SIZE];
-#ifdef CONFIG_CMDLINE_BOOL
-static char __initdata builtin_cmdline[COMMAND_LINE_SIZE] = CONFIG_CMDLINE;
-#endif
 
 #if defined(CONFIG_EDD) || defined(CONFIG_EDD_MODULE)
 struct edd edd;
@@ -883,19 +881,7 @@ void __init setup_arch(char **cmdline_p)
bss_resource.start = __pa_symbol(__bss_start);
bss_resource.end = __pa_symbol(__bss_stop)-1;
 
-#ifdef CONFIG_CMDLINE_BOOL
-#ifdef CONFIG_CMDLINE_OVERRIDE
-   strlcpy(boot_command_line, builtin_cmdline, COMMAND_LINE_SIZE);
-#else
-   if (builtin_cmdline[0]) {
-   /* append boot loader cmdline to builtin */
-   strlcat(builtin_cmdline, " ", COMMAND_LINE_SIZE);
-   strlcat(builtin_cmdline, boot_command_line, COMMAND_LINE_SIZE);
-   strlcpy(boot_command_line, builtin_cmdline, COMMAND_LINE_SIZE);
-   }
-#endif
-#endif
-
+   cmdline_add_builtin(boot_command_line, NULL, COMMAND_LINE_SIZE);
strlcpy(command_line, boot_command_line, COMMAND_LINE_SIZE);
*cmdline_p = command_line;
 
-- 
2.25.1

[PATCH 6/8] drivers: firmware: efi: libstub: enable generic commandline

[Daniel Walker]

This adds code to handle the generic command line changes.
The efi code appears that it doesn't benefit as much from this design
as it could.

For example, if you had a prepend command line with "nokaslr" then
you might be helpful to re-enable it in the boot loader or dts,
but there appears to be no way to re-enable kaslr or some of the
other options.

Cc: xe-linux-exter...@cisco.com
Signed-off-by: Daniel Walker 
---
 .../firmware/efi/libstub/efi-stub-helper.c| 35 +++
 drivers/firmware/efi/libstub/efi-stub.c   |  7 
 drivers/firmware/efi/libstub/efistub.h|  1 +
 drivers/firmware/efi/libstub/x86-stub.c   | 13 +--
 4 files changed, 54 insertions(+), 2 deletions(-)

diff --git a/drivers/firmware/efi/libstub/efi-stub-helper.c 
b/drivers/firmware/efi/libstub/efi-stub-helper.c
index aa8da0a49829..c155837cedc9 100644
--- a/drivers/firmware/efi/libstub/efi-stub-helper.c
+++ b/drivers/firmware/efi/libstub/efi-stub-helper.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include  /* For CONSOLE_LOGLEVEL_* */
+#include 
 #include 
 #include 
 
@@ -172,6 +173,40 @@ int efi_printk(const char *fmt, ...)
return printed;
 }
 
+/**
+ * efi_handle_cmdline() - handle adding in building parts of the command line
+ * @cmdline:   kernel command line
+ *
+ * Add in the generic parts of the commandline and start the parsing of the
+ * command line.
+ *
+ * Return: status code
+ */
+efi_status_t efi_handle_cmdline(char const *cmdline)
+{
+   efi_status_t status;
+
+   status = efi_parse_options(CMDLINE_PREPEND);
+   if (status != EFI_SUCCESS) {
+   efi_err("Failed to parse options\n");
+   return status;
+   }
+
+   status = efi_parse_options(IS_ENABLED(CONFIG_CMDLINE_OVERRIDE) ? "" : 
cmdline);
+   if (status != EFI_SUCCESS) {
+   efi_err("Failed to parse options\n");
+   return status;
+   }
+
+   status = efi_parse_options(CMDLINE_APPEND);
+   if (status != EFI_SUCCESS) {
+   efi_err("Failed to parse options\n");
+   return status;
+   }
+
+   return EFI_SUCCESS;
+}
+
 /**
  * efi_parse_options() - Parse EFI command line options
  * @cmdline:   kernel command line
diff --git a/drivers/firmware/efi/libstub/efi-stub.c 
b/drivers/firmware/efi/libstub/efi-stub.c
index 26e69788f27a..760480248adf 100644
--- a/drivers/firmware/efi/libstub/efi-stub.c
+++ b/drivers/firmware/efi/libstub/efi-stub.c
@@ -172,6 +172,12 @@ efi_status_t __efiapi efi_pe_entry(efi_handle_t handle,
goto fail;
}
 
+#ifdef CONFIG_GENERIC_CMDLINE
+   status = efi_handle_cmdline(cmdline_ptr);
+   if (status != EFI_SUCCESS) {
+   goto fail_free_cmdline;
+   }
+#else
if (IS_ENABLED(CONFIG_CMDLINE_EXTEND) ||
IS_ENABLED(CONFIG_CMDLINE_FORCE) ||
cmdline_size == 0) {
@@ -189,6 +195,7 @@ efi_status_t __efiapi efi_pe_entry(efi_handle_t handle,
goto fail_free_cmdline;
}
}
+#endif
 
efi_info("Booting Linux Kernel...\n");
 
diff --git a/drivers/firmware/efi/libstub/efistub.h 
b/drivers/firmware/efi/libstub/efistub.h
index cde0a2ef507d..07c7f9fdfffc 100644
--- a/drivers/firmware/efi/libstub/efistub.h
+++ b/drivers/firmware/efi/libstub/efistub.h
@@ -800,6 +800,7 @@ efi_status_t efi_relocate_kernel(unsigned long *image_addr,
 unsigned long alignment,
 unsigned long min_addr);
 
+efi_status_t efi_handle_cmdline(char const *cmdline);
 efi_status_t efi_parse_options(char const *cmdline);
 
 void efi_parse_option_graphics(char *option);
diff --git a/drivers/firmware/efi/libstub/x86-stub.c 
b/drivers/firmware/efi/libstub/x86-stub.c
index f14c4ff5839f..30ad8fb7122d 100644
--- a/drivers/firmware/efi/libstub/x86-stub.c
+++ b/drivers/firmware/efi/libstub/x86-stub.c
@@ -673,6 +673,8 @@ unsigned long efi_main(efi_handle_t handle,
unsigned long bzimage_addr = (unsigned long)startup_32;
unsigned long buffer_start, buffer_end;
struct setup_header *hdr = _params->hdr;
+   unsigned long cmdline_paddr = ((u64)hdr->cmd_line_ptr |
+  ((u64)boot_params->ext_cmd_line_ptr << 
32));
efi_status_t status;
 
efi_system_table = sys_table_arg;
@@ -735,6 +737,14 @@ unsigned long efi_main(efi_handle_t handle,
image_offset = 0;
}
 
+#ifdef CONFIG_GENERIC_CMDLINE
+   status = efi_handle_cmdline((char *)cmdline_paddr);
+   if (status != EFI_SUCCESS) {
+   efi_err("Failed to parse options\n");
+   goto fail;
+   }
+#else /* CONFIG_GENERIC_CMDLINE */
+
 #ifdef CONFIG_CMDLINE_BOOL
status = efi_parse_options(CONFIG_CMDLINE);
if (status != EFI_SUCCESS) {
@@ -743,8 +753,6 @@ unsigned long efi_main(efi_handle_t handle,
}
 #endif
if (!IS_ENABLED(CONFIG_CMDLINE_OVERRIDE)) {
-   

[PATCH 5/8] CMDLINE: mips: convert to generic builtin command line

[Daniel Walker]

This updates the mips code to use the CONFIG_GENERIC_CMDLINE
option.

This deletes the option for MIPS_CMDLINE_BUILTIN_EXTEND
and replaces the functionality with generic code.

This includes a scripted mass convert of the config files to use
the new generic cmdline. There is a bit of a trim effect here.
It would seems that some of the config haven't been trimmed in
a while.

The script used is as follows,

if [[ -z "$1" || -z "$2" ]]; then
echo "Two arguments are needed."
exit 1
fi
mkdir $1
cp $2 $1/.config
sed -i 's/CONFIG_CMDLINE=/CONFIG_CMDLINE_BOOL=y\nCONFIG_CMDLINE_PREPEND=/g' 
$1/.config
make ARCH=$1 O=$1 olddefconfig
make ARCH=$1 O=$1 savedefconfig
cp $1/defconfig $2
rm -Rf $1

Cc: xe-linux-exter...@cisco.com
Signed-off-by: Ruslan Ruslichenko 
Signed-off-by: Ruslan Bilovol 
Signed-off-by: Daniel Walker 
---
 arch/mips/Kconfig  |  4 +--
 arch/mips/Kconfig.debug| 44 --
 arch/mips/configs/ar7_defconfig|  9 ++
 arch/mips/configs/bcm47xx_defconfig|  8 ++---
 arch/mips/configs/bcm63xx_defconfig| 15 +++--
 arch/mips/configs/bmips_be_defconfig   | 11 +++
 arch/mips/configs/bmips_stb_defconfig  | 11 +++
 arch/mips/configs/capcella_defconfig   | 11 ++-
 arch/mips/configs/ci20_defconfig   | 10 +++---
 arch/mips/configs/cu1000-neo_defconfig | 10 +++---
 arch/mips/configs/cu1830-neo_defconfig | 10 +++---
 arch/mips/configs/e55_defconfig|  4 +--
 arch/mips/configs/generic_defconfig|  6 ++--
 arch/mips/configs/gpr_defconfig| 18 ++-
 arch/mips/configs/loongson3_defconfig  | 13 ++--
 arch/mips/configs/mpc30x_defconfig |  7 ++--
 arch/mips/configs/tb0219_defconfig |  7 ++--
 arch/mips/configs/tb0226_defconfig |  7 ++--
 arch/mips/configs/tb0287_defconfig |  7 ++--
 arch/mips/configs/workpad_defconfig| 11 +++
 arch/mips/kernel/setup.c   | 36 +++--
 21 files changed, 59 insertions(+), 200 deletions(-)

diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index d89efba3d8a4..0e753894d28d 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -24,6 +24,7 @@ config MIPS
select CPU_NO_EFFICIENT_FFS if (TARGET_ISA_REV < 1)
select CPU_PM if CPU_IDLE
select GENERIC_ATOMIC64 if !64BIT
+   select GENERIC_CMDLINE
select GENERIC_CMOS_UPDATE
select GENERIC_CPU_AUTOPROBE
select GENERIC_GETTIMEOFDAY
@@ -3212,9 +3213,6 @@ choice
config MIPS_CMDLINE_FROM_BOOTLOADER
bool "Bootloader kernel arguments if available"
 
-   config MIPS_CMDLINE_BUILTIN_EXTEND
-   depends on CMDLINE_BOOL
-   bool "Extend builtin kernel arguments with bootloader arguments"
 endchoice
 
 endmenu
diff --git a/arch/mips/Kconfig.debug b/arch/mips/Kconfig.debug
index 7a8d94cdd493..b5a099c74eb6 100644
--- a/arch/mips/Kconfig.debug
+++ b/arch/mips/Kconfig.debug
@@ -30,50 +30,6 @@ config EARLY_PRINTK_8250
 config USE_GENERIC_EARLY_PRINTK_8250
bool
 
-config CMDLINE_BOOL
-   bool "Built-in kernel command line"
-   help
- For most systems, it is firmware or second stage bootloader that
- by default specifies the kernel command line options.  However,
- it might be necessary or advantageous to either override the
- default kernel command line or add a few extra options to it.
- For such cases, this option allows you to hardcode your own
- command line options directly into the kernel.  For that, you
- should choose 'Y' here, and fill in the extra boot arguments
- in CONFIG_CMDLINE.
-
- The built-in options will be concatenated to the default command
- line if CMDLINE_OVERRIDE is set to 'N'. Otherwise, the default
- command line will be ignored and replaced by the built-in string.
-
- Most MIPS systems will normally expect 'N' here and rely upon
- the command line from the firmware or the second-stage bootloader.
-
-config CMDLINE
-   string "Default kernel command string"
-   depends on CMDLINE_BOOL
-   help
- On some platforms, there is currently no way for the boot loader to
- pass arguments to the kernel.  For these platforms, and for the cases
- when you want to add some extra options to the command line or ignore
- the default command line, you can supply some command-line options at
- build time by entering them here.  In other cases you can specify
- kernel args so that you don't have to set them up in board prom
- initialization routines.
-
- For more information, see the CMDLINE_BOOL and CMDLINE_OVERRIDE
- options.
-
-config CMDLINE_OVERRIDE
-   bool "Built-in command line overrides firmware arguments"
-   depends on CMDLINE_BOOL
-   help
- By setting this option to 'Y' you will have your kernel ignore
- command line arguments from 

[PATCH 4/8] CMDLINE: powerpc: convert to generic builtin command line

[Daniel Walker]

This updates the powerpc code to use the CONFIG_GENERIC_CMDLINE
option.

This includes a scripted mass convert of the config files to use
the new generic cmdline. There is a bit of a trim effect here.
It would seems that some of the config haven't been trimmed in
a while.

The bash script used to convert is as follows,

if [[ -z "$1" || -z "$2" ]]; then
echo "Two arguments are needed."
exit 1
fi
mkdir $1
cp $2 $1/.config
sed -i 's/CONFIG_CMDLINE=/CONFIG_CMDLINE_BOOL=y\nCONFIG_CMDLINE_PREPEND=/g' 
$1/.config
make ARCH=$1 O=$1 olddefconfig
make ARCH=$1 O=$1 savedefconfig
cp $1/defconfig $2
rm -Rf $1

Cc: xe-linux-exter...@cisco.com
Signed-off-by: Ruslan Ruslichenko 
Signed-off-by: Ruslan Bilovol 
Signed-off-by: Daniel Walker 
---
 arch/powerpc/Kconfig  | 38 +--
 arch/powerpc/configs/44x/fsp2_defconfig   | 32 
 arch/powerpc/configs/44x/iss476-smp_defconfig | 24 ++--
 arch/powerpc/configs/44x/warp_defconfig   | 17 -
 arch/powerpc/configs/holly_defconfig  | 13 ---
 arch/powerpc/configs/mvme5100_defconfig   | 23 +--
 arch/powerpc/configs/skiroot_defconfig| 12 +++---
 arch/powerpc/configs/storcenter_defconfig | 18 -
 arch/powerpc/kernel/prom_init.c   | 10 +++--
 9 files changed, 74 insertions(+), 113 deletions(-)

diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 386ae12d8523..3a19e5b74177 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -167,6 +167,8 @@ config PPC
select EDAC_SUPPORT
select GENERIC_ATOMIC64 if PPC32
select GENERIC_CLOCKEVENTS_BROADCASTif SMP
+   select GENERIC_CMDLINE
+   select GENERIC_CMDLINE_OF
select GENERIC_CMOS_UPDATE
select GENERIC_CPU_AUTOPROBE
select GENERIC_CPU_VULNERABILITIES  if PPC_BARRIER_NOSPEC
@@ -886,42 +888,6 @@ config PPC_DENORMALISATION
  Add support for handling denormalisation of single precision
  values.  Useful for bare metal only.  If unsure say Y here.
 
-config CMDLINE
-   string "Initial kernel command string"
-   default ""
-   help
- On some platforms, there is currently no way for the boot loader to
- pass arguments to the kernel. For these platforms, you can supply
- some command-line options at build time by entering them here.  In
- most cases you will need to specify the root device here.
-
-choice
-   prompt "Kernel command line type" if CMDLINE != ""
-   default CMDLINE_FROM_BOOTLOADER
-
-config CMDLINE_FROM_BOOTLOADER
-   bool "Use bootloader kernel arguments if available"
-   help
- Uses the command-line options passed by the boot loader. If
- the boot loader doesn't provide any, the default kernel command
- string provided in CMDLINE will be used.
-
-config CMDLINE_EXTEND
-   bool "Extend bootloader kernel arguments"
-   help
- The command-line arguments provided by the boot loader will be
- appended to the default kernel command string.
-
-config CMDLINE_FORCE
-   bool "Always use the default kernel command string"
-   help
- Always use the default kernel command string, even if the boot
- loader passes other arguments to the kernel.
- This is useful if you cannot or don't want to change the
- command-line options your boot loader passes to the kernel.
-
-endchoice
-
 config EXTRA_TARGETS
string "Additional default image types"
help
diff --git a/arch/powerpc/configs/44x/fsp2_defconfig 
b/arch/powerpc/configs/44x/fsp2_defconfig
index 8da316e61a08..4993db054589 100644
--- a/arch/powerpc/configs/44x/fsp2_defconfig
+++ b/arch/powerpc/configs/44x/fsp2_defconfig
@@ -1,8 +1,6 @@
-CONFIG_44x=y
 # CONFIG_SWAP is not set
 CONFIG_SYSVIPC=y
 # CONFIG_CROSS_MEMORY_ATTACH is not set
-# CONFIG_FHANDLE is not set
 CONFIG_NO_HZ=y
 CONFIG_HIGH_RES_TIMERS=y
 CONFIG_IKCONFIG=y
@@ -13,23 +11,25 @@ CONFIG_BLK_DEV_INITRD=y
 # CONFIG_RD_XZ is not set
 # CONFIG_RD_LZO is not set
 # CONFIG_RD_LZ4 is not set
+# CONFIG_FHANDLE is not set
 CONFIG_KALLSYMS_ALL=y
 CONFIG_BPF_SYSCALL=y
 CONFIG_EMBEDDED=y
 CONFIG_PROFILING=y
-CONFIG_MODULES=y
-CONFIG_MODULE_UNLOAD=y
-# CONFIG_BLK_DEV_BSG is not set
+CONFIG_CMDLINE_BOOL=y
+CONFIG_CMDLINE_PREPEND="ip=on rw"
+CONFIG_44x=y
 CONFIG_PPC_47x=y
 # CONFIG_EBONY is not set
 CONFIG_FSP2=y
 CONFIG_476FPE_ERR46=y
-CONFIG_SWIOTLB=y
 CONFIG_KEXEC=y
 CONFIG_CRASH_DUMP=y
-CONFIG_CMDLINE="ip=on rw"
 # CONFIG_SUSPEND is not set
-# CONFIG_PCI is not set
+CONFIG_OPROFILE=y
+CONFIG_MODULES=y
+CONFIG_MODULE_UNLOAD=y
+# CONFIG_BLK_DEV_BSG is not set
 CONFIG_NET=y
 CONFIG_PACKET=y
 CONFIG_UNIX=y
@@ -46,14 +46,12 @@ CONFIG_MTD=y
 CONFIG_MTD_BLOCK=y
 CONFIG_MTD_JEDECPROBE=y
 CONFIG_MTD_CFI_AMDSTD=y
-CONFIG_MTD_PHYSMAP_OF=y
 CONFIG_BLK_DEV_RAM=y
 CONFIG_BLK_DEV_RAM_SIZE=35000
 # CONFIG_SCSI_PROC_FS is not set
 CONFIG_BLK_DEV_SD=y
 

[PATCH 3/8] powerpc: convert strcpy to strlcpy in prom_init

[Daniel Walker]

There's only two users of strcpy and one is the command
line handling. The generic command line handling uses strlcpy
and it makes sense to convert this one other user to strlcpy to
keep prom_init size consistent.

Cc: xe-linux-exter...@cisco.com
Signed-off-by: Daniel Walker 
---
 arch/powerpc/kernel/prom_init.c | 25 +++--
 1 file changed, 15 insertions(+), 10 deletions(-)

diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c
index ccf77b985c8f..2c2f33155317 100644
--- a/arch/powerpc/kernel/prom_init.c
+++ b/arch/powerpc/kernel/prom_init.c
@@ -242,15 +242,6 @@ static int __init prom_strcmp(const char *cs, const char 
*ct)
return 0;
 }
 
-static char __init *prom_strcpy(char *dest, const char *src)
-{
-   char *tmp = dest;
-
-   while ((*dest++ = *src++) != '\0')
-   /* nothing */;
-   return tmp;
-}
-
 static int __init prom_strncmp(const char *cs, const char *ct, size_t count)
 {
unsigned char c1, c2;
@@ -276,6 +267,20 @@ static size_t __init prom_strlen(const char *s)
return sc - s;
 }
 
+static size_t __init prom_strlcpy(char *dest, const char *src, size_t size)
+{
+   size_t ret = prom_strlen(src);
+
+   if (size) {
+   size_t len = (ret >= size) ? size - 1 : ret;
+
+   memcpy(dest, src, len);
+   dest[len] = '\0';
+   }
+   return ret;
+}
+
+
 static int __init prom_memcmp(const void *cs, const void *ct, size_t count)
 {
const unsigned char *su1, *su2;
@@ -2702,7 +2707,7 @@ static void __init flatten_device_tree(void)
 
/* Add "phandle" in there, we'll need it */
namep = make_room(_start, _end, 16, 1);
-   prom_strcpy(namep, "phandle");
+   prom_strlcpy(namep, "phandle", 8);
mem_start = (unsigned long)namep + prom_strlen(namep) + 1;
 
/* Build string array */
-- 
2.25.1

[PATCH 1/8] CMDLINE: add generic builtin command line

[Daniel Walker]

This code allows architectures to use a generic builtin command line.
The state of the builtin command line options across architecture is
diverse. MIPS and X86 once has similar systems, then mips added some
options to allow extending the command line. Powerpc did something
simiar in adding the ability to extend. Even with mips and powerpc
enhancement the needs of Cisco are not met on these platforms.

The code in this commit unifies the code into a generic
header file under the CONFIG_GENERIC_CMDLINE option. When this
option is enabled the architecture can call the cmdline_add_builtin()
to add the builtin command line.

This unified implementation offers the same functionality needed by
Cisco on all platform which use it.

Cc: xe-linux-exter...@cisco.com
Signed-off-by: Ruslan Bilovol 
Signed-off-by: Daniel Walker 
---
 include/linux/cmdline.h | 98 +
 init/Kconfig| 72 ++
 2 files changed, 170 insertions(+)
 create mode 100644 include/linux/cmdline.h

diff --git a/include/linux/cmdline.h b/include/linux/cmdline.h
new file mode 100644
index ..439c4585feba
--- /dev/null
+++ b/include/linux/cmdline.h
@@ -0,0 +1,98 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _LINUX_CMDLINE_H
+#define _LINUX_CMDLINE_H
+
+/*
+ *
+ * Copyright (C) 2006,2021. Cisco Systems, Inc.
+ *
+ * Generic Append/Prepend cmdline support.
+ */
+
+#if defined(CONFIG_GENERIC_CMDLINE) && defined(CONFIG_CMDLINE_BOOL)
+
+#ifndef CONFIG_CMDLINE_OVERRIDE
+#define GENERIC_CMDLINE_NEED_STRLCAT
+#define CMDLINE_PREPEND CONFIG_CMDLINE_PREPEND
+#define CMDLINE_APPEND CONFIG_CMDLINE_APPEND
+
+/*
+ * This function will append or prepend a builtin command line to the command
+ * line provided by the bootloader. Kconfig options can be used to alter
+ * the behavior of this builtin command line.
+ * @dest: The destination of the final appended/prepended string
+ * @src: The starting string or NULL if there isn't one.
+ * @tmp: temporary space used for prepending
+ * @length: the maximum length of the strings above.
+ * @cmdline_strlcpy: point to a compatible strlcpy
+ * @cmdline_strlcat: point to a compatible strlcat
+ */
+static inline void
+__cmdline_add_builtin(char *dest, const char *src, char *tmp, unsigned long 
length,
+   size_t (*cmdline_strlcpy)(char *dest, const char *src, size_t 
size),
+   size_t (*cmdline_strlcat)(char *dest, const char *src, size_t 
count))
+{
+   if (src != dest && src != NULL) {
+   cmdline_strlcpy(dest, " ", length);
+   cmdline_strlcat(dest, src, length);
+   }
+
+   if (sizeof(CONFIG_CMDLINE_APPEND) > 1)
+   cmdline_strlcat(dest, " " CONFIG_CMDLINE_APPEND, length);
+
+   if (sizeof(CONFIG_CMDLINE_PREPEND) > 1) {
+   cmdline_strlcpy(tmp, CONFIG_CMDLINE_PREPEND " ", length);
+   cmdline_strlcat(tmp, dest, length);
+   cmdline_strlcpy(dest, tmp, length);
+   }
+}
+
+#define cmdline_add_builtin_custom(dest, src, length, label, cmdline_strlcpy, 
cmdline_strlcat) \
+{  
\
+   if (sizeof(CONFIG_CMDLINE_PREPEND) > 1) {   
\
+   static label char cmdline_tmp_space[length];
\
+   __cmdline_add_builtin(dest, src, cmdline_tmp_space, length, 
cmdline_strlcpy, cmdline_strlcat);  \
+   } else if (sizeof(CONFIG_CMDLINE_APPEND) > 1) { 
\
+   __cmdline_add_builtin(dest, src, NULL, length, cmdline_strlcpy, 
cmdline_strlcat);   \
+   }   
\
+}
+#define cmdline_add_builtin(dest, src, length) \
+   cmdline_add_builtin_custom(dest, src, length, __initdata, strlcpy, 
strlcat)
+
+#else /* CONFIG_CMDLINE_OVERRIDE */
+
+#define CMDLINE_PREPEND CONFIG_CMDLINE_PREPEND
+#define CMDLINE_APPEND CONFIG_CMDLINE_APPEND
+
+static inline void
+__cmdline_add_builtin_custom(char *dest, const char *src, unsigned long length,
+   size_t (*cmdline_strlcpy)(char *dest, const char *src, size_t 
size))
+{
+   cmdline_strlcpy(dest, CONFIG_CMDLINE_PREPEND " " CONFIG_CMDLINE_APPEND, 
length);
+}
+#define cmdline_add_builtin_custom(dest, src, length, label, cmdline_strlcpy, 
cmdline_strlcat) \
+   __cmdline_add_builtin_custom(dest, src, length, cmdline_strlcpy)
+#define cmdline_add_builtin(dest, src, length) \
+   __cmdline_add_builtin_custom(dest, src, length, strlcpy)
+#endif /* !CONFIG_CMDLINE_OVERRIDE */
+
+#else /* !CONFIG_GENERIC_CMDLINE || !CONFIG_CMDLINE_BOOL */
+
+#define CMDLINE_PREPEND ""
+#define CMDLINE_APPEND ""
+
+static inline void
+__cmdline_add_builtin_custom(char *dest, 

[PATCH 2/8] CMDLINE: drivers: of: ifdef out cmdline section

[Daniel Walker]

It looks like there's some seepage of cmdline stuff into
the generic device tree code. This conflicts with the
generic cmdline implementation so I remove it in the case
when that's enabled.

Cc: xe-linux-exter...@cisco.com
Signed-off-by: Ruslan Ruslichenko 
Signed-off-by: Daniel Walker 
---
 drivers/of/fdt.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index dcc1dd96911a..d8805cd9717a 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include   /* for COMMAND_LINE_SIZE */
 #include 
@@ -1050,6 +1051,18 @@ int __init early_init_dt_scan_chosen(unsigned long node, 
const char *uname,
 
/* Retrieve command line */
p = of_get_flat_dt_prop(node, "bootargs", );
+
+#if defined(CONFIG_GENERIC_CMDLINE) && defined(CONFIG_GENERIC_CMDLINE_OF)
+   /*
+* The builtin command line will be added here, or it can override
+* with the DT bootargs.
+*/
+   cmdline_add_builtin(data,
+   (l > 0 ? p : NULL), /* This is sanity checking */
+   COMMAND_LINE_SIZE);
+#elif defined(CONFIG_GENERIC_CMDLINE)
+   strlcpy(data, p, COMMAND_LINE_SIZE);
+#else
if (p != NULL && l > 0)
strlcpy(data, p, min(l, COMMAND_LINE_SIZE));
 
@@ -1070,6 +1083,7 @@ int __init early_init_dt_scan_chosen(unsigned long node, 
const char *uname,
strlcpy(data, CONFIG_CMDLINE, COMMAND_LINE_SIZE);
 #endif
 #endif /* CONFIG_CMDLINE */
+#endif /* CONFIG_GENERIC_CMDLINE */
 
pr_debug("Command line is: %s\n", (char *)data);
 
-- 
2.25.1

Re: Enabling pmbus power control

[Zev Weiss]

On Tue, Mar 30, 2021 at 12:42:21PM CDT, Mark Brown wrote:

On Tue, Mar 30, 2021 at 12:19:29PM -0500, Zev Weiss wrote:

On Tue, Mar 30, 2021 at 06:22:54AM CDT, Mark Brown wrote:
> On Tue, Mar 30, 2021 at 03:34:16AM -0700, Guenter Roeck wrote:



> > (and I don't know if the userspace consumer code is appropriate - you
> > might want to check with the regulator maintainer on that).



> It's not, you should never see this in a production system.



Sorry, can you clarify what exactly "this" refers to here?


The userspace consumer.


> I can't really tell what the issue is here without more context, the
> global name list should not be relevant for much in a system that's well
> configured so it sounds like it's user error.



My initial attempt I guess followed the existing ltc2978 code a little too
closely and I ended up with all my lm25066 regulators registered under the
same (static) name, so when I went to attach the reg-userspace-consumer
instances to them by way of that name I got this:


I don't know what you're trying to do or why, nor how you're going about
achieving it so I can't really comment.  Like I say anything that's
instantiating a userspace consumer in upstream code is broken, it's
there for test during development of regulator drivers.  Whatever device
is supplied by the regulator should have a driver which should control
the regulator at runtime if that is needed.


Okay, to expand a bit on the description in my initial message -- we've
got a single chassis with multiple server boards and a single manager 
board that handles, among other things, power control for the servers.
The manager board has one LM25066 for each attached server, which acts 
as the "power switch" for that server.  There thus really isn't any 
driver to speak of for the downstream device.


We need to be able to toggle that power switch from userspace on the 
manager board, which we could achieve via i2cset, but we don't want to 
give up the sensors provided by the hwmon driver.


The hardware seems perfectly capable of providing the functionality we 
need -- is there any way of implementing the requisite kernel support in 
a way that the relevant subsystem maintainers would find palatable, or 
is carrying an out-of-tree patch my only option for this?



Thanks,
Zev

Re: Candidate Linux ABI for Intel AMX and hypothetical new related features

[Len Brown]

On Tue, Mar 30, 2021 at 1:06 PM Andy Lutomirski  wrote:

> > On Mar 30, 2021, at 10:01 AM, Len Brown  wrote:

> > Is it required (by the "ABI") that a user program has everything
> > on the stack for user-space XSAVE/XRESTOR to get back
> > to the state of the program just before receiving the signal?
>
> The current Linux signal frame format has XSTATE in uncompacted format,
> so everything has to be there.
> Maybe we could have an opt in new signal frame format, but the details would 
> need to be worked out.
>
> It is certainly the case that a signal should be able to be delivered, run 
> “async-signal-safe” code,
> and return, without corrupting register contents.

And so an an acknowledgement:

We can't change the legacy signal stack format without breaking
existing programs.  The legacy is uncompressed XSTATE.  It is a
complete set of architectural state -- everything necessary to
XRESTOR.  Further, the sigreturn flow allows the signal handler to
*change* any of that state, so that it becomes active upon return from
signal.

And a proposal:

Future programs, which know that they don't need the full-blown legacy
signal stack format, can opt-in to a new format.  That new format, can
be minimal (fast) by default.  Perhaps, as Noah suggests, it could
have some sort of mechanism where the program can explicitly select
which state components they would want included on their signal stack,
and restored by sigreturn.

If the new fast-signal format is successful, in a number of years, it
will have spread to have taken over the world.

thoughts?

Len Brown, Intel Open Source Technology Center

Re: [PATCH v3 0/5] Add support for CP110 UTMI PHY

[Vinod Koul]

On 07-03-21, 18:33, kos...@marvell.com wrote:
> From: Konstantin Porotchkin 
> 
> This series of patches adds a new PHY driver for supporting CP110 UTMI
> PHY in Linux. Currently the functionality of USB ports connected to
> this PHY depends on boot loader setup.
> The new driver eliminates kernel configuration dependency from the boot
> loader. 

Applied 1-3, thanks

-- 
~Vinod

Re: [PATCH v2 2/4] cxl/mem: Fix synchronization mechanism for device removal vs ioctl operations

[Jason Gunthorpe]

On Tue, Mar 30, 2021 at 10:31:15AM -0700, Dan Williams wrote:
> On Tue, Mar 30, 2021 at 10:03 AM Jason Gunthorpe  wrote:
> >
> > On Tue, Mar 30, 2021 at 09:05:29AM -0700, Dan Williams wrote:
> >
> > > > If you can't clearly point to the *data* under RCU protection it is
> > > > being used wrong.
> > >
> > > Agree.
> > >
> > > The data being protected is the value of
> > > dev->kobj.state_in_sysfs. The
> >
> > So where is that read under:
> >
> > +   idx = srcu_read_lock(_memdev_srcu);
> > +   rc = __cxl_memdev_ioctl(cxlmd, cmd, arg);
> > +   srcu_read_unlock(_memdev_srcu, idx);
> >
> > ?
> 
> device_is_registered() inside __cxl_memdev_ioctl().

Oh, I see, I missed that

> > It can't read the RCU protected data outside the RCU critical region,
> > and it can't read/write RCU protected data without using the helper
> > macros which insert the required barriers.
> 
> The required barriers are there. srcu_read_lock() +
> device_is_registered() is paired with cdev_device_del() +
> synchronize_rcu().

RCU needs barriers on the actual load/store just a naked
device_is_registered() alone is not strong enough.

> > IMHO this can't use 'dev->kobj.state_in_sysfs' as the RCU protected data.
> 
> This usage of srcu is functionally equivalent to replacing
> srcu_read_lock() with down_read() and the shutdown path with:

Sort of, but the rules for load/store under RCU are different than for
load/store under a normal barriered lock. All the data is unstable for
instance and minimially needs READ_ONCE.

> cdev_device_del(...);
> down_write(...):
> up_write(...);

The lock would have to enclose the store to state_in_sysfs, otherwise
as written it has the same data race problems.

Jason

Re: [PATCH 3/3] MIPS: Remove get_fs/set_fs

[Christoph Hellwig]

> - if (likely(access_ok( __gu_ptr, size))) {   \
> - if (eva_kernel_access())\
> - __get_kernel_common((x), size, __gu_ptr);   \

FYI, it might be a good idea to fold __{get,put}_kernel_common into
__{get,put}_kernel_nofault now that these are the only callers left.

Similarly __get_user_common and __put_user_common should probably also
go away.

>  static inline unsigned long
>  raw_copy_to_user(void __user *to, const void *from, unsigned long n)
>  {
> + return __invoke_copy_to_user(to, from, n);

I think __invoke_copy_to_user, __invoke_copy_from_user and
___invoke_copy_in_user can go away now as well.

Re: [PATCH v5 03/10] coresight: config: Add configuration and feature generic functions

[Mathieu Poirier]

On Tue, Mar 16, 2021 at 06:03:53PM +, Mike Leach wrote:
> Adds a set of generic support functions that allow devices to set and save
> features values on the device, and enable and disable configurations.
> 
> Additional functions for other common operations including feature
> reset.
> 
> Signed-off-by: Mike Leach 
> ---
>  drivers/hwtracing/coresight/Makefile  |   2 +-
>  .../hwtracing/coresight/coresight-config.c| 274 ++
>  .../hwtracing/coresight/coresight-config.h|   9 +
>  .../hwtracing/coresight/coresight-syscfg.c|   3 +-
>  4 files changed, 286 insertions(+), 2 deletions(-)
>  create mode 100644 drivers/hwtracing/coresight/coresight-config.c
>

This patch is so much easier to review with a consistent naming convention...

With the kernel test robot warning addressed: 

Reviewed-by: Mathieu Poirier 

 
> diff --git a/drivers/hwtracing/coresight/Makefile 
> b/drivers/hwtracing/coresight/Makefile
> index 4ce854c434b1..daad9f103a78 100644
> --- a/drivers/hwtracing/coresight/Makefile
> +++ b/drivers/hwtracing/coresight/Makefile
> @@ -4,7 +4,7 @@
>  #
>  obj-$(CONFIG_CORESIGHT) += coresight.o
>  coresight-y := coresight-core.o  coresight-etm-perf.o coresight-platform.o \
> - coresight-sysfs.o coresight-syscfg.o
> + coresight-sysfs.o coresight-syscfg.o coresight-config.o
>  obj-$(CONFIG_CORESIGHT_LINK_AND_SINK_TMC) += coresight-tmc.o
>  coresight-tmc-y := coresight-tmc-core.o coresight-tmc-etf.o \
> coresight-tmc-etr.o
> diff --git a/drivers/hwtracing/coresight/coresight-config.c 
> b/drivers/hwtracing/coresight/coresight-config.c
> new file mode 100644
> index ..571e90485c06
> --- /dev/null
> +++ b/drivers/hwtracing/coresight/coresight-config.c
> @@ -0,0 +1,274 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright(C) 2020 Linaro Limited. All rights reserved.
> + * Author: Mike Leach 
> + */
> +
> +#include 
> +#include "coresight-config.h"
> +#include "coresight-priv.h"
> +
> +/*
> + * This provides a set of generic functions that operate on configurations
> + * and features to manage the handling of parameters, the programming and
> + * saving of registers used by features on devices.
> + */
> +
> +/*
> + * Write the value held in the register structure into the driver internal 
> memory
> + * location.
> + */
> +static void cscfg_set_reg(struct cscfg_regval_csdev *reg_csdev)
> +{
> + u32 *p_val32 = (u32 *)reg_csdev->driver_regval;
> + u32 tmp32 = reg_csdev->reg_desc.val32;
> +
> + if (reg_csdev->reg_desc.type & CS_CFG_REG_TYPE_VAL_64BIT) {
> + *((u64 *)reg_csdev->driver_regval) = reg_csdev->reg_desc.val64;
> + return;
> + }
> +
> + if (reg_csdev->reg_desc.type & CS_CFG_REG_TYPE_VAL_MASK) {
> + tmp32 = *p_val32;
> + tmp32 &= ~reg_csdev->reg_desc.mask32;
> + tmp32 |= reg_csdev->reg_desc.val32 & reg_csdev->reg_desc.mask32;
> + }
> + *p_val32 = tmp32;
> +}
> +
> +/*
> + * Read the driver value into the reg if this is marked as one we want to 
> save.
> + */
> +static void cscfg_save_reg(struct cscfg_regval_csdev *reg_csdev)
> +{
> + if (!(reg_csdev->reg_desc.type & CS_CFG_REG_TYPE_VAL_SAVE))
> + return;
> + if (reg_csdev->reg_desc.type & CS_CFG_REG_TYPE_VAL_64BIT)
> + reg_csdev->reg_desc.val64 = *(u64 *)(reg_csdev->driver_regval);
> + else
> + reg_csdev->reg_desc.val32 = *(u32 *)(reg_csdev->driver_regval);
> +}
> +
> +/*
> + * Some register values are set from parameters. Initialise these registers
> + * from the current parameter values.
> + */
> +static void cscfg_init_reg_param(struct cscfg_feature_csdev *feat_csdev,
> +  struct cscfg_regval_desc *reg_desc,
> +  struct cscfg_regval_csdev *reg_csdev)
> +{
> + struct cscfg_parameter_csdev *param_csdev;
> +
> + /* for param, load routines have validated the index */
> + param_csdev = _csdev->params_csdev[reg_desc->param_idx];
> + param_csdev->reg_csdev = reg_csdev;
> + param_csdev->val64 = reg_csdev->reg_desc.type & 
> CS_CFG_REG_TYPE_VAL_64BIT;
> +
> + if (param_csdev->val64)
> + reg_csdev->reg_desc.val64 = param_csdev->current_value;
> + else
> + reg_csdev->reg_desc.val32 = (u32)param_csdev->current_value;
> +}
> +
> +/* set values into the driver locations referenced in cscfg_reg_csdev */
> +static int cscfg_set_on_enable(struct cscfg_feature_csdev *feat_csdev)
> +{
> + int i;
> +
> + spin_lock(feat_csdev->drv_spinlock);
> + for (i = 0; i < feat_csdev->nr_regs; i++)
> + cscfg_set_reg(_csdev->regs_csdev[i]);
> + spin_unlock(feat_csdev->drv_spinlock);
> + dev_dbg(_csdev->csdev->dev, "Feature %s: %s",
> + feat_csdev->feat_desc->name, "set on enable");
> + return 0;
> +}
> +
> +/* copy back values from the driver locations referenced in cscfg_reg_csdev 
> */
> 

Re: [PATCH] hwmon: (nzxt-kraken2) mark and order concurrent accesses

[Jonas Malaco]

On Tue, Mar 30, 2021 at 03:51:21AM -0700, Guenter Roeck wrote:
> [ ... ]
> 
> Then please explain why _this_ use of time_after() is wrong but all
> others in the kernel are not. Also, please note that we are not
> concerned with code generation by the compiler as long as the
> generated code is correct (and I don't see any indication that
> it isn't).

The accesses to priv->temp_input[], ->fan_input[] and ->updated (where
this relates to your question about time_after()) are not wrong, but
undefined.

But if we are not concerned with code that is currently generated
correctly, which indeed is the case in the five arch x compiler
combinations I tested, then there simply is no point to this patch.

Thanks for going through this with me,
Jonas

P.S. Admittedly from a sample way too small, but in the kernel
time_after(jiffies, x) calls do not generally appear to involve an
expression x with a data race.  And there are a few calls where
READ_ONCE() is indeed used in x.

[PATCH] nds32: flush_dcache_page: use page_mapping_file to avoid races with swapoff

[Mike Rapoport]

From: Mike Rapoport 

Commit cb9f753a3731 ("mm: fix races between swapoff and flush dcache")
updated flush_dcache_page implementations on several architectures to use
page_mapping_file() in order to avoid races between page_mapping() and
swapoff().

This update missed arch/nds32 and there is a possibility of a race there.

Replace page_mapping() with page_mapping_file() in nds32 implementation of
flush_dcache_page().

Fixes: cb9f753a3731 ("mm: fix races between swapoff and flush dcache")
Signed-off-by: Mike Rapoport 
---
 arch/nds32/mm/cacheflush.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/nds32/mm/cacheflush.c b/arch/nds32/mm/cacheflush.c
index 6eb98a7ad27d..ad5344ef5d33 100644
--- a/arch/nds32/mm/cacheflush.c
+++ b/arch/nds32/mm/cacheflush.c
@@ -238,7 +238,7 @@ void flush_dcache_page(struct page *page)
 {
struct address_space *mapping;
 
-   mapping = page_mapping(page);
+   mapping = page_mapping_file(page);
if (mapping && !mapping_mapped(mapping))
set_bit(PG_dcache_dirty, >flags);
else {
-- 
2.28.0

Re: [PATCH 2/3] MIPS: uaccess: Remove get_fs/set_fs call sites

[Christoph Hellwig]

On Tue, Mar 30, 2021 at 07:26:59PM +0200, Thomas Bogendoerfer wrote:
> +#define __get_data(x, ptr, u)
> \
> + (((u) == true) ? __get_udata((x), (ptr), sizeof(*(ptr))) :  \
> + __get_kdata((x), (ptr), sizeof(*(ptr
> +

I'm a little worried about exposing this in uaccess.h.  Can you
have local helpers insted, preferably strongly typed for their
specific use cases?

Re: [PATCH v2 1/4] iommu/vt-d: Enable write protect for supervisor SVM

[Jacob Pan]

Hi Guenter,

On Mon, 22 Mar 2021 10:53:38 -0700, Guenter Roeck 
wrote:

> On Tue, Mar 02, 2021 at 02:13:57AM -0800, Jacob Pan wrote:
> > Write protect bit, when set, inhibits supervisor writes to the read-only
> > pages. In supervisor shared virtual addressing (SVA), where page tables
> > are shared between CPU and DMA, IOMMU PASID entry WPE bit should match
> > CR0.WP bit in the CPU.
> > This patch sets WPE bit for supervisor PASIDs if CR0.WP is set.
> > 
> > Signed-off-by: Sanjay Kumar 
> > Signed-off-by: Jacob Pan 
> > ---  
> 
> ia64:defconfig:
> 
> drivers/iommu/intel/pasid.c: In function 'pasid_enable_wpe':
> drivers/iommu/intel/pasid.c:536:22: error: implicit declaration of
> function 'read_cr0' drivers/iommu/intel/pasid.c:539:23: error:
> 'X86_CR0_WP' undeclared
> 
> Maybe it _is_ time to retire ia64 ?

Good catch, sorry for the late reply. I guess otherwise I will have to do
some #ifdef?

There are many basic x86 helpers are missing in ia64.

+Tony

Thanks,

Jacob

BUG: key ffff000800eba398 has not been registered!

[Naresh Kamboju]

While running kselftest recently added gpio gpio-sim.sh test case the following
warning was triggered on Linux next tag 20210330 tag running on arm64 juno
and hikey devices.

GOOD: next-20210326
BAD: next-20210330

# selftests: gpio: gpio-sim.sh
# 1. chip_name and dev_name attributes
# 1.1. Chip name is communicated to user
[  143.081193] BUG: key 000800eba398 has not been registered!
[  143.087326] [ cut here ]
[  143.091987] DEBUG_LOCKS_WARN_ON(1)
[  143.092005] WARNING: CPU: 1 PID: 1821 at
/usr/src/kernel/kernel/locking/lockdep.c:4688
lockdep_init_map_type+0xf0/0x298
[  143.106223] Modules linked in: gpio_sim rfkill tda998x cec
drm_kms_helper drm crct10dif_ce fuse [last unloaded: gpio_mockup]
[  143.117495] CPU: 1 PID: 1821 Comm: mv Not tainted 5.12.0-rc5-next-20210330 #1
[  143.124645] Hardware name: ARM Juno development board (r2) (DT)
[  143.130572] pstate: 4005 (nZcv daif -PAN -UAO -TCO BTYPE=--)
[  143.136589] pc : lockdep_init_map_type+0xf0/0x298
[  143.141302] lr : lockdep_init_map_type+0xf0/0x298
[  143.146014] sp : 800013fb3560
[  143.149330] x29: 800013fb3560 x28: ee4b
[  143.154655] x27: 11b4 x26: 1000
[  143.159979] x25: 000800eba380 x24: 
[  143.165303] x23:  x22: 
[  143.170626] x21: 80001382b000 x20: 000800eba398
[  143.175949] x19: 000827ac32a8 x18: 
[  143.181273] x17:  x16: 
[  143.186595] x15: 800012900a88 x14: 800093fb3167
[  143.191918] x13: 800013fb3175 x12: a0ec
[  143.197241] x11: 05f5e0ff x10: 800013fb30c0
[  143.202565] x9 : 800013fb3560 x8 : 4e5241575f534b43
[  143.207888] x7 : 800012989ad8 x6 : 800013fb3180
[  143.213211] x5 : 0001 x4 : 0001
[  143.218534] x3 : 800012901000 x2 : 
[  143.223856] x1 : b4b7acac5f71bc00 x0 : 
[  143.229180] Call trace:
[  143.231625]  lockdep_init_map_type+0xf0/0x298
[  143.235989]  __kernfs_create_file+0xa8/0x1d0
[  143.240268]  sysfs_add_file_mode_ns+0xa8/0x1f8
[  143.244718]  internal_create_group+0x118/0x420
[  143.249169]  sysfs_create_group+0x2c/0x38
[  143.253185]  gpio_sim_probe+0x358/0x3c0 [gpio_sim]
[  143.257995]  platform_probe+0x6c/0xd8
[  143.261663]  really_probe+0x16c/0x508
[  143.265332]  driver_probe_device+0x104/0x178
[  143.269610]  __device_attach_driver+0xa4/0x130
[  143.274062]  bus_for_each_drv+0x78/0xd8
[  143.277903]  __device_attach+0xf0/0x178
[  143.281745]  device_initial_probe+0x24/0x30
[  143.285935]  bus_probe_device+0xa0/0xa8
[  143.289776]  device_add+0x424/0x810
[  143.293270]  platform_device_add+0x12c/0x2c0
[  143.297545]  platform_device_register_full+0x124/0x150
[  143.302692]  gpio_sim_config_commit_item+0x160/0x1e0 [gpio_sim]
[  143.308628]  configfs_rename+0x1dc/0x220
[  143.312557]  vfs_rename+0x394/0x960
[  143.316051]  do_renameat2+0x408/0x4c0
[  143.319718]  __arm64_sys_renameat+0x5c/0x70
[  143.323908]  el0_svc_common+0x7c/0x158
[  143.327665]  do_el0_svc+0x38/0x90
[  143.330985]  el0_svc+0x20/0x30
[  143.334045]  el0_sync_handler+0x8c/0xb0
[  143.337886]  el0_sync+0x13c/0x140
[  143.341204] irq event stamp: 5607
[  143.344520] hardirqs last  enabled at (5607): []
_raw_spin_unlock_irq+0x48/0x90
[  143.353410] hardirqs last disabled at (5606): []
__schedule+0x364/0x950
[  143.361605] softirqs last  enabled at (5602): []
__do_softirq+0x510/0x63c
[  143.369971] softirqs last disabled at (5577): []
irq_exit+0x1b4/0x1c0
[  143.377992] ---[ end trace bc3c86ef609281aa ]---
# 1.2. chip_name returns 'none' if the chip is still pending

Reported-by: Naresh Kamboju 

metadata:
  git branch: master
  git repo: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
  git describe: next-20210330
  kernel-config:
http://snapshots.linaro.org/openembedded/lkft/lkft/sumo/juno/lkft/linux-next/995/config

Full test log link,
https://qa-reports.linaro.org/lkft/linux-next-master/build/next-20210330/testrun/4268728/suite/linux-log-parser/test/check-kernel-bug-2463256/log

git log --oneline next-20210326..next-20210330  -- tools/testing/selftests/gpio/
9d940ab72645 selftests: gpio: add test cases for gpio-sim
8a4cb2823240 selftests: gpio: add a helper for reading GPIO line names
ab1dbed6f4e8 selftests: gpio: provide a helper for reading chip info

-- 
Linaro LKFT
https://lkft.linaro.org

Re: [PATCH v2 2/2] thermal: qcom-spmi-temp-alarm: add support for GEN2 rev 1 PMIC peripherals

[Guru Das Srinagesh]

On Tue, Aug 04, 2020 at 11:48:30PM -0700, Stephen Boyd wrote:
> Quoting Guru Das Srinagesh (2020-07-29 09:52:52)
> > From: David Collins 
> > 
> > Add support for TEMP_ALARM GEN2 PMIC peripherals with digital
> > major revision 1.  This revision utilizes a different temperature
> > threshold mapping than earlier revisions.
> > 
> > Signed-off-by: David Collins 
> > Signed-off-by: Guru Das Srinagesh 
> > ---
> 
> Reviewed-by: Stephen Boyd 

+ Daniel Lezcano

Hi Daniel,

I just checked Linus' tree and discovered that this patch has not been
applied - only the other patch in this series. Since this patch has been
reviewed already, could you please check if it's good to be applied as
well?

Thank you.

Guru Das.

[PATCH v6 0/2] Add Realtek Otto GPIO support

[Sander Vanheule]

Add support for the GPIO controller employed by Realtek in multiple series of
MIPS SoCs. These include the supported RTL838x and RTL839x. The register layout
also matches the one found in the GPIO controller of other (Lexra-based) SoCs
such as RTL8196E, RTL8197D, and RTL8197F.

For the platform name 'otto', I am not aware of any official resources as to
what hardware this specifically applies to. However, in all of the GPL archives
we've received, from vendors using compatible SoCs in their design, the
platform under the MIPS architecture is referred to by this name.

The GPIO ports have been tested on a Zyxel GS1900-8 (RTL8380), and Zyxel
GS1900-48 (RTL8393). Furthermore, the GPIO ports and interrupt controller have
been tested on a Netgear GS110TPPv1 (RTL8381).

Changes in v6:
- Use devm_gpiochip_add_data()
- Code style for reading ngpios, header order
- Add Andy's Reviewed-by tag

Changes in v5:
- Edited code comments
- Fold functions that were used only once or twice (ISR/IMR accessors)
- Drop trivial functions for line to port/pin calculations
- Use gpio_irq_chip->init_hw() to initialise IRQ registers
- Invert GPIO_INTERRUPTS flag to GPIO_INTERRUPTS_DISABLED
- Support building as module
- Add Rob's Reviewed-by tag

Changes in v4:
- Fix pointer notation style
- Drop unused read_u16_reg() function
- Drop 'inline' specifier from functions

Changes in v3:
- Remove OF dependencies in driver probe
- Don't accept IRQ_TYPE_NONE as a valid interrupt type
- Remove (now unused) dev property from control structure
- Use u8/u16 port registers, instead of raw u32 registers
- Use 'line' name for gpiochip, 'port' and 'pin' names for hardware
- Renamed DT bindings file
- Dropped fallback-only DT compatible
- Various code style clean-ups

Changes in v2:
- Clarify structure and usage of IMR registers
- Added Linus' Reviewed-by tags

Sander Vanheule (2):
  dt-bindings: gpio: Binding for Realtek Otto GPIO
  gpio: Add Realtek Otto GPIO support

 .../bindings/gpio/realtek,otto-gpio.yaml  |  78 +
 drivers/gpio/Kconfig  |  13 +
 drivers/gpio/Makefile |   1 +
 drivers/gpio/gpio-realtek-otto.c  | 325 ++
 4 files changed, 417 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/gpio/realtek,otto-gpio.yaml
 create mode 100644 drivers/gpio/gpio-realtek-otto.c

-- 
2.30.2

[PATCH v6 2/2] gpio: Add Realtek Otto GPIO support

[Sander Vanheule]

Realtek MIPS SoCs (platform name Otto) have GPIO controllers with up to
64 GPIOs, divided over two banks. Each bank has a set of registers for
32 GPIOs, with support for edge-triggered interrupts.

Each GPIO bank consists of four 8-bit GPIO ports (ABCD and EFGH). Most
registers pack one bit per GPIO, except for the IMR register, which
packs two bits per GPIO (AB-CD).

Although the byte order is currently assumed to have port A..D at offset
0x0..0x3, this has been observed to be reversed on other, Lexra-based,
SoCs (e.g. RTL8196E/97D/97F).

Interrupt support is disabled for the fallback devicetree-compatible
'realtek,otto-gpio'. This allows for quick support of GPIO banks in
which the byte order would be unknown. In this case, the port ordering
in the IMR registers may not match the reversed order in the other
registers (DCBA, and BA-DC or DC-BA).

Signed-off-by: Sander Vanheule 
Reviewed-by: Linus Walleij 
Reviewed-by: Andy Shevchenko 
---
 drivers/gpio/Kconfig |  13 ++
 drivers/gpio/Makefile|   1 +
 drivers/gpio/gpio-realtek-otto.c | 325 +++
 3 files changed, 339 insertions(+)
 create mode 100644 drivers/gpio/gpio-realtek-otto.c

diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index e3607ec4c2e8..6fb13d6507db 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -502,6 +502,19 @@ config GPIO_RDA
help
  Say Y here to support RDA Micro GPIO controller.
 
+config GPIO_REALTEK_OTTO
+   tristate "Realtek Otto GPIO support"
+   depends on MACH_REALTEK_RTL
+   default MACH_REALTEK_RTL
+   select GPIO_GENERIC
+   select GPIOLIB_IRQCHIP
+   help
+ The GPIO controller on the Otto MIPS platform supports up to two
+ banks of 32 GPIOs, with edge triggered interrupts. The 32 GPIOs
+ are grouped in four 8-bit wide ports.
+
+ When built as a module, the module will be called realtek_otto_gpio.
+
 config GPIO_REG
bool
help
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index c58a90a3c3b1..8ace5934e3c3 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -124,6 +124,7 @@ obj-$(CONFIG_GPIO_RC5T583)  += gpio-rc5t583.o
 obj-$(CONFIG_GPIO_RCAR)+= gpio-rcar.o
 obj-$(CONFIG_GPIO_RDA) += gpio-rda.o
 obj-$(CONFIG_GPIO_RDC321X) += gpio-rdc321x.o
+obj-$(CONFIG_GPIO_REALTEK_OTTO)+= gpio-realtek-otto.o
 obj-$(CONFIG_GPIO_REG) += gpio-reg.o
 obj-$(CONFIG_ARCH_SA1100)  += gpio-sa1100.o
 obj-$(CONFIG_GPIO_SAMA5D2_PIOBU)   += gpio-sama5d2-piobu.o
diff --git a/drivers/gpio/gpio-realtek-otto.c b/drivers/gpio/gpio-realtek-otto.c
new file mode 100644
index ..cb64fb5a51aa
--- /dev/null
+++ b/drivers/gpio/gpio-realtek-otto.c
@@ -0,0 +1,325 @@
+// SPDX-License-Identifier: GPL-2.0-only
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/*
+ * Total register block size is 0x1C for one bank of four ports (A, B, C, D).
+ * An optional second bank, with ports E, F, G, and H, may be present, starting
+ * at register offset 0x1C.
+ */
+
+/*
+ * Pin select: (0) "normal", (1) "dedicate peripheral"
+ * Not used on RTL8380/RTL8390, peripheral selection is managed by control bits
+ * in the peripheral registers.
+ */
+#define REALTEK_GPIO_REG_CNR   0x00
+/* Clear bit (0) for input, set bit (1) for output */
+#define REALTEK_GPIO_REG_DIR   0x08
+#define REALTEK_GPIO_REG_DATA  0x0C
+/* Read bit for IRQ status, write 1 to clear IRQ */
+#define REALTEK_GPIO_REG_ISR   0x10
+/* Two bits per GPIO in IMR registers */
+#define REALTEK_GPIO_REG_IMR   0x14
+#define REALTEK_GPIO_REG_IMR_AB0x14
+#define REALTEK_GPIO_REG_IMR_CD0x18
+#define REALTEK_GPIO_IMR_LINE_MASK GENMASK(1, 0)
+#define REALTEK_GPIO_IRQ_EDGE_FALLING  1
+#define REALTEK_GPIO_IRQ_EDGE_RISING   2
+#define REALTEK_GPIO_IRQ_EDGE_BOTH 3
+
+#define REALTEK_GPIO_MAX   32
+#define REALTEK_GPIO_PORTS_PER_BANK4
+
+/**
+ * realtek_gpio_ctrl - Realtek Otto GPIO driver data
+ *
+ * @gc: Associated gpio_chip instance
+ * @base: Base address of the register block for a GPIO bank
+ * @lock: Lock for accessing the IRQ registers and values
+ * @intr_mask: Mask for interrupts lines
+ * @intr_type: Interrupt type selection
+ *
+ * Because the interrupt mask register (IMR) combines the function of IRQ type
+ * selection and masking, two extra values are stored. @intr_mask is used to
+ * mask/unmask the interrupts for a GPIO port, and @intr_type is used to store
+ * the selected interrupt types. The logical AND of these values is written to
+ * IMR on changes.
+ */
+struct realtek_gpio_ctrl {
+   struct gpio_chip gc;
+   void __iomem *base;
+   raw_spinlock_t lock;
+   u16 intr_mask[REALTEK_GPIO_PORTS_PER_BANK];
+   u16 intr_type[REALTEK_GPIO_PORTS_PER_BANK];
+};
+
+/* Expand with 

[PATCH v6 1/2] dt-bindings: gpio: Binding for Realtek Otto GPIO

[Sander Vanheule]

Add a binding description for Realtek's GPIO controller found on several
of their MIPS-based SoCs (codenamed Otto), such as the RTL838x and
RTL839x series of switch SoCs.

A fallback binding 'realtek,otto-gpio' is provided for cases where the
actual port ordering is not known yet, and enabling the interrupt
controller may result in uncaught interrupts.

Signed-off-by: Sander Vanheule 
Reviewed-by: Linus Walleij 
Reviewed-by: Rob Herring 
---
 .../bindings/gpio/realtek,otto-gpio.yaml  | 78 +++
 1 file changed, 78 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/gpio/realtek,otto-gpio.yaml

diff --git a/Documentation/devicetree/bindings/gpio/realtek,otto-gpio.yaml 
b/Documentation/devicetree/bindings/gpio/realtek,otto-gpio.yaml
new file mode 100644
index ..100f20cebd76
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/realtek,otto-gpio.yaml
@@ -0,0 +1,78 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/gpio/realtek,otto-gpio.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Realtek Otto GPIO controller
+
+maintainers:
+  - Sander Vanheule 
+  - Bert Vermeulen 
+
+description: |
+  Realtek's GPIO controller on their MIPS switch SoCs (Otto platform) consists
+  of two banks of 32 GPIOs. These GPIOs can generate edge-triggered interrupts.
+  Each bank's interrupts are cascased into one interrupt line on the parent
+  interrupt controller, if provided.
+  This binding allows defining a single bank in the devicetree. The interrupt
+  controller is not supported on the fallback compatible name, which only
+  allows for GPIO port use.
+
+properties:
+  $nodename:
+pattern: "^gpio@[0-9a-f]+$"
+
+  compatible:
+items:
+  - enum:
+  - realtek,rtl8380-gpio
+  - realtek,rtl8390-gpio
+  - const: realtek,otto-gpio
+
+  reg:
+maxItems: 1
+
+  "#gpio-cells":
+const: 2
+
+  gpio-controller: true
+
+  ngpios:
+minimum: 1
+maximum: 32
+
+  interrupt-controller: true
+
+  "#interrupt-cells":
+const: 2
+
+  interrupts:
+maxItems: 1
+
+required:
+  - compatible
+  - reg
+  - "#gpio-cells"
+  - gpio-controller
+
+additionalProperties: false
+
+dependencies:
+  interrupt-controller: [ interrupts ]
+
+examples:
+  - |
+  gpio@3500 {
+compatible = "realtek,rtl8380-gpio", "realtek,otto-gpio";
+reg = <0x3500 0x1c>;
+gpio-controller;
+#gpio-cells = <2>;
+ngpios = <24>;
+interrupt-controller;
+#interrupt-cells = <2>;
+interrupt-parent = <>;
+interrupts = <23>;
+  };
+
+...
-- 
2.30.2

Re: [PATCH 1/3] MIPS: uaccess: Added __get/__put_kernel_nofault

[Christoph Hellwig]

On Tue, Mar 30, 2021 at 07:26:58PM +0200, Thomas Bogendoerfer wrote:
> Added __get/__put_kernel_nofault as preparation for removing
> get/set_fs.

For !CONFIG_EVA __get_user_common is simply defined to
__get_kernel_common, which probably does the wrong thing here
as it would allow access to user space addresses, won't it?

Re: [PATCH v2] sched/debug: Use sched_debug_lock to serialize use of cgroup_path[] only

[Waiman Long]

On 3/30/21 6:42 AM, Daniel Thompson wrote:

On Mon, Mar 29, 2021 at 03:32:35PM -0400, Waiman Long wrote:

The handling of sysrq keys should normally be done in an user context
except when MAGIC_SYSRQ_SERIAL is set and the magic sequence is typed
in a serial console.

This seems to be a poor summary of the typical calling context for
handle_sysrq() except in the trivial case of using
/proc/sysrq-trigger.

For example on my system then the backtrace when I do sysrq-h on a USB
keyboard shows us running from a softirq handler and with interrupts
locked. Note also that the interrupt lock is present even on systems that
handle keyboard input from a kthread due to the interrupt lock in
report_input_key().
I will reword this part of the patch. I don't have a deep understanding 
of how the different way of keyword input work and thanks for showing me 
that there are other ways of getting keyboard input.



Currently in print_cpu() of kernel/sched/debug.c, sched_debug_lock is taken
with interrupt disabled for the whole duration of the calls to print_*_stats()
and print_rq() which could last for the quite some time if the information dump
happens on the serial console.

If the system has many cpus and the sched_debug_lock is somehow busy
(e.g. parallel sysrq-t), the system may hit a hard lockup panic, like




The purpose of sched_debug_lock is to serialize the use of the global
cgroup_path[] buffer in print_cpu(). The rests of the printk() calls
don't need serialization from sched_debug_lock.

Calling printk() with interrupt disabled can still be/proc/sysrq-trigger
problematic. Allocating a stack buffer of PATH_MAX bytes is not
feasible. So a compromised solution is used where a small stack buffer
is allocated for pathname. If the actual pathname is short enough, it
is copied to the stack buffer with sched_debug_lock release afterward
before printk().  Otherwise, the global group_path[] buffer will be
used with sched_debug_lock held until after printk().

Does this actually fix the problem in any circumstance except when the
sysrq is triggered using /proc/sysrq-trigger?


I have a reproducer that generates hard lockup panic when there are 
multiple instances of sysrq-t via /proc/sysrq-trigger. This is probably 
less a problem on console as I don't think we can do multiple 
simultaneous sysrq-t there. Anyway, my goal is to limit the amount of 
time that irq is disabled. Doing a printk can take a while depending on 
whether there are contention in the underlying locks or resources. Even 
if I limit the the critical sections to just those printk() that outputs 
cgroup path, I can still cause the panic.


Cheers,
Longman

The approach used by this patch should minimize the chance of a panic 
happening. However, if there are many tasks with very long cgroup paths, 
I suppose that panic may still happen under some extreme conditions. So 
I won't say this will completely fix the problem until the printk() 
rework that makes printk work more like printk_deferred() is merged.

Re: Enabling pmbus power control

[Mark Brown]

On Tue, Mar 30, 2021 at 12:19:29PM -0500, Zev Weiss wrote:
> On Tue, Mar 30, 2021 at 06:22:54AM CDT, Mark Brown wrote:
> > On Tue, Mar 30, 2021 at 03:34:16AM -0700, Guenter Roeck wrote:

> > > (and I don't know if the userspace consumer code is appropriate - you
> > > might want to check with the regulator maintainer on that).

> > It's not, you should never see this in a production system.

> Sorry, can you clarify what exactly "this" refers to here?

The userspace consumer.

> > I can't really tell what the issue is here without more context, the
> > global name list should not be relevant for much in a system that's well
> > configured so it sounds like it's user error.

> My initial attempt I guess followed the existing ltc2978 code a little too
> closely and I ended up with all my lm25066 regulators registered under the
> same (static) name, so when I went to attach the reg-userspace-consumer
> instances to them by way of that name I got this:

I don't know what you're trying to do or why, nor how you're going about
achieving it so I can't really comment.  Like I say anything that's
instantiating a userspace consumer in upstream code is broken, it's
there for test during development of regulator drivers.  Whatever device
is supplied by the regulator should have a driver which should control
the regulator at runtime if that is needed.


signature.asc
Description: PGP signature

Re: [PATCH v8 25/38] iio/scmi: Port driver to the new scmi_sensor_proto_ops interface

[Jonathan Cameron]

On Tue, 30 Mar 2021 14:47:11 +0100
Cristian Marussi  wrote:

> Port the scmi iio driver to the new SCMI sensor interface based on
> protocol handles and common devm_get_ops().
> 
> Link: 
> https://lore.kernel.org/r/20210316124903.35011-26-cristian.maru...@arm.com
> Cc: Jyoti Bhayana 
> Cc: Jonathan Cameron 
> Cc: linux-...@vger.kernel.org
> Tested-by: Florian Fainelli 
> Acked-by: Jonathan Cameron 
> Signed-off-by: Cristian Marussi 
> Signed-off-by: Sudeep Holla 

Thanks for doing this, but beyond the more general question I put
in the reply to v7 of why we have this abstraction in the first place,
I'm fine with either version (v7 or v8).

I 'slightly' prefer this one I guess, but it actually hides the
more interesting question of whether the use of a protocol
related function to get access to functions that could just have
been exported from the original module actually makes sense?

Ah well. Let's go with the perfect not being the enemy of good and
all that.

Acked-by: Jonathan Cameron 

for this one as well. Take your pick ;)

Jonathan
 
> 
> v7 --> v8
> - make sensor_ops NON global
> ---
>  drivers/iio/common/scmi_sensors/scmi_iio.c | 100 ++---
>  1 file changed, 50 insertions(+), 50 deletions(-)
> 
> diff --git a/drivers/iio/common/scmi_sensors/scmi_iio.c 
> b/drivers/iio/common/scmi_sensors/scmi_iio.c
> index 872d87ca6256..8f4154d92c68 100644
> --- a/drivers/iio/common/scmi_sensors/scmi_iio.c
> +++ b/drivers/iio/common/scmi_sensors/scmi_iio.c
> @@ -22,7 +22,8 @@
>  #define SCMI_IIO_NUM_OF_AXIS 3
>  
>  struct scmi_iio_priv {
> - struct scmi_handle *handle;
> + const struct scmi_sensor_proto_ops *sensor_ops;
> + struct scmi_protocol_handle *ph;
>   const struct scmi_sensor_info *sensor_info;
>   struct iio_dev *indio_dev;
>   /* adding one additional channel for timestamp */
> @@ -82,7 +83,6 @@ static int scmi_iio_sensor_update_cb(struct notifier_block 
> *nb,
>  static int scmi_iio_buffer_preenable(struct iio_dev *iio_dev)
>  {
>   struct scmi_iio_priv *sensor = iio_priv(iio_dev);
> - u32 sensor_id = sensor->sensor_info->id;
>   u32 sensor_config = 0;
>   int err;
>  
> @@ -92,27 +92,12 @@ static int scmi_iio_buffer_preenable(struct iio_dev 
> *iio_dev)
>  
>   sensor_config |= FIELD_PREP(SCMI_SENS_CFG_SENSOR_ENABLED_MASK,
>   SCMI_SENS_CFG_SENSOR_ENABLE);
> -
> - err = 
> sensor->handle->notify_ops->register_event_notifier(sensor->handle,
> - SCMI_PROTOCOL_SENSOR, SCMI_EVENT_SENSOR_UPDATE,
> - _id, >sensor_update_nb);
> - if (err) {
> - dev_err(_dev->dev,
> - "Error in registering sensor update notifier for sensor 
> %s err %d",
> - sensor->sensor_info->name, err);
> - return err;
> - }
> -
> - err = sensor->handle->sensor_ops->config_set(sensor->handle,
> - sensor->sensor_info->id, sensor_config);
> - if (err) {
> - 
> sensor->handle->notify_ops->unregister_event_notifier(sensor->handle,
> - SCMI_PROTOCOL_SENSOR,
> - SCMI_EVENT_SENSOR_UPDATE, _id,
> - >sensor_update_nb);
> + err = sensor->sensor_ops->config_set(sensor->ph,
> +  sensor->sensor_info->id,
> +  sensor_config);
> + if (err)
>   dev_err(_dev->dev, "Error in enabling sensor %s err %d",
>   sensor->sensor_info->name, err);
> - }
>  
>   return err;
>  }
> @@ -120,25 +105,14 @@ static int scmi_iio_buffer_preenable(struct iio_dev 
> *iio_dev)
>  static int scmi_iio_buffer_postdisable(struct iio_dev *iio_dev)
>  {
>   struct scmi_iio_priv *sensor = iio_priv(iio_dev);
> - u32 sensor_id = sensor->sensor_info->id;
>   u32 sensor_config = 0;
>   int err;
>  
>   sensor_config |= FIELD_PREP(SCMI_SENS_CFG_SENSOR_ENABLED_MASK,
>   SCMI_SENS_CFG_SENSOR_DISABLE);
> -
> - err = 
> sensor->handle->notify_ops->unregister_event_notifier(sensor->handle,
> - SCMI_PROTOCOL_SENSOR, SCMI_EVENT_SENSOR_UPDATE,
> - _id, >sensor_update_nb);
> - if (err) {
> - dev_err(_dev->dev,
> - "Error in unregistering sensor update notifier for 
> sensor %s err %d",
> - sensor->sensor_info->name, err);
> - return err;
> - }
> -
> - err = sensor->handle->sensor_ops->config_set(sensor->handle, sensor_id,
> -  sensor_config);
> + err = sensor->sensor_ops->config_set(sensor->ph,
> +  sensor->sensor_info->id,
> +  sensor_config);
>   if (err) {
>   dev_err(_dev->dev,
>   "Error in disabling 

Re: [PATCH] btrfs: Use readahead_batch_length

[Matthew Wilcox]

ping?

On Sun, Mar 21, 2021 at 09:03:11PM +, Matthew Wilcox (Oracle) wrote:
> Implement readahead_batch_length() to determine the number of bytes in
> the current batch of readahead pages and use it in btrfs.
> 
> Signed-off-by: Matthew Wilcox (Oracle) 
> ---
>  fs/btrfs/extent_io.c| 6 ++
>  include/linux/pagemap.h | 9 +
>  2 files changed, 11 insertions(+), 4 deletions(-)
> 
> diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c
> index e9837562f7d6..97ac4ddb2857 100644
> --- a/fs/btrfs/extent_io.c
> +++ b/fs/btrfs/extent_io.c
> @@ -4875,10 +4875,8 @@ void extent_readahead(struct readahead_control *rac)
>   int nr;
>  
>   while ((nr = readahead_page_batch(rac, pagepool))) {
> - u64 contig_start = page_offset(pagepool[0]);
> - u64 contig_end = page_offset(pagepool[nr - 1]) + PAGE_SIZE - 1;
> -
> - ASSERT(contig_start + nr * PAGE_SIZE - 1 == contig_end);
> + u64 contig_start = readahead_pos(rac);
> + u64 contig_end = contig_start + readahead_batch_length(rac) - 1;
>  
>   contiguous_readpages(pagepool, nr, contig_start, contig_end,
>   _cached, , _flags, _em_start);
> diff --git a/include/linux/pagemap.h b/include/linux/pagemap.h
> index 2cbfd4c36026..92939afd4944 100644
> --- a/include/linux/pagemap.h
> +++ b/include/linux/pagemap.h
> @@ -1174,6 +1174,15 @@ static inline unsigned int readahead_count(struct 
> readahead_control *rac)
>   return rac->_nr_pages;
>  }
>  
> +/**
> + * readahead_batch_length - The number of bytes in the current batch.
> + * @rac: The readahead request.
> + */
> +static inline loff_t readahead_batch_length(struct readahead_control *rac)
> +{
> + return rac->_batch_count * PAGE_SIZE;
> +}
> +
>  static inline unsigned long dir_pages(struct inode *inode)
>  {
>   return (unsigned long)(inode->i_size + PAGE_SIZE - 1) >>
> -- 
> 2.30.2
> 

[PATCH 16/16] dt-bindings: phy: cdns,dphy: add power-domains property

[Pratyush Yadav]

This property is needed on TI platforms to enable the PD of the DPHY
before it can be used.

Signed-off-by: Pratyush Yadav 
---
 Documentation/devicetree/bindings/phy/cdns,dphy.yaml | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/phy/cdns,dphy.yaml 
b/Documentation/devicetree/bindings/phy/cdns,dphy.yaml
index 0807ba68284d..ddcd4de0aef6 100644
--- a/Documentation/devicetree/bindings/phy/cdns,dphy.yaml
+++ b/Documentation/devicetree/bindings/phy/cdns,dphy.yaml
@@ -30,6 +30,9 @@ properties:
   "#phy-cells":
 const: 0
 
+  power-domains:
+maxItems: 1
+
 required:
   - compatible
   - reg
-- 
2.30.0

[PATCH 15/16] dt-bindings: phy: cdns,dphy: make clocks optional

[Pratyush Yadav]

The clocks are not used by the DPHY when used in Rx mode so make them
optional.

Signed-off-by: Pratyush Yadav 
---
 Documentation/devicetree/bindings/phy/cdns,dphy.yaml | 2 --
 1 file changed, 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/phy/cdns,dphy.yaml 
b/Documentation/devicetree/bindings/phy/cdns,dphy.yaml
index d1bbf96a8250..0807ba68284d 100644
--- a/Documentation/devicetree/bindings/phy/cdns,dphy.yaml
+++ b/Documentation/devicetree/bindings/phy/cdns,dphy.yaml
@@ -33,8 +33,6 @@ properties:
 required:
   - compatible
   - reg
-  - clocks
-  - clock-names
   - "#phy-cells"
 
 additionalProperties: false
-- 
2.30.0

[PATCH 14/16] dt-bindings: phy: Convert Cadence DPHY binding to YAML

[Pratyush Yadav]

Convert Cadence DPHY binding to YAML.

Signed-off-by: Pratyush Yadav 
---
 .../devicetree/bindings/phy/cdns,dphy.txt | 20 
 .../devicetree/bindings/phy/cdns,dphy.yaml| 51 +++
 2 files changed, 51 insertions(+), 20 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/phy/cdns,dphy.txt
 create mode 100644 Documentation/devicetree/bindings/phy/cdns,dphy.yaml

diff --git a/Documentation/devicetree/bindings/phy/cdns,dphy.txt 
b/Documentation/devicetree/bindings/phy/cdns,dphy.txt
deleted file mode 100644
index 1095bc4e72d9..
--- a/Documentation/devicetree/bindings/phy/cdns,dphy.txt
+++ /dev/null
@@ -1,20 +0,0 @@
-Cadence DPHY
-
-
-Cadence DPHY block.
-
-Required properties:
-- compatible: should be set to "cdns,dphy".
-- reg: physical base address and length of the DPHY registers.
-- clocks: DPHY reference clocks.
-- clock-names: must contain "psm" and "pll_ref".
-- #phy-cells: must be set to 0.
-
-Example:
-   dphy0: dphy@fd0e{
-   compatible = "cdns,dphy";
-   reg = <0x0 0xfd0e 0x0 0x1000>;
-   clocks = <_clk>, <_ref_clk>;
-   clock-names = "psm", "pll_ref";
-   #phy-cells = <0>;
-   };
diff --git a/Documentation/devicetree/bindings/phy/cdns,dphy.yaml 
b/Documentation/devicetree/bindings/phy/cdns,dphy.yaml
new file mode 100644
index ..d1bbf96a8250
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/cdns,dphy.yaml
@@ -0,0 +1,51 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/cdns,dphy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Cadence DPHY Device Tree Bindings
+
+maintainers:
+  - Pratyush Yadav 
+
+properties:
+  compatible:
+items:
+  - const: cdns,dphy
+
+  reg:
+maxItems: 1
+description: Physical base address and length of the DPHY registers.
+
+  clocks:
+maxItems: 2
+description: DPHY reference clocks.
+
+  clock-names:
+items:
+  - const: psm
+  - const: pll_ref
+
+  "#phy-cells":
+const: 0
+
+required:
+  - compatible
+  - reg
+  - clocks
+  - clock-names
+  - "#phy-cells"
+
+additionalProperties: false
+
+examples:
+  - |
+
+dphy0: dphy@fd0e{
+compatible = "cdns,dphy";
+reg = <0xfd0e 0x1000>;
+clocks = <_clk>, <_ref_clk>;
+clock-names = "psm", "pll_ref";
+#phy-cells = <0>;
+};
-- 
2.30.0

[PATCH 13/16] media: ti-vpe: csi2rx: Add CSI2RX support

[Pratyush Yadav]

TI's J721E uses the Cadence CSI2RX and DPHY peripherals to facilitate
capture over a CSI-2 bus.

The Cadence CSI2RX IP acts as a bridge between the TI specific parts and
the CSI-2 protocol parts. TI then has a wrapper on top of this bridge
called the SHIM layer. It takes in data from stream 0, repacks it, and
sends it to memory over PSI-L DMA.

This driver acts as the "front end" to V4L2 client applications. It
implements the required ioctls and buffer operations, passes the
necessary calls on to the bridge, programs the SHIM layer, and performs
DMA via the dmaengine API to finally return the data to a buffer
supplied by the application.

Signed-off-by: Pratyush Yadav 
---
 MAINTAINERS   |   7 +
 drivers/media/platform/Kconfig|  11 +
 drivers/media/platform/ti-vpe/Makefile|   1 +
 drivers/media/platform/ti-vpe/ti-csi2rx.c | 964 ++
 4 files changed, 983 insertions(+)
 create mode 100644 drivers/media/platform/ti-vpe/ti-csi2rx.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 8c44fd8fd85d..06fb8fdb874d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -18006,6 +18006,13 @@ S: Odd Fixes
 F: drivers/clk/ti/
 F: include/linux/clk/ti.h
 
+TI CSI2RX DRIVER
+M: Pratyush Yadav 
+L: linux-me...@vger.kernel.org
+S: Maintained
+F: Documentation/devicetree/bindings/media/ti,csi2rx.yaml
+F: drivers/media/platform/ti-vpe/ti-csi2rx.c
+
 TI DAVINCI MACHINE SUPPORT
 M: Sekhar Nori 
 R: Bartosz Golaszewski 
diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index b238a923d1b4..3b240d8e4cb8 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -200,6 +200,17 @@ config VIDEO_TI_CAL_MC
 
 endif # VIDEO_TI_CAL
 
+config VIDEO_TI_CSI2RX
+   tristate "TI CSI2RX wrapper layer driver"
+   depends on VIDEO_DEV && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API && 
MEDIA_SUPPORT
+   depends on PHY_CADENCE_DPHY && VIDEO_CADENCE_CSI2RX
+   depends on ARCH_K3 || COMPILE_TEST
+   select VIDEOBUF2_DMA_CONTIG
+   select V4L2_FWNODE
+   help
+ Support for TI CSI2RX wrapper layer. This just enables the wrapper 
driver.
+ The Cadence CSI2RX bridge driver needs to be enabled separately.
+
 endif # V4L_PLATFORM_DRIVERS
 
 menuconfig V4L_MEM2MEM_DRIVERS
diff --git a/drivers/media/platform/ti-vpe/Makefile 
b/drivers/media/platform/ti-vpe/Makefile
index ad624056e039..c4ee49484b73 100644
--- a/drivers/media/platform/ti-vpe/Makefile
+++ b/drivers/media/platform/ti-vpe/Makefile
@@ -3,6 +3,7 @@ obj-$(CONFIG_VIDEO_TI_VPE) += ti-vpe.o
 obj-$(CONFIG_VIDEO_TI_VPDMA) += ti-vpdma.o
 obj-$(CONFIG_VIDEO_TI_SC) += ti-sc.o
 obj-$(CONFIG_VIDEO_TI_CSC) += ti-csc.o
+obj-$(CONFIG_VIDEO_TI_CSI2RX) += ti-csi2rx.o
 
 ti-vpe-y := vpe.o
 ti-vpdma-y := vpdma.o
diff --git a/drivers/media/platform/ti-vpe/ti-csi2rx.c 
b/drivers/media/platform/ti-vpe/ti-csi2rx.c
new file mode 100644
index ..355204ae473b
--- /dev/null
+++ b/drivers/media/platform/ti-vpe/ti-csi2rx.c
@@ -0,0 +1,964 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * TI CSI2 RX driver.
+ *
+ * Copyright (C) 2021 Texas Instruments Incorporated - https://www.ti.com/
+ *
+ * Author: Pratyush Yadav 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#define TI_CSI2RX_MODULE_NAME  "ti-csi2rx"
+
+#define SHIM_CNTL  0x10
+#define SHIM_CNTL_PIX_RST  BIT(0)
+
+#define SHIM_DMACNTX   0x20
+#define SHIM_DMACNTX_ENBIT(31)
+#define SHIM_DMACNTX_YUV422GENMASK(27, 26)
+#define SHIM_DMACNTX_FMT   GENMASK(5, 0)
+#define SHIM_DMACNTX_UYVY  0
+#define SHIM_DMACNTX_VYUY  1
+#define SHIM_DMACNTX_YUYV  2
+#define SHIM_DMACNTX_YVYU  3
+
+#define SHIM_PSI_CFG0  0x24
+#define SHIM_PSI_CFG0_SRC_TAG  GENMASK(15, 0)
+#define SHIM_PSI_CFG0_DST_TAG  GENMASK(31, 15)
+
+#define CSI_DF_YUV420  0x18
+#define CSI_DF_YUV422  0x1e
+#define CSI_DF_RGB444  0x20
+#define CSI_DF_RGB888  0x24
+
+struct ti_csi2rx_fmt {
+   u32 fourcc; /* Four character code. */
+   u32 code;   /* Mbus code. */
+   u32 csi_df; /* CSI Data format. */
+   u8  bpp;/* Bits per pixel. */
+};
+
+struct ti_csi2rx_buffer {
+   /* Common v4l2 buffer. Must be first. */
+   struct vb2_v4l2_buffer  vb;
+   struct list_headlist;
+};
+
+struct ti_csi2rx_dmaq {
+   struct list_headlist;
+};
+
+struct ti_csi2rx_dev {
+   struct device   *dev;
+   void __iomem*shim;
+   struct v4l2_device  v4l2_dev;
+   struct video_device vdev;
+   struct 

[PATCH 12/16] dt-bindings: media: Add DT bindings for TI CSI2RX driver

[Pratyush Yadav]

TI's J721E uses the Cadence CSI2RX and DPHY peripherals to facilitate
capture over a CSI-2 bus. The TI CSI2RX platform driver glues all the
parts together.

Signed-off-by: Pratyush Yadav 
---
 .../devicetree/bindings/media/ti,csi2rx.yaml  | 70 +++
 1 file changed, 70 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/ti,csi2rx.yaml

diff --git a/Documentation/devicetree/bindings/media/ti,csi2rx.yaml 
b/Documentation/devicetree/bindings/media/ti,csi2rx.yaml
new file mode 100644
index ..ebd894364391
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/ti,csi2rx.yaml
@@ -0,0 +1,70 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/ti,csi2rx.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI CSI2RX Wrapper Device Tree Bindings
+
+maintainers:
+  - Pratyush Yadav 
+
+properties:
+  compatible:
+items:
+  - const: ti,csi2rx
+
+  dmas:
+description: RX DMA Channel 0
+
+  dma-names:
+items:
+  - const: rx0
+
+  reg:
+maxItems: 1
+description: Base address and size of the TI wrapper registers.
+
+  power-domains:
+maxItems: 1
+description:
+  PM domain provider node and an args specifier containing
+  the device id value.
+
+  ranges: true
+
+  "#address-cells":
+const: 2
+
+  "#size-cells":
+const: 2
+
+patternProperties:
+  "csi-bridge@":
+type: object
+description: CSI2 bridge node.
+
+required:
+  - compatible
+  - reg
+  - dmas
+  - dma-names
+  - power-domains
+  - "#address-cells"
+  - "#size-cells"
+
+additionalProperties: false
+
+examples:
+  - |
+#include 
+
+ti_csi2rx0: ticsi2rx {
+compatible = "ti,csi2rx";
+dmas = <_udmap 0x4940>;
+dma-names = "rx0";
+reg = <0x0 0x450 0x0 0x1000>;
+power-domains = <_pds 26 TI_SCI_PD_EXCLUSIVE>;
+#address-cells = <2>;
+#size-cells = <2>;
+};
-- 
2.30.0

Re: [PATCH v2 3/7] powerpc: convert config files to generic cmdline

[Daniel Walker]

On Mon, Mar 29, 2021 at 11:07:51AM +0100, Will Deacon wrote:
> On Thu, Mar 25, 2021 at 12:59:56PM -0700, Daniel Walker wrote:
> > On Thu, Mar 25, 2021 at 01:03:55PM +0100, Christophe Leroy wrote:
> > > 
> > > Ok, so you agree we don't need to provide two CMDLINE, one to be appended 
> > > and one to be prepended.
> > > 
> > > Let's only provide once CMDLINE as of today, and ask the user to select
> > > whether he wants it appended or prepended or replacee. Then no need to
> > > change all existing config to rename CONFIG_CMDLINE into either of the new
> > > ones.
> > > 
> > > That's the main difference between my series and Daniel's series. So I'll
> > > finish taking Will's comment into account and we'll send out a v3 soon.
> > 
> > It doesn't solve the needs of Cisco, I've stated many times your changes 
> > have
> > little value. Please stop submitting them.
> 
> FWIW, they're useful for arm64 and I will gladly review the updated series.
> 
> I don't think asking people to stop submitting patches is ever the right
> answer. Please don't do that.

Why ? It's me nacking his series, is that not allowed anymore ?

Daniel

Re: [PATCH v7 25/38] iio/scmi: port driver to the new scmi_sensor_proto_ops interface

[Jonathan Cameron]

On Tue, 30 Mar 2021 13:51:13 +0100
Cristian Marussi  wrote:

> Hi Jonathan,
> 
> On Tue, Mar 30, 2021 at 12:33:25PM +0100, Jonathan Cameron wrote:
> > On Tue, 16 Mar 2021 12:48:50 +
> > Cristian Marussi  wrote:
> >   
> > > Port driver to the new SCMI Sensor interface based on protocol handles
> > > and common devm_get_ops().
> > > 
> > > Cc: Jyoti Bhayana 
> > > Cc: Jonathan Cameron 
> > > Signed-off-by: Cristian Marussi   
> > 
> > +CC linux-...@vger.kernel.org
> > 
> > Rule of thumb if it doesn't go there it ends up in randomly location based
> > on other lists and I might not see it for a few weeks :(
> >   
> 
> Ah sorry, I thought the direct CC was enough.

No problem. Too much email :)

> 
> > > ---
> > >  drivers/iio/common/scmi_sensors/scmi_iio.c | 91 ++
> > >  1 file changed, 41 insertions(+), 50 deletions(-)
> > > 
> > > diff --git a/drivers/iio/common/scmi_sensors/scmi_iio.c 
> > > b/drivers/iio/common/scmi_sensors/scmi_iio.c
> > > index 872d87ca6256..b4bdc3f3a946 100644
> > > --- a/drivers/iio/common/scmi_sensors/scmi_iio.c
> > > +++ b/drivers/iio/common/scmi_sensors/scmi_iio.c
> > > @@ -21,8 +21,10 @@
> > >  
> > >  #define SCMI_IIO_NUM_OF_AXIS 3
> > >  
> > > +static const struct scmi_sensor_proto_ops *sensor_ops;  
> > 
> > Hmm.   I'm not keen on globals when they really should not be necessary.
> > They just result in lifetimes being out of sync.  Here you are fine because
> > you set it to an appropriate value as the first thing you do in probe, and
> > I assume the function only ever returns on answer on repeated calls.
> > 
> > Why not put a copy of that pointer inside the struct scmi_iio_priv 
> > structures?
> >   
> 
> The reason for this, as I said to Jyoyi who made the same comment indeed,
> from my point of view (maybe wrong..) was that while the protocol_handle,
> and previously the handle, are 'per-instance data' (so that you get a
> different one each time this driver is possibly probed against a different
> platform-handle) and as such are stored in scmi_iio_priv, the _ops are
> just plain code pointers and are returned always the same for the same
> protocol no matter how many times you probe this driver:

As that's the case, I'm a little confused to why you have added the complexity
of a query interface in the first place?  Why not just export the ops and
have the various drivers access them directly?  If there is only
one set of scmi_sensor_ops etc, then let drivers at it directly, or
indeed export the functions that make up the ops structure directly.

This sounds like a bit of abstraction that only serves to make the
code harder to read.

> you just end up
> calling them against the proper different saved protocol_handle; so it
> seemed to me an unneeded duplication to stick a copy of the same _ops
> inside each per-instance scmi_iio_priv, and at the same time it seemed
> also more straigthforward to access them without too many indirections
> from inside the scmi_iio_priv struct).
> 
> But if these are not valid points I can change this in IIO now, and in
> the future also in all the other SCMI drivers that currently use this
> same API and pattern of usage with global ops. (..at least because I'd
> have to collect again all the other ACks agains and it's a bit later for
> that now)

I'm fine with leaving it as is.  There's no fundamental issue, it's just
a little bit ugly and I'm fussy :)

> 
> Thanks
> 
> Cristian
> 
> > Otherwise this all looks like straight forward refactoring so given the
> > above is more a 'bad smell' than a bug and I'm rather late to the game.
> > 
> > Acked-by: Jonathan Cameron 
> > 
> >   
> > > +
> > >  struct scmi_iio_priv {
> > > - struct scmi_handle *handle;
> > > + struct scmi_protocol_handle *ph;
> > >   const struct scmi_sensor_info *sensor_info;
> > >   struct iio_dev *indio_dev;
> > >   /* adding one additional channel for timestamp */
> > > @@ -82,7 +84,6 @@ static int scmi_iio_sensor_update_cb(struct 
> > > notifier_block *nb,
> > >  static int scmi_iio_buffer_preenable(struct iio_dev *iio_dev)
> > >  {
> > >   struct scmi_iio_priv *sensor = iio_priv(iio_dev);
> > > - u32 sensor_id = sensor->sensor_info->id;
> > >   u32 sensor_config = 0;
> > >   int err;
> > >  
> > > @@ -92,27 +93,11 @@ static int scmi_iio_buffer_preenable(struct iio_dev 
> > > *iio_dev)
> > >  
> > >   sensor_config |= FIELD_PREP(SCMI_SENS_CFG_SENSOR_ENABLED_MASK,
> > >   SCMI_SENS_CFG_SENSOR_ENABLE);
> > > -
> > > - err = 
> > > sensor->handle->notify_ops->register_event_notifier(sensor->handle,
> > > - SCMI_PROTOCOL_SENSOR, SCMI_EVENT_SENSOR_UPDATE,
> > > - _id, >sensor_update_nb);
> > > - if (err) {
> > > - dev_err(_dev->dev,
> > > - "Error in registering sensor update notifier for sensor 
> > > %s err %d",
> > > - sensor->sensor_info->name, err);
> > > - return err;
> > > - }
> > > -
> > > - err = 

[PATCH 11/16] dmaengine: ti: k3-psil-j721e: Add entry for CSI2RX

[Pratyush Yadav]

The CSI2RX subsystem uses PSI-L DMA to transfer frames to memory. It can
have up to 32 threads but the current driver only supports using one. So
add an entry for that one thread.

Signed-off-by: Pratyush Yadav 
---
 drivers/dma/ti/k3-psil-j721e.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/dma/ti/k3-psil-j721e.c b/drivers/dma/ti/k3-psil-j721e.c
index 7580870ed746..19ffa31e6dc6 100644
--- a/drivers/dma/ti/k3-psil-j721e.c
+++ b/drivers/dma/ti/k3-psil-j721e.c
@@ -58,6 +58,14 @@
},  \
}
 
+#define PSIL_CSI2RX(x) \
+   {   \
+   .thread_id = x, \
+   .ep_config = {  \
+   .ep_type = PSIL_EP_NATIVE,  \
+   },  \
+   }
+
 /* PSI-L source thread IDs, used for RX (DMA_DEV_TO_MEM) */
 static struct psil_ep j721e_src_ep_map[] = {
/* SA2UL */
@@ -138,6 +146,8 @@ static struct psil_ep j721e_src_ep_map[] = {
PSIL_PDMA_XY_PKT(0x4707),
PSIL_PDMA_XY_PKT(0x4708),
PSIL_PDMA_XY_PKT(0x4709),
+   /* CSI2RX */
+   PSIL_CSI2RX(0x4940),
/* CPSW9 */
PSIL_ETHERNET(0x4a00),
/* CPSW0 */
-- 
2.30.0

[PATCH 10/16] media: cadence: csi2rx: Add wrappers for subdev calls

[Pratyush Yadav]

When this bridge driver is being user by another platform driver, it
might want to call subdev operations like getting format, setting
format, enumerating format codes, etc. Add wrapper functions that pass
that call through to the sensor.

Currently wrappers are added only for the ops used by TI's platform
driver. More can be added later as needed.

Signed-off-by: Pratyush Yadav 
---
 drivers/media/platform/cadence/cdns-csi2rx.c | 77 
 1 file changed, 77 insertions(+)

diff --git a/drivers/media/platform/cadence/cdns-csi2rx.c 
b/drivers/media/platform/cadence/cdns-csi2rx.c
index 3385e1bc213e..2e8bbc53cb8b 100644
--- a/drivers/media/platform/cadence/cdns-csi2rx.c
+++ b/drivers/media/platform/cadence/cdns-csi2rx.c
@@ -408,12 +408,89 @@ static int csi2rx_s_stream(struct v4l2_subdev *subdev, 
int enable)
return ret;
 }
 
+static int csi2rx_g_frame_interval(struct v4l2_subdev *subdev,
+  struct v4l2_subdev_frame_interval *fi)
+{
+   struct csi2rx_priv *csi2rx = v4l2_subdev_to_csi2rx(subdev);
+
+   return v4l2_subdev_call(csi2rx->source_subdev, video, g_frame_interval,
+   fi);
+}
+
+static int csi2rx_s_frame_interval(struct v4l2_subdev *subdev,
+  struct v4l2_subdev_frame_interval *fi)
+{
+   struct csi2rx_priv *csi2rx = v4l2_subdev_to_csi2rx(subdev);
+
+   return v4l2_subdev_call(csi2rx->source_subdev, video, s_frame_interval,
+   fi);
+}
+
+static int csi2rx_enum_mbus_code(struct v4l2_subdev *subdev,
+struct v4l2_subdev_pad_config *cfg,
+struct v4l2_subdev_mbus_code_enum *code)
+{
+   struct csi2rx_priv *csi2rx = v4l2_subdev_to_csi2rx(subdev);
+
+   return v4l2_subdev_call(csi2rx->source_subdev, pad, enum_mbus_code,
+   cfg, code);
+}
+
+static int csi2rx_get_fmt(struct v4l2_subdev *subdev,
+ struct v4l2_subdev_pad_config *cfg,
+ struct v4l2_subdev_format *fmt)
+{
+   struct csi2rx_priv *csi2rx = v4l2_subdev_to_csi2rx(subdev);
+
+   return v4l2_subdev_call(csi2rx->source_subdev, pad, get_fmt, cfg, fmt);
+}
+
+static int csi2rx_set_fmt(struct v4l2_subdev *subdev,
+ struct v4l2_subdev_pad_config *cfg,
+ struct v4l2_subdev_format *fmt)
+{
+   struct csi2rx_priv *csi2rx = v4l2_subdev_to_csi2rx(subdev);
+
+   return v4l2_subdev_call(csi2rx->source_subdev, pad, set_fmt, cfg, fmt);
+}
+
+static int csi2rx_enum_frame_size(struct v4l2_subdev *subdev,
+ struct v4l2_subdev_pad_config *cfg,
+ struct v4l2_subdev_frame_size_enum *fse)
+{
+   struct csi2rx_priv *csi2rx = v4l2_subdev_to_csi2rx(subdev);
+
+   return v4l2_subdev_call(csi2rx->source_subdev, pad, enum_frame_size,
+   cfg, fse);
+}
+
+static int csi2rx_enum_frame_interval(struct v4l2_subdev *subdev,
+ struct v4l2_subdev_pad_config *cfg,
+ struct v4l2_subdev_frame_interval_enum 
*fie)
+{
+   struct csi2rx_priv *csi2rx = v4l2_subdev_to_csi2rx(subdev);
+
+   return v4l2_subdev_call(csi2rx->source_subdev, pad, enum_frame_interval,
+   cfg, fie);
+}
+
 static const struct v4l2_subdev_video_ops csi2rx_video_ops = {
.s_stream   = csi2rx_s_stream,
+   .g_frame_interval = csi2rx_g_frame_interval,
+   .s_frame_interval = csi2rx_s_frame_interval,
+};
+
+static const struct v4l2_subdev_pad_ops csi2rx_pad_ops = {
+   .enum_mbus_code = csi2rx_enum_mbus_code,
+   .get_fmt= csi2rx_get_fmt,
+   .set_fmt= csi2rx_set_fmt,
+   .enum_frame_size = csi2rx_enum_frame_size,
+   .enum_frame_interval = csi2rx_enum_frame_interval,
 };
 
 static const struct v4l2_subdev_ops csi2rx_subdev_ops = {
.video  = _video_ops,
+   .pad= _pad_ops,
 };
 
 static int csi2rx_async_bound(struct v4l2_async_notifier *notifier,
-- 
2.30.0

[PATCH 09/16] media: cadence: csi2rx: Turn subdev power on before starting stream

[Pratyush Yadav]

The subdevice power needs to be turned on before the stream is started.
Otherwise it might not be in the proper state to stream the data. Turn
it off when stopping the stream.

Signed-off-by: Pratyush Yadav 
---
 drivers/media/platform/cadence/cdns-csi2rx.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/media/platform/cadence/cdns-csi2rx.c 
b/drivers/media/platform/cadence/cdns-csi2rx.c
index 7d1ac51e0698..3385e1bc213e 100644
--- a/drivers/media/platform/cadence/cdns-csi2rx.c
+++ b/drivers/media/platform/cadence/cdns-csi2rx.c
@@ -256,6 +256,10 @@ static int csi2rx_start(struct csi2rx_priv *csi2rx)
 
writel(reg, csi2rx->base + CSI2RX_STATIC_CFG_REG);
 
+   ret = v4l2_subdev_call(csi2rx->source_subdev, core, s_power, true);
+   if (ret && ret != -ENOIOCTLCMD)
+   goto err_disable_pclk;
+
ret = v4l2_subdev_call(csi2rx->source_subdev, video, s_stream, true);
if (ret)
goto err_disable_pclk;
@@ -358,6 +362,10 @@ static void csi2rx_stop(struct csi2rx_priv *csi2rx)
if (v4l2_subdev_call(csi2rx->source_subdev, video, s_stream, false))
dev_warn(csi2rx->dev, "Couldn't disable our subdev\n");
 
+   ret = v4l2_subdev_call(csi2rx->source_subdev, core, s_power, false);
+   if (ret && ret != -ENOIOCTLCMD)
+   dev_warn(csi2rx->dev, "Couldn't power off subdev\n");
+
if (csi2rx->dphy) {
writel(0, csi2rx->base + CSI2RX_DPHY_LANE_CTRL_REG);
 
-- 
2.30.0

[PATCH 08/16] media: cadence: csi2rx: Fix stream data configuration

[Pratyush Yadav]

Firstly, there is no VC_EN bit present in the STREAM_DATA_CFG register.
Bit 31 is part of the VL_SELECT field. Remove it completely.

Secondly, it makes little sense to enable ith virtual channel for ith
stream. Sure, there might be a use-case that demands it. But there might
also be a use case that demands all streams to use the 0th virtual
channel. Prefer this case over the former because it is less arbitrary
and also makes it very clear what the limitations of the current driver
is instead of giving a false impression that multiple virtual channels
are supported.

Signed-off-by: Pratyush Yadav 
---
 drivers/media/platform/cadence/cdns-csi2rx.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/media/platform/cadence/cdns-csi2rx.c 
b/drivers/media/platform/cadence/cdns-csi2rx.c
index eca65b157f59..7d1ac51e0698 100644
--- a/drivers/media/platform/cadence/cdns-csi2rx.c
+++ b/drivers/media/platform/cadence/cdns-csi2rx.c
@@ -48,7 +48,6 @@
 #define CSI2RX_STREAM_STATUS_RDY   BIT(31)
 
 #define CSI2RX_STREAM_DATA_CFG_REG(n)  (CSI2RX_STREAM_BASE(n) + 0x008)
-#define CSI2RX_STREAM_DATA_CFG_EN_VC_SELECTBIT(31)
 #define CSI2RX_STREAM_DATA_CFG_VC_SELECT(n)BIT((n) + 16)
 
 #define CSI2RX_STREAM_CFG_REG(n)   (CSI2RX_STREAM_BASE(n) + 0x00c)
@@ -290,8 +289,11 @@ static int csi2rx_start(struct csi2rx_priv *csi2rx)
writel(CSI2RX_STREAM_CFG_FIFO_MODE_LARGE_BUF,
   csi2rx->base + CSI2RX_STREAM_CFG_REG(i));
 
-   writel(CSI2RX_STREAM_DATA_CFG_EN_VC_SELECT |
-  CSI2RX_STREAM_DATA_CFG_VC_SELECT(i),
+   /*
+* Enable one virtual channel. When multiple virtual channels
+* are supported this will have to be changed.
+*/
+   writel(CSI2RX_STREAM_DATA_CFG_VC_SELECT(0),
   csi2rx->base + CSI2RX_STREAM_DATA_CFG_REG(i));
 
writel(CSI2RX_STREAM_CTRL_START,
-- 
2.30.0

[PATCH 07/16] media: cadence: csi2rx: Set the STOP bit when stopping a stream

[Pratyush Yadav]

The stream stop procedure says that the STOP bit should be set when the
stream is to be stopped, and then the ready bit in stream status
register polled to make sure the STOP operation is finished.

Signed-off-by: Pratyush Yadav 
---
 drivers/media/platform/cadence/cdns-csi2rx.c | 18 +-
 1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/drivers/media/platform/cadence/cdns-csi2rx.c 
b/drivers/media/platform/cadence/cdns-csi2rx.c
index b03d2d2e6762..eca65b157f59 100644
--- a/drivers/media/platform/cadence/cdns-csi2rx.c
+++ b/drivers/media/platform/cadence/cdns-csi2rx.c
@@ -8,6 +8,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -40,8 +41,12 @@
 
 #define CSI2RX_STREAM_CTRL_REG(n)  (CSI2RX_STREAM_BASE(n) + 0x000)
 #define CSI2RX_STREAM_CTRL_SOFT_RSTBIT(4)
+#define CSI2RX_STREAM_CTRL_STOPBIT(1)
 #define CSI2RX_STREAM_CTRL_START   BIT(0)
 
+#define CSI2RX_STREAM_STATUS_REG(n)(CSI2RX_STREAM_BASE(n) + 0x004)
+#define CSI2RX_STREAM_STATUS_RDY   BIT(31)
+
 #define CSI2RX_STREAM_DATA_CFG_REG(n)  (CSI2RX_STREAM_BASE(n) + 0x008)
 #define CSI2RX_STREAM_DATA_CFG_EN_VC_SELECTBIT(31)
 #define CSI2RX_STREAM_DATA_CFG_VC_SELECT(n)BIT((n) + 16)
@@ -325,12 +330,23 @@ static int csi2rx_start(struct csi2rx_priv *csi2rx)
 static void csi2rx_stop(struct csi2rx_priv *csi2rx)
 {
unsigned int i;
+   u32 val;
+   int ret;
 
clk_prepare_enable(csi2rx->p_clk);
clk_disable_unprepare(csi2rx->sys_clk);
 
for (i = 0; i < csi2rx->max_streams; i++) {
-   writel(0, csi2rx->base + CSI2RX_STREAM_CTRL_REG(i));
+   writel(CSI2RX_STREAM_CTRL_STOP,
+  csi2rx->base + CSI2RX_STREAM_CTRL_REG(i));
+
+   ret = readl_relaxed_poll_timeout(csi2rx->base +
+CSI2RX_STREAM_STATUS_REG(i),
+val,
+(val & 
CSI2RX_STREAM_STATUS_RDY),
+10, 1);
+   if (ret)
+   dev_warn(csi2rx->dev, "Failed to stop stream%d\n", i);
 
clk_disable_unprepare(csi2rx->pixel_clk[i]);
}
-- 
2.30.0

[PATCH 05/16] media: cadence: csi2rx: Add external DPHY support

[Pratyush Yadav]

Some platforms like TI's J721E can have the CSI2RX paired with an
external DPHY. Add support to enable and configure the DPHY using the
generic PHY framework.

Get the pixel rate and bpp from the subdev and pass them on to the DPHY
along with the number of lanes. All other settings are left to their
default values.

Signed-off-by: Pratyush Yadav 
---
 drivers/media/platform/cadence/cdns-csi2rx.c | 147 +--
 1 file changed, 137 insertions(+), 10 deletions(-)

diff --git a/drivers/media/platform/cadence/cdns-csi2rx.c 
b/drivers/media/platform/cadence/cdns-csi2rx.c
index c68a3eac62cd..31bd80e3f780 100644
--- a/drivers/media/platform/cadence/cdns-csi2rx.c
+++ b/drivers/media/platform/cadence/cdns-csi2rx.c
@@ -30,6 +30,12 @@
 #define CSI2RX_STATIC_CFG_DLANE_MAP(llane, plane)  ((plane) << (16 + 
(llane) * 4))
 #define CSI2RX_STATIC_CFG_LANES_MASK   GENMASK(11, 8)
 
+#define CSI2RX_DPHY_LANE_CTRL_REG  0x40
+#define CSI2RX_DPHY_CL_RST BIT(16)
+#define CSI2RX_DPHY_DL_RST(i)  BIT((i) + 12)
+#define CSI2RX_DPHY_CL_EN  BIT(4)
+#define CSI2RX_DPHY_DL_EN(i)   BIT(i)
+
 #define CSI2RX_STREAM_BASE(n)  (((n) + 1) * 0x100)
 
 #define CSI2RX_STREAM_CTRL_REG(n)  (CSI2RX_STREAM_BASE(n) + 0x000)
@@ -54,6 +60,11 @@ enum csi2rx_pads {
CSI2RX_PAD_MAX,
 };
 
+struct csi2rx_fmt {
+   u32 code;
+   u8  bpp;
+};
+
 struct csi2rx_priv {
struct device   *dev;
unsigned intcount;
@@ -85,6 +96,52 @@ struct csi2rx_priv {
int source_pad;
 };
 
+static const struct csi2rx_fmt formats[] = {
+   {
+   .code   = MEDIA_BUS_FMT_YUYV8_2X8,
+   .bpp= 16,
+   },
+   {
+   .code   = MEDIA_BUS_FMT_UYVY8_2X8,
+   .bpp= 16,
+   },
+   {
+   .code   = MEDIA_BUS_FMT_YVYU8_2X8,
+   .bpp= 16,
+   },
+   {
+   .code   = MEDIA_BUS_FMT_VYUY8_2X8,
+   .bpp= 16,
+   },
+};
+
+static u8 csi2rx_get_bpp(u32 code)
+{
+   int i;
+
+   for (i = 0; i < ARRAY_SIZE(formats); i++) {
+   if (formats[i].code == code)
+   return formats[i].bpp;
+   }
+
+   return 0;
+}
+
+static s64 csi2rx_get_pixel_rate(struct csi2rx_priv *csi2rx)
+{
+   struct v4l2_ctrl *ctrl;
+
+   ctrl = v4l2_ctrl_find(csi2rx->source_subdev->ctrl_handler,
+ V4L2_CID_PIXEL_RATE);
+   if (!ctrl) {
+   dev_err(csi2rx->dev, "no pixel rate control in subdev: %s\n",
+   csi2rx->source_subdev->name);
+   return -EINVAL;
+   }
+
+   return v4l2_ctrl_g_ctrl_int64(ctrl);
+}
+
 static inline
 struct csi2rx_priv *v4l2_subdev_to_csi2rx(struct v4l2_subdev *subdev)
 {
@@ -101,6 +158,55 @@ static void csi2rx_reset(struct csi2rx_priv *csi2rx)
writel(0, csi2rx->base + CSI2RX_SOFT_RESET_REG);
 }
 
+static int csi2rx_configure_external_dphy(struct csi2rx_priv *csi2rx)
+{
+   union phy_configure_opts opts = { };
+   struct phy_configure_opts_mipi_dphy *cfg = _dphy;
+   struct v4l2_subdev_format sd_fmt;
+   s64 pixel_rate;
+   int ret;
+   u8 bpp;
+
+   sd_fmt.which = V4L2_SUBDEV_FORMAT_ACTIVE;
+   sd_fmt.pad = 0;
+
+   ret = v4l2_subdev_call(csi2rx->source_subdev, pad, get_fmt, NULL,
+  _fmt);
+   if (ret)
+   return ret;
+
+   bpp = csi2rx_get_bpp(sd_fmt.format.code);
+   if (!bpp)
+   return -EINVAL;
+
+   pixel_rate = csi2rx_get_pixel_rate(csi2rx);
+   if (pixel_rate < 0)
+   return pixel_rate;
+
+   ret = phy_mipi_dphy_get_default_config(pixel_rate, bpp,
+  csi2rx->num_lanes, cfg);
+   if (ret)
+   return ret;
+
+   ret = phy_set_mode_ext(csi2rx->dphy, PHY_MODE_MIPI_DPHY,
+  PHY_MIPI_DPHY_SUBMODE_RX);
+   if (ret)
+   return ret;
+
+   ret = phy_power_on(csi2rx->dphy);
+   if (ret)
+   return ret;
+
+   ret = phy_configure(csi2rx->dphy, );
+   if (ret) {
+   /* Can't do anything if it fails. Ignore the return value. */
+   phy_power_off(csi2rx->dphy);
+   return ret;
+   }
+
+   return 0;
+}
+
 static int csi2rx_start(struct csi2rx_priv *csi2rx)
 {
unsigned int i;
@@ -139,6 +245,17 @@ static int csi2rx_start(struct csi2rx_priv *csi2rx)
if (ret)
goto err_disable_pclk;
 
+   /* Enable DPHY clk and data lanes. */
+   if (csi2rx->dphy) {
+   reg = CSI2RX_DPHY_CL_EN | CSI2RX_DPHY_CL_RST;
+   for (i = 0; i < csi2rx->num_lanes; i++) {
+   reg |= 

[PATCH 06/16] media: cadence: csi2rx: Soft reset the streams before starting capture

[Pratyush Yadav]

This resets the stream state machines and FIFOs, giving them a clean
slate. On J721E if the streams are not reset before starting the
capture, the captured frame gets wrapped around vertically on every run
after the first.

Signed-off-by: Pratyush Yadav 
---
 drivers/media/platform/cadence/cdns-csi2rx.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/media/platform/cadence/cdns-csi2rx.c 
b/drivers/media/platform/cadence/cdns-csi2rx.c
index 31bd80e3f780..b03d2d2e6762 100644
--- a/drivers/media/platform/cadence/cdns-csi2rx.c
+++ b/drivers/media/platform/cadence/cdns-csi2rx.c
@@ -39,6 +39,7 @@
 #define CSI2RX_STREAM_BASE(n)  (((n) + 1) * 0x100)
 
 #define CSI2RX_STREAM_CTRL_REG(n)  (CSI2RX_STREAM_BASE(n) + 0x000)
+#define CSI2RX_STREAM_CTRL_SOFT_RSTBIT(4)
 #define CSI2RX_STREAM_CTRL_START   BIT(0)
 
 #define CSI2RX_STREAM_DATA_CFG_REG(n)  (CSI2RX_STREAM_BASE(n) + 0x008)
@@ -150,12 +151,22 @@ struct csi2rx_priv *v4l2_subdev_to_csi2rx(struct 
v4l2_subdev *subdev)
 
 static void csi2rx_reset(struct csi2rx_priv *csi2rx)
 {
+   int i;
+
writel(CSI2RX_SOFT_RESET_PROTOCOL | CSI2RX_SOFT_RESET_FRONT,
   csi2rx->base + CSI2RX_SOFT_RESET_REG);
 
udelay(10);
 
writel(0, csi2rx->base + CSI2RX_SOFT_RESET_REG);
+
+   /* Reset individual streams. */
+   for (i = 0; i < csi2rx->max_streams; i++) {
+   writel(CSI2RX_STREAM_CTRL_SOFT_RST,
+  csi2rx->base + CSI2RX_STREAM_CTRL_REG(i));
+   usleep_range(10, 20);
+   writel(0, csi2rx->base + CSI2RX_STREAM_CTRL_REG(i));
+   }
 }
 
 static int csi2rx_configure_external_dphy(struct csi2rx_priv *csi2rx)
-- 
2.30.0

[PATCH 04/16] phy: cdns-dphy: Add Rx support

[Pratyush Yadav]

The Cadence DPHY can be used to receive image data over the CSI-2
protocol. Add support for Rx mode. The programming sequence differs from
the Tx mode so it is added as a separate set of hooks to isolate the two
paths.

The PHY is in Tx mode by default and it needs to be set in Rx mode by
setting the submode to PHY_MIPI_DPHY_SUBMODE_RX in the set_mode()
callback.

Signed-off-by: Pratyush Yadav 
---
 drivers/phy/cadence/cdns-dphy.c | 237 
 1 file changed, 237 insertions(+)

diff --git a/drivers/phy/cadence/cdns-dphy.c b/drivers/phy/cadence/cdns-dphy.c
index 7d5f7b333893..7bbca679e2bb 100644
--- a/drivers/phy/cadence/cdns-dphy.c
+++ b/drivers/phy/cadence/cdns-dphy.c
@@ -1,11 +1,14 @@
 // SPDX-License-Identifier: GPL-2.0+
 /*
  * Copyright: 2017-2018 Cadence Design Systems, Inc.
+ * Copyright (C) 2021 Texas Instruments Incorporated - https://www.ti.com/
  */
 
 #include 
+#include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -25,10 +28,14 @@
 #define DPHY_PMA_RCLK(reg) (0x600 + (reg))
 #define DPHY_PMA_RDATA(lane, reg)  (0x700 + ((lane) * 0x100) + (reg))
 #define DPHY_PCS(reg)  (0xb00 + (reg))
+#define DPHY_ISO(reg)  (0xc00 + (reg))
 
 #define DPHY_CMN_SSM   DPHY_PMA_CMN(0x20)
 #define DPHY_CMN_SSM_ENBIT(0)
+#define DPHY_CMN_RX_BANDGAP_TIMER_MASK GENMASK(8, 1)
 #define DPHY_CMN_TX_MODE_ENBIT(9)
+#define DPHY_CMN_RX_MODE_ENBIT(10)
+#define DPHY_CMN_RX_BANDGAP_TIMER  0x14
 
 #define DPHY_CMN_PWM   DPHY_PMA_CMN(0x40)
 #define DPHY_CMN_PWM_DIV(x)((x) << 20)
@@ -45,10 +52,27 @@
 #define DPHY_CMN_OPDIV_FROM_REGBIT(6)
 #define DPHY_CMN_OPDIV(x)  ((x) << 7)
 
+#define DPHY_BAND_CFG  DPHY_PCS(0x0)
+#define DPHY_BAND_CFG_LEFT_BANDGENMASK(4, 0)
+#define DPHY_BAND_CFG_RIGHT_BAND   GENMASK(9, 5)
+
 #define DPHY_PSM_CFG   DPHY_PCS(0x4)
 #define DPHY_PSM_CFG_FROM_REG  BIT(0)
 #define DPHY_PSM_CLK_DIV(x)((x) << 1)
 
+#define DPHY_POWER_ISLAND_EN_DATA  DPHY_PCS(0x8)
+#define DPHY_POWER_ISLAND_EN_DATA_VAL  0x
+#define DPHY_POWER_ISLAND_EN_CLK   DPHY_PCS(0xc)
+#define DPHY_POWER_ISLAND_EN_CLK_VAL   0xaa
+
+#define DPHY_ISO_CL_CTRL_L DPHY_ISO(0x10)
+#define DPHY_ISO_DL_CTRL_L0DPHY_ISO(0x14)
+#define DPHY_ISO_DL_CTRL_L1DPHY_ISO(0x20)
+#define DPHY_ISO_DL_CTRL_L2DPHY_ISO(0x30)
+#define DPHY_ISO_DL_CTRL_L3DPHY_ISO(0x3c)
+#define DPHY_ISO_LANE_READY_BIT0
+#define DPHY_ISO_LANE_READY_TIMEOUT_MS 100UL
+
 #define DSI_HBP_FRAME_OVERHEAD 12
 #define DSI_HSA_FRAME_OVERHEAD 14
 #define DSI_HFP_FRAME_OVERHEAD 6
@@ -57,6 +81,9 @@
 #define DSI_NULL_FRAME_OVERHEAD6
 #define DSI_EOT_PKT_SIZE   4
 
+#define DPHY_LANES_MIN 1
+#define DPHY_LANES_MAX 4
+
 struct cdns_dphy_cfg {
u8 pll_ipdiv;
u8 pll_opdiv;
@@ -312,6 +339,214 @@ static const struct cdns_dphy_ops tx_ref_dphy_ops = {
.set_psm_div = cdns_dphy_ref_set_psm_div,
 };
 
+static int cdns_dphy_rx_power_on(struct cdns_dphy *dphy)
+{
+   /* Start RX state machine. */
+   writel(DPHY_CMN_SSM_EN | DPHY_CMN_RX_MODE_EN |
+  FIELD_PREP(DPHY_CMN_RX_BANDGAP_TIMER_MASK,
+ DPHY_CMN_RX_BANDGAP_TIMER),
+  dphy->regs + DPHY_CMN_SSM);
+
+   return 0;
+}
+
+static int cdns_dphy_rx_power_off(struct cdns_dphy *dphy)
+{
+   writel(0, dphy->regs + DPHY_CMN_SSM);
+
+   return 0;
+}
+
+static int cdns_dphy_rx_get_band_ctrl(unsigned long hs_clk_rate)
+{
+   unsigned int rate = hs_clk_rate / 100UL;
+
+   if (rate < 80 || rate >= 2500)
+   return -EOPNOTSUPP;
+
+   if (rate >= 80 && rate < 100)
+   return 0;
+
+   if (rate >= 100 && rate < 120)
+   return 1;
+
+   if (rate >= 120 && rate < 160)
+   return 2;
+
+   if (rate >= 160 && rate < 200)
+   return 3;
+
+   if (rate >= 200 && rate < 240)
+   return 4;
+
+   if (rate >= 240 && rate < 280)
+   return 5;
+
+   if (rate >= 280 && rate < 320)
+   return 6;
+
+   if (rate >= 320 && rate < 360)
+   return 7;
+
+   if (rate >= 360 && rate < 400)
+   return 8;
+
+   if (rate >= 400 && rate < 480)
+   return 9;
+
+   if (rate >= 480 && rate < 560)
+   return 10;
+
+   if (rate >= 560 && rate < 640)
+   return 11;
+
+   if (rate >= 640 && rate < 720)
+   return 12;
+
+   if (rate >= 720 && rate < 800)
+   return 13;
+
+   if (rate >= 800 && rate < 880)
+   return 14;
+
+   if (rate >= 880 && rate < 1040)
+   return 15;
+
+   if (rate 

[PATCH 00/16] CSI2RX support on J721E

[Pratyush Yadav]

Hi,

This series adds support for CSI2 capture on J721E. It includes some
fixes to the Cadence CSI2RX driver, adds Rx support to Cadence DPHY
driver, and finally adds the TI CSI2RX wrapper driver.

Tested on TI's J721E with OV5640 sensor.

Paul Kocialkowski (1):
  phy: Distinguish between Rx and Tx for MIPI D-PHY with submodes

Pratyush Yadav (15):
  phy: cdns-dphy: Prepare for Rx support
  phy: cdns-dphy: Allow setting mode
  phy: cdns-dphy: Add Rx support
  media: cadence: csi2rx: Add external DPHY support
  media: cadence: csi2rx: Soft reset the streams before starting capture
  media: cadence: csi2rx: Set the STOP bit when stopping a stream
  media: cadence: csi2rx: Fix stream data configuration
  media: cadence: csi2rx: Turn subdev power on before starting stream
  media: cadence: csi2rx: Add wrappers for subdev calls
  dmaengine: ti: k3-psil-j721e: Add entry for CSI2RX
  dt-bindings: media: Add DT bindings for TI CSI2RX driver
  media: ti-vpe: csi2rx: Add CSI2RX support
  dt-bindings: phy: Convert Cadence DPHY binding to YAML
  dt-bindings: phy: cdns,dphy: make clocks optional
  dt-bindings: phy: cdns,dphy: add power-domains property

 .../devicetree/bindings/media/ti,csi2rx.yaml  |  70 ++
 .../devicetree/bindings/phy/cdns,dphy.txt |  20 -
 .../devicetree/bindings/phy/cdns,dphy.yaml|  52 +
 MAINTAINERS   |   7 +
 drivers/dma/ti/k3-psil-j721e.c|  10 +
 drivers/media/platform/Kconfig|  11 +
 drivers/media/platform/cadence/cdns-csi2rx.c  | 269 -
 drivers/media/platform/ti-vpe/Makefile|   1 +
 drivers/media/platform/ti-vpe/ti-csi2rx.c | 964 ++
 drivers/phy/cadence/cdns-dphy.c   | 407 +++-
 include/linux/phy/phy-mipi-dphy.h |  13 +
 11 files changed, 1754 insertions(+), 70 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/media/ti,csi2rx.yaml
 delete mode 100644 Documentation/devicetree/bindings/phy/cdns,dphy.txt
 create mode 100644 Documentation/devicetree/bindings/phy/cdns,dphy.yaml
 create mode 100644 drivers/media/platform/ti-vpe/ti-csi2rx.c

--
2.30.0

[PATCH 03/16] phy: cdns-dphy: Allow setting mode

[Pratyush Yadav]

Allow callers to set the PHY mode. The main mode should always be
PHY_MODE_MIPI_DPHY but the submode can either be
PHY_MIPI_DPHY_SUBMODE_RX or PHY_MIPI_DPHY_SUBMODE_TX. Update the ops
based on the requested submode.

Signed-off-by: Pratyush Yadav 
---
 drivers/phy/cadence/cdns-dphy.c | 30 ++
 1 file changed, 30 insertions(+)

diff --git a/drivers/phy/cadence/cdns-dphy.c b/drivers/phy/cadence/cdns-dphy.c
index 8656f2102a91..7d5f7b333893 100644
--- a/drivers/phy/cadence/cdns-dphy.c
+++ b/drivers/phy/cadence/cdns-dphy.c
@@ -365,11 +365,41 @@ static int cdns_dphy_configure(struct phy *phy, union 
phy_configure_opts *opts)
return 0;
 }
 
+static int cdns_dphy_set_mode(struct phy *phy, enum phy_mode mode, int submode)
+{
+   struct cdns_dphy *dphy = phy_get_drvdata(phy);
+   const struct cdns_dphy_driver_data *ddata;
+
+   ddata = of_device_get_match_data(dphy->dev);
+   if (!ddata)
+   return -EINVAL;
+
+   if (mode != PHY_MODE_MIPI_DPHY)
+   return -EINVAL;
+
+   if (submode == PHY_MIPI_DPHY_SUBMODE_TX) {
+   if (!ddata->tx)
+   return -EOPNOTSUPP;
+
+   dphy->ops = ddata->tx;
+   } else if (submode == PHY_MIPI_DPHY_SUBMODE_RX) {
+   if (!ddata->rx)
+   return -EOPNOTSUPP;
+
+   dphy->ops = ddata->rx;
+   } else {
+   return -EOPNOTSUPP;
+   }
+
+   return 0;
+}
+
 static const struct phy_ops cdns_dphy_ops = {
.configure  = cdns_dphy_configure,
.validate   = cdns_dphy_validate,
.power_on   = cdns_dphy_power_on,
.power_off  = cdns_dphy_power_off,
+   .set_mode   = cdns_dphy_set_mode,
 };
 
 static int cdns_dphy_probe(struct platform_device *pdev)
-- 
2.30.0

Re: [PATCH v2] nvme-tcp: Check if request has started before processing it

[Sagi Grimberg]

It is, but in this situation, the controller is sending a second
completion that results in a use-after-free, which makes the
transport irrelevant. Unless there is some other flow (which is
unclear
to me) that causes this which is a bug that needs to be fixed rather
than hidden with a safeguard.



The kernel should not crash regardless of any network traffic that is
sent to the system.  It should not be possible to either intentionally
of mistakenly contruct packets that will deny service in this way.


This is not specific to nvme-tcp. I can build an rdma or pci controller
that can trigger the same crash... I saw a similar patch from Hannes
implemented in the scsi level, and not the individual scsi transports..

I would also mention, that a crash is not even the scariest issue that
we can see here, because if the request happened to be reused we are
in the silent data corruption realm...

[PATCH 02/16] phy: cdns-dphy: Prepare for Rx support

[Pratyush Yadav]

The Rx programming sequence differs from the Tx programming sequence.
Currently only Tx mode is supported. Move all the Tx related parts into
a set of Tx-specific hooks that are then called by the main PHY
framework hooks. This way when Rx support is added all that is needed to
be done is to plug in the Rx hooks.

The clocks "psm" and "pll_ref" are not used by the Rx path so make them
optional in the probe and then check if they exist in the power_on()
hook.

Signed-off-by: Pratyush Yadav 
---
 drivers/phy/cadence/cdns-dphy.c | 140 
 1 file changed, 104 insertions(+), 36 deletions(-)

diff --git a/drivers/phy/cadence/cdns-dphy.c b/drivers/phy/cadence/cdns-dphy.c
index ba042e39cfaf..8656f2102a91 100644
--- a/drivers/phy/cadence/cdns-dphy.c
+++ b/drivers/phy/cadence/cdns-dphy.c
@@ -75,6 +75,11 @@ struct cdns_dphy;
 struct cdns_dphy_ops {
int (*probe)(struct cdns_dphy *dphy);
void (*remove)(struct cdns_dphy *dphy);
+   int (*power_on)(struct cdns_dphy *dphy);
+   int (*power_off)(struct cdns_dphy *dphy);
+   int (*validate)(struct cdns_dphy *dphy, enum phy_mode mode, int submode,
+   union phy_configure_opts *opts);
+   int (*configure)(struct cdns_dphy *dphy, union phy_configure_opts 
*opts);
void (*set_psm_div)(struct cdns_dphy *dphy, u8 div);
void (*set_clk_lane_cfg)(struct cdns_dphy *dphy,
 enum cdns_dphy_clk_lane_cfg cfg);
@@ -86,12 +91,18 @@ struct cdns_dphy_ops {
 struct cdns_dphy {
struct cdns_dphy_cfg cfg;
void __iomem *regs;
+   struct device *dev;
struct clk *psm_clk;
struct clk *pll_ref_clk;
const struct cdns_dphy_ops *ops;
struct phy *phy;
 };
 
+struct cdns_dphy_driver_data {
+   const struct cdns_dphy_ops *tx;
+   const struct cdns_dphy_ops *rx;
+};
+
 static int cdns_dsi_get_dphy_pll_cfg(struct cdns_dphy *dphy,
 struct cdns_dphy_cfg *cfg,
 struct phy_configure_opts_mipi_dphy *opts,
@@ -199,20 +210,9 @@ static void cdns_dphy_ref_set_psm_div(struct cdns_dphy 
*dphy, u8 div)
   dphy->regs + DPHY_PSM_CFG);
 }
 
-/*
- * This is the reference implementation of DPHY hooks. Specific integration of
- * this IP may have to re-implement some of them depending on how they decided
- * to wire things in the SoC.
- */
-static const struct cdns_dphy_ops ref_dphy_ops = {
-   .get_wakeup_time_ns = cdns_dphy_ref_get_wakeup_time_ns,
-   .set_pll_cfg = cdns_dphy_ref_set_pll_cfg,
-   .set_psm_div = cdns_dphy_ref_set_psm_div,
-};
-
-static int cdns_dphy_config_from_opts(struct phy *phy,
- struct phy_configure_opts_mipi_dphy *opts,
- struct cdns_dphy_cfg *cfg)
+static int cdns_dphy_tx_config_from_opts(struct phy *phy,
+struct phy_configure_opts_mipi_dphy 
*opts,
+struct cdns_dphy_cfg *cfg)
 {
struct cdns_dphy *dphy = phy_get_drvdata(phy);
unsigned int dsi_hfp_ext = 0;
@@ -232,24 +232,13 @@ static int cdns_dphy_config_from_opts(struct phy *phy,
return 0;
 }
 
-static int cdns_dphy_validate(struct phy *phy, enum phy_mode mode, int submode,
- union phy_configure_opts *opts)
+static int cdns_dphy_tx_configure(struct cdns_dphy *dphy,
+ union phy_configure_opts *opts)
 {
struct cdns_dphy_cfg cfg = { 0 };
-
-   if (mode != PHY_MODE_MIPI_DPHY)
-   return -EINVAL;
-
-   return cdns_dphy_config_from_opts(phy, >mipi_dphy, );
-}
-
-static int cdns_dphy_configure(struct phy *phy, union phy_configure_opts *opts)
-{
-   struct cdns_dphy *dphy = phy_get_drvdata(phy);
-   struct cdns_dphy_cfg cfg = { 0 };
int ret;
 
-   ret = cdns_dphy_config_from_opts(phy, >mipi_dphy, );
+   ret = cdns_dphy_tx_config_from_opts(dphy->phy, >mipi_dphy, );
if (ret)
return ret;
 
@@ -279,9 +268,21 @@ static int cdns_dphy_configure(struct phy *phy, union 
phy_configure_opts *opts)
return 0;
 }
 
-static int cdns_dphy_power_on(struct phy *phy)
+static int cdns_dphy_tx_validate(struct cdns_dphy *dphy, enum phy_mode mode,
+int submode, union phy_configure_opts *opts)
 {
-   struct cdns_dphy *dphy = phy_get_drvdata(phy);
+   struct cdns_dphy_cfg cfg = { 0 };
+
+   if (submode != PHY_MIPI_DPHY_SUBMODE_TX)
+   return -EINVAL;
+
+   return cdns_dphy_tx_config_from_opts(dphy->phy, >mipi_dphy, );
+}
+
+static int cdns_dphy_tx_power_on(struct cdns_dphy *dphy)
+{
+   if (!dphy->psm_clk || !dphy->pll_ref_clk)
+   return -EINVAL;
 
clk_prepare_enable(dphy->psm_clk);
clk_prepare_enable(dphy->pll_ref_clk);
@@ -293,16 +294,77 @@ static int cdns_dphy_power_on(struct phy *phy)

[PATCH 01/16] phy: Distinguish between Rx and Tx for MIPI D-PHY with submodes

[Pratyush Yadav]

From: Paul Kocialkowski 

As some D-PHY controllers support both Rx and Tx mode, we need a way for
users to explicitly request one or the other. For instance, Rx mode can
be used along with MIPI CSI-2 while Tx mode can be used with MIPI DSI.

Introduce new MIPI D-PHY PHY submodes to use with PHY_MODE_MIPI_DPHY.
The default (zero value) is kept to Tx so only the rkisp1 driver, which
uses D-PHY in Rx mode, needs to be adapted.

Signed-off-by: Paul Kocialkowski 
Signed-off-by: Pratyush Yadav 
---
 include/linux/phy/phy-mipi-dphy.h | 13 +
 1 file changed, 13 insertions(+)

diff --git a/include/linux/phy/phy-mipi-dphy.h 
b/include/linux/phy/phy-mipi-dphy.h
index a877ffee845d..0f57ef46a8b5 100644
--- a/include/linux/phy/phy-mipi-dphy.h
+++ b/include/linux/phy/phy-mipi-dphy.h
@@ -6,6 +6,19 @@
 #ifndef __PHY_MIPI_DPHY_H_
 #define __PHY_MIPI_DPHY_H_
 
+/**
+ * enum phy_mipi_dphy_submode - MIPI D-PHY sub-mode
+ *
+ * A MIPI D-PHY can be used to transmit or receive data.
+ * Since some controllers can support both, the direction to enable is 
specified
+ * with the PHY sub-mode. Transmit is assumed by default with phy_set_mode.
+ */
+
+enum phy_mipi_dphy_submode {
+   PHY_MIPI_DPHY_SUBMODE_TX = 0,
+   PHY_MIPI_DPHY_SUBMODE_RX,
+};
+
 /**
  * struct phy_configure_opts_mipi_dphy - MIPI D-PHY configuration set
  *
-- 
2.30.0

Re: [PATCH v3 3/4] kernel/smp: add more data to CSD lock debugging

[Paul E. McKenney]

On Wed, Mar 24, 2021 at 11:18:03AM +0100, Jürgen Groß wrote:
> On 02.03.21 07:28, Juergen Gross wrote:
> > In order to help identifying problems with IPI handling and remote
> > function execution add some more data to IPI debugging code.
> > 
> > There have been multiple reports of cpus looping long times (many
> > seconds) in smp_call_function_many() waiting for another cpu executing
> > a function like tlb flushing. Most of these reports have been for
> > cases where the kernel was running as a guest on top of KVM or Xen
> > (there are rumours of that happening under VMWare, too, and even on
> > bare metal).
> > 
> > Finding the root cause hasn't been successful yet, even after more than
> > 2 years of chasing this bug by different developers.
> > 
> > Commit 35feb60474bf4f7 ("kernel/smp: Provide CSD lock timeout
> > diagnostics") tried to address this by adding some debug code and by
> > issuing another IPI when a hang was detected. This helped mitigating
> > the problem (the repeated IPI unlocks the hang), but the root cause is
> > still unknown.
> > 
> > Current available data suggests that either an IPI wasn't sent when it
> > should have been, or that the IPI didn't result in the target cpu
> > executing the queued function (due to the IPI not reaching the cpu,
> > the IPI handler not being called, or the handler not seeing the queued
> > request).
> > 
> > Try to add more diagnostic data by introducing a global atomic counter
> > which is being incremented when doing critical operations (before and
> > after queueing a new request, when sending an IPI, and when dequeueing
> > a request). The counter value is stored in percpu variables which can
> > be printed out when a hang is detected.
> > 
> > The data of the last event (consisting of sequence counter, source
> > cpu, target cpu, and event type) is stored in a global variable. When
> > a new event is to be traced, the data of the last event is stored in
> > the event related percpu location and the global data is updated with
> > the new event's data. This allows to track two events in one data
> > location: one by the value of the event data (the event before the
> > current one), and one by the location itself (the current event).
> > 
> > A typical printout with a detected hang will look like this:
> > 
> > csd: Detected non-responsive CSD lock (#1) on CPU#1, waiting 53 ns 
> > for CPU#06 scf_handler_1+0x0/0x50(0xa2a881bb1410).
> > csd: CSD lock (#1) handling prior 
> > scf_handler_1+0x0/0x50(0xa2a8813823c0) request.
> >  csd: cnt(8cc): -> dequeue (src cpu 0 == empty)
> >  csd: cnt(8cd): ->0006 idle
> >  csd: cnt(0003668): 0001->0006 queue
> >  csd: cnt(0003669): 0001->0006 ipi
> >  csd: cnt(0003e0f): 0007->000a queue
> >  csd: cnt(0003e10): 0001-> ping
> >  csd: cnt(0003e71): 0003-> ping
> >  csd: cnt(0003e72): ->0006 gotipi
> >  csd: cnt(0003e73): ->0006 handle
> >  csd: cnt(0003e74): ->0006 dequeue (src cpu 0 == empty)
> >  csd: cnt(0003e7f): 0004->0006 ping
> >  csd: cnt(0003e80): 0001-> pinged
> >  csd: cnt(0003eb2): 0005->0001 noipi
> >  csd: cnt(0003eb3): 0001->0006 queue
> >  csd: cnt(0003eb4): 0001->0006 noipi
> >  csd: cnt now: 0003f00
> > 
> > This example (being an artificial one, produced with a previous version
> > of this patch without the "hdlend" event), shows that cpu#6 started to
> > handle an IPI (cnt 3e72-3e74), bit didn't start to handle another IPI
> > (sent by cpu#4, cnt 3e7f). The next request from cpu#1 for cpu#6 was
> > queued (3eb3), but no IPI was needed (cnt 3eb4, there was the event
> > from cpu#4 in the queue already).
> > 
> > The idea is to print only relevant entries. Those are all events which
> > are associated with the hang (so sender side events for the source cpu
> > of the hanging request, and receiver side events for the target cpu),
> > and the related events just before those (for adding data needed to
> > identify a possible race). Printing all available data would be
> > possible, but this would add large amounts of data printed on larger
> > configurations.
> > 
> > Signed-off-by: Juergen Gross 
> > Tested-by: Paul E. McKenney 
> 
> Just an update regarding current status with debugging the underlying
> issue:
> 
> On a customer's machine with a backport of this patch applied we've
> seen another case of the hang. In the logs we've found:
> 
> smp: csd: Detected non-responsive CSD lock (#1) on CPU#18, waiting
> 500046 ns for CPU#06 do_flush_tlb_all+0x0/0x30(  (null)).
> smp:  csd: CSD lock (#1) unresponsive.
> smp:  csd: cnt(000): -> queue
> smp:  csd: cnt(001): ->0006 idle
> smp:  csd: cnt(0025dba): 0012->0006 queue
> smp:  csd: cnt(0025dbb): 0012->0006 noipi
> smp:  csd: cnt(01d1333): 001a->0006 pinged
> smp:  csd: cnt(01d1334): ->0006 gotipi
> smp:  csd: cnt(01d1335): 

Re: [PATCH v2 3/7] powerpc: convert config files to generic cmdline

[Daniel Walker]

On Thu, Mar 25, 2021 at 05:29:44PM -0600, Rob Herring wrote:
> On Thu, Mar 25, 2021 at 2:00 PM Daniel Walker  wrote:
> >
> > On Thu, Mar 25, 2021 at 01:03:55PM +0100, Christophe Leroy wrote:
> > >
> > > Ok, so you agree we don't need to provide two CMDLINE, one to be appended 
> > > and one to be prepended.
> > >
> > > Let's only provide once CMDLINE as of today, and ask the user to select
> > > whether he wants it appended or prepended or replacee. Then no need to
> > > change all existing config to rename CONFIG_CMDLINE into either of the new
> > > ones.
> > >
> > > That's the main difference between my series and Daniel's series. So I'll
> > > finish taking Will's comment into account and we'll send out a v3 soon.
> >
> > It doesn't solve the needs of Cisco, I've stated many times your changes 
> > have
> > little value. Please stop submitting them.
> 
> Can you please outline what those needs are which aren't met?

append AND prepend at the same time on all architectures. Christophe doesn't
understand the need, and hence tries to minimize the feature set which is
incompatible with Cisco needs and all the other out of tree users.

Daniel

Re: [PATCH v2 2/4] cxl/mem: Fix synchronization mechanism for device removal vs ioctl operations

[Dan Williams]

On Tue, Mar 30, 2021 at 10:03 AM Jason Gunthorpe  wrote:
>
> On Tue, Mar 30, 2021 at 09:05:29AM -0700, Dan Williams wrote:
>
> > > If you can't clearly point to the *data* under RCU protection it is
> > > being used wrong.
> >
> > Agree.
> >
> > The data being protected is the value of
> > dev->kobj.state_in_sysfs. The
>
> So where is that read under:
>
> +   idx = srcu_read_lock(_memdev_srcu);
> +   rc = __cxl_memdev_ioctl(cxlmd, cmd, arg);
> +   srcu_read_unlock(_memdev_srcu, idx);
>
> ?

device_is_registered() inside __cxl_memdev_ioctl().

> It can't read the RCU protected data outside the RCU critical region,
> and it can't read/write RCU protected data without using the helper
> macros which insert the required barriers.

The required barriers are there. srcu_read_lock() +
device_is_registered() is paired with cdev_device_del() +
synchronize_rcu().

> IMHO this can't use 'dev->kobj.state_in_sysfs' as the RCU protected data.

This usage of srcu is functionally equivalent to replacing
srcu_read_lock() with down_read() and the shutdown path with:

cdev_device_del(...);
down_write(...):
up_write(...);

...to flush readers that read ->state_in_sysfs == 1.

Re: [PATCH 14/30] Revert "s3c24xx-dma.c: Fix a typo"

[Vinod Koul]

On 29-03-21, 05:23, Bhaskar Chowdhury wrote:
> s/transferred/transfered/
> 
> This reverts commit a2ddb8aea8106bd5552f8516ad7a8a26b9282a8f.

This is not upstream, why not squash in. Also would make sense to write
sensible changelog and not phrases and use the right subsystem
conventions!

Droped the series now


-- 
~Vinod

[GIT PULL] s390 updates for 5.12-rc6

[Heiko Carstens]

Hi Linus,

please pull a couple of small updates for s390.

Thanks,
Heiko

The following changes since commit 0d02ec6b3136c73c09e7859f0d0e4e2c4c07b49b:

  Linux 5.12-rc4 (2021-03-21 14:56:43 -0700)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git tags/s390-5.12-5

for you to fetch changes up to 84d572e634e28827d105746c922d8ada425e2d8b:

  MAINTAINERS: add backups for s390 vfio drivers (2021-03-28 20:20:33 +0200)


s390 updates for 5.12-rc6

- fix incorrect initialization and update of vdso data pages, which
  results in incorrect tod clock steering, and that
  clock_gettime(CLOCK_MONOTONIC_RAW, ...) returns incorrect values.

- update MAINTAINERS for s390 vfio drivers


Heiko Carstens (3):
  s390/vdso: copy tod_steering_delta value to vdso_data page
  s390/vdso: fix tod_steering_delta type
  s390/vdso: fix initializing and updating of vdso_data

Matthew Rosato (1):
  MAINTAINERS: add backups for s390 vfio drivers

 MAINTAINERS   |  4 +++-
 arch/s390/include/asm/vdso/data.h |  2 +-
 arch/s390/kernel/time.c   | 10 --
 3 files changed, 12 insertions(+), 4 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 9e876927c60d..68a562374b85 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -15634,8 +15634,8 @@ F:  Documentation/s390/pci.rst
 
 S390 VFIO AP DRIVER
 M: Tony Krowiak 
-M: Pierre Morel 
 M: Halil Pasic 
+M: Jason Herne 
 L: linux-s...@vger.kernel.org
 S: Supported
 W: http://www.ibm.com/developerworks/linux/linux390/
@@ -15647,6 +15647,7 @@ F:  drivers/s390/crypto/vfio_ap_private.h
 S390 VFIO-CCW DRIVER
 M: Cornelia Huck 
 M: Eric Farman 
+M: Matthew Rosato 
 R: Halil Pasic 
 L: linux-s...@vger.kernel.org
 L: k...@vger.kernel.org
@@ -15657,6 +15658,7 @@ F:  include/uapi/linux/vfio_ccw.h
 
 S390 VFIO-PCI DRIVER
 M: Matthew Rosato 
+M: Eric Farman 
 L: linux-s...@vger.kernel.org
 L: k...@vger.kernel.org
 S: Supported
diff --git a/arch/s390/include/asm/vdso/data.h 
b/arch/s390/include/asm/vdso/data.h
index 7b3cdb4a5f48..73ee89142666 100644
--- a/arch/s390/include/asm/vdso/data.h
+++ b/arch/s390/include/asm/vdso/data.h
@@ -6,7 +6,7 @@
 #include 
 
 struct arch_vdso_data {
-   __u64 tod_steering_delta;
+   __s64 tod_steering_delta;
__u64 tod_steering_end;
 };
 
diff --git a/arch/s390/kernel/time.c b/arch/s390/kernel/time.c
index 165da961f901..326cb8f75f58 100644
--- a/arch/s390/kernel/time.c
+++ b/arch/s390/kernel/time.c
@@ -80,10 +80,12 @@ void __init time_early_init(void)
 {
struct ptff_qto qto;
struct ptff_qui qui;
+   int cs;
 
/* Initialize TOD steering parameters */
tod_steering_end = tod_clock_base.tod;
-   vdso_data->arch_data.tod_steering_end = tod_steering_end;
+   for (cs = 0; cs < CS_BASES; cs++)
+   vdso_data[cs].arch_data.tod_steering_end = tod_steering_end;
 
if (!test_facility(28))
return;
@@ -366,6 +368,7 @@ static void clock_sync_global(unsigned long delta)
 {
unsigned long now, adj;
struct ptff_qto qto;
+   int cs;
 
/* Fixup the monotonic sched clock. */
tod_clock_base.eitod += delta;
@@ -381,7 +384,10 @@ static void clock_sync_global(unsigned long delta)
panic("TOD clock sync offset %li is too large to drift\n",
  tod_steering_delta);
tod_steering_end = now + (abs(tod_steering_delta) << 15);
-   vdso_data->arch_data.tod_steering_end = tod_steering_end;
+   for (cs = 0; cs < CS_BASES; cs++) {
+   vdso_data[cs].arch_data.tod_steering_end = tod_steering_end;
+   vdso_data[cs].arch_data.tod_steering_delta = tod_steering_delta;
+   }
 
/* Update LPAR offset. */
if (ptff_query(PTFF_QTO) && ptff(, sizeof(qto), PTFF_QTO) == 0)

Re: [RESEND PATCH 3/5] clk: at91: sama7g5: add securam's peripheral clock

[Nicolas Ferre]

On 24/03/2021 at 10:43, Claudiu Beznea wrote:

Add SECURAM's peripheral clock.

Signed-off-by: Claudiu Beznea 


Acked-by: Nicolas Ferre 


---
  drivers/clk/at91/sama7g5.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/drivers/clk/at91/sama7g5.c b/drivers/clk/at91/sama7g5.c
index a6e20b35960e..28e26fb90417 100644
--- a/drivers/clk/at91/sama7g5.c
+++ b/drivers/clk/at91/sama7g5.c
@@ -377,6 +377,7 @@ static const struct {
u8 id;
  } sama7g5_periphck[] = {
{ .n = "pioA_clk",.p = "mck0", .id = 11, },
+   { .n = "securam_clk", .p = "mck0", .id = 18, },
{ .n = "sfr_clk", .p = "mck1", .id = 19, },
{ .n = "hsmc_clk",.p = "mck1", .id = 21, },
{ .n = "xdmac0_clk",  .p = "mck1", .id = 22, },



Thanks,
  Nicolas

--
Nicolas Ferre

Re: [PATCH v3 01/17] cmdline: Add generic function to build command line.

[Daniel Walker]

On Fri, Mar 26, 2021 at 01:44:48PM +, Christophe Leroy wrote:
> This code provides architectures with a way to build command line
> based on what is built in the kernel and what is handed over by the
> bootloader, based on selected compile-time options.
> 
> Signed-off-by: Christophe Leroy 
> ---
> v3:
> - Addressed comments from Will
> - Added capability to have src == dst
> ---
>  include/linux/cmdline.h | 57 +
>  1 file changed, 57 insertions(+)
>  create mode 100644 include/linux/cmdline.h
> 
> diff --git a/include/linux/cmdline.h b/include/linux/cmdline.h
> new file mode 100644
> index ..dea87edd41be
> --- /dev/null
> +++ b/include/linux/cmdline.h
> @@ -0,0 +1,57 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#ifndef _LINUX_CMDLINE_H
> +#define _LINUX_CMDLINE_H
> +
> +#include 
> +
> +/* Allow architectures to override strlcat, powerpc can't use strings so 
> early */
> +#ifndef cmdline_strlcat
> +#define cmdline_strlcat strlcat
> +#endif
> +
> +/*
> + * This function will append or prepend a builtin command line to the command
> + * line provided by the bootloader. Kconfig options can be used to alter
> + * the behavior of this builtin command line.
> + * @dst: The destination of the final appended/prepended string.
> + * @src: The starting string or NULL if there isn't one.
> + * @len: the length of dest buffer.
> + */

Append or prepend ? Cisco requires both at the same time. This is why my
implementation provides both. I can't use this with both at once.

Daniel

[PATCH 3/3] MIPS: Remove get_fs/set_fs

[Thomas Bogendoerfer]

All get_fs/set_fs calls in MIPS code are gone, so remove implementation
of it.  With the clear separation of user/kernel space access we no
longer need the EVA special handling, so get rid of that, too.

Signed-off-by: Thomas Bogendoerfer 
---
 arch/mips/Kconfig   |   1 -
 arch/mips/include/asm/processor.h   |   4 -
 arch/mips/include/asm/thread_info.h |   6 -
 arch/mips/include/asm/uaccess.h | 197 +++-
 arch/mips/kernel/asm-offsets.c  |   1 -
 arch/mips/kernel/process.c  |   2 -
 arch/mips/kernel/scall32-o32.S  |   4 +-
 arch/mips/lib/memset.S  |   3 -
 arch/mips/lib/strncpy_user.S|  48 ++-
 arch/mips/lib/strnlen_user.S|  44 ++-
 10 files changed, 75 insertions(+), 235 deletions(-)

diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index b72458215d20..70faa0686444 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -93,7 +93,6 @@ config MIPS
select PERF_USE_VMALLOC
select PCI_MSI_ARCH_FALLBACKS if PCI_MSI
select RTC_LIB
-   select SET_FS
select SYSCTL_EXCEPTION_TRACE
select VIRT_TO_BUS
select ARCH_HAS_ELFCORE_COMPAT
diff --git a/arch/mips/include/asm/processor.h 
b/arch/mips/include/asm/processor.h
index 8e69e0a35ee9..0c3550c82b72 100644
--- a/arch/mips/include/asm/processor.h
+++ b/arch/mips/include/asm/processor.h
@@ -221,10 +221,6 @@ struct nlm_cop2_state {
 #define COP2_INIT
 #endif
 
-typedef struct {
-   unsigned long seg;
-} mm_segment_t;
-
 #ifdef CONFIG_CPU_HAS_MSA
 # define ARCH_MIN_TASKALIGN16
 # define FPU_ALIGN __aligned(16)
diff --git a/arch/mips/include/asm/thread_info.h 
b/arch/mips/include/asm/thread_info.h
index e2c352da3877..0b17aaa9e012 100644
--- a/arch/mips/include/asm/thread_info.h
+++ b/arch/mips/include/asm/thread_info.h
@@ -28,11 +28,6 @@ struct thread_info {
unsigned long   tp_value;   /* thread pointer */
__u32   cpu;/* current CPU */
int preempt_count;  /* 0 => preemptable, <0 => BUG 
*/
-   mm_segment_taddr_limit; /*
-* thread address space limit:
-* 0x7fff for user-thead
-* 0x for kernel-thread
-*/
struct pt_regs  *regs;
longsyscall;/* syscall number */
 };
@@ -46,7 +41,6 @@ struct thread_info {
.flags  = _TIF_FIXADE,  \
.cpu= 0,\
.preempt_count  = INIT_PREEMPT_COUNT,   \
-   .addr_limit = KERNEL_DS,\
 }
 
 /*
diff --git a/arch/mips/include/asm/uaccess.h b/arch/mips/include/asm/uaccess.h
index 8b3a4b992ebc..5b1fd2e97f57 100644
--- a/arch/mips/include/asm/uaccess.h
+++ b/arch/mips/include/asm/uaccess.h
@@ -16,13 +16,6 @@
 #include 
 #include 
 
-/*
- * The fs value determines whether argument validity checking should be
- * performed or not.  If get_fs() == USER_DS, checking is performed, with
- * get_fs() == KERNEL_DS, checking is bypassed.
- *
- * For historical reasons, these macros are grossly misnamed.
- */
 #ifdef CONFIG_32BIT
 
 #define __UA_LIMIT 0x8000UL
@@ -49,38 +42,6 @@ extern u64 __ua_limit;
 
 #endif /* CONFIG_64BIT */
 
-/*
- * USER_DS is a bitmask that has the bits set that may not be set in a valid
- * userspace address.  Note that we limit 32-bit userspace to 0x7fff8000 but
- * the arithmetic we're doing only works if the limit is a power of two, so
- * we use 0x8000 here on 32-bit kernels.  If a process passes an invalid
- * address in this range it's the process's problem, not ours :-)
- */
-
-#define KERNEL_DS  ((mm_segment_t) { 0UL })
-#define USER_DS((mm_segment_t) { __UA_LIMIT })
-
-#define get_fs()   (current_thread_info()->addr_limit)
-#define set_fs(x)  (current_thread_info()->addr_limit = (x))
-
-#define uaccess_kernel()   (get_fs().seg == KERNEL_DS.seg)
-
-/*
- * eva_kernel_access() - determine whether kernel memory access on an EVA 
system
- *
- * Determines whether memory accesses should be performed to kernel memory
- * on a system using Extended Virtual Addressing (EVA).
- *
- * Return: true if a kernel memory access on an EVA system, else false.
- */
-static inline bool eva_kernel_access(void)
-{
-   if (!IS_ENABLED(CONFIG_EVA))
-   return false;
-
-   return uaccess_kernel();
-}
-
 /*
  * Is a address valid? This does a straightforward calculation rather
  * than tests.
@@ -118,7 +79,7 @@ static inline bool eva_kernel_access(void)
 static inline int __access_ok(const void __user *p, unsigned long size)
 {
unsigned long addr = (unsigned long)p;
-   return (get_fs().seg & (addr | (addr + size) | __ua_size(size))) == 0;
+   return (__UA_LIMIT & (addr | 

[PATCH 2/3] MIPS: uaccess: Remove get_fs/set_fs call sites

[Thomas Bogendoerfer]

Use new __get_data macro to access user/kernel for functions, which
are used with user/kernel pointers. Instead of dealing with get_fs/set_fs
this macro uses a parameter to select user/kernel access.

Signed-off-by: Thomas Bogendoerfer 
---
 arch/mips/include/asm/uaccess.h |  23 
 arch/mips/kernel/traps.c|  72 
 arch/mips/kernel/unaligned.c| 197 
 3 files changed, 116 insertions(+), 176 deletions(-)

diff --git a/arch/mips/include/asm/uaccess.h b/arch/mips/include/asm/uaccess.h
index c5cab0b8f902..8b3a4b992ebc 100644
--- a/arch/mips/include/asm/uaccess.h
+++ b/arch/mips/include/asm/uaccess.h
@@ -355,6 +355,29 @@ do {   
\
(val) = __gu_tmp.t; \
 }
 
+#define __get_udata(x, ptr, size)  \
+({ \
+   int __gu_err;   \
+   \
+   __chk_user_ptr(ptr);\
+   __get_user_common((x), size, ptr);  \
+   \
+   __gu_err;   \
+})
+
+#define __get_kdata(x, ptr, size)  \
+({ \
+   int __gu_err;   \
+   \
+   __get_kernel_common((x), size, ptr);\
+   \
+   __gu_err;   \
+})
+
+#define __get_data(x, ptr, u)  \
+   (((u) == true) ? __get_udata((x), (ptr), sizeof(*(ptr))) :  \
+   __get_kdata((x), (ptr), sizeof(*(ptr
+
 #define HAVE_GET_KERNEL_NOFAULT
 
 #define __get_kernel_nofault(dst, src, type, err_label)
\
diff --git a/arch/mips/kernel/traps.c b/arch/mips/kernel/traps.c
index 808b8b61ded1..6561c0c7841d 100644
--- a/arch/mips/kernel/traps.c
+++ b/arch/mips/kernel/traps.c
@@ -108,7 +108,8 @@ void (*board_bind_eic_interrupt)(int irq, int regset);
 void (*board_ebase_setup)(void);
 void(*board_cache_error_setup)(void);
 
-static void show_raw_backtrace(unsigned long reg29, const char *loglvl)
+static void show_raw_backtrace(unsigned long reg29, const char *loglvl,
+  bool user)
 {
unsigned long *sp = (unsigned long *)(reg29 & ~3);
unsigned long addr;
@@ -120,7 +121,7 @@ static void show_raw_backtrace(unsigned long reg29, const 
char *loglvl)
while (!kstack_end(sp)) {
unsigned long __user *p =
(unsigned long __user *)(unsigned long)sp++;
-   if (__get_user(addr, p)) {
+   if (__get_data(addr, p, user)) {
printk("%s (Bad stack address)", loglvl);
break;
}
@@ -141,7 +142,7 @@ __setup("raw_show_trace", set_raw_show_trace);
 #endif
 
 static void show_backtrace(struct task_struct *task, const struct pt_regs 
*regs,
-  const char *loglvl)
+  const char *loglvl, bool user)
 {
unsigned long sp = regs->regs[29];
unsigned long ra = regs->regs[31];
@@ -151,7 +152,7 @@ static void show_backtrace(struct task_struct *task, const 
struct pt_regs *regs,
task = current;
 
if (raw_show_trace || user_mode(regs) || !__kernel_text_address(pc)) {
-   show_raw_backtrace(sp, loglvl);
+   show_raw_backtrace(sp, loglvl, user);
return;
}
printk("%sCall Trace:\n", loglvl);
@@ -167,7 +168,7 @@ static void show_backtrace(struct task_struct *task, const 
struct pt_regs *regs,
  * with at least a bit of error checking ...
  */
 static void show_stacktrace(struct task_struct *task,
-   const struct pt_regs *regs, const char *loglvl)
+   const struct pt_regs *regs, const char *loglvl, bool user)
 {
const int field = 2 * sizeof(unsigned long);
long stackdata;
@@ -186,7 +187,7 @@ static void show_stacktrace(struct task_struct *task,
break;
}
 
-   if (__get_user(stackdata, sp++)) {
+   if (__get_data(stackdata, sp++, user)) {
pr_cont(" (Bad stack address)");
break;
}
@@ -195,13 +196,12 @@ static void show_stacktrace(struct task_struct *task,
i++;
}
pr_cont("\n");
-   show_backtrace(task, regs, 

[PATCH 1/3] MIPS: uaccess: Added __get/__put_kernel_nofault

[Thomas Bogendoerfer]

Added __get/__put_kernel_nofault as preparation for removing
get/set_fs.

Signed-off-by: Thomas Bogendoerfer 
---
 arch/mips/include/asm/uaccess.h | 24 
 1 file changed, 24 insertions(+)

diff --git a/arch/mips/include/asm/uaccess.h b/arch/mips/include/asm/uaccess.h
index d273a3857809..c5cab0b8f902 100644
--- a/arch/mips/include/asm/uaccess.h
+++ b/arch/mips/include/asm/uaccess.h
@@ -355,6 +355,18 @@ do {   
\
(val) = __gu_tmp.t; \
 }
 
+#define HAVE_GET_KERNEL_NOFAULT
+
+#define __get_kernel_nofault(dst, src, type, err_label)
\
+do {   \
+   int __gu_err;   \
+   \
+   __get_kernel_common(*((type *)(dst)), sizeof(type), \
+   (__force type *)(src)); \
+   if (unlikely(__gu_err)) \
+   goto err_label; \
+} while (0)
+
 #ifndef CONFIG_EVA
 #define __put_kernel_common(ptr, size) __put_user_common(ptr, size)
 #else
@@ -483,6 +495,18 @@ do {   
\
 
 extern void __put_user_unknown(void);
 
+#define __put_kernel_nofault(dst, src, type, err_label)
\
+do {   \
+   type __pu_val;  \
+   int __pu_err = 0;   \
+   \
+   __pu_val = *(__force type *)(src);  \
+   __put_kernel_common(((type *)(dst)), sizeof(type)); \
+   if (unlikely(__pu_err)) \
+   goto err_label; \
+} while (0)
+
+
 /*
  * We're generating jump to subroutines which will be outside the range of
  * jump instructions
-- 
2.29.2

[PATCH 0/3] MIPS: Remove get_fs/set_fs

[Thomas Bogendoerfer]

This series replaces get_fs/set_fs and removes it from MIPS arch code.

Thomas Bogendoerfer (3):
  MIPS: uaccess: Added __get/__put_kernel_nofault
  MIPS: uaccess: Remove get_fs/set_fs call sites
  MIPS: Remove get_fs/set_fs

 arch/mips/Kconfig   |   1 -
 arch/mips/include/asm/processor.h   |   4 -
 arch/mips/include/asm/thread_info.h |   6 -
 arch/mips/include/asm/uaccess.h | 244 +++-
 arch/mips/kernel/asm-offsets.c  |   1 -
 arch/mips/kernel/process.c  |   2 -
 arch/mips/kernel/scall32-o32.S  |   4 +-
 arch/mips/kernel/traps.c|  72 +++-
 arch/mips/kernel/unaligned.c| 197 --
 arch/mips/lib/memset.S  |   3 -
 arch/mips/lib/strncpy_user.S|  48 ++
 arch/mips/lib/strnlen_user.S|  44 ++---
 12 files changed, 215 insertions(+), 411 deletions(-)

-- 
2.29.2

Re: [PATCH v6 0/9] soundwire: qcom: various improvements

[Vinod Koul]

On 30-03-21, 15:47, Srinivas Kandagatla wrote:
> Thanks for reviewing v5 of this patchset!
> 
> During testing SoundWire controller on SM8250 MTP, we found
> few issues like all the interrupts are not handled,
> all transport parameters are not read from device tree.
> Patch to add Auto Enumeration supported by the controller
> is also part of this series.
> 
> Other major issue was register read/writes which was interrupt based
> was an overhead and puts lot of limitation on context it can be used from.
> 
> With previous approach number of interrupts generated
> after enumeration are around 130:
> $ cat /proc/interrupts  | grep soundwire
> 21: 130 0 0 0 0 0 0 0 GICv3 234 Edge  soundwire
> 
> after this patch they are just 3 interrupts
> $ cat /proc/interrupts  | grep soundwire
> 21: 3 0 0 0 0 0 0 0 GICv3 234 Edge  soundwire
> 
> So this patchset add various improvements to the existing driver
> to address above issues.
> 
> Tested it on SM8250 MTP with 2x WSA881x speakers, HeadPhones on
> WCD938x via lpass-rx-macro and Analog MICs via lpass-tx-macro.
> Also tested on DragonBoard DB845c with 2xWSA881x speakers.

Applied, thanks

-- 
~Vinod

Re: WARNING: at fs/proc/generic.c:717 remove_proc_entry

[Naresh Kamboju]

Small correction,
As per available test data the good tag is next-20210326.
GOOD: next-20210326
BAD: next-20210330

On Tue, 30 Mar 2021 at 22:19, Naresh Kamboju  wrote:
>
> While running kselftest gpio on x86_64 and i386 the following warnings were
> noticed and the device did not recover.
>

GOOD: next-20210326

> BAD: next-20210330
>
> steps to reproduce:
> ---
> # Boot linux next tag 20210330 on x86_64 machine
> # cd /opt/kselftests/default-in-kernel/
> # ./gpio-mockup.sh --> which is doing modprobe gpio-mockup
>
> Test log:
> 
> # selftests: gpio: gpio-mockup.sh
> # 1.  Module load tests
> # 1.1.  dynamic allocation of gpio
> # ./gpio-mockup.sh: line 106: ./gpio-mockup-cdev: No such file or directory
> # test failed: line value is 127 when 1 was[   46.136044]
> [ cut here ]
> [   46.141916] remove_proc_entry: removing non-empty directory
> 'irq/3', leaking at least 'ttyS1'
>  expected
> # GPI[   46.150471] WARNING: CPU: 2 PID: 603 at
> /usr/src/kernel/fs/proc/generic.c:717 remove_proc_entry+0x1a8/0x1c0
> [   46.161566] Modules linked in: gpio_mockup(-) x86_pkg_temp_thermal fuse
> [   46.168195] CPU: 2 PID: 603 Comm: modprobe Not tainted
> 5.12.0-rc5-next-20210330 #1
> [   46.175793] Hardware name: Supermicro SYS-5019S-ML/X11SSH-F, BIOS
> 2.2 05/23/2018
> [   46.183217] RIP: 0010:remove_proc_entry+0x1a8/0x1c0
> O gpio-mockup te[   46.188128] Code: 40 bc 24 a8 48 c7 c7 98 4a 6a a8
> 48 0f 45 c2 49 8b 94 24 b0 00 00 00 4c 8b 80 d8 00 00 00 48 8b 92 d8
> 00 00 00 e8 38 36 cb ff <0f> 0b e9 5b ff ff ff e8 0c f4 c5 00 66 90 66
> 2e 0f 1f 84 00 00 00
> [   46.208252] RSP: 0018:9da080293c58 EFLAGS: 00010286
> [   46.213511] RAX:  RBX: 93e8403bcbb8 RCX: 
> 
> [   46.220650] RDX: 0001 RSI: 93e9afb177f0 RDI: 
> 93e9afb177f0
> [   46.227820] RBP: 9da080293c88 R08: 0001 R09: 
> 0001
> [   46.235018] R10: 9da080293a80 R11: 9da080293a08 R12: 
> 93e8403bcb00
> [   46.242165] R13: 93e840263100 R14: 0001 R15: 
> 
> st FAIL
> [   46.249303] FS:  7f7dc2501740() GS:93e9afb0()
> knlGS:
> [   46.258164] CS:  0010 DS:  ES:  CR0: 80050033
> [   46.263977] CR2: 7f7dc1de67f0 CR3: 00014f292003 CR4: 
> 003706e0
> [   46.271124] DR0:  DR1:  DR2: 
> 
> [   46.278292] DR3:  DR6: fffe0ff0 DR7: 
> 0400
> [   46.285459] Call Trace:
> [   46.287926]  unregister_irq_proc+0xf8/0x110
> [   46.292128]  free_desc+0x2e/0x70
> [   46.295393]  irq_free_descs+0x54/0x80
> [   46.299102]  irq_domain_free_irqs+0x11b/0x150
> [   46.303507]  irq_dispose_mapping+0x77/0x120
> [   46.307711]  gpio_mockup_dispose_mappings+0x4c/0x60 [gpio_mockup]
> [   46.313817]  devm_action_release+0x15/0x20
> [   46.317933]  release_nodes+0x11e/0x220
> [   46.321707]  devres_release_all+0x3c/0x50
> [   46.325733]  device_release_driver_internal+0x10e/0x1d0
> [   46.331016]  driver_detach+0x4d/0xa0
> [   46.334609]  bus_remove_driver+0x5f/0xe0
> [   46.338553]  driver_unregister+0x2f/0x50
> [   46.342495]  platform_driver_unregister+0x12/0x20
> [   46.347218]  gpio_mockup_exit+0x1f/0x5cc [gpio_mockup]
> [   46.352374]  __x64_sys_delete_module+0x15b/0x260
> [   46.357082]  do_syscall_64+0x37/0x50
> [   46.360676]  entry_SYSCALL_64_after_hwframe+0x44/0xae
> [   46.365748] RIP: 0033:0x7f7dc1e0f997
> [   46.369342] Code: 73 01 c3 48 8b 0d 01 a5 2b 00 f7 d8 64 89 01 48
> 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 b8 b0 00 00
> 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d d1 a4 2b 00 f7 d8 64 89
> 01 48
> [   46.388108] RSP: 002b:7ffe35506e78 EFLAGS: 0206 ORIG_RAX:
> 00b0
> [   46.395708] RAX: ffda RBX: 0134ebd0 RCX: 
> 7f7dc1e0f997
> [   46.402883] RDX:  RSI: 0800 RDI: 
> 0134ec38
> [   46.410031] RBP:  R08: 7ffe35505e41 R09: 
> 
> [   46.417183] R10: 08da R11: 0206 R12: 
> 0134ec38
> [   46.424331] R13: 0001 R14: 0134ec38 R15: 
> 7ffe35508238
> [   46.431507] irq event stamp: 6645
> [   46.434845] hardirqs last  enabled at (6655): []
> console_unlock+0x34e/0x550
> [   46.443380] hardirqs last disabled at (6664): []
> console_unlock+0x3b9/0x550
> [   46.451915] softirqs last  enabled at (6564): []
> __do_softirq+0x30e/0x421
> [   46.460333] softirqs last disabled at (6559): []
> irq_exit_rcu+0xb3/0xc0
> [   46.468548] ---[ end trace 89d01

Re: [RESEND PATCH 4/5] clk: at91: clk-master: add register definition for sama7g5's master clock

[Nicolas Ferre]

On 24/03/2021 at 10:43, Claudiu Beznea wrote:

Add register definitions for SAMA7G5's master clock. These would be
also used by architecture specific power saving code. With this, update
also clk-master.c.

Signed-off-by: Claudiu Beznea 
---
  drivers/clk/at91/clk-master.c | 51 +--
  include/linux/clk/at91_pmc.h  | 26 ++
  2 files changed, 50 insertions(+), 27 deletions(-)

diff --git a/drivers/clk/at91/clk-master.c b/drivers/clk/at91/clk-master.c
index 6f1fb2eb2a8d..a6a393bb1def 100644
--- a/drivers/clk/at91/clk-master.c
+++ b/drivers/clk/at91/clk-master.c
@@ -17,15 +17,7 @@
  #define MASTER_DIV_SHIFT  8
  #define MASTER_DIV_MASK   0x7
  
-#define PMC_MCR			0x30

-#define PMC_MCR_ID_MSK GENMASK(3, 0)
-#define PMC_MCR_CMDBIT(7)
-#define PMC_MCR_DIVGENMASK(10, 8)
-#define PMC_MCR_CSSGENMASK(20, 16)
  #define PMC_MCR_CSS_SHIFT (16)
-#define PMC_MCR_EN BIT(28)
-
-#define PMC_MCR_ID(x)  ((x) & PMC_MCR_ID_MSK)
  
  #define MASTER_MAX_ID		4
  
@@ -685,17 +677,20 @@ static void clk_sama7g5_master_set(struct clk_master *master,
  
  	spin_lock_irqsave(master->lock, flags);
  
-	regmap_write(master->regmap, PMC_MCR, PMC_MCR_ID(master->id));

-   regmap_read(master->regmap, PMC_MCR, );
-   regmap_update_bits(master->regmap, PMC_MCR,
-  (status ? PMC_MCR_EN : 0) | PMC_MCR_CSS | 
PMC_MCR_DIV |
-  PMC_MCR_CMD | PMC_MCR_ID_MSK,
-  (status ? PMC_MCR_EN : 0) |
+   regmap_write(master->regmap, AT91_PMC_MCR_V2,
+AT91_PMC_MCR_V2_ID(master->id));
+   regmap_read(master->regmap, AT91_PMC_MCR_V2, );
+   regmap_update_bits(master->regmap, AT91_PMC_MCR_V2,
+  (status ? AT91_PMC_MCR_V2_EN : 0) |
+  AT91_PMC_MCR_V2_CSS | AT91_PMC_MCR_V2_DIV |
+  AT91_PMC_MCR_V2_CMD | AT91_PMC_MCR_V2_ID_MSK,
+  (status ? AT91_PMC_MCR_V2_EN : 0) |


Ok, here also. Can't we make it simpler to read?


   (master->parent << PMC_MCR_CSS_SHIFT) |
   (master->div << MASTER_DIV_SHIFT) |
-  PMC_MCR_CMD | PMC_MCR_ID(master->id));
+  AT91_PMC_MCR_V2_CMD |
+  AT91_PMC_MCR_V2_ID(master->id));
  
-	cparent = (val & PMC_MCR_CSS) >> PMC_MCR_CSS_SHIFT;

+   cparent = (val & AT91_PMC_MCR_V2_CSS) >> PMC_MCR_CSS_SHIFT;
  
  	/* Wait here only if parent is being changed. */

while ((cparent != master->parent) && !clk_master_ready(master))
@@ -720,10 +715,12 @@ static void clk_sama7g5_master_disable(struct clk_hw *hw)
  
  	spin_lock_irqsave(master->lock, flags);
  
-	regmap_write(master->regmap, PMC_MCR, master->id);

-   regmap_update_bits(master->regmap, PMC_MCR,
-  PMC_MCR_EN | PMC_MCR_CMD | PMC_MCR_ID_MSK,
-  PMC_MCR_CMD | PMC_MCR_ID(master->id));
+   regmap_write(master->regmap, AT91_PMC_MCR_V2, master->id);
+   regmap_update_bits(master->regmap, AT91_PMC_MCR_V2,
+  AT91_PMC_MCR_V2_EN | AT91_PMC_MCR_V2_CMD |
+  AT91_PMC_MCR_V2_ID_MSK,
+  AT91_PMC_MCR_V2_CMD |
+  AT91_PMC_MCR_V2_ID(master->id));
  
  	spin_unlock_irqrestore(master->lock, flags);

  }
@@ -736,12 +733,12 @@ static int clk_sama7g5_master_is_enabled(struct clk_hw 
*hw)
  
  	spin_lock_irqsave(master->lock, flags);
  
-	regmap_write(master->regmap, PMC_MCR, master->id);

-   regmap_read(master->regmap, PMC_MCR, );
+   regmap_write(master->regmap, AT91_PMC_MCR_V2, master->id);
+   regmap_read(master->regmap, AT91_PMC_MCR_V2, );
  
  	spin_unlock_irqrestore(master->lock, flags);
  
-	return !!(val & PMC_MCR_EN);

+   return !!(val & AT91_PMC_MCR_V2_EN);
  }
  
  static int clk_sama7g5_master_set_rate(struct clk_hw *hw, unsigned long rate,

@@ -837,10 +834,10 @@ at91_clk_sama7g5_register_master(struct regmap *regmap,
master->mux_table = mux_table;
  
  	spin_lock_irqsave(master->lock, flags);

-   regmap_write(master->regmap, PMC_MCR, master->id);
-   regmap_read(master->regmap, PMC_MCR, );
-   master->parent = (val & PMC_MCR_CSS) >> PMC_MCR_CSS_SHIFT;
-   master->div = (val & PMC_MCR_DIV) >> MASTER_DIV_SHIFT;
+   regmap_write(master->regmap, AT91_PMC_MCR_V2, master->id);
+   regmap_read(master->regmap, AT91_PMC_MCR_V2, );
+   master->parent = (val & AT91_PMC_MCR_V2_CSS) >> PMC_MCR_CSS_SHIFT;
+   master->div = (val & AT91_PMC_MCR_V2_DIV) >> MASTER_DIV_SHIFT;
spin_unlock_irqrestore(master->lock, flags);
  
  	hw = >hw;

diff --git a/include/linux/clk/at91_pmc.h b/include/linux/clk/at91_pmc.h
index a4f82e836a7c..ccb3f034bfa9 100644
--- a/include/linux/clk/at91_pmc.h
+++ b/include/linux/clk/at91_pmc.h
@@ -137,6 +137,32 @@