[PATCH v2] arm64: Add __init section marker to some functions

[Jisheng Zhang]

They are not needed after booting, so mark them as __init to move them
to the .init section.

Signed-off-by: Jisheng Zhang 
---
Since v1:
 - add __init section mark to __vdso_init() and __aarch32_alloc_vdso_pages()

 arch/arm64/include/asm/ptdump.h | 2 +-
 arch/arm64/kernel/vdso.c| 4 ++--
 arch/arm64/mm/ptdump.c  | 4 ++--
 arch/arm64/mm/ptdump_debugfs.c  | 2 +-
 4 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm64/include/asm/ptdump.h b/arch/arm64/include/asm/ptdump.h
index 38187f74e089..b1dd7ecff7ef 100644
--- a/arch/arm64/include/asm/ptdump.h
+++ b/arch/arm64/include/asm/ptdump.h
@@ -23,7 +23,7 @@ struct ptdump_info {
 
 void ptdump_walk(struct seq_file *s, struct ptdump_info *info);
 #ifdef CONFIG_PTDUMP_DEBUGFS
-void ptdump_debugfs_register(struct ptdump_info *info, const char *name);
+void __init ptdump_debugfs_register(struct ptdump_info *info, const char 
*name);
 #else
 static inline void ptdump_debugfs_register(struct ptdump_info *info,
   const char *name) { }
diff --git a/arch/arm64/kernel/vdso.c b/arch/arm64/kernel/vdso.c
index cee5d04ea9ad..d1fa288518a7 100644
--- a/arch/arm64/kernel/vdso.c
+++ b/arch/arm64/kernel/vdso.c
@@ -86,7 +86,7 @@ static int vdso_mremap(const struct vm_special_mapping *sm,
return 0;
 }
 
-static int __vdso_init(enum vdso_abi abi)
+static int __init __vdso_init(enum vdso_abi abi)
 {
int i;
struct page **vdso_pagelist;
@@ -326,7 +326,7 @@ static int aarch32_alloc_sigpage(void)
return 0;
 }
 
-static int __aarch32_alloc_vdso_pages(void)
+static int __init __aarch32_alloc_vdso_pages(void)
 {
 
if (!IS_ENABLED(CONFIG_COMPAT_VDSO))
diff --git a/arch/arm64/mm/ptdump.c b/arch/arm64/mm/ptdump.c
index 0e050d76b83a..a50e92ea1878 100644
--- a/arch/arm64/mm/ptdump.c
+++ b/arch/arm64/mm/ptdump.c
@@ -337,7 +337,7 @@ void ptdump_walk(struct seq_file *s, struct ptdump_info 
*info)
ptdump_walk_pgd(, info->mm, NULL);
 }
 
-static void ptdump_initialize(void)
+static void __init ptdump_initialize(void)
 {
unsigned i, j;
 
@@ -381,7 +381,7 @@ void ptdump_check_wx(void)
pr_info("Checked W+X mappings: passed, no W+X pages found\n");
 }
 
-static int ptdump_init(void)
+static int __init ptdump_init(void)
 {
address_markers[PAGE_END_NR].start_address = PAGE_END;
 #if defined(CONFIG_KASAN_GENERIC) || defined(CONFIG_KASAN_SW_TAGS)
diff --git a/arch/arm64/mm/ptdump_debugfs.c b/arch/arm64/mm/ptdump_debugfs.c
index d29d722ec3ec..68bf1a125502 100644
--- a/arch/arm64/mm/ptdump_debugfs.c
+++ b/arch/arm64/mm/ptdump_debugfs.c
@@ -16,7 +16,7 @@ static int ptdump_show(struct seq_file *m, void *v)
 }
 DEFINE_SHOW_ATTRIBUTE(ptdump);
 
-void ptdump_debugfs_register(struct ptdump_info *info, const char *name)
+void __init ptdump_debugfs_register(struct ptdump_info *info, const char *name)
 {
debugfs_create_file(name, 0400, NULL, info, _fops);
 }
-- 
2.31.0

Re: [PATCH] ftrace: Fix spelling mistake "disabed" -> "disabled"

[Palmer Dabbelt]

On Wed, 17 Mar 2021 06:42:23 PDT (-0700), rost...@goodmis.org wrote:

On Tue, 16 Mar 2021 21:21:08 -0700 (PDT)
Palmer Dabbelt  wrote:


Thanks, this is on fixes.


What does this mean? Is there a tree that spelling fixes go through now?

I had already pulled this patch into my queue for the next merge window
(and it's still in the testing phase with other patches before going to
linux-next).

Should I drop it?


Oh, sorry.  It's on the fixes branch of the riscv tree 
 .  
It's what I sent up to Linus every week, this one already went up.


I must have not been looking closely enough, for some reason I thought 
this only touched the riscv tree.  I wouldn't have taken it without an 
Ack if I'd noticed, I guess just because it was only a comment spelling 
change I hadn't checked the paths.  I'll try not to do that again.

Re: [PATCH] riscv,entry: fix misaligned base for excp_vect_table

[Palmer Dabbelt]

On Wed, 17 Mar 2021 01:17:25 PDT (-0700), yuzi...@ict.ac.cn wrote:

* In RV64, the size of each entry in excp_vect_table is 8 bytes. If the
  base of the table is not 8-byte aligned, loading an entry in the table
  will raise a misaligned exception. Although such exception will be
  handled by opensbi/bbl, this still causes performance degradation.

Signed-off-by: Zihao Yu 
---
 arch/riscv/kernel/entry.S | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/riscv/kernel/entry.S b/arch/riscv/kernel/entry.S
index 744f3209c..76274a4a1 100644
--- a/arch/riscv/kernel/entry.S
+++ b/arch/riscv/kernel/entry.S
@@ -447,6 +447,7 @@ ENDPROC(__switch_to)
 #endif

.section ".rodata"
+   .align LGREG
/* Exception vector table */
 ENTRY(excp_vect_table)
RISCV_PTR do_trap_insn_misaligned


Thanks, this is on fixes.

Re: [PATCH v4 3/4] locking/qspinlock: Add ARCH_USE_QUEUED_SPINLOCKS_XCHG32

[Anup Patel]

On Tue, Mar 30, 2021 at 7:56 AM Guo Ren  wrote:
>
> On Mon, Mar 29, 2021 at 9:56 PM Arnd Bergmann  wrote:
> >
> > On Mon, Mar 29, 2021 at 2:52 PM Guo Ren  wrote:
> > >
> > > On Mon, Mar 29, 2021 at 7:31 PM Peter Zijlstra  
> > > wrote:
> > > >
> > > > On Mon, Mar 29, 2021 at 01:16:53PM +0200, Peter Zijlstra wrote:
> > > > > Anyway, an additional 'funny' is that I suspect you cannot prove fwd
> > > > > progress of the entire primitive with any of this on. But who cares
> > > > > about details anyway.. :/
> > > >
> > > > What's the architectural guarantee on LL/SC progress for RISC-V ?
> > >
> > > funct5| aq | rl   | rs2 |  rs1  | funct3 | rd | opcode
> > >  5  11  5   5 35  7
> > > LR.W/D  ordering  0 addrwidth   destAMO
> > > SC.W/D  ordering  src  addrwidth   destAMO
> > >
> > > LR.W loads a word from the address in rs1, places the sign-extended
> > > value in rd, and registers a reservation set—a set of bytes that
> > > subsumes the bytes in the addressed word. SC.W conditionally writes a
> > > word in rs2 to the address in rs1: the SC.W succeeds only if the
> > > reservation is still valid and the reservation set contains the bytes
> > > being written. If the SC.W succeeds, the instruction writes the word
> > > in rs2 to memory, and it writes zero to rd. If the SC.W fails, the
> > > instruction does not write to memory, and it writes a nonzero value to
> > > rd. Regardless of success or failure, executing an SC.W instruction
> > > *invalidates any reservation held by this hart*.
> > >
> > > More details, ref:
> > > https://github.com/riscv/riscv-isa-manual
> >
> > I think section "3.5.3.2 Reservability PMA" [1] would be a more relevant
> > link, as this defines memory areas that either do or do not have
> > forward progress guarantees, including this part:
> >
> >"When LR/SC is used for memory locations marked RsrvNonEventual,
> >  software should provide alternative fall-back mechanisms used when
> >  lack of progress is detected."
> >
> > My reading of this is that if the example you tried stalls, then either
> > the PMA is not RsrvEventual, and it is wrong to rely on ll/sc on this,
> > or that the PMA is marked RsrvEventual but the implementation is
> > buggy.
> Yes, PMA just defines physical memory region attributes, But in our
> processor, when MMU is enabled (satp's value register > 2) in s-mode,
> it will look at our custom PTE's attributes BIT(63) ref [1]:
>
>PTE format:
>| 63 | 62 | 61 | 60 | 59 | 58-8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0
>  SO   CBSH   SERSW   D   A   G   U   X   W   R   V
>  ^^^^^
>BIT(63): SO - Strong Order
>BIT(62): C  - Cacheable
>BIT(61): B  - Bufferable
>BIT(60): SH - Shareable
>BIT(59): SE - Security
>
> So the memory also could be RsrvNone/RsrvEventual.
>
> [1] 
> https://github.com/c-sky/csky-linux/commit/e837aad23148542771794d8a2fcc52afd0fcbf88

Is this about your C-sky architecture or your RISC-V implementation.

If these PTE bits are in your RISC-V implementation then clearly your
RISC-V implementation is not compliant with the RISC-V privilege spec
because these bits are not defined in RISC-V privilege spec.

Regards,
Anup
>
> >
> > It also seems that the current "amoswap" based implementation
> > would be reliable independent of RsrvEventual/RsrvNonEventual.
> Yes, the hardware implementation of AMO could be different from LR/SC.
> AMO could use ACE snoop holding to lock the bus in hw coherency
> design, but LR/SC uses an exclusive monitor without locking the bus.
>
> > arm64 is already in the situation of having to choose between
> > two cmpxchg() implementation at runtime to allow falling back to
> > a slower but more general version, but it's best to avoid that if you
> > can.
> Current RISC-V needn't multiple versions to select, and all AMO &
> LR/SC has been defined in the spec.
>
> RISC-V hasn't CAS instructions, and it uses LR/SC for cmpxchg. I don't
> think LR/SC would be slower than CAS, and CAS is just good for code
> size.
>
> >
> >  Arnd
> >
> > [1] 
> > http://www.five-embeddev.com/riscv-isa-manual/latest/machine.html#atomicity-pmas
>
> --
> Best Regards
>  Guo Ren
>
> ML: https://lore.kernel.org/linux-csky/

Re: [PATCH 5.4 000/111] 5.4.109-rc1 review

[Naresh Kamboju]

On Mon, 29 Mar 2021 at 13:44, Greg Kroah-Hartman
 wrote:
>
> This is the start of the stable review cycle for the 5.4.109 release.
> There are 111 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed, 31 Mar 2021 07:55:56 +.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> 
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.109-rc1.gz
> or in the git tree and branch at:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-5.4.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h


Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.

Tested-by: Linux Kernel Functional Testing 

Summary


kernel: 5.4.109-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-5.4.y
git commit: 7b78fa4bf15f02997c4dba22fe2bf2ca8aa9906f
git describe: v5.4.108-112-g7b78fa4bf15f
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.4.y/build/v5.4.108-112-g7b78fa4bf15f

No regressions (compared to build v5.4.108)

No fixes (compared to build v5.4.108)

Ran 59776 total tests in the following environments and test suites.

Environments
--
- arc
- arm
- arm64
- dragonboard-410c
- hi6220-hikey
- i386
- juno-r2
- juno-r2-compat
- juno-r2-kasan
- mips
- nxp-ls2088
- nxp-ls2088-64k_page_size
- parisc
- powerpc
- qemu-arm-clang
- qemu-arm-debug
- qemu-arm64-clang
- qemu-arm64-debug
- qemu-arm64-kasan
- qemu-i386-debug
- qemu-x86_64-clang
- qemu-x86_64-debug
- qemu-x86_64-kasan
- qemu-x86_64-kcsan
- qemu_arm
- qemu_arm64
- qemu_arm64-compat
- qemu_i386
- qemu_x86_64
- qemu_x86_64-compat
- riscv
- s390
- sh
- sparc
- x15
- x86
- x86-kasan
- x86_64

Test Suites
---
* build
* linux-log-parser
* install-android-platform-tools-r2600
* kselftest-efivarfs
* kselftest-filesystems
* kselftest-firmware
* kselftest-fpu
* kselftest-futex
* kselftest-gpio
* kselftest-ipc
* kselftest-ir
* kselftest-kcmp
* kselftest-kvm
* kselftest-lib
* kselftest-lkdtm
* kselftest-membarrier
* kselftest-memfd
* kselftest-memory-hotplug
* kselftest-mincore
* kselftest-mount
* kselftest-mqueue
* kselftest-net
* kselftest-netfilter
* kselftest-nsfs
* kselftest-openat2
* kselftest-pid_namespace
* kselftest-pidfd
* kselftest-proc
* kselftest-pstore
* kselftest-tc-testing
* ltp-cap_bounds-tests
* ltp-containers-tests
* ltp-cpuhotplug-tests
* ltp-crypto-tests
* ltp-cve-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-math-tests
* ltp-mm-tests
* ltp-sched-tests
* ltp-tracing-tests
* perf
* v4l2-compliance
* fwts
* kselftest-android
* kselftest-bpf
* kselftest-capabilities
* kselftest-cgroup
* kselftest-clone3
* kselftest-core
* kselftest-cpu-hotplug
* kselftest-cpufreq
* kselftest-intel_pstate
* kselftest-livepatch
* kselftest-ptrace
* kselftest-rseq
* kselftest-rtc
* kselftest-seccomp
* kselftest-sigaltstack
* kselftest-size
* kselftest-splice
* kselftest-static_keys
* kselftest-sync
* kselftest-sysctl
* kselftest-timens
* kselftest-timers
* kselftest-tmpfs
* kselftest-tpm2
* kselftest-user
* kselftest-zram
* kvm-unit-tests
* libhugetlbfs
* ltp-commands-tests
* ltp-controllers-tests
* ltp-dio-tests
* ltp-fs-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* network-basic-tests
* kselftest-kexec
* kselftest-vm
* kselftest-x86
* ltp-open-posix-tests
* rcutorture
* igt-gpu-tools
* ssuite
* kselftest-vsyscall-mode-native-

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

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

[Noah Goldstein]

Forgive if this is silly but would it be possible to do something
simliar to rseq where the user can register a set of features for a
program counter region and then on interrupt check that to determine
what needs to be saved?

For example if a user doesn't use any AMX but loads a library that
does, for all ip in the users code AMX state won't be saved but an
interrupt in ip range of the library will save AMX state.

One advantage of this is it would be pretty easy silently do this
right with compiler support and to preserve old code the "ip not found
in table" case could default to the worst case the CPU supports.

On Tue, Mar 30, 2021 at 1:09 AM Andy Lutomirski via Libc-alpha
 wrote:
>
> On Mon, Mar 29, 2021 at 3:38 PM Len Brown  wrote:
> >
> > On Mon, Mar 29, 2021 at 2:16 PM Andy Lutomirski  wrote:
> > >
>
> > Hi Andy,
> >
> > Can you provide a concise definition of the exact problemI(s) this thread
> > is attempting to address?
>
> The AVX-512 state, all by itself, is more than 2048 bytes.  Quoting
> the POSIX sigaltstack page (man 3p sigaltstack):
>
>The  value  SIGSTKSZ is a system default specifying the number of bytes
>that would be used to cover the usual case when manually allocating  an
>alternate  stack area. The value MINSIGSTKSZ is defined to be the mini‐
>mum stack size for a signal handler. In computing  an  alternate  stack
>size, a program should add that amount to its stack requirements to al‐
>low for the system implementation overhead. The  constants  SS_ONSTACK,
>SS_DISABLE, SIGSTKSZ, and MINSIGSTKSZ are defined in .
>
> arch/x86/include/uapi/asm/signal.h:#define MINSIGSTKSZ2048
> arch/x86/include/uapi/asm/signal.h:#define SIGSTKSZ8192
>
> Regrettably, the Linux signal frame format is the uncompacted format
> and, also regrettably, the uncompacted format has the nasty property
> that its format depends on XCR0 but not on the set of registers that
> are actually used or wanted, so, with the current ABI, the signal
> frame is stuck being quite large for all programs on a machine that
> supports avx512 and has it enabled by the kernel.  And it's even
> larger for AMX and violates SIGSTKSZ as well as MINSTKSZ.
>
> There are apparently real programs that break as a result.  We need to
> find a way to handle new, large extended states without breaking user
> ABI.  We should also find a way to handle them without consuming silly
> amounts of stack space for programs that don't use them.
>
> Sadly, if the solution we settle on involves context switching XCR0,
> performance on first-generation hardware will suffer because VMX does
> not have any way to allow guests to write XCR0 without exiting.  I
> don't consider this to be a showstopper -- if we end up having this
> problem, fixing it in subsequent CPUs is straightforward.
>
> >
> > Thank ahead-of-time for excluding "blow up power consumption",
> > since that paranoia is not grounded in fact.
> >
>
> I will gladly exclude power consumption from this discussion, since
> that's a separate issue that has nothing to do with the user<->kernel
> ABI.

Re: [PATCH v16 00/17] KVM RISC-V Support

[Anup Patel]

On Sat, Jan 23, 2021 at 9:10 AM Palmer Dabbelt  wrote:
>
> On Fri, 15 Jan 2021 04:18:29 PST (-0800), Anup Patel wrote:
> > This series adds initial KVM RISC-V support. Currently, we are able to boot
> > Linux on RV64/RV32 Guest with multiple VCPUs.
>
> Thanks.  IIUC the spec is still in limbo at the RISC-V foundation?  I haven't
> really been paying attention lately.

There is no change in H-extension spec for more than a year now.

The H-extension spec also has provision for external interrupt controller
with virtualization support (such as the RISC-V AIA specification).

It seems Andrew does not want to freeze H-extension until we have virtualization
aware interrupt controller (such as RISC-V AIA specification) and IOMMU. Lot
of us feel that these things can be done independently because RISC-V
H-extension already has provisions for external interrupt controller with
virtualization support.

The freeze criteria for H-extension is still not clear to me.
Refer, 
https://lists.riscv.org/g/tech-privileged/topic/risc_v_h_extension_freeze/80346318?p=,,,20,0,0,0::recentpostdate%2Fsticky,,,20,2,0,80346318

Regards,
Anup

>
> >
> > Key aspects of KVM RISC-V added by this series are:
> > 1. No RISC-V specific KVM IOCTL
> > 2. Minimal possible KVM world-switch which touches only GPRs and few CSRs
> > 3. Both RV64 and RV32 host supported
> > 4. Full Guest/VM switch is done via vcpu_get/vcpu_put infrastructure
> > 5. KVM ONE_REG interface for VCPU register access from user-space
> > 6. PLIC emulation is done in user-space
> > 7. Timer and IPI emuation is done in-kernel
> > 8. Both Sv39x4 and Sv48x4 supported for RV64 host
> > 9. MMU notifiers supported
> > 10. Generic dirtylog supported
> > 11. FP lazy save/restore supported
> > 12. SBI v0.1 emulation for KVM Guest available
> > 13. Forward unhandled SBI calls to KVM userspace
> > 14. Hugepage support for Guest/VM
> > 15. IOEVENTFD support for Vhost
> >
> > Here's a brief TODO list which we will work upon after this series:
> > 1. SBI v0.2 emulation in-kernel
> > 2. SBI v0.2 hart state management emulation in-kernel
> > 3. In-kernel PLIC emulation
> > 4. . and more .
> >
> > This series can be found in riscv_kvm_v16 branch at:
> > https//github.com/avpatel/linux.git
> >
> > Our work-in-progress KVMTOOL RISC-V port can be found in riscv_v6 branch
> > at: https//github.com/avpatel/kvmtool.git
> >
> > The QEMU RISC-V hypervisor emulation is done by Alistair and is available
> > in master branch at: https://git.qemu.org/git/qemu.git
> >
> > To play around with KVM RISC-V, refer KVM RISC-V wiki at:
> > https://github.com/kvm-riscv/howto/wiki
> > https://github.com/kvm-riscv/howto/wiki/KVM-RISCV64-on-QEMU
> > https://github.com/kvm-riscv/howto/wiki/KVM-RISCV64-on-Spike
> >
> > Changes since v15:
> >  - Rebased on Linux-5.11-rc3
> >  - Fixed kvm_stage2_map() to use gfn_to_pfn_prot() for determing
> >writeability of a host pfn.
> >  - Use "__u64" in-place of "u64" and "__u32" in-place of "u32" for
> >uapi/asm/kvm.h
> >
> > Changes since v14:
> >  - Rebased on Linux-5.10-rc3
> >  - Fixed Stage2 (G-stage) PDG allocation to ensure it is 16KB aligned
> >
> > Changes since v13:
> >  - Rebased on Linux-5.9-rc3
> >  - Fixed kvm_riscv_vcpu_set_reg_csr() for SIP updation in PATCH5
> >  - Fixed instruction length computation in PATCH7
> >  - Added ioeventfd support in PATCH7
> >  - Ensure HSTATUS.SPVP is set to correct value before using HLV/HSV
> >intructions in PATCH7
> >  - Fixed stage2_map_page() to set PTE 'A' and 'D' bits correctly
> >in PATCH10
> >  - Added stage2 dirty page logging in PATCH10
> >  - Allow KVM user-space to SET/GET SCOUNTER CSR in PATCH5
> >  - Save/restore SCOUNTEREN in PATCH6
> >  - Reduced quite a few instructions for __kvm_riscv_switch_to() by
> >using CSR swap instruction in PATCH6
> >  - Detect and use Sv48x4 when available in PATCH10
> >
> > Changes since v12:
> >  - Rebased patches on Linux-5.8-rc4
> >  - By default enable all counters in HCOUNTEREN
> >  - RISC-V H-Extension v0.6.1 spec support
> >
> > Changes since v11:
> >  - Rebased patches on Linux-5.7-rc3
> >  - Fixed typo in typecast of stage2_map_size define
> >  - Introduced struct kvm_cpu_trap to represent trap details and
> >use it as function parameter wherever applicable
> >  - Pass memslot to kvm_riscv_stage2_map() for supporing dirty page
> >logging in future
> >  - RISC-V H-Extension v0.6 spec support
> >  - Send-out first three patches as separate series so that it can
> >be taken by Palmer for Linux RISC-V
> >
> > Changes since v10:
> >  - Rebased patches on Linux-5.6-rc5
> >  - Reduce RISCV_ISA_EXT_MAX from 256 to 64
> >  - Separate PATCH for removing N-extension related defines
> >  - Added comments as requested by Palmer
> >  - Fixed HIDELEG CSR programming
> >
> > Changes since v9:
> >  - Rebased patches on Linux-5.5-rc3
> >  - Squash PATCH19 and PATCH20 into PATCH5
> >  - Squash PATCH18 into PATCH11
> >  - Squash PATCH17 into PATCH16
> >  - 

Re: [PATCH v5 4/4] fs: unicode: Add utf8 module and a unicode layer

[Eric Biggers]

On Mon, Mar 29, 2021 at 10:16:57PM -0400, Gabriel Krisman Bertazi wrote:
> Eric Biggers  writes:
> 
> > On Tue, Mar 30, 2021 at 02:12:40AM +0530, Shreeya Patel wrote:
> >> diff --git a/fs/unicode/Kconfig b/fs/unicode/Kconfig
> >> index 2c27b9a5cd6c..ad4b837f2eb2 100644
> >> --- a/fs/unicode/Kconfig
> >> +++ b/fs/unicode/Kconfig
> >> @@ -2,13 +2,26 @@
> >>  #
> >>  # UTF-8 normalization
> >>  #
> >> +# CONFIG_UNICODE will be automatically enabled if CONFIG_UNICODE_UTF8
> >> +# is enabled. This config option adds the unicode subsystem layer which 
> >> loads
> >> +# the UTF-8 module whenever any filesystem needs it.
> >>  config UNICODE
> >> -  bool "UTF-8 normalization and casefolding support"
> >> +  bool
> >> +
> >> +# utf8data.h_shipped has a large database table which is an auto-generated
> >> +# decodification trie for the unicode normalization functions and it is 
> >> not
> >> +# necessary to carry this large table in the kernel.
> >> +# Enabling UNICODE_UTF8 option will allow UTF-8 encoding to be built as a
> >> +# module and this module will be loaded by the unicode subsystem layer 
> >> only
> >> +# when any filesystem needs it.
> >> +config UNICODE_UTF8
> >> +  tristate "UTF-8 module"
> >>help
> >>  Say Y here to enable UTF-8 NFD normalization and NFD+CF casefolding
> >>  support.
> >> +  select UNICODE
> >
> > This seems problematic; it allows users to set CONFIG_EXT4_FS=y (or
> > CONFIG_F2FS_FS=y) but then CONFIG_UNICODE_UTF8=m.  Then the filesystem won't
> > work if the modules are located on the filesystem itself.
> 
> Hi Eric,
> 
> Isn't this a user problem?  If the modules required to boot are on the
> filesystem itself, you are in trouble.  But, if that is the case, your
> rootfs is case-insensitive and you gotta have utf8 as built-in or have
> it in an early userspace.
> 

We could make it the user's problem, but that seems rather unfriendly.
Especially because the utf8 module would be needed if the filesystem has the
casefold feature at all, regardless of whether any casefolded directories are
needed at boot time or not.  (Unless there is a plan to change that?)

- Eric

Re: [Question] Is there a race window between swapoff vs synchronous swap_readpage

[Yu Zhao]

On Mon, Mar 29, 2021 at 9:44 PM Huang, Ying  wrote:
>
> Miaohe Lin  writes:
>
> > On 2021/3/30 9:57, Huang, Ying wrote:
> >> Hi, Miaohe,
> >>
> >> Miaohe Lin  writes:
> >>
> >>> Hi all,
> >>> I am investigating the swap code, and I found the below possible race 
> >>> window:
> >>>
> >>> CPU 1   CPU 2
> >>> -   -
> >>> do_swap_page
> >>>   skip swapcache case (synchronous swap_readpage)
> >>> alloc_page_vma
> >>> swapoff
> >>>   release swap_file, 
> >>> bdev, or ...
> >>>   swap_readpage
> >>> check sis->flags is ok
> >>>   access swap_file, bdev or ...[oops!]
> >>> si->flags = 0
> >>>
> >>> The swapcache case is ok because swapoff will wait on the page_lock of 
> >>> swapcache page.
> >>> Is this will really happen or Am I miss something ?
> >>> Any reply would be really grateful. Thanks! :)
> >>
> >> This appears possible.  Even for swapcache case, we can't guarantee the
> >
> > Many thanks for reply!
> >
> >> swap entry gotten from the page table is always valid too.  The
> >
> > The page table may change at any time. And we may thus do some useless work.
> > But the pte_same() check could handle these races correctly if these do not
> > result in oops.
> >
> >> underlying swap device can be swapped off at the same time.  So we use
> >> get/put_swap_device() for that.  Maybe we need similar stuff here.
> >
> > Using get/put_swap_device() to guard against swapoff for swap_readpage() 
> > sounds
> > really bad as swap_readpage() may take really long time. Also such race may 
> > not be
> > really hurtful because swapoff is usually done when system shutdown only.
> > I can not figure some simple and stable stuff out to fix this. Any 
> > suggestions or
> > could anyone help get rid of such race?
>
> Some reference counting on the swap device can prevent swap device from
> swapping-off.  To reduce the performance overhead on the hot-path as
> much as possible, it appears we can use the percpu_ref.

Hi,

I've been seeing crashes when testing the latest kernels with
  stress-ng --class vm -a 20 -t 600s --temp-path /tmp

I haven't had time to look into them yet:

DEBUG_VM:
  BUG: unable to handle page fault for address: 905c33c9a000
  Call Trace:
   get_swap_pages+0x278/0x590
   get_swap_page+0x1ab/0x280
   add_to_swap+0x7d/0x130
   shrink_page_list+0xf84/0x25f0
   reclaim_pages+0x313/0x430
   madvise_cold_or_pageout_pte_range+0x95c/0xaa0

KASAN:
  ==
  BUG: KASAN: slab-out-of-bounds in __frontswap_store+0xc9/0x2e0
  Read of size 8 at addr 88901f646f18 by task stress-ng-mrema/31329
  CPU: 2 PID: 31329 Comm: stress-ng-mrema Tainted: G SI  L
5.12.0-smp-DEV #2
  Call Trace:
   dump_stack+0xff/0x165
   print_address_description+0x81/0x390
   __kasan_report+0x154/0x1b0
   ? __frontswap_store+0xc9/0x2e0
   ? __frontswap_store+0xc9/0x2e0
   kasan_report+0x47/0x60
   kasan_check_range+0x2f3/0x340
   __kasan_check_read+0x11/0x20
   __frontswap_store+0xc9/0x2e0
   swap_writepage+0x52/0x80
   pageout+0x489/0x7f0
   shrink_page_list+0x1b11/0x2c90
   reclaim_pages+0x6ca/0x930
   madvise_cold_or_pageout_pte_range+0x1260/0x13a0

  Allocated by task 16813:
   kasan_kmalloc+0xb0/0xe0
   __kasan_kmalloc+0x9/0x10
   __kmalloc_node+0x52/0x70
   kvmalloc_node+0x50/0x90
   __se_sys_swapon+0x353a/0x4860
   __x64_sys_swapon+0x5b/0x70

  The buggy address belongs to the object at 88901f64
   which belongs to the cache kmalloc-32k of size 32768
  The buggy address is located 28440 bytes inside of
   32768-byte region [88901f64, 88901f648000)
  The buggy address belongs to the page:
  page:32d23e33 refcount:1 mapcount:0 mapping:
index:0x0 pfn:0x101f640
  head:32d23e33 order:4 compound_mapcount:0 compound_pincount:0
  flags: 0x4010200(slab|head)
  raw: 04010200 ea00062b8408 ea000a6e9008 888100040300
  raw:  88901f64 00010001 000
  page dumped because: kasan: bad access detected

Memory state around the buggy address:
   88901f646e00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
   88901f646e80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  >88901f646f00: 00 00 00 fc fc fc fc fc fc fc fc fc fc fc fc fc
  ^
   88901f646f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
   88901f647000: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
  ==

Relevant config options I could think of:

CONFIG_MEMCG_SWAP=y
CONFIG_THP_SWAP=y
CONFIG_ZSWAP=y

[PATCH V2 3/4] remoteproc: imx: move memory parsing to rproc_ops

[peng . fan]

From: Peng Fan 

Use the rproc_ops::prepare() hook for doing memory resources
reallocation when reattach an remote procesor.

Suggested-by: Mathieu Poirier 
Signed-off-by: Peng Fan 
---
 drivers/remoteproc/imx_rproc.c | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
index b05aae0ad7a2..7cd09971d1a4 100644
--- a/drivers/remoteproc/imx_rproc.c
+++ b/drivers/remoteproc/imx_rproc.c
@@ -317,7 +317,7 @@ static int imx_rproc_mem_release(struct rproc *rproc,
return 0;
 }
 
-static int imx_rproc_parse_memory_regions(struct rproc *rproc)
+static int imx_rproc_prepare(struct rproc *rproc)
 {
struct imx_rproc *priv = rproc->priv;
struct device_node *np = priv->dev->of_node;
@@ -363,10 +363,7 @@ static int imx_rproc_parse_memory_regions(struct rproc 
*rproc)
 
 static int imx_rproc_parse_fw(struct rproc *rproc, const struct firmware *fw)
 {
-   int ret = imx_rproc_parse_memory_regions(rproc);
-
-   if (ret)
-   return ret;
+   int ret;
 
ret = rproc_elf_load_rsc_table(rproc, fw);
if (ret)
@@ -399,6 +396,7 @@ static void imx_rproc_kick(struct rproc *rproc, int vqid)
 }
 
 static const struct rproc_ops imx_rproc_ops = {
+   .prepare= imx_rproc_prepare,
.start  = imx_rproc_start,
.stop   = imx_rproc_stop,
.kick   = imx_rproc_kick,
-- 
2.30.0

[PATCH V2 4/4] remoteproc: imx_rproc: support remote cores booted before Linux Kernel

[peng . fan]

From: Peng Fan 

 - Add rsc_table to hold the resource table published by remote cores.
 - Add attach hook.
 - Add imx_rproc_get_loaded_rsc_table to get resource table published by
   remote processors.
 - Add imx_rproc_detect_mode to detect remote cores' working mode.

Signed-off-by: Peng Fan 
---
 drivers/remoteproc/imx_rproc.c | 45 ++
 1 file changed, 45 insertions(+)

diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
index 7cd09971d1a4..d6338872c6db 100644
--- a/drivers/remoteproc/imx_rproc.c
+++ b/drivers/remoteproc/imx_rproc.c
@@ -95,6 +95,7 @@ struct imx_rproc {
struct mbox_chan*rx_ch;
struct work_struct  rproc_work;
struct workqueue_struct *workqueue;
+   void __iomem*rsc_table;
 };
 
 static const struct imx_rproc_att imx_rproc_att_imx8mq[] = {
@@ -395,8 +396,26 @@ static void imx_rproc_kick(struct rproc *rproc, int vqid)
__func__, vqid, err);
 }
 
+static int imx_rproc_attach(struct rproc *rproc)
+{
+   return 0;
+}
+
+static struct resource_table *imx_rproc_get_loaded_rsc_table(struct rproc 
*rproc, size_t *table_sz)
+{
+   struct imx_rproc *priv = rproc->priv;
+
+   /* The resource table has already been mapped in imx_rproc_addr_init */
+   if (!priv->rsc_table)
+   return NULL;
+
+   *table_sz = SZ_1K;
+   return (struct resource_table *)priv->rsc_table;
+}
+
 static const struct rproc_ops imx_rproc_ops = {
.prepare= imx_rproc_prepare,
+   .attach = imx_rproc_attach,
.start  = imx_rproc_start,
.stop   = imx_rproc_stop,
.kick   = imx_rproc_kick,
@@ -404,6 +423,7 @@ static const struct rproc_ops imx_rproc_ops = {
.load   = rproc_elf_load_segments,
.parse_fw   = imx_rproc_parse_fw,
.find_loaded_rsc_table = rproc_elf_find_loaded_rsc_table,
+   .get_loaded_rsc_table = imx_rproc_get_loaded_rsc_table,
.sanity_check   = rproc_elf_sanity_check,
.get_boot_addr  = rproc_elf_get_boot_addr,
 };
@@ -470,6 +490,8 @@ static int imx_rproc_addr_init(struct imx_rproc *priv,
}
priv->mem[b].sys_addr = res.start;
priv->mem[b].size = resource_size();
+   if (!strcmp(node->name, "rsc_table"))
+   priv->rsc_table = priv->mem[b].cpu_addr;
b++;
}
 
@@ -536,6 +558,25 @@ static void imx_rproc_free_mbox(struct rproc *rproc)
mbox_free_channel(priv->rx_ch);
 }
 
+static int imx_rproc_detect_mode(struct imx_rproc *priv)
+{
+   const struct imx_rproc_dcfg *dcfg = priv->dcfg;
+   struct device *dev = priv->dev;
+   int ret;
+   u32 val;
+
+   ret = regmap_read(priv->regmap, dcfg->src_reg, );
+   if (ret) {
+   dev_err(dev, "Failed to read src\n");
+   return ret;
+   }
+
+   if (!(val & dcfg->src_stop))
+   priv->rproc->state = RPROC_DETACHED;
+
+   return 0;
+}
+
 static int imx_rproc_probe(struct platform_device *pdev)
 {
struct device *dev = >dev;
@@ -590,6 +631,10 @@ static int imx_rproc_probe(struct platform_device *pdev)
goto err_put_mbox;
}
 
+   ret = imx_rproc_detect_mode(priv);
+   if (ret)
+   goto err_put_mbox;
+
priv->clk = devm_clk_get(dev, NULL);
if (IS_ERR(priv->clk)) {
dev_err(dev, "Failed to get clock\n");
-- 
2.30.0

[PATCH V2 1/4] remoteproc: imx: add missing of_node_put

[peng . fan]

From: Peng Fan 

After of_parse_phandle, we need of_node_put to decrease the refcount
of the device_node.

Reported-by: Mathieu Poirier 
Signed-off-by: Peng Fan 
---
 drivers/remoteproc/imx_rproc.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
index 6d3207ccbaef..077413319f58 100644
--- a/drivers/remoteproc/imx_rproc.c
+++ b/drivers/remoteproc/imx_rproc.c
@@ -459,6 +459,8 @@ static int imx_rproc_addr_init(struct imx_rproc *priv,
return err;
}
 
+   of_node_put(node);
+
if (b >= IMX7D_RPROC_MEM_MAX)
break;
 
-- 
2.30.0

[PATCH V2 2/4] remoteproc: imx_rproc: enlarge IMX7D_RPROC_MEM_MAX

[peng . fan]

From: Peng Fan 

8 is not enough when we need more, such as resource table for remote cores
that booted before Linux Kernel, so enlarge IMX7D_RPROC_MEM_MAX to 32.
And also rename it to IMX_RPROC_MEM_MAX which make more sense.

Signed-off-by: Peng Fan 
Reviewed-by: Mathieu Poirier 
---
 drivers/remoteproc/imx_rproc.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
index 077413319f58..b05aae0ad7a2 100644
--- a/drivers/remoteproc/imx_rproc.c
+++ b/drivers/remoteproc/imx_rproc.c
@@ -48,7 +48,7 @@
 | IMX6SX_SW_M4C_NON_SCLR_RST \
 | IMX6SX_SW_M4C_RST)
 
-#define IMX7D_RPROC_MEM_MAX8
+#define IMX_RPROC_MEM_MAX  32
 
 /**
  * struct imx_rproc_mem - slim internal memory structure
@@ -88,7 +88,7 @@ struct imx_rproc {
struct regmap   *regmap;
struct rproc*rproc;
const struct imx_rproc_dcfg *dcfg;
-   struct imx_rproc_memmem[IMX7D_RPROC_MEM_MAX];
+   struct imx_rproc_memmem[IMX_RPROC_MEM_MAX];
struct clk  *clk;
struct mbox_client  cl;
struct mbox_chan*tx_ch;
@@ -272,7 +272,7 @@ static void *imx_rproc_da_to_va(struct rproc *rproc, u64 
da, size_t len, bool *i
if (imx_rproc_da_to_sys(priv, da, len, ))
return NULL;
 
-   for (i = 0; i < IMX7D_RPROC_MEM_MAX; i++) {
+   for (i = 0; i < IMX_RPROC_MEM_MAX; i++) {
if (sys >= priv->mem[i].sys_addr && sys + len <
priv->mem[i].sys_addr +  priv->mem[i].size) {
unsigned int offset = sys - priv->mem[i].sys_addr;
@@ -425,7 +425,7 @@ static int imx_rproc_addr_init(struct imx_rproc *priv,
if (!(att->flags & ATT_OWN))
continue;
 
-   if (b >= IMX7D_RPROC_MEM_MAX)
+   if (b >= IMX_RPROC_MEM_MAX)
break;
 
priv->mem[b].cpu_addr = devm_ioremap(>dev,
@@ -461,7 +461,7 @@ static int imx_rproc_addr_init(struct imx_rproc *priv,
 
of_node_put(node);
 
-   if (b >= IMX7D_RPROC_MEM_MAX)
+   if (b >= IMX_RPROC_MEM_MAX)
break;
 
/* Not use resource version, because we might share region */
-- 
2.30.0

[PATCH V2 0/4] remoteproc: imx: support remote cores booted early

[peng . fan]

From: Peng Fan 

V2:
 Patch [1,3]/4 is new
 Patch 4/4: Update commit message, drop unneeded code that already implemented 
by core

This patchset is to support booted remote cores could be attached to linux.
- Add missing of_node_put to decrease device node refcount
- Enlarge IMX7D_RPROC_MEM_MAX because need more imx_rproc_mem, such as resource 
table.
- Following stm32 remoteproc practice, move memory parsing to rproc_ops
- Support attaching booted cores, by adding attach, get loaded resource table 
and etc.

Peng Fan (4):
  remoteproc: imx: add missing of_node_put
  remoteproc: imx_rproc: enlarge IMX7D_RPROC_MEM_MAX
  remoteproc: imx: move memory parsing to rproc_ops
  remoteproc: imx_rproc: support remote cores booted before Linux Kernel

 drivers/remoteproc/imx_rproc.c | 65 --
 1 file changed, 55 insertions(+), 10 deletions(-)

-- 
2.30.0

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

[Guenter Roeck]

On 3/29/21 8:16 PM, Jonas Malaco wrote:
> On Mon, Mar 29, 2021 at 06:01:00PM -0700, Guenter Roeck wrote:
>> On 3/29/21 5:21 PM, Jonas Malaco wrote:
>>> On Mon, Mar 29, 2021 at 02:53:39PM -0700, Guenter Roeck wrote:
 On Mon, Mar 29, 2021 at 05:22:01AM -0300, Jonas Malaco wrote:
> To avoid a spinlock, the driver explores concurrent memory accesses
> between _raw_event and _read, having the former updating fields on a
> data structure while the latter could be reading from them.  Because
> these are "plain" accesses, those are data races according to the Linux
> kernel memory model (LKMM).
>
> Data races are undefined behavior in both C11 and LKMM.  In practice,
> the compiler is free to make optimizations assuming there is no data
> race, including load tearing, load fusing and many others,[1] most of
> which could result in corruption of the values reported to user-space.
>
> Prevent undesirable optimizations to those concurrent accesses by
> marking them with READ_ONCE() and WRITE_ONCE().  This also removes the
> data races, according to the LKMM, because both loads and stores to each
> location are now "marked" accesses.
>
> As a special case, use smp_load_acquire() and smp_load_release() when
> loading and storing ->updated, as it is used to track the validity of
> the other values, and thus has to be stored after and loaded before
> them.  These imply READ_ONCE()/WRITE_ONCE() but also ensure the desired
> order of memory accesses.
>
> [1] https://lwn.net/Articles/793253/
>

 I think you lost me a bit there. What out-of-order accesses that would be
 triggered by a compiler optimization are you concerned about here ?
 The only "problem" I can think of is that priv->updated may have been
 written before the actual values. The impact would be ... zero. An
 attribute read would return "stale" data for a few microseconds.
 Why is that a concern, and what difference does it make ?
>>>
>>> The impact of out-of-order accesses to priv->updated is indeed minimal.
>>>
>>> That said, smp_load_acquire() and smp_store_release() were meant to
>>> prevent reordering at runtime, and only affect architectures other than
>>> x86.  READ_ONCE() and WRITE_ONCE() would already prevent reordering from
>>> compiler optimizations, and x86 provides the load-acquire/store-release
>>> semantics by default.
>>>
>>> But the reordering issue is not a concern to me, I got carried away when
>>> adding READ_ONCE()/WRITE_ONCE().  While smp_load_acquire() and
>>> smp_store_release() make the code work more like I intend it to, they
>>> are (small) costs we can spare.
>>>
>>> I still think that READ_ONCE()/WRITE_ONCE() are necessary, including for
>>> priv->updated.  Do you agree?
>>>
>>
>> No. What is the point ? The order of writes doesn't matter, the writes won't
>> be randomly dropped, and it doesn't matter if the reader reports old values
>> for a couple of microseconds either. This would be different if the values
>> were used as synchronization primitives or similar, but that isn't the case
>> here. As for priv->updated, if you are concerned about lost reports and
>> the 4th report is received a few microseconds before the read, I'd suggest
>> to loosen the interval a bit instead.
>>
>> Supposedly we are getting reports every 500ms. We have two situations:
>> - More than three reports are lost, making priv->updated somewhat relevant.
>>   In this case, it doesn't matter if outdated values are reported for
>>   a few uS since most/many/some reports are outdated more than a second
>>   anyway.
>> - A report is received but old values are reported for a few uS. That
>>   doesn't matter either because reports are always outdated anyway by
>>   much more than a few uS anyway, and the code already tolerates up to
>>   2 seconds of lost reports.
>>
>> Sorry, I completely fail to see the problem you are trying to solve here.
> 
> Please disregard the out-of-order accesses, I agree that preventing them
> "are a (small) cost we can spare".
> 
> The main problem I still would like to address are the data races.
> While the stores and loads cannot be dropped, and we can tolerate their
> reordering, they could still be teared, fused, perhaps invented...
> According to [1] these types of optimizations are not unheard.
> 
> Load tearing alone could easily produce values that are not stale, but
> wrong.  Do we also tolerate wrong values, even if they are infrequent?
> 
> Another detail I should have mentioned sooner is that READ_ONCE() and
> WRITE_ONCE() cause only minor (gcc) to no (clang) changes to the
> generated code for x86_64 and i386.[2]  While this seems contrary to the
> point I am trying to make, I want to show that, for the most part, these
> changes just lock in a reasonable compiler behavior.
> 
> Specifically, on x86_64/gcc (the most relevant arch/compiler for this
> driver) the changes are restricted to 

Re: [PATCH 5.10 000/219] 5.10.27-rc2 review

[Naresh Kamboju]

On Mon, 29 Mar 2021 at 15:44, Greg Kroah-Hartman
 wrote:
>
> This is the start of the stable review cycle for the 5.10.27 release.
> There are 219 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed, 31 Mar 2021 10:13:09 +.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> 
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.27-rc2.gz
> or in the git tree and branch at:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-5.10.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h

Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.

Tested-by: Linux Kernel Functional Testing 

Summary


kernel: 5.10.27-rc2
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-5.10.y
git commit: 8c8bcec351223764ccc3ab7551540172989b5194
git describe: v5.10.26-220-g8c8bcec35122
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.10.y/build/v5.10.26-220-g8c8bcec35122

No regressions (compared to build v5.10.26)

No fixes (compared to build v5.10.26)


Ran 65388 total tests in the following environments and test suites.

Environments
--
- arc
- arm
- arm64
- dragonboard-410c
- hi6220-hikey
- i386
- juno-r2
- juno-r2-compat
- juno-r2-kasan
- mips
- nxp-ls2088
- nxp-ls2088-64k_page_size
- parisc
- powerpc
- qemu-arm-clang
- qemu-arm-debug
- qemu-arm64-clang
- qemu-arm64-debug
- qemu-arm64-kasan
- qemu-i386-clang
- qemu-i386-debug
- qemu-x86_64-clang
- qemu-x86_64-debug
- qemu-x86_64-kasan
- qemu-x86_64-kcsan
- qemu_arm
- qemu_arm64
- qemu_arm64-compat
- qemu_i386
- qemu_x86_64
- qemu_x86_64-compat
- riscv
- s390
- sh
- sparc
- x15
- x86
- x86-kasan
- x86_64

Test Suites
---
* build
* linux-log-parser
* install-android-platform-tools-r2600
* kselftest-timens
* kselftest-timers
* kselftest-tmpfs
* kselftest-tpm2
* kselftest-user
* kselftest-zram
* kvm-unit-tests
* ltp-commands-tests
* ltp-containers-tests
* ltp-cve-tests
* ltp-fs-tests
* ltp-math-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-tracing-tests
* v4l2-compliance
* fwts
* kselftest-intel_pstate
* kselftest-kvm
* kselftest-livepatch
* kselftest-ptrace
* kselftest-rseq
* kselftest-rtc
* kselftest-seccomp
* kselftest-sigaltstack
* kselftest-size
* kselftest-splice
* kselftest-static_keys
* kselftest-sync
* kselftest-sysctl
* libhugetlbfs
* ltp-cap_bounds-tests
* ltp-cpuhotplug-tests
* ltp-crypto-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-mm-tests
* ltp-sched-tests
* network-basic-tests
* perf
* kselftest-
* kselftest-android
* kselftest-bpf
* kselftest-capabilities
* kselftest-cgroup
* kselftest-clone3
* kselftest-core
* kselftest-cpu-hotplug
* kselftest-cpufreq
* kselftest-efivarfs
* kselftest-filesystems
* kselftest-firmware
* kselftest-fpu
* kselftest-futex
* kselftest-gpio
* kselftest-ipc
* kselftest-ir
* kselftest-kcmp
* kselftest-kexec
* kselftest-lib
* kselftest-lkdtm
* kselftest-membarrier
* kselftest-memfd
* kselftest-memory-hotplug
* kselftest-mincore
* kselftest-mount
* kselftest-mqueue
* kselftest-net
* kselftest-netfilter
* kselftest-nsfs
* kselftest-openat2
* kselftest-pid_namespace
* kselftest-pidfd
* kselftest-proc
* kselftest-pstore
* kselftest-tc-testing
* kselftest-vm
* kselftest-x86
* ltp-controllers-tests
* ltp-dio-tests
* ltp-open-posix-tests
* kunit
* rcutorture
* kselftest-vsyscall-mode-native-
* kselftest-vsyscall-mode-none-
* ssuite

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

Re: [PATCH] hwmon: Add driver for fsp-3y PSUs and PDUs

[Guenter Roeck]

On 3/29/21 8:31 PM, Václav Kubernát wrote:
> Hi Guenter,
> 
> Thank you for the review.
> 
> po 29. 3. 2021 v 19:47 odesílatel Guenter Roeck  napsal:
>>
>> On 3/29/21 7:38 AM, Václav Kubernát wrote:
>>> After some testing, I have found out there is a timing issue with this
>>> device. After setting page, the device doesn't immediately react and
>>> gives values from the previous page for some time. This is why there
>>> needs to be a delay between pmbus_set_page and the actual read.
>>>
>>> Also, a lot of the standard commands don't work with the devices, so
>>> they are filtered out in the custom read function.
>>>
>>
>> This is not an appropriate patch description. Describe the driver here,
>> not the workarounds / quirks. The reason for the delay should be a
>> comment in the patch, not in the patch description.
>>
>> Also, "don't work" is inappropriate (and, again, does not belong into
>> the patch description). It is perfectly appropriate for the core
>> to try those commands to see if they are supported. The only reason
>> to mask them out would be that the device reacts badly to seeing
>> them. If that is the case, "don't work" should be replaced with
>> a more detailed comment in the code. Describe what happens, and why
>> the commands needs to be caught.
>>
>>
>> What might be useful is a note indicating if you have a manual for
>> those power supplies available, or if the driver is based on reverse
>> engineering.
>>
> 
> I will rework the commit message in a V2 patch.
> 
>>> Signed-off-by: Václav Kubernát 
>>> ---
>>>  drivers/hwmon/pmbus/Kconfig  |   9 ++
>>>  drivers/hwmon/pmbus/Makefile |   1 +
>>>  drivers/hwmon/pmbus/fsp-3y.c | 164 +++
>>
>> Documentation/hwmon/fsp-3y.rst is missing.
>>
>>>  3 files changed, 174 insertions(+)
>>>  create mode 100644 drivers/hwmon/pmbus/fsp-3y.c
>>>
>>> diff --git a/drivers/hwmon/pmbus/Kconfig b/drivers/hwmon/pmbus/Kconfig
>>> index 03606d4298a4..66d1655b6750 100644
>>> --- a/drivers/hwmon/pmbus/Kconfig
>>> +++ b/drivers/hwmon/pmbus/Kconfig
>>> @@ -56,6 +56,15 @@ config SENSORS_BEL_PFE
>>> This driver can also be built as a module. If so, the module will
>>> be called bel-pfe.
>>>
>>> +config SENSORS_FSP_3Y
>>> + tristate "FSP/3Y-Power power supplies"
>>> + help
>>> +   If you say yes here you get hardware monitoring support for
>>> +   FSP/3Y-Power hot-swap power supplies.
>>> +
>>
>> This should list the supported models - if not here, then at least in the
>> (missing) documentation.
>>
> 
> Okay.
> 
>>> +   This driver can also be built as a module. If so, the module will
>>> +   be called fsp-3y.
>>> +
>>>  config SENSORS_IBM_CFFPS
>>>   tristate "IBM Common Form Factor Power Supply"
>>>   depends on LEDS_CLASS
>>> diff --git a/drivers/hwmon/pmbus/Makefile b/drivers/hwmon/pmbus/Makefile
>>> index 6a4ba0fdc1db..bfe218ad898f 100644
>>> --- a/drivers/hwmon/pmbus/Makefile
>>> +++ b/drivers/hwmon/pmbus/Makefile
>>> @@ -8,6 +8,7 @@ obj-$(CONFIG_SENSORS_PMBUS)   += pmbus.o
>>>  obj-$(CONFIG_SENSORS_ADM1266)+= adm1266.o
>>>  obj-$(CONFIG_SENSORS_ADM1275)+= adm1275.o
>>>  obj-$(CONFIG_SENSORS_BEL_PFE)+= bel-pfe.o
>>> +obj-$(CONFIG_SENSORS_FSP_3Y) += fsp-3y.o
>>>  obj-$(CONFIG_SENSORS_IBM_CFFPS)  += ibm-cffps.o
>>>  obj-$(CONFIG_SENSORS_INSPUR_IPSPS) += inspur-ipsps.o
>>>  obj-$(CONFIG_SENSORS_IR35221)+= ir35221.o
>>> diff --git a/drivers/hwmon/pmbus/fsp-3y.c b/drivers/hwmon/pmbus/fsp-3y.c
>>> new file mode 100644
>>> index ..7f3c3de3a1e6
>>> --- /dev/null
>>> +++ b/drivers/hwmon/pmbus/fsp-3y.c
>>> @@ -0,0 +1,164 @@
>>> +// SPDX-License-Identifier: GPL-2.0-or-later
>>> +/*
>>> + * Hardware monitoring driver for FSP 3Y-Power PSUs
>>> + *
>>> + * Copyright (c) 2021 Václav Kubernát, CESNET
>>> + */
>>> +
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>
>> Alphabetic include file order, please.
>>
>>> +#include "pmbus.h"
>>> +
>>> +#define YM2151_PAGE_12V  0x00
>>> +#define YM2151_PAGE_5V   0x20
>>> +#define YH5151E_PAGE_12V 0x00
>>> +#define YH5151E_PAGE_5V  0x10
>>> +#define YH5151E_PAGE_3V3 0x11
>>> +
>>> +enum chips {
>>> + ym2151e,
>>> + yh5151e
>>> +};
>>> +
>>> +static int set_page(struct i2c_client *client, int page)
>>> +{
>>> + int rv;
>>> +
>>> + rv = i2c_smbus_read_byte_data(client, PMBUS_PAGE);
>>> +
>> Please no empty line here.
>>
>> You might want to consider caching the current page to avoid having to read 
>> it
>> for each access, similar to the code implemented in the pmbus core.
>>
> 
> This was actually what I wanted to do at first, but I wasn't able to
> get i2c_set_clientdata to work. Later I found out that it is because
> pmbus_do_probe uses sets it own data. What do you think I should use
> to cache the page?
> 

Several other PMBus drivers use local data. The trick is to put
the pmbus_driver_info data structure into that local data, then use

Re: [PATCH] ARM: Qualify enabling of swiotlb_init()

[Christoph Hellwig]

On Mon, Mar 29, 2021 at 12:30:42PM -0700, Florian Fainelli wrote:
> Should I toss this in Russell's patch tracker or do you need me to make
> some changes to the patch?

Due to all the other changes in this area I don't think anything but
the swiotlb tree makes much sense here.

Re: [PATCH v2] Documentation: crypto: add info about "fips=" boot option

[Eric Biggers]

On Mon, Mar 29, 2021 at 10:06:51PM -0700, Randy Dunlap wrote:
> Having just seen a report of using "fips=1" on the kernel command line,
> I could not find it documented anywhere, so add some help for it.
> 
> Signed-off-by: Randy Dunlap 
> Cc: Dexuan Cui 
> Cc: linux-cry...@vger.kernel.org
> Cc: Eric Biggers 
> Cc: Herbert Xu 
> Cc: "David S. Miller" 
> Cc: Jonathan Corbet 
> Cc: linux-...@vger.kernel.org
> ---
> Updates/corrections welcome.
> 
> v2: drop comment that "fips_enabled can cause some tests to be skipped".
> 
>  Documentation/admin-guide/kernel-parameters.txt |   14 ++
>  1 file changed, 14 insertions(+)
> 
> --- linux-next-20210329.orig/Documentation/admin-guide/kernel-parameters.txt
> +++ linux-next-20210329/Documentation/admin-guide/kernel-parameters.txt
> @@ -1370,6 +1370,20 @@
>   See Documentation/admin-guide/sysctl/net.rst for
>   fb_tunnels_only_for_init_ns
>  
> + fips=   Format: { 0 | 1}
> + Use to disable (0) or enable (1) FIPS mode.
> + If enabled, any process that is waiting on the
> + 'fips_fail_notif_chain' will be notified of fips
> + failures.
> + This setting can also be modified via sysctl at
> + /proc/sysctl/crypto/fips_enabled, i.e.,
> + crypto.fips_enabled.
> + If fips_enabled = 1 and a test fails, it will cause a
> + kernel panic.
> + If fips_enabled = 1, RSA test requires a key size of
> + 2K or larger.
> + It can also effect which ECC curve is used.

This doesn't really explain why anyone would want to give this option.
What high-level thing is this option meant to be accomplishing?
That's what the documentation should explain.

- Eric

[PATCH] sched/fair: use signed long when compute energy delta in eas

[Xuewen Yan]

From: Xuewen Yan 

now the energy delta compute as follow:

base_energy_pd = compute_energy(p, -1, pd);
--->Traverse all CPUs in pd
--->em_pd_energy()
- \
search for the max_sapre_cap_cpu   \
-   search time
cur_delta = compute_energy(p, max_spare_cap_cpu, pd);  /
--->Traverse all CPUs in pd   /
 /
--->em_pd_energy()
cur_delta -= base_energy_pd;

During the search_time, or when calculate the cpu_util in
compute_energy(), there may occurred task dequeue or cpu_util change,
it may cause the cur_energy < base_energy_pd, so the cur_delta
would be negative. But the cur_delta is unsigned long, at this time,
the cur_delta would always bigger than best_delta of last pd.

Change the vars to signed long.

Signed-off-by: Xuewen Yan 
---
 kernel/sched/fair.c | 31 +--
 1 file changed, 17 insertions(+), 14 deletions(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 794c2cb945f8..310d9d215cd7 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -6586,7 +6586,7 @@ compute_energy(struct task_struct *p, int dst_cpu, struct 
perf_domain *pd)
  */
 static int find_energy_efficient_cpu(struct task_struct *p, int prev_cpu)
 {
-   unsigned long prev_delta = ULONG_MAX, best_delta = ULONG_MAX;
+   long prev_delta = LONG_MAX, best_delta = LONG_MAX;
struct root_domain *rd = cpu_rq(smp_processor_id())->rd;
unsigned long cpu_cap, util, base_energy = 0;
int cpu, best_energy_cpu = prev_cpu;
@@ -6613,13 +6613,11 @@ static int find_energy_efficient_cpu(struct task_struct 
*p, int prev_cpu)
goto unlock;
 
for (; pd; pd = pd->next) {
-   unsigned long cur_delta, spare_cap, max_spare_cap = 0;
+   long cur_delta;
+   unsigned long spare_cap, max_spare_cap = 0;
unsigned long base_energy_pd;
int max_spare_cap_cpu = -1;
-
-   /* Compute the 'base' energy of the pd, without @p */
-   base_energy_pd = compute_energy(p, -1, pd);
-   base_energy += base_energy_pd;
+   bool prev_in_pd = false;
 
for_each_cpu_and(cpu, perf_domain_span(pd), 
sched_domain_span(sd)) {
if (!cpumask_test_cpu(cpu, p->cpus_ptr))
@@ -6641,13 +6639,8 @@ static int find_energy_efficient_cpu(struct task_struct 
*p, int prev_cpu)
if (!fits_capacity(util, cpu_cap))
continue;
 
-   /* Always use prev_cpu as a candidate. */
-   if (cpu == prev_cpu) {
-   prev_delta = compute_energy(p, prev_cpu, pd);
-   prev_delta -= base_energy_pd;
-   best_delta = min(best_delta, prev_delta);
-   }
-
+   if (cpu == prev_cpu)
+   prev_in_pd = true;
/*
 * Find the CPU with the maximum spare capacity in
 * the performance domain
@@ -6658,6 +6651,16 @@ static int find_energy_efficient_cpu(struct task_struct 
*p, int prev_cpu)
}
}
 
+   /* Compute the 'base' energy of the pd, without @p */
+   base_energy_pd = compute_energy(p, -1, pd);
+   base_energy += base_energy_pd;
+
+   /* Always use prev_cpu as a candidate. */
+   if (prev_in_pd) {
+   prev_delta = compute_energy(p, prev_cpu, pd);
+   prev_delta -= base_energy_pd;
+   best_delta = min(best_delta, prev_delta);
+   }
/* Evaluate the energy impact of using this CPU. */
if (max_spare_cap_cpu >= 0 && max_spare_cap_cpu != prev_cpu) {
cur_delta = compute_energy(p, max_spare_cap_cpu, pd);
@@ -6675,7 +6678,7 @@ static int find_energy_efficient_cpu(struct task_struct 
*p, int prev_cpu)
 * Pick the best CPU if prev_cpu cannot be used, or if it saves at
 * least 6% of the energy used by prev_cpu.
 */
-   if (prev_delta == ULONG_MAX)
+   if (prev_delta == LONG_MAX)
return best_energy_cpu;
 
if ((prev_delta - best_delta) > ((prev_delta + base_energy) >> 4))
-- 
2.29.0

[PATCH v1 3/4] arm64: dts: add DRAMC node for MT6779

[Po-Kai Chi]

Add the DRAMC node for the DRAMC kernel driver.

Properties are divided into three categories:
  - Platform DTS:
  MediaTek DRAMC platform common part.

  - Project DTS:
  Runtime filled in by bootloader according to the board
  hardware configuration.

  - Driver level:
  Hardware-specific register settings, encapsulated as
  compatible data for better DTS compatibility.

Signed-off-by: Po-Kai Chi 
---
 arch/arm64/boot/dts/mediatek/mt6779-evb.dts |9 +
 arch/arm64/boot/dts/mediatek/mt6779.dtsi|   18 ++
 2 files changed, 27 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt6779-evb.dts 
b/arch/arm64/boot/dts/mediatek/mt6779-evb.dts
index 164f5cb..9a556ad 100644
--- a/arch/arm64/boot/dts/mediatek/mt6779-evb.dts
+++ b/arch/arm64/boot/dts/mediatek/mt6779-evb.dts
@@ -29,3 +29,12 @@
  {
status = "okay";
 };
+
+ {
+   dram_type = <0>;
+   channel_cnt = <2>;
+   rank_cnt = <2>;
+   rank_size = <0x0 0x0>;
+   mr_cnt = <1>;
+   mr = <0x5 0xff>;
+};
diff --git a/arch/arm64/boot/dts/mediatek/mt6779.dtsi 
b/arch/arm64/boot/dts/mediatek/mt6779.dtsi
index 9bdf514..332d48d 100644
--- a/arch/arm64/boot/dts/mediatek/mt6779.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt6779.dtsi
@@ -206,6 +206,24 @@
clock-names = "devapc-infra-clock";
};
 
+   dramc: dramc@1023 {
+   compatible = "mediatek,mt6779-dramc";
+   reg = <0 0x1023 0 0x2000>, /* DRAMC AO CHA */
+   <0 0x1024 0 0x2000>, /* DRAMC AO CHB */
+   <0 0x10234000 0 0x1000>, /* DRAMC NAO CHA */
+   <0 0x10244000 0 0x1000>, /* DRAMC NAO CHB */
+   <0 0x10238000 0 0x2000>, /* DDRPHY AO CHA */
+   <0 0x10248000 0 0x2000>; /* DDRPHY AO CHB */
+   support_channel_cnt = <2>;
+   freq_cnt = <6>;
+   freq_step = <3718 3733>,
+   <3094 3200>,
+   <2392 2400>,
+   <1534 1600>,
+   <1196 1200>,
+   <754 800>;
+   };
+
uart0: serial@11002000 {
compatible = "mediatek,mt6779-uart",
 "mediatek,mt6577-uart";
-- 
1.7.9.5

[PATCH v1 4/4] arm64: defconfig: Enable MediaTek DRAMC common driver

[Po-Kai Chi]

This commit enables MediaTek DRAMC common driver to be built
as a module by default for the ARM64 builds.

Signed-off-by: Po-Kai Chi 
---
 arch/arm64/configs/defconfig |1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index d612f63..49d7464 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -1163,3 +1163,4 @@ CONFIG_DEBUG_KERNEL=y
 # CONFIG_DEBUG_PREEMPT is not set
 # CONFIG_FTRACE is not set
 CONFIG_MEMTEST=y
+CONFIG_MTK_DRAMC=m
-- 
1.7.9.5

[PATCH v1 2/4] memory: mediatek: add DRAM controller driver

[Po-Kai Chi]

MediaTek DRAM controller (DRAMC) driver provides cross-platform features
as below:
  - API provided to other kernel modules for querying DRAM type,
rank count, rank size, channel count and mode register settings.
  - Sysfs interface used to pass DRAM mode register settings and current
DRAM data rate to user-space for MediaTek ecosystem.

Signed-off-by: Po-Kai Chi 
---
 drivers/memory/Kconfig  |1 +
 drivers/memory/Makefile |1 +
 drivers/memory/mediatek/Kconfig |9 +
 drivers/memory/mediatek/Makefile|3 +
 drivers/memory/mediatek/mtk-dramc.c |  711 +++
 include/memory/mediatek/dramc.h |   18 +
 6 files changed, 743 insertions(+)
 create mode 100644 drivers/memory/mediatek/Kconfig
 create mode 100644 drivers/memory/mediatek/Makefile
 create mode 100644 drivers/memory/mediatek/mtk-dramc.c
 create mode 100644 include/memory/mediatek/dramc.h

diff --git a/drivers/memory/Kconfig b/drivers/memory/Kconfig
index 72c0df1..056e906 100644
--- a/drivers/memory/Kconfig
+++ b/drivers/memory/Kconfig
@@ -225,6 +225,7 @@ config STM32_FMC2_EBI
  devices (like SRAM, ethernet adapters, FPGAs, LCD displays, ...) on
  SOCs containing the FMC2 External Bus Interface.
 
+source "drivers/memory/mediatek/Kconfig"
 source "drivers/memory/samsung/Kconfig"
 source "drivers/memory/tegra/Kconfig"
 
diff --git a/drivers/memory/Makefile b/drivers/memory/Makefile
index bc7663e..cd4f8cf 100644
--- a/drivers/memory/Makefile
+++ b/drivers/memory/Makefile
@@ -25,6 +25,7 @@ obj-$(CONFIG_PL353_SMC)   += pl353-smc.o
 obj-$(CONFIG_RENESAS_RPCIF)+= renesas-rpc-if.o
 obj-$(CONFIG_STM32_FMC2_EBI)   += stm32-fmc2-ebi.o
 
+obj-$(CONFIG_MTK_DRAMC)+= mediatek/
 obj-$(CONFIG_SAMSUNG_MC)   += samsung/
 obj-$(CONFIG_TEGRA_MC) += tegra/
 obj-$(CONFIG_TI_EMIF_SRAM) += ti-emif-sram.o
diff --git a/drivers/memory/mediatek/Kconfig b/drivers/memory/mediatek/Kconfig
new file mode 100644
index 000..a1618b0
--- /dev/null
+++ b/drivers/memory/mediatek/Kconfig
@@ -0,0 +1,9 @@
+# SPDX-License-Identifier: GPL-2.0
+
+config MTK_DRAMC
+   tristate "MediaTek DRAMC driver"
+   help
+ This selects the MediaTek(R) DRAMC driver.
+ Provide the API for DRAMC low power scenario, and the interface
+ for reporting DRAM information, e.g. DRAM mode register (MR) for
+ DRAM vendor ID, temperature, and density.
diff --git a/drivers/memory/mediatek/Makefile b/drivers/memory/mediatek/Makefile
new file mode 100644
index 000..632be48
--- /dev/null
+++ b/drivers/memory/mediatek/Makefile
@@ -0,0 +1,3 @@
+# SPDX-License-Identifier: GPL-2.0
+
+obj-$(CONFIG_MTK_DRAMC)+= mtk-dramc.o
diff --git a/drivers/memory/mediatek/mtk-dramc.c 
b/drivers/memory/mediatek/mtk-dramc.c
new file mode 100644
index 000..d81d311
--- /dev/null
+++ b/drivers/memory/mediatek/mtk-dramc.c
@@ -0,0 +1,711 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2021 MediaTek Inc.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DRAMC_DRV_NAME "mtk-dramc"
+
+struct mr_info_t {
+   unsigned int mr_index;
+   unsigned int mr_value;
+};
+
+/*
+ * struct reg_ctrl_t - to describe the bits required in a register
+ * @offset: register address offset from a base
+ * @mask: bitmask of the target bits
+ * @shift: starting bit of the target bits
+ */
+struct reg_ctrl_t {
+   unsigned int offset;
+   unsigned int mask;
+   unsigned int shift;
+};
+
+struct fmeter_dev_t {
+   unsigned int crystal_freq;
+   unsigned int shu_of;
+   struct reg_ctrl_t shu_lv;
+   struct reg_ctrl_t pll_id;
+   struct reg_ctrl_t pll_md[2];
+   struct reg_ctrl_t sdmpcw[2];
+   struct reg_ctrl_t prediv[2];
+   struct reg_ctrl_t posdiv[2];
+   struct reg_ctrl_t ckdiv4[2];
+   struct reg_ctrl_t cldiv2[2];
+   struct reg_ctrl_t fbksel[2];
+   struct reg_ctrl_t dqopen[2];
+};
+
+struct mr4_dev_t {
+   struct reg_ctrl_t mr4_rg;
+};
+
+struct dramc_dev_t {
+   unsigned int dram_type;
+   unsigned int support_channel_cnt;
+   unsigned int channel_cnt;
+   unsigned int rank_cnt;
+   unsigned int mr_cnt;
+   unsigned int freq_cnt;
+   unsigned int *rank_size;
+   unsigned int *freq_step;
+   struct mr_info_t *mr_info_ptr;
+   void __iomem **dramc_chn_base_ao;
+   void __iomem **dramc_chn_base_nao;
+   void __iomem **ddrphy_chn_base_ao;
+   void *mr4_dev_ptr;
+   void *fmeter_dev_ptr;
+};
+
+enum DRAM_TYPE {
+   TYPE_NONE = 0,
+   TYPE_DDR1,
+   TYPE_LPDDR2,
+   TYPE_LPDDR3,
+   TYPE_PCDDR3,
+   TYPE_LPDDR4,
+   TYPE_LPDDR4X,
+   TYPE_LPDDR4P
+};
+
+static const struct fmeter_dev_t fmeter_v0_mt6779_t = {
+   .crystal_freq = 52,
+   .shu_of = 0x500,
+   .shu_lv = { .offset = 0x00e4, .mask = 

[PATCH v1 1/4] dt-bindings: memory: Add binding for MediaTek Common DRAM Controller

[Po-Kai Chi]

This patch adds the documentation of the device-tree binding for
MediaTek Common DRAM Controller.

Signed-off-by: Po-Kai Chi 
---
 .../memory-controllers/mediatek,dramc.yaml |  155 
 1 file changed, 155 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/memory-controllers/mediatek,dramc.yaml

diff --git 
a/Documentation/devicetree/bindings/memory-controllers/mediatek,dramc.yaml 
b/Documentation/devicetree/bindings/memory-controllers/mediatek,dramc.yaml
new file mode 100644
index 000..0217ce0
--- /dev/null
+++ b/Documentation/devicetree/bindings/memory-controllers/mediatek,dramc.yaml
@@ -0,0 +1,155 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (c) 2021 MediaTek Inc.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/memory-controllers/mediatek,dramc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek DRAM Controller
+
+maintainers:
+  - Po-Kai Chi 
+
+description: |
+  MediaTek DRAM controller (DRAMC) provides an interface to query information
+  about DRAM which collected from bootloader and device tree.
+  This is mainly used by MediaTek Extended Memory Interface (EMI) and DVFS 
Resource
+  Control (DVFSRC).
+
+properties:
+  compatible:
+items:
+  - enum:
+  - mediatek,mt6779-dramc
+
+  reg:
+description:
+  Base address of MediaTek DRAM related hardware modules, each channel has
+  its own base address in order of
+  DRAMC_AO_{CH}, DRAMC_NAO_{CH}, DDRPHY_AO_{CH}.
+minItems: 3# 3 * N channels
+maxItems: 6
+
+  dram_type:
+description:
+  The DRAM type of current DRAM chip.
+  This property is filled in by bootloader according to the board hardware
+  configuration.
+$ref: /schemas/types.yaml#/definitions/uint32
+minimum: 0
+maximum: 7
+
+  support_channel_cnt:
+description:
+  The maximum DRAM channel count supported by SoC.
+$ref: /schemas/types.yaml#/definitions/uint32
+minimum: 1
+maximum: 4
+
+  channel_cnt:
+description:
+  The DRAM channel count of current DRAM chip.
+  This property is filled in by bootloader according to the board hardware
+  configuration.
+$ref: /schemas/types.yaml#/definitions/uint32
+minimum: 1
+maximum: 4
+
+  rank_cnt:
+description:
+  The DRAM rank count of current DRAM chip.
+  This property is filled in by bootloader according to the board hardware
+  configuration.
+$ref: /schemas/types.yaml#/definitions/uint32
+minimum: 1
+maximum: 2
+
+  rank_size:
+description:
+  The size of each DRAM rank.
+  This property is filled in by bootloader according to the board hardware
+  configuration.
+$ref: /schemas/types.yaml#/definitions/uint64
+minItems: 1
+maxItems: 2
+items:
+  minimum: 0x0
+  maximum: 0x1# support up to 4GB in single rank
+
+  mr_cnt:
+description:
+  Specifies how many sets of DRAM mode register information to provide.
+  This property is filled in by bootloader according to the board hardware
+  configuration.
+$ref: /schemas/types.yaml#/definitions/uint32
+maximum: 40# total 40 MRs for JEDEC LPDDR4X
+
+  mr:
+description:
+  Pair of DRAM mode register information.
+  This property is filled in by bootloader according to the board hardware
+  configuration.
+$ref: /schemas/types.yaml#/definitions/uint32-matrix
+maxItems: 40# align with mr_cnt
+items:
+  items:
+- description:
+Mode register index
+- description:
+Mode register value
+
+  freq_cnt:
+description:
+  Specifies how many sets of DRAM data clock rate supported by SoC.
+$ref: /schemas/types.yaml#/definitions/uint32
+
+  freq_step:
+description:
+  The DRAM data clock rate may be slightly different from those defined
+  by the specification due to errors in multiples of the base frequency.
+  This describe the mapping from real data clock rate measured by
+  frequency meter to JEDEC data clock rate.
+$ref: /schemas/types.yaml#/definitions/uint32-matrix
+items:
+  items:
+- description:
+Real data rate
+- description:
+Spec data rate
+
+required:
+  - compatible
+  - reg
+  - dram_type
+  - support_channel_cnt
+  - channel_cnt
+  - rank_cnt
+  - mr_cnt
+  - freq_cnt
+
+additionalProperties: false
+
+examples:
+  - |
+dramc@1023 {
+compatible = "mediatek,mt6779-dramc";
+reg = <0 0x1023 0 0x2000>, /* DRAMC AO CHA */
+<0 0x1024 0 0x2000>,   /* DRAMC AO CHB */
+<0 0x10234000 0 0x1000>,   /* DRAMC NAO CHA */
+<0 0x10244000 0 0x1000>,   /* DRAMC NAO CHB */
+<0 0x10238000 0 0x2000>,   /* DDRPHY AO CHA */
+<0 0x10248000 0 0x2000>;   /* DDRPHY AO CHB */
+dram_type = <0>;
+support_channel_cnt = <2>;
+

[PATCH v1] memory: mediatek: add DRAM controller driver

[Po-Kai Chi]

These patch series introduces the MediaTek DRAM controller driver (DRAMC)
on MT6779 SoC, and enables to be built as a module by default for the
ARM64 builds.

MediaTek DRAMC driver provides cross-platform features as below:
  - API provided to other kernel modules for querying DRAM type,
rank count, rank size, channel count and mode register settings.
  - Sysfs interface used to pass DRAM mode register settings and current
DRAM data rate to user-space for MediaTek ecosystem.

The API user includes MediaTek External Memory Interface (EMI) and
DVFS Resource Control (DVFSRC), which will be sent to mainline later.

Re: [PATCH v3] kernel/resource: Fix locking in request_free_mem_region

[John Hubbard]

On 3/29/21 9:59 PM, Alistair Popple wrote:
...

res->desc = IORES_DESC_DEVICE_PRIVATE_MEMORY;
+   if (dev) {
+   dr->parent = _resource;
+   dr->start = addr;
+   dr->n = size;
+   devres_add(dev, dr);
+   }
+
+   write_unlock(_lock);
+   revoke_iomem(res);


This is new, and not mentioned in the commit log, and therefore quite
surprising. It seems like the right thing to do but it also seems like a
different fix! I'm not saying that it should be a separate patch, but it
does seem worth loudly mentioning in the commit log, yes?


This isn't a different fix though, it is just about maintaining the original
behaviour which called revoke_iomem() after dropping the lock. I inadvertently
switched this around in the initial patch such that revoke_iomem() got called
with the lock, leading to deadlock on x86 with CONFIG_IO_STRICT_DEVMEM=y.

This does change the order of revoke_iomem() and devres_add() slightly, but as
far as I can tell that shouldn't be an issue. Can call that out in the commit
log.


Maybe that's why it looked like a change to me. I do think it's worth 
mentioning.


thanks,
--
John Hubbard
NVIDIA

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

[Andy Lutomirski]

On Mon, Mar 29, 2021 at 3:38 PM Len Brown  wrote:
>
> On Mon, Mar 29, 2021 at 2:16 PM Andy Lutomirski  wrote:
> >

> Hi Andy,
>
> Can you provide a concise definition of the exact problemI(s) this thread
> is attempting to address?

The AVX-512 state, all by itself, is more than 2048 bytes.  Quoting
the POSIX sigaltstack page (man 3p sigaltstack):

   The  value  SIGSTKSZ is a system default specifying the number of bytes
   that would be used to cover the usual case when manually allocating  an
   alternate  stack area. The value MINSIGSTKSZ is defined to be the mini‐
   mum stack size for a signal handler. In computing  an  alternate  stack
   size, a program should add that amount to its stack requirements to al‐
   low for the system implementation overhead. The  constants  SS_ONSTACK,
   SS_DISABLE, SIGSTKSZ, and MINSIGSTKSZ are defined in .

arch/x86/include/uapi/asm/signal.h:#define MINSIGSTKSZ2048
arch/x86/include/uapi/asm/signal.h:#define SIGSTKSZ8192

Regrettably, the Linux signal frame format is the uncompacted format
and, also regrettably, the uncompacted format has the nasty property
that its format depends on XCR0 but not on the set of registers that
are actually used or wanted, so, with the current ABI, the signal
frame is stuck being quite large for all programs on a machine that
supports avx512 and has it enabled by the kernel.  And it's even
larger for AMX and violates SIGSTKSZ as well as MINSTKSZ.

There are apparently real programs that break as a result.  We need to
find a way to handle new, large extended states without breaking user
ABI.  We should also find a way to handle them without consuming silly
amounts of stack space for programs that don't use them.

Sadly, if the solution we settle on involves context switching XCR0,
performance on first-generation hardware will suffer because VMX does
not have any way to allow guests to write XCR0 without exiting.  I
don't consider this to be a showstopper -- if we end up having this
problem, fixing it in subsequent CPUs is straightforward.

>
> Thank ahead-of-time for excluding "blow up power consumption",
> since that paranoia is not grounded in fact.
>

I will gladly exclude power consumption from this discussion, since
that's a separate issue that has nothing to do with the user<->kernel
ABI.

Re: [PATCH] riscv: Bump COMMAND_LINE_SIZE value to 1024

[Palmer Dabbelt]

On Tue, 16 Mar 2021 12:34:20 PDT (-0700), a...@ghiti.fr wrote:

Increase COMMAND_LINE_SIZE as the current default value is too low
for syzbot kernel command line.

Reported-by: Dmitry Vyukov 
Signed-off-by: Alexandre Ghiti 
---
 arch/riscv/include/uapi/asm/setup.h | 8 
 1 file changed, 8 insertions(+)
 create mode 100644 arch/riscv/include/uapi/asm/setup.h

diff --git a/arch/riscv/include/uapi/asm/setup.h 
b/arch/riscv/include/uapi/asm/setup.h
new file mode 100644
index ..66b13a522880
--- /dev/null
+++ b/arch/riscv/include/uapi/asm/setup.h
@@ -0,0 +1,8 @@
+/* SPDX-License-Identifier: GPL-2.0-only WITH Linux-syscall-note */
+
+#ifndef _UAPI_ASM_RISCV_SETUP_H
+#define _UAPI_ASM_RISCV_SETUP_H
+
+#define COMMAND_LINE_SIZE  1024
+
+#endif /* _UAPI_ASM_RISCV_SETUP_H */


I put this on fixes, but it seemes like this should really be a Kconfig 
enttry.  Either way, ours was quite a bit smaller than most 
architectures and it's great that syzbot has started to find bugs, so 
I'd rather get this in sooner.

[PATCH v2] Documentation: crypto: add info about "fips=" boot option

[Randy Dunlap]

Having just seen a report of using "fips=1" on the kernel command line,
I could not find it documented anywhere, so add some help for it.

Signed-off-by: Randy Dunlap 
Cc: Dexuan Cui 
Cc: linux-cry...@vger.kernel.org
Cc: Eric Biggers 
Cc: Herbert Xu 
Cc: "David S. Miller" 
Cc: Jonathan Corbet 
Cc: linux-...@vger.kernel.org
---
Updates/corrections welcome.

v2: drop comment that "fips_enabled can cause some tests to be skipped".

 Documentation/admin-guide/kernel-parameters.txt |   14 ++
 1 file changed, 14 insertions(+)

--- linux-next-20210329.orig/Documentation/admin-guide/kernel-parameters.txt
+++ linux-next-20210329/Documentation/admin-guide/kernel-parameters.txt
@@ -1370,6 +1370,20 @@
See Documentation/admin-guide/sysctl/net.rst for
fb_tunnels_only_for_init_ns
 
+   fips=   Format: { 0 | 1}
+   Use to disable (0) or enable (1) FIPS mode.
+   If enabled, any process that is waiting on the
+   'fips_fail_notif_chain' will be notified of fips
+   failures.
+   This setting can also be modified via sysctl at
+   /proc/sysctl/crypto/fips_enabled, i.e.,
+   crypto.fips_enabled.
+   If fips_enabled = 1 and a test fails, it will cause a
+   kernel panic.
+   If fips_enabled = 1, RSA test requires a key size of
+   2K or larger.
+   It can also effect which ECC curve is used.
+
floppy= [HW]
See Documentation/admin-guide/blockdev/floppy.rst.
 

Re: [PATCH v3 2/2] riscv: Cleanup KASAN_VMALLOC support

[Palmer Dabbelt]

On Sat, 13 Mar 2021 00:45:05 PST (-0800), a...@ghiti.fr wrote:

When KASAN vmalloc region is populated, there is no userspace process and
the page table in use is swapper_pg_dir, so there is no need to read
SATP. Then we can use the same scheme used by kasan_populate_p*d
functions to go through the page table, which harmonizes the code.

In addition, make use of set_pgd that goes through all unused page table
levels, contrary to p*d_populate functions, which makes this function work
whatever the number of page table levels.

Signed-off-by: Alexandre Ghiti 
Reviewed-by: Palmer Dabbelt 
---
 arch/riscv/mm/kasan_init.c | 59 --
 1 file changed, 18 insertions(+), 41 deletions(-)

diff --git a/arch/riscv/mm/kasan_init.c b/arch/riscv/mm/kasan_init.c
index 57bf4ae09361..c16178918239 100644
--- a/arch/riscv/mm/kasan_init.c
+++ b/arch/riscv/mm/kasan_init.c
@@ -11,18 +11,6 @@
 #include 
 #include 

-static __init void *early_alloc(size_t size, int node)
-{
-   void *ptr = memblock_alloc_try_nid(size, size,
-   __pa(MAX_DMA_ADDRESS), MEMBLOCK_ALLOC_ACCESSIBLE, node);
-
-   if (!ptr)
-   panic("%pS: Failed to allocate %zu bytes align=%zx nid=%d 
from=%llx\n",
-   __func__, size, size, node, (u64)__pa(MAX_DMA_ADDRESS));
-
-   return ptr;
-}
-
 extern pgd_t early_pg_dir[PTRS_PER_PGD];
 asmlinkage void __init kasan_early_init(void)
 {
@@ -155,38 +143,27 @@ static void __init kasan_populate(void *start, void *end)
memset(start, KASAN_SHADOW_INIT, end - start);
 }

-void __init kasan_shallow_populate(void *start, void *end)
+static void __init kasan_shallow_populate_pgd(unsigned long vaddr, unsigned 
long end)
 {
-   unsigned long vaddr = (unsigned long)start & PAGE_MASK;
-   unsigned long vend = PAGE_ALIGN((unsigned long)end);
-   unsigned long pfn;
-   int index;
+   unsigned long next;
void *p;
-   pud_t *pud_dir, *pud_k;
-   pgd_t *pgd_dir, *pgd_k;
-   p4d_t *p4d_dir, *p4d_k;
-
-   while (vaddr < vend) {
-   index = pgd_index(vaddr);
-   pfn = csr_read(CSR_SATP) & SATP_PPN;
-   pgd_dir = (pgd_t *)pfn_to_virt(pfn) + index;
-   pgd_k = init_mm.pgd + index;
-   pgd_dir = pgd_offset_k(vaddr);
-   set_pgd(pgd_dir, *pgd_k);
-
-   p4d_dir = p4d_offset(pgd_dir, vaddr);
-   p4d_k  = p4d_offset(pgd_k, vaddr);
-
-   vaddr = (vaddr + PUD_SIZE) & PUD_MASK;
-   pud_dir = pud_offset(p4d_dir, vaddr);
-   pud_k = pud_offset(p4d_k, vaddr);
-
-   if (pud_present(*pud_dir)) {
-   p = early_alloc(PAGE_SIZE, NUMA_NO_NODE);
-   pud_populate(_mm, pud_dir, p);
+   pgd_t *pgd_k = pgd_offset_k(vaddr);
+
+   do {
+   next = pgd_addr_end(vaddr, end);
+   if (pgd_page_vaddr(*pgd_k) == (unsigned 
long)lm_alias(kasan_early_shadow_pmd)) {
+   p = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
+   set_pgd(pgd_k, pfn_pgd(PFN_DOWN(__pa(p)), PAGE_TABLE));
}
-   vaddr += PAGE_SIZE;
-   }
+   } while (pgd_k++, vaddr = next, vaddr != end);
+}
+
+static void __init kasan_shallow_populate(void *start, void *end)
+{
+   unsigned long vaddr = (unsigned long)start & PAGE_MASK;
+   unsigned long vend = PAGE_ALIGN((unsigned long)end);
+
+   kasan_shallow_populate_pgd(vaddr, vend);

local_flush_tlb_all();
 }


Thanks, this is on for-next.

Re: [PATCH] kbuild: buildtar: add riscv support

[Palmer Dabbelt]

On Tue, 16 Mar 2021 09:02:43 PDT (-0700), m...@carlosedp.com wrote:

Make 'make tar-pkg' and 'tarbz2-pkg' work on riscv.

Signed-off-by: Carlos de Paula 
---
 scripts/package/buildtar | 8 
 1 file changed, 8 insertions(+)

diff --git a/scripts/package/buildtar b/scripts/package/buildtar
index 936198a90477..221aa7df008d 100755
--- a/scripts/package/buildtar
+++ b/scripts/package/buildtar
@@ -123,10 +123,18 @@ case "${ARCH}" in
cp -v -- "${objtree}/arch/arm64/boot/${i}" 
"${tmpdir}/boot/vmlinuz-${KERNELRELEASE}"
break
fi
done
;;
+   riscv)
+   for i in Image.bz2 Image.gz Image; do
+   if [ -f "${objtree}/arch/riscv/boot/${i}" ] ; then
+   cp -v -- "${objtree}/arch/riscv/boot/${i}" 
"${tmpdir}/boot/vmlinux-${KERNELRELEASE}"
+   break
+   fi
+   done
+   ;;
*)
[ -f "${KBUILD_IMAGE}" ] && cp -v -- "${KBUILD_IMAGE}" 
"${tmpdir}/boot/vmlinux-kbuild-${KERNELRELEASE}"
echo "" >&2
echo '** ** **  WARNING  ** ** **' >&2
echo "" >&2


Thanks, this is on for-next.

Re: [PATCH] Documentation: crypto: add info about "fips=" boot option

[Herbert Xu]

On Mon, Mar 29, 2021 at 10:00:45PM -0700, Randy Dunlap wrote:
> On 3/29/21 9:37 PM, Herbert Xu wrote:
> > On Mon, Mar 29, 2021 at 09:00:01PM -0700, Randy Dunlap wrote:
> >>
> >> +  If fips_enabled = 1, some crypto tests are skipped.
> > 
> > I don't think any tests are skipped.  It does however disable
> > many algorithms by essentially failing them at the testing stage.
> 
> That statement was based on crypto/testmgr.c (in 4 places):
> 
>   if (fips_enabled && template[i].fips_skip)
>   continue;

By skipping the test, the algorithm effectively fails the self-test
and therefore is disabled.

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

Re: [PATCH] Documentation: crypto: add info about "fips=" boot option

[Randy Dunlap]

On 3/29/21 9:37 PM, Herbert Xu wrote:
> On Mon, Mar 29, 2021 at 09:00:01PM -0700, Randy Dunlap wrote:
>>
>> +If fips_enabled = 1, some crypto tests are skipped.
> 
> I don't think any tests are skipped.  It does however disable
> many algorithms by essentially failing them at the testing stage.

That statement was based on crypto/testmgr.c (in 4 places):

if (fips_enabled && template[i].fips_skip)
continue;

and

if (fips_enabled && vec->fips_skip)
return 0;

and

if (fips_enabled && !alg_test_descs[i].fips_allowed)
goto non_fips_alg;

and

if (fips_enabled && ((i >= 0 && !alg_test_descs[i].fips_allowed) ||
 (j >= 0 && !alg_test_descs[j].fips_allowed)))
goto non_fips_alg;


so it appears (at least to me) that there are some methods (infrastructure)
for tests to be skipped, but maybe none are actually using that possiblilty.

In any case, I don't mind dropping that part of the documentation.

thanks.
-- 
~Randy

Re: [PATCH v3] mm: fix race by making init_zero_pfn() early_initcall

[Zhou Yanjie]

Hi Ilya,

On 2021/3/30 下午12:42, Ilya Lipnitskiy wrote:

There are code paths that rely on zero_pfn to be fully initialized
before core_initcall. For example, wq_sysfs_init() is a core_initcall
function that eventually results in a call to kernel_execve, which
causes a page fault with a subsequent mmput. If zero_pfn is not
initialized by then it may not get cleaned up properly and result in an
error:
   BUG: Bad rss-counter state mm:(ptrval) type:MM_ANONPAGES val:1

Here is an analysis of the race as seen on a MIPS device. On this
particular MT7621 device (Ubiquiti ER-X), zero_pfn is PFN 0 until
initialized, at which point it becomes PFN 5120:
   1. wq_sysfs_init calls into kobject_uevent_env at core_initcall:
[<80340dc8>] kobject_uevent_env+0x7e4/0x7ec
[<8033f8b8>] kset_register+0x68/0x88
[<803cf824>] bus_register+0xdc/0x34c
[<803cfac8>] subsys_virtual_register+0x34/0x78
[<8086afb0>] wq_sysfs_init+0x1c/0x4c
[<80001648>] do_one_initcall+0x50/0x1a8
[<8086503c>] kernel_init_freeable+0x230/0x2c8
[<8066bca0>] kernel_init+0x10/0x100
[<80003038>] ret_from_kernel_thread+0x14/0x1c

   2. kobject_uevent_env() calls call_usermodehelper_exec() which executes
  kernel_execve asynchronously.

   3. Memory allocations in kernel_execve cause a page fault, bumping the
  MM reference counter:
[<8015adb4>] add_mm_counter_fast+0xb4/0xc0
[<80160d58>] handle_mm_fault+0x6e4/0xea0
[<80158aa4>] __get_user_pages.part.78+0x190/0x37c
[<8015992c>] __get_user_pages_remote+0x128/0x360
[<801a6d9c>] get_arg_page+0x34/0xa0
[<801a7394>] copy_string_kernel+0x194/0x2a4
[<801a880c>] kernel_execve+0x11c/0x298
[<800420f4>] call_usermodehelper_exec_async+0x114/0x194

   4. In case zero_pfn has not been initialized yet, zap_pte_range does
  not decrement the MM_ANONPAGES RSS counter and the BUG message is
  triggered shortly afterwards when __mmdrop checks the ref counters:
[<800285e8>] __mmdrop+0x98/0x1d0
[<801a6de8>] free_bprm+0x44/0x118
[<801a86a8>] kernel_execve+0x160/0x1d8
[<800420f4>] call_usermodehelper_exec_async+0x114/0x194
[<80003198>] ret_from_kernel_thread+0x14/0x1c

To avoid races such as described above, initialize init_zero_pfn at
early_initcall level. Depending on the architecture, ZERO_PAGE is either
constant or gets initialized even earlier, at paging_init, so there is
no issue with initializing zero_pfn earlier.

Discussion: 
https://lkml.kernel.org/r/CALCv0x2YqOXEAy2Q=hafjhHCtTHVodChv1qpM=niaxopqeb...@mail.gmail.com

Signed-off-by: Ilya Lipnitskiy 
Cc: Hugh Dickins 
Cc: "Eric W. Biederman" 
Cc: sta...@vger.kernel.org
---
  mm/memory.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)



Tested-by: 周琰杰 (Zhou Yanjie) # on 
CU1000-Neo/X1000E and CU1830-Neo/X1830




diff --git a/mm/memory.c b/mm/memory.c
index 5c3b29d3af66..e66b11ac1659 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -166,7 +166,7 @@ static int __init init_zero_pfn(void)
zero_pfn = page_to_pfn(ZERO_PAGE(0));
return 0;
  }
-core_initcall(init_zero_pfn);
+early_initcall(init_zero_pfn);
  
  void mm_trace_rss_stat(struct mm_struct *mm, int member, long count)

  {

Re: [PATCH v3] kernel/resource: Fix locking in request_free_mem_region

[Alistair Popple]

On Tuesday, 30 March 2021 2:42:34 PM AEDT John Hubbard wrote:
> On 3/29/21 5:38 PM, Alistair Popple wrote:
> > request_free_mem_region() is used to find an empty range of physical
> > addresses for hotplugging ZONE_DEVICE memory. It does this by iterating
> > over the range of possible addresses using region_intersects() to see if
> > the range is free.
> > 
> > region_intersects() obtains a read lock before walking the resource tree
> > to protect against concurrent changes. However it drops the lock prior
> > to returning. This means by the time request_mem_region() is called in
> > request_free_mem_region() another thread may have already reserved the
> > requested region resulting in unexpected failures and a message in the
> > kernel log from hitting this condition:
> > 
> >  /*
> >   * mm/hmm.c reserves physical addresses which then
> >   * become unavailable to other users.  Conflicts are
> >   * not expected.  Warn to aid debugging if encountered.
> >   */
> >  if (conflict->desc == IORES_DESC_DEVICE_PRIVATE_MEMORY) {
> >  pr_warn("Unaddressable device %s %pR conflicts with %pR",
> >  conflict->name, conflict, res);
> > 
> > To fix this create versions of region_intersects() and
> > request_mem_region() that allow the caller to take the appropriate lock
> > such that it may be held over the required calls.
> > 
> > Instead of creating another version of devm_request_mem_region() that
> > doesn't take the lock open-code it to allow the caller to pre-allocate
> > the required memory prior to taking the lock.
> > 
> > Fixes: 0c385190392d8 ("resource: add a not device managed 
request_free_mem_region variant")
> > Fixes: 0092908d16c60 ("mm: factor out a devm_request_free_mem_region 
helper")
> 
> Hi Alistair!
> 
> The above "Fixes:" tag looks wrong to me, because that commit did not create
> the broken locking that this patch fixes. Therefore, I think that particular 
line
> should be removed from the commit description.

Right, the last "Fixes:" tag is the origin of the bug but the refactoring into 
different functions and files made it non-obvious how this patch was related. 
Happy to drop these though.
 
> Another note below:
> 
> > Fixes: 4ef589dc9b10c ("mm/hmm/devmem: device memory hotplug using 
ZONE_DEVICE")
> > Signed-off-by: Alistair Popple 
> > Acked-by: Balbir Singh 
> > Reported-by: kernel test robot 
> > 
> > ---
> > 
> > Hi Andrew,
> > 
> > This fixes a boot issue reported by the kernel test robot with the
> > previous version of the patch on x86 with CONFIG_IO_STRICT_DEVMEM=y.
> > This was due to the platform specific implementation of
> > devmem_is_allowed() creating a recursive lock which I missed. I notice
> > you have put v2 in mmtom so apologies for the churn but can you please
> > use this version instead? Thanks.
> > 
> >   - Alistair
> > ---
> >   kernel/resource.c | 142 ++
> >   1 file changed, 92 insertions(+), 50 deletions(-)
> > 
> > diff --git a/kernel/resource.c b/kernel/resource.c
> > index 627e61b0c124..7061b9f903ca 100644
> > --- a/kernel/resource.c
> > +++ b/kernel/resource.c
> > @@ -523,6 +523,34 @@ int __weak page_is_ram(unsigned long pfn)
> >   }
> >   EXPORT_SYMBOL_GPL(page_is_ram);
> >   
> > +static int __region_intersects(resource_size_t start, size_t size,
> > +  unsigned long flags, unsigned long desc)
> > +{
> > +   struct resource res;
> > +   int type = 0; int other = 0;
> > +   struct resource *p;
> > +
> > +   res.start = start;
> > +   res.end = start + size - 1;
> > +
> > +   for (p = iomem_resource.child; p ; p = p->sibling) {
> > +   bool is_type = (((p->flags & flags) == flags) &&
> > +   ((desc == IORES_DESC_NONE) ||
> > +(desc == p->desc)));
> > +
> > +   if (resource_overlaps(p, ))
> > +   is_type ? type++ : other++;
> > +   }
> > +
> > +   if (type == 0)
> > +   return REGION_DISJOINT;
> > +
> > +   if (other == 0)
> > +   return REGION_INTERSECTS;
> > +
> > +   return REGION_MIXED;
> > +}
> > +
> >   /**
> >* region_intersects() - determine intersection of region with known 
resources
> >* @start: region start address
> > @@ -546,31 +574,12 @@ EXPORT_SYMBOL_GPL(page_is_ram);
> >   int region_intersects(resource_size_t start, size_t size, unsigned long 
flags,
> >   unsigned long desc)
> >   {
> > -   struct resource res;
> > -   int type = 0; int other = 0;
> > -   struct resource *p;
> > -
> > -   res.start = start;
> > -   res.end = start + size - 1;
> > +   int rc;
> >   
> > read_lock(_lock);
> > -   for (p = iomem_resource.child; p ; p = p->sibling) {
> > -   bool is_type = (((p->flags & flags) == flags) &&
> > -   ((desc == IORES_DESC_NONE) ||
> > -(desc == p->desc)));
> > -
> > -   if 

Re: [PATCH -tip v4 10/12] x86/kprobes: Push a fake return address at kretprobe_trampoline

[Josh Poimboeuf]

On Fri, Mar 26, 2021 at 10:20:09AM -0400, Steven Rostedt wrote:
> On Fri, 26 Mar 2021 21:03:49 +0900
> Masami Hiramatsu  wrote:
> 
> > I confirmed this is not related to this series, but occurs when I build 
> > kernels with different
> > configs without cleanup.
> > 
> > Once I build kernel with CONFIG_UNWIND_GUESS=y (for testing), and after 
> > that,
> > I build kernel again with CONFIG_UNWIND_ORC=y (but without make clean), this
> > happened. In this case, I guess ORC data might be corrupted?
> > When I cleanup and rebuild, the stacktrace seems correct.
> 
> Hmm, that should be fixed. Seems like we are missing a dependency somewhere.

Thomas reported something similar: for example arch/x86/kernel/head_64.o
doesn't get rebuilt when changing unwinders.

  https://lkml.kernel.org/r/87tuqublrb@nanos.tec.linutronix.de

Masahiro, any idea how we can force a full tree rebuild when changing
the unwinder?

-- 
Josh

Re: [PATCH] nvmem: Change to unified property interface

[kernel test robot]

Hi Kevin,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on linus/master]
[also build test WARNING on v5.12-rc5 next-20210329]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:
https://github.com/0day-ci/linux/commits/Kevin-Paul-Herbert/nvmem-Change-to-unified-property-interface/20210330-064121
base:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
1e43c377a79f9189fea8f2711b399d4e8b4e609b
config: x86_64-randconfig-a014-20210329 (attached as .config)
compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project 
482283042f795ecc27838a3b2f76b5494991401c)
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# install x86_64 cross compiling tool for clang build
# apt-get install binutils-x86-64-linux-gnu
# 
https://github.com/0day-ci/linux/commit/edbc7632702cf638265a6d7180bd8c951cda6ad9
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review 
Kevin-Paul-Herbert/nvmem-Change-to-unified-property-interface/20210330-064121
git checkout edbc7632702cf638265a6d7180bd8c951cda6ad9
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross 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 >>):

   drivers/thermal/sprd_thermal.c:128:9: error: implicit declaration of 
function 'of_nvmem_cell_get' [-Werror,-Wimplicit-function-declaration]
   cell = of_nvmem_cell_get(np, cell_id);
  ^
   drivers/thermal/sprd_thermal.c:128:9: note: did you mean 'nvmem_cell_get'?
   include/linux/nvmem-consumer.h:60:20: note: 'nvmem_cell_get' declared here
   struct nvmem_cell *nvmem_cell_get(struct device *dev, const char *id);
  ^
>> drivers/thermal/sprd_thermal.c:128:7: warning: incompatible integer to 
>> pointer conversion assigning to 'struct nvmem_cell *' from 'int' 
>> [-Wint-conversion]
   cell = of_nvmem_cell_get(np, cell_id);
^ ~~
   1 warning and 1 error generated.


vim +128 drivers/thermal/sprd_thermal.c

554fdbaf19b188 Freeman Liu 2020-02-18  120  
554fdbaf19b188 Freeman Liu 2020-02-18  121  static int sprd_thm_cal_read(struct 
device_node *np, const char *cell_id,
554fdbaf19b188 Freeman Liu 2020-02-18  122   u32 *val)
554fdbaf19b188 Freeman Liu 2020-02-18  123  {
554fdbaf19b188 Freeman Liu 2020-02-18  124  struct nvmem_cell *cell;
554fdbaf19b188 Freeman Liu 2020-02-18  125  void *buf;
554fdbaf19b188 Freeman Liu 2020-02-18  126  size_t len;
554fdbaf19b188 Freeman Liu 2020-02-18  127  
554fdbaf19b188 Freeman Liu 2020-02-18 @128  cell = of_nvmem_cell_get(np, 
cell_id);
554fdbaf19b188 Freeman Liu 2020-02-18  129  if (IS_ERR(cell))
554fdbaf19b188 Freeman Liu 2020-02-18  130  return PTR_ERR(cell);
554fdbaf19b188 Freeman Liu 2020-02-18  131  
554fdbaf19b188 Freeman Liu 2020-02-18  132  buf = nvmem_cell_read(cell, 
);
554fdbaf19b188 Freeman Liu 2020-02-18  133  nvmem_cell_put(cell);
554fdbaf19b188 Freeman Liu 2020-02-18  134  if (IS_ERR(buf))
554fdbaf19b188 Freeman Liu 2020-02-18  135  return PTR_ERR(buf);
554fdbaf19b188 Freeman Liu 2020-02-18  136  
554fdbaf19b188 Freeman Liu 2020-02-18  137  if (len > sizeof(u32)) {
554fdbaf19b188 Freeman Liu 2020-02-18  138  kfree(buf);
554fdbaf19b188 Freeman Liu 2020-02-18  139  return -EINVAL;
554fdbaf19b188 Freeman Liu 2020-02-18  140  }
554fdbaf19b188 Freeman Liu 2020-02-18  141  
554fdbaf19b188 Freeman Liu 2020-02-18  142  memcpy(val, buf, len);
554fdbaf19b188 Freeman Liu 2020-02-18  143  
554fdbaf19b188 Freeman Liu 2020-02-18  144  kfree(buf);
554fdbaf19b188 Freeman Liu 2020-02-18  145  return 0;
554fdbaf19b188 Freeman Liu 2020-02-18  146  }
554fdbaf19b188 Freeman Liu 2020-02-18  147  

---
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 v1 1/1] x86/tdx: Handle MWAIT, MONITOR and WBINVD

[Xiaoyao Li]

On 3/27/2021 8:18 AM, Kuppuswamy Sathyanarayanan wrote:

In non-root TDX guest mode, MWAIT, MONITOR and WBINVD instructions
are not supported. So handle #VE due to these instructions as no ops.

Signed-off-by: Kuppuswamy Sathyanarayanan 

Reviewed-by: Andi Kleen 
---

Changes since previous series:
  * Suppressed MWAIT feature as per Andi's comment.
  * Added warning debug log for MWAIT #VE exception.

  arch/x86/kernel/tdx.c | 23 +++
  1 file changed, 23 insertions(+)

diff --git a/arch/x86/kernel/tdx.c b/arch/x86/kernel/tdx.c
index e936b2f88bf6..fb7d22b846fc 100644
--- a/arch/x86/kernel/tdx.c
+++ b/arch/x86/kernel/tdx.c
@@ -308,6 +308,9 @@ void __init tdx_early_init(void)
  
  	setup_force_cpu_cap(X86_FEATURE_TDX_GUEST);
  
+	/* MWAIT is not supported in TDX platform, so suppress it */

+   setup_clear_cpu_cap(X86_FEATURE_MWAIT);


In fact, MWAIT bit returned by CPUID instruction is zero for TD guest. 
This is enforced by SEAM module.


Do we still need to safeguard it by setup_clear_cpu_cap() here?


+
tdg_get_info();
  
  	pv_ops.irq.safe_halt = tdg_safe_halt;

Re: exec error: BUG: Bad rss-counter

[Zhou Yanjie]

Hi Ilya,

On 2021/3/29 上午10:48, Ilya Lipnitskiy wrote:

On Sat, Mar 20, 2021 at 8:59 AM Zhou Yanjie  wrote:

Hi Ilya,

On 2021/3/3 下午11:55, Ilya Lipnitskiy wrote:

On Wed, Mar 3, 2021 at 7:50 AM Eric W. Biederman  wrote:

Ilya Lipnitskiy  writes:


On Tue, Mar 2, 2021 at 11:37 AM Eric W. Biederman  wrote:

Ilya Lipnitskiy  writes:


On Mon, Mar 1, 2021 at 12:43 PM Eric W. Biederman  wrote:

Ilya Lipnitskiy  writes:


Eric, All,

The following error appears when running Linux 5.10.18 on an embedded
MIPS mt7621 target:
[0.301219] BUG: Bad rss-counter state mm:(ptrval) type:MM_ANONPAGES val:1

Being a very generic error, I started digging and added a stack dump
before the BUG:
Call Trace:
[<80008094>] show_stack+0x30/0x100
[<8033b238>] dump_stack+0xac/0xe8
[<800285e8>] __mmdrop+0x98/0x1d0
[<801a6de8>] free_bprm+0x44/0x118
[<801a86a8>] kernel_execve+0x160/0x1d8
[<800420f4>] call_usermodehelper_exec_async+0x114/0x194
[<80003198>] ret_from_kernel_thread+0x14/0x1c

So that's how I got to looking at fs/exec.c and noticed quite a few
changes last year. Turns out this message only occurs once very early
at boot during the very first call to kernel_execve. current->mm is
NULL at this stage, so acct_arg_size() is effectively a no-op.

If you believe this is a new error you could bisect the kernel
to see which change introduced the behavior you are seeing.


More digging, and I traced the RSS counter increment to:
[<8015adb4>] add_mm_counter_fast+0xb4/0xc0
[<80160d58>] handle_mm_fault+0x6e4/0xea0
[<80158aa4>] __get_user_pages.part.78+0x190/0x37c
[<8015992c>] __get_user_pages_remote+0x128/0x360
[<801a6d9c>] get_arg_page+0x34/0xa0
[<801a7394>] copy_string_kernel+0x194/0x2a4
[<801a880c>] kernel_execve+0x11c/0x298
[<800420f4>] call_usermodehelper_exec_async+0x114/0x194
[<80003198>] ret_from_kernel_thread+0x14/0x1c

In fact, I also checked vma_pages(bprm->vma) and lo and behold it is set to 1.

How is fs/exec.c supposed to handle implied RSS increments that happen
due to page faults when discarding the bprm structure? In this case,
the bug-generating kernel_execve call never succeeded, it returned -2,
but I didn't trace exactly what failed.

Unless I am mistaken any left over pages should be purged by exit_mmap
which is called by mmput before mmput calls mmdrop.

Good to know. Some more digging and I can say that we hit this error
when trying to unmap PFN 0 (is_zero_pfn(pfn) returns TRUE,
vm_normal_page returns NULL, zap_pte_range does not decrement
MM_ANONPAGES RSS counter). Is my understanding correct that PFN 0 is
usable, but special? Or am I totally off the mark here?

It would be good to know if that is the page that get_user_pages_remote
returned to copy_string_kernel.  The zero page that is always zero,
should never be returned when a writable mapping is desired.

Indeed, pfn 0 is returned from get_arg_page: (page is 0x809cf000,
page_to_pfn(page) is 0) and it is the same page that is being freed and not
refcounted in mmput/zap_pte_range. Confirmed with good old printk. Also,
ZERO_PAGE(0)==0x809fc000 -> PFN 5120.

I think I have found the problem though, after much digging and thanks to all
the information provided. init_zero_pfn() gets called too late (after
the call to
is_zero_pfn(0) from mmput returns true), until then zero_pfn == 0, and after,
zero_pfn == 5120. Boom.

So PFN 0 is special, but only for a little bit, enough for something
on my system
to call kernel_execve :)

Question: is my system not supposed to be calling kernel_execve this
early or does
init_zero_pfn() need to happen earlier? init_zero_pfn is currently a
core_initcall.

Looking quickly it seems that init_zero_pfn() is in mm/memory.c and is
common for both mips and x86.  Further it appears init_zero_pfn() has
been that was since 2009 a13ea5b75964 ("mm: reinstate ZERO_PAGE").

Given the testing that x86 gets and that nothing like this has been
reported it looks like whatever driver is triggering the kernel_execve
is doing something wrong.
Because honestly.  If the zero page isn't working there is not a chance
that anything in userspace is working so it is clearly much too early.

I suspect there is some driver that is initialized very early that is
doing something that looks innocuous (like triggering a hotplug event)
and that happens to cause a call_usermode_helper which then calls
kernel_execve.

I will investigate the offenders more closely. However, I do not
notice this behavior on the same system based on the 5.4 kernel. Is it


I also encountered this problem on Ingenic X1000 and X1830. This is the
printed information:

[0.120715] BUG: Bad rss-counter state mm:(ptrval)
   type:MM_ANONPAGES val:1

I tested kernel 5.9, kernel 5.10, kernel 5.11, and kernel 5.12, only
kernel 5.9 did not have this problem, so we can know that this problem
was introduced in kernel 5.10, have you found any effective solution?

Try:
diff --git a/mm/memory.c b/mm/memory.c
index c8e357627318..1fd753245369 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -166,7 

RE: [PATCH v4 3/4] locking/qspinlock: Add ARCH_USE_QUEUED_SPINLOCKS_XCHG32

[Anup Patel]

> -Original Message-
> From: Guo Ren 
> Sent: 30 March 2021 08:44
> To: Peter Zijlstra 
> Cc: linux-riscv ; Linux Kernel Mailing List
> ; linux-c...@vger.kernel.org; linux-arch
> ; Guo Ren ; Will
> Deacon ; Ingo Molnar ; Waiman
> Long ; Arnd Bergmann ; Anup
> Patel 
> Subject: Re: [PATCH v4 3/4] locking/qspinlock: Add
> ARCH_USE_QUEUED_SPINLOCKS_XCHG32
> 
> On Mon, Mar 29, 2021 at 8:50 PM Peter Zijlstra 
> wrote:
> >
> > On Mon, Mar 29, 2021 at 08:01:41PM +0800, Guo Ren wrote:
> > > u32 a = 0x55aa66bb;
> > > u16 *ptr = 
> > >
> > > CPU0   CPU1
> > > = =
> > > xchg16(ptr, new) while(1)
> > > WRITE_ONCE(*(ptr + 1), x);
> > >
> > > When we use lr.w/sc.w implement xchg16, it'll cause CPU0 deadlock.
> >
> > Then I think your LL/SC is broken.
> >
> > That also means you really don't want to build super complex locking
> > primitives on top, because that live-lock will percolate through.
> Do you mean the below implementation has live-lock risk?
> +static __always_inline u32 xchg_tail(struct qspinlock *lock, u32 tail)
> +{
> +   u32 old, new, val = atomic_read(>val);
> +
> +   for (;;) {
> +   new = (val & _Q_LOCKED_PENDING_MASK) | tail;
> +   old = atomic_cmpxchg(>val, val, new);
> +   if (old == val)
> +   break;
> +
> +   val = old;
> +   }
> +   return old;
> +}
> 
> 
> >
> > Step 1 would be to get your architecute fixed such that it can provide
> > fwd progress guarantees for LL/SC. Otherwise there's absolutely no
> > point in building complex systems with it.
> 
> Quote Waiman's comment [1] on xchg16 optimization:
> 
> "This optimization is needed to make the qspinlock achieve performance
> parity with ticket spinlock at light load."
> 
> [1] https://lore.kernel.org/kvm/1429901803-29771-6-git-send-email-
> waiman.l...@hp.com/
> 
> So for a non-xhg16 machine:
>  - ticket-lock for small numbers of CPUs
>  - qspinlock for large numbers of CPUs
> 
> Okay, I'll put all of them into the next patch 

I would suggest to have separate Kconfig opitons for ticket spinlock
in Linux RISC-V which will be disabled by default. This means Linux
RISC-V will use qspinlock by default and use ticket spinlock only when
ticket spinlock kconfig is enabled.

Regards,
Anup

Re: [PATCH 2/4] cxl/mem: Fix cdev_device_add() error handling

[Dan Williams]

On Mon, Mar 29, 2021 at 3:44 PM Jason Gunthorpe  wrote:
>
> On Mon, Mar 29, 2021 at 02:03:37PM -0700, Dan Williams wrote:
>
> > Ugh, exactly why I was motivated to attempt to preclude this with new
> > core infrastructure that attempted to fix this centrally [1]. Remove
> > the  possibility of "others" getting this wrong. However after my
> > initial idea bounced off Greg then I ended up shipping this bug in the
> > local rewrite. I think the debugfs api gets this right in terms of
> > centralizing the reference count management, and I want to see
> > something similar for common driver ioctl patterns.
>
> There is a lot of variety here, I'm not sure how much valuable common
> code there will be that could be lifted into the core.. srcu,
> refcount, rwsem, percpu_ref, etc are all common implementations with
> various properties.
>
> The easist implementation is to just block driver destruction with a
> refcount & completion pattern
>
> The hardest is to allow the underlying HW driver to be removed from
> the fops while the file remains open.
>
> Usually whatever scheme is used has to flow into some in-kernel API as
> well, so isolating it in cdev may no be entirely helpful.
>
> The easisted helper API would be to add an 'unregistration lock' to
> the struct device that blocks unregistration. A refcount & completion
> for instance. I've seen that open coded enough times.

I do agree there is too much variety to widely unify. At the same time
it is a common enough pattern for devices that allow removal before
final close, especially devices that support hot-removal disconnecting
is a better pattern than blocking unregisteration.

Just the small matter of time to see this through...

[PATCH v4 3/3] svm/sev: Register SEV and SEV-ES ASIDs to the misc controller

[Vipin Sharma]

Secure Encrypted Virtualization (SEV) and Secure Encrypted
Virtualization - Encrypted State (SEV-ES) ASIDs are used to encrypt KVMs
on AMD platform. These ASIDs are available in the limited quantities on
a host.

Register their capacity and usage to the misc controller for tracking
via cgroups.

Signed-off-by: Vipin Sharma 
Reviewed-by: David Rientjes 
---
 arch/x86/kvm/svm/sev.c  | 70 +++--
 arch/x86/kvm/svm/svm.h  |  1 +
 include/linux/misc_cgroup.h |  6 
 kernel/cgroup/misc.c|  6 
 4 files changed, 73 insertions(+), 10 deletions(-)

diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
index 874ea309279f..214eefb20414 100644
--- a/arch/x86/kvm/svm/sev.c
+++ b/arch/x86/kvm/svm/sev.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -28,6 +29,21 @@
 
 #define __ex(x) __kvm_handle_fault_on_reboot(x)
 
+#ifndef CONFIG_KVM_AMD_SEV
+/*
+ * When this config is not defined, SEV feature is not supported and APIs in
+ * this file are not used but this file still gets compiled into the KVM AMD
+ * module.
+ *
+ * We will not have MISC_CG_RES_SEV and MISC_CG_RES_SEV_ES entries in the enum
+ * misc_res_type {} defined in linux/misc_cgroup.h.
+ *
+ * Below macros allow compilation to succeed.
+ */
+#define MISC_CG_RES_SEV MISC_CG_RES_TYPES
+#define MISC_CG_RES_SEV_ES MISC_CG_RES_TYPES
+#endif
+
 static u8 sev_enc_bit;
 static int sev_flush_asids(void);
 static DECLARE_RWSEM(sev_deactivate_lock);
@@ -89,8 +105,19 @@ static bool __sev_recycle_asids(int min_asid, int max_asid)
 
 static int sev_asid_new(struct kvm_sev_info *sev)
 {
-   int pos, min_asid, max_asid;
+   int pos, min_asid, max_asid, ret;
bool retry = true;
+   enum misc_res_type type;
+
+   type = sev->es_active ? MISC_CG_RES_SEV_ES : MISC_CG_RES_SEV;
+   WARN_ON(sev->misc_cg);
+   sev->misc_cg = get_current_misc_cg();
+   ret = misc_cg_try_charge(type, sev->misc_cg, 1);
+   if (ret) {
+   put_misc_cg(sev->misc_cg);
+   sev->misc_cg = NULL;
+   return ret;
+   }
 
mutex_lock(_bitmap_lock);
 
@@ -108,7 +135,8 @@ static int sev_asid_new(struct kvm_sev_info *sev)
goto again;
}
mutex_unlock(_bitmap_lock);
-   return -EBUSY;
+   ret = -EBUSY;
+   goto e_uncharge;
}
 
__set_bit(pos, sev_asid_bitmap);
@@ -116,6 +144,11 @@ static int sev_asid_new(struct kvm_sev_info *sev)
mutex_unlock(_bitmap_lock);
 
return pos + 1;
+e_uncharge:
+   misc_cg_uncharge(type, sev->misc_cg, 1);
+   put_misc_cg(sev->misc_cg);
+   sev->misc_cg = NULL;
+   return ret;
 }
 
 static int sev_get_asid(struct kvm *kvm)
@@ -125,14 +158,15 @@ static int sev_get_asid(struct kvm *kvm)
return sev->asid;
 }
 
-static void sev_asid_free(int asid)
+static void sev_asid_free(struct kvm_sev_info *sev)
 {
struct svm_cpu_data *sd;
int cpu, pos;
+   enum misc_res_type type;
 
mutex_lock(_bitmap_lock);
 
-   pos = asid - 1;
+   pos = sev->asid - 1;
__set_bit(pos, sev_reclaim_asid_bitmap);
 
for_each_possible_cpu(cpu) {
@@ -141,6 +175,11 @@ static void sev_asid_free(int asid)
}
 
mutex_unlock(_bitmap_lock);
+
+   type = sev->es_active ? MISC_CG_RES_SEV_ES : MISC_CG_RES_SEV;
+   misc_cg_uncharge(type, sev->misc_cg, 1);
+   put_misc_cg(sev->misc_cg);
+   sev->misc_cg = NULL;
 }
 
 static void sev_unbind_asid(struct kvm *kvm, unsigned int handle)
@@ -188,19 +227,20 @@ static int sev_guest_init(struct kvm *kvm, struct 
kvm_sev_cmd *argp)
asid = sev_asid_new(sev);
if (asid < 0)
return ret;
+   sev->asid = asid;
 
ret = sev_platform_init(>error);
if (ret)
goto e_free;
 
sev->active = true;
-   sev->asid = asid;
INIT_LIST_HEAD(>regions_list);
 
return 0;
 
 e_free:
-   sev_asid_free(asid);
+   sev_asid_free(sev);
+   sev->asid = 0;
return ret;
 }
 
@@ -1315,12 +1355,12 @@ void sev_vm_destroy(struct kvm *kvm)
mutex_unlock(>lock);
 
sev_unbind_asid(kvm, sev->handle);
-   sev_asid_free(sev->asid);
+   sev_asid_free(sev);
 }
 
 void __init sev_hardware_setup(void)
 {
-   unsigned int eax, ebx, ecx, edx;
+   unsigned int eax, ebx, ecx, edx, sev_asid_count, sev_es_asid_count;
bool sev_es_supported = false;
bool sev_supported = false;
 
@@ -1352,7 +1392,11 @@ void __init sev_hardware_setup(void)
if (!sev_reclaim_asid_bitmap)
goto out;
 
-   pr_info("SEV supported: %u ASIDs\n", max_sev_asid - min_sev_asid + 1);
+   sev_asid_count = max_sev_asid - min_sev_asid + 1;
+   if (misc_cg_set_capacity(MISC_CG_RES_SEV, sev_asid_count))
+   goto out;
+
+   pr_info("SEV supported: %u ASIDs\n", 

[PATCH v4 1/3] cgroup: Add misc cgroup controller

[Vipin Sharma]

The Miscellaneous cgroup provides the resource limiting and tracking
mechanism for the scalar resources which cannot be abstracted like the
other cgroup resources. Controller is enabled by the CONFIG_CGROUP_MISC
config option.

A resource can be added to the controller via enum misc_res_type{} in
the include/linux/misc_cgroup.h file and the corresponding name via
misc_res_name[] in the kernel/cgroup/misc.c file. Provider of the
resource must set its capacity prior to using the resource by calling
misc_cg_set_capacity().

Once a capacity is set then the resource usage can be updated using
charge and uncharge APIs. All of the APIs to interact with misc
controller are in include/linux/misc_cgroup.h.

Miscellaneous controller provides 3 interface files. If two misc
resources (res_a and res_b) are registered then:

misc.capacity
A read-only flat-keyed file shown only in the root cgroup.  It shows
miscellaneous scalar resources available on the platform along with
their quantities::

$ cat misc.capacity
res_a 50
res_b 10

misc.current
A read-only flat-keyed file shown in the non-root cgroups.  It shows
the current usage of the resources in the cgroup and its children::

$ cat misc.current
res_a 3
res_b 0

misc.max
A read-write flat-keyed file shown in the non root cgroups. Allowed
maximum usage of the resources in the cgroup and its children.::

$ cat misc.max
res_a max
res_b 4

Limit can be set by::

# echo res_a 1 > misc.max

Limit can be set to max by::

# echo res_a max > misc.max

Limits can be set more than the capacity value in the misc.capacity
file.

Signed-off-by: Vipin Sharma 
Reviewed-by: David Rientjes 
---
 include/linux/cgroup_subsys.h |   4 +
 include/linux/misc_cgroup.h   | 126 +++
 init/Kconfig  |  14 ++
 kernel/cgroup/Makefile|   1 +
 kernel/cgroup/misc.c  | 401 ++
 5 files changed, 546 insertions(+)
 create mode 100644 include/linux/misc_cgroup.h
 create mode 100644 kernel/cgroup/misc.c

diff --git a/include/linux/cgroup_subsys.h b/include/linux/cgroup_subsys.h
index acb77dcff3b4..445235487230 100644
--- a/include/linux/cgroup_subsys.h
+++ b/include/linux/cgroup_subsys.h
@@ -61,6 +61,10 @@ SUBSYS(pids)
 SUBSYS(rdma)
 #endif
 
+#if IS_ENABLED(CONFIG_CGROUP_MISC)
+SUBSYS(misc)
+#endif
+
 /*
  * The following subsystems are not supported on the default hierarchy.
  */
diff --git a/include/linux/misc_cgroup.h b/include/linux/misc_cgroup.h
new file mode 100644
index ..1195d36558b4
--- /dev/null
+++ b/include/linux/misc_cgroup.h
@@ -0,0 +1,126 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Miscellaneous cgroup controller.
+ *
+ * Copyright 2020 Google LLC
+ * Author: Vipin Sharma 
+ */
+#ifndef _MISC_CGROUP_H_
+#define _MISC_CGROUP_H_
+
+/**
+ * Types of misc cgroup entries supported by the host.
+ */
+enum misc_res_type {
+   MISC_CG_RES_TYPES
+};
+
+struct misc_cg;
+
+#ifdef CONFIG_CGROUP_MISC
+
+#include 
+
+/**
+ * struct misc_res: Per cgroup per misc type resource
+ * @max: Maximum limit on the resource.
+ * @usage: Current usage of the resource.
+ * @failed: True if charged failed for the resource in a cgroup.
+ */
+struct misc_res {
+   unsigned long max;
+   atomic_long_t usage;
+   bool failed;
+};
+
+/**
+ * struct misc_cg - Miscellaneous controller's cgroup structure.
+ * @css: cgroup subsys state object.
+ * @res: Array of misc resources usage in the cgroup.
+ */
+struct misc_cg {
+   struct cgroup_subsys_state css;
+   struct misc_res res[MISC_CG_RES_TYPES];
+};
+
+unsigned long misc_cg_res_total_usage(enum misc_res_type type);
+int misc_cg_set_capacity(enum misc_res_type type, unsigned long capacity);
+int misc_cg_try_charge(enum misc_res_type type, struct misc_cg *cg,
+  unsigned long amount);
+void misc_cg_uncharge(enum misc_res_type type, struct misc_cg *cg,
+ unsigned long amount);
+
+/**
+ * css_misc() - Get misc cgroup from the css.
+ * @css: cgroup subsys state object.
+ *
+ * Context: Any context.
+ * Return:
+ * * %NULL - If @css is null.
+ * * struct misc_cg* - misc cgroup pointer of the passed css.
+ */
+static inline struct misc_cg *css_misc(struct cgroup_subsys_state *css)
+{
+   return css ? container_of(css, struct misc_cg, css) : NULL;
+}
+
+/*
+ * get_current_misc_cg() - Find and get the misc cgroup of the current task.
+ *
+ * Returned cgroup has its ref count increased by 1. Caller must call
+ * put_misc_cg() to return the reference.
+ *
+ * Return: Misc cgroup to which the current task belongs to.
+ */
+static inline struct misc_cg *get_current_misc_cg(void)
+{
+   return css_misc(task_get_css(current, misc_cgrp_id));
+}
+
+/*
+ * put_misc_cg() - Put the misc cgroup and reduce its ref count.
+ * @cg - cgroup to put.
+ */
+static inline void put_misc_cg(struct misc_cg *cg)
+{
+   if (cg)
+   css_put(>css);
+}
+
+#else /* !CONFIG_CGROUP_MISC */
+

[PATCH v4 2/3] cgroup: Miscellaneous cgroup documentation.

[Vipin Sharma]

Documentation of miscellaneous cgroup controller. This new controller is
used to track and limit the usage of scalar resources.

Signed-off-by: Vipin Sharma 
Reviewed-by: David Rientjes 
---
 Documentation/admin-guide/cgroup-v1/index.rst |  1 +
 Documentation/admin-guide/cgroup-v1/misc.rst  |  4 +
 Documentation/admin-guide/cgroup-v2.rst   | 73 ++-
 3 files changed, 76 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/admin-guide/cgroup-v1/misc.rst

diff --git a/Documentation/admin-guide/cgroup-v1/index.rst 
b/Documentation/admin-guide/cgroup-v1/index.rst
index 226f64473e8e..99fbc8a64ba9 100644
--- a/Documentation/admin-guide/cgroup-v1/index.rst
+++ b/Documentation/admin-guide/cgroup-v1/index.rst
@@ -17,6 +17,7 @@ Control Groups version 1
 hugetlb
 memcg_test
 memory
+misc
 net_cls
 net_prio
 pids
diff --git a/Documentation/admin-guide/cgroup-v1/misc.rst 
b/Documentation/admin-guide/cgroup-v1/misc.rst
new file mode 100644
index ..661614c24df3
--- /dev/null
+++ b/Documentation/admin-guide/cgroup-v1/misc.rst
@@ -0,0 +1,4 @@
+===
+Misc controller
+===
+Please refer "Misc" documentation in Documentation/admin-guide/cgroup-v2.rst
diff --git a/Documentation/admin-guide/cgroup-v2.rst 
b/Documentation/admin-guide/cgroup-v2.rst
index 64c62b979f2f..b1e81aa8598a 100644
--- a/Documentation/admin-guide/cgroup-v2.rst
+++ b/Documentation/admin-guide/cgroup-v2.rst
@@ -65,8 +65,11 @@ v1 is available under 
:ref:`Documentation/admin-guide/cgroup-v1/index.rst  misc.max
+
+   Limit can be set to max by::
+
+ # echo res_a max > misc.max
+
+Limits can be set higher than the capacity value in the misc.capacity
+file.
+
+Migration and Ownership
+~~~
+
+A miscellaneous scalar resource is charged to the cgroup in which it is used
+first, and stays charged to that cgroup until that resource is freed. Migrating
+a process to a different cgroup does not move the charge to the destination
+cgroup where the process has moved.
+
+Others
+--
+
 perf_event
 ~~
 
-- 
2.31.0.291.g576ba9dcdaf-goog

[PATCH v3] mm: fix race by making init_zero_pfn() early_initcall

[Ilya Lipnitskiy]

There are code paths that rely on zero_pfn to be fully initialized
before core_initcall. For example, wq_sysfs_init() is a core_initcall
function that eventually results in a call to kernel_execve, which
causes a page fault with a subsequent mmput. If zero_pfn is not
initialized by then it may not get cleaned up properly and result in an
error:
  BUG: Bad rss-counter state mm:(ptrval) type:MM_ANONPAGES val:1

Here is an analysis of the race as seen on a MIPS device. On this
particular MT7621 device (Ubiquiti ER-X), zero_pfn is PFN 0 until
initialized, at which point it becomes PFN 5120:
  1. wq_sysfs_init calls into kobject_uevent_env at core_initcall:
   [<80340dc8>] kobject_uevent_env+0x7e4/0x7ec
   [<8033f8b8>] kset_register+0x68/0x88
   [<803cf824>] bus_register+0xdc/0x34c
   [<803cfac8>] subsys_virtual_register+0x34/0x78
   [<8086afb0>] wq_sysfs_init+0x1c/0x4c
   [<80001648>] do_one_initcall+0x50/0x1a8
   [<8086503c>] kernel_init_freeable+0x230/0x2c8
   [<8066bca0>] kernel_init+0x10/0x100
   [<80003038>] ret_from_kernel_thread+0x14/0x1c

  2. kobject_uevent_env() calls call_usermodehelper_exec() which executes
 kernel_execve asynchronously.

  3. Memory allocations in kernel_execve cause a page fault, bumping the
 MM reference counter:
   [<8015adb4>] add_mm_counter_fast+0xb4/0xc0
   [<80160d58>] handle_mm_fault+0x6e4/0xea0
   [<80158aa4>] __get_user_pages.part.78+0x190/0x37c
   [<8015992c>] __get_user_pages_remote+0x128/0x360
   [<801a6d9c>] get_arg_page+0x34/0xa0
   [<801a7394>] copy_string_kernel+0x194/0x2a4
   [<801a880c>] kernel_execve+0x11c/0x298
   [<800420f4>] call_usermodehelper_exec_async+0x114/0x194

  4. In case zero_pfn has not been initialized yet, zap_pte_range does
 not decrement the MM_ANONPAGES RSS counter and the BUG message is
 triggered shortly afterwards when __mmdrop checks the ref counters:
   [<800285e8>] __mmdrop+0x98/0x1d0
   [<801a6de8>] free_bprm+0x44/0x118
   [<801a86a8>] kernel_execve+0x160/0x1d8
   [<800420f4>] call_usermodehelper_exec_async+0x114/0x194
   [<80003198>] ret_from_kernel_thread+0x14/0x1c

To avoid races such as described above, initialize init_zero_pfn at
early_initcall level. Depending on the architecture, ZERO_PAGE is either
constant or gets initialized even earlier, at paging_init, so there is
no issue with initializing zero_pfn earlier.

Discussion: 
https://lkml.kernel.org/r/CALCv0x2YqOXEAy2Q=hafjhHCtTHVodChv1qpM=niaxopqeb...@mail.gmail.com

Signed-off-by: Ilya Lipnitskiy 
Cc: Hugh Dickins 
Cc: "Eric W. Biederman" 
Cc: sta...@vger.kernel.org
---
 mm/memory.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mm/memory.c b/mm/memory.c
index 5c3b29d3af66..e66b11ac1659 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -166,7 +166,7 @@ static int __init init_zero_pfn(void)
zero_pfn = page_to_pfn(ZERO_PAGE(0));
return 0;
 }
-core_initcall(init_zero_pfn);
+early_initcall(init_zero_pfn);
 
 void mm_trace_rss_stat(struct mm_struct *mm, int member, long count)
 {
-- 
2.31.0

[PATCH v4 0/3] cgroup: New misc cgroup controller

[Vipin Sharma]

Hello,

This patch series is creating a new misc cgroup controller for limiting
and tracking of resources which are not abstract like other cgroup
controllers.

This controller was initially proposed as encryption_id but after the
feedbacks and use cases for other resources, it is now changed to misc
cgroup.
https://lore.kernel.org/lkml/20210108012846.4134815-2-vipi...@google.com/

Most of the cloud infrastructure use cgroups for knowing the host state,
track the resources usage, enforce limits on them, etc. They use this
info to optimize work allocation in the fleet and make sure no rogue job
consumes more than it needs and starves others.

There are resources on a system which are not abstract enough like other
cgroup controllers and are available in a limited quantity on a host.

One of them is Secure Encrypted Virtualization (SEV) ASID on AMD CPU.
SEV ASIDs are used for creating encrypted VMs. SEV is mostly be used by
the cloud providers for providing confidential VMs. Since SEV ASIDs are
limited, there is a need to schedule encrypted VMs in a cloud
infrastructure based on SEV ASIDs availability and also to limit its
usage.

There are similar requirements for other resource types like TDX keys,
IOASIDs and SEID.

Adding these resources to a cgroup controller is a natural choice with
least amount of friction. Cgroup itself says it is a mechanism to
distribute system resources along the hierarchy in a controlled
mechanism and configurable manner. Most of the resources in cgroups are
abstracted enough but there are still some resources which are not
abstract but have limited availability or have specific use cases.

Misc controller is a generic controller which can be used by these
kinds of resources.

One suggestion was to use BPF for this purpose, however, there are
couple of things which might not be addressed with BPF:
1. Which controller to use in v1 case? These are not abstract resources
   so in v1 where each controller have their own hierarchy it might not
   be easy to identify the best controller to use for BPF.

2. Abstracting out a single BPF program which can help with all of the
   resources types might not be possible, because resources we are
   working with are not similar and abstract enough, for example network
   packets, and there will be different places in the source code to use
   these resources.

A new cgroup controller tends to give much easier and well integrated
solution when it comes to scheduling and limiting a resource with
existing tools in a cloud infrastructure.

Changes in RFC v4:
1. Misc controller patch is split into two patches. One for generic misc
   controller and second for adding SEV and SEV-ES resource.
2. Using READ_ONCE and WRITE_ONCE for variable accesses.
3. Updated documentation.
4. Changed EXPORT_SYMBOL to EXPORT_SYMBOL_GPL.
5. Included cgroup header in misc_cgroup.h.
6. misc_cg_reduce_charge changed to misc_cg_cancel_charge.
7. misc_cg set to NULL after uncharge.
8. Added WARN_ON if misc_cg not NULL before charging in SEV/SEV-ES.

Changes in RFC v3:
1. Changed implementation to support 64 bit counters.
2. Print kernel logs only once per resource per cgroup.
3. Capacity can be set less than the current usage.

Changes in RFC v2:
1. Documentation fixes.
2. Added kernel log messages.
3. Changed charge API to treat misc_cg as input parameter.
4. Added helper APIs to get and release references on the cgroup.

[1] https://lore.kernel.org/lkml/20210218195549.1696769-1-vipi...@google.com
[2] https://lore.kernel.org/lkml/20210302081705.1990283-1-vipi...@google.com/
[3] https://lore.kernel.org/lkml/20210304231946.2766648-1-vipi...@google.com/

Vipin Sharma (3):
  cgroup: Add misc cgroup controller
  cgroup: Miscellaneous cgroup documentation.
  svm/sev: Register SEV and SEV-ES ASIDs to the misc controller

 Documentation/admin-guide/cgroup-v1/index.rst |   1 +
 Documentation/admin-guide/cgroup-v1/misc.rst  |   4 +
 Documentation/admin-guide/cgroup-v2.rst   |  73 +++-
 arch/x86/kvm/svm/sev.c|  70 ++-
 arch/x86/kvm/svm/svm.h|   1 +
 include/linux/cgroup_subsys.h |   4 +
 include/linux/misc_cgroup.h   | 132 ++
 init/Kconfig  |  14 +
 kernel/cgroup/Makefile|   1 +
 kernel/cgroup/misc.c  | 407 ++
 10 files changed, 695 insertions(+), 12 deletions(-)
 create mode 100644 Documentation/admin-guide/cgroup-v1/misc.rst
 create mode 100644 include/linux/misc_cgroup.h
 create mode 100644 kernel/cgroup/misc.c

-- 
2.31.0.291.g576ba9dcdaf-goog

Re: [PATCH] Documentation: crypto: add info about "fips=" boot option

[Herbert Xu]

On Mon, Mar 29, 2021 at 09:00:01PM -0700, Randy Dunlap wrote:
>
> + If fips_enabled = 1, some crypto tests are skipped.

I don't think any tests are skipped.  It does however disable
many algorithms by essentially failing them at the testing stage.

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

Re: [PATCH V8 2/8] cpufreq: mediatek: Enable clock and regulator

[Viresh Kumar]

On 23-03-21, 19:33, Andrew-sh.Cheng wrote:
> From: "Andrew-sh.Cheng" 
> 
> Need to enable regulator,
> so that the max/min requested value will be recorded
> even it is not applied right away.
> 
> Intermediate clock is not always enabled by ccf in different projects,
> so cpufreq should enable it by itself.
> 
> Signed-off-by: Andrew-sh.Cheng 
> ---
>  drivers/cpufreq/mediatek-cpufreq.c | 33 +
>  1 file changed, 29 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/cpufreq/mediatek-cpufreq.c 
> b/drivers/cpufreq/mediatek-cpufreq.c
> index f2e491b25b07..432368707ea6 100644
> --- a/drivers/cpufreq/mediatek-cpufreq.c
> +++ b/drivers/cpufreq/mediatek-cpufreq.c
> @@ -350,6 +350,11 @@ static int mtk_cpu_dvfs_info_init(struct 
> mtk_cpu_dvfs_info *info, int cpu)
>   ret = PTR_ERR(proc_reg);
>   goto out_free_resources;
>   }
> + ret = regulator_enable(proc_reg);
> + if (ret) {
> + pr_warn("enable vproc for cpu%d fail\n", cpu);
> + goto out_free_resources;
> + }

Regulators are enabled by OPP core as well now, you sure this is
required ?

-- 
viresh

[PATCH v2] nvmem: Change to unified property interface

[Kevin Paul Herbert]

Change from using device tree (Open Firmware) APIs to the unified
'fwnode' interface.

Change of_nvmem_cell_get() to fwnode_nvmem_cell_get(), and add a
wrapper for of_nvmem_cell_get().

Change of_nvmem_device_get() to fwnode_nvmem_device_get(). There
are no known accessors to the OF interface, so no need for a wrapper.

The first version of this patch incorrectly had a wrapper for
of_nvmem_device_get(), even though the comments about the patch
not needing this were correct.

Reported-by: kernel test robot 

Signed-off-by: Kevin Paul Herbert 
---
 drivers/nvmem/core.c   | 176 -
 include/linux/nvmem-consumer.h |  31 +++---
 2 files changed, 125 insertions(+), 82 deletions(-)

diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
index a5ab1e0c74cf..2e49304cd9a8 100644
--- a/drivers/nvmem/core.c
+++ b/drivers/nvmem/core.c
@@ -6,6 +6,7 @@
  * Copyright (C) 2013 Maxime Ripard 
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -17,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 struct nvmem_device {
@@ -52,7 +54,7 @@ struct nvmem_cell {
int bytes;
int bit_offset;
int nbits;
-   struct device_node  *np;
+   struct fwnode_handle*fwnode;
struct nvmem_device *nvmem;
struct list_headnode;
 };
@@ -424,7 +426,7 @@ static void nvmem_cell_drop(struct nvmem_cell *cell)
mutex_lock(_mutex);
list_del(>node);
mutex_unlock(_mutex);
-   of_node_put(cell->np);
+   fwnode_handle_put(cell->fwnode);
kfree_const(cell->name);
kfree(cell);
 }
@@ -670,39 +672,40 @@ static int nvmem_validate_keepouts(struct nvmem_device 
*nvmem)
return 0;
 }
 
-static int nvmem_add_cells_from_of(struct nvmem_device *nvmem)
+static int nvmem_add_cells_from_fw(struct nvmem_device *nvmem)
 {
-   struct device_node *parent, *child;
+   struct fwnode_handle *parent, *child;
struct device *dev = >dev;
struct nvmem_cell *cell;
-   const __be32 *addr;
-   int len;
+   int rval;
+   u32 vals[2];
 
-   parent = dev->of_node;
+   parent = dev_fwnode(dev);
 
-   for_each_child_of_node(parent, child) {
-   addr = of_get_property(child, "reg", );
-   if (!addr)
+   fwnode_for_each_child_node(parent, child) {
+   rval = fwnode_property_read_u32_array(child, "reg", NULL, 2);
+   if (rval < 0)
continue;
-   if (len < 2 * sizeof(u32)) {
-   dev_err(dev, "nvmem: invalid reg on %pOF\n", child);
+   if (rval < 2) {
+   dev_err(dev, "nvmem: invalid reg %d on %pfw\n",
+   rval, child);
return -EINVAL;
}
-
+   rval = fwnode_property_read_u32_array(child, "reg", vals, 2);
cell = kzalloc(sizeof(*cell), GFP_KERNEL);
if (!cell)
return -ENOMEM;
 
cell->nvmem = nvmem;
-   cell->np = of_node_get(child);
-   cell->offset = be32_to_cpup(addr++);
-   cell->bytes = be32_to_cpup(addr);
-   cell->name = kasprintf(GFP_KERNEL, "%pOFn", child);
-
-   addr = of_get_property(child, "bits", );
-   if (addr && len == (2 * sizeof(u32))) {
-   cell->bit_offset = be32_to_cpup(addr++);
-   cell->nbits = be32_to_cpup(addr);
+   cell->fwnode = child;
+   cell->offset = vals[0];
+   cell->bytes = vals[1];
+   cell->name = kasprintf(GFP_KERNEL, "%pfwn", child);
+
+   rval = fwnode_property_read_u32_array(child, "bits", vals, 2);
+   if (rval >= 0) {
+   cell->bit_offset = vals[0];
+   cell->nbits = vals[1];
}
 
if (cell->nbits)
@@ -715,7 +718,7 @@ static int nvmem_add_cells_from_of(struct nvmem_device 
*nvmem)
cell->name, nvmem->stride);
/* Cells already added will be freed later. */
kfree_const(cell->name);
-   of_node_put(cell->np);
+   fwnode_handle_put(cell->fwnode);
kfree(cell);
return -EINVAL;
}
@@ -789,8 +792,10 @@ struct nvmem_device *nvmem_register(const struct 
nvmem_config *config)
nvmem->reg_write = config->reg_write;
nvmem->keepout = config->keepout;
nvmem->nkeepout = config->nkeepout;
-   if (!config->no_of_node)
+   if (!config->no_of_node) {
nvmem->dev.of_node = config->dev->of_node;
+   nvmem->dev.fwnode = config->dev->fwnode;
+   }
 
switch (config->id) {
case NVMEM_DEVID_NONE:
@@ -841,7 

Re: [PATCH 2/2] gpiolib: Allow drivers to return EOPNOTSUPP from config

[Matti Vaittinen]

Morning Folks,

On Mon, 2021-03-29 at 16:30 +0300, Andy Shevchenko wrote:
> On Mon, Mar 29, 2021 at 03:20:07PM +0300, Matti Vaittinen wrote:
> > On Mon, 2021-03-29 at 14:59 +0300, Andy Shevchenko wrote:
> > > On Mon, Mar 29, 2021 at 2:43 PM Matti Vaittinen
> > >  wrote:
> > > > The checkpacth instructs to switch from ENOSUPP to EOPNOTSUPP.
> > > > > WARNING: ENOTSUPP is not a SUSV4 error code, prefer
> > > > > EOPNOTSUPP
> > > > 
> > > > Make the gpiolib allow drivers to return both so driver
> > > > developers
> > > > can avoid one of the checkpatch complaints.
> > > 
> > > Internally we are fine to use the ENOTSUPP.
> > > Checkpatch false positives there.
> > 
> > I agree. OTOH, the checkpatch check makes sense to user-visible
> > stuff.
> > Yet, the checkpatch has hard time guessing what is user-visible -
> > so it
> > probably is easiest to nag about all ENOTSUPP uses as it does now.
> > 
> > > I doubt we need this change. Rather checkpatch should rephrase
> > > this
> > > to
> > > point out that this is only applicable to _user-visible_ error
> > > path.
> > > Cc'ed Joe.
> > 
> > Yes, thanks for pulling Joe in.
> > 
> > Anyways, no matter what the warning says, all false positives are
> > annoying. I don't see why we should stay with ENOTSUPP in gpiolib?
> > (other than the burden of changing it).
> 
> For sake of the changing we are not changing the code.
No. But for the sake of making it better / more consistent :)

Anyway - after giving this second thought (thanks Andy for provoking me
to thinking this further) - I do agree with Andy that this particular
change is bad. More I think of this, less I like the idea of having two
separate return values to indicate the same thing. So we should support
only one which makes my patch terrible.

For the sake of consistency it would be cleaner to use same, single
value, for same error both inside the gpiolib and at user-interface.
That would be EOPNOTSUPP. As I said, having two separate error codes to
indicate same thing is confusing. Now the confusion is at the boundary
of gpiolib and user-land. Please educate me - is there difference in
the meaning of ENOTSUPP and EOPNOTSUPP or are they really indicating
the same thing? If yes, then yes - correct fix would be to use only one
and ditch the other. Whether the amount of work is such it is
practically worth is another topic - but that would be the right thing
to do (tm).

> 
> > But I have no strong opinion on this. All options I see have
> > downsides.
> > 
> > Accepting both ENOTSUPP and EOPNOTSUPP is the easy way to avoid
> > allowing checkpatch warnings - but I admit it isn't stylish.
> 
> I think the error code which is Linux kernel internal is for a
> reason.

If so, then the current checkpatch warning is even more questionable.

> 
> > Converting all ENOTSUPP cases inside gpiolib to EOPNOTSUPP is
> > teodious
> > although end result might be nicer.
> 
> Why? You still missed the justification except satisfying some tool
> that gives
> you false positives. We don't do that. It's the tool that has to be
> fixed /
> amended.
> 
> > Leaving it as is gives annoying false-positives to driver
> > developers.
> > 
> > My personal preference was this patch - others can have other view
> > like
> > Andy does. I'll leave this to community/maintainers to evaluate :)
> 
> This patch misses documentation fixes, for example.

Valid point.

> Also, do you suggest that we have to do the same in entire pin
> control
> subsystem?

After reading/writing this, I am unsure. This is why the discussion is
good :) I don't see why we should have two separate error codes for
same thing - but as you put it:

> I think the error code which is Linux kernel internal is for a
> reason.

not all of us thinks the same. So maybe I just don't get it? :)

Best Regards
Matti Vaittinen

[PATCH v2] nvmem: Change to unified property interface

[Kevin Paul Herbert]

The original version of this patch correctly stated that the only
wrapper needed was for of_nvmem_cell_get(), but included only a wrapper
for of_nvmem_device_get(). Replace with the proper wrapper.

[PATCH v2] nvmem: Change to unified property interface

[Kevin Paul Herbert]

THis first version of this patch erroneously had an unnecessary wrapper
for of_nvmem_device_get() even though the commentary properly stated
that the only wrapper needed was of_nvmem_cell_get(). Fix the code to
match the intent.

RE: [PATCH] usb: cdnsp: Fixes issue with Configure Endpoint command

[Pawel Laszczak]

Hi Peter,

>
>On 21-03-22 07:09:02, Pawel Laszczak wrote:
>> From: Pawel Laszczak 
>>
>> Patch adds flag EP_UNCONFIGURED to detect whether endpoint was
>> unconfigured. This flag is set in cdnsp_reset_device after Reset Device
>> command. Among others this command disables all non control endpoints.
>> Flag is used in cdnsp_gadget_ep_disable to protect controller against
>> invoking Configure Endpoint command on disabled endpoint. Lack of this
>> protection in some cases caused that Configure Endpoint command completed
>> with Context State Error code completion.
>>
>> Fixes: 3d82904559f4 ("usb: cdnsp: cdns3 Add main part of Cadence USBSSP DRD 
>> Driver")
>> Signed-off-by: Pawel Laszczak 
>> ---
>>  drivers/usb/cdns3/cdnsp-gadget.c | 18 +-
>>  drivers/usb/cdns3/cdnsp-gadget.h | 11 ++-
>>  2 files changed, 19 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/usb/cdns3/cdnsp-gadget.c 
>> b/drivers/usb/cdns3/cdnsp-gadget.c
>> index d7d4bdd57f46..de17cc4ad91a 100644
>> --- a/drivers/usb/cdns3/cdnsp-gadget.c
>> +++ b/drivers/usb/cdns3/cdnsp-gadget.c
>> @@ -727,7 +727,7 @@ int cdnsp_reset_device(struct cdnsp_device *pdev)
>>   * are in Disabled state.
>>   */
>>  for (i = 1; i < CDNSP_ENDPOINTS_NUM; ++i)
>> -pdev->eps[i].ep_state |= EP_STOPPED;
>> +pdev->eps[i].ep_state |= EP_STOPPED | EP_UNCONFIGURED;
>>
>>  trace_cdnsp_handle_cmd_reset_dev(slot_ctx);
>>
>> @@ -942,6 +942,7 @@ static int cdnsp_gadget_ep_enable(struct usb_ep *ep,
>>
>>  pep = to_cdnsp_ep(ep);
>>  pdev = pep->pdev;
>> +pep->ep_state &= ~EP_UNCONFIGURED;
>>
>>  if (dev_WARN_ONCE(pdev->dev, pep->ep_state & EP_ENABLED,
>>"%s is already enabled\n", pep->name))
>> @@ -1023,9 +1024,13 @@ static int cdnsp_gadget_ep_disable(struct usb_ep *ep)
>>  goto finish;
>>  }
>>
>> -cdnsp_cmd_stop_ep(pdev, pep);
>>  pep->ep_state |= EP_DIS_IN_RROGRESS;
>> -cdnsp_cmd_flush_ep(pdev, pep);
>> +
>> +/* Endpoint was unconfigured by Reset Device command. */
>> +if (!(pep->ep_state & EP_UNCONFIGURED)) {
>> +cdnsp_cmd_stop_ep(pdev, pep);
>> +cdnsp_cmd_flush_ep(pdev, pep);
>> +}
>>
>>  /* Remove all queued USB requests. */
>>  while (!list_empty(>pending_list)) {
>> @@ -1036,6 +1041,7 @@ static int cdnsp_gadget_ep_disable(struct usb_ep *ep)
>>  cdnsp_invalidate_ep_events(pdev, pep);
>>
>>  pep->ep_state &= ~EP_DIS_IN_RROGRESS;
>> +
>
>Useless blank line
>
>>  drop_flag = cdnsp_get_endpoint_flag(pep->endpoint.desc);
>>  ctrl_ctx = cdnsp_get_input_control_ctx(>in_ctx);
>>  ctrl_ctx->drop_flags = cpu_to_le32(drop_flag);
>> @@ -1043,10 +1049,12 @@ static int cdnsp_gadget_ep_disable(struct usb_ep *ep)
>>
>>  cdnsp_endpoint_zero(pdev, pep);
>>
>> -ret = cdnsp_update_eps_configuration(pdev, pep);
>> +if (!(pep->ep_state & EP_UNCONFIGURED))
>> +ret = cdnsp_update_eps_configuration(pdev, pep);
>> +
>>  cdnsp_free_endpoint_rings(pdev, pep);
>>
>> -pep->ep_state &= ~EP_ENABLED;
>> +pep->ep_state &= ~(EP_ENABLED | EP_UNCONFIGURED);
>>  pep->ep_state |= EP_STOPPED;
>>
>>  finish:
>> diff --git a/drivers/usb/cdns3/cdnsp-gadget.h 
>> b/drivers/usb/cdns3/cdnsp-gadget.h
>> index 6bbb26548c04..e628bd539e23 100644
>> --- a/drivers/usb/cdns3/cdnsp-gadget.h
>> +++ b/drivers/usb/cdns3/cdnsp-gadget.h
>> @@ -830,11 +830,12 @@ struct cdnsp_ep {
>>  unsigned int ep_state;
>>  #define EP_ENABLED  BIT(0)
>>  #define EP_DIS_IN_RROGRESS  BIT(1)
>> -#define EP_HALTED   BIT(2)
>> -#define EP_STOPPED  BIT(3)
>> -#define EP_WEDGEBIT(4)
>> -#define EP0_HALTED_STATUS   BIT(5)
>> -#define EP_HAS_STREAMS  BIT(6)
>> +#define EP_UNCONFIGURED BIT(2)
>
>Why add new flag as BIT(2), it causes many changes in this patch?

In my feeling, EP_UNCONFIGURED is more associates with the first 2 flags, so 
I've decided 
put it after BIT(1).  

>
>> +#define EP_HALTED   BIT(3)
>> +#define EP_STOPPED  BIT(4)
>> +#define EP_WEDGEBIT(5)
>> +#define EP0_HALTED_STATUS   BIT(6)
>> +#define EP_HAS_STREAMS  BIT(7)
>>
>>  bool skip;
>>  };
>> --
>> 2.25.1
>>
>
>--
>
>Thanks,
>Peter Chen

Re: [PATCH v4 0/5] Add Microchip PolarFire Soc Support

[Palmer Dabbelt]

On Wed, 03 Mar 2021 12:02:48 PST (-0800), Atish Patra wrote:

This series adds minimal support for Microchip Polar Fire Soc Icicle kit.
It is rebased on v5.12-rc1 and depends on clock support.
Only MMC and ethernet drivers are enabled via this series.
The idea here is to add the foundational patches so that other drivers
can be added to on top of this. The device tree may change based on
feedback on bindings of individual driver support patches.

This series has been tested on Qemu and Polar Fire Soc Icicle kit.
It depends on the updated clock-series[2] and macb fix[3].
The series is also tested by Lewis from Microchip.

The series can also be found at.
https://github.com/atishp04/linux/tree/polarfire_support_upstream_v4

[1] https://lists.nongnu.org/archive/html/qemu-devel/2020-10/msg08582.html
[2] https://www.spinics.net/lists/linux-clk/msg54579.html

Changes from v3->v4:
1. Fixed few DT specific issues.
2. Rebased on top of new clock driver.
3. SD card functionality is verified.

Changes from v2->v3:
1. Fixed a typo in dt binding.
2. Included MAINTAINERS entry for PolarFire SoC.
3. Improved the dts file by using lowercase clock names and keeping phy
   details in board specific dts file.

Changes from v1->v2:
1. Modified the DT to match the device tree in U-Boot.
2. Added both eMMC & SDcard entries in DT. However, SD card is only enabled
   as it allows larger storage option for linux distros.

Atish Patra (4):
RISC-V: Add Microchip PolarFire SoC kconfig option
dt-bindings: riscv: microchip: Add YAML documentation for the
PolarFire SoC
RISC-V: Initial DTS for Microchip ICICLE board
RISC-V: Enable Microchip PolarFire ICICLE SoC

Conor Dooley (1):
MAINTAINERS: add microchip polarfire soc support

.../devicetree/bindings/riscv/microchip.yaml  |  27 ++
MAINTAINERS   |   8 +
arch/riscv/Kconfig.socs   |   7 +
arch/riscv/boot/dts/Makefile  |   1 +
arch/riscv/boot/dts/microchip/Makefile|   2 +
.../microchip/microchip-mpfs-icicle-kit.dts   |  72 
.../boot/dts/microchip/microchip-mpfs.dtsi| 329 ++
arch/riscv/configs/defconfig  |   4 +
8 files changed, 450 insertions(+)
create mode 100644 Documentation/devicetree/bindings/riscv/microchip.yaml
create mode 100644 arch/riscv/boot/dts/microchip/Makefile
create mode 100644 arch/riscv/boot/dts/microchip/microchip-mpfs-icicle-kit.dts
create mode 100644 arch/riscv/boot/dts/microchip/microchip-mpfs.dtsi


I had this left in my inbox waiting for either some reviews to come in or a v2,
but I don't see any.  Did I miss something?

RE: [PATCH V4 05/18] iommu/ioasid: Redefine IOASID set and allocation APIs

[Tian, Kevin]

> From: Tian, Kevin
> Sent: Tuesday, March 30, 2021 10:24 AM
> 
> > From: Jason Gunthorpe 
> > Sent: Tuesday, March 30, 2021 12:32 AM
> > > In terms of usage for guest SVA, an ioasid_set is mostly tied to a host 
> > > mm,
> > > the use case is as the following:
> >
> > From that doc:
> >
> >   It is imperative to enforce
> >   VM-IOASID ownership such that a malicious guest cannot target DMA
> >   traffic outside its own IOASIDs, or free an active IOASID that belongs
> >   to another VM.
> >
> > Huh?
> >
> > Security in a PASID world comes from the IOMMU blocking access to the
> > PASID except from approved PCI-ID's. If a VF/PF is assigned to a guest
> > then that guest can cause the device to issue any PASID by having
> > complete control and the vIOMMU is supposed to tell the real IOMMU
> > what PASID's the device is alowed to access.
> >
> > If a device is sharing a single PCI function with different security
> > contexts (eg vfio mdev) then the device itself is responsible to
> > ensure that only the secure interface can program a PASID and a less
> > secure context can never self-enroll.
> >
> > Here the mdev driver would have to consule with the vIOMMU to ensure
> > the mdev device is allowed to access the PASID - is that what this
> > set stuff is about?
> >
> > If yes, it is backwards. The MDEV is the thing doing the security, the
> > MDEV should have the list of allowed PASID's and a single PASID
> > created under /dev/ioasid should be loaded into MDEV with some 'Ok you
> > can use PASID xyz from FD abc' command.
> >
> 
> The 'set' is per-VM. Once the mdev is assigned to a VM, all valid PASID's
> in the set of that VM are considered legitimate on this mdev. The mdev
> driver will mediate guest operations which program PASID to the backend
> context and load the PASID only if it is within the 'set' (i.e. already
> allocated through /dev/ioasid). This prevents a malicious VM from attacking
> others. Though it's not mdev which directly maintaining the list of allowed
> PASID's, the effect is the same in concept.
> 

One correction. The mdev should still construct the list of allowed PASID's as
you said (by listening to IOASID_BIND/UNBIND event), in addition to the ioasid 
set maintained per VM (updated when a PASID is allocated/freed). The per-VM
set is required for inter-VM isolation (verified when a pgtable is bound to the 
mdev/PASID), while the mdev's own list is necessary for intra-VM isolation when 
multiple mdevs are assigned to the same VM (verified before loading a PASID 
to the mdev). This series just handles the general part i.e. per-VM ioasid set 
and 
leaves the mdev's own list to be managed by specific mdev driver which listens
to various IOASID events).

Thanks
Kevin

crypto: possible NULL reference

[Randy Dunlap]

As I was trying to document "fips= here is not checked for NULL or not NULL
before it is used. Nor is the use of  in most other functions
in ecc.c.


Is there something else protecting the improper use of 
in these cases?  or is a patch warranted?


thanks.
-- 
~Randy

[PATCH] Documentation: crypto: add info about "fips=" boot option

[Randy Dunlap]

Having just seen a report of using "fips=1" on the kernel command line,
I could not find it documented anywhere, so add some help for it.

Signed-off-by: Randy Dunlap 
Cc: Dexuan Cui 
Cc: linux-cry...@vger.kernel.org
Cc: Eric Biggers 
Cc: Herbert Xu 
Cc: "David S. Miller" 
Cc: Jonathan Corbet 
Cc: linux-...@vger.kernel.org
---
Updates/corrections welcome.

 Documentation/admin-guide/kernel-parameters.txt |   15 ++
 1 file changed, 15 insertions(+)

--- linux-next-20210329.orig/Documentation/admin-guide/kernel-parameters.txt
+++ linux-next-20210329/Documentation/admin-guide/kernel-parameters.txt
@@ -1370,6 +1370,21 @@
See Documentation/admin-guide/sysctl/net.rst for
fb_tunnels_only_for_init_ns
 
+   fips=   Format: { 0 | 1}
+   Use to disable (0) or enable (1) FIPS mode.
+   If enabled, any process that is waiting on the
+   'fips_fail_notif_chain' will be notified of fips
+   failures.
+   This setting can also be modified via sysctl at
+   /proc/sysctl/crypto/fips_enabled, i.e.,
+   crypto.fips_enabled.
+   If fips_enabled = 1, some crypto tests are skipped.
+   It can also effect which ECC curve is used.
+   If fips_enabled = 1 and a test fails, it will cause a
+   kernel panic.
+   If fips_enabled = 1, RSA test requires a key size of
+   2K or larger.
+
floppy= [HW]
See Documentation/admin-guide/blockdev/floppy.rst.
 

Re: [PATCH 1/2] iommu/arm-smmu-qcom: Skip the TTBR1 quirk for db820c.

[Rob Clark]

On Mon, Mar 29, 2021 at 7:47 AM Will Deacon  wrote:
>
> On Fri, Mar 26, 2021 at 04:13:02PM -0700, Eric Anholt wrote:
> > db820c wants to use the qcom smmu path to get HUPCF set (which keeps
> > the GPU from wedging and then sometimes wedging the kernel after a
> > page fault), but it doesn't have separate pagetables support yet in
> > drm/msm so we can't go all the way to the TTBR1 path.
>
> What do you mean by "doesn't have separate pagetables support yet"? The
> compatible string doesn't feel like the right way to determine this.

the compatible string identifies what it is, not what the sw
limitations are, so in that regard it seems right to me..

BR,
-R

Re: [PATCH v2] media: venus : hfi: add venus image info into smem

[Bjorn Andersson]

On Fri 26 Mar 01:33 CDT 2021, Dikshita Agarwal wrote:

> Fill fw version info into smem to be printed as part of
> soc info.
> 
> Signed-off-by: Dikshita Agarwal 
> 
> Changes since v1:
>  adressed comments from stephen.
>  removed unwanted code.
> ---
>  drivers/media/platform/qcom/venus/hfi_msgs.c | 21 +++--
>  1 file changed, 19 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/media/platform/qcom/venus/hfi_msgs.c 
> b/drivers/media/platform/qcom/venus/hfi_msgs.c
> index 06a1908..6b6d33c9 100644
> --- a/drivers/media/platform/qcom/venus/hfi_msgs.c
> +++ b/drivers/media/platform/qcom/venus/hfi_msgs.c
> @@ -6,6 +6,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  #include "core.h"
> @@ -14,6 +15,10 @@
>  #include "hfi_msgs.h"
>  #include "hfi_parser.h"
>  
> +#define SMEM_IMG_VER_TBL 469
> +#define VER_STR_SZ   128
> +#define SMEM_IMG_INDEX_VENUS 14 * 128

14 is the index, 128 is the element size, so this is now an "offset".

> +
>  static void event_seq_changed(struct venus_core *core, struct venus_inst 
> *inst,
> struct hfi_msg_event_notify_pkt *pkt)
>  {
> @@ -239,15 +244,27 @@ static void
>  sys_get_prop_image_version(struct device *dev,
>  struct hfi_msg_sys_property_info_pkt *pkt)
>  {
> + size_t smem_blk_sz = 0;

You shouldn't need to initialize smem_blk_sz if you check the return
value of qcom_smem_get() first.

> + u8 *smem_tbl_ptr;
> + u8 *img_ver;
>   int req_bytes;
>  
>   req_bytes = pkt->hdr.size - sizeof(*pkt);
>  
> - if (req_bytes < 128 || !pkt->data[1] || pkt->num_properties > 1)
> + if (req_bytes < VER_STR_SZ || !pkt->data[1] || pkt->num_properties > 1)
>   /* bad packet */
>   return;
>  
> - dev_dbg(dev, VDBGL "F/W version: %s\n", (u8 *)>data[1]);
> + img_ver = (u8 *)>data[1];
> +
> + dev_dbg(dev, VDBGL "F/W version: %s\n", img_ver);
> +
> + smem_tbl_ptr = qcom_smem_get(QCOM_SMEM_HOST_ANY,
> +SMEM_IMG_VER_TBL, _blk_sz);

80 chars is just a guideline and this looks prettier if you avoid the
line wrap. That said, if you pick shorter names for smem_tbl_ptr and
smem_blk_sz you probably even have to worry.

> + if ((SMEM_IMG_INDEX_VENUS + VER_STR_SZ) <= smem_blk_sz &&
> + smem_tbl_ptr)

In English you're trying to determine: "did qcom_smem_get() return a
valid pointer and is the item's size at least as big as we need".

So just write that in C:

if (smem_tbl_ptr && smem_blk_sz >= SMEM_IMG_INDEX_VENUS + VER_STR_SZ)

> + memcpy(smem_tbl_ptr + SMEM_IMG_INDEX_VENUS,
> +img_ver, VER_STR_SZ);

Again, please avoid the line wrap...

Regards,
Bjorn

>  }
>  
>  static void hfi_sys_property_info(struct venus_core *core,
> -- 
> 2.7.4
> 

Re: [PATCH] scsi: ibmvscsi: delete the useless casting value returned

[Martin K. Petersen]

On Fri, 12 Mar 2021 10:18:53 +0800, Wang Qing wrote:

> Fix the following coccicheck warning:
> WARNING: casting value returned by memory allocation function is useless.

Applied to 5.13/scsi-queue, thanks!

[1/1] scsi: ibmvscsi: delete the useless casting value returned
  https://git.kernel.org/mkp/scsi/c/0d556a21a9da

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH 2/2] blktrace: limit allowed total trace buffer size

[Ming Lei]

On Tue, Mar 30, 2021 at 10:57:04AM +0800, Su Yue wrote:
> 
> On Tue 23 Mar 2021 at 16:14, Ming Lei  wrote:
> 
> > On some ARCHs, such as aarch64, page size may be 64K, meantime there may
> > be lots of CPU cores. relay_open() needs to allocate pages on each CPU
> > blktrace, so easily too many pages are taken by blktrace. For example,
> > on one ARM64 server: 224 CPU cores, 16G RAM, blktrace finally got
> > allocated 7GB in case of 'blktrace -b 8192' which is used by
> > device-mapper
> > test suite[1]. This way could cause OOM easily.
> > 
> > Fix the issue by limiting max allowed pages to be 1/8 of
> > totalram_pages().
> > 
> > [1] https://github.com/jthornber/device-mapper-test-suite.git
> > 
> > Signed-off-by: Ming Lei 
> > ---
> >  kernel/trace/blktrace.c | 32 
> >  1 file changed, 32 insertions(+)
> > 
> > diff --git a/kernel/trace/blktrace.c b/kernel/trace/blktrace.c
> > index c221e4c3f625..8403ff19d533 100644
> > --- a/kernel/trace/blktrace.c
> > +++ b/kernel/trace/blktrace.c
> > @@ -466,6 +466,35 @@ static void blk_trace_setup_lba(struct blk_trace
> > *bt,
> > }
> >  }
> > 
> > +/* limit total allocated buffer size is <= 1/8 of total pages */
> > +static void validate_and_adjust_buf(struct blk_user_trace_setup *buts)
> > +{
> > +   unsigned buf_size = buts->buf_size;
> > +   unsigned buf_nr = buts->buf_nr;
> > +   unsigned long max_allowed_pages = totalram_pages() >> 3;
> > +   unsigned long req_pages = PAGE_ALIGN(buf_size * buf_nr) >> PAGE_SHIFT;
> > +
> > +   if (req_pages * num_online_cpus() <= max_allowed_pages)
> > +   return;
> > +
> > +   req_pages = DIV_ROUND_UP(max_allowed_pages, num_online_cpus());
> > +
> > +   if (req_pages == 0) {
> > +   buf_size = PAGE_SIZE;
> > +   buf_nr = 1;
> > +   } else {
> > +   buf_size = req_pages << PAGE_SHIFT / buf_nr;
> > 
> Should it be:
> buf_size = (req_pages << PAGE_SHIFT) / buf_nr;
> ?
> The priority of '<<' is lower than '/', right? :)

Good catch, thanks!

-- 
Ming

Re: [PATCH RESEND] scsi: ufs: Remove unnecessary null checks in ufshcd_find_max_sup_active_icc_level()

[Martin K. Petersen]

On Fri, 19 Mar 2021 15:09:16 +0800, Yue Hu wrote:

> Since vcc/vccq/vccq2 have already been null checked before using.

Applied to 5.13/scsi-queue, thanks!

[1/1] scsi: ufs: Remove unnecessary null checks in 
ufshcd_find_max_sup_active_icc_level()
  https://git.kernel.org/mkp/scsi/c/0873045f63c4

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH] scsi: scsi_dh: Fix a typo

[Martin K. Petersen]

On Mon, 22 Mar 2021 12:17:24 +0530, Bhaskar Chowdhury wrote:

> s/infrastruture/infrastructure/

Applied to 5.13/scsi-queue, thanks!

[1/1] scsi: scsi_dh: Fix a typo
  https://git.kernel.org/mkp/scsi/c/ae98ddf05fdb

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH] scsi: bfa: Fix a typo in two places

[Martin K. Petersen]

On Tue, 23 Mar 2021 02:28:21 +0530, Bhaskar Chowdhury wrote:

> s/defintions/definitions/  two different places.

Applied to 5.13/scsi-queue, thanks!

[1/1] scsi: bfa: Fix a typo in two places
  https://git.kernel.org/mkp/scsi/c/9991ca001b9c

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH] scsi: mpt3sas: Fix a typo

[Martin K. Petersen]

On Mon, 22 Mar 2021 08:51:45 +0530, Bhaskar Chowdhury wrote:

> s/encloure/enclosure/

Applied to 5.13/scsi-queue, thanks!

[1/1] scsi: mpt3sas: Fix a typo
  https://git.kernel.org/mkp/scsi/c/206a3afa9482

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH] scsi: dc395x: Use bitwise instead of arithmetic operator for flags

[Martin K. Petersen]

On Tue, 9 Mar 2021 11:39:13 +0800, Jiapeng Chong wrote:

> Fix the following coccicheck warnings:
> 
> ./drivers/scsi/dc395x.c:2921:28-29: WARNING: sum of probable bitmasks,
> consider |.

Applied to 5.13/scsi-queue, thanks!

[1/1] scsi: dc395x: Use bitwise instead of arithmetic operator for flags
  https://git.kernel.org/mkp/scsi/c/973c920811bc

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH] scsi: fnic: delete the useless casting value returned

[Martin K. Petersen]

On Fri, 12 Mar 2021 10:18:19 +0800, Wang Qing wrote:

> Fix the following coccicheck warning:
> WARNING: casting value returned by memory allocation function is useless.

Applied to 5.13/scsi-queue, thanks!

[1/1] scsi: fnic: delete the useless casting value returned
  https://git.kernel.org/mkp/scsi/c/3ba9f38ed43d

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH] message: fusion: delete the useless casting value returned

[Martin K. Petersen]

On Fri, 12 Mar 2021 10:18:03 +0800, Wang Qing wrote:

> Fix the following coccicheck warning:
> WARNING: casting value returned by memory allocation function is useless.

Applied to 5.13/scsi-queue, thanks!

[1/1] message: fusion: delete the useless casting value returned
  https://git.kernel.org/mkp/scsi/c/690209d5ebef

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH] scsi: bnx2fc: Fix a typo

[Martin K. Petersen]

On Mon, 22 Mar 2021 12:05:30 +0530, Bhaskar Chowdhury wrote:

> s/struture/structure/

Applied to 5.13/scsi-queue, thanks!

[1/1] scsi: bnx2fc: Fix a typo
  https://git.kernel.org/mkp/scsi/c/5fae809faec6

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH] scsi: esp_scsi: Trivial typo fixes

[Martin K. Petersen]

On Wed, 24 Mar 2021 11:43:18 +0530, Bhaskar Chowdhury wrote:

> s/conditon/condition/
> s/pecularity/peculiarity/

Applied to 5.13/scsi-queue, thanks!

[1/1] scsi: esp_scsi: Trivial typo fixes
  https://git.kernel.org/mkp/scsi/c/835b8c16a0e3

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH] scsi: csiostor: Fix a typo

[Martin K. Petersen]

On Fri, 19 Mar 2021 14:53:11 +0530, Bhaskar Chowdhury wrote:

> s/boudaries/boundaries/

Applied to 5.13/scsi-queue, thanks!

[1/1] scsi: csiostor: Fix a typo
  https://git.kernel.org/mkp/scsi/c/a89562e31f01

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH] scsi: lpfc: A mundane typo fix

[Martin K. Petersen]

On Wed, 24 Mar 2021 12:18:29 +0530, Bhaskar Chowdhury wrote:

> s/conditons/conditions/

Applied to 5.13/scsi-queue, thanks!

[1/1] scsi: lpfc: A mundane typo fix
  https://git.kernel.org/mkp/scsi/c/f1891f9bbc46

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH] scsi: lpfc: Fix some typo error

[Martin K. Petersen]

On Mon, 22 Mar 2021 15:56:45 +0800, samirweng1979 wrote:

> change 'lenth' to 'length'.

Applied to 5.13/scsi-queue, thanks!

[1/1] scsi: lpfc: Fix some typo error
  https://git.kernel.org/mkp/scsi/c/89bbf550eafc

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH] scsi: pm8001: avoid -Wrestrict warning

[Martin K. Petersen]

On Tue, 23 Mar 2021 13:54:23 +0100, Arnd Bergmann wrote:

> On some configurations, gcc warns about overlapping source and
> destination arguments to snprintf:
> 
> drivers/scsi/pm8001/pm8001_init.c: In function 'pm8001_request_msix':
> drivers/scsi/pm8001/pm8001_init.c:977:3: error: 'snprintf' argument 4 may 
> overlap destination object 'pm8001_ha' [-Werror=restrict]
>   977 |   snprintf(drvname, len, "%s-%d", pm8001_ha->name, i);
>   |   ^~~
> drivers/scsi/pm8001/pm8001_init.c:962:56: note: destination object referenced 
> by 'restrict'-qualified argument 1 was declared here
>   962 | static u32 pm8001_request_msix(struct pm8001_hba_info *pm8001_ha)
>   |^
> 
> [...]

Applied to 5.13/scsi-queue, thanks!

[1/1] scsi: pm8001: avoid -Wrestrict warning
  https://git.kernel.org/mkp/scsi/c/c2255ece2be2

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH] scsi: qla1280: fix warning comparing pointer to 0

[Martin K. Petersen]

On Mon, 15 Mar 2021 11:49:19 +0800, Jiapeng Chong wrote:

> Fix the following coccicheck warning:
> 
> ./drivers/scsi/qla1280.c:3057:37-38: WARNING comparing pointer to 0.

Applied to 5.13/scsi-queue, thanks!

[1/1] scsi: qla1280: fix warning comparing pointer to 0
  https://git.kernel.org/mkp/scsi/c/3070c72155c5

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH] scsi: mac53c94: fix warning comparing pointer to 0

[Martin K. Petersen]

On Wed, 10 Mar 2021 12:16:11 +0800, Jiapeng Chong wrote:

> Fix the following coccicheck warning:
> 
> ./drivers/scsi/mac53c94.c:470:29-30: WARNING comparing pointer to 0.
> ./drivers/scsi/mac53c94.c:349:12-13: WARNING comparing pointer to 0.

Applied to 5.13/scsi-queue, thanks!

[1/1] scsi: mac53c94: fix warning comparing pointer to 0
  https://git.kernel.org/mkp/scsi/c/be20b96b6319

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH] scsi: bnx2i: make bnx2i_process_iscsi_error simpler and more robust

[Martin K. Petersen]

On Wed, 10 Mar 2021 23:16:02 +0100, Rasmus Villemoes wrote:

> Instead of strcpy'ing into a stack buffer, just let additional_notice
> point to a string literal living in .rodata. This is better in a few
> ways:
> 
> - Smaller .text - instead of gcc compiling the strcpys as a bunch of
>   immediate stores (effectively encoding the string literal in the
>   instruction stream), we only pay the price of storing the literal in
>   .rodata.
> 
> [...]

Applied to 5.13/scsi-queue, thanks!

[1/1] scsi: bnx2i: make bnx2i_process_iscsi_error simpler and more robust
  https://git.kernel.org/mkp/scsi/c/adb253433dc8

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH] scsi: bfa: fix warning comparing pointer to 0

[Martin K. Petersen]

On Tue, 16 Mar 2021 15:48:50 +0800, Jiapeng Chong wrote:

> Fix the following coccicheck warning:
> 
> ./drivers/scsi/bfa/bfad_bsg.c:3412:29-30: WARNING comparing pointer to
> 0.

Applied to 5.13/scsi-queue, thanks!

[1/1] scsi: bfa: fix warning comparing pointer to 0
  https://git.kernel.org/mkp/scsi/c/1630e752fb83

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH v3 1/2] dt-bindings: thermal: qcom-tsens: Add compatible for sm8350

[Bjorn Andersson]

On Wed 24 Mar 07:43 CDT 2021, Robert Foss wrote:

> Add tsens bindings for sm8350.
> 
> Signed-off-by: Robert Foss 
> Reviewed-by: Vinod Koul 

Reviewed-by: Bjorn Andersson 

@Daniel, I presume it's better that you take this patch (1/2) through
your tree. I've picked patch 2.

Regards,
Bjorn

> ---
> 
> Changes since v1:
>  - Vinod: Remove comment
> 
>  Documentation/devicetree/bindings/thermal/qcom-tsens.yaml | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml 
> b/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml
> index 95462e071ab4..e788378eff8d 100644
> --- a/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml
> +++ b/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml
> @@ -43,6 +43,7 @@ properties:
>- qcom,sdm845-tsens
>- qcom,sm8150-tsens
>- qcom,sm8250-tsens
> +  - qcom,sm8350-tsens
>- const: qcom,tsens-v2
>  
>reg:
> -- 
> 2.31.0.30.g398dba342d.dirty
> 

Re: [Question] Is there a race window between swapoff vs synchronous swap_readpage

[Huang, Ying]

Miaohe Lin  writes:

> On 2021/3/30 9:57, Huang, Ying wrote:
>> Hi, Miaohe,
>> 
>> Miaohe Lin  writes:
>> 
>>> Hi all,
>>> I am investigating the swap code, and I found the below possible race 
>>> window:
>>>
>>> CPU 1   CPU 2
>>> -   -
>>> do_swap_page
>>>   skip swapcache case (synchronous swap_readpage)
>>> alloc_page_vma
>>> swapoff
>>>   release swap_file, 
>>> bdev, or ...
>>>   swap_readpage
>>> check sis->flags is ok
>>>   access swap_file, bdev or ...[oops!]
>>> si->flags = 0
>>>
>>> The swapcache case is ok because swapoff will wait on the page_lock of 
>>> swapcache page.
>>> Is this will really happen or Am I miss something ?
>>> Any reply would be really grateful. Thanks! :)
>> 
>> This appears possible.  Even for swapcache case, we can't guarantee the
>
> Many thanks for reply!
>
>> swap entry gotten from the page table is always valid too.  The
>
> The page table may change at any time. And we may thus do some useless work.
> But the pte_same() check could handle these races correctly if these do not
> result in oops.
>
>> underlying swap device can be swapped off at the same time.  So we use
>> get/put_swap_device() for that.  Maybe we need similar stuff here.
>
> Using get/put_swap_device() to guard against swapoff for swap_readpage() 
> sounds
> really bad as swap_readpage() may take really long time. Also such race may 
> not be
> really hurtful because swapoff is usually done when system shutdown only.
> I can not figure some simple and stable stuff out to fix this. Any 
> suggestions or
> could anyone help get rid of such race?

Some reference counting on the swap device can prevent swap device from
swapping-off.  To reduce the performance overhead on the hot-path as
much as possible, it appears we can use the percpu_ref.

Best Regards,
Huang, Ying

Re:Re: [PATCH] linux/trace_events.h: Remove duplicate struct declaration

[万家兵]

 
>On Tue, 30 Mar 2021 09:55:17 +0800>Wan Jiabing  wrote:
>
>> struct trace_array is declared twice. One has been declared
>> at forward struct declaration. Remove the duplicate.
>> And sort these forward declarations alphabetically.
>
>Um, no that's not how we sort things.
>
>> 
>> Signed-off-by: Wan Jiabing 
>> ---
>>  include/linux/trace_events.h | 7 +++
>>  1 file changed, 3 insertions(+), 4 deletions(-)
>> 
>> diff --git a/include/linux/trace_events.h b/include/linux/trace_events.h
>> index 28e7af1406f2..29ae3ec5cab9 100644
>> --- a/include/linux/trace_events.h
>> +++ b/include/linux/trace_events.h
>> @@ -10,11 +10,11 @@
>>  #include 
>>  #include 
>>  
>> -struct trace_array;
>>  struct array_buffer;
>> -struct tracer;
>> -struct dentry;
>>  struct bpf_prog;
>> +struct dentry;
>> +struct tracer;
>> +struct trace_array;
>
>NAK to the above. If anything, we sort it by length. But the above doesn't
>need to be touched.
>

OK, I know. I resend the v2.
Please review.

Yours,
Wan Jiabing

>>  
>>  const char *trace_print_flags_seq(struct trace_seq *p, const char *delim,
>>unsigned long flags,
>> @@ -404,7 +404,6 @@ trace_get_fields(struct trace_event_call *event_call)
>>  return event_call->class->get_fields(event_call);
>>  }
>>  
>> -struct trace_array;
>
>This part is fine.
>
>Thanks,
>
>-- Steve
>
>>  struct trace_subsystem_dir;
>>  
>>  enum {
>

Re: [PATCH v2 1/5] hwmon: (max31790) Rework to use regmap

[Václav Kubernát]

Hi Guenter,

Thank you for the comments. I will fix the issues in a V3 patch.

About the mutex: I was looking at regmap and saw it did locking by
itself. But I suppose writing still has to be locked, because the
write function writes more than once. I will add the mutex back.

Václav

út 30. 3. 2021 v 0:27 odesílatel Guenter Roeck  napsal:
>
> On Tue, Mar 16, 2021 at 06:54:58PM +0100, Václav Kubernát wrote:
> > Converting the driver to use regmap makes it more generic. It also makes
> > it a lot easier to debug through debugfs.
> >
> > Signed-off-by: Václav Kubernát 
>
> Comments are in addition to comments from Dan and 0-day.
>
> > ---
> >  drivers/hwmon/Kconfig|   1 +
> >  drivers/hwmon/max31790.c | 318 ---
> >  2 files changed, 163 insertions(+), 156 deletions(-)
> >
> > diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
> > index 54f04e61fb83..c2ec57672c4e 100644
> > --- a/drivers/hwmon/Kconfig
> > +++ b/drivers/hwmon/Kconfig
> > @@ -1092,6 +1092,7 @@ config SENSORS_MAX6697
> >  config SENSORS_MAX31790
> >   tristate "Maxim MAX31790 sensor chip"
> >   depends on I2C
> > + select REGMAP_I2C
> >   help
> > If you say yes here you get support for 6-Channel PWM-Output
> > Fan RPM Controller.
> > diff --git a/drivers/hwmon/max31790.c b/drivers/hwmon/max31790.c
> > index 86e6c71db685..4e5add567890 100644
> > --- a/drivers/hwmon/max31790.c
> > +++ b/drivers/hwmon/max31790.c
> > @@ -12,6 +12,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >
> >  /* MAX31790 registers */
> > @@ -46,92 +47,49 @@
> >
> >  #define NR_CHANNEL   6
> >
> > +#define MAX31790_REG_USER_BYTE_670x67
> > +
> > +#define BULK_TO_U16(msb, lsb)(((msb) << 8) + (lsb))
> > +#define U16_MSB(num) (((num) & 0xFF00) >> 8)
> > +#define U16_LSB(num) ((num) & 0x00FF)
> > +
> > +static const struct regmap_range max31790_ro_range = {
> > + .range_min = MAX31790_REG_TACH_COUNT(0),
> > + .range_max = MAX31790_REG_PWMOUT(0) - 1,
> > +};
> > +
> > +static const struct regmap_access_table max31790_wr_table = {
> > + .no_ranges = _ro_range,
> > + .n_no_ranges = 1,
> > +};
> > +
> > +static const struct regmap_range max31790_volatile_ranges[] = {
> > + regmap_reg_range(MAX31790_REG_TACH_COUNT(0), 
> > MAX31790_REG_TACH_COUNT(12)),
> > + regmap_reg_range(MAX31790_REG_FAN_FAULT_STATUS2, 
> > MAX31790_REG_FAN_FAULT_STATUS1),
> > +};
> > +
> > +static const struct regmap_access_table max31790_volatile_table = {
> > + .no_ranges = max31790_volatile_ranges,
> > + .n_no_ranges = 2,
> > + .n_yes_ranges = 0
> > +};
> > +
> > +static const struct regmap_config max31790_regmap_config = {
> > + .reg_bits = 8,
> > + .val_bits = 8,
> > + .reg_stride = 1,
> > + .max_register = MAX31790_REG_USER_BYTE_67,
> > + .wr_table = _wr_table,
> > + .volatile_table = _volatile_table
> > +};
> > +
> >  /*
> >   * Client data (each client gets its own)
> >   */
> >  struct max31790_data {
> > - struct i2c_client *client;
> > - struct mutex update_lock;
> > - bool valid; /* zero until following fields are valid */
> > - unsigned long last_updated; /* in jiffies */
> > -
> > - /* register values */
> > - u8 fan_config[NR_CHANNEL];
> > - u8 fan_dynamics[NR_CHANNEL];
> > - u16 fault_status;
> > - u16 tach[NR_CHANNEL * 2];
> > - u16 pwm[NR_CHANNEL];
> > - u16 target_count[NR_CHANNEL];
> > + struct regmap *regmap;
> >  };
> >
> > -static struct max31790_data *max31790_update_device(struct device *dev)
> > -{
> > - struct max31790_data *data = dev_get_drvdata(dev);
> > - struct i2c_client *client = data->client;
> > - struct max31790_data *ret = data;
> > - int i;
> > - int rv;
> > -
> > - mutex_lock(>update_lock);
> > -
> > - if (time_after(jiffies, data->last_updated + HZ) || !data->valid) {
> > - rv = i2c_smbus_read_byte_data(client,
> > - MAX31790_REG_FAN_FAULT_STATUS1);
> > - if (rv < 0)
> > - goto abort;
> > - data->fault_status = rv & 0x3F;
> > -
> > - rv = i2c_smbus_read_byte_data(client,
> > - MAX31790_REG_FAN_FAULT_STATUS2);
> > - if (rv < 0)
> > - goto abort;
> > - data->fault_status |= (rv & 0x3F) << 6;
> > -
> > - for (i = 0; i < NR_CHANNEL; i++) {
> > - rv = i2c_smbus_read_word_swapped(client,
> > - MAX31790_REG_TACH_COUNT(i));
> > - if (rv < 0)
> > - goto abort;
> > - data->tach[i] = rv;
> > -
> > - if (data->fan_config[i]
> > - & MAX31790_FAN_CFG_TACH_INPUT) {
> > - rv = 

RE: [PATCH] usb: cdns3: delete repeated clear operations

[Pawel Laszczak]

>
>On 21-03-22 07:19:46, Pawel Laszczak wrote:
>> Hi Peter,
>>
>> Can you add this patch to for-usb-next branch.
>>
>
>Feel free add your ACK base on this patch.
>
>Peter
>> Thanks.
>>
>> >
>> >
>> >dma_alloc_coherent already zeroes out memory, so memset is not needed.
>> >
>> >Signed-off-by: Wang Qing 
>>
>> Reviewed-by: Pawel Laszczak 


Acked-by: Pawel Laszczak 

>>
>> >---
>> > drivers/usb/cdns3/cdnsp-mem.c | 1 -
>> > 1 file changed, 1 deletion(-)
>> >
>> >diff --git a/drivers/usb/cdns3/cdnsp-mem.c b/drivers/usb/cdns3/cdnsp-mem.c
>> >index 7a84e92..1d1b9a4
>> >--- a/drivers/usb/cdns3/cdnsp-mem.c
>> >+++ b/drivers/usb/cdns3/cdnsp-mem.c
>> >@@ -1231,7 +1231,6 @@ int cdnsp_mem_init(struct cdnsp_device *pdev)
>> >if (!pdev->dcbaa)
>> >return -ENOMEM;
>> >
>> >-   memset(pdev->dcbaa, 0, sizeof(*pdev->dcbaa));
>> >pdev->dcbaa->dma = dma;
>> >
>> >cdnsp_write_64(dma, >op_regs->dcbaa_ptr);
>> >--
>> >2.7.4
>>
>> Regards,
>> Pawel Laszczak
>
>--
>
>Thanks,
>Peter Chen

Regards,
Pawel Laszczak

Re: [PATCH v3] kernel/resource: Fix locking in request_free_mem_region

[John Hubbard]

On 3/29/21 5:38 PM, Alistair Popple wrote:

request_free_mem_region() is used to find an empty range of physical
addresses for hotplugging ZONE_DEVICE memory. It does this by iterating
over the range of possible addresses using region_intersects() to see if
the range is free.

region_intersects() obtains a read lock before walking the resource tree
to protect against concurrent changes. However it drops the lock prior
to returning. This means by the time request_mem_region() is called in
request_free_mem_region() another thread may have already reserved the
requested region resulting in unexpected failures and a message in the
kernel log from hitting this condition:

 /*
  * mm/hmm.c reserves physical addresses which then
  * become unavailable to other users.  Conflicts are
  * not expected.  Warn to aid debugging if encountered.
  */
 if (conflict->desc == IORES_DESC_DEVICE_PRIVATE_MEMORY) {
 pr_warn("Unaddressable device %s %pR conflicts with %pR",
 conflict->name, conflict, res);

To fix this create versions of region_intersects() and
request_mem_region() that allow the caller to take the appropriate lock
such that it may be held over the required calls.

Instead of creating another version of devm_request_mem_region() that
doesn't take the lock open-code it to allow the caller to pre-allocate
the required memory prior to taking the lock.

Fixes: 0c385190392d8 ("resource: add a not device managed request_free_mem_region 
variant")
Fixes: 0092908d16c60 ("mm: factor out a devm_request_free_mem_region helper")


Hi Alistair!

The above "Fixes:" tag looks wrong to me, because that commit did not create
the broken locking that this patch fixes. Therefore, I think that particular 
line
should be removed from the commit description.

Another note below:


Fixes: 4ef589dc9b10c ("mm/hmm/devmem: device memory hotplug using ZONE_DEVICE")
Signed-off-by: Alistair Popple 
Acked-by: Balbir Singh 
Reported-by: kernel test robot 

---

Hi Andrew,

This fixes a boot issue reported by the kernel test robot with the
previous version of the patch on x86 with CONFIG_IO_STRICT_DEVMEM=y.
This was due to the platform specific implementation of
devmem_is_allowed() creating a recursive lock which I missed. I notice
you have put v2 in mmtom so apologies for the churn but can you please
use this version instead? Thanks.

  - Alistair
---
  kernel/resource.c | 142 ++
  1 file changed, 92 insertions(+), 50 deletions(-)

diff --git a/kernel/resource.c b/kernel/resource.c
index 627e61b0c124..7061b9f903ca 100644
--- a/kernel/resource.c
+++ b/kernel/resource.c
@@ -523,6 +523,34 @@ int __weak page_is_ram(unsigned long pfn)
  }
  EXPORT_SYMBOL_GPL(page_is_ram);
  
+static int __region_intersects(resource_size_t start, size_t size,

+  unsigned long flags, unsigned long desc)
+{
+   struct resource res;
+   int type = 0; int other = 0;
+   struct resource *p;
+
+   res.start = start;
+   res.end = start + size - 1;
+
+   for (p = iomem_resource.child; p ; p = p->sibling) {
+   bool is_type = (((p->flags & flags) == flags) &&
+   ((desc == IORES_DESC_NONE) ||
+(desc == p->desc)));
+
+   if (resource_overlaps(p, ))
+   is_type ? type++ : other++;
+   }
+
+   if (type == 0)
+   return REGION_DISJOINT;
+
+   if (other == 0)
+   return REGION_INTERSECTS;
+
+   return REGION_MIXED;
+}
+
  /**
   * region_intersects() - determine intersection of region with known resources
   * @start: region start address
@@ -546,31 +574,12 @@ EXPORT_SYMBOL_GPL(page_is_ram);
  int region_intersects(resource_size_t start, size_t size, unsigned long flags,
  unsigned long desc)
  {
-   struct resource res;
-   int type = 0; int other = 0;
-   struct resource *p;
-
-   res.start = start;
-   res.end = start + size - 1;
+   int rc;
  
  	read_lock(_lock);

-   for (p = iomem_resource.child; p ; p = p->sibling) {
-   bool is_type = (((p->flags & flags) == flags) &&
-   ((desc == IORES_DESC_NONE) ||
-(desc == p->desc)));
-
-   if (resource_overlaps(p, ))
-   is_type ? type++ : other++;
-   }
+   rc = __region_intersects(start, size, flags, desc);
read_unlock(_lock);
-
-   if (type == 0)
-   return REGION_DISJOINT;
-
-   if (other == 0)
-   return REGION_INTERSECTS;
-
-   return REGION_MIXED;
+   return rc;
  }
  EXPORT_SYMBOL_GPL(region_intersects);
  
@@ -1171,31 +1180,16 @@ struct address_space *iomem_get_mapping(void)

return smp_load_acquire(_inode)->i_mapping;
  }
  
-/**

- * __request_region - create a new busy resource 

[PATCH] [v2] linux/trace_events.h: Remove duplicate struct declaration

[Wan Jiabing]

struct trace_array is declared twice. One has been declared
at forward declaration. Remove the duplicate.

Signed-off-by: Wan Jiabing 
---
Changelog:
v2:
- Undo sorting forward declarations alphabetically.
---
 include/linux/trace_events.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/include/linux/trace_events.h b/include/linux/trace_events.h
index 28e7af1406f2..0237094e51f6 100644
--- a/include/linux/trace_events.h
+++ b/include/linux/trace_events.h
@@ -404,7 +404,6 @@ trace_get_fields(struct trace_event_call *event_call)
return event_call->class->get_fields(event_call);
 }
 
-struct trace_array;
 struct trace_subsystem_dir;
 
 enum {
-- 
2.25.1

Re: [PATCH 3/5] arm: dts: qcom: Add support for MSM8226 SoC

[Bjorn Andersson]

On Fri 26 Mar 09:58 CDT 2021, Bartosz Dudziak wrote:

> This patch adds basic device tree support for MSM8226 SoC which belongs
> to the Snapdragon 400 family. For now, this file adds the basic nodes
> like gcc, pinctrl and other required configuration for booting up to
> the serial console.
> 
> Signed-off-by: Bartosz Dudziak 
> ---
>  arch/arm/boot/dts/qcom-msm8226.dtsi | 152 
>  1 file changed, 152 insertions(+)
>  create mode 100644 arch/arm/boot/dts/qcom-msm8226.dtsi
> 
> diff --git a/arch/arm/boot/dts/qcom-msm8226.dtsi 
> b/arch/arm/boot/dts/qcom-msm8226.dtsi
> new file mode 100644
> index 00..81bb19398e
> --- /dev/null
> +++ b/arch/arm/boot/dts/qcom-msm8226.dtsi
> @@ -0,0 +1,152 @@
> +// SPDX-License-Identifier: GPL-2.0

Can you please make this BSD license?

> +/*
> + * Copyright (c) 2020, The Linux Foundation. All rights reserved.
> + */
> +
> +/dts-v1/;
> +
> +#include 
> +#include 
> +
> +/ {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + model = "Qualcomm Technologies, Inc. MSM8226";
> + compatible = "qcom,msm8226";

model and compatible should always be specified in the .dts, so the ones
specified here would be overwritten. So drop them here.

> + interrupt-parent = <>;
> +
> + chosen { };
> +
> + memory {
> + device_type = "memory";
> + /* We expect the bootloader to fill in the size */
> + reg = <0x0 0x0>;
> + };
> +
> + soc: soc {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> + compatible = "simple-bus";
> +
> + intc: interrupt-controller@f900 {
> + compatible = "qcom,msm-qgic2";
> + interrupt-controller;
> + #interrupt-cells = <3>;
> + reg = <0xF900 0x1000>,
> +   <0xF9002000 0x1000>;
> + };
> +
> + gcc: clock-controller@fc40 {
> + compatible = "qcom,gcc-msm8226";
> + #clock-cells = <1>;
> + #reset-cells = <1>;
> + #power-domain-cells = <1>;
> + reg = <0xfc40 0x4000>;
> + };
> +
> + msmgpio: pinctrl@fd51 {

Rename the label "tlmm"

> + compatible = "qcom,msm8226-pinctrl";
> + reg = <0xfd51 0x4000>;
> + gpio-controller;
> + #gpio-cells = <2>;
> + gpio-ranges = < 0 0 117>;
> + interrupt-controller;
> + #interrupt-cells = <2>;
> + interrupts = ;
> + };
> +
> + blsp1_uart3: serial@f991f000 {
> + compatible = "qcom,msm-uartdm-v1.4", "qcom,msm-uartdm";
> + reg = <0xf991f000 0x1000>;
> + interrupts = ;
> + clocks = < GCC_BLSP1_UART3_APPS_CLK>, < 
> GCC_BLSP1_AHB_CLK>;
> + clock-names = "core", "iface";
> + status = "disabled";
> + };
> +
> + restart@fc4ab000 {
> + compatible = "qcom,pshold";
> + reg = <0xfc4ab000 0x4>;
> + };
> +
> + rng@f9bff000 {
> + compatible = "qcom,prng";
> + reg = <0xf9bff000 0x200>;
> + clocks = < GCC_PRNG_AHB_CLK>;
> + clock-names = "core";
> + };
> +
> + timer@f902 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> + compatible = "arm,armv7-timer-mem";

It's nice to have compatible & reg first in the nodes.

Regards,
Bjorn

> + reg = <0xf902 0x1000>;
> + clock-frequency = <1920>;
> +
> + frame@f9021000 {
> + frame-number = <0>;
> + interrupts = ,
> +  ;
> + reg = <0xf9021000 0x1000>,
> +   <0xf9022000 0x1000>;
> + };
> +
> + frame@f9023000 {
> + frame-number = <1>;
> + interrupts = ;
> + reg = <0xf9023000 0x1000>;
> + status = "disabled";
> + };
> +
> + frame@f9024000 {
> + frame-number = <2>;
> + interrupts = ;
> + reg = <0xf9024000 0x1000>;
> + status = "disabled";
> + };
> +
> + frame@f9025000 {
> + frame-number = <3>;
> +

RE: [PATCH] usb: cdnsp: remove redundant initialization of variable ret

[Pawel Laszczak]

Hi Colin,

Thanks for this fix. 

>
>From: Colin Ian King 
>
>The variable ret is being initialized with a value that is
>never read and it is being updated later with a new value.  The
>initialization is redundant and can be removed.
>
>Addresses-Coverity: ("Unused value")
>Signed-off-by: Colin Ian King 

Reviewed-by: Pawel Laszczak 

>---
> drivers/usb/cdns3/cdnsp-mem.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff --git a/drivers/usb/cdns3/cdnsp-mem.c b/drivers/usb/cdns3/cdnsp-mem.c
>index 7a84e928710e..d87b640e7b49 100644
>--- a/drivers/usb/cdns3/cdnsp-mem.c
>+++ b/drivers/usb/cdns3/cdnsp-mem.c
>@@ -686,7 +686,7 @@ static void cdnsp_free_priv_device(struct cdnsp_device 
>*pdev)
>
> static int cdnsp_alloc_priv_device(struct cdnsp_device *pdev)
> {
>-  int ret = -ENOMEM;
>+  int ret;
>
>   ret = cdnsp_init_device_ctx(pdev);
>   if (ret)
>--
>2.30.2

Regards,
Pawel Laszczak

Re: [PATCH] drm/msm: Fix removal of valid error case when checking speed_bin

[Akhil P Oommen]

On 3/30/2021 7:04 AM, John Stultz wrote:

Commit 7bf168c8fe8c  ("drm/msm: Fix speed-bin support not to
access outside valid memory"), reworked the nvmem reading of
"speed_bin", but in doing so dropped handling of the -ENOENT
case which was previously documented as "fine".

That change resulted in the db845c board display to fail to
start, with the following error:

adreno 500.gpu: [drm:a6xx_gpu_init] *ERROR* failed to read speed-bin (-2). 
Some OPPs may not be supported by hardware

Thus, this patch simply re-adds the ENOENT handling so the lack
of the speed_bin entry isn't fatal for display, and gets things
working on db845c.

Cc: Rob Clark 
Cc: Sean Paul 
Cc: Jordan Crouse 
Cc: Eric Anholt 
Cc: Douglas Anderson 
Cc: linux-arm-...@vger.kernel.org
Cc: freedr...@lists.freedesktop.org
Cc: Bjorn Andersson 
Cc: YongQin Liu 
Reported-by: YongQin Liu 
Fixes: 7bf168c8fe8c  ("drm/msm: Fix speed-bin support not to access outside valid 
memory")
Signed-off-by: John Stultz 
---
  drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 8 +++-
  1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index 690409ca8a186..cb2df8736ca85 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -1406,7 +1406,13 @@ static int a6xx_set_supported_hw(struct device *dev, 
struct a6xx_gpu *a6xx_gpu,
int ret;
  
  	ret = nvmem_cell_read_u16(dev, "speed_bin", );

-   if (ret) {
+   /*
+* -ENOENT means that the platform doesn't support speedbin which is
+* fine
+*/
+   if (ret == -ENOENT) {
+   return 0;
+   } else if (ret) {
DRM_DEV_ERROR(dev,
  "failed to read speed-bin (%d). Some OPPs may not be 
supported by hardware",
  ret);



Reviewed-by: Akhil P Oommen 

This looks "fine" to me. ;)

-Akhil.

Re: [PATCH v2 2/6] clk: sifive: Use reset-simple in prci driver for PCIe driver

[Greentime Hu]

Stephen Boyd  於 2021年3月30日 週二 上午3:14寫道：
>
> Quoting Greentime Hu (2021-03-17 23:08:09)
> > diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
> > index 71ab75a46491..f094df93d911 100644
> > --- a/drivers/reset/Kconfig
> > +++ b/drivers/reset/Kconfig
> > @@ -173,7 +173,7 @@ config RESET_SCMI
> >
> >  config RESET_SIMPLE
> > bool "Simple Reset Controller Driver" if COMPILE_TEST
> > -   default ARCH_AGILEX || ARCH_ASPEED || ARCH_BITMAIN || ARCH_REALTEK 
> > || ARCH_STM32 || ARCH_STRATIX10 || ARCH_SUNXI || ARCH_ZX || ARC
> > +   default ARCH_AGILEX || ARCH_ASPEED || ARCH_BITMAIN || ARCH_REALTEK 
> > || ARCH_STM32 || ARCH_STRATIX10 || ARCH_SUNXI || ARCH_ZX || ARC || RISCV
>
> This conflicts. Can this default be part of the riscv defconfig instead?
>

Maybe I should remove this since it has been selected by CLK_SIFIVE_PRCI?

 config CLK_SIFIVE_PRCI
bool "PRCI driver for SiFive SoCs"
+   select RESET_CONTROLLER
+   select RESET_SIMPLE

> > help
> >   This enables a simple reset controller driver for reset lines that
> >   that can be asserted and deasserted by toggling bits in a 
> > contiguous,
> > @@ -187,6 +187,7 @@ config RESET_SIMPLE
> >- RCC reset controller in STM32 MCUs
> >- Allwinner SoCs
> >- ZTE's zx2967 family
> > +  - SiFive FU740 SoCs
> >
> >  config RESET_STM32MP157
> > bool "STM32MP157 Reset Driver" if COMPILE_TEST

Re: [PATCH v5 7/7] arm64: dts: qcom: use dp_phy to provide clocks to dispcc

[Bjorn Andersson]

On Sun 28 Mar 15:52 CDT 2021, Dmitry Baryshkov wrote:

> Plug dp_phy-provided clocks to display clock controller.
> 

Reviewed-by: Bjorn Andersson 

Regards,
Bjorn

> Signed-off-by: Dmitry Baryshkov 
> ---
>  arch/arm64/boot/dts/qcom/sm8250.dtsi | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/qcom/sm8250.dtsi 
> b/arch/arm64/boot/dts/qcom/sm8250.dtsi
> index 0f79e6885004..a2478bd3590a 100644
> --- a/arch/arm64/boot/dts/qcom/sm8250.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sm8250.dtsi
> @@ -2600,8 +2600,8 @@ dispcc: clock-controller@af0 {
><_phy 1>,
><_phy 0>,
><_phy 1>,
> -  <0>,
> -  <0>,
> +  <_phy 0>,
> +  <_phy 1>,
><0>,
><0>,
><0>,
> @@ -2614,8 +2614,8 @@ dispcc: clock-controller@af0 {
> "dsi0_phy_pll_out_dsiclk",
> "dsi1_phy_pll_out_byteclk",
> "dsi1_phy_pll_out_dsiclk",
> -   "dp_link_clk_divsel_ten",
> -   "dp_vco_divided_clk_src_mux",
> +   "dp_phy_pll_link_clk",
> +   "dp_phy_pll_vco_div_clk",
> "dptx1_phy_pll_link_clk",
> "dptx1_phy_pll_vco_div_clk",
> "dptx2_phy_pll_link_clk",
> -- 
> 2.30.2
> 

Re: [PATCH v5 6/7] arm64: dts: qcom: sm8250: switch usb1 qmp phy to USB3+DP mode

[Bjorn Andersson]

On Sun 28 Mar 15:52 CDT 2021, Dmitry Baryshkov wrote:

> USB1 QMP PHY is not just a USB3 PHY, but USB3+DP PHY. Change device tree
> nodes accordingly.
> 
> Signed-off-by: Dmitry Baryshkov 

Reviewed-by: Bjorn Andersson 

@Vinod, will you let me know when you've picked the driver changes so I
can pick the two DT patches?

Regards,
Bjorn

> ---
>  arch/arm64/boot/dts/qcom/sm8250.dtsi | 23 ++-
>  1 file changed, 18 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/qcom/sm8250.dtsi 
> b/arch/arm64/boot/dts/qcom/sm8250.dtsi
> index 947e1accae3a..0f79e6885004 100644
> --- a/arch/arm64/boot/dts/qcom/sm8250.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sm8250.dtsi
> @@ -2097,12 +2097,11 @@ usb_2_hsphy: phy@88e4000 {
>   };
>  
>   usb_1_qmpphy: phy@88e9000 {
> - compatible = "qcom,sm8250-qmp-usb3-phy";
> + compatible = "qcom,sm8250-qmp-usb3-dp-phy";
>   reg = <0 0x088e9000 0 0x200>,
> -   <0 0x088e8000 0 0x20>;
> - reg-names = "reg-base", "dp_com";
> +   <0 0x088e8000 0 0x40>,
> +   <0 0x088ea000 0 0x200>;
>   status = "disabled";
> - #clock-cells = <1>;
>   #address-cells = <2>;
>   #size-cells = <2>;
>   ranges;
> @@ -2116,7 +2115,7 @@ usb_1_qmpphy: phy@88e9000 {
>< GCC_USB3_PHY_PRIM_BCR>;
>   reset-names = "phy", "common";
>  
> - usb_1_ssphy: lanes@88e9200 {
> + usb_1_ssphy: usb3-phy@88e9200 {
>   reg = <0 0x088e9200 0 0x200>,
> <0 0x088e9400 0 0x200>,
> <0 0x088e9c00 0 0x400>,
> @@ -2128,6 +2127,20 @@ usb_1_ssphy: lanes@88e9200 {
>   clock-names = "pipe0";
>   clock-output-names = "usb3_phy_pipe_clk_src";
>   };
> +
> + dp_phy: dp-phy@88ea200 {
> + reg = <0 0x088ea200 0 0x200>,
> +   <0 0x088ea400 0 0x200>,
> +   <0 0x088eac00 0 0x400>,
> +   <0 0x088ea600 0 0x200>,
> +   <0 0x088ea800 0 0x200>,
> +   <0 0x088eaa00 0 0x100>;
> + #phy-cells = <0>;
> + #clock-cells = <1>;
> + clocks = < GCC_USB3_PRIM_PHY_PIPE_CLK>;
> + clock-names = "pipe0";
> + clock-output-names = "usb3_phy_pipe_clk_src";
> + };
>   };
>  
>   usb_2_qmpphy: phy@88eb000 {
> -- 
> 2.30.2
> 

Re: [PATCH] hwmon: Add driver for fsp-3y PSUs and PDUs

[Václav Kubernát]

Hi Guenter,

Thank you for the review.

po 29. 3. 2021 v 19:47 odesílatel Guenter Roeck  napsal:
>
> On 3/29/21 7:38 AM, Václav Kubernát wrote:
> > After some testing, I have found out there is a timing issue with this
> > device. After setting page, the device doesn't immediately react and
> > gives values from the previous page for some time. This is why there
> > needs to be a delay between pmbus_set_page and the actual read.
> >
> > Also, a lot of the standard commands don't work with the devices, so
> > they are filtered out in the custom read function.
> >
>
> This is not an appropriate patch description. Describe the driver here,
> not the workarounds / quirks. The reason for the delay should be a
> comment in the patch, not in the patch description.
>
> Also, "don't work" is inappropriate (and, again, does not belong into
> the patch description). It is perfectly appropriate for the core
> to try those commands to see if they are supported. The only reason
> to mask them out would be that the device reacts badly to seeing
> them. If that is the case, "don't work" should be replaced with
> a more detailed comment in the code. Describe what happens, and why
> the commands needs to be caught.
>
>
> What might be useful is a note indicating if you have a manual for
> those power supplies available, or if the driver is based on reverse
> engineering.
>

I will rework the commit message in a V2 patch.

> > Signed-off-by: Václav Kubernát 
> > ---
> >  drivers/hwmon/pmbus/Kconfig  |   9 ++
> >  drivers/hwmon/pmbus/Makefile |   1 +
> >  drivers/hwmon/pmbus/fsp-3y.c | 164 +++
>
> Documentation/hwmon/fsp-3y.rst is missing.
>
> >  3 files changed, 174 insertions(+)
> >  create mode 100644 drivers/hwmon/pmbus/fsp-3y.c
> >
> > diff --git a/drivers/hwmon/pmbus/Kconfig b/drivers/hwmon/pmbus/Kconfig
> > index 03606d4298a4..66d1655b6750 100644
> > --- a/drivers/hwmon/pmbus/Kconfig
> > +++ b/drivers/hwmon/pmbus/Kconfig
> > @@ -56,6 +56,15 @@ config SENSORS_BEL_PFE
> > This driver can also be built as a module. If so, the module will
> > be called bel-pfe.
> >
> > +config SENSORS_FSP_3Y
> > + tristate "FSP/3Y-Power power supplies"
> > + help
> > +   If you say yes here you get hardware monitoring support for
> > +   FSP/3Y-Power hot-swap power supplies.
> > +
>
> This should list the supported models - if not here, then at least in the
> (missing) documentation.
>

Okay.

> > +   This driver can also be built as a module. If so, the module will
> > +   be called fsp-3y.
> > +
> >  config SENSORS_IBM_CFFPS
> >   tristate "IBM Common Form Factor Power Supply"
> >   depends on LEDS_CLASS
> > diff --git a/drivers/hwmon/pmbus/Makefile b/drivers/hwmon/pmbus/Makefile
> > index 6a4ba0fdc1db..bfe218ad898f 100644
> > --- a/drivers/hwmon/pmbus/Makefile
> > +++ b/drivers/hwmon/pmbus/Makefile
> > @@ -8,6 +8,7 @@ obj-$(CONFIG_SENSORS_PMBUS)   += pmbus.o
> >  obj-$(CONFIG_SENSORS_ADM1266)+= adm1266.o
> >  obj-$(CONFIG_SENSORS_ADM1275)+= adm1275.o
> >  obj-$(CONFIG_SENSORS_BEL_PFE)+= bel-pfe.o
> > +obj-$(CONFIG_SENSORS_FSP_3Y) += fsp-3y.o
> >  obj-$(CONFIG_SENSORS_IBM_CFFPS)  += ibm-cffps.o
> >  obj-$(CONFIG_SENSORS_INSPUR_IPSPS) += inspur-ipsps.o
> >  obj-$(CONFIG_SENSORS_IR35221)+= ir35221.o
> > diff --git a/drivers/hwmon/pmbus/fsp-3y.c b/drivers/hwmon/pmbus/fsp-3y.c
> > new file mode 100644
> > index ..7f3c3de3a1e6
> > --- /dev/null
> > +++ b/drivers/hwmon/pmbus/fsp-3y.c
> > @@ -0,0 +1,164 @@
> > +// SPDX-License-Identifier: GPL-2.0-or-later
> > +/*
> > + * Hardware monitoring driver for FSP 3Y-Power PSUs
> > + *
> > + * Copyright (c) 2021 Václav Kubernát, CESNET
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
>
> Alphabetic include file order, please.
>
> > +#include "pmbus.h"
> > +
> > +#define YM2151_PAGE_12V  0x00
> > +#define YM2151_PAGE_5V   0x20
> > +#define YH5151E_PAGE_12V 0x00
> > +#define YH5151E_PAGE_5V  0x10
> > +#define YH5151E_PAGE_3V3 0x11
> > +
> > +enum chips {
> > + ym2151e,
> > + yh5151e
> > +};
> > +
> > +static int set_page(struct i2c_client *client, int page)
> > +{
> > + int rv;
> > +
> > + rv = i2c_smbus_read_byte_data(client, PMBUS_PAGE);
> > +
> Please no empty line here.
>
> You might want to consider caching the current page to avoid having to read it
> for each access, similar to the code implemented in the pmbus core.
>

This was actually what I wanted to do at first, but I wasn't able to
get i2c_set_clientdata to work. Later I found out that it is because
pmbus_do_probe uses sets it own data. What do you think I should use
to cache the page?

> > + if (rv < 0)
> > + return rv;
> > +
> > + if (rv != page) {
> > + rv = pmbus_set_page(client, page, 0xff);
> > + if (rv < 0)
> > + return rv;
> > +
> > + msleep(20);
>

Re: [PATCH v5 5/7] phy: qcom-qmp: add support for sm8250-usb3-dp phy

[Bjorn Andersson]

On Sun 28 Mar 15:52 CDT 2021, Dmitry Baryshkov wrote:

> Add support for QMP V4 Combo USB3+DP PHY (for SM8250 platform).
> 
> Signed-off-by: Dmitry Baryshkov 

Acked-by: Bjorn Andersson 

Regards,
Bjorn

> ---
>  drivers/phy/qualcomm/phy-qcom-qmp.c | 388 ++--
>  drivers/phy/qualcomm/phy-qcom-qmp.h |  40 ++-
>  2 files changed, 406 insertions(+), 22 deletions(-)
> 
> diff --git a/drivers/phy/qualcomm/phy-qcom-qmp.c 
> b/drivers/phy/qualcomm/phy-qcom-qmp.c
> index 097bc005ba43..a47da2fff7a1 100644
> --- a/drivers/phy/qualcomm/phy-qcom-qmp.c
> +++ b/drivers/phy/qualcomm/phy-qcom-qmp.c
> @@ -1840,6 +1840,86 @@ static const struct qmp_phy_init_tbl 
> sm8250_usb3_uniphy_pcs_tbl[] = {
>   QMP_PHY_INIT_CFG(QPHY_V4_PCS_REFGEN_REQ_CONFIG1, 0x21),
>  };
>  
> +static const struct qmp_phy_init_tbl qmp_v4_dp_serdes_tbl[] = {
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_SVS_MODE_CLK_SEL, 0x05),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_SYSCLK_EN_SEL, 0x3b),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_SYS_CLK_CTRL, 0x02),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_CLK_ENABLE1, 0x0c),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_SYSCLK_BUF_ENABLE, 0x06),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_CLK_SELECT, 0x30),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_PLL_IVCO, 0x0f),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_PLL_CCTRL_MODE0, 0x36),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_PLL_RCTRL_MODE0, 0x16),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_CP_CTRL_MODE0, 0x06),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_CMN_CONFIG, 0x02),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_INTEGLOOP_GAIN0_MODE0, 0x3f),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_INTEGLOOP_GAIN1_MODE0, 0x00),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_VCO_TUNE_MAP, 0x00),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_DIV_FRAC_START1_MODE0, 0x00),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_BG_TIMER, 0x0a),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_CORECLK_DIV_MODE0, 0x0a),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_VCO_TUNE_CTRL, 0x00),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_BIAS_EN_CLKBUFLR_EN, 0x17),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_CORE_CLK_EN, 0x1f),
> +};
> +
> +static const struct qmp_phy_init_tbl qmp_v4_dp_serdes_tbl_rbr[] = {
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_HSCLK_SEL, 0x05),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_DEC_START_MODE0, 0x69),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_DIV_FRAC_START2_MODE0, 0x80),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_DIV_FRAC_START3_MODE0, 0x07),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_LOCK_CMP1_MODE0, 0x6f),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_LOCK_CMP2_MODE0, 0x08),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_LOCK_CMP_EN, 0x04),
> +};
> +
> +static const struct qmp_phy_init_tbl qmp_v4_dp_serdes_tbl_hbr[] = {
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_HSCLK_SEL, 0x03),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_DEC_START_MODE0, 0x69),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_DIV_FRAC_START2_MODE0, 0x80),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_DIV_FRAC_START3_MODE0, 0x07),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_LOCK_CMP1_MODE0, 0x0f),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_LOCK_CMP2_MODE0, 0x0e),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_LOCK_CMP_EN, 0x08),
> +};
> +
> +static const struct qmp_phy_init_tbl qmp_v4_dp_serdes_tbl_hbr2[] = {
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_HSCLK_SEL, 0x01),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_DEC_START_MODE0, 0x8c),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_DIV_FRAC_START2_MODE0, 0x00),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_DIV_FRAC_START3_MODE0, 0x0a),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_LOCK_CMP1_MODE0, 0x1f),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_LOCK_CMP2_MODE0, 0x1c),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_LOCK_CMP_EN, 0x08),
> +};
> +
> +static const struct qmp_phy_init_tbl qmp_v4_dp_serdes_tbl_hbr3[] = {
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_HSCLK_SEL, 0x00),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_DEC_START_MODE0, 0x69),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_DIV_FRAC_START2_MODE0, 0x80),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_DIV_FRAC_START3_MODE0, 0x07),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_LOCK_CMP1_MODE0, 0x2f),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_LOCK_CMP2_MODE0, 0x2a),
> + QMP_PHY_INIT_CFG(QSERDES_V4_COM_LOCK_CMP_EN, 0x08),
> +};
> +
> +static const struct qmp_phy_init_tbl qmp_v4_dp_tx_tbl[] = {
> + QMP_PHY_INIT_CFG(QSERDES_V4_TX_VMODE_CTRL1, 0x40),
> + QMP_PHY_INIT_CFG(QSERDES_V4_TX_PRE_STALL_LDO_BOOST_EN, 0x30),
> + QMP_PHY_INIT_CFG(QSERDES_V4_TX_INTERFACE_SELECT, 0x3b),
> + QMP_PHY_INIT_CFG(QSERDES_V4_TX_CLKBUF_ENABLE, 0x0f),
> + QMP_PHY_INIT_CFG(QSERDES_V4_TX_RESET_TSYNC_EN, 0x03),
> + QMP_PHY_INIT_CFG(QSERDES_V4_TX_TRAN_DRVR_EMP_EN, 0x0f),
> + QMP_PHY_INIT_CFG(QSERDES_V4_TX_PARRATE_REC_DETECT_IDLE_EN, 0x00),
> + QMP_PHY_INIT_CFG(QSERDES_V4_TX_TX_INTERFACE_MODE, 0x00),
> + QMP_PHY_INIT_CFG(QSERDES_V4_TX_RES_CODE_LANE_OFFSET_TX, 0x11),
> + QMP_PHY_INIT_CFG(QSERDES_V4_TX_RES_CODE_LANE_OFFSET_RX, 0x11),
> + 

Re: [PATCH v5 4/7] phy: qcom-qmp: rename common registers

[Bjorn Andersson]

On Sun 28 Mar 15:52 CDT 2021, Dmitry Baryshkov wrote:

> A plenty of DP PHY registers are common between V3 and V4. To simplify
> V4 code, rename all common registers.
> 
> Signed-off-by: Dmitry Baryshkov 

Reviewed-by: Bjorn Andersson 

Regards,
Bjorn

> ---
>  drivers/phy/qualcomm/phy-qcom-qmp.c | 50 ++---
>  drivers/phy/qualcomm/phy-qcom-qmp.h | 37 ++---
>  2 files changed, 44 insertions(+), 43 deletions(-)
> 
> diff --git a/drivers/phy/qualcomm/phy-qcom-qmp.c 
> b/drivers/phy/qualcomm/phy-qcom-qmp.c
> index 4150096fd350..097bc005ba43 100644
> --- a/drivers/phy/qualcomm/phy-qcom-qmp.c
> +++ b/drivers/phy/qualcomm/phy-qcom-qmp.c
> @@ -2435,20 +2435,20 @@ static void qcom_qmp_v3_phy_dp_aux_init(struct 
> qmp_phy *qphy)
>  {
>   writel(DP_PHY_PD_CTL_PWRDN | DP_PHY_PD_CTL_AUX_PWRDN |
>  DP_PHY_PD_CTL_PLL_PWRDN | DP_PHY_PD_CTL_DP_CLAMP_EN,
> -qphy->pcs + QSERDES_V3_DP_PHY_PD_CTL);
> +qphy->pcs + QSERDES_DP_PHY_PD_CTL);
>  
>   /* Turn on BIAS current for PHY/PLL */
>   writel(QSERDES_V3_COM_BIAS_EN | QSERDES_V3_COM_BIAS_EN_MUX |
>  QSERDES_V3_COM_CLKBUF_L_EN | QSERDES_V3_COM_EN_SYSCLK_TX_SEL,
>  qphy->serdes + QSERDES_V3_COM_BIAS_EN_CLKBUFLR_EN);
>  
> - writel(DP_PHY_PD_CTL_PSR_PWRDN, qphy->pcs + QSERDES_V3_DP_PHY_PD_CTL);
> + writel(DP_PHY_PD_CTL_PSR_PWRDN, qphy->pcs + QSERDES_DP_PHY_PD_CTL);
>  
>   writel(DP_PHY_PD_CTL_PWRDN | DP_PHY_PD_CTL_AUX_PWRDN |
>  DP_PHY_PD_CTL_LANE_0_1_PWRDN |
>  DP_PHY_PD_CTL_LANE_2_3_PWRDN | DP_PHY_PD_CTL_PLL_PWRDN |
>  DP_PHY_PD_CTL_DP_CLAMP_EN,
> -qphy->pcs + QSERDES_V3_DP_PHY_PD_CTL);
> +qphy->pcs + QSERDES_DP_PHY_PD_CTL);
>  
>   writel(QSERDES_V3_COM_BIAS_EN |
>  QSERDES_V3_COM_BIAS_EN_MUX | QSERDES_V3_COM_CLKBUF_R_EN |
> @@ -2456,16 +2456,16 @@ static void qcom_qmp_v3_phy_dp_aux_init(struct 
> qmp_phy *qphy)
>  QSERDES_V3_COM_CLKBUF_RX_DRIVE_L,
>  qphy->serdes + QSERDES_V3_COM_BIAS_EN_CLKBUFLR_EN);
>  
> - writel(0x00, qphy->pcs + QSERDES_V3_DP_PHY_AUX_CFG0);
> - writel(0x13, qphy->pcs + QSERDES_V3_DP_PHY_AUX_CFG1);
> - writel(0x24, qphy->pcs + QSERDES_V3_DP_PHY_AUX_CFG2);
> - writel(0x00, qphy->pcs + QSERDES_V3_DP_PHY_AUX_CFG3);
> - writel(0x0a, qphy->pcs + QSERDES_V3_DP_PHY_AUX_CFG4);
> - writel(0x26, qphy->pcs + QSERDES_V3_DP_PHY_AUX_CFG5);
> - writel(0x0a, qphy->pcs + QSERDES_V3_DP_PHY_AUX_CFG6);
> - writel(0x03, qphy->pcs + QSERDES_V3_DP_PHY_AUX_CFG7);
> - writel(0xbb, qphy->pcs + QSERDES_V3_DP_PHY_AUX_CFG8);
> - writel(0x03, qphy->pcs + QSERDES_V3_DP_PHY_AUX_CFG9);
> + writel(0x00, qphy->pcs + QSERDES_DP_PHY_AUX_CFG0);
> + writel(0x13, qphy->pcs + QSERDES_DP_PHY_AUX_CFG1);
> + writel(0x24, qphy->pcs + QSERDES_DP_PHY_AUX_CFG2);
> + writel(0x00, qphy->pcs + QSERDES_DP_PHY_AUX_CFG3);
> + writel(0x0a, qphy->pcs + QSERDES_DP_PHY_AUX_CFG4);
> + writel(0x26, qphy->pcs + QSERDES_DP_PHY_AUX_CFG5);
> + writel(0x0a, qphy->pcs + QSERDES_DP_PHY_AUX_CFG6);
> + writel(0x03, qphy->pcs + QSERDES_DP_PHY_AUX_CFG7);
> + writel(0xbb, qphy->pcs + QSERDES_DP_PHY_AUX_CFG8);
> + writel(0x03, qphy->pcs + QSERDES_DP_PHY_AUX_CFG9);
>   qphy->dp_aux_cfg = 0;
>  
>   writel(PHY_AUX_STOP_ERR_MASK | PHY_AUX_DEC_ERR_MASK |
> @@ -2556,9 +2556,9 @@ static int qcom_qmp_v3_phy_configure_dp_phy(struct 
> qmp_phy *qphy)
>*  writel(0x4c, qphy->pcs + QSERDES_V3_DP_PHY_MODE);
>*/
>   val |= DP_PHY_PD_CTL_LANE_2_3_PWRDN;
> - writel(val, qphy->pcs + QSERDES_V3_DP_PHY_PD_CTL);
> + writel(val, qphy->pcs + QSERDES_DP_PHY_PD_CTL);
>  
> - writel(0x5c, qphy->pcs + QSERDES_V3_DP_PHY_MODE);
> + writel(0x5c, qphy->pcs + QSERDES_DP_PHY_MODE);
>   writel(0x05, qphy->pcs + QSERDES_V3_DP_PHY_TX0_TX1_LANE_CTL);
>   writel(0x05, qphy->pcs + QSERDES_V3_DP_PHY_TX2_TX3_LANE_CTL);
>  
> @@ -2588,11 +2588,11 @@ static int qcom_qmp_v3_phy_configure_dp_phy(struct 
> qmp_phy *qphy)
>   clk_set_rate(dp_clks->dp_link_hw.clk, dp_opts->link_rate * 10);
>   clk_set_rate(dp_clks->dp_pixel_hw.clk, pixel_freq);
>  
> - writel(0x04, qphy->pcs + QSERDES_V3_DP_PHY_AUX_CFG2);
> - writel(0x01, qphy->pcs + QSERDES_V3_DP_PHY_CFG);
> - writel(0x05, qphy->pcs + QSERDES_V3_DP_PHY_CFG);
> - writel(0x01, qphy->pcs + QSERDES_V3_DP_PHY_CFG);
> - writel(0x09, qphy->pcs + QSERDES_V3_DP_PHY_CFG);
> + writel(0x04, qphy->pcs + QSERDES_DP_PHY_AUX_CFG2);
> + writel(0x01, qphy->pcs + QSERDES_DP_PHY_CFG);
> + writel(0x05, qphy->pcs + QSERDES_DP_PHY_CFG);
> + writel(0x01, qphy->pcs + QSERDES_DP_PHY_CFG);
> + writel(0x09, qphy->pcs + QSERDES_DP_PHY_CFG);
>  
>   writel(0x20, qphy->serdes + QSERDES_V3_COM_RESETSM_CNTRL);
>  
> @@ -2603,7 +2603,7 @@ static int qcom_qmp_v3_phy_configure_dp_phy(struct 
> qmp_phy *qphy)
>   1))
>  

Re: [PATCH] linux/trace_events.h: Remove duplicate struct declaration

[Steven Rostedt]

On Tue, 30 Mar 2021 09:55:17 +0800
Wan Jiabing  wrote:

> struct trace_array is declared twice. One has been declared
> at forward struct declaration. Remove the duplicate.
> And sort these forward declarations alphabetically.

Um, no that's not how we sort things.

> 
> Signed-off-by: Wan Jiabing 
> ---
>  include/linux/trace_events.h | 7 +++
>  1 file changed, 3 insertions(+), 4 deletions(-)
> 
> diff --git a/include/linux/trace_events.h b/include/linux/trace_events.h
> index 28e7af1406f2..29ae3ec5cab9 100644
> --- a/include/linux/trace_events.h
> +++ b/include/linux/trace_events.h
> @@ -10,11 +10,11 @@
>  #include 
>  #include 
>  
> -struct trace_array;
>  struct array_buffer;
> -struct tracer;
> -struct dentry;
>  struct bpf_prog;
> +struct dentry;
> +struct tracer;
> +struct trace_array;

NAK to the above. If anything, we sort it by length. But the above doesn't
need to be touched.

>  
>  const char *trace_print_flags_seq(struct trace_seq *p, const char *delim,
> unsigned long flags,
> @@ -404,7 +404,6 @@ trace_get_fields(struct trace_event_call *event_call)
>   return event_call->class->get_fields(event_call);
>  }
>  
> -struct trace_array;

This part is fine.

Thanks,

-- Steve

>  struct trace_subsystem_dir;
>  
>  enum {

Re: [PATCH bpf-next 5/5] libbpf: add selftests for TC-BPF API

[Alexei Starovoitov]

On Sun, Mar 28, 2021 at 07:38:42PM -0700, Andrii Nakryiko wrote:
> 
> See above. I don't know which hassle is libbpf for users today. You
> were implying code size used for functionality users might not use
> (e.g., linker). Libbpf is a very small library, <300KB. There are
> users building tools for constrained embedded systems that use libbpf.
> There are/were various problems mentioned, but the size of libbpf
> wasn't yet one of them. We should certainly watch the code bloat, but
> we are not yet at the point where library is too big for users to be
> turned off. 

It's true that today sizeof(libbpf + libelf + libz) ~ 500k is not a concern.
I'm worried what it will get to if we don't start splitting things up.

Why split libxdp into its own lib?
If tc attach is going to part of libbpf all things xdp should be
part of libbpf as well.

But af_xdp folks are probably annoyed that they need to add -lelf an -lz
though they're not using them. Just a tech debt that eventually need to be paid.

> > I would take this opportunity to split libbpf into maintainable pieces:
> > - libsysbpf - sys_bpf wrappers (pretty much tools/lib/bpf/bpf.c)
> > - libbpfutil - hash, strset
> 
> strset and hash are internal data structures, I never intended to
> expose them through public APIs. I haven't investigated, but if we
> have a separate shared library (libbpfutil), I imagine we won't be
> able to hide those APIs, right?

In the other thread you've proposed to copy paste hash implemenation
into pahole. That's not ideal. If we had libbpfutil other projects
could have used that without copy-paste.

> But again, let's just reflect for a second that we are talking about
> the library that takes less than 300KB total. 

that's today. Plus mandatory libelf and libz.
I would like to have libsysbpf that doesn't depend on libelf/libz
for folks that don't need it.
Also I'd like to see symbolizer to be included in "libbpf package".
Currently it's the main component that libbcc offers, but libbpf doesn't.
Say we don't split libbpf. Then symbolizer will bring some dwarf library
(say libdwarves ~ 1Mbyte) and libiberty ~ 500k (for c++ demangle).
Now we're looking at multi megabyte libbpf package.
I think the users would benefit from smaller building blocks.
Splitting into 10 mini libs is overkill, of course,
but some split is necessary.
I agree that moving static linking into separate lib won't really
affect .text size. The point is not to reduce text, but to establish
a framework where such things are possible. Then symbolizer and
anything fancier that would depend on other libs can be part
of "libbpf package". I mean single rpm that contains all libbpf libs.
Basic libsysbpf wouldn't need libelf/z.
libbpfsymbolizer would need libdwarf, etc.
Maybe some libbpfnet would depend on libnl or what not.

Re: [PATCH v5 3/7] phy: qcom-qmp: move DP functions to callbacks

[Bjorn Andersson]

On Sun 28 Mar 15:52 CDT 2021, Dmitry Baryshkov wrote:

> In preparation to adding support for V4 DP PHY move DP functions to
> callbacks at struct qmp_phy_cfg.
> 

Reviewed-by: Bjorn Andersson 

Regards,
Bjorn

> Signed-off-by: Dmitry Baryshkov 
> ---
>  drivers/phy/qualcomm/phy-qcom-qmp.c | 438 +++-
>  1 file changed, 231 insertions(+), 207 deletions(-)
> 
> diff --git a/drivers/phy/qualcomm/phy-qcom-qmp.c 
> b/drivers/phy/qualcomm/phy-qcom-qmp.c
> index 9cdebe7f26cb..4150096fd350 100644
> --- a/drivers/phy/qualcomm/phy-qcom-qmp.c
> +++ b/drivers/phy/qualcomm/phy-qcom-qmp.c
> @@ -2268,6 +2268,8 @@ static const struct qmp_phy_init_tbl 
> sm8350_usb3_uniphy_pcs_tbl[] = {
>   QMP_PHY_INIT_CFG(QPHY_V4_PCS_REFGEN_REQ_CONFIG1, 0x21),
>  };
>  
> +struct qmp_phy;
> +
>  /* struct qmp_phy_cfg - per-PHY initialization config */
>  struct qmp_phy_cfg {
>   /* phy-type - PCIE/UFS/USB */
> @@ -2307,6 +2309,12 @@ struct qmp_phy_cfg {
>   const struct qmp_phy_init_tbl *serdes_tbl_hbr3;
>   int serdes_tbl_hbr3_num;
>  
> + /* DP PHY callbacks */
> + int (*configure_dp_phy)(struct qmp_phy *qphy);
> + void (*configure_dp_tx)(struct qmp_phy *qphy);
> + int (*calibrate_dp_phy)(struct qmp_phy *qphy);
> + void (*dp_aux_init)(struct qmp_phy *qphy);
> +
>   /* clock ids to be requested */
>   const char * const *clk_list;
>   int num_clks;
> @@ -2423,6 +2431,216 @@ struct qcom_qmp {
>   struct reset_control *ufs_reset;
>  };
>  
> +static void qcom_qmp_v3_phy_dp_aux_init(struct qmp_phy *qphy)
> +{
> + writel(DP_PHY_PD_CTL_PWRDN | DP_PHY_PD_CTL_AUX_PWRDN |
> +DP_PHY_PD_CTL_PLL_PWRDN | DP_PHY_PD_CTL_DP_CLAMP_EN,
> +qphy->pcs + QSERDES_V3_DP_PHY_PD_CTL);
> +
> + /* Turn on BIAS current for PHY/PLL */
> + writel(QSERDES_V3_COM_BIAS_EN | QSERDES_V3_COM_BIAS_EN_MUX |
> +QSERDES_V3_COM_CLKBUF_L_EN | QSERDES_V3_COM_EN_SYSCLK_TX_SEL,
> +qphy->serdes + QSERDES_V3_COM_BIAS_EN_CLKBUFLR_EN);
> +
> + writel(DP_PHY_PD_CTL_PSR_PWRDN, qphy->pcs + QSERDES_V3_DP_PHY_PD_CTL);
> +
> + writel(DP_PHY_PD_CTL_PWRDN | DP_PHY_PD_CTL_AUX_PWRDN |
> +DP_PHY_PD_CTL_LANE_0_1_PWRDN |
> +DP_PHY_PD_CTL_LANE_2_3_PWRDN | DP_PHY_PD_CTL_PLL_PWRDN |
> +DP_PHY_PD_CTL_DP_CLAMP_EN,
> +qphy->pcs + QSERDES_V3_DP_PHY_PD_CTL);
> +
> + writel(QSERDES_V3_COM_BIAS_EN |
> +QSERDES_V3_COM_BIAS_EN_MUX | QSERDES_V3_COM_CLKBUF_R_EN |
> +QSERDES_V3_COM_CLKBUF_L_EN | QSERDES_V3_COM_EN_SYSCLK_TX_SEL |
> +QSERDES_V3_COM_CLKBUF_RX_DRIVE_L,
> +qphy->serdes + QSERDES_V3_COM_BIAS_EN_CLKBUFLR_EN);
> +
> + writel(0x00, qphy->pcs + QSERDES_V3_DP_PHY_AUX_CFG0);
> + writel(0x13, qphy->pcs + QSERDES_V3_DP_PHY_AUX_CFG1);
> + writel(0x24, qphy->pcs + QSERDES_V3_DP_PHY_AUX_CFG2);
> + writel(0x00, qphy->pcs + QSERDES_V3_DP_PHY_AUX_CFG3);
> + writel(0x0a, qphy->pcs + QSERDES_V3_DP_PHY_AUX_CFG4);
> + writel(0x26, qphy->pcs + QSERDES_V3_DP_PHY_AUX_CFG5);
> + writel(0x0a, qphy->pcs + QSERDES_V3_DP_PHY_AUX_CFG6);
> + writel(0x03, qphy->pcs + QSERDES_V3_DP_PHY_AUX_CFG7);
> + writel(0xbb, qphy->pcs + QSERDES_V3_DP_PHY_AUX_CFG8);
> + writel(0x03, qphy->pcs + QSERDES_V3_DP_PHY_AUX_CFG9);
> + qphy->dp_aux_cfg = 0;
> +
> + writel(PHY_AUX_STOP_ERR_MASK | PHY_AUX_DEC_ERR_MASK |
> +PHY_AUX_SYNC_ERR_MASK | PHY_AUX_ALIGN_ERR_MASK |
> +PHY_AUX_REQ_ERR_MASK,
> +qphy->pcs + QSERDES_V3_DP_PHY_AUX_INTERRUPT_MASK);
> +}
> +
> +static const u8 qmp_dp_v3_pre_emphasis_hbr_rbr[4][4] = {
> + { 0x00, 0x0c, 0x14, 0x19 },
> + { 0x00, 0x0b, 0x12, 0xff },
> + { 0x00, 0x0b, 0xff, 0xff },
> + { 0x04, 0xff, 0xff, 0xff }
> +};
> +
> +static const u8 qmp_dp_v3_voltage_swing_hbr_rbr[4][4] = {
> + { 0x08, 0x0f, 0x16, 0x1f },
> + { 0x11, 0x1e, 0x1f, 0xff },
> + { 0x19, 0x1f, 0xff, 0xff },
> + { 0x1f, 0xff, 0xff, 0xff }
> +};
> +
> +static void qcom_qmp_v3_phy_configure_dp_tx(struct qmp_phy *qphy)
> +{
> + const struct phy_configure_opts_dp *dp_opts = >dp_opts;
> + unsigned int v_level = 0, p_level = 0;
> + u32 bias_en, drvr_en;
> + u8 voltage_swing_cfg, pre_emphasis_cfg;
> + int i;
> +
> + for (i = 0; i < dp_opts->lanes; i++) {
> + v_level = max(v_level, dp_opts->voltage[i]);
> + p_level = max(p_level, dp_opts->pre[i]);
> + }
> +
> + if (dp_opts->lanes == 1) {
> + bias_en = 0x3e;
> + drvr_en = 0x13;
> + } else {
> + bias_en = 0x3f;
> + drvr_en = 0x10;
> + }
> +
> + voltage_swing_cfg = qmp_dp_v3_voltage_swing_hbr_rbr[v_level][p_level];
> + pre_emphasis_cfg = qmp_dp_v3_pre_emphasis_hbr_rbr[v_level][p_level];
> +
> + /* TODO: Move check to config check */
> + if (voltage_swing_cfg == 0xFF && pre_emphasis_cfg == 0xFF)
> + return;
> +
> + /* Enable 

Re: [PATCH v5 2/7] dt-bindings: phy: qcom,qmp-usb3-dp: Add support for SM8250

[Bjorn Andersson]

On Sun 28 Mar 15:52 CDT 2021, Dmitry Baryshkov wrote:

> Add compatible for SM8250 in QMP USB3 DP PHY bindings.
> 
> Signed-off-by: Dmitry Baryshkov 
> Acked-by: Rob Herring 

Reviewed-by: Bjorn Andersson 

> ---
>  Documentation/devicetree/bindings/phy/qcom,qmp-usb3-dp-phy.yaml | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/Documentation/devicetree/bindings/phy/qcom,qmp-usb3-dp-phy.yaml 
> b/Documentation/devicetree/bindings/phy/qcom,qmp-usb3-dp-phy.yaml
> index 62c0179d1765..217aa6c91893 100644
> --- a/Documentation/devicetree/bindings/phy/qcom,qmp-usb3-dp-phy.yaml
> +++ b/Documentation/devicetree/bindings/phy/qcom,qmp-usb3-dp-phy.yaml
> @@ -15,6 +15,7 @@ properties:
>  enum:
>- qcom,sc7180-qmp-usb3-dp-phy
>- qcom,sdm845-qmp-usb3-dp-phy
> +  - qcom,sm8250-qmp-usb3-dp-phy
>reg:
>  items:
>- description: Address and length of PHY's USB serdes block.
> -- 
> 2.30.2
> 

Re: [PATCH v5 1/7] dt-bindings: phy: qcom,qmp-usb3-dp-phy: move usb3 compatibles back to qcom,qmp-phy.yaml

[Bjorn Andersson]

On Sun 28 Mar 15:52 CDT 2021, Dmitry Baryshkov wrote:

> The commit 724fabf5df13 ("dt-bindings: phy: qcom,qmp-usb3-dp: Add DP phy
> information") has support for DP part of USB3+DP combo PHYs. However
> this change is not backwards compatible, placing additional requirements
> onto qcom,sc7180-qmp-usb3-phy and qcom,sdm845-qmp-usb3-phy device nodes
> (to include separate DP part, etc). However the aforementioned nodes do
> not inclue DP part, they strictly follow the schema defined in the
> qcom,qmp-phy.yaml file. Move those compatibles, leaving
> qcom,qmp-usb3-dp-phy.yaml to describe only real "combo" USB3+DP device nodes.
> 
> Fixes: 724fabf5df13 ("dt-bindings: phy: qcom,qmp-usb3-dp: Add DP phy 
> information")
> Cc: Stephen Boyd 
> Cc: Sandeep Maheswaram 
> Signed-off-by: Dmitry Baryshkov 
> Acked-by: Rob Herring 
> Reviewed-by: Stephen Boyd 

Reviewed-by: Bjorn Andersson 

> ---
>  Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml | 2 ++
>  Documentation/devicetree/bindings/phy/qcom,qmp-usb3-dp-phy.yaml | 2 --
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml 
> b/Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml
> index 626447fee092..7808ec8bc712 100644
> --- a/Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml
> +++ b/Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml
> @@ -25,11 +25,13 @@ properties:
>- qcom,msm8998-qmp-pcie-phy
>- qcom,msm8998-qmp-ufs-phy
>- qcom,msm8998-qmp-usb3-phy
> +  - qcom,sc7180-qmp-usb3-phy
>- qcom,sc8180x-qmp-ufs-phy
>- qcom,sc8180x-qmp-usb3-phy
>- qcom,sdm845-qhp-pcie-phy
>- qcom,sdm845-qmp-pcie-phy
>- qcom,sdm845-qmp-ufs-phy
> +  - qcom,sdm845-qmp-usb3-phy
>- qcom,sdm845-qmp-usb3-uni-phy
>- qcom,sm8150-qmp-ufs-phy
>- qcom,sm8150-qmp-usb3-phy
> diff --git a/Documentation/devicetree/bindings/phy/qcom,qmp-usb3-dp-phy.yaml 
> b/Documentation/devicetree/bindings/phy/qcom,qmp-usb3-dp-phy.yaml
> index 33974ad10afe..62c0179d1765 100644
> --- a/Documentation/devicetree/bindings/phy/qcom,qmp-usb3-dp-phy.yaml
> +++ b/Documentation/devicetree/bindings/phy/qcom,qmp-usb3-dp-phy.yaml
> @@ -14,9 +14,7 @@ properties:
>compatible:
>  enum:
>- qcom,sc7180-qmp-usb3-dp-phy
> -  - qcom,sc7180-qmp-usb3-phy
>- qcom,sdm845-qmp-usb3-dp-phy
> -  - qcom,sdm845-qmp-usb3-phy
>reg:
>  items:
>- description: Address and length of PHY's USB serdes block.
> -- 
> 2.30.2
> 

Re: [PATCH v2 04/13] spidev: Add Pensando CPLD compatible

[Brad Larson]

On Mon, Mar 29, 2021 at 3:45 AM Andy Shevchenko
 wrote:
>
> On Mon, Mar 29, 2021 at 5:01 AM Brad Larson  wrote:
> >
> > Pensando Elba SoC platforms have a SPI connected CPLD
> > for platform management.
>
> And? It's not a good justification to spread the (debugging only)
> spidev interface.
>
> What tool is going to use it? Why can't you have a driver for that in
> the kernel?

The driver is in userspace and we need to instantiate /dev/spi0.N
in the /dev directory.  The CPLD includes a device id and version
id that userspace applications use to differentiate functionality on
different boards.  It wouldn't really be appropriate to use one of
the existing entries.

For example even with high pin count SoCs we are offloading
low speed functionality into the CPLD connected over SPI.  The
elba-asic-common.dtsi file shows a compatible string of
"pensando,cpld-rd1173" which does have a kernel driver we
intend to contribute later if there is interest.  This IP in the CPLD
is readily available from Lattice which provides two I2C Masters
which in our case we use for access to the network port transceivers.
What was missing in the kernel was a bridge driver that exposes
what looks like a standard I2C device to userspace where the
drivers/i2c/busses/i2c-rd1173.c handles the spi transfers to the
Lattice IP in the CPLD.

>
> --
> With Best Regards,
> Andy Shevchenko